AI Agent

MCP 不只是开发工具：生产级 Agent 集成的三条路

Anthropic 系统梳理了 Agent 连接外部系统的三条路：直接调 API、CLI 和 MCP 协议。本文详解生产级 MCP 服务器的设计模式、认证标准化、Tool Search 上下文优化，以及 Skills 与 MCP 的互补定位。

撰文Pengfei Ni

发布2026 年 04 月 23 日

阅读时间8 分钟

题记：本文编译自 Anthropic 博客《Building agents that reach production systems with MCP》。文章从 Agent 连接外部系统的三条路讲起，重点梳理了 MCP 服务器的设计模式、认证标准化、上下文优化，以及 Skills 的互补定位。不算长，但信息密度不低，尤其是 Cloudflare 的代码编排模式和 Vault 的凭证管理思路，值得做 MCP 服务器的人细看和参考。

我之前给 Claude Code 配 MCP 服务器的时候，最头疼的是上下文占用的问题，后来《Claude Code 终于解决了 MCP 最大的痛点》那篇写过 Tool Search 怎么解决这个事。但用得越多越发现，上下文只是冰山一角。

本地开发时，Agent 调个 API、跑个命令行工具，一切都很丝滑。但等你想把它放到云上跑，问题就来了：CLI 工具没有 shell 可用，API 调用的认证凭证要自己管，每对接一个新服务就要从头写一套集成代码。

刚刚看到 Anthropic 发了一篇博客，系统梳理了 Agent 连接外部系统的三条路，以及为什么生产环境下 MCP 可能是最务实的选择，分享一下，供大家参考。

把 Agent 接入外部系统

Anthropic 把 Agent 接入外部系统的方式分成三种：直接调 API、用 CLI，以及走 MCP 协议。

直接调 API 是最多人的起点，也是最简单的。Agent 在沙箱里发 HTTP 请求，或者通过 function calling 调用外部服务。一个 Agent 对一个服务没什么问题。但接的服务一多，每个 Agent 和服务的配对都要单独处理认证、工具描述和异常情况。做过微服务的人应该很熟悉，这就是经典的 M×N 集成问题。

CLI 也能用，快、轻量，复用现有工具链。但在移动端、Web 端和云托管平台这些没有 shell 的地方往往会到处碰壁，认证也只能靠磁盘上的凭证文件。说白了，CLI 是本地开发的好帮手，离生产还差一截。

MCP 走的是协议层。Agent 连上一个 MCP 服务器，服务器把你系统的能力暴露出来，认证、发现、语义描述都标准化了。一个远程服务器可以同时服务 Claude、ChatGPT、Cursor、VS Code 这些客户端，部署在哪都行。MCP 的前期投入确实比前两种大一些，但换来的是可移植性，以及协议本身能描述的东西也更多。

我自己的感受是，本地开发阶段 CLI 和 MCP 都够用，但一旦 Agent 要上云、要服务多个客户端，MCP 基本是唯一的选择。那为什么 Anthropic 现在特别强调生产环境？

生产 Agent 跑在云上

因为生产级 Agent 越来越多地跑在云上，它们需要连接的系统也在云上：数据存在那里，工单跟踪在那里，基础设施也在那里。这些系统通常是远程的、带认证的，正好是 MCP 擅长处理的场景。

从 Anthropic 自己的产品线也能看出这个趋势。前段时间发布的 Managed Agents，底层就是靠 MCP 连接外部工具和数据源，之前那篇《Managed Agents 架构拆解》分析过它的脑手分离设计。Claude Cowork、Claude Code Channels 也是类似的思路，MCP 在里面扮演的就是连接层的角色。MCP SDK 的月下载量从年初的 1 亿涨到了 3 亿，增速确实有点猛。

不过 Anthropic 也没说 MCP 就应该替代其他方式。API 是基础，CLI 服务本地开发，MCP 覆盖云端。三条路最终都会并存。

那问题就变成了：决定用 MCP 之后，服务器怎么设计才好用？

MCP 服务器怎么设计才好用

Anthropic 目前 MCP 目录里有 200 多个服务器。从这些实践中他们提炼了几个设计模式，结合我自己写 MCP 服务器的经验，聊聊几个我觉得最有价值的。

远程服务器优先

只有远程服务器才能同时覆盖 Web、移动端和云端 Agent，这是分发的前提。本地服务器在开发阶段够用，但想让 Agent 在任何环境下都能调用你的服务，必须上远程。

按意图分组工具，不要一比一镜像 API

这个我之前在《Claude Code 终于解决了 MCP 最大的痛点》提过，工具越少、描述越好，Agent 用起来越准。一个 create_issue_from_thread 工具，比让 Agent 自己拼 get_thread + parse_messages + create_issue + link_attachment 靠谱得多。

做过 Agent 开发的你应该都体会过，把底层 API 原封不动暴露给模型，基本就是在赌它能自己编排出正确的调用序列。赌赢的概率不高。我之前做 Kubernetes MCP 服务器的时候，最开始也是把 Kubernetes API 一比一映射成工具，结果模型光是选对工具就要好几轮，后来按运维场景重新分组，调用准确率提升了很多。

