MCP vs CLI+README:从外包比喻到上下文污染的完整对比

原始问题

“MCP 是不是相当于公司常驻员工 + 外包,Agent 挑功能对口的发东西给他,拿到返回值就行?” “CLI+Readme 到底怎么实现?要不要额外调用 LLM?这样不会污染上下文吗?” “老板亲自下场,为什么比一直养着外包更好?“

MCP 方案的机制(外包装比)

MCP Server 像一个被注册到公司名单的外包人员。Harness 启动时自动连接所有 MCP Server → 获取工具列表 → 和内置工具合并到一个名单(dispatch table)→ Agent 从名单中选人 → 发任务 → 拿结果。

Agent 不知道也不关心一个工具是内置的还是外包的——名单上没写,dispatch table 吞掉了差异。

CLI + README 方案的机制(老板亲自下场)

  1. Agent 启动,工具列表只有 4 个(read/write/edit/bash),完全不知道有外包的存在
  2. Agent 遇到需求,自己推断”项目里可能有文档”→ glob 找到 ./tools/browser/README.mdread 阅读
  3. README 里写了 CLI 工具的用法(纯自然语言描述)
  4. Agent 理解后,直接 bash "browser-cli get-text <url>" 调用 CLI 程序
  5. CLI 程序输出通过 stdout 返回 → Harness 打包给 Agent

关键区别:Agent 自己发现工具、理解用法、拼命令——全程靠推理能力,没有中间层转发。

上下文污染的代价

MCP 方案CLI + README 方案
系统提示词每次 API 调用都带着工具定义(~13K/次)零额外开销
按需开销不需要额外推理读 README(~2K)+ 多一次推理(~500)
整个会话50 次调用 × 13K = 650K 垃圾税49 次零开销 + 1 次 ~2.5K = 总计 ~2.5K

MCP 是垃圾税——不管用不用,次次交。CLI + README 是按需付费——只用一次。

两种方案都污染上下文,但污染的方式不同:MCP 是慢性持续污染,CLI 是单次急性污染后恢复干净。

什么时候哪个方案更好

场景推荐
强模型(Opus),偶尔需要外部工具CLI + README:模型自己会读文档,不需要长期养外包
中等模型(国产),需要外部工具MCP:模型读文档可能出错,结构化工具定义更安全
外部工具被高频调用(每次会话都用)MCP:既然每次都要用,不如提前定义好,省每轮推理
外部工具极少被调用(小概率事件)CLI + README:不值得为小概率事件长期交垃圾税

核心比喻

“老板可以不用每天受到这么多员工点名的折磨,一年要是有一件事,他亲自下场干就干了,反正遇到小概率事件自己出马比一直雇佣外包但是不用还是省钱一点的。”

Mario 方案的精髓:token 应该按需消费,而不是提前支付。 不用的功能——零成本。需要时才付。MCP 的问题是把所有可能的工具提前”注册”并持续收费,无论用不用。

核心引用

“前沿模型被 RL 训练得足够好,不需要冗长的工具定义。模型自己会读文档、理解用法、拼命令。”

“MCP 是垃圾税——不管用不用,次次交。CLI + README 是按需付费——只用一次。”