我最近围绕 Agent 做应用，踩出来一个结论：
把执行动作收敛成 CLI，会让 Agent 用起来顺很多。
先说清楚：提示词当然重要，它决定了你让 Agent 怎么想、怎么判断、怎么把话说清楚。
我这里想强调的是另一件事：Agent 最贵的不是“不会做”，而是“需要你讲太多上下文”，以及“执行动作不够确定”。
所以我把零散的脚本都收进了一个工具：z-cli。
每个任务对应一句命令，比如：
- 导出 / 转换内容
- 生成规范产物
- 调发布、调草稿箱、调上传
然后 Skill 就轻了很多：
- 脚本收进 CLI 之后，Skill 篇幅会短一大截
- 不用在对话里反复解释流程
- 不用把参数、路径、约定塞进上下文
- 只要调用 CLI，拿结果就行
顺带一提：当这些“脏活累活”都变成一句句命令之后，Agent 的上下文也会跟着变得很小。
说白了：
Skill 负责“决定做什么”，CLI 负责“怎么做”。
这么一拆，Agent 的上下文压力小很多，稳定性也上来了。
另外，CLI 还顺手解决了一个很现实的问题：skill 里 scripts 变多之后，会越来越难管。
大部分人的 skill 都是 AI 写的，你去读它的代码，体验很像：
“我现在要接手维护一个别人维护了很久的项目。”——难受。
当然，你也可以直接用别人的 skill，或者让自己的 AI 现写一个。
但就怕用着用着：别人的需求变了，顺手就让 AI 把 skill 改掉了。
更要命的是：脚本反正也不是你亲手写的，你对它没什么印象。
真正要用的时候，你又得让 AI 重新读一遍、重新理解一遍。
所以 skill 一多，很多人会选择把它们集中管理，然后在用到的地方“链过去”。
这确实能缓解 skill 无限膨胀 的问题。
但如果 skill 里的脚本也开始出现交叉复用需求，那还是得工程化解决。
我觉得把它们收进 CLI 里，是个不错的选择。
再加一条：CLI 的 --help 天生就是一个简短的 description。
非常契合现在 AI 的发展阶段（也就是 skill 这一套）。
除非 LLM 本身发生巨变，否则 上下文管理 会一直是重点之一。
毕竟普通人玩 Agent，是不得不考虑 Token 的消耗问题的。