摘要：很多人以为 Agent 接外部系统，无非就是调 API、跑 CLI、再做几个函数调用。但真正到了生产环境，问题很快会从“能不能接上”变成“能不能规模化复用、稳定授权、跨平台运行”。这正是 MCP 变得越来越重要的原因。
最近 Anthropic 发了一篇很值得技术团队细读的文章，主题很直接，如何让 Agent 真正连接到生产系统，以及为什么很多团队最后会走向 MCP（Model Context Protocol）。
这个问题非常关键。因为今天很多人讨论 Agent，还是停留在“模型会不会规划”“提示词怎么写”“工作流怎么搭”。但一旦真想把 Agent 用在企业环境里，真正决定它有没有价值的，往往不是推理能力，而是它到底能不能安全、稳定、低成本地接进真实系统。
说白了，Agent 再聪明，如果碰不到 Jira、数据库、工单系统、代码仓库、云资源、知识库、支付系统，它就只能做一个聊天机器人。
所以这篇文章真正讨论的是一个很工程、也很现实的话题：Agent 到底该怎么接外部系统？
Anthropic 把答案归纳成三种路径：
- 直接调 API
- 调用 CLI
- 通过 MCP 接入
这三条路都能走，但适用阶段完全不一样。
一、最容易开始的方式，永远是直接调 API
绝大多数团队第一次做 Agent 接入外部系统，都会从 API 开始。
这是最自然的路径。模型要查工单，就发 HTTP 请求；要建任务，就调一个 createTask 接口；要拿数据库记录，就调用内部服务。现在很多平台还会把这个过程包装成 function calling，看起来更优雅，但本质上还是一回事：Agent 直接面对具体 API。
这条路为什么流行？原因很简单：
- 上手最快
- 不需要额外协议层
- 一个 Agent 接一个系统时很直接
- Demo 特别容易做出来
所以如果你现在只是做一个小规模原型，比如“让 Agent 去查 CRM 里的客户信息”，那直接调 API 完全没问题。
问题在于，这种方式只适合起步，不适合规模化。
为什么？因为一旦系统和 Agent 数量上来，就会出现典型的 M×N 集成问题。
比如：
- 3 个 Agent
- 8 个系统
- 不同系统各自有认证方式、参数格式、错误码、速率限制
最后会变成什么？
每一个 Agent 和每一个系统之间，都是一条独立集成链路。于是你会得到：
- 各种重复写的鉴权逻辑
- 各种重复定义的工具描述
- 各种互不一致的异常处理
- 一个新 Agent 上线，就要重新接一遍
- 一个新平台切进来，又要重做一次适配
这就是 API 直连的核心问题，它能用，但不形成公共层。
二、CLI 很快很猛，但它更像“本地开发期武器”
第二条路，是让 Agent 直接跑命令行工具，也就是 CLI。
这个方式在开发者场景里特别常见。比如：
- 调 git
- 调 kubectl
- 调 terraform
- 调某个内部脚本
- 调已经成熟的企业 CLI
它的优点也很明显：
- 复用现有工具链
- 不用重新封装太多语义
- 对本地开发环境很友好
- 在 shell + 文件系统 + 容器 里特别顺手
这也是为什么很多 coding agent、运维 agent、内部自动化 agent，在本地或沙箱里非常喜欢 CLI。
因为它几乎是零门槛接入。你本来就有一套命令行工作流，Agent 只是替你执行。
但 CLI 有一个硬限制，Anthropic 这篇文章点得很准：它的公共层太薄了。
CLI 的问题不是不好用，而是它很难成为“跨平台生产标准层”。
比如：
- 在 Web 端，很多环境不给 shell
- 在移动端，基本没有完整命令执行环境
- 在云托管 agent 场景里，也未必能给你容器和本地文件系统
- 凭证管理通常依赖本地配置文件，迁移麻烦
- 工具语义不标准，Agent 很难稳定理解每个命令的行为边界
所以 CLI 特别适合：
- 本地开发
- 临时自动化
- 宽权限内部环境
- 已有工具很多、先快速接起来的场景
但如果你要的是真正跨端、长期、可复用、可治理的接入方式，CLI 也会很快碰到天花板。
三、MCP 为什么越来越像生产级 Agent 的“公共连接层”
第三条路，就是 MCP。
MCP 可以理解成：在 Agent 和外部系统之间，加了一个标准化协议层。
不再是每个 Agent 自己去理解每个系统，也不再是每个平台自己发明一套工具描述，而是通过 MCP server，把一个系统的能力以标准方式暴露给 Agent。
这件事一旦成立，带来的变化很大。
1. 它先解决的是“复用”问题
如果你直接接 API，本质是 Agent 和系统点对点耦合。
如果你做成 MCP server，那么：
- Claude 能接
- ChatGPT 能接
- Cursor 能接
- VS Code 里的 agent 能接
- 未来别的兼容客户端也能接
也就是说，你不再是在给某一个 Agent 写私有适配层，而是在给整个 agent 生态写一个可复用能力接口。
2. 它解决的是“运行环境不统一”的问题
现在越来越多生产级 Agent 都跑在云端，而不是用户本机。
这是因为生产系统需要：
- 持续运行
- 异步执行
- 弹性扩容
- 多租户管理
- 统一审计
而这些 Agent 要接触的数据和系统，本身也都在云端，比如：
- 企业 SaaS
- 内部工单系统
- 云资源
- 代码托管平台
- 知识库
- 数据平台
这时候，CLI 那套“本地 shell + 本地凭证文件”的思路就不够用了。
MCP 的好处是，它天然更适合远程连接和托管式运行。一个远程 MCP server，可以同时服务 Web、移动端、云 Agent 和桌面客户端。
这就是它最重要的工程价值，不只是“标准”，而是可分发、可跨环境运行。
四、为什么说生产环境最后要的不是“更多工具”，而是“更少但更像任务的工具”
Anthropic 这篇文章里有一个非常重要的观点，我特别认同：
不要把 API 一比一照搬成 MCP 工具，而要按“用户意图”组织工具。
这是很多团队最容易踩的坑。
他们一做 MCP server，就想把自己的 API 全部映射出来：
- getUser
- getThread
- getMessages
- parseAttachment
- createIssue
- attachFile
- updateStatus
看起来很完整，实际上 Agent 用起来会很痛苦。
因为模型不擅长在过多底层原子能力之间自己稳定拼流程。工具越碎，调用链越长，出错概率越高，token 消耗越大。
所以更好的方法是什么？
按任务意图封装。
比如，不要给 6 个底层工具，而是直接给一个：
create_issue_from_thread
这样 Agent 不需要自己做太多中间编排，既减少错误，也减少上下文消耗。
这件事说白了，就是 MCP server 的设计目标不该是“忠实镜像后端 API”，而应该是：
让 Agent 用最少调用次数完成一个完整任务。
这是一种典型的 agent-native 工具设计思维。
五、当系统特别大时，为什么又不能只靠“意图工具”
但事情并不是永远这么简单。
如果你的系统像 AWS、Cloudflare、Kubernetes 这种级别，有几百上千个操作，单靠几个高层意图工具是不够的。
这时候 Anthropic 提出了另一个很实用的模式：code orchestration。
意思是，不要试图为几千个 API 都设计成独立工具，而是只暴露一个很薄的工具层，比如：
- 搜索能力
- 执行能力
然后让 Agent 自己生成一小段代码，这段代码在受控沙箱里运行，再去调用你的 API，最后只把结果返回。
这个模式本质上是在做什么？
是在工具层和代码执行层之间做平衡：
- 工具层保持很薄
- 覆盖面足够大
- Agent 保留灵活性
- 服务端仍能控制安全边界
文章里提到 Cloudflare 的 MCP server 是一个典型例子，两三个工具就能覆盖大量 endpoint，而且 token 成本控制得很好。
这说明一个现实：MCP 不是只能做“固定工具菜单”，它也可以承载更动态、更复杂的编排方式。
六、MCP 真正比 API / CLI 更强的地方，在于它开始有“丰富语义”
如果只把 MCP 理解成“标准化工具调用”，其实还低估了它。
Anthropic 现在强调的一个方向是：MCP 不只是能返回文本，还能返回更丰富的交互语义。
这包括两个特别重要的能力。
1. MCP Apps
MCP Apps 是一个协议扩展，允许工具调用结果直接返回一个交互界面，比如：
- 图表
- 表单
- Dashboard
- 小型操作界面
这件事为什么重要？
因为很多业务场景，文本并不是最好交互方式。
比如：
- 看数据趋势，用图表更直观
- 填参数，用表单更高效
- 看资源状态，用 dashboard 更清楚
如果 Agent 只能返回一段文字，它就很难真正进入复杂业务流程。可一旦 MCP 能把产品 UI 局部嵌进对话界面，Agent 的可用性会立刻上一个台阶。
某种程度上，这意味着 MCP 正在变成一种对话时代的应用接入层。
2. Elicitation
另一个能力叫 elicitation，可以理解成：工具执行到一半，暂停下来向用户要信息。
这很重要，因为真实任务往往不是参数一次给全。
比如：
- 缺一个必填字段
- 要确认删除操作
- 候选项有歧义，需要用户选一下
- 要跳 OAuth 登录
- 要跳支付页
如果没有这种机制，Agent 往往只能中断任务，然后对用户说“请你去设置页完成某某操作”。体验非常割裂。
有了 elicitation，用户还留在当前流程里，只是补一个表单、点一个确认、或者跳一个网页完成授权，再回到任务主线。
这对生产环境太重要了，因为真正可用的 Agent，必须能在自动化和人类介入之间平滑切换。
七、为什么 OAuth、凭证托管这些“脏活累活”，反而决定 MCP 能不能进生产
很多人讨论 Agent 协议，容易只盯着工具格式、返回结构、schema 设计。
但生产环境里，真正最难的，常常不是调用能力本身，而是：
- 用户怎么授权
- Token 怎么保存
- 过期了怎么刷新
- 多个 Agent 会话怎么复用凭证
- 怎样避免每次调用都重新登录
这也是为什么 Anthropic 在文里专门强调标准化认证。
如果一个 MCP server 需要 OAuth，那么规范化的客户端注册和授权流程，会极大降低首次接入和后续维护成本。
更进一步，云托管 Agent 还要解决一个更麻烦的问题：
用户授权之后，Agent 在后台长期运行时，凭证到底放哪？
Anthropic 提到的 vault 思路，本质上就是把这个问题平台化：
- 用户授权一次
- 平台代管 token
- 会话创建时按 vault ID 注入
- 平台负责刷新和复用
这意味着开发团队不需要自己再造一套秘密管理和 token 生命周期系统。
这看起来像“工程细节”，但其实非常关键。因为生产级 Agent 真正落地，最后拼的往往不是 Demo 漂不漂亮，而是谁先把这些脏活累活工程化。
八、如果你今天在做 Agent 集成，应该怎么选？
说到这里，其实就能给出一个非常务实的判断。
如果你在做原型验证
直接调 API 就够了。
因为你最关心的是：
- 能不能跑通
- 业务值不值得做
- 用户有没有兴趣
这时候别过早设计复杂协议层。
如果你在做本地开发者工具
CLI 仍然非常好用。
尤其是：
- coding agent
- devops agent
- sandbox agent
- 内部提效工具
这类场景本来就离 shell 很近，CLI 的性价比很高。
如果你在做生产级、跨平台、长期复用的 agent 系统
那你几乎一定会认真考虑 MCP。
因为你最终需要的是：
- 可复用接入层
- 标准化能力发现
- 更稳定的鉴权流程
- 跨端兼容
- 更丰富的交互语义
- 对云托管 agent 更友好的运行方式
这不是“追新协议”，而是工程复杂度逼出来的结果。
九、写在最后，MCP 真正解决的不是“调用工具”，而是“让 Agent 接近软件系统的方式标准化”
我觉得这篇文章最值得读懂的一点是：
很多人把 MCP 当成一个新工具格式，但它真正的价值远不止这个。
它在解决的，是一个更大的问题：
当 Agent 不再只是聊天助手，而要真正进入企业软件、云平台、业务流程时，它应该通过什么公共层去接近这些系统？
API 当然还能继续用。CLI 当然也不会消失。
但只要 Agent 继续往生产环境走，继续往跨平台走，继续往远程托管走，行业就一定会需要一种更统一的连接层。
而 MCP 现在越来越像那个位置。
所以，MCP 的意义不是“比 API 高级”，也不是“要取代 CLI”，而是：
它开始把 Agent 连接软件世界这件事，从零散集成，推向标准工程。
这一步，可能比很多人现在意识到的还要重要。
参考资料：
- Anthropic Blog: Building agents that reach production systems with MCP
- Anthropic 关于 MCP Apps、Elicitation、Claude Managed Agents 与 Vaults 的公开说明