别争了，CLI+Skill才是AI工具的未来

如果你最近关注 AI 工具圈，你的信息流大概被这些标题轰炸过：

• “GUI 将死，CLI 才是一切”
• “忘掉 MCP，CLI 才是 AI 连接世界的终极接口”
• “Perplexity CTO：我们不再以 MCP 为主要方向”
• “CLI 之后，人类与 AI 将相忘于江湖”

一边是狂热地摇旗呐喊”CLI 万岁”，一边是 MCP 的支持者反驳”你们根本不懂动态工具发现的价值”。

Twitter 上吵、Hacker News 上吵、知乎上也在吵。

你可能一脸懵：MCP 是啥？CLI 不就是黑乎乎的命令行吗？这有什么好争的？

别急，我花了很长时间跟 AI 反复对话、拆解这些概念，才终于搞明白这场争论的本质。

今天这篇文章，就是把我”搞明白”的过程分享给你——不卖弄术语，只讲人话。

一切的起点：大厂集体”回到终端”

2025 年到 2026 年间，一件反直觉的事情发生了——在大家以为 AI 工具会越来越像 App、越来越可视化的时候，三大 AI 巨头不约而同地发布了”终端里的 AI”：

• Anthropic 发布了 Claude Code，一个运行在终端里的 AI 编程助手
• OpenAI 发布了 Codex CLI，把 GPT 的能力搬到了命令行
• Google 在 2025 年 6 月发布了 Gemini CLI，开源、免费、直接跑在终端里

三家公司，三条赛道，但做了同一个选择：CLI（命令行界面）。

如果只是一家这么干，你可以说是产品策略。三家同时这么干，那就是趋势。

但这还不是最劲爆的。

2026 年 2 月，一个叫 OpenClaw 的开源项目 2 天拿下 10 万 Star。它的作者 Peter Steinberger 公开喊话：

“忘掉 MCP，CLI 才是 AI 连接世界的终极接口。”

2026 年 3 月 11 日，Perplexity 的 CTO Denis Yarats 在 Ask 2026 大会上更是直接宣布：Perplexity 将不再以 Anthropic 的 MCP 作为主要发展方向，转而拥抱 API 和 CLI。他的理由很直接——MCP 的工具描述太吃上下文窗口了，在实际生产中”上下文还没开始干活就被耗光了”。

整个技术圈炸了。

支持方说”早该如此”，反对方说”MCP 的动态工具发现能力被你们忽略了”。双方吵得不可开交，但大多数人其实连这些概念都没搞清楚。

所以，让我们从头捋一遍。

先搞清楚几个概念

在开吵之前，我们得先把这几个概念掰扯明白。我用一个类比来说——假设你是一个老板，AI 是你的助手，你让它帮你在飞书上发个消息。

API：快递员的送货地址

API（Application Programming Interface）就是飞书给外部世界开的一扇门。你想发消息？调这个接口，传这些参数，格式是 JSON，token 放 header 里。

API 是一切的基础。没有 API，其他一切都是空谈。

但问题是，直接调 API 就像让你的助手自己查快递单号、填地址、贴邮票、跑到邮局排队。能干？能干。但费劲——费的是你助手的时间和精力（对应到 AI 就是 Token 和出错率）。

CLI：帮你包装好的一键下单按钮

CLI（Command-Line Interface）是什么呢？有人把飞书的一堆 API 包装成了一个命令行工具，比如 feishu-cli。现在发消息只需要一行：

feishu-cli send --chat "产品群" --text "明天10点开会"


Token 管理、JSON 拼装、错误重试——这些”脏活”全被 CLI 程序处理掉了。AI 只需要想出这一行命令就行。
能用工具干的事，别让 AI 亲自干。 AI 亲自干 = 花 Token + 容易出错。CLI 替 AI 干 = 零 Token 消耗 + 确定性执行。
MCP：AI 工具的标准化插座
MCP（Model Context Protocol）是 Anthropic 在 2024 年底推出的协议。它想解决一个问题：每个工具都有自己的接入方式，AI 要对接 10 个工具就得写 10 套代码。MCP 的愿景是做一个”通用 USB-C 接口”——任何工具只要实现了 MCP 协议，任何 AI 客户端都能即插即用。
听起来很美好，对吧？但魔鬼在细节里。
Skill：AI 的操作手册
Skill 是一个相对新的概念。简单说，它就是一份告诉 AI “怎么用某个工具”的说明书——通常是一个 Markdown 文件，写着命令格式、参数含义、使用示例。
为什么需要它？因为 AI 不是全知全能的。对于 git、curl 这些老牌工具，AI 训练时见过无数次，天然就会用。但对于 feishu-cli 这种新工具，AI 根本不知道它的存在。你不告诉 AI 怎么用，它就不会用。
Skill 就是那份”告诉”。
MCP 模式：先把菜单全背下来
理解了四个概念，我们来看看两种模式的工作方式有什么不同。
MCP 的工作方式是这样的：


AI 启动时，加载所有已注册 MCP 工具的完整描述（工具名、功能说明、所有参数的 Schema、返回格式）


