模型上下文协议 （MCP） 承诺将 AI 工具交互标准化为“用于 AI 的 USB-C”。虽然 MCP 的简单性加速了采用，但它系统地忽视了四十年来之不易的分布式系统经验教训。这不是一个学术问题：今天部署 MCP 的企业正在建立在缺乏自 1982 年以来每个生产远程过程调用 （RPC） 系统都认为必不可少的基本功能的基础上。

炒作与现实之间的危险差距

MCP 的倡导者将该协议定位为生产就绪的基础设施，但其设计理念将易于采用置于运营稳健性之上，这为企业制造了一颗定时炸弹。当开发人员处理具有实际业务影响的数百万个请求时，使开发人员能够在下午集成工具的简单性就变成了一种负担。

人工智能炒作周期加速了 MCP 架构成熟度的采用。公司部署 MCP 并不是因为它满足了他们的运营要求，而是因为人工智能淘金热需要立即采取行动。这种期望和能力之间的不匹配将导致痛苦的生产失败。

四十年的教训被忽视

让我们从 1982 年推出的 UNIX RPC 开始。创建者明白一些基本的东西：当系统使用不同的语言或在异构架构上运行时，您需要的不仅仅是良好的意图，以确保一个系统上的 32 位整数不会成为另一个系统上的垃圾数据。他们的解决方案外部数据表示 （XDR） 并没有过度工程化。对于数据损坏可能导致系统故障的系统来说，这是至关重要的。具有编译器生成存根的接口定义语言 （IDL） 在生成时（而不是运行时）捕获类型不匹配。

MCP 放弃了这一课，选择了带有可选的非强制提示的无架构 JSON。类型验证在运行时进行（如果有的话）。当 AI 工具期望 ISO-8601 时间戳但收到 Unix 纪元时，模型可能会产生日期幻觉，而不是完全失败。在金融服务领域，这意味着交易人工智能可能会误解数字类型并以错误的小数精度执行交易。在医疗保健领域，患者数据类型被错误地强制，可能导致错误的药物剂量建议。制造系统在 JSON 序列化过程中失去传感器读取精度，导致质量控制失败。

CORBA 于 1991 年问世，带来了另一个重要的见解：在异构环境中，您不能只是用每种语言“实现协议”并希望得到最好的结果。OMG IDL 在 C++、Java、Python 等中生成一致的绑定，确保服务器抛出的 C++ 异常被 Java 客户端正确捕获和处理。生成的绑定保证了所有语言都看到相同的接口，从而防止了细微的序列化差异。

MCP 完全忽略了这一点。每种语言独立实现 MCP，保证不一致。Python 的 JSON 编码器处理 Unicode 的方式与 JavaScript 的 JSON 编码器不同。浮点表示形式各不相同。错误传播是临时的。当前端 JavaScript 和后端 Python 以不同的方式解释 MCP 消息时，您会遇到集成噩梦。使用不同 MCP 库的第三方工具仅在边缘情况下表现出细微的不兼容性。特定于语言的错误需要每个实现的专业知识，而不是协议知识。

2000年带来了两项具有互补教训的主要议定书。REST 告诉我们，无状态可以实现水平扩展：任何服务器都可以处理任何请求，从而实现负载平衡和容错。缓存标头将后端负载减少了几个数量级。具有清晰动词语义的统一接口使请求意图对中介来说很明显。

MCP 混合了有状态和无状态作，没有明确的区别。虽然它通过 Mcp-Session-Id 标头维护会话，但没有缓存控制机制，也没有支持安全重试的标准化作语义。如果不了解工具调用的副作用，就无法安全地重试或进行负载均衡。如果没有复杂的会话关联性，就无法水平扩展 MCP 服务器。即使对于相同的重复查询，每个请求都会到达后端。

SOAP 尽管很冗长，但它理解了 MCP 所不理解的事情：机器可读的合约很重要。WSDL 支持自动客户端生成、协定验证和兼容性检查。WS-Security 意味着安全令牌随消息一起传输。标准化的故障协定实现了跨平台的一致错误处理。

