Agent 时代，先别着急开发 CLI，来个Skill带你设计

Agent 时代，先别着急开发 CLI，来个Skill带你设计

昨天读到 Justin Poehnelt 的一篇文章 You Need to Rewrite Your CLI for AI Agents，大意是：现在已经是 AI Agent 时代了，CLI 这种天生适合 Agent 使用的工具，不能继续沿用老一套面向人类的设计范式了。

我瞬间感觉好像遇到知音了，很有共鸣啊，连夜动手，搓了一个 Skill 出来，今天分享给大家。不过在聊 CLI 的设计之前，我想先提一嘴 MCP 的事，说说我的共鸣是哪来的。

---

MCP 的问题：30k 上下文买来了什么？

MCP 大火的时候，我就一直很纳闷：本质上还是各种接口调用，为什么非要统一成一种协议、塞进一个巨大的上下文？

我记得装了几个很常见的 MCP，比如 GitHub MCP、Playwright MCP，当时还在用 Cursor 和 Claude Code，Cursor 直接提示我 MCP 工具最好别超过 40 个。因为工具自身的 prompt 太长了，长到严重挤占 Agent 的可用上下文。果不其然，同样是这些 MCP，我一打开 Claude Code，Statusline 就告诉我上下文已经占了 30k。还没开始干活，预算就花掉一大块。

（随便截了个图，不是真的说上下文占了这么多哈）

而相比之下，CLI 则天生更适合做 Agent 的外部工具。原因很直接：

• CLI 自带 --help，主命令有，子命令也有，天然分层，你想看哪个命令的就去 command --help，不会一股脑全塞给你
• 对知名 CLI，LLM 的知识库里本来就会用。没错，我说的就是 gh
• 不需要危险的 API Key 存到 MCP 的配置文件，又或者费半天劲解决了 PATH 的加载之后再存到环境变量里，CLI的关键的令牌管理安全且顺手
• 不需要开个会话一个 hi 就吃掉几千 token 的工具描述，你不调用它它永远不会烦你

所以我至今不太能理解 GitHub MCP 的意义：拿着 API Key，做着很有限的事情，消耗巨大的上下文。gh 不香吗？

从 Airis 实验到 Justin 的文章：CLI 的 help 其实也不够用

意识到 CLI 比 MCP 更适合 Agent 之后，我做了一个实验。

我搓了一个叫 Airis 的 CLI，包了海量工具进去成为一个个命令和子命令，然后把每个命令和子命令的 help 写得像 skill 说明书一样详细。效果还行，但有一个明显的问题，Agent 可没有我这个工具的知识库记忆，有的低智商模型直接上来就猜，直到碰壁了才去查 help。

这就像给一个人一本厚厚的手册，他不会先看完再动手，而是出错了才翻。所以说，--help 能救急，但救不了设计。

后来 skill 这个范式被提出来的时候，我立刻觉得这是对的方向。本质上和我对 help 的认知一致：把最关键的知识前置到 Agent 的上下文里，而不是等它运行时碰壁再去查。

但即便有了 skill，还剩一个更根本的问题没解决。

读到 Justin 那篇文章之后，我终于想明白了，为什么顶级的 CLI 好用，而随手 VibeCoding 出来的不行，根本原因还是在人：我们做 CLI 的时候，大多数是从功能出发的。让 Agent 帮忙起个 MVP，或者干脆就是从一个小脚本演化而来的。VibeCoder 很少有人会停下来问：

• 这个 CLI 到底是给谁用的？
• 它属于什么类型？
• 它的状态性有多强？
• 它的风险轮廓是什么？

而为我们开发 CLI 的 Agent 也没那么自觉，来问我们这些东西。Plan Mode 会稍微好点，但本质还是那样。

尤其是，我们可能从未认真考虑过一件事：有些 CLI 只会被 Agent 操作，人这辈子都不会碰；有些 CLI 专门用来连接两种不同语言的运行时，只供脚本和程序调用。这些工具和一个面向人类操作员的 CLI，设计上应该有本质的区别。

比如最近 OpenClaw 非常流行。OpenClaw 是一个典型的高度自主 Agent，它为了完成任务会反复设计各种小脚本和 CLI 工具。反过来，我们也可能想专门为 OpenClaw 开发一个 CLI，让它更高效地完成使命。这类场景下，CLI 的主要用户根本不是人，设计重心自然也完全不同。

缺了这些判断，你后面做的所有设计决策，命令树怎么排、输出什么格式、要不要加 --json、要不要上 TUI，全是在凭感觉。

所以我做了一个 skill：cli-design-framework

调研了一圈顶级 CLI 的最佳实践之后，从 POSIX/GNU 的语法纪律，到 CLIG 的 human-first 原则，到 Justin 文章里的 agent-era 新约束，我把这些东西收束成了一个框架。

核心只有一句话：先分类，再设计。

框架会沿着五个维度做判断：

分类一旦成立，设计后果是连锁的。举个例子：

需求：“做一个 CLI 来启动、观察和停止 AI agent 任务。”

这个 CLI 的分类应该是 Runtime，不是 Capability。一旦判断成立：

• 命令结构该用 start / attach / stop / approve，不是 create / get / delete。因为你管的是活着的进程，不是数据库里的对象。
• Approval 是一等公民命令，不是某个 flag 的附属品。High Side-Effect 加上 Human-Primary 意味着人类治理是产品核心。
• Session attach/detach 是核心能力。关掉终端不等于杀掉 agent，你需要能回来。

如果你跳过分类直接设计，很可能会做出一个整洁的 session list / session get / session delete 命令树。看起来不错，但你会发现：你有一个能描述 agent session 的工具，却治理不了它。

这就是 category mistake 的代价。

怎么用

如果你对自己的 CLI 应该长什么样还不够确定，装上这个 skill 之后，Agent 会从 plan mode 开始，一步步带你澄清需求、判断分类、推导设计后果。你不需要提前了解整套框架，分类体系、输出模板、锚点样例和反面教材都会在对话过程中自动拉进上下文。

三种用法：

• 快速启动：快速判断分类和核心设计后果
• 产出设计蓝图：输出完整的设计蓝图，从分类到命令树到风险模型，后续就可以基于此进行开发了
• 结构化Review：评审已有 CLI，把"分类错了"和"同类下做得不够好"分开说清楚

仓库：https://github.com/wangnov/cli-design-framework

后续我也会更新一些用这个 Skill 设计的 CLI，放在仓库的文档里做参考，看看这个 Skill 的威力是不是真的像吹的这么大。

# ClawHub
clawhub install cli-design-framework

# 或从仓库安装
npx skills add wangnov/cli-design-framework

兼容 Claude Code / Codex / OpenClaw 等一切 Agent，提示词内没有针对不同 Agent 进行调优，是通用的。我用它们仨分别设计了一遍几个实验性的 CLI，都挺满意的。

最后，Codex 在帮我写完 Skill 之后，给我留了一句看着很像名言的话，我自己也觉得很带感：
Classify first. Design second.
这才是 Agent 时代，我们人类的注意力需要聚焦的内容。而 Coding？和吃饭喝水一样简单。