文章用户精选· 08-17 · 10:28

MCP vs CLI 是错误的争论：代码模式才是真正的答案

打开原文

MCP vs CLI 是错误的争论

原标题：MCP vs CLI was the wrong debate

作者：Akshay (@akshay_pachaar)

发布：2026-05-09

互动：💬 11　🔁 59　❤️ 490　🔖 977　👀 259,890

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

一个阵营主张使用 MCP，也就是 Anthropic 发布的、用来连接智能体与外部服务的协议。另一个阵营则说，跳过协议，直接给智能体一个 Shell 就行。

双方都有实在的论据，但双方也都错过了重点。

每个阵营说对了什么

质疑者们算了算 MCP 服务器实际消耗的上下文：

Playwright MCP 吃掉 13.7K token
Chrome DevTools MCP 吃掉 18K
一个 5 台服务器的配置，还没开始干活就烧掉 55K token

拥护者们则用多租户场景回击：

CLI 在多租户应用上会出问题
没有类型契约，智能体只能靠猜来理解输出
面对不熟悉的 API，智能体会在解析文本上浪费很多轮次

如果你读到这儿，心里想的是"好吧，那到底谁赢了？"，那这个问题就问错了。

重新框定问题

2025 年 11 月 4 日，Anthropic 发表了"Code execution with MCP"，彻底改变了讨论方向。

问题从来不在协议上，而在于那种习惯：每次会话一开始，就把所有工具的完整描述都加载到上下文里。再加上这些工具返回的数据，每一步都要经过模型，一个工作流轻轻松松就能膨胀到 150K token。

解决办法是翻转模型的工作。模型不再通过自己的上下文去调用工具，而是写代码，通过一个运行时去调用工具。模型只看到它导入的部分。

在 Anthropic 给出的例子里，一份 Google Drive 的转录稿要流入一次 Salesforce CRM 的更新。旧方法需要加载两个工具的 schema，还要把转录稿反复送进模型。新方法则是几行 TypeScript，按需导入。同一个任务，只要 2K token。下降了 98.7%。

Cloudflare 进一步推进了这个思路。他们把包含 2500 个端点、schema 多达 1.17M token 的完整 API，压缩到了 1K token，只暴露两个函数：search 和 execute。智能体写代码去搜索目录，然后只执行匹配到的部分。

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

代码模式（Code Mode）是一个运行时，智能体在其中写代码，混合使用两种原语。

Bash，用来处理所有已经安装好二进制文件的东西，比如 git、curl 或 grep。这些在训练数据中模型都见过，知道怎么组合。需要找出所有 import 了 pandas 的 Python 文件？智能体写一行就行：

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

不需要工具定义，Shell 直接搞定。

类型化模块导入，用来处理 Salesforce、Stripe 或者你内部服务这类私有 API。可以把它们想象成智能体按需拉取的小型 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 的工具定义，只在 import 那几行才进入上下文。运行时提供的其他所有工具，一概不进来。

文件列表在代码里处理，而不是一次次送进模型。模型根本看不到原始的文件路径列表，它只看到代码生成的摘要。

智能体在真正的代码里组合循环和转换，不再每一步都跟模型来回折腾。

可以这么想：在旧模式下，智能体走进一个房间，所有工具都摊在桌面上。在代码模式（Code Mode）下，智能体走进一个房间，墙上挂着工具目录，它只取下自己需要的。

MCP 的类型契约加上 CLI 的按需加载，放在同一个运行时里。智能体按任务选择。

串联起来

三种方法并排放在一起，完整的来龙去脉就清楚了。

MCP 给了我们类型契约，但一开始就把所有东西都加载了。CLI 给了我们按需访问，但没给契约。代码模式（Code Mode）从 MCP 那里拿来了类型契约，又从 CLI 那里拿来了按需加载，把两者放在同一个运行时里。

这张图的底部才是真正的实践启示。代码模式（Code Mode）不是要替代双方，而是一个同时使用两者的运行时。Bash 负责所有 $PATH 上有二进制文件的东西，类型化模块导入负责私有 API。

智能体按任务自己决定。搜文件用 bash，更新 Salesforce 用类型化导入。同一个工作流，几行代码里就可以混用。

这也正是为什么把争论框定为"MCP 还是 CLI"会错过重点。两者都活下来了，只是它们不再扮演运行时，而是变成了运行时去组合的原语。

这意味着什么

"MCP 已死"并不是这场争论应该得出的结论。

Anthropic 刚刚报告了 MCP SDK 下载量达到 3 亿次，而今年年初时这个数字还是 1 亿。这个协议并没有衰落。它是当前增长最快的智能体基础设施之一。

真正被淘汰的，是一开始就提前加载所有工具的做法。那从来都不是个好主意。

如果你在 2026 年构建智能体，规则很简单。工具定义应该放在代码里，而不是放在上下文中。模型只需要写几行代码来调用它们，剩下的交给运行时来处理。

那才是这场争论真正关乎的问题。

感谢阅读！

如果你觉得这篇文章很有启发，欢迎分享给你的朋友们。

关注我 →@akshay_pachaar✔️

获取更多关于 LLM、AI 智能体和机器学习的见解与教程！