新的 MCP 路线图

原文 ↗ Hacker News 讨论 ↗

Anthropic 更新后的 Model Context Protocol (MCP) 路线图在开发者中引发了褒贬不一的反应：人们欢迎其向无状态、基于 HTTP 的服务器以及更好的 agent 授权迈进，但也批评该规范在实践中过度设计且碎片化。许多人认为，现有模式如 REST + OpenAPI（或带直接 HTTP 访问的“代码模式”）往往更简单、性能更好，尤其适用于非交互式工作负载；而 MCP 的价值主要在于标准化的工具发现、细粒度权限和更适合企业的认证流程。普遍共识是，长寿命 token 和人工浏览器审批并不适合自治 agent 的规模化使用，但对于 MCP 是否是合适的抽象层，还是又一个追逐 AI 热潮的复杂协议，大家并无一致看法。

代码模式 vs MCP

  • 几位评论者正在从基于 MCP 的方案转向“代码模式”（例如 Cloudflare 的做法），理由是运行时性能更好、对复杂工具调用的编排更灵活，而且协议麻烦更少。
  • 有人要求提供比较 MCP 与代码模式的量化基准；线程中没有给出数据，因此相对性能影响仍不明确。

认证、身份与安全

  • 路线图对 DPoP、Workload Identity Federation 以及基于 OAuth 的标准的关注引发了讨论。
  • 批评者认为这属于过度设计，并主张把存储在 secret manager 里的长寿命 token（例如 1Password）作为更简单的方案。
  • 也有人回应说，长寿命凭证，尤其是交到 agent 手里，对许多组织来说根本不可接受；出于吊销、委派和合规等需求，复杂协议是必要的。
  • 企业托管、非交互式的 agent 认证是一个主要目标；人工浏览器审批被视为扩展性瓶颈。
  • 对“子实体”（专门化 agent）进行细粒度、类似角色的权限控制被认为是必要的，但在用户体验上具有挑战性。

协议设计、传输与状态

  • 许多人欢迎转向“MCP over HTTP”，并将 MCP 视为和其他 HTTP 工作负载一样的东西；专门的 v1 协议则普遍被批评为碎片化且令人困惑。
  • 关于 stdio 的未来存在困惑；线程中的最佳猜测是通过 stdio 运行 HTTP，但这也被描述为不够明确。
  • 有些人不喜欢把 HTTP 作为通用 IPC 层，更偏好与传输无关的核心协议；另一些人指出 gRPC 方案看起来过于笨重。
  • v1 的有状态设计被称为不利于部署且难以测试；向无状态转变受到赞赏。

MCP vs REST、Skills 与 OpenAPI

  • 多位评论者认为，一个文档完善的 REST API 加上 skills/markdown 描述或 OpenAPI 规范，对 agent 来说已经足够好用。
  • MCP 的主要附加价值被描述为：
    • 集中式、自动化的工具发现与更新。
    • API 与工具定义之间的紧密一致性。
    • 细粒度、按工具划分的授权，以及更容易对能力进行门控。
  • 其他人反驳说，企业已经在管理成千上万的 HTTP 端点，而 MCP 会增加变动和潜在的破坏性改动，却看不出明确回报。

复杂性、采用情况与现实使用

  • 有些人认为 MCP 正在“跳鲨鱼”，试图吞并过多的 HTTP 和认证功能；他们计划继续使用最小化的 JSON-RPC 式用法。
  • 也有人对早期 MCP 推出涉及多个部分重叠的标准、重上下文设计以及客户端支持不一致感到沮丧，认为这消耗了信任。
  • 仍有少数人认为 MCP 在更狭窄、交互式的场景中很有前景，例如：安全地封装特权 API、通过 elicitation 执行特权操作，以及缩减工具目录以减少上下文膨胀。