Agent时代的路线之争：为什么CLI击败了MCP
核心观点
MCP的衰落不是因为技术不好，而是因为在Agent时代，简洁和高效战胜了规范和抽象。CLI的回归不是倒退，而是对AI本质的重新理解。
一场悄然发生的路线之争
2024年，MCP（Model Context Protocol）横空出世，被誉为AI Agent的"USB接口"。各大厂商纷纷站台，开发者趋之若鹜。那时候的叙事是：需要一个标准化的协议，让AI能够无缝对接各种工具和服务。
2026年初，风向变了。
Scalekit跑了75个基准测试，发现MCP的成本比CLI高出32倍，且有28%的失败率来自连接超时。CircleCI的测试结果类似。
但这还只是冰山一角。
2026年2月，微软发布Playwright CLI，明确建议开发者用它替代Playwright MCP。实测数据显示：Playwright MCP每次测试消耗114,000 tokens，而Playwright CLI只需要27,000 tokens——节省了76%。
2026年3月11日，在Ask 2026大会上，Perplexity CTO Denis Yarats公开宣布：公司正在放弃MCP，转回传统API和CLI。原因是MCP消耗高达72%的上下文窗口，而且认证机制笨重。这距离Anthropic在2025年12月将MCP捐赠给Linux基金会，仅仅过去4个月。
更早之前，OpenClaw创始人Vincent Koc就明确表示：不会支持MCP。这不是懒惰，而是方向性选择。他认为AI agents不会通过分层协议运行，而是直接通过CLI命令。在他看来，MCP是"server to serve a server"——APIs已经是服务器了，为什么还要在外面再包装一层？
这不是一个"技术选型"的故事，而是一个关于"理解AI本质"的故事。
MCP的承诺与困境
MCP的想法很美好：定义一套标准化的JSON Schema，让AI Agent能够以统一的方式调用各种工具。理论上，这意味着：
- 开发者只需要实现一次MCP server
- 所有AI Agent都能自动发现和使用这些工具
- 工具之间可以无缝协作
但现实很骨感。
天生缺陷一：线性上下文成本
MCP的协议模式是：定义一组工具（带有Schema的函数），将其注入Agent的上下文窗口，然后让Agent调用它们。
这种模式可行，但难以为继。
核心问题在于：你添加的每一个MCP工具，都会占用Agent的上下文窗口。包括它的名称、描述、参数Schema和示例。
如果你连接10个服务，每个服务有5个工具，那么在Agent开始执行任何任务之前，你就已经烧掉了数千个token。
据社区开发者反馈，仅加载一个Playwright MCP Server就会占用上下文窗口的8%。在多轮对话中，这会迅速累积，导致成本飙升和推理能力下降。
开发者只能在三种不理想的方案中做选择：
- 构建动态加载机制：引入额外的复杂度
- 限制集成数量：违背了"连接一切"的初衷
- 预加载所有工具：性能下降，成本飙升
天生缺陷二：日常使用的三座大山
如果说上下文成本是理论缺陷，那日常使用中的摩擦才是压垮骆驼的稻草。
初始化地狱
MCP Server经常启动失败。配置文件写错一个逗号、环境变量漏了一个、端口被占用了……结果就是疯狂重启、清空状态、从头再来。
开发者反馈："我以为在用AI提升效率，实际上一半时间在调MCP Server。"
认证疲劳
每个MCP工具都需要单独认证——GitHub要Token、数据库要密码、云服务要Key。而且这些认证还经常失效，需要无休止地重新授权。
权限粗糙
MCP的权限控制非黑即白——要么完全信任Server，要么完全不用。你没法说"我只给你读权限，不给写权限"或者"你只能查这张表，不能查那张表"。
这在企业场景中是不可接受的安全隐患。
天生缺陷三："builder多于user"的危险信号
从MCP发布以来，社区里一直有个尖锐的观察：谈论如何构建MCP server的人，远多于实际使用MCP的人。
这是一个危险信号。当技术圈里"怎么做"的声音超过"为什么做"时，通常意味着方向出了问题。
[!warning] 更讽刺的是，Anthropic自己在工程博客里也承认了这个问题
他们提出的"Code Execution with MCP"方案，让Agent通过写代码而非调用工具来交互，Token使用量从150,000降至2,000，节省了98.7%
等等——Anthropic自己在告诉你：别用标准的MCP工具调用，写代码更高效？
这不是在打自己的脸吗？
CLI的复兴：回归本质
为什么CLI工具在Agent时代复兴了？
LLM的"母语"：命令行
今天的LLM是在数十年累积的Unix文档、Stack Overflow问答、GitHub代码上训练的。它们对CLI工具的理解是"刻在DNA里"的。
这不是比喻，而是字面意义上的事实。
当你让Claude执行gh pr view 123，它就能正常工作。不需要任何schema定义，不需要专门的协议。它知道这是什么，知道怎么用，知道如何解读输出。
而MCP？你需要先定义schema，然后让AI理解这个schema，然后才能开始工作。这是一个额外的、昂贵的、且容易出错的步骤。
调试透明度：输入一致，输出一致
当Claude对Jira执行了一些意料之外的操作时，你可以运行同样的jira issue view命令，并准确地看到它看到了什么。
相同的输入，相同的输出，一切尽在掌握。
而使用MCP时，该工具仅存在于LLM的对话内部。一旦出错，你不得不去翻找复杂的JSON传输日志，而不是自己跑一遍命令。
调试不应该需要协议解码器。
可组合性：Unix哲学的胜利
Unix哲学的核心是：做好一件事，并且能够和其他工具组合。
grep可以和xargs组合，find可以和exec组合，git可以和diff组合。这种组合能力是CLI工具的天然优势。
以分析一个大型Terraform plan为例：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
使用MCP时，你要么把整个plan塞进上下文窗口（成本高昂，而且通常无法实现），要么把自定义过滤逻辑做进MCP服务器本身。
无论哪种，你都是在做更多工作，却得到更差结果。
CLI方法用的是已经存在、文档完善、且人和代理都懂的工具。
认证本来就能正常工作
MCP在身份认证上过于"有主见"。而一个为LLM提供工具的协议，为什么要操心身份认证？
CLI工具就从来不会在意这些。aws用profiles和SSO。gh用gh auth login。kubectl用kubeconfig。
这些都是经过实战检验的认证流程，不论你自己操作，还是用AI驱动，都是同一套。
当认证出问题时，你照常处理：aws sso login、gh auth refresh。不需要任何MCP专属排障。
无需管理额外进程
本地MCP服务器是进程。它们需要启动、保持运行、且不能悄悄卡死。
在Claude Code里，它们作为子进程被拉起，这套机制在"某些时候"可用，直到它不可用为止。
开发者反馈："MCP server启动失败的次数已经数不清了。"
而CLI工具？它们只是磁盘上的二进制文件。没有后台进程，没有要管理的状态，也无需初始化。你需要时它就在，不用时它就不占资源。
速度和可靠性
CLI工具是本地进程，启动快、执行快、输出直接。没有网络延迟，没有JSON序列化/反序列化的开销，没有连接超时的风险。
在Agent场景下，速度就是用户体验，可靠性就是可用性。
CLI才是Agent的"母语"
为什么说CLI才是Agent的母语，而不是MCP？
智能体和人类不同
智能体（Agent）和人类不同，它不需要精美的图形界面（GUI），它需要的是能够被理解的逻辑边界。
CLI恰好提供了这种逻辑边界——明确的输入、明确的输出、明确的行为。
自描述的帮助文档即"自然语言指令"
人类觉得CLI难用，是因为需要记忆命令和参数。但对Agent来说，这根本不是问题。
Agent可以读取--help输出，就像人类读说明书一样。更重要的是，它可以基于这些说明自主推理出如何使用工具。
有开发者让Claude下载了ffmpeg和Blender的源码，然后自己读代码理解那些文档里没写的功能。
这种级别的"自学能力"，确实让MCP的"标准化文档"显得有点多余。
LLM真正擅长的是什么
LLM真正擅长的是什么？靠自己把事情搞清楚。
给它们一个CLI和一份文档，它们就能如鱼得水。MCP承诺提供更简洁的接口，但在实践中，你还是要写同样的文档：每个工具做什么、接收哪些参数、更重要的是，何时使用它。
那为什么不直接让LLM读CLI文档呢？
最好的工具总是双用的
一个深刻的洞察：最好的工具总是既能为人所用，又能被机器高效处理的。
CLI就是这样。人类可以用它，Agent也可以用它。而且用的方式是一样的。
而MCP？它只为了Agent而存在。这意味着你需要维护两套系统：一套给人类用（GUI、CLI），一套给Agent用（MCP）。
这是重复劳动，是技术债，是不必要的复杂度。
三大转折：MCP溃败的2026年春天
2026年2月到3月，短短一个月内，发生了三件事，彻底改变了MCP的命运。
微软的转向：Playwright CLI取代MCP
微软在2026年2月推出Playwright CLI，建议开发者用它替代Playwright MCP。数据很直观：
- Playwright MCP：114,000 tokens/次
- Playwright CLI：27,000 tokens/次
节省了76%的token消耗。更重要的是，Playwright CLI将浏览器状态保存到磁盘，让AI按需读取，而不是把所有信息都塞进上下文窗口。
来源：微软Playwright CLI GitHub报告，2026年2月
Perplexity的公开声明：72%上下文浪费
2026年3月11日，Perplexity CTO Denis Yarats在Ask 2026大会上公开表示：公司正在放弃MCP，转回传统API和CLI。
核心原因：
- MCP消耗高达72%的上下文窗口
- 认证机制笨重且不安全
- stdio transport在生产环境完全失效
来源：Perplexity Ask 2026大会，2026年3月11日
OpenClaw的拒绝：从设计之初就不支持
OpenClaw是2026年最火的AI Agent框架，GitHub上32万+stars。但它的创始人peter从一开始就拒绝支持MCP。
当被问及原因时，他说：这不是懒惰，而是方向。他相信AI agents不会通过分层协议运行，而是直接通过CLI命令。在他看来，MCP是冗余的抽象——APIs已经是服务器了，为什么还要在外面再包装一层？
来源：OpenClaw GitHub Issue #13248，2026年2月
技术趋势的钟摆
这不是第一次发生这样的故事。
2000年代，SOAP协议试图统一Web服务，但RESTful API以其简洁性最终胜出。
2010年代，微服务架构兴起，大家追求"大一统"的服务网格，但后来又开始回归到"足够简单"的解决方案。
现在，MCP vs CLI的故事，是同一钟摆的又一次摆动。
技术趋势不是线性的，而是循环的。每次循环，我们都学到一些东西，但也容易忘记之前的教训。
未来的方向：务实主义
那么，MCP真的死了吗？
不一定。但它的定位需要重新思考。
MCP适合的场景
- 需要结构化数据交换的场景
- 需要实时流式数据传输的场景
- 需要动态工具发现的场景
- 企业环境中的安全控制和权限管理
CLI适合的场景
- 绝大多数Agent自动化场景
- 需要快速迭代和原型开发的场景
- 对成本和性能敏感的场景
- 需要工具组合和管道操作的场景
混合架构可能是终局
未来的Agent基础设施，很可能是一个混合架构：用CLI处理大部分任务，用MCP处理特定的、需要标准化的场景。
但核心原则应该是：能用CLI的，绝不用MCP。
给开发者的建议
如果你正在构建Agent相关的产品：
- 优先考虑CLI工具：它们更快、更便宜、更可靠
- 谨慎引入MCP：只在真正需要标准化的场景下使用
- 关注token效率：每个额外的抽象层都有成本
- 保持简单：不要为了"标准化"而牺牲实际价值
- 善用现有工具：不要重新发明轮子，CLI已经很好用了
结语：务实的胜利
MCP的衰落，CLI的复兴，本质上是一次务实的胜利。
它提醒我们：在AI时代，最重要的不是构建最完美的抽象层，而是理解AI的本质，让它做它最擅长的事。
AI不是传统的软件系统，不能用传统的思维方式来构建。它需要新的范式，而这个范式，很可能比我们想象的要简单得多。
正如Eric Holmes在Hacker News的那篇文章标题所说："MCP is dead. Long live the CLI."
这不是倒退，而是前进。是回归本质，是去繁就简。
[!tip] 技术趋势的本质不是追逐最新最热，而是理解问题的本质，选择最合适的工具。
