MCP与CLI之争：争论错了方向

2025年的大部分时间里，AI工程师们一直在争论智能体应该如何调用工具。

一方主张使用MCP——Anthropic发布的用于将智能体连接至外部服务的协议。另一方则主张跳过协议，直接给智能体一个终端。

双方都有切实的理由，但也都偏离了重点。

双方各自的合理之处

怀疑派衡量了MCP服务器在上下文中实际消耗的资源：

支持派则以多租户场景进行反驳：

如果你读到这儿在想“好吧，那到底哪边赢了？”，那你就问错了问题。

重新定义问题

2025年11月4日，Anthropic发布了“使用MCP执行代码”，改变了这场讨论的方向。

问题从来不在协议本身，而在于一种习惯：会话一开始就把每个工具的完整描述加载进上下文。再加上这些工具返回的数据，每一步都经过模型传递，一个简单的工作流就可能膨胀到150K tokens。

解决办法是翻转模型的职责。模型不再通过上下文调用工具，而是编写代码，通过运行时调用工具。模型只看到它导入的内容。

在Anthropic的示例中，一份Google Drive的转录文本流入Salesforce CRM更新。旧方式加载两个工具的模式，并将转录文本两次通过模型。新方式则是几行TypeScript，按需导入所需内容。同样的任务，只需2K tokens，下降了98.7%。

Cloudflare 更进一步。他们将其整个包含 2,500 个端点的 API 从 117 万 token 的 schema 压缩到仅 1K token，只暴露了两个函数：search 和 execute。代理编写代码来搜索目录，然后仅执行匹配的内容。

新模式：代码模式

代码模式是一种运行时，代理在其中编写代码，混合使用两种原语。

Bash，用于任何已安装二进制文件的场景，如 git、curl 或 grep。模型在训练数据中见过这些，知道如何组合使用。需要找到每个导入 pandas 的 Python 文件？代理只需写一行代码：

grep -r "import pandas" --include="*.py" .

无需工具定义。Shell 就能完成工作。

类型化模块导入，用于专有 API，如 Salesforce、Stripe 或你的内部服务。可以将这些视为小型 TypeScript 文件，代理可按需拉取。每个文件描述一个工具，明确其输入和输出。代理只加载实际使用的文件。

第二部分是关键。类型签名随导入一起传递。代理为其选择的工具获得严格契约，而跳过未使用的工具则无需付出任何代价。

以下是实际效果：

// The agent writes this. Types load only on these import lines.
import { searchFiles } from "@tools/github";
import { sendMessage } from "@tools/slack";

const files = await searchFiles({ pattern: "*.py", path: "./src" });
const summary = files.map(f => f.path).join("\n");

await sendMessage({
  channel: "#engineering",
  text: `Found ${files.length} Python files:\n${summary}`,
});

这里发生了三件以前不可能实现的事情。

GitHub 和 Slack 工具定义仅在导入行进入上下文。运行时提供的所有其他工具都保持在外。

文件列表的处理是在代码中完成的，而非通过模型传递。模型从未见过原始的路径列表，它只看到代码构建出的摘要。

代理在实际代码中编写循环和变换，每一步都不需要经过模型的往返处理。

一个有用的比喻是：在旧模型中，代理走进一个房间，所有工具都摆在桌上。而在代码模式下，代理走进一个房间，墙上挂着一排工具目录，只取自己需要的那些。

MCP的类型化契约加上CLI的懒加载，融合在同一个运行时中。代理根据任务按需选择。

整合起来

三种方法并排对比，就能看清全貌。

MCP提供了类型化契约，但一开始就加载了所有内容。CLI提供了懒加载访问，但没有契约。代码模式从MCP那里继承了类型化契约，从CLI那里继承了懒加载，并将两者整合进同一个运行时。

图表的底部注释是实际要点。代码模式并不是对这两种方法的替代，而是一个同时使用两者的运行时。对于$PATH上有二进制的任何操作，使用Bash；对于专有API，使用类型化模块导入。

代理根据任务决定。文件搜索用bash，Salesforce更新用类型化导入。同一个工作流可以在几行代码中混合使用两者。

这也是为什么将辩论框定为“MCP对CLI”的争论没有抓住重点。两种方法都存活了下来，它们只是不再是运行时本身，而成为了运行时组合的基本单元。

这意味着什么

“MCP已死”并非这场辩论的正确结论。

Anthropic 刚刚报告称 MCP SDK 下载量已达 3 亿次，而年初时仅为 1 亿次。该协议并未消亡，它目前是增长最快的智能体基础设施。

真正被淘汰的是预先加载所有工具的做法。这从来都不是个好主意。

如果你在 2026 年构建智能体，规则很简单：工具定义属于代码，而非上下文。模型只需编写几行调用它们的代码，其余工作由运行时完成。

这才是这场辩论的真正核心。

感谢阅读！