“MCP vs CLI” 是一场错误的辩论

在 2025 年的大部分时间里，AI 工程师们都在争论代理（Agent）应该如何调用工具。

一方主张使用 MCP（Anthropic 发布的用于连接代理与外部服务的协议）。另一方则认为跳过协议，直接给代理一个 Shell 即可。

两方都有各自的理由。但两方都偏离了重点。

各方对的地方

怀疑论者衡量了 MCP 服务器在实际上下文中的成本：

• Playwright MCP 消耗 13.7K tokens
• Chrome DevTools MCP 消耗 18K tokens
• 一个 5 个服务器的配置在任何工作开始之前就会消耗 55K tokens

支持者则用多租户案例进行了反驳：

• CLI 在多租户应用中容易出错
• 没有类型化契约，导致代理只能猜测输出
• 在面对不熟悉的 API 时，代理会浪费多次交互来解析文本

如果你在读到这里时在想“好吧，那谁赢了？”，那你问错问题了。

重新审视

2025 年 11 月 4 日，Anthropic 发布了《通过 MCP 进行代码执行》，改变了讨论的方向。

问题从来都不是协议本身。问题在于一旦会话开始，就将每个工具的完整描述加载到上下文中的习惯。加上这些工具返回的数据，并在每一步都通过模型传递，单个工作流的 token 消耗可能会膨胀到 150K。

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

在 Anthropic 的例子中，Google Drive 的转录内容流向 Salesforce CRM 更新。旧的方式是加载两个工具的 schema，并将转录内容两次通过模型。新的方式只需要几行 TypeScript，导入所需的内容。同样的任务，仅需 2K tokens。减少了 98.7%。

Cloudflare 将其推得更远。他们通过将 2,500 个端点的整个 API schema 从 1.17M tokens 压缩到 1K tokens，仅暴露两个函数：search 和 execute。代理编写代码搜索目录，然后只执行匹配的内容。

新模式：代码模式（Code Mode）

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

Bash，用于任何已安装二进制文件的任务，如 git、curl 或 grep。模型在训练数据中见过这些，并知道如何组合它们。需要查找所有导入 pandas 的 Python 文件吗？代理只需写一行：

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

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

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

第二部分是关键所在。类型签名随导入一起加载。代理获得其所选工具的严格契约，而无需为跳过的工具支付任何费用。

实际操作如下所示：

// 代理编写此代码。类型仅在这些导入行加载。
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 vs CLI”的辩论框架偏离了重点的原因。两种方法都幸存下来了。它们只是不再作为运行时，而是成为运行时组合的原语。

这意味着什么

“MCP 已死”是对这场辩论的错误总结。

Anthropic 刚刚报告 MCP SDK 下载量达到 3 亿次，而年初时为 1 亿次。协议并没有消亡。它是目前增长最快的代理基础设施部分。

消亡的是预先加载每个工具的做法。这从来都不是一个好主意。

如果你要在 2026 年构建代理，规则很简单。工具定义应属于代码，而不是上下文。模型编写几行代码调用它们。运行时完成其余工作。

这才是这场辩论真正关于的内容。

感谢阅读！

如果你觉得有见地，请与你的网络分享。

找到我 → @akshay_pachaar ✔️

获取更多关于 LLM、AI 代理和机器学习的见解和教程！