API 之后

API 连接了软件。而智能体引入了一种必须自行决定要连接哪个软件的软件。

传统的集成始于知识:开发者选择一个端点,研究它的模式(schema),并围绕它编写确定性代码。调用方了解服务,通常也了解操作。智能体软件改变了这一假设。它可能需要发现能力、理解它们的描述、在它们之间做出选择,并跨越边界携带上下文。

从调用到发现

REST、RPC 和事件流依然必不可少。MCP 并不会让它们过时。它解决的是另一个层面:通过共享接口,向模型驱动的客户端呈现工具、资源和提示词。底层操作仍然可能是一次 API 调用、一次数据库查询或一个本地进程。

这个区别很重要。发现不仅仅是一个更好用的 SDK。一台选择能力的机器需要支持正确推理的名称和描述、约束输入的模式,以及明确的安全边界。含糊的工具描述是一种架构缺陷,因为它会改变选择行为。

MCP 规范定义了客户端-主机-服务器架构和能力协商。它还告诫实现者要维护同意、数据隐私和工具安全。这些都是关于新层的线索:上下文交换无法与权限分离。

我关注的不是 MCP 是否会成为最终协议,而是智能体与系统的交互已经重要到需要一个协议层的程度。协议可能会变,但需求会一直存在。

围绕工具的控制平面

一个有用的智能体工具生态需要的不仅仅是目录,还需要生命周期和治理。谁注册了某个工具?哪个版本处于激活状态?哪个租户可以看到它?发现意味着许可,还是仅仅意味着知晓?结果如何被标记为不可信?当服务器在工作流中途消失时会发生什么?

这些都是分布式系统的问题。服务会独立故障。模式会演进。重试可能重复副作用。智能体可能持有过期的上下文。一个对模型来说看似原子的工具调用,底层可能跨越多个非原子操作。

想象一个运维智能体在读取遥测、创建事件和变更容量的工具之间做选择。发现机制应该暴露所有三种能力,但授权不应该是均一的。读取可以很宽泛。创建事件应该是幂等的。容量变更应要求更强的策略,并包含一个有界的范围。共享协议有助于描述接口;平台仍必须强制边界。

厂商边界让这一点更加重要。组织将使用多个模型供应商以及数百个内部和外部服务。定制适配器会在两个方向上产生耦合。协议层可以让工具演进,而无需每个客户端都学习它的私有集成方式;也可以让客户端变更,而无需重写每个服务。

去神话化的标准化

重要的生态系统往往在接口变得可预测时加速发展。但类比所掩盖的可能多于它所解释的。MCP 并不只是“新的 HTTP”。HTTP 在网络化组件之间传输表示(representation)。MCP 为面向模型的上下文和能力定义约定,通常在其下使用现有的传输方式。

有用的架构论断更窄。标准接口减少了组件协作所需的双边协议数量。它们为工具链创造了空间:注册中心、网关、策略引擎、测试框架和可观测性。它们还让故障变得可比较。

标准化不会自动带来互操作性。两个服务器可以实现相同的协议,却使用不兼容的语义。一个名为 `search` 的工具可能搜索客户的文档、公开网络或运维数据库。语义质量、来源和信任仍然是系统层面的问题。

这指向一种分层设计。用协议来处理发现与交换。用身份和策略来处理授权。用领域契约来处理语义。用追踪和审计记录来实现问责。用普通的 API 和队列来实现可靠执行。任何单一的一层都不应假装能解决其他层的问题。

因此,对构建者而言,MCP 的直接价值并不是普适性的承诺,而是一种推动模型客户端与工具实现解耦的实际压力。这让实验成本更低,让替换更具可逆性。

协议之所以重要,是因为它们让系统能够独立演进。

参考资料

• Model Context Protocol 规范
• MCP 安全最佳实践