问 HN：谁在生产环境中使用 MCP？

Hacker News 讨论 ↗

开发者正越来越多地在生产环境中部署 Model Context Protocol（MCP）服务器，以便让 AI agent 安全地与 Jira、GitHub、CRM、监控工具和自定义内部应用等企业系统交互。支持者认为，MCP 为工具发现、基于 OAuth 的认证和细粒度能力边界提供了标准化方式——这对非技术用户以及第三方语音/聊天平台尤其有价值——而批评者则认为，随着模型更擅长使用工具，许多场景更适合直接 API 或 CLI。总体而言，MCP 正在成为 AI agent 在多系统、多供应商环境中的事实标准集成层，尽管它长期是否必要以及效率如何仍存在争议。

整体情绪

  • 很多评论者正在生产环境中积极使用 MCP（Model Context Protocol）；也有人持怀疑态度，或认为随着模型和 CLI 的改进，它的价值正在缩小。
  • 对“开发者在终端里用的 agent”与“终端用户 / 企业集成”之间存在明显分歧，后者通常被认为 MCP 更有价值。

常见的生产环境用例

  • 面向客户和内部的语音代理：预约安排、订单状态、CRM 访问、电话接待员。
  • SaaS 产品：CRM/ERP、托管/控制面板、监控、合规工具、报表/分析、社交媒体管理、帮助中心、电商分析、垂直细分工具。
  • 开发者工作流：缺陷/功能报告、任务跟踪、项目管理（Jira/Linear 等）、跨日志/指标/告警的代码调试、基础设施配置。
  • 个人/实验性工具：学习助手、自定义数据归档、买菜、语言学习、家庭自动化、视觉特效工作流、个人工单板。
  • 跨系统的“网关”型 MCP，将日志、指标、多种 API 或遗留系统统一成一个对 agent 友好的入口。

感知到的优势

  • 标准化、原生面向 agent 的接口：
    • 工具/资源是自描述且可发现的。
    • 比起原始 API 端点，更容易暴露“配方”/工作流。
  • 认证与安全：
    • OAuth + 标准化流程；用户可以通过点击/OAuth 连接，而不是管理 API key。
    • 可以严格限定能力范围，并向模型隐藏底层服务凭证。
  • 分发与易用性：
    • 非技术用户无需 CLI 就能把产品接入 ChatGPT/Claude 等。
    • 同一个 MCP 经常可被应用内助手、外部 agent 和多个供应商复用。
  • 抽象层：
    • 用更干净、针对 LLM 调优的一层，封装丑陋、不一致或难以更改的 REST/CLI 接口。

批评与怀疑

  • 许多开发者更偏好 CLI 或直接 API：
    • 成本更低、token 使用更高效、更容易调试、上下文膨胀更少。
    • 技能 + shell 访问通常就已经足够。
  • 有人抱怨 MCP 服务器质量参差不齐；很多甚至比直接 API 更差。
  • 一些人认为，随着模型对 API/CLI 的使用能力提升，MCP 只是昙花一现或不必要的抽象。
  • 构建一个“工程质量很好”的 MCP 被描述为很重：需要仔细设计、基准测试和持续迭代。
  • 对于开发密集型团队，人们会质疑它相对“优秀的 REST + 文档”到底有多少边际收益。

细微差别与未解问题

  • token 效率和性能比较仍有争议。
  • 工具的延迟加载和工具搜索可以缓解开销，但取决于 harness。
  • MCP 与 API/skills/CLI 的长期角色仍在争论中，尚无定论。