MCP（模型上下文协议）缺失的一半：为什么二阶服务器尚未存在

来源: Agentic AI Foundation (AAIF)
作者: Agentic AI Foundation
发布时间: 2026年6月18日 03:19:19
原文链接: https://aaif.io/blog/mcps-missing-half-why-second-order-servers-dont-exist-yet/

---

Jerome Swannack’s talk at MCP Dev Summit North America 2026.

TLDR：MCP 服务器可以调用工具（tools），但客户端（clients）无法将工具暴露回服务器。MCP 的原始架构师之一 Jerome Swannack 解释了客户端到服务器的工具共享如何解锁更模块化、可插拔的 MCP 系统。

*

在 Jerome Swannack 构建 MCP 时，他意识到一个关键协议缺口，并将其称为“二阶”（second-order）MCP 服务器。典型的（或一阶）MCP 服务器将 AI 客户端连接到记录系统（system of record）以执行某些操作，比如读取内容、发布内容或执行动作。二阶服务器则不同：它不是将客户端连接到外部系统，而是将客户端连接到其其他 MCP 服务器，直接在 MCP 层上运行。

在实践中，二阶服务器通常出现在一些常见问题场景中。一个研究型 agent 需要访问你的 Slack、邮件、日历和文档 MCP 服务器。一个工具搜索层（tool-search layer）需要决定向模型展示哪些工具，而又不淹没上下文窗口。一个代码模式服务器（code-mode server）需要一个能够以编程方式调用工具的运行时。一个附件处理器需要在服务器之间移动文件，而不必将文档通过 base64 编码塞入提示词（prompt）中。

这些功能的一部分已经存在于各种客户端、框架和自定义 agent 堆栈中。或者，用户可能要求基于浏览器的 AI 工具跨标签页操作，从不同的实时 Web 应用中收集数据。然而，缺失的部分是 MCP 原生版本——一种标准方式，将这些能力打包为可复用的服务器，并能与生态系统中的其他部分组合。

为什么如今构建二阶服务器如此困难

以 agent 服务器用例为例。你有一个 MCP 客户端、一组 MCP 服务器，以及一个你想启动并用于跨它们进行研究的 agent 服务器。该 agent 需要访问那些其他服务器。实现这种连接的唯一方式是将认证令牌（authentication tokens）分散到多个服务中，为每个服务执行单独的 OAuth 流程，或者将 API 密钥直接嵌入 agent 服务器。信任最终分散在系统中，而非集中化，同时用户的体验是一连串的认证提示，使整个过程显得脆弱且繁琐。自动模式（Automatic mode）解决了部分问题，但将粘合逻辑转移到 UX 层并非可扩展的解决方案。

代码模式场景也面临类似挑战。为了让模型拥有一个能通过编程方式调用其他 MCP 工具的运行时，你最终会复制同样的认证蔓延问题。本应属于客户端的复杂性被分散到了各个服务器上。

附件场景也有其痛点。目前形成的非正式标准是将文件作为工具调用中的 base64 编码参数传递。这在技术上是可行的，但它会膨胀上下文窗口，并产生脆弱且难以驾驭的集成。

这三种情况的共同核心摩擦点是相同的：如今的 MCP 是非对称的。服务器可以被调用，但客户端不可以。

对称 MCP 将改变什么

在他的演讲中，Jerome 提议赋予 MCP 客户端从服务器暴露工具列表并接受工具调用的能力，就像当前服务器为客户端所做的那样。一旦实现，客户端将成为一个交换中心。agent 服务器不再需要为每个下游 MCP 服务器获取令牌。它发出工具调用，客户端将其路由到正确的服务器，客户端处理认证，然后返回结果。信任链保持集中。OAuth 问题消失了，因为客户端已经持有凭据。

代码模式服务器也变得更简单。它暴露一个 run_code 工具，客户端将运行时内的任何工具调用路由到相应的服务器，从而无需在每个客户端中分别嵌入 JavaScript 或 Linux 虚拟机，即可实现可插拔的编程式工具调用。

对于附件，客户端可以将文件作为服务器可直接访问的资源（resources）列出，完全消除 base64 的变通方法。

为了演示他的构想，Jerome 构建了一个基于 Docker 的虚拟机，通过对称传输（symmetric transport）调用 MCP 服务器，并带有权限界面，可以指定每个二阶服务器允许访问哪些服务器。agent 服务器可以访问代码模式，而代码模式可以访问其他所有内容。本质上，这是一个由可组合的 MCP 服务器构建而成的、支持代码模式的多 agent 系统，由客户端负责路由。

为什么双向 MCP 道路尚未存在

简短的回答是：MCP 是为了解决更紧迫的问题而构建的：将 AI 客户端连接到外部系统。二阶服务器并非首要任务。

Jerome 确实构建了一个早期原型，但当时协议不容易朝这个方向扩展。这也是为什么较新的 MCP 扩展工作如此重要——它为开发者提供了更多空间来测试此类模式，而无需将每个想法都强行塞入核心规范。

更棘手的问题是，对称 MCP（模型上下文协议）改变了客户端的角色。如今，客户端主要调用服务器。在杰罗姆（Jerome）的模型中，客户端还成为了路由器和权限层。它决定哪些服务器可以调用哪些其他服务器，请求应该发往何处，以及允许使用哪些凭据。

这增加了复杂性。但杰罗姆指出，这种复杂性早已存在。没有对称性，它只是被推向了错误的地方。服务器最终持有它们本不该持有的令牌。每个代理或运行时都要重新构建自己的路由逻辑。文件处理变得临时拼凑。权限变得更难审计。

对称模型并不能消除所有风险。配置不当的客户端仍然可能暴露过多信息。但它将信任边界集中在一个地方，而不是分散在十几个服务中。这使得系统更易于推理，也更易于保护。

当二阶 MCP 标准化后可能实现什么

一旦客户端成为路由层，MCP 生态系统就可以提供安德烈·卡帕西（Andrej Karpathy）所描述的 LLM 操作系统（LLM OS）的部分功能，而无需每个客户端从头构建一切。工具搜索成为可插拔的服务器。重试逻辑和速率限制成为可插拔的服务器。代理通信则自然地从那些同时也是客户端的 MCP 服务器中涌现出来。这提供了可组合性——就像 Unix 管道给 shell 用户带来的那样：具有明确定义接口的小工具组合起来，实现了作者并未特意规划的功能。请关注即将发布的 MCP 版本，因为这一缺口很可能在不久的将来得到填补，MCP 草案规范（RC 2026-07-28）已经在这方面做出了重要的架构调整。

*

杰罗姆是 Anthropic 的软件工程师。Agentic AI 基金会是开放代理标准和开源基础设施的家园。要了解更多关于 MCP 的信息，并与思考这些问题的工程师建立联系，请访问 aaif.io，加入 AAIF Discord 的讨论，或参加即将举行的 AAIF 活动。