AI时代的接口标准之战已悄然打响！MCP与CLI两种协议的较量不仅关乎技术路线，更揭示了人类工程思维与AI本能的深层冲突。当Schema注入导致MCP效率瓶颈日益凸显，CLI却凭借零成本优势成为AI的"母语"。Skill文档的兴起更是直接动摇了MCP的根基，而CLI-Anything与OpenCLI等开源项目正在将这场革命从概念变为现实。

一、两种接口的兴衰，一个时代的转折

2024 年，Anthropic 搞出了一个东西叫 MCP，全称 Model Context Protocol。当时整个 AI 圈的反应是——这玩意儿就是 AI 时代的 USB 接口，以后所有工具都能插进来。

说实话，这个比喻确实很好理解。USB 出来之前，各种设备接口一团糟，鼠标是鼠标的口，键盘是键盘的口，打印机又是另一套。USB 统一了这一切。MCP 的逻辑是一样的——以前 Claude 连 GitHub 要一套代码，连 Slack 又要另一套，现在都走 MCP，谁想接就接，标准统一了。

结果到了 2025 年，MCP Server 在 GitHub 上突破了 5000 个，Cursor、Windsurf、Claude Desktop 全部接入，行业里几乎形成了一个共识：不上 MCP，你就是落后。

但就在大家都在抢着接 MCP 的时候，2026 年 3 月，Perplexity 的 CTO Denis Yarats 公开说，他们放弃 MCP，转向 CLI。

这句话在圈子里引发了不小的争议。因为 Perplexity 不是小公司，它是全球访问量前十的 AI 产品，有 1.8 亿用户，CTO 说这句话不是随便说说的。

然后是 Andrej Karpathy——前 Tesla AI 总监，OpenAI 联合创始人，AI 领域最顶尖的工程师之一，他说了这样一句话：

“AI agents can natively and easily use them（CLI tools）. LLMs have processed vast amounts of CLI documentation, man pages, and shell scripts during training.”

— Andrej Karpathy，2026

翻译过来就是：CLI 工具，AI 天生就会用，因为 AI 在训练的时候，就把全世界几十年积累的 CLI 文档、手册、脚本全部消化掉了。

这句话说到了核心。CLI 不是 AI 的工具选项，CLI 是 AI 的母语。MCP 是我们用人类的工程习惯，强行给 AI 套了一个外壳。从这个意义上说，MCP 作为 AI Agent 接口的主流范式，已经走到了拐点。

核心判断#1

接口之争的本质，是人类思维习惯和 AI 本能之间的冲突。MCP 是前者，CLI 是后者。

二、MCP 的问题，到底出在哪里

先说清楚一件事：MCP 不是没有价值的东西。

MCP 真正解决了一个问题，就是让不同的 AI 工具能对接同一套服务。有了 MCP，写一个 GitHub MCP Server，所有 AI 工具都能直接用，不需要重复开发。在企业级场景里，MCP 还有原生的权限控制机制——多用户、多租户，各自有各自的访问权限，在协议层就能处理，不需要开发者自己搭一套复杂的授权体系。

MCP 的本质是一套治理协议，它解决的是”谁有权做什么”，而不是”怎么做最快”。这两件事本来就是两回事。

问题就出在这里——大多数人根本不需要那套企业级权限管理，但却在为它的全部成本买单。

MCP 的先天缺陷：Schema 注入

MCP 有一个先天的设计缺陷，叫做Schema 注入。每次 AI 调用 MCP 工具时，它会把这个 Server 上所有工具的”说明书”全部塞进对话上下文里，哪怕你只需要用其中一个。

举个例子：GitHub 的 MCP Server 有 43 个工具。你现在只想问它一件事——这个仓库用的是什么编程语言？AI 要回答这个问题，必须先把另外 42 个工具的说明书全读一遍，什么创建 Gist 的方法、管理 Webhook 的方法、配置 PR Review 的方法，一个都不能少。

这不是 bug，是协议设计决定的。标准化的代价，就是永远要携带全套行李，哪怕你只出门买个包子。

数据对比：CLI vs MCP

ScaleKit 团队做了 75 次基准测试，对比 CLI 和 MCP 完成同样任务的消耗：

不只是贵。MCP 还不稳定——CLI 在本地执行，成功率 100%；MCP 连接远程服务器，25 次测试里有 7 次因 TCP 超时直接失败，成功率只有 72%。

核心判断#2

MCP 的问题不是”贵”，而是贵得没有道理。更深的隐患是：AI Agent 越强，单次任务调用工具次数越多，MCP 的 Schema 注入成本就越高——这是一个随 AI 能力增长而持续恶化的结构性缺陷。

