当AI Agent从原型迈向生产环境时，MCP协议正成为解决规模化集成的关键基础设施。Anthropic最新工程实践揭示：直接API调用和CLI路径在服务增长时面临指数级复杂度，而MCP通过标准化协议层将集成成本降为线性。本文深度解析Cloudflare等案例如何用2个工具覆盖2500个端点，以及工具懒加载如何减少85% token消耗。
做过 AI agent 的人都踩过同一个坑。
你花了两周把一个 agent 搭起来，接上了几个 API，本地跑得挺好。演示效果很不错，领导很满意。然后你开始准备上生产——发现每一个新服务要连接，就要从头写一套认证逻辑、一套工具描述、一套错误处理。连第三个服务的时候，你意识到这套东西开始变得很难维护了。连第五个的时候，你已经不确定改一个地方会不会影响到其他地方了。
这不是你的问题，这是一个架构问题。具体来说，是一个没有公共抽象层的系统，在服务数量增长之后必然出现的问题。
更让人沮丧的是，这不是「再认真一点就能解决」的问题。你的代码质量可以很高、文档可以写得很全、测试覆盖率可以很好——但只要架构里缺少那一层公共抽象，随着服务数量线性增长，复杂度就会指数级膨胀。没有银弹，只有改架构。
Anthropic 在 4 月 22 日发布了一篇博客文章，题目是「构建能触达生产系统的 Agent」，系统地讲清楚了 agent 连接外部系统的三条路，以及为什么跑在生产环境的 agent 最终都会走向 MCP。文章来自 Claude Platform 团队，不是概念性的展望，是他们在实际支撑 Claude 相关产品时总结的工程实践。
这篇文章发布时机很微妙。就在同一周，MCP SDK 的月下载量刚刚突破 3 亿次——而 2026 年年初的时候，这个数字还是 1 亿。三个月，翻了三倍。每天有数百万人通过 MCP 使用 Claude，它现在支撑着 Claude Cowork、Claude Managed Agents、Claude Code 里的 channels 等核心产品。
不是小众技术了。是基础设施。
Anthropic 官方博客：Building agents that reach production systems with MCP（2026年4月22日）
第一条路是直接 API 调用。agent 直接发 HTTP 请求，或者通过 function calling 工具调用你的 API。
大多数团队从这里开始，完全合理。它简单、直接，对于一个 agent 只需要对接一个服务的场景，完全够用。原型阶段，这条路是对的。
问题在于规模化之后。
当你有 M 个 agent、N 个服务，每一对 agent-服务组合都变成了一套独立的集成——独立的认证处理、独立的工具描述、独立的错误处理、独立的边界情况。这就是 Anthropic 文章里提到的「M×N 集成问题」。
不只是工作量的问题，更是一致性的问题。每个 agent 对同一个服务的理解，可能是不同的、相互矛盾的。同样是调用公司的内部 CRM，销售 agent 的工具描述可能和客服 agent 的完全不同，各自维护，各自演化，最终变成一个没人能整体理解的系统。
听起来有点抽象，但你如果在一家稍微大一点的公司做过 AI 基础设施，你会立刻认出这个场景：每个团队的 agent 都在以各自的方式接入同样的 CRM、同样的数据库、同样的 Slack，没有任何共用的抽象层，维护成本随服务数量指数级增加，技术债务在悄悄累积。
这也是为什么「原型很好跑，生产跑不动」的根本原因之一——不是模型不够好，是集成架构的债务在生产规模下撑不住。
M×N 问题 vs MCP 架构：引入公共协议层，将集成复杂度从指数级降为线性
第二条路是 CLI。agent 在 shell 里运行你的命令行工具。
这条路的优点很明显：快、轻量，可以复用已有的工具链，而且不需要额外的服务器。在本地环境、沙箱容器里工作得很好——只要有文件系统和 shell 就行。很多开发者工具走这条路，Claude Code 里的大量功能也是通过 CLI 实现的。
但 CLI 有一个硬限制，而且这个限制随着 AI 部署模式的变化变得越来越关键：它无法触达没有暴露容器的平台。移动端没有 shell，Web 服务不能给 agent 一个本地环境，云托管的服务也没有文件系统让你存 credential 文件。
认证通常靠磁盘上的 credential 文件，这在受控的开发环境里没问题，但在生产的云端 agent 里，这是一个安全边界问题——你不能把用户的 API token 以文件形式存在 agent 的容器里。
更根本的问题是：生产环境的 agent 越来越多地跑在云上，而 CLI 是一个本地优先的工具。如果你的 agent 是一个常驻云端的服务，而不是用户桌面上的进程，CLI 集成就无从谈起。这两件事之间有一条结构性的裂缝，不是优化能弥补的，是架构层面的不匹配。
我觉得 CLI 路线的失败很有启发性：它失败的不是技术能力，而是部署模型不兼容。这种「在正确的环境里完全正确，换个环境就完全失效」的脆弱性，在 agent 工程里出现的频率远比我们通常意识到的要高。
第三条路是 MCP（Model Context Protocol）。
MCP 做的事情，是把那个「公共层」变成一个协议。agent 连接到一个 MCP server，这个 server 以标准化的方式暴露你的系统能力——认证、工具发现、语义描述，全部标准化。
这一层标准化意味着什么？意味着一个远程 MCP server，可以被任何兼容的客户端使用：Claude、ChatGPT、Cursor、VS Code，以及其他各种 AI 工具，在任何部署环境里——不管是本地还是云端——都可以接入。你的系统只需要维护一个 MCP server，就可以被所有这些客户端和 agent 使用，而不需要为每一个写一套独立的集成。
M×N 问题在 MCP 的架构里变成了 M+N 问题：你有 N 个服务，每个服务维护一个 MCP server；你有 M 个 agent，每个 agent 支持 MCP 协议。它们天然可以互相使用，不需要额外的胶水代码。
Anthropic 在文章里说了一句很关键的话：「生产 agent 越来越多地跑在云上，以便扩展和持续运行。它们需要触达的系统也是云托管的——数据存在的地方、工作被追踪的地方、基础设施运行的地方。这些系统通常是远程的、需要认证的，MCP 提供了那个公共层。」
这就是 MCP 月下载量从年初 1 亿涨到现在 3 亿的结构性原因：它解决的问题，是随着 agent 部署模式成熟化而必然浮现的问题。它不只是一个工具，是一个让 agent 生态可以规模化的基础协议。
它现在支撑着 Claude Cowork、Claude Managed Agents、Claude Code 里的 channels。不是实验性功能，是已经在跑的核心基础设施。
我个人认为，MCP 之所以能在这么短的时间内变成事实上的标准，除了技术本身的合理性之外，还有一个重要原因：它降低了「构建可被他人复用的集成」的门槛。
以前，你做的 agent 集成只有自己能用；有了 MCP，你的集成天然兼容所有支持协议的客户端。
这种「一次投入，多方受益」的特性，对开源社区和商业公司都是强激励，反过来又加速了生态的扩张。这种正向飞轮，不是人为设计出来的，是协议标准化之后自然发生的。
Anthropic 的 MCP 目录里现在有超过 200 个 server，每天被数百万人使用。他们从这些实践里总结出了五个决定性的设计模式，这些模式决定了一个 server 能不能被 agent 可靠地使用。
① 构建远程 server，不要停留在本地。只有远程 server 才能真正分发出去：它是唯一能在 Web、移动端、云托管 agent 里都跑起来的配置，也是各大客户端优先优化的目标。如果你只做了本地 server，你的集成范围就被硬性限制在了有 shell 的环境里。想要让你的系统被尽可能多的 agent 使用，远程 server 是前提。本地 server 用于开发调试完全可以，但不要在这一步停下来。
② 工具按意图分组，不要按 API 端点映射。这是文章里我觉得最实用的一条建议，也是最容易被忽视的。很多开发者做 MCP server 的第一直觉，是把 REST API 的每个端点包装成一个工具。这样做出来的 server 工具数量多、颗粒度细，agent 需要自己想清楚要先调哪个再调哪个，然后把结果拼起来。调用链长了，出错概率上升，token 消耗增加，用户体验变差。
正确的方式是按「用户想完成什么」来组织工具，而不是按「API 提供了什么」来组织。一个 create_issue_from_thread 工具，比 get_thread + parse_messages + create_issue + link_attachment 四个独立工具，在实际使用里要好得多。agent 一次调用完成任务，不需要在多个工具之间协调，错误点更少，成功率更高。
③ 如果 API 面很大，暴露代码执行接口。但是对于 Cloudflare、AWS、Kubernetes 这类有几百甚至几千个操作的大型平台，按意图分组反而行不通——因为意图太多了，你根本无法穷举。Anthropic 给出的解法很优雅：暴露一个「代码执行」接口。agent 写一小段脚本，你的 server 在沙箱里执行它，只把结果返回给 agent。
Cloudflare 的 MCP server 是这种模式的参考实现——两个工具（搜索和执行），覆盖了大约 2500 个端点，工具描述只用了 1K token 左右。这是把「灵活性」交给代码表达能力，而不是试图用工具列表穷举所有可能。
这里有一个更深层的设计哲学值得回味：描述能力的最好方式，有时候不是列举，而是赋予表达能力。一张纸可以写无限多的句子，不是因为纸上列出了所有可能的词，而是因为它让你自由组合。代码执行接口的思路与此同理——与其用工具名称的集合来约束 agent 的动作空间，不如给 agent 一个沙箱，让代码去描述任意可能的操作序列。这个模式越来越多地出现在各大平台的 MCP 集成里，不是偶然。
代码执行接口模式：2 个工具 + 1K token，覆盖 Cloudflare 2500 个端点
④ 用标准化认证，别自己造轮子。认证是让 MCP 在生产环境里跑起来的关键一环，也是最容易做错的地方。最新的 MCP 规范支持 CIMD（客户端 ID 元数据文档）用于客户端注册，提供快速的首次授权流程，减少意外的重新认证请求。一旦用户授权，Claude Managed Agents 里的 Vaults 功能可以托管 OAuth token，自动刷新，agent 每次调用不需要自己传 token——这是 Anthropic 推荐的生产认证模式，不需要自建 token 存储，不需要每次调用传递凭证。
⑤ 用 MCP Apps 给用户返回交互界面，不只是文字。MCP Apps 是第一个官方协议扩展，允许工具直接返回交互式界面——图表、表单、仪表盘——内联渲染在对话界面里，用户不需要离开对话去打开另一个页面。Anthropic 的数据显示，使用了 MCP Apps 的 server，采用率和留存率明显高于只返回文本的 server。配套的 Elicitation（引导输入）功能允许 server 在工具调用中途暂停并向用户请求额外信息——比如确认一个破坏性操作，或者完成一个 OAuth 授权流程。
Anthropic 不只讲了怎么做 server，也讲了 client 端的优化模式。这部分是我觉得文章里最有实操价值的内容之一。
工具懒加载（Tool Search）：传统的做法是在 context 里预加载所有工具定义，然后让模型从里面挑选要用哪个。这没什么问题，直到工具数量开始增加。如果你连接了 5 个 MCP server，每个 server 有 20 个工具，那你的 context 里就有 100 个工具定义的固定开销，每次对话都要付出，不管这次对话实际用到了几个工具。
工具懒加载的思路是：不预加载，按需搜索。agent 在运行时从工具目录里搜索它需要的工具，只把相关的工具定义拉进 context。Anthropic 的测试结果是工具定义的 token 使用量减少了 85% 以上，同时工具选择的准确率基本不变。85% 是一个非常大的数字，对于长期运行的生产 agent 来说，这直接转化成可观的成本节省和更快的响应速度。
工具懒加载（Tool Search）：按需拉取工具定义，token 消耗减少 85%，准确率不变
程序化工具调用（Programmatic Tool Calling）：传统的做法是把工具调用的原始结果直接返回给模型，让模型来理解和处理。但如果一个任务需要调用多个工具、对比多个结果、做一些聚合计算，那么每次调用的原始输出都会进入 context，context 迅速膨胀。
程序化工具调用的做法是：在代码执行沙箱里处理工具调用结果。agent 在代码里循环调用、过滤、聚合，只把最终输出放进 context。对于复杂的多步工作流，token 使用量减少了约 37%。
两个模式叠加起来，在多个 MCP server 的场景下自然组合：context 更精简，往返次数更少，响应更快，成本更低。如果你在做 MCP client 端的产品，这两个模式是值得直接采用的工程实践。
这两个优化有一个共同的底层逻辑：把决策权从「全量加载」转移到「按需加载」。传统的做法是防御性的——不确定用哪个，就全部加载进来。新的做法是信任系统的检索能力，只在真正需要时把必要的东西拉进来。这种思路的转变，在软件工程里已经有很长的历史（懒加载、按需渲染），现在轮到 AI agent 的工具管理了。
这是文章里我觉得最值得展开的一个论点：MCP 和 skills 是互补的，不是竞争关系。很多人把这两个概念混为一谈，或者认为有了 MCP 就不需要 skills，这是一个误解。
MCP 给 agent 提供的是「能力的接入口」：我可以查这个数据库，我可以操作这个 API，我可以读取这个系统的状态。但这并不等于 agent 知道「在什么情况下、以什么顺序、出于什么原因使用这些能力」。
Skills 填补的正是这个空缺。Skills 给 agent 提供的是程序性知识——具体的操作流程、决策逻辑、最佳实践、领域专业判断。一个只有 MCP 的 agent，像一个有很多工具但不知道怎么做项目的助手。一个有 MCP 又有 skills 的 agent，才像一个真正懂业务的专家。
Anthropic 举了一个具体例子：他们为 Cowork 做的数据插件，包含 10 个 skills 和 8 个 MCP server，对接了 Snowflake、Databricks、BigQuery、Hex 等数据工具。没有 skills 的情况下，agent 知道可以调用这些工具，但遇到「分析这个季度的销售漏斗并找出断点」这样的问题，它未必知道应该先查哪个表、怎么定义漏斗转化率、什么样的数字值得 flag 出来。有了 skills，agent 具备了领域知识，才能端到端完成真实的数据分析任务。
一个正在推进中的扩展方向：让 MCP server 直接发布对应的 skill，这样 client 在连接 server 的时候自动继承相关的操作知识。Canva、Notion、Sentry 现在已经在 Claude 的目录里这样做了——连接它们的 MCP server，同时获得它们为这个 server 写的使用指南。
这个模式如果标准化，意味着未来每一个高质量的 MCP server 都会自带「使用说明书」，而且这个说明书会随着 server 的版本一起演化、始终和 API 保持同步。这是 MCP 生态的一个很有意思的演化方向。
从用户角度来说，这件事的价值可能比工程师更容易感知到：你连接一个新系统，不需要花时间摸索「怎么用」，因为 server 直接把「最佳用法」打包进来了。这是连接即上手，不是连接完了再学习。对于一个非技术的业务用户来说，这可能是他们愿意真正开始使用 AI agent 的关键门槛。
我读完这篇文章，有一个很清晰的感受：MCP 不再是「可选的」了。
如果你在构建 AI agent，而这个 agent 需要在生产环境里运行、需要接入真实的系统、需要持续可靠地工作——MCP 是那个你迟早要走到的地方。不是因为 Anthropic 在推广它，是因为它解决了一个真实的结构性问题：在 agent 和服务之间，需要一个公共的、可标准化的、可认证的中间层。没有这一层，规模化之后的复杂性会把你压垮。
这篇文章值得细读的地方，不只是它描述了「MCP 是什么」，而是它描述了「优秀的 MCP 集成是什么样的」。工具按意图分组、懒加载工具定义、代码执行接口对接大型 API、skills 和 server 打包分发——这些是具体的设计决策，不是概念。很少有文章把这个层面的实践细节说得这么清楚。
有一个细节让我印象深刻：Cloudflare 用两个工具覆盖了 2500 个端点，只用了 1K token。这不是一个聪明的 trick，这是系统设计上的正确决策——把「灵活性」交给 agent 的代码执行能力，而不是试图用工具列表穷举所有可能。这个思路本身就值得反复回味：有些事情，与其用数据结构描述，不如用可执行代码表达。
还有 85% 这个数字。工具懒加载把工具定义的 token 消耗减少了 85%，但工具选择准确率基本不变。这说明什么？它说明传统「把所有工具都塞进 context」的方式，是一种很粗糙的设计——大量的 token 在做没有必要的「让模型看到所有可能」，而真正需要的只是「在对的时候，让模型看到对的工具」。这是精确度和效率同时提升，而不是权衡取舍。这类「不需要妥协就能做对」的设计空间，在 AI 工程里正在被快速发掘出来。
对于正在构建 AI 产品的团队来说，这篇文章传达的信息很直接：如果你今天还在用直接 API 调用的方式构建 agent 集成，你在建造的是一个会随时间变得越来越难维护的系统。MCP 是那个让集成可以在生态里复用、让一次投入产生持续价值的架构选择。
文章最后有一句话我觉得很准确：「建立在 MCP 上的每一个集成，都在强化整个生态——更少的边界情况需要独立解决，更少的定制集成需要维护。」
这台机器正在标准化。每一个接入 MCP 的团队，都在往这个标准里投票。早进去的人，比晚进去的人少踩很多坑，也更早开始享受生态成熟带来的红利。
对于我们正在构建的产品，这篇文章提供了一个很清晰的参照：你的产品是否有 MCP server？如果还没有，你的用户在 AI 时代里的体验，就比那些有的竞争对手天然低了一个级别——不是因为你的产品不好，而是因为你还没有出现在 agent 能触达的地方。这不是遥远的未来，是现在已经在发生的区别。
原文：Anthropic 官方博客，2026年4月22日
原文：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
本文由人人都是产品经理作者【深思SenseAI】，微信公众号：【深思SenseAI】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。