Agent 时代我们为什么都在做 CLI——从食材、预制菜到菜谱的三层能力栈

过去 12 个月，所有主流 AI 编程助手都做了同一件事：把交互入口收回命令行。Cursor 出了 CLI，Anthropic 的 Claude Code 是一开始就 CLI first，连 OpenAI 的 Codex 都悄悄把 CLI 摆到 IDE 前面。

看起来像一次"复古回归"。但任何把这件事当怀旧的人，都错过了真正的问题。

2026 年 7 月 6 日，腾讯工程师郭小成写了一篇刷屏文《为什么 Agent 时代，大家都在做 CLI 》。他的核心判断只有一句——当软件的操作者从人扩展到 Agent，CLI 不再只是给工程师用的老工具，它成了 Agent 调用数字世界的高效入口。

同一天，百度网盘主端 FE 团队公开了一组数据：他们每月 2000 次 Code Review，其中 55.87% 的代码已经是 AI 写的；传统人工 Review 效果锐减，于是搞了一套多 Agent 多角色 AI 审查链路。

也是同一天，JetBrains 在博客发了一个反直觉的实测——有个叫 Caveman 的插件号称"让 AI 说原始人话"能省 65% token，JetBrains 把它扔进 SkillsBench 跑 86 个任务，实测只省 8.5%，任务质量没有显著差异。

三件事拼在一起，2026 年 Agent 时代的轮廓清晰了：CLI 复兴不是审美复古，是结构性必然。

为什么是 CLI，不是 GUI

计算机的界面进化，过去四十年一直是从 CLI 到 GUI。从文字到图标，从键盘到触屏，对人越来越友好。Agent 时代方向反过来了——软件的用户变成了 AI Agent。

LLM 和终端说同一种语言。LLM 是 text-in、text-out 的机器，终端是 text-in、text-out 的界面。让 AI 操作 GUI 就绕远了：得截图、用视觉模型识别按钮在哪、再模拟鼠标去点，一行命令能搞定的事拆成四步，每步都可能出错。对 AI 来说，CLI 就是最短路径。

这背后是四个结构性优势，每一个都对应 Agent 工作的真实痛点。

天然同构：上面已经说了，text-in/text-out 是 LLM 的母语，CLI 是它的母语。让 AI 操作 GUI 是逼它学外语。

自描述：这是 CLI 相对 API 最被低估的优势。AI 碰到一个陌生的 CLI，敲一下 --help 就知道有哪些能力、怎么用、参数怎么填。CLI 自带说明书。API 不行——AI 得先拿到文档、弄清端点、搞懂认证方式，才能动手。工具本身就是文档，这种"自描述性"让 CLI 成为对 AI 最友好的接口。

Unix 哲学：管道和组合，是 AI Agent 最需要的执行模型。antwork calendar agenda --next-week | grep "张三" | wc -l 一行命令查出下周和张三有几个会。MCP 更适合预定义的标准操作，而 CLI 可以靠管道组合出没预设过的操作——这种"即兴编排"能力是 CLI 独有的。

并行是原生的：CLI 命令本质上是无状态、可序列化的，一个字符串就是一个完整的操作指令。Agent 可以批量生成命令、并行分发到多个进程、独立重试，不需要维护 session 状态。当你的工作从"一个人写代码"变成"指挥一群 Agent 干活"，CLI 的无状态特性让并行调度水到渠成。

JetBrains 那个 8.5% 的反例正好佐证了这一点——他们测的"原始人话"省 token 失败，正是因为 Agent 的输出大部分是代码、diff、工具调用、错误字符串，这些不能压缩。CLI 之所以适合 Agent，是因为 Agent 真正消耗的 token 本来就是结构化的文本，而不是自然语言。

三层能力栈：食材、预制菜、菜谱

CLI 和 MCP 放在一起看，不是二选一，是 Agent 能力栈的不同层级。加上越来越多人讨论的 SKILL，三者构成一个从底到顶的分层结构。

CLI（食材）：最底层的原子操作。Agent 直接在终端执行命令，一个字符串就是一个动作。灵活度最高，但每次都要从零组装。

MCP（预制菜）：把常用操作封装成结构化的工具，预先注册给 Agent。输入输出有 schema，调用方式标准化。

SKILL（菜谱）：最上层的编排逻辑。一个 SKILL 可能组合多个 CLI 命令和 MCP 工具，封装成一个完整的多步骤流程。

打一个比方：CLI 是食材，MCP 是预制菜，SKILL 是菜谱。食材最灵活，你可以做任何菜，但每道菜都得从洗菜切菜开始。预制菜省事，开袋加热就能吃，但只有菜单上有的品种。菜谱是完整的烹饪流程，告诉你先放什么后放什么、火候多大、什么时候翻面——它可能同时用到食材和预制菜。

这三层意味着什么？Agent 真正需要的不是三选一，是根据场景在三层之间自由切换。简单操作直接敲 CLI；高频标准操作走 MCP；复杂多步流程用 SKILL 编排。好的 Agent 框架应该让这三层无缝衔接，不是把 Agent 锁死在某一层。

这也解释了为什么 CLI 复兴不等于 MCP 衰落。CLI 是创新的试验场，MCP 是标准化的沉淀池，SKILL 是最佳实践的固化层。CLI 越繁荣，沉淀出的 MCP 工具和 SKILL 工作流越多——Agent 在 CLI 层积累的操作经验，最终会凝固成生态。