MCP 没有这种丰富性。除了基本的 JSON 模式之外，没有机器可读的合约意味着您无法生成类型安全的客户端或向审计员证明 AI 交互遵循指定的合约。虽然 MCP 现在包括 OAuth 2.1 支持（截至 2025-03-26 年修订版），但这一关键安全功能并不是企业急于采用的原始协议的一部分。即使现在，它也仅适用于 HTTP 传输。stdio 传输依赖于环境变量来获取凭据，这是一种 1970 年代的方法，缺乏现代企业所需的精细访问控制。架构更改会以静默方式中断客户端，并且没有超出协议级别的版本控制支持。

快进到 2016 年，gRPC 向我们展示了为什么可观测性在分布式系统中不是可选的。具有元数据传播功能的内置分布式跟踪支持调试。双向流式处理支持响应式 UI。截止时间传播可防止级联故障。结构化状态代码区分可重试故障和永久故障。

MCP 的流式传输支持揭示了复选框和功能之间的鸿沟。是的，它支持用于流响应的服务器发送事件，是的，服务器可以发起请求。然而，它在单个 RPC 调用中缺乏 gRPC 的双向流，迫使复杂的交互模式通过多次往返来实现。没有跟踪上下文传播。您无法通过多个工具调用来跟踪 AI 的决策路径。如果没有截止日期传播，单个缓慢的工具可能会阻止整个 AI 代理。虽然 MCP 将 JSON-RPC 的错误结构与代码和消息字段一起使用，但它缺乏丰富、可作的错误分类法，例如，“超出速率限制，在 30 秒内重试”与“无效输入，修复您的请求”。

“只使用这个库”陷阱

这就是 MCP 倡导者揭示该协议根本失败的地方。指出这些差距中的任何一个，他们会立即回答“哦，但是有 mcp-oauth-wrapper 添加了身份验证！”或“查看用于分布式跟踪的 mcp-tracing-extension！”或“X 公司开源 mcp-schema-generator 解决了 IDL 问题！

这种响应模式本身就是问题所在。当您的协议对关键企业需求的答案是一系列第三方库时，您还没有构建协议。你已经构建了一个碎片化的秘诀。

考虑一下这对企业架构师意味着什么：

• 我们应该对五个竞争的 MCP 身份验证库中的哪一个进行标准化？
• 这些库是否得到维护？两年后它们会出现吗？
• 它们是否互作？使用 mcp-auth-li，b 的工具 A 是否可以使用 mcp-security-wrapper 与工具 B 一起使用？
• 谁负责修复安全漏洞？
• 我们如何确保在 200 人的工程团队中实现一致的实施？

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

这种生态系统碎片化的企业成本是惊人的。您不是在一种协议上培训开发人员，而是在 MCP 和十几个半兼容扩展上培训他们。您不是执行单个安全审核，而是审核多个身份验证库。您不是管理单个供应商关系，而是管理与多个质量和承诺级别不同的开源项目的关系。

拼凑协议问题

2025-03-26 协议修订版读起来就像一个补丁说明列表，列出了企业在生产中发现的所有内容。OAuth 支持、用于区分只读作和破坏性作的工具注释、会话管理和进度通知。这些不是增强，而是承认过早释放。

考虑工具注释。MCP 现在支持将工具标记为“只读”或“破坏性”，但此功能是在早期采用者已经构建了没有此类区别的系统之后引入的。它是基于能力的安全性，是事后才想到的，是在生产事件发生后进行改造的，而不是根据第一原则进行设计。

安全方面的新增功能尤其能说明问题。身份验证不是疏忽。对于初始版本来说，它被认为是不必要的。这揭示了对企业需求的根本误解。没有一家财富 500 强公司会在没有身份验证的情况下部署数据库，但 MCP 倡导者希望他们在没有身份验证的情况下将人工智能连接到关键业务工具。

调试噩梦

这是我在多个协议中以不同形式生活的场景。想象一下，调试一个生产问题，其中 AI 代理在其他五个服务中进行了 20 次工具调用来回答客户查询，但响应是错误的。

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

使用 MCP，您需要跨多个服务浏览 JSON 日志，没有相关 ID，尝试重建发生的事情。每个服务都有其日志格式。没有跨工具边界跟踪请求的标准方法。如果不构建关联机制，您甚至无法可靠地将请求与响应进行匹配。我经历过这两种情况。一个需要 30 分钟，另一个需要 3 天。

成本归因危机

