MCP 丸辣？不不不，Agent 进生产都绕不开 MCP

最近几个月 Agent 领域的 CLI（命令行）和 Skills 非常热，这俩配合也特别顺畅，这种默契程度在我们开发墨问 CLI 的过程里已经见识过了。于是很多人（包括我）会觉得，之前的 MCP 会被逐步放弃掉，因为太耗费上下文了，效率也没那么高。

最近看了 Anthropic 发的一篇文章，标题是《Building agents that reach production systems with MCP》。文章的核心是：Agent 要连接外部系统，通常有三种方式，直接 API 调用、CLI，以及 MCP。但构建生产级别的 Agent，目前还是 MCP 靠谱。

1

Agent 调业务系统的服务，最直接的方式，自然是让 Agent 直接调用系统的 API。

比如在 VM 沙箱里发送 HTTP 请求，或者通过 function calling 的方式调用某个服务。这样做的好处是，早期验证很方便，让 Coding Agent 自己实现一个这样的服务也是分分钟的事儿：一个 Agent 接一个服务，接口清晰，场景单一，很快就能跑起来。

规模化之后就有点麻烦了。

每多一个 Agent，就多一个服务，多一组集成关系。认证、参数描述，错误恢复，权限分配，异常处理，都得做。Anthropic 把这种情况称之为 M×N integration problem，也就是 M 个 Agent 乘以 N 个服务带来的集成问题。

开始是工程问题，最后会演变成组织成本问题。小团队可以靠文档和默契硬扛，大团队很快就会被重复集成拖住。

2

第二种方式就是命令行 + Skills，Skills 技术和规范差不多是所有 Agent 的标配了，整合上下文喂给大模型，然后根据用户指令和上下文选择在 shell 里运行命令行工具，解析返回的数据，再把“温暖的数据”返回给用户，无比丝滑。

这个方式对开发者很友好，对本地友好，因为大量成熟系统本来就有 CLI。Git、Kubernetes、Cloudflare、AWS、内部运维工具，很多能力已经沉淀在命令行里了，还有很多业务系统正在做命令行化，比如飞书、钉钉、企微都有命令行工具，墨问的也快上线了，同时还有类似 opencli 这样的通用命令行可以访问各大网站——CLI 逐步变得无所不能。

CLI 的优势是快、轻，贴近本地环境。只要有文件系统、有 shell、有凭证文件，Agent 就能把已有工具连接起来，完成多个复杂的长任务。

CLI 更适合的场景是本地和沙箱容器，或者把 LLM + CLI 封装成 Agetn 放在云端提供服务。一旦 Agent 跑在 Web 和移动端里，运行环境、凭证文件、权限隔离都会变复杂，比如一些个人助理（Cowork），其实是没法直接运行 CLI 的，这个我们昨天的文章里也提到过。

3

第三条路就是 MCP，全程 Model Context Protocol。MCP 的故事显然已经有点老了，但这货正在进入成熟期。它做的事情，是把 Agent 和外部系统之间的连接层标准化。外部系统通过 MCP Server 暴露能力，Agent 客户端通过协议发现工具、处理认证、理解语义，并完成调用。

MCP 需要更多前期投入。写一个好用的 MCP Server，比封装一个 API 或让 Agent 去运行 CLI 更麻烦一些。

不过，生产系统看重的是准确性、可靠性和安全性，而不仅仅是开发成本。

Anthropic 的一个关键判断是：生产级 Agent 越来越多地运行在云端。云端 Agent 既能持续运行，又能扩展和统一管理，也更容易接入企业流程。与此同时，它要访问的系统也大多在云端：数据仓库、工单系统、CRM、代码仓库、监控平台、基础设施服务。

这时，CLI 的本地优势会变成限制，直接 API 调用又容易把每个 Agent 和每个系统绑成一团。MCP 的优势就会显露出来：一个远程 MCP Server，可以服务多个兼容的客户端/服务端。类似 Claude、Codex、SOLO 以及其他 Agent 平台，只要支持 MCP 协议，就能接入同样的能力。

这种做法更适合企业级应用，展现了 MCP 的复利：一次编写，到处被调用，嗷嚎～

总结一下：API 是基础功能，CLI 和 MCP 都需要 API。CLI 是开发者工具，更适合个人助理类的本地产品，比如龙虾，Claude Code 等，MCP 则是 Agent 时代的连接层，更适合生产系统。

那么，如何封装 MCP 呢？

尽可能构建远程 MCP Server，比如墨问官方 MCP 就是基于 Streamable HTTP 协议做的，一次安装，Web、移动端和云托管 Agent 都能用，不需要依赖本机环境，也不需要每个 Agent 都构建沙箱运行 shell。对生产系统来说，这是很友好的。

另外，很多系统有几十个甚至几百个 API。如果把这些 API 一比一封装成 MCP 工具，在 Agent 面前的展现的是一堆碎片能力。大模型需要自己判断先调用哪个、再调用哪个、怎么组合、怎么处理边界情况，速度慢还费 Token。

更好的方式，是把工具设计成任务单元。

比如“从一段对话创建 issue”，就比“ 获取对话、解析消息、创建 issue、关联附件” 更适合 Agent 使用。前者接近人的目标，后者只是各种零碎信息。

再举个例子，一个订单追踪功能，如果后端有三个接口（查订单、查物流、查预计送达时间），糟糕的封装会把这三个全部暴露成工具，大模型需要加载三份工具描述、发起三次往返调用、并把所有中间结果塞进对话历史；而好的封装只暴露一个 track_order(email)，内部自己串联三次调用，最后返回"订单 #12345678 已由 老池 发出，周一送达"。

换句话说，MCP 是给 AI Agent 用的 UI，不是给开发者用的 SDK。它的每个 tool 都应该对应用户/Agent 想要达成的一个完整目标，而不是对应后端一个原子操作。

未来我们做产品，一方面要考虑人怎么用，另一方面要想想，Agent 怎么用。谁都不能得罪，都得 Friendly（芙蓉得利）。