三、CLI 是什么，为什么 AI 天生就懂它

可能很多人听到 CLI，第一反应是——那不是那个黑框框，要打命令的东西吗？对，就是那个东西。但它和 AI 的关系，可能比你想象的要深得多。

CLI 的历史：从未消亡的底层语言

CLI 是软件世界的”拉丁文”——普通人看不懂，但一切都在用它。

CLI vs GUI：本质区别

为什么 AI 天生懂 CLI

LLM 在训练时，消化了全球几十年积累的 CLI 文档、man page、shell 脚本、GitHub README、Stack Overflow 命令示例——CLI 语法和常用工具的用法，AI 早就通过训练内化成了直觉，不需要任何人再重新教它。

AI 调用gh repo view查 GitHub 仓库信息，就像一个有经验的工程师直接打命令一样，是本能，不是查文档。而 MCP 的 Schema 注入，某种程度上是在对 AI 说”你先把这 43 页说明书读完，再开始工作”——对一个本来就知道怎么做的人来说，这是浪费，甚至是一种冒犯。

核心判断

CLI 的零成本优势，不是工程优化的结果，而是 LLM 训练数据天然内化的体现。AI 懂 CLI，是因为 CLI 本来就是 AI 训练语料的一部分。

四、Skill 出现了，MCP 的最后理由也没了

说到这里，可能有人会问：CLI 效率确实高，但 AI 对一些冷门工具或特殊场景，掌握深度够吗？万一走了弯路怎么办？

这是 CLI 真实存在的一个弱点。MCP 的拥护者也正是拿这一点来说事：Schema 提供了标准化引导，告诉 AI 这个工具有哪些功能可以用。

然后Skill 出现了。

什么是 Skill

Skill = 一份精心设计的领域使用文档（通常 500-1000 Token），里面写的是：这个工具最重要的几个用法是什么，常用参数有哪些，输出结果怎么格式化。

• 不是接口定义

• 不是 Schema

• ✅ 就是人话——把一个有经验的工程师对这个工具的理解，压缩成一份简短的说明交给 AI

本质上，Skill 是把人类的专家经验，以最低成本的方式传递给 AI。

Skill vs MCP：成本对比

核心判断#4

Skill 用 1/50 的成本，做到了 MCP Schema 同样的事，甚至做得更精准。

当 Skill 生态成熟，MCP 的工程价值空间被压缩到唯一一个场景：多租户企业级授权管理。而这，恰恰是绝大多数人根本碰不到的场景。

五、软件世界正在被重写

聊到这里，我想说一个更大的判断。

我们现在讨论 MCP 和 CLI，好像只是在讨论两种技术接口的优劣。但我认为，这背后有一个更根本的变化正在发生——AI 正在重新定义软件存在的意义。

应用软件为什么存在

本质上，整个应用软件行业解决的都是同一个问题——让不懂 CLI、不懂编程的人，也能使用计算机底层的能力。GUI 是给人类看的，CLI 是给机器用的，应用软件是这两者之间的那层翻译。

当 AI 出现，翻译层失去意义

当 AI 成为新的人机交互入口：

• 用户不再需要学软件界面，只需用自然语言说”我要做什么”
•  AI 通过 CLI 直接调用底层工具能力，跳过 GUI 这一层
• 你说”帮我把这段视频剪掉前三秒，加字幕，导出 1080p”，AI 调用ffmpeg和whisper，完成，全程不需要打开任何软件

这个模型的终点是：一个 AI 入口 + 无数 CLI 化的软件能力。用户和 AI 对话，AI 在底层编排一切。软件作为独立”入口”的意义，正在消失。

谁会消失，谁能存活

核心判断#5

CLI 化的本质，是 AI 对软件世界的”去中间化”。未来软件公司的核心竞争力，将从”界面好不好用”转移到”CLI 接口稳不稳定、数据独不独特”。

没有 CLI 接口的软件，在 AI 时代等于主动放弃接入资格。

六、已经有人在做了：CLI-Anything 与 OpenCLI

说了这么多趋势判断，来看两个真实在发生的开源项目。它们正在把”CLI 化软件世界”这件事从概念变成现实。

CLI-Anything：让桌面软件全面 CLI 化

项目方：香港大学 DS 实验室核心定位：让任何桌面软件都能被 AI Agent 通过命令行驱动

核心机制：

• 为每个软件构建标准化 CLI 层（JSON 输出 + REPL 交互 +–help自描述）
• 自动生成 Skill 文档（HARNESS.md），供 Claude Code、Codex 一键加载
• 1,774 个测试用例，通过率 100%