用户提出需求


AI 从已加载的工具列表中选一个合适的


按照预加载的 Schema 构造参数，通过 MCP 协议调用


打个比方：你走进一家有 200 道菜的餐厅，服务员在你坐下的瞬间把完整菜单一字不落地背给你听。从前菜的配料到甜品的做法，全背一遍。然后你说”来碗蛋炒饭”。
问题出在哪？信息加载成本太高了。
Perplexity CTO Denis Yarats 在 Ask 2026 上给出了具体的痛点：

“MCP 的工具定义——包括工具描述、参数 Schema 和返回格式——都需要消耗模型的上下文窗口 Token。对于需要大量工具调用和长对话的 Agent 来说，这种开销会不断叠加，上下文还没开始干活就被耗光了。”

这不是理论问题，是生产环境里的真实痛点。当你只接 3-5 个工具时感觉还行，但当工具数量膨胀到几十上百个——这在企业场景里太常见了——上下文窗口就撑不住了。
CLI 模式：用到什么查什么
CLI 模式的工作方式完全不同：


AI 启动时，不预加载任何工具描述


用户提出需求（比如”帮我在飞书发个消息”）


AI 判断需要用飞书相关的工具


AI 运行 feishu-cli –help，按需获取使用说明


AI 根据帮助信息构造命令并执行


还是那家 200 道菜的餐厅。这次服务员只说了一句”菜单在桌上，想吃什么翻”。你翻到第 3 页，看了蛋炒饭的描述，点了。
核心区别不是 CLI vs MCP，是全量预加载 vs 按需渐进披露。
OpenClaw 作者 Peter Steinberger 观察到一个现象：当 AI Agent 遇到一个新的 CLI 工具时，它会自发地运行 my-tool --help，通过阅读帮助文档在一秒钟内学会操作。CLI 的帮助文档天然就是零噪音、高密度且包含示例的文本——本质上就是一份完美的 Prompt。
这不是巧合。Unix 哲学在 50 年前就确定了 CLI 的设计原则——自描述、可组合、文本输入输出。这些原则和今天 AI Agent 的需求天然契合。
等一下——AI 不认识新工具怎么办？
到这里，有人会说：”好，CLI 很棒，按需查询很棒。但 feishu-cli 不是 git，AI 训练的时候根本没见过它。AI 怎么知道要去运行 feishu-cli --help？它连这个工具叫什么名字都不知道啊！”
这就是 Skill 登场的时刻。
还记得吗？对于 git、docker、curl 这些老牌工具，AI 在训练时已经见过无数次了，天然就会用，零成本。但 feishu-cli 是个新东西——你不告诉 AI，它就不知道。
Skill 文件就是那个”告诉”。它不需要把整个工具的 Schema 全倒出来，只需要说清楚几件事：


这个工具叫什么、干什么


基本的命令格式和常用参数


几个典型的使用示例


当 AI 需要用飞书功能时，它读取 Skill 文件，知道”哦，有个 feishu-cli 可以用”，然后再通过 --help 获取具体的参数细节。
这就是渐进式披露（Progressive Disclosure）的精髓：先给摘要，用到时再给详情。
Anthropic 自己也走了同样的路。2025 年 10 月，Anthropic 推出了 Agent Skill——一种基于文件系统的技能模块，本质上就是包含 SKILL.md 说明文档和可选代码的文件夹。Claude 在会话启动时只加载每个 Skill 的元数据（名称和描述），消耗极少 Token。只有当用户请求匹配某个 Skill 时，才动态加载完整指令。
这和我们上面说的 CLI + Skill 的渐进式披露如出一辙。

IntuitionLabs 在对比 Claude Skills 和 MCP 时，给出了一个精准的定位：Skills 是 AI 的”大脑”——负责知道怎么做；MCP 是 AI 的”手脚”——负责连接外部世界。两者是互补的，不是替代的。

一个活生生的例子：feishu-cli

说了这么多理论，让我们看一个真实的项目。
feishu-cli 是一个个人开发者做的飞书命令行工具（非官方）。它的仓库里有一个 skills/ 目录，包含 11 个技能文件。
完整的工作链路是这样的：
用户："帮我给产品群发个消息说明天 10 点开会"
    ↓
AI 读取 feishu-cli 的 Skill 文件 → 知道有这个工具、怎么用
    ↓
AI 如果需要更多细节 → 运行 feishu-cli send --help
    ↓
AI 构造命令：feishu-cli send --chat "产品群" --text "明天10点开会"
    ↓
CLI 程序在终端执行 → 内部处理 token、JSON、API 调用
    ↓
返回结果："消息已发送"


注意这个流程里的分工：




角色


干了什么


消耗 Token 吗？






Skill 文件


告诉 AI 有这个工具、基本用法


少量（仅元数据）




–help


提供详细参数说明


按需，仅在需要时




AI


理解意图 + 构造一行命令


✅ 但很少




CLI 程序


Token 管理、JSON 拼装、API 调用、错误处理


❌ 零消耗




