Anthropic 实战复盘：为什么我们决定用 MCP 统一一切工具调用

这是一次来自 Anthropic 一线工程师的复盘分享，讲述他们在大规模落地 AI 工具调用时踩过的坑，以及为什么最终选择用 MCP 作为统一标准。文章将带你理解 MCP 真正解决了什么问题，以及它在安全、扩展性和组织效率上的长期价值。

从 20 年踩坑史出发：这不是一次“新协议布道”

这场分享一开始就定下了基调。John Welsh 并不是以“标准制定者”的姿态出现，而是以一个在大型系统里工作了 20 年、犯过无数错误的工程师身份。他直言，自己过去几个月在 Anthropic 做的事情非常具体：围绕工具调用（tool calling）和外部集成，给内部系统实现 MCP 支持。

这个背景很重要，因为 MCP（Model Context Protocol）并不是一个抽象的“未来标准”，而是 Anthropic 在真实业务压力下的工程选择。John 说，他之所以愿意出来分享，是希望别人“maybe some thoughts on avoiding some of those mistakes”。这不是炫技，而是一次经验止损。

在 Anthropic 这样的组织里，模型并不是孤立运行的。模型需要上下文，需要访问工具，需要和外部世界交互。而当这些需求在一个快速增长的组织里爆发时，问题往往不是“模型能不能做”，而是“系统还能不能管得住”。

John 的核心视角很工程化：当一家公司开始规模化使用 LLM，真正的难点很快会从模型能力，转移到工具集成、标准化和安全边界上。这也为后面 MCP 的出现，埋下了现实动因。

工具调用爆发后的混乱：每个团队都在“重新造轮子”

John 描述了一个很多 AI 团队都正在经历的阶段：大概在 2024 年中，模型终于“足够擅长”调用工具了。模型可以查 Google Drive、调地图、发消息，几乎不需要太多额外工作，就能做出看起来很酷的应用。

结果是，所有人都开始加速。每个团队、每个用例，都快速做了自己的工具接口：/call、/get_context、各种自定义 endpoint。短期内看，这是效率；中期来看，就变成了灾难。

John 用一句话总结这种状态：“you have an integration that works really well in service A， but then you want to use it in service B but you can't because it's going to take you three weeks to rewrite it”。接口不统一、认证方式不同、上下文格式不一致，导致复用成本极高。

更糟的是，这些问题一开始并不明显。因为在小规模时，一切“还能跑”。但当工具数量、服务数量、Agent 数量同时增长时，组织内部就进入了他所说的“integration chaos”。这并不是 Anthropic 独有的问题，而是 LLM 工程进入第二阶段后，几乎必然出现的结构性问题。

MCP 的两张脸：真正有价值的不是传输层

在解释 MCP 时，John 刻意拆开了它的两个部分。他认为，这两部分在心理上“感觉有点不相关”。

第一部分，是 MCP 的 JSON-RPC 消息规范。它定义了模型和上下文提供方之间，如何以结构化的方式请求工具、资源和补充信息。这部分对工程师来说极其重要，因为它让“模型在问什么、系统在给什么”变得可推理、可审计。

第二部分，是所谓的“全局传输标准”，包括 streamable HTTP、OAuth 2.1、会话管理等。John 非常坦率地说，这部分“really nitty”，而且标准化很难，因为你在试图让所有人说同一种语言。

他的关键判断是：MCP 的大部分价值，其实不在传输层，而在消息规范本身。甚至即使你一开始没有完整使用 MCP 的所有能力，随着系统演进，你“最终也会发明出一个长得很像 MCP 的东西”。

这也是 Anthropic 内部的结论：与其晚点被迫迁移，不如一开始就统一。正如 John 说的：“being boring on stuff like this is good”。把非竞争优势的部分标准化，反而释放了工程组织的创造力。

MCP Gateway：把混乱压缩到一个入口

真正体现 Anthropic 工程取舍的，是他们设计的 MCP Gateway。这是一个共享基础设施，目标只有一个：让工程师只需要调用一次“connect to MCP”，就能获得一个可用的 MCP 客户端会话。

这个设计解决了多个正在同时逼近的问题。第一，外部开始出现远程 MCP 服务，连接它们需要网络、认证和安全策略。第二，内部 Agent 数量爆炸：PR review bot、Slack 管理工具、各种实验性服务层出不穷。第三，安全风险急剧上升——你不可能让每个 Agent 都直接接触用户凭证。

Gateway 的做法是集中处理：URL 路由区分内部和外部 MCP 服务；统一的凭证管理，避免在公司里“implement OAuth five times”；集中做限流和可观测性。这些都不是炫酷功能，但极其关键。

在内部传输上，他们选择了 WebSocket，并明确表示：这完全是组织层面的选择。因为在 MCP 的视角下，“MCP is really just JSON streams”。你如何在基础设施里搬运这些流，只是实现细节。

一个额外但非常重要的收益，是安全。John 提到，MCP Gateway 成为了模型上下文的“中央观察点”，这对于研究和防御 MCP prompt injection 攻击，提供了现实基础。

总结

这场分享的价值，并不在于教你“如何实现 MCP”，而在于展示了一家顶级 AI 公司是如何在混乱中做工程决策的。Anthropic 选择 MCP，不是因为它完美，而是因为它足够早地解决了未来一定会出现的问题。对任何正在构建 AI Agent 或工具生态的团队来说，这都是一次关于标准化、边界和长期成本的清醒提醒。

关键词： MCP， Anthropic， AI Agent， 工具调用， AI 安全

事实核查备注： John Welsh 为 Anthropic Member of Technical Staff；视频标题为“Remote MCPs： What we learned from shipping”；MCP 被描述为 JSON-RPC 消息规范 + 全局传输标准；Anthropic 内部使用 WebSocket 作为传输；提到 OAuth 2.1、JSON streams、MCP Gateway、prompt injection attacks。