摘要：MCP（Model Context Protocol，模型上下文协议）号称要将 AI 与工具的交互标准化为「AI 的 USB-C」。虽然其简单性加速了采用，但 MCP 系统性地忽视了分布式系统领域四十年来的惨痛教训。这不是学术担忧：如今部署 MCP 的企业正在

原文 | https://julsimon.medium.com/why-mcps-disregard-for-40-years-of-RPC-best-practices-will-burn-enterprises-8ef85ce5bc9b

编译 | 段小草 + Grok 4（需要修改的细节用语比较多，综合来看还是 Gemini 好用）

上当一次，是你的错；上当两次，是我的错。

MCP（Model Context Protocol，模型上下文协议）号称要将 AI 与工具的交互标准化为「AI 的 USB-C」。虽然其简单性加速了采用，但 MCP 系统性地忽视了分布式系统领域四十年来的惨痛教训。这不是学术担忧：如今部署 MCP 的企业正在基于缺乏基本能力的基金会构建，而这些基本能力是自 1982 年以来每个生产级远程过程调用（RPC）系统都视为必需的。

MCP 的倡导者将该协议定位为生产就绪的基础设施，但其设计哲学优先考虑采用的便利性而非操作鲁棒性，这为企业埋下了一个定时炸弹。同样的简单性让开发者能在下午集成一个工具，但当该工具处理数百万具有实际业务影响的请求时，它就成为一个负担。

AI 炒作周期加速了 MCP 的采用，超出了其架构成熟度。公司部署 MCP 不是因为它满足了他们的操作要求，而是因为 AI 淘金热要求立即行动。这种期望与能力之间的不匹配将导致痛苦的生产事故。

让我们从 1982 年引入的 UNIX RPC 开始。其设计者理解了一个基本原则：当系统使用不同语言或运行在异构架构上时，仅凭良好意图不足以确保一个系统上的 32 位整数不会在另一个系统上变成垃圾数据。他们的解决方案 External Data Representation（XDR）不是过度工程设计。它对那些数据损坏可能导致系统故障的系统至关重要。Interface Definition Language（IDL）能在编译时而非运行时就捕获类型不匹配问题。

MCP 丢弃了这一教训，选择采用无模式 JSON 伴随可选的、非强制执行的提示。类型验证发生在运行时，如果有的话。当 AI 工具期望 ISO-8601 时间戳但收到 Unix 时间时，模型可能幻觉日期而不是明确地报错。在金融服务中，这意味着交易 AI 可能误解数值类型并以错误的十进制精度执行交易。在医疗保健中，患者数据类型被错误强制转换，可能导致错误的药物剂量推荐。制造系统在 JSON 序列化过程中丢失传感器读数精度，导致质量控制故障。

CORBA 在 1991 年提出了另一个关键洞见：在异构环境中，你不能只是「在每种语言中实现协议」并寄希望于最好。OMG IDL 生成一致的绑定，跨越 C++、Java、Python 等，确保 C++ 服务器抛出的异常被 Java 客户端正确捕获和处理。生成的绑定保证所有语言看到相同的接口，防止微妙的序列化差异。

MCP 完全忽略了这一点。每种语言独立实现 MCP，必然会导致不一致性。Python 的 JSON 编码器处理 Unicode 的方式不同于 JavaScript 的 JSON 编码器。浮点表示各不相同。错误传播机制随意。当前端 JavaScript 和后端 Python 以不同方式解释 MCP 消息时，就会引发集成噩梦。使用不同 MCP 库的第三方工具在边缘情况下表现出微妙的不兼容性。语言特定的 bug 需要精通每种实现方式，而非协议本身的知识。

2000 年诞生的两大协议带来了互补的经验教训。REST 教会我们无状态性实现水平扩展：任何服务器都能处理任何请求，允许负载均衡和容错。缓存头将后端负载减少几个数量级。统一接口与清晰的动词语义使请求意图对中间件显而易见。

MCP 混淆了有状态和无状态操作且界限模糊。虽然它通过 Mcp-Session-Id 头维护会话，但没有缓存控制机制，没有标准化操作语义来启用安全重试。工具调用无法安全重试或负载均衡，除非理解它们的副作用。你无法在没有复杂会话亲和性的情况下水平扩展 MCP 服务器。即使对于相同、重复的查询，每个请求都会直达后端。

SOAP 尽管冗长，但它理解了一个 MCP 未能领悟的要义：机器可读合约很重要。WSDL 启用自动化客户端生成、合约验证和兼容性检查。WS-Security 意味着安全令牌随消息传输。标准化的故障合约启用跨平台一致的错误处理。