大量 API 场景用代码编排

如果你的服务有几百个接口，按意图分组也覆盖不完。这时候 Cloudflare 的做法挺妙的：只暴露两个工具（搜索和执行），覆盖了大约 2500 个 API 端点，整个工具定义只占 1K token。思路是让 Agent 写一小段脚本，服务器在沙箱里跑，只返回结果。

用 MCP Apps 做交互

MCP Apps 是 MCP 协议的第一个官方扩展，允许工具返回交互式界面，图表、表单、仪表盘，直接嵌在对话里渲染。你让 Agent 查一下数据库的慢查询，返回的不是一堆文本，而是一个可排序的交互式表格。这体验一下子就提升上去了，Anthropic 说支持 MCP Apps 的服务器在用户留存上表现好很多，这个不难理解。

还有一个叫 Elicitation 的能力也值得关注。它让 MCP 服务器在工具调用中途暂停，向用户请求输入。比如你让 Agent 删一个资源，服务器可以弹一个确认表单，而不是直接执行。更敏感的操作比如 OAuth 登录，可以把用户引到浏览器里完成，凭证不经过 MCP 客户端。这个设计思路和之前聊过的 Managed Agents 的安全隔离一脉相承，敏感信息能不过手就不过手。

认证这块终于不用自己造轮子了

说实话，认证一直是 MCP 从开发到生产最让人头疼的部分。本地开发时 MCP 服务器大多不需要认证，或者直接用 API Key 凑合。但到了生产环境，用户授权、token 存储、过期刷新、多租户隔离，每个环节都是坑。之前每个 MCP 服务器都得自己处理 OAuth 流程，各种边角情况踩不完。

最新的 MCP 规范在这块改进了不少。CIMD（Client ID Metadata Documents）简化了客户端注册的 OAuth 流程，用户首次授权更快，反复弹授权框的情况也少了。MCP SDK、Claude.ai 和 Claude Code 都已经支持这个规范。

对云端 Agent 来说，令牌的存储和刷新是另一个痛点。Managed Agents 的 Vault 机制处理了这个问题：注册一次用户的 OAuth 令牌，创建 session 时引用 Vault ID，平台自动把凭证注入每个 MCP 连接，过期了自己刷新。不用自己搭密钥管理服务，不用每次调用传 token。这个思路和 Kubernetes 里 ServiceAccount 自动挂载 token 的逻辑挺像的，让凭证管理变成基础设施的一部分，应用层不用操心。

上下文效率：Tool Search 和程序化调用

MCP 服务器越多，上下文占用越大，这个问题前面提到过。Anthropic 现在有两个客户端侧的优化模式。

Tool Search 是按需加载工具定义，不一次性全塞进上下文。Agent 运行时搜索工具目录，只拉取当前任务需要的工具。根据 Anthropic 的测试，工具定义相关的 token 占用能降低 85% 以上，选择准确率基本不受影响。

Tool Search 上下文优化效果

程序化工具调用是在代码执行沙箱里处理工具返回结果，而不是原样扔回给模型。Agent 可以在代码里循环、过滤、聚合多次调用的结果，只把最终输出放进上下文。复杂的多步工作流能省掉大约 37% 的 token。

两个模式叠加使用的效果更好：上下文更精简，往返次数更少，响应也更快。

Skills 和 MCP 是互补的

这个话题之前也聊过。简单说，MCP 给 Agent 能力（能调什么工具、能访问什么数据），Skills 给 Agent 知识（怎么用这些工具完成具体任务），两者最好结合着一起使用。

Skills 和 MCP 的协作方式

具体有两种组合模式。

第一种是把 Skills 和 MCP 服务器打包成 Plugin。Claude 的 Plugin 可以捆绑 Skills、MCP 服务器、Hooks、子 Agent 这些组件，一键分发。比如 Cowork 的数据 Plugin，里面有 10 个 Skills 和 8 个 MCP 服务器，覆盖 Snowflake、Databricks、BigQuery 这些数据工具。这种模式让 Claude 从通用助手变成领域专家。

第二种是让 MCP 服务器自带 Skill。Canva、Notion、Sentry 这些厂商已经在做了，在 Claude 的目录里把 Skill 和 Connector 放在一起。MCP 社区也在做一个扩展，让服务器直接分发 Skills，客户端自动继承，版本跟着 API 走。

我的体会是：MCP 服务器只提供工具的话，Agent 每次都得自己摸索调用顺序和参数搭配，效率不高。Skill 把最佳实践编码进去，等于给 Agent 附了一份操作手册，开箱就能按套路来。

写在最后

回头看生产环境 Agent 集成外部系统这件事，由于 Agent 跑在云上，需要连接的服务也在云上，中间就需要一个标准化的协议层。

相比直接 API 调用和命令行 CLI，MCP 目前是这个位置上最合适的协议，特别是远程 MCP 服务器。MCP 的优势在于它是开放协议，不绑定任何一家模型厂商，一个服务器建好了，Claude、ChatGPT 之类的任意 AI Agent 都能用。