为什么越来越多的大厂抛弃MCP，转向CLI？
在过去的一年里，Model Context Protocol (MCP，模型上下文协议) 曾被视为 AI Agent 工具集成的终极标准。作为一个由 Anthropic 推出的开源协议，它旨在为 AI 与外部数据源和工具之间建立一套类似于 USB-C 接口的标准化协议。
然而，到了 2026 年，技术圈的工程实践发生了一次引人注目的理性回归。越来越多的大厂和顶尖开发者在构建实际生产环境中的 AI Agent（如 Anthropic 的 Claude Code 等）时，开始冷处理甚至放弃 MCP，重新拥抱诞生已半个世纪的 CLI (Command Line Interface，命令行界面)。这股“抛弃 MCP，转向 CLI”的技术转折背后，究竟有着怎样的工程学考量？
MCP 的阵痛：开局吃掉 10 万 Token 的“上下文肥胖症”
MCP 最受争议的设计在于其“开局全注册”的机制。在 MCP 架构下，AI 客户端连接到服务器后，服务器需要一次性将所有可用工具的 JSON Schema 定义、参数类型、以及每个字段的详细描述全量注入到模型的上下文窗口中。
这种设计在连接 1~2 个简单工具时没有问题，但在大型工业级应用中会引发灾难性的后果：
1. Token 开销高昂：如果你连接了多个功能强大的 MCP 服务器，仅仅是工具声明部分就会轻易吃掉 10 万个甚至更多的 Token。这意味着 AI 还没开始处理你的第一句提问，高昂的上下文成本就已经产生了。
2. 上下文腐烂（Context Decay）：随着上下文窗口被大量无关的 JSON Schema 填满，模型处理核心任务的关注度会显著下降。大模型的注意力机制会被这庞大的元数据干扰，导致它在执行实际任务时，工具选择的准确率反而随工具数量的增加而急剧下降。
这种在会话初期就将所有规则悉数倒给 AI 的做法，被开发者戏称为 AI 时代的“SOAP 协议”——过度设计且笨重无比，严重拖慢了 Agent 的运行响应速度。
CLI 的复兴：回归 Unix 哲学与“按需探索”
与 MCP “开局全塞”的笨重机制相反，CLI 走的是一条极其务实的“按需探索（Progressive Disclosure）”路线。
当 AI Agent 需要使用某项功能时，它不需要预先加载该工具的所有参数。AI 可以像人类开发者一样，仅在需要时通过调用帮助命令（例如 gh --help 或 git commit --help）来动态获取所需的指令结构。
这种机制带来了巨大的工程优势：
• 极致的 Token 效率：上下文窗口在会话开始时保持极度干净，只有在真正需要调用某个命令时，AI 才去读取特定的 --help 信息。实测表明，在相同复杂度的任务下，CLI 方案所消耗的 Token 成本比 MCP 方案降低了数十倍。
• Unix 哲学的可组合性：Unix 哲学的核心是“做好一件事，并通过标准接口组合”。CLI 原生支持管道符（|）操作，AI Agent 可以轻松地通过 grep、awk、xargs 将多个简单的命令串联成一条复杂的逻辑链，而不需要在客户端编写任何复杂的胶水代码。
这种天然的组合能力和低上下文占用，让 AI Agent 在执行长任务（Long-running tasks）时，不仅速度飞快，而且极不易因为上下文过载而发生逻辑混乱。
为什么 CLI 是大语言模型最擅长的“原生母语”？
除了 Token 效率和组合灵活性，另一个让大厂坚定转向 CLI 的重要原因在于：命令行本身就是 LLM 的“原生母语”。
在预训练阶段，各大主流大模型（GPT-4、Claude 3.5、DeepSeek 等）阅读了互联网上几乎所有的开源代码库、Unix/Linux 官方文档、Shell 脚本以及无数的 Stack Overflow 问答。模型在底层对 git、curl、docker、sed 等命令行工具的用法、报错信息以及排错机制已经具备了极强的“原生直觉”。
这意味着：
• 零转换负担：模型不需要任何人给它定义一套严谨的 JSON 结构，它自己就知道该怎么写出符合要求的 tar -czf 命令。
• 极高的容错与纠错能力：当 CLI 执行出错时，标准错误流（stderr）返回的往往是人类可读的文字（如 Permission denied 或 No such file or directory）。大模型极其擅长理解这些文本，并能根据报错内容自动进行多轮自我修正（Self-correction），这比解析 MCP JSON-RPC 返回的抽象错误代码要顺畅得多。
深度对比：MCP 治理与 CLI 执行的选型矩阵
为了更清晰地呈现这两种技术选型的差异，我们从多个工程维度对 MCP 与 CLI 进行了对比：
| 维度 | MCP (Model Context Protocol) | CLI (Command Line Interface) |
|---|---|---|
| 交互媒介 | 强类型 JSON-RPC / API 契约 | 纯文本输入与标准输入输出流 (stdin/stdout) |
| Token 消耗 | 极高 (必须在 System Prompt 中加载完整 Schema) | 极低 (AI 通过 --help 在交互中按需获取参数) |
| 模型适配度 | 依赖工具描述的质量，需对模型进行显式工具微调 | 原生适配 (模型对命令行具备天然的极强直觉) |
| 组合灵活性 | 差 (无法直接在模型侧将多个工具进行流式组合) | 极强 (支持 Unix 管道 | 以及重定向) |
| 安全与审计 | 极高 (内置 OAuth，支持细粒度的权限控制) | 较弱 (依赖系统本身的权限，AI 误操作风险较高) |
| 典型适用场景 | 企业级安全网关集成、跨语言中台数据接入 | 个人开发助手 (如 Claude Code)、高性能本地自动化 |
通过对比可以看出，两者的优缺点形成了完美的互补。大厂的转向并非“全盘否定”MCP，而是技术选型走向成熟的标志。
工程实践：AI Agent 如何使用 CLI 进行“按需探索”
在实际的 AI Agent 架构中，使用 CLI 进行按需探索的交互流程非常直观。以下是一个模拟 AI 遇到未知 CLI 工具时，通过自动阅读帮助信息并执行命令的完整交互过程：
1. 客户端给 AI 的 System Prompt
在系统启动时，不需要把所有的命令都告诉 AI，只需要给它提供运行终端的能力即可：
你是一个拥有终端（Terminal）执行权限的 AI 助手。
如果需要操作当前目录的文件或调用系统工具，请直接输出相应的 shell 命令。
如果你对某个工具的参数不确定，可以优先执行 `tool_name --help` 进行按需学习。
2. AI Agent 自动探索与执行的过程
当用户提出任务：“帮我把项目中的 data.csv 文件转换为 JSON 格式” 时，AI 的思考与执行链如下：
第 1 轮交互（AI 探索工具用法）：
AI 发现本地有 csv2json 这个 CLI 工具，但不确定它的参数，于是输出命令：
csv2json --help
终端返回的标准输出（stdout）：
csv-to-json converter utility v1.2
Usage: csv2json [options] <input_file> <output_file>
Options:
-p, --pretty Pretty-print the output JSON
-d, --delim <char> Separator character (default is ',')
第 2 轮交互（AI 掌握参数并执行组合命令）： AI 瞬间通过 stdout 学习到了该工具的用法，并结合 Unix 管道机制，输出最终的命令：
csv2json -p data.csv output.json && head -n 10 output.json
在这个过程中，AI 从零认识工具到完成任务，仅在第 2 轮会话中引入了不足 200 个 Token 的帮助文档内容，相比于 MCP 方案启动时全量加载数百行 JSON 定义，效率提升了几个数量级。
结语：分层共识的未来
大厂抛弃 MCP 转向 CLI，本质上是 AI Agent 工程化从“崇拜新协议”过渡到“实用主义”的必然结果。
现在的业界共识已经非常清晰：让 CLI 负责高频、高效的原子级“动作执行”；而让 MCP 负责标准化、高合规性的“系统连接与数据治理”。将 AI 复杂的系统解耦为“CLI 执行 + MCP 治理”的双层架构，这也许是未来 AI Agent 工程落地的最佳路线。
长按二维码关注 “边学边练”