MCP 不具备这些丰富特性。除了基本 JSON 模式之外没有机器可读合约，意味着你无法生成类型安全的客户端或向审计员证明 AI 交互遵循指定的合约。虽然 MCP 在 2025 年 3 月 26 日修订版中加入了 OAuth 2.1 支持，但这一关键安全功能并非最初协议的一部分，企业匆忙采用的正是那个版本。即使现在，它仅适用于 HTTP 传输。stdio 传输依赖环境变量进行凭据，这是一种 1970 年代的方法，完全无法满足现代企业所需的细粒度访问控制。协议层面的模式变更会无声无息地破坏客户端，且完全不提供版本控制支持。

快进到 2016 年，gRPC 向我们展示了为什么在分布式系统中可观测性不是可选的。内置分布式跟踪与元数据传播启用调试。双向流式传输启用响应式 UI。截止期限传播防止级联故障。结构化状态码区分可重试故障与永久故障。

MCP 的流式支持暴露了功能清单与实际能力间的巨大鸿沟。是的，它支持 Server-Sent Events 用于流式响应，也允许服务器主动发起请求。然而，它缺乏 gRPC 在单个 RPC 调用中的双向流式传输，强制通过多个往返实现复杂交互模式。没有跟踪上下文传播。你无法跟随 AI 的决策路径通过多个工具调用。没有截止时间传播机制，一个缓慢的工具可以阻塞整个 AI 智能体。虽然 MCP 使用 JSON-RPC 的错误结构，带有 code 和 message 字段，但它缺乏丰富的、可操作的错误分类，例如区分「超过速率限制，30 秒后重试」与「无效输入，修复你的请求」这些本质不同的错误场景。

这正是 MCP 倡导者揭示协议根本失败的地方。每当有人指出任何这些短板，他们会条件反射般地回应「但我们有 mcp-oauth-wrapper 来添加鉴权认证！」或「试试用 mcp-tracing-extension 实现分布式跟踪！」或「公司 X 开源了 mcp-schema-generator 就能解决 IDL 问题！」

这种回应本身就是问题。当你的协议对关键企业要求的答案是一系列第三方库时，你构建就不是一个协议，而是在构建了制造分裂的配方。

试想一下，这对企业架构师意味着什么：

这正是协议本应该防止的碎片化。gRPC 不需要第三方跟踪库，它内置了该功能。REST 不需要外部缓存语义，这些已经是 HTTP 的一部分。CORBA 不需要社区维护的 IDL 生成器，ORB 供应商提供了这些工具。

这种生态系统碎片化的企业成本是惊人的。你不是在培训开发者一个协议，而是 MCP 加上十几个半兼容扩展。你不是进行单一安全审计，而是审计多个认证库。你不是管理单一供应商关系，而是管理几个质量和承诺水平不同的开源项目。

2025–03–26 协议修订读起来像是一个补丁清单列表，列出了企业在生产中发现缺失的一切。OAuth 支持、工具注解用于区分只读与破坏性操作、会话管理和进度通知。这些不是功能性增强，而是对仓促发布的变相承认。

以工具注解为例。MCP 现在支持将工具标记为「read-only」或「destructive」，但这一功能是在早期采用者已经构建没有此类区分的系统后引入的。这种基于能力的安全机制更像是事后补救，是在生产事故发生后打补丁，而非基于第一性原理的设计。

安全功能的缺失尤其说明问题。身份认证不是疏忽。它被认为对初始发布不必要。这揭示了对企业要求的根本误解。没有哪家财富 500 强公司会部署没有认证的数据库，但 MCP 倡导者期望他们将 AI 连接到关键业务工具而没不采用任何验证机制。

这里是一个我在不同协议中以不同形式经历过的场景。想象调试一个生产问题，其中 AI 智能体进行了 20 次工具调用跨越五个其他服务来回答客户查询，并且最终响应是错误的。

如果使用 gRPC，分布式跟踪会在几分钟内显示确切的失败调用。你会看到完整的请求流、每个步骤的延迟，以及导致问题的具体错误。跟踪 ID 会关联所有服务的日志。

使用 MCP，你需要在没有关联 ID 的多个服务中 grep JSON 日志，试图重建发生了什么。每个服务有其日志格式。没有标准方式跟踪请求跨越工具边界。你甚至无法可靠地将请求与响应匹配，而不构建自己的关联机制。这两种情况我都经历过，一个花 30 分钟，另一个花 3 天。