当 OpenAI 为上个月的 API 使用收取 50,000 美元的费用时，您能说出哪个部门的 MCP 工具推动了这一成本吗？调用哪些特定工具？哪些个人用户或用例？

MCP 没有为这一基本作要求提供机制。协议级别没有代币计数。无成本归因标头。没有配额管理。你对人工智能的支出视而不见，无法优化，甚至无法了解钱的去向。

相比之下，云提供商在几十年前就吸取了这一教训。每个 AWS API 调用都可以进行标记、归因和成本跟踪。每个 Google Cloud作都会流入详细的结算明细。MCP 要求企业消耗具有 1990 年代成本可见性的昂贵 AI 资源。

仍然存在的关键运营差距

在尝试构建可复原的多区域部署之前，服务发现听起来似乎是可有可无的。MCP 的手动配置假定您在部署时熟悉所有工具。这会在您需要动态缩放或故障转移的时刻中断。您无法构建适应基础设施变化的系统。

当您有数十种工具相互独立发展时，版本管理变得至关重要。MCP 具有协议版本协商，但没有模式版本控制。工具界面可能会在没有警告的情况下更改。任何工具更新都有破坏所有客户端的风险。您面临一个选择：永远不要更新工具，或者协调整个生态系统中的大规模部署工作。

性能对于演示来说可能无关紧要，但 JSON 的开销和缺乏连接池无法扩展。当您需要低延迟、高吞吐量的 AI 系统进行实时应用时，MCP 的基于文本的协议就会成为瓶颈。没有二进制协议选项，没有超出传输级 gzip 的压缩。尤其是 stdio 传输，它为每次交互创建了一种新的过程连接，这是我们在 1990 年代放弃的模式，这是有充分理由的。

为什么这些遗漏现在很重要

企业人工智能的采用曲线正在变陡。公司不再进行实验。他们正在将人工智能部署到收入关键型和安全关键型系统中。金融服务使用人工智能进行交易决策、欺诈检测和风险评估。医疗保健系统提供诊断支持和个性化治疗建议。工业系统依靠人工智能进行质量控制和预测性维护。客户服务通过人工智能交互处理敏感数据。

这些领域中的每一个都花了几十年的时间来构建强大的集成模式。MCP 要求他们放弃这些模式，转而使用仍在改造基本安全功能的协议。适用于演示的“快速行动并打破事物”的方法在应用于故障产生实际后果的系统时将变得灾难性。

前进的道路：从历史中学习

MCP 不需要成为 CORBA，但它必须包含经过验证的模式。最近添加的内容表明，维护者正在倾听，但他们正在追赶他们的长辈几十年前解决的问题。

仍未解决的直接需求包括改进的类型安全性、将相关 ID 集成到协议中的分布式跟踪、超越简单工具注释的基于功能的授权、用于合规性的标准化审计跟踪格式以及独立于协议版本的模式版本控制。

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

长期成熟度需要企业级功能：用于复杂交互的真正双向流、内置速率限制和配额管理、SLA 实施机制、令牌使用的全面成本归因以及工作流编排原语。

底线

MCP 当前的设计反映了一种赌注，即简单性胜过人工智能工具集成的稳健性。这个赌注对于实验来说是有意义的，但对于生产部署来说却是灾难性的失败。该协议的快速采用是由人工智能炒作而不是运营准备推动的，这正在使企业面临痛苦的失败。

改造关键特征的模式证明 MCP 过早发布。企业采用它基于承诺和炒作，而不是运营现实。现在他们发现，在事后增加安全性、可观察性和适当的错误处理类似于在汽车撞车后添加安全气囊。

我们在分布式系统方面拥有 40 年的经验，展示了哪些模式可以实现可靠、安全和可扩展的作。这些不是学术练习。它们是解决当系统出现故障时真正公司损失真金白银的问题的解决方案。

窗口正在关闭。随着企业达到 MCP 的局限性，他们将构建专有解决方案。软件供应商也是如此。MCP 旨在防止的碎片化仍然会出现，尽管需要采取额外的步骤和浪费的努力。

人工智能行业有一个选择：从四十年的 RPC 演变中吸取教训，或者重复每一个痛苦的错误。根据当前的发展轨迹，关键功能被作为事后的想法，我们选择重复，企业将在部署失败、安全漏洞和完全可以预防的运营噩梦中付出代价。