MCP 当道，你的 API 依然重要

大家都在谈论‘数字同事’的潜力，Model Context Protocol（MCP）成了智能体（Agent）领域的热词。但如果你过去十年一直在为组织构建 API，是不是就得全盘抛弃，转向 MCP 优先策略？别急着‘把孩子和洗澡水一起倒掉’，我们先看看 API 和 MCP 集成的几种可行路径。

API：可靠的老桥梁

API 常被比作让两个系统通信的桥梁，但我更愿意把它看作餐厅菜单上的菜品。每道菜的内容都标得清清楚楚，你点牛肉就不会收到意面。API 也一样，由人类预先定义，附有使用前可查阅的文档。

API 不允许猜测。比如，你想在应用里获取客户数据，就调用 API 的客户端点。选择客户端点，你得到的就是客户数据，而不是天气预报。

“An API is often described as a bridge that lets two systems talk to each other, but I find it more helpful to think of APIs as selections on a restaurant menu.”

API 的好处在于具体且结构严谨，代码必须遵循既定模式。设计良好的 REST API 就有清晰的动词（系统能做什么）和名词（系统中的组件）模式。动词如‘获取’、‘创建’、‘删除’，名词如‘文件’、‘用户’、‘发票’。这种分离让机器能基于 API 语义进行规范、可控的交互。

在 AI 智能体出现前，构建调用 API 的客户端应用需要编写与每个特定 API 直接对齐的自定义代码。应用只能与被告知使用的端点交互。而 AI 智能体拿到一个端点后，会反复调用它，试图理解其工作原理，直到获得成功响应。

它们能学会使用 API，但有时后果很严重。智能体已被证明会过度调用端点、检索敏感数据，或重试 API 直到意外破坏某些东西。更糟的是，有些智能体还泄露了 API 密钥，比如 OpenClaw API 密钥泄露事件。

即便进入这个新的智能体范式，API 在交付成功智能体方面仍有作用。例如，如果你有能提升智能体准确性的私有数据，但数据高度敏感且需要复杂的授权结构，API 可以确保对其的受控访问。不过，你需要仔细考虑面向智能体的 API 策略，因为这里有成本……字面意义上的成本。

比如，如果你有一个包含许多字段的复杂 API，就需要为智能体详细记录使用方法。智能体还可能开始探索 API 中的其他端点。

提供 API 使用方式及具体参数的信息，是智能体在整个会话中需要携带的额外信息，这意味着你在 API 信息上消耗的 Token 会叠加，并占用更多上下文窗口（Context Window）空间。

与其依赖可能消耗大量 Token 的详细 API，不如考虑使用 Model Context Protocol（MCP）。MCP 为智能体提供了一种更轻量、基于规范的集成替代方案，有助于在整个会话中节省 Token。

MCP：面向智能体交互的协议

Model Context Protocol（MCP）是为 AI 智能体（而非人类）直接与工具、数据源和应用交互的世界设计的。由于 MCP 是通用的 AI 集成标准，智能体无需理解自定义客户端代码（如 REST 端点）就能与 MCP 服务器通信。

所有集成都使用同一协议，因此比 API 更统一。此外，每个 MCP 服务器的能力——工具、资源、提示——都是自描述的，它们会宣告自己能做什么。你不需要额外工具来解决 API 中的文档问题。

MCP 让智能体能够动态发现和使用工具，无需文档，类似于 USB 是连接新外设硬件的通用方式（通常无需下载新软件）。智能体可以基于标准采取行动，不需要额外的工具或解决方案。通过 MCP，服务器‘广告’它们的功能。

作为‘同事’的智能体可以‘看到’可用能力，并根据 MCP 服务器提供的描述自主做出决定。AI 智能体会判断这些工具是否为其独立制定的问题解决计划所需。

所以本质上，MCP 使智能体能够理解并找到特定‘工具’来完成其任务。与 API 不同，通过 MCP 访问的工具不依赖单独、详尽的文档。API 告诉机器具体做什么，而 MCP 告诉 AI 智能体存在哪些工具，以便智能体按需使用。

如果 API 是餐厅的实体菜单，那么 MCP 就像外卖应用。餐厅只能给你该特定地点的菜单（API）。然而，MCP 提供了通用的‘应用’，让食客（智能体）通过单一界面浏览、订购并与该区域任何厨房对话。

食客不再需要为每家餐厅单独下载应用，MCP 客户端充当了统一的店面。它代理对 MCP 服务器（各个厨房）的访问，允许 AI 动态发现新‘菜品’（工具和数据），无需手动设置。通过标准化这种握手，MCP 将 AI 从有限的单一菜单选项转变为具有全市可访问性的智能体。

“If an API is a restaurant’s physical menu, then MCP is like a food-delivery application, providing the universal ‘app’ that allows the diner (agent) to browse, order from, and talk to any kitchen.”

考虑到使用这些 MCP 服务器访问工具的 LLM 的非确定性（Non-Deterministic）本质，IT 组织必须通过实施 MCP 网关（MCP Gateway）来考虑 MCP 服务器的控制和治理（Governance）。

定义你的智能体集成策略

考虑到潜在风险和治理难题，为什么还要考虑 MCP 集成？很简单……因为智能体需要动态性。API 是静态的，这对智能体同事来说可能过于僵化。话虽如此，在组织出于安全或监管原因需要更受控、确定性（Deterministic）方法的具体情况下，API 对智能体仍然相关。

你可能会问，‘为什么不直接用 MCP 包装我的 API？’ Tanzu 团队已经看到多个成功案例，使用 Spring AI 通过 MCP 工具命令包装 API，从而减少了智能体在交互中必须理解和查找的复杂规范数量。

表面上看，这很有吸引力，因为你不会失去几十年在 API 上的投资，还能节省 Token。但包装并非智能体友好 API 的万能药。这取决于对每个 API 的个体分析。需要跨多个数据源进行动态分析以提供推荐的情况，是 MCP 包装的良好候选（例如零售推荐引擎或实时投资分析）。

这类分层集成可能使用 API 处理客户数据，然后添加单独的 MCP 集成处理实时数据。但每个用例仍需要仔细评估。

无论你的分析结果如何，有一件事是确定的。MCP 服务器和 API 注定会随着时间在 AI 用例中激增。对 IT 性能、成本、合规性和安全性负责的组织将需要对其激增的集成进行可观测性（Observability）、安全护栏（Guardrails）和可审计性（Auditability）。

这就是应用平台（如 VMware Tanzu Platform）可以发挥作用的地方，它能帮助你扩展 API 和 MCP 服务器生态系统，在开发者/智能体市场中发布 MCP 服务器和 API，并提供可见性和生命周期管理能力，从而为 AI 持续升级和优化你的 API 和 MCP 集成。

在这场即将举行的网络研讨会中，我们的同事 Adib Saikali 将讨论企业如何制定其 API 和 MCP 集成策略。加入我们，太平洋时间 3 月 25 日上午 9 点！