书边客

最近圈子里流传着一句话："MCP 已死，CLI 永存"。从 MCP 发布时的全民狂欢，到短短几个月后风向急转，这场争论其实比表面上看更有意思。

我梳理了国内外 Reddit 和博客上的核心论点，结合自己在 OpenClaw 中实践的 "Skills" 架构，聊聊这个话题。

一、MCP 真的过度设计了吗？

MCP（Model Context Protocol）是 Anthropic 推出的一个标准化协议，旨在让 LLM 能够通过统一接口对接各种工具和数据源。刚出来的时候，整个行业都沸腾了——仿佛一夜之间，所有 AI 应用都必须支持 MCP 才够 "AI First"。

但现实给了当头一棒。Erik Holmes 在《MCP is dead. Long live the CLI》中说得很直白：

MCP 承诺了更干净的接口，但实践中我发现自己还是要写一遍文档——每个工具做什么，接受什么参数，什么时候该用它。LLM 根本不需要一个新协议。

我认同这个观点的核心：MCP 在大多数场景下确实不够简洁，不够高效。

几个实际痛点：

上下文膨胀——MCP 服务器一启动就把十几个甚至几十个工具全部扔到上下文里，不管你用不用。Token 就这么白白浪费了。
调试困难——MCP 工具只存在于 LLM 对话中，出了问题你不能像 CLI 那样自己跑一遍看看输入输出，只能去扒 JSON 传输日志。
认证重复造轮子——CLI 工具根本不需要操心认证：aws 用 profiles 和 SSO，gh 用 gh auth login，kubectl 用 kubeconfig。这些久经考验的认证流程不管是人用还是 Agent 用都一样，坏了按照老方法修就行，不需要 MCP 特定的排障。
无法组合——CLI 天生支持组合：terraform show -json plan.out | jq '[...] | length'。放到 MCP 里，要么你把整个计划 dump 进上下文（昂贵，经常不可能），要么你得在 MCP 服务端里定制过滤逻辑。怎么选都是更差的结果。

说白了，MCP 试图构建一个更好的抽象，但我们已经有了一个久经考验的抽象——那就是 CLI。

"CLI 永存"这句话我是认同的。CLI 大道至简，符合 Unix 哲学：做一件事，把它做好，可以和其他工具组合。

LLM 其实非常擅长使用 CLI。它见过数百万个 man 页面、Stack Overflow 回答、GitHub 仓库里的 shell 脚本。你告诉 Claude 用 gh pr view 123，它直接就能用，根本不需要额外学习。

而且 CLI 对人类友好。Agent 操作错了，你登上去敲同样的命令就能看到一模一样的结果，debug 起来行云流水。这一点 MCP 比不了。

但 CLI 也不是银弹，它有自己的局限性：

对于自定义、非通用的 CLI 工具，LLM 其实并不天生会用。

如果是 grep/jq/aws 这种训练数据里充斥着海量例子的工具，没问题。但如果你写了一个自己的 ./scripts/daily-portfolio-analysis.sh，LLM 怎么知道什么时候该调用它？参数有哪些？边界条件是什么？

你还是得写文档，还是得告诉 LLM。这时候，CLi 并没有比 MCP 节省多少上下文，只是把 schema 从结构化的 JSON 变成了 --help 文本而已。本质上，你还是在描述工具接口。

另外，对于企业级多用户场景，CLI 确实解决不了认证和权限的问题。如果每个开发者都需要在本地安装一堆 CLI 工具，配置一堆密钥，运维起来就是一场灾难。权限也无法细粒度控制，密钥一旦泄露就是全权限，没法做到只读这种范围。

所以说，MCP 不是完全没用——它在中心化、企业级场景下还是有价值的，这一点 Charlie Schnier 在《MCP is Dead; Long Live MCP!》中讲得很清楚：远程 MCP 服务带来了中心化的可观测性、统一认证、权限审计、动态更新，这些对于企业来说都是实实在在的价值。

在 OpenClaw 的实践中，我们走的既不是纯 MCP 也不是纯 CLI，而是 Skills 架构——每个技能是一个独立模块，带有 SKILL.md 描述、明确的输入输出约定，按需加载。

我认为这是目前单体/个人开发场景下的最佳平衡：

按需加载，不浪费上下文——你不用把所有工具都塞给 LLM，需要哪个技能才加载哪个技能的描述。这解决了 MCP 最大的痛点——上下文膨胀。
结构化描述，但保持简洁——SKILL.md 用人类可读的markdown描述清楚：做什么的、什么时候用、参数有哪些。既不像 MCP 那样全量schema带来膨胀，也不像纯 CLI 那样全靠 LLM 自己从 --help 里摸索。
兼容 CLI——Skill 可以简单包装一下现有的 CLI 工具，不用重复造轮子。比如日常量化分析脚本本身就是一个 CLI 工具，Skill 只需要薄薄一层描述就够了。
人类可理解——SKILL.md 既是给 LLM 看的，也是给人看的。新人接手，一看就知道这个技能干什么用，怎么改。

但我也不认为 Skills 就是终点。

目前 Skills 的讨论中，有一个误区需要澄清：说 "Skills 没法中心化分发"其实不准确——现在已经出现了像腾讯 SkillHub 这样的中心化技能平台，社区共享技能、按需拉取，这条路已经走通了。

真正的问题不在于能不能中心化，而在于中心化 skill 平台能否真正形成生态。平台需要解决发现、评级、权限、版本更新等一系列问题，这需要时间验证，现在下结论还太早。

对于大型组织，权限审计、统一分发这些场景，确实还是中心化 MCP 更适合。另外，Skills 描述目前还是以自然语言为主，相比 MCP 的结构化 schema，不那么严谨。

所以我认为未来一段时间的格局会是：

这场争论本质上不是 "MCP vs CLI"，而是 "复杂企业级场景 vs 简单个人开发场景" 的不同需求。

如果你是一个人或者小团队干活，相信我，MCP 过度设计了，CLI + Skills 足够好用。大道至简，符合 Unix 哲学，Debug 方便，Token 不浪费。
如果你是大型企业，需要统一管控、权限审计、可观测性，MCP 还是有价值的，特别是 HTTP 模式的远程 MCP 服务，解决了很多 CLI 解决不了的问题。

而 OpenClaw 走的 Skills 路线，其实就是在这两者之间取了一个平衡——对个人开发者友好，保持简洁高效，同时兼容生态化的技能分发。

MCP 不会真的死掉，CLI 也不会被取代。未来一段时间，会是 Skills + CLI 占主角，MCP 保有一席之地的格局。它们只是适合不同的场景罢了。

最后，用一句话总结：

好工具从来不是消灭旧工具，而是在工具箱里多添一把。什么时候用什么，取决于你面对什么问题。

本文基于当前社区讨论整理，观点仅代表个人。你在使用 MCP 还是 CLI？欢迎留言交流。