Claude最新文章：指明了MCP的位置，并给出使用MCP的正确姿势

公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-04-26 21:02

原文链接：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp

✅点击上方🔺公众号🔺关注我✅

ClaudeDevs昨天发了一篇博客，标题很干：“构建能连接生产系统的Agent”。

讲了三件事：Agent连接外部系统有几种方式？为什么生产级Agent最终都选了MCP？以及怎么把MCP服务器写好。

很实战，没有废话。

先说痛点：Agent其实是个”瞎子”

一个大模型再强，它也只能看到自己训练时喂进去的东西。

你的Jira、工单系统、数据库、GitHub仓库——这些东西对Agent来说是黑的。

所以业界一直在找方案：怎么让Agent真正触达到生产系统？

Anthropic观察了无数团队之后，总结出三条路。

三条路：Direct API、CLI、MCP

第一条：Direct API Agent直接调你的接口——在代码沙箱里发HTTP请求，或者通过通用函数调用工具。

起步快，适合一个Agent对一个服务。但规模一大就完蛋——每个Agent-服务对都是一套独立的集成，要各自写认证逻辑、工具描述、处理边界情况。这就是所谓的 **M×N问题：**10个Agent × 10个服务 = 100套定制集成。

第二条：CLI Agent在你的机器上跑命令行工具。快、轻量、绕过了网络限制。

但CLI天生只适合本地环境和沙箱容器。一旦你的系统是移动端、Web、云服务——没有容器就跑不动。认证也是问题，CLI通常靠本地凭证文件，没有通用方案。

第三条：MCP（Model Context Protocol） MCP是一个协议层，提供标准化的通用接口。Agent连接到一个MCP服务器，服务器再连接你的系统——认证、发现、丰富的语义都标准化了。

一个远程服务器，可以被任何兼容客户端（Claude、ChatGPT、Cursor、VS Code……）调用，不挑部署环境。

代价是要多做一点前期工作。但回报是集成是可移植的，而且能获取足够丰富的语义。

为什么生产级Agent最终都选MCP？

关键趋势：生产级Agent正在向云端迁移。

它们需要连接的系统也在云上——你的数据、工作流、基础设施，全是远程的，而且有认证保护。

MCP恰好填补了这个空白。

几个信号：

MCP SDKs月下载量已突破3亿次（年初才1亿）
Claude目录已有**200+**已发布的MCP服务器
MCP已被ChatGPT、Cursor、VS Code、Gemini、Microsoft Copilot等主流工具原生支持
Anthropic已经把MCP捐给了Linux Foundation下的Agentic AI Foundation（AAIF），联合方还有OpenAI、Google、Microsoft、AWS、Cloudflare、Bloomberg——这是一个行业级别的共识

现在建MCP服务器，不是在押注一个私有协议，而是在参与一个开放标准。

怎么写一个好的MCP服务器？

原则一：做远程服务器，最大化分发范围

远程服务器是唯一能让Agent在Web、移动端、云端都能跑通的方式。所有主流客户端都在为此优化。

原则二：按”意图”分组工具，而不是按API端点

不要把API一对一映射成MCP工具——这是反模式。

好的做法是按Agent要完成的意图来分组。一个 create_issue_from_thread 工具，远好过 get_thread + parse_messages + create_issue + link_attachment 四步走。

Agent两三个调用就能完成任务，而不是拼凑一堆原始操作。

Anthropic自己的经验：更少、更精准的工具描述，效果永远好过穷举式API镜像。

原则三：表面大而深的API，用代码编排

如果你的服务涉及成百上千个操作（比如Cloudflare、AWS、Kubernetes），意图分组也覆盖不过来。

解法：暴露一个薄薄的工具表面，允许Agent写脚本——Agent写一段短代码，你的服务器在沙箱里执行，对API只返回结果。

Cloudflare的MCP服务器是标杆案例：两个工具（search + execute），覆盖约2500个API端数，Token消耗约1K。

原则四：用富语义提升体验

MCP Apps是官方首个协议扩展，能让工具返回一个交互界面——图表、表单、仪表盘，直接内嵌在聊天界面里。

用过的都知道：返回富媒体的服务器，用户粘性和使用率都显著高于纯文本返回。

Elicitation（征询）允许服务器在工具调用中途停下来向用户请求输入——补全一个缺失的参数、确认一个危险操作、或者在多个选项中做判断。两种模式：Form Mode（返回结构化表单-schema，客户端渲染原生界面）和URL Mode（把用户跳转浏览器，完成OAuth或支付等敏感操作）。两者都让用户留在流程里，而不是跳到设置页面。

原则五：用标准化认证方案

MCP spec现在支持CIMD（Client ID Metadata Documents），做首次认证的快速通道，而且用户授权之后，云端Agent运行时能自动持有和复用token，不需要你自己搭密钥存储，也不需要每次调用都传一遍。

客户端怎么省Token？两个关键技术

MCP不只是服务器的事情。客户端也可以做优化，Anthropic给了两个成熟方案：

Tool Search：按需加载工具定义

传统做法是Agent初始化时就把所有工具定义全部塞进context。问题是：如果你接了20个MCP服务器，每个服务器有50个工具，这就是1000个工具定义——Token消耗巨大。

Tool Search把这件事反过来：Agent在运行时搜索工具目录，只在需要的时候才把相关工具加载进来。

实测数据：Token消耗减少**85%+，**工具选择准确率基本不变。

Programmatic Tool Calling：代码里处理工具结果

传统做法：Agent调工具，工具返回原始结果，Agent再把这些结果放进prompt里继续推理。

问题：多步骤工作流里，Agent要在脑子里”循环”处理中间结果，每一步都要占Token。

Programmatic Tool Calling把工具结果先丢进代码执行沙箱处理——Agent在代码里做循环、过滤、聚合，只把最终结果放进上下文。

实测数据：复杂多步骤工作流的Token消耗减少37%。

MCP + Skills：1+1>2

MCP解决的是Agent的”能力”问题——它能调用哪些工具和数据。

Skills解决的是Agent的”知识”问题——它知道怎么用这些工具把一件事真正干好。

两者是互补的。Anthropic指出了两个组合模式：

模式一：打包成插件

用Claude的插件格式，把Skills和MCP服务器打包在一起分发。一个Notion插件里，可能包含10个Skills + 8个MCP服务器，分别对应Snowflake、Databricks、BigQuery、Hex等数据工具。

Agent既有了工具，也有了使用这些工具的流程知识。

模式二：从MCP服务器分发Skills

现在越来越多提供商在发布MCP服务器的同时附带一个Skill——Agent连接服务器之后，自动获得这个领域的使用手册，Skills版本还跟着API版本走，不会出现接口变了但指引还是旧的情况。

MCP社区正在推进一个官方扩展，让这个组合可以跨客户端移植。预计会成为主流。

结论：MCP是那个复利层

文章最后有一句话很到位：

每次在MCP上建一个集成，整个生态系统都因此变强了一点。不需要重复造轮子，不需要维护一堆定制集成。

这才是MCP真正的价值——它不是一个技术方案，而是一个复利资产。

你现在在MCP上投入的每一分开发成本，都在未来每一次有新客户端接入时自动升值。今天写好一个MCP服务器，明天Claude、ChatGPT、Cursor、VS Code都能用，不需要你做任何额外工作。

附：Anthropic官方博客原文

Building agents that reach production systems with MCP

https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp

如果觉得这篇文章有帮助，欢迎点赞、在看、转发！有问题也可以在评论区留言，我会尽量回复！

cover_image

AI兴观点程叙架构与AI.