如果换成”AI 直接调飞书 API”的方式呢？AI 需要自己管理 OAuth token、拼装 JSON body、处理分页、重试失败请求……这些全是确定性的固定逻辑，让 AI 用昂贵的推理能力来干这种”脏活”，是巨大的浪费。
CLI 封装脏活，AI 专注思考。 这才是正确的分工。
CLI + Skill 的渐进式信息流
让我们把整个信息加载过程画出来，和 MCP 做个对比：
MCP 模式的信息流
启动时 → [工具A的完整Schema] + [工具B的完整Schema] + ... + [工具N的完整Schema]
         ↓
      全部塞进上下文（可能消耗数千 Token）
         ↓
      用户提问
         ↓
      AI 从预加载的信息中选择工具


CLI + Skill 模式的信息流
启动时 → [Skill A: 名字+一句话描述] + [Skill B: 名字+一句话描述] + ...
         ↓
      仅加载元数据（几十个 Token）
         ↓
      用户提问："帮我在飞书发消息"
         ↓
      AI 匹配到飞书 Skill → 加载完整 Skill 内容（几百 Token）
         ↓
      需要参数细节 → 运行 feishu-cli send --help（按需）
         ↓
      构造命令，执行


差异一目了然。MCP 是”一次性全给”，CLI + Skill 是”三级渐进式披露”：


第一级：元数据（名字 + 描述）—— 几个 Token


第二级：完整 Skill 内容（用法 + 示例）—— 几百个 Token


第三级：–help 详细参数说明 —— 按需加载


但 MCP 并不是敌人
写到这里，我必须公平地说一句：MCP 并不是错的，它只是在不同的场景里有不同的适用性。
MCP 支持者有一个强有力的反驳：MCP 提供的动态工具发现能力，是硬编码的 CLI 集成无法复制的。MCP 允许 Agent 在运行时发现并使用它事先不知道的工具——这种能力在某些场景下至关重要。
Peter Steinberger 自己也在文章里给出了一个务实的决策树：


只是你自己用？→ 写个 CLI（5 分钟搞定）


需要团队共享？→ 封装成 MCP Server


涉及敏感操作？→ 用 MCP 提供安全沙箱


CLI 是 Agent 的”肌肉”——瞬时、敏捷、原子化的动作。MCP 是 Agent 的”神经系统”——持续、抽象化、可治理的能力连接。两者的关系不是替代，而是分工。
但趋势是明确的：在信息加载效率这件事上，渐进式披露已经赢了。 无论你用 CLI 还是 MCP，”先给摘要，用到再给详情”这个原则都是通用的。
真正的洞察：产品正在为 AI 重新设计
最后，让我们退后一步，看看更大的图景。
CLI 化不仅仅是一个技术趋势，它代表了一个更深层的转变：软件产品正在从”为人类使用而设计”转向”为 AI 使用而设计”。
过去 40 年，软件界面的演进方向是 CLI → GUI → 触屏 → 语音，越来越”人性化”。但现在，当软件的主要使用者从人类变成 AI Agent 时，界面设计需要反过来。
正如腾讯新闻上一篇文章所说的：

“GUI 本质上是为了弥补人类不擅长记忆命令的缺陷而发明的翻译层。而 Agent 天生就说命令行语言。强迫 Agent 去点按钮、拖滑块、填表单，相当于让一个母语是中文的人用英文再转一道。”

CLI-Anything 这个项目更是把这个逻辑推到了极致——它能自动给 GIMP、Blender、OBS 这些 GUI 软件生成 CLI 接口，让 Agent 绕过 GUI 直接与软件底层对话。2 万多 Star，印证了需求的真实性。
CLI 是产品为 AI 使用而设计的重要一步。 而 Skill 是让 AI 高效使用这些 CLI 工具的关键配套——它实现了渐进式披露，让 AI 在有限的上下文窗口里，精准地获取它需要的信息，不多也不少。
总结：给得准比给得多重要
这场争论的本质，不是”CLI vs MCP”，不是”命令行 vs 协议”，而是一个更底层的设计原则之争：
你是一次性把所有信息倒给 AI，还是让 AI 按需、渐进地获取信息？
答案已经很清楚了。在上下文窗口有限的现实约束下，渐进式披露是唯一可扩展的方案。CLI + Skill 恰好是这个原则最自然的工程实现：


CLI 提供能力——封装 API 调用的复杂性，提供简洁的命令接口


Skill 提供说明——告诉 AI 有什么工具可用、怎么用


–help 提供细节——AI 需要时才查询，不浪费一个 Token


三级渐进，各司其职。
当然，这不意味着 MCP 会消亡。在企业级场景、安全治理、多平台工具共享等领域，MCP 的标准化能力仍然不可替代。但信息加载的方式必须进化——不管底层走的是什么协议。
给得准比给得多重要。这是 AI Agent 工程领域里，我越来越确信的一条原则。



END





若觉得内容有帮助，欢迎点赞、推荐、关注。别错过更新，给公众号加个星标★吧！祝您在2026年里天天开心，快乐，身体健康，万事如意！期待与您的下次相遇～😃