当 OpenAI 为上个月的 API 使用开出 50,000 美元账单时，你能分辨哪个部门的 MCP 工具驱动了该成本吗？哪些具体工具调用？哪些是个别用户或用例？

MCP 不提供这种基本操作要求的机制。没有协议级别的 token 计数。没有成本归属标识头。没有配额管理。你在 AI 支出上如同盲飞，无法优化甚至理解钱究竟去了哪里。

相比之下，云提供商几十年前就学到了这一教训。每个 AWS API 调用都可以标记、归属和成本跟踪。每个 Google Cloud 操作流入详细的计费细分。MCP 要求企业以 1990 年代水平的成本可见性来消耗昂贵的 AI 资源。

服务发现可能听起来像是锦上添花，直到你尝试构建弹性多区域部署。MCP 的手动配置假设你在部署时熟悉所有工具。一旦你需要动态扩展或故障转移，这就崩溃了。你无法构建适应基础设施变化的系统。

版本管理在你有数十个独立演化的工具时变得关键。MCP 有协议版本协商但没有模式版本。工具接口可以无警告更改。任何工具更新都可能破坏所有客户端。你面临两难选择：永不更新工具，或在整个生态系统协调大规模部署工作。

性能对于 demo 演示可能无关紧要，但 JSON 的开销和缺乏连接池的设计不适合扩展。当你需要低延迟、高吞吐量的 AI 系统用于实时应用时，MCP 的基于文本协议成为瓶颈。没有二进制协议选项，没有超出传输级 gzip 的压缩。stdio 传输特别为每个交互创建新进程连接，这些模式早在 1990 年代我们就出于充分理由而摒弃了。

企业 AI 的采用曲线正在陡峭化。企业已不再止步于试验阶段，他们正在将 AI 部署到收入关键和安全关键系统中。金融服务使用 AI 进行交易决策、欺诈检测和风险评估。医疗保健系统提供诊断支持和个性化治疗推荐。工业系统依赖 AI 进行质量控制和预测维护。客户服务通过 AI 交互处理敏感数据。

这些领域中的每一个都花费数十年构建鲁棒集成模式。MCP 要求他们放弃这些模式，转而使用一个仍在改装基本安全功能的协议。「快速行动、打破常规」的做法适用于演示，一旦应用于故障会产生实际后果的系统时，就会酿成灾难。

MCP 不需要成为 CORBA，但它必须吸纳经过验证的模式。最近的更新显示维护者正在倾听，但他们正在追赶前辈们几十年前就已解决的问题。

剩余未解决的即时需求包括改进的类型安全、集成到协议中的分布式跟踪与关联 ID、超越简单工具注解的能力型授权、用于合规的标准审计轨迹格式，以及独立于协议版本的模式版本。

短期演化应聚焦于运营的刚需，包括用于动态环境的服务发现机制、用于改进性能的连接池和持久连接、用于高吞吐量场景的二进制协议选项、防止级联故障的截止期限传播，以及带有标准化重试语义的全面错误分类。

长期成熟需要企业级功能：用于复杂交互的真正双向流式传输、内置速率限制和配额管理、SLA 执行机制、用于 token 使用的全面成本归属，以及工作流编排原语。

MCP 的当前设计反映了一个赌注，即认为在 AI 工具集成中简单性胜过稳健性。这一赌注对于实验阶段尚可理解，但对于生产部署导致灾难性的失败。MCP 协议的快速采用，是由 AI 炒作驱动，而非实际需求驱动，正使企业面临痛苦的失败。

关键功能的后续补丁证明 MCP 被过早发布。企业基于承诺和炒作采用它，而不是实际情况。现在他们正在发现事后添加安全、可观测性和适当错误处理，无异于在汽车撞车后才加装安全气囊。

我们在分布式系统中拥有四十年的经验，展示了哪些模式启用可靠、安全和可扩展的操作。这些不是学术练习。而是针对系统故障曾让企业付出真金白银代价的问题解决方案。

时间窗口正在关闭。随着企业触及 MCP 的局限性，他们将构建专有解决方案。软件供应商也会如此。MCP 原本想要防止的碎片化仍会出现，只不过多了额外步骤和资源浪费。

AI 行业有一个选择：要么四十年 RPC 演化中借鉴学习，要么重蹈所有惨痛错误的覆辙。基于当前发展轨迹，关键功能作为事后补救被临时拼凑，我们正在选择后者。企业将为此付出代价——遭遇失败部署、遭遇本可完全避免的部署失败、安全漏洞和运维噩梦。

Julien

—

此分析基于最新的 MCP 规范：

来源：不二小段