百度网盘 FE 团队的 AICR 实践正好是这个三层结构的标准范本。55.87% 的 CR 已经是 AI 写的，传统人工 Review 看不过来，他们怎么解决？把审查拆成多 Agent 多角色链路：一个 Agent 负责整理 diff 上下文，一个负责查 API 契约，一个负责查高危模式，最后一个负责裁决风险——每个 Agent 就是一个 CLI 命令或 MCP 工具，整个审查流程是一条 SKILL 链。这不是"给 AI 加个 CLI"，是把整个工程流水线按 Agent 重新设计。

AI 友好四要素：可调用、可理解、可组合、可恢复

"AI 友好"这个词 2026 年开始刷屏。但什么叫 AI 友好？郭小成给了四个特征，比那些"AI First""智能化升级"的空话具体得多。

可调用：能力不能锁在 GUI 里。每一个有价值的操作，都应该有对应的编程接口——CLI、API 或 MCP 工具。GUI 是给人的"前门"，Agent 需要一个同样通畅的"后门"。如果你的产品只有前门，Agent 就只能对着屏幕截图再模拟点击，这不叫 AI 友好，这叫为难 AI。

可理解：Agent 拿到接口后，不需要翻 200 页手册才能上手。参数有语义化命名，返回有结构化格式，错误信息能指导下一步操作。--help 就是最好的例子——工具自己会说话。

可组合：单个操作是原子的，多个操作可以自由串联。Agent 的强项是编排，但前提是每块积木的接口是标准的。如果每个操作都是一个黑盒，输入输出格式各不相同，Agent 就没法组装出新流程。

可恢复：Agent 会犯错，这是确定的。好的 AI 友好设计不是假设 Agent 永远正确，而是让错误可以低成本回退。操作最好是幂等的，状态变更是可追溯的，失败不会导致不可逆的损害。

但这些只是"对 Agent 友好"的部分。真正的 AI 友好还有另一半：对"人 + Agent"这个组合友好。

这回到了可观测性问题。人不需要看到 Agent 的每一行日志，但需要在关键节点上有决策权。完全不放手的 Agent 每一步都要请示，效率比自己干还低；完全放手，Agent 跑飞了可能都不知道。核心问题是可观测性怎么设计。

好的产品应该为这种协作模式提供原生支持：哪些操作 Agent 可以自主执行，哪些需要人类确认，出了问题怎么回滚——这些应该是产品平台提供的基础能力，而非 Agent 自己实现的逻辑。

诚实的反面：CLI 的三大短板

把话说全。CLI 不是银弹，它有三个绕不开的短板。

学习曲线。对大部分非程序员来说，CLI 是拒绝的。命令记不住、参数填不对、错误看不懂。JetBrains 那个 Caveman 插件之所以在"原始人话"上动脑筋，正是因为开发者也嫌"和 Agent 说话太啰嗦"。

Windows 兼容性。POSIX 风格的管道、grep、wc 在 Windows 下要么缺失要么别扭。Agent 要跨平台工作，这层摩擦不能假装不存在。

调试可观测性差。Agent 跑 CLI 出错时，错误信息往往不够结构化。MCP 至少有 schema 返回的标准化错误码，CLI 只有 stderr 一坨文本流。

但这些短板是可以被工程化解决的，不是结构性缺陷。JetBrains 的实测结果反过来说明一件事：只要你把工具做对（自描述、幂等、上下文干净），Agent 实际工作时的摩擦比想象中小得多。那个 8.5% 才是真实基线，65% 才是过度营销。

2026 是 Agent First 的 2010

2010 年大家也在争论"要不要做 App"。历史告诉我们，答案很快变成"不做 App 就出局"。

把目光放到当下，2026 年我们面临的问题不再是"要不要 AI 友好"，而是"怎么比别人更快地实现 AI 友好"。先把能力 CLI 化、API 化、MCP 化的产品，会率先接入 Agent 生态，获得第一波 AI 原生用户。那些还在想"我们的 GUI 已经够好了"的产品，会像当年坚持"网页版体验已经很好了"的公司一样，看着用户悄悄流向 Agent 能直接操作的竞品。

对开发者来说，今天能动手的事有三件。

第一，给你的产品暴露 CLI 后门。不需要全套，挑出 5-10 个最高频的操作，结构化输出，加 --help 自描述。JetBrains 实测证明工具质量是核心，CLI 本身不难。

第二，高频操作用 MCP 封装进工具清单。当你的 CLI 跑稳了，把"Agent 每天要调 100 次"的那几个操作包成 MCP 工具，节省 token 消耗和上下文窗口。

第三，复杂多步流程用 SKILL 沉淀成 SOP。把团队里"老员工才知道的判断"写成 SKILL 工作流，新员工/新 Agent 拿来就能跑——这是把组织能力数字化资产化的关键一步。

我们正站在 Agent First 的 2010。先把 CLI 暴露出去的产品，会先吃到 Agent 生态的第一波红利。 三年后回看今天，CLI、MCP、SKILL 会像 2013 年的 App 一样，成为产品的基础设施而非选配。

那些现在还在问"我们要不要做 CLI"的人，2027 年会问的是"我们还能不能上车"。