最近 AI Agent 圈里有个很热的争论：为什么越来越多人不再把 MCP 当默认答案，而是重新回到 CLI？
这个话题之所以突然火起来，一方面是因为 Perplexity CTO Denis Yarats 在 2026 年 3 月的 Ask 2026 上公开说，Perplexity 内部正在从 MCP 转向 API 和 CLI；另一方面，Y Combinator 的 Garry Tan 也在 X 上很直白地吐槽过 MCP，说它吃上下文、鉴权麻烦，自己干脆 30 分钟写了个 Playwright 的 CLI wrapper。Junia、Garry Tan 原帖
于是很多人顺手就把结论写成了：
MCP 不行了，CLI 才是未来。
但真把这件事拆开看，会发现这个结论其实有点太快了。
更准确的说法不是“MCP 被抛弃了”，而是：在编码型 Agent 这类高频、强执行、强上下文压力的场景里，CLI 这套老办法突然显得比 MCP 更顺手；可一旦你进入跨组织、代用户操作、需要 OAuth、审计和治理的场景，MCP 又会重新变得重要。
所以这不是一场谁把谁彻底打死的战争，而是一次很典型的“场景错配”被公开放大的过程。
一、先把概念说清楚：MCP 和 CLI 根本不是一类东西
很多讨论一开始就错在这里。
MCP，全称 Model Context Protocol，是 Anthropic 在 2024 年 11 月公开推出的开放标准。Anthropic 官方把它比作“AI 应用的 USB-C 接口”：目标是让 AI 应用通过统一协议去连接工具、资源和工作流，而不是每接一个系统就重写一套私有集成。它的核心机制包括 JSON-RPC、状态化连接、能力协商，以及 tools / resources / prompts 等原语。Anthropic、MCP 规范
CLI 则完全不是协议，它是交互方式。说白了，就是让 Agent 直接调用 Shell 命令和现有命令行工具去做事。比如 git、gh、curl、psql、kubectl、playwright 这一整套世界，本来就已经存在。Agent 只是接过了键盘。
所以两者的差别不只是“一个新，一个老”，而是：
- MCP 解决的是标准化接入
- CLI 解决的是直接执行
这两个问题并不等价。也正因为不等价，才会出现今天这种看上去互相替代、实际却经常并存的局面。
二、原文抓到了真实问题，但有几处写得太满了
你给的原文不是完全站不住，它其实抓到了 MCP 在现实落地中最容易被吐槽的几个点：上下文开销、调试复杂、在 coding agent 场景里不如 CLI 顺手。这些都是真问题。
但它有三类典型的问题。
1. 把“局部趋势”写成了“行业定论”
Perplexity 的 CTO 确实公开表示过他们内部正在从 MCP 转向 API 和 CLI；Garry Tan 也确实公开吐槽了 MCP，并说自己用 CLI wrapper 更舒服。可这说明的是：一批做 coding agent 和开发者工具的人，正在重新评估 MCP 在自己场景里的性价比。
这并不等于“行业正在集体抛弃 MCP”。
事实上，Anthropic 官方在 2025 年 11 月的工程文章里还明确写过：MCP 自 2024 年发布以来采用速度很快，社区已经构建了成千上万的 MCP servers，主流语言有 SDK，行业里很多工具和平台仍在把它当成事实上的标准连接层。你可以不同意这个判断，但至少它说明：MCP 并没有进入“只剩余温”的状态。 Anthropic Engineering
2. 把特定 benchmark 写成了普遍真理
原文里最扎眼的数据，是“CLI 比 MCP 便宜 10 到 32 倍”“同样查语言构成，1365 token 对 44026 token”。这些数字不是凭空编的，它们来自 2026 年 3 月 Scalekit 那篇很出圈的 benchmark。
但这组 benchmark 的前提非常具体：
- 同一个模型：Claude Sonnet 4
- 同样的任务：5 个只读 GitHub 任务
- 同样的对象：
anthropics/anthropic-sdk-python - MCP 端接的是 GitHub 的 Copilot MCP server，而且会一次性暴露 43 个工具 schema
在这个设定下，CLI 的确更便宜也更稳；Scalekit 自己的结论也是 MCP 在这组测试里 4–32 倍更贵，CLI 100% 成功率，而 MCP 是 72%。但同一篇文章也明确说了：如果你是在构建“代表别的用户去执行操作”的产品，而不是自动化你自己的开发流程，CLI 的效率优势会变成治理层面的负担。 Scalekit
换句话说，这组数据很有参考价值，但它证明的是：
在特定 coding-agent 任务里，CLI 可能显著比某种 MCP 接法更省 token。
它并不能直接推出：
MCP 在所有场景下都不划算。
3. 把实现问题说成了“协议原罪”
原文最容易误导人的一句，是“MCP 的设计从根本上违背了 AI Agent 的真实使用需求”。这话就说太重了。
MCP 确实会带来 schema 注入、上下文膨胀、鉴权复杂、调试链路变长这些现实问题；但其中有不少问题，和“你怎么实现 MCP”关系很大，而不是协议本身就无可救药。
比如 Scalekit 自己就提到，schema bloat 的一个重要缓解方案是 gateway 层做 schema filtering，只把当前请求真正相关的 2–3 个工具返回给 agent，而不是把 43 个工具全塞进去。再比如，MCP 社区这两年一直在补授权体系：规范要求 OAuth 2.1，文档里有完整的 Protected Resource Metadata、Auth Server Discovery 流程；同时又新增了 OAuth Client Credentials 扩展，专门处理“没有用户在场的自动化系统”该怎么连 MCP server 的问题。Authorization 教程、OAuth Client Credentials 扩展
这恰恰说明：MCP 的问题不是没人看见，而是协议正在从“理想的标准化连接层”往“能在生产里用的连接层”慢慢补课。
三、那 CLI 为什么偏偏在今天显得这么香？
这里我反而觉得原文的方向是对的：在 coding agent 场景里，CLI 这波回潮不是偶然。
1. CLI 和“开发者世界”天然同构
很多工具在开发者生态里，本来就先有 CLI。git、gh、docker、kubectl、curl、sqlite3、psql……这些东西不是为了 AI 发明的，它们本来就是工程系统的一部分。
这意味着 Agent 一旦能用 Shell，它不是在“接一个协议”，而是在“接整个开发者世界”。对 coding agent 来说，这个起点太高了。
2. CLI 更适合按需暴露，而不是预先铺满上下文
这是当前 debate 的真正核心。
MCP 的理想是标准化 discovery，但在很多实现里，这个 discovery 的代价是：先把大量工具 schema 摆到模型面前。对办公助手或跨 SaaS 调用来说，这可能还值得；可对一个正在改代码、跑测试、查日志的 agent 来说，很多时候它真正需要的只是几个短小命令。
CLI 的好处就是，它天然支持“我需要的时候再问”。Agent 不一定要在第一轮就知道所有参数，只要能跑 --help、看错误输出、尝试再修正，它就能用一种更贴近开发者的方法把事做下去。
3. CLI 的可调试性太强了
这是很多人嘴上不常说，但真正离不开的一点。
CLI 出错时，你至少能直接看到命令、stderr、退出码、重试过程；而 MCP 一旦出问题，往往会把错误拆到协议层、传输层、授权层、server 实现层，定位路径明显更长。
对于个人开发者和内部小团队来说，这一点的实际影响，常常比“架构是否优雅”更大。
4. CLI 符合编码 Agent 的任务形态
现在最强的 Agent 落点，仍然高度集中在 coding workflow：读仓库、改文件、跑测试、查依赖、看日志、开 PR。这类任务的共同特点是：
- 本地环境多
- 命令链短而频繁
- 对实时反馈依赖大
- 工具组合很碎
CLI 天生适合这种“小步快跑、边执行边纠偏”的节奏。MCP 不是不能做，但在这类场景里，它经常显得更重。
四、那 MCP 到底还有没有价值？
有，而且是很明确的价值。
如果只看个人 coding agent 场景，CLI 今天确实更像赢家；但一旦换到下面这些场景，MCP 的意义就会重新冒出来。
1. 你不是在替自己干活，而是在替“别的用户”干活
这是分水岭。
如果 Agent 操作的是你自己的本地仓库、你自己的 GitHub、你自己的 shell 环境，那 CLI 非常合理。可如果 Agent 要去读客户的 Jira、改客户的 Slack、操作客户的 SaaS 资源，那“把一把 CLI 凭证交给 agent”这件事很快就会变得难以治理。
Scalekit 那篇 benchmark 最值得看的，其实不是前半段“CLI 更省”，而是后半段那句：当你的 agent 开始代表别的用户行动时，CLI 的 ambient credentials 会变成架构负担。 Scalekit
2. 你需要标准化 discovery、OAuth、审计和权限边界
MCP 官方文档把这些场景写得很明确：当 server 涉及用户数据、管理员操作、审计、按用户限流或企业级访问控制时，授权强烈建议开启；而且远程 MCP server 的标准授权流本来就是围绕 OAuth 2.1 构建的。MCP 授权文档
CLI 当然也能自己做权限系统，但那意味着你要一层层自己补。MCP 的价值，恰恰是把这些问题从“每个团队各写一套”变成“协议层有统一做法”。
3. 你在做的不是一个编码助手，而是一个平台
这是另一个经常被忽略的点。
CLI 对个人和内部工具特别友好，但对平台型产品不一定友好。因为平台追求的是可复用、可治理、可审计、可接第三方，而不是“我本地这套脚本非常顺”。
从这个角度看，MCP 最大的价值从来不是最省 token，而是最省“生态碎片化”。
五、给新手一个更实用的判断框架
如果现在正好在选型，我觉得不用先问“站哪一边”，而是先问自己四个问题。
第一，你的 Agent 主要是在写代码，还是在跨系统办事？
偏写代码、跑命令、改仓库，CLI 往往更顺。
偏跨系统、跨 SaaS、跨用户权限，MCP 往往更值钱。
第二，它是在替你做事，还是替你的用户做事？
替自己做事，CLI-first 很合理。
替用户做事，就要开始认真想 OAuth、审计、租户隔离和授权边界了。
第三，你最缺的是“低成本执行”，还是“统一接入与治理”？
缺前者，CLI 更香。
缺后者，MCP 仍然是少数真正往这个方向系统化推进的标准。
第四，你要的是“今天能跑”，还是“以后能扩”?
CLI 的优势很大程度上在今天。
MCP 的优势很大程度上在以后——尤其是当接入系统、身份治理、工具共享开始复杂化的时候。
六、最后的判断：真正发生的，不是 MCP 死了，而是默认答案变了
如果只让我给一句结论，我会这么写：
MCP 没死，但它不再适合被当成一切 Agent 的默认起点；CLI 也没有赢到可以一统天下，但它已经重新成为 coding agent 的默认偏好。
这才是 2026 年这波讨论真正说明的问题。
Perplexity 的选择、Garry Tan 的吐槽、Scalekit 的 benchmark，它们都不该被理解成“给 MCP 盖棺定论”，而更像是在提醒整个行业：
标准化连接层很重要，但如果它在高频执行场景里太重，开发者就会毫不犹豫地退回更轻、更直接、更能调试的旧世界。
所以未来更可能出现的，不是 CLI 完全取代 MCP，而是更清晰的分工：
- 编码型、个人型、内部自动化：CLI-first
- 跨组织、代用户执行、强调治理与审计：MCP 或 MCP + gateway
- 高成本 schema 场景：继续往按需暴露、schema filtering、混合架构方向优化
真正值得学到的，不是“谁赢了”，而是以后别再把一个协议，当成所有场景的万能钥匙。
评论