已支持软件矩阵：

OpenCLI：让 Web 应用和网站全面 CLI 化

项目数据：GitHub 18,400 Stars ｜ 1,800 Forks ｜ 166 位贡献者 ｜ 持续更新中

核心定位：把任何网站、任何 Electron 桌面应用、任何本地工具，统一转化成可被 AI Agent 调用的 CLI 接口

三大核心能力：

LLM Token 消耗：0

核心判断#6

CLI-Anything 证明桌面软件世界可以被系统性 CLI 化；OpenCLI 证明 Web 应用世界同样可以被系统性 CLI 化。

两个项目合力说明——AI Agent 的统一软件操控层，不是未来的设想，是正在建设中的基础设施。

七、实战案例：用 Playwright CLI 做浏览器自动化

来给大家示范一个完整的 CLI 化实践案例：用 Playwright CLI 实现浏览器自动化，运行时额外 Token 消耗接近 0。

对比参考：Playwright MCP 版本每次调用携带完整 Schema，Token 消耗是 CLI 版本的4 倍以上。

第一步：安装（两行命令）

npm install -g playwright-cli

playwright-cli install –skills skills # 自动为 AI Agent 加载 Skill

第二条命令是关键——–skills把这个工具的使用经验一次性传递给 AI，整个会话内都有效，不需要重复注入。

第二步：三个最常用操作

# 网页截图

playwright-cli screenshot https://example.com output.png

# 打开网页，复用浏览器登录态（无需重新输密码）

playwright-cli open https://xiaohongshu.com –persistent

# 提取网页结构化数据，直接输出 CSV

playwright-cli open https://news.ycombinator.com –headed –extract-csv

–persistent参数：AI 直接复用你浏览器里的登录状态，账号密码不经过任何第三方程序，安全和便利都顾到了。

第三步：完整自动化场景

任务：批量采集 100 个网页的标题、正文、发布时间，输出 CSV

AI 执行链路：

打开目标网页 → DOM 结构解析 → 定位关键字段 → 结构化提取 → 写入 CSV → 迭代下一个 URL

实测结果：

• 全程额外 Token 消耗为 0（Skill 已预加载）
• Claude Code、Codex 均可直接驱动
• Windows PowerShell 原生支持，无需配置 Linux 环境

可实现的完整功能清单

• 内容监控：新闻热榜、电商价格变化、社媒动态追踪
• 自动化测试：Web 应用功能测试、回归测试
• 批量操作：表单提交、数据录入、页面交互
• AI 内容理解：网页摘要生成、关键信息提取
• 生态扩展：配合 OpenCLI 的 90+ 适配器，覆盖大多数 Web 自动化场景

八、从 CLI 看 AI 时代的五个趋势判断

最后，说五个我个人认为比较确定的方向，不一定全对，但值得长期关注。

趋势 ① 接口层将全面重构

未来几年，一个软件没有 CLI 接口，在 AI 生态里的接入资格会越来越低。

CLI 会成为软件能否被 AI 调用的基础门槛，就像今天一个产品没有 API 会被认为不完整一样。

趋势 ② MCP 将收缩至企业级场景

多租户企业 SaaS、金融合规、政府系统——这些场景真的需要 MCP 的授权体系，MCP 会在这里继续存在。

但对大多数开发者和产品来说，CLI + Skill 将成为主流，MCP 的适用边界会越来越清晰。

趋势 ③ Skill 工程是被严重低估的价值点

给特定工具或场景写高质量 Skill 文档，现在几乎没人在认真做。

当 CLI 化浪潮来临，谁手里有高质量 Skill 库，谁就有先发优势。这是一个投入极低、回报极高、目前几乎没有竞争的方向。

趋势 ④ 软件护城河从 UI 转移到数据与网络效应

以前说护城河是功能差异、用户体验，未来这些会被 AI 快速追平。

真正的护城河是不可替代的数据，和深度绑定用户的网络效应。没有这两样，只靠功能设计的产品，压力会越来越大。

趋势 ⑤ 这是一场软件层的基础设施革命

就像移动互联网刚起来时，大家觉得 App 是个新东西，却没预料到它会把整个 PC 端软件行业重新洗一遍。

CLI 化正在做的事情，规模和深度不亚于那一次。

OpenCLI 的 18,400 个 Star 和 CLI-Anything 的 1,774 个测试用例，在这场革命的时间轴上，可能只是非常早期的注脚。

但注脚，往往是最值得关注的地方。