本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

如果你只想要一句话结论：CLI-Anything 是香港大学数据科学实验室（HKUDS）开源的一个项目，它做的事情是——读取某个软件的源代码，自动为它生成一整套命令行接口（CLI），从而让 AI Agent 不用截图点鼠标，就能像调用程序一样调用那些原本只有图形界面的软件。它已经在 GIMP、Blender、LibreOffice、OBS、Kdenlive 等二十来款专业软件上实测，官方公布的测试用例累计接近两千项、全部通过。它的价值不在于"炫技"，而在于补上了 Agent 生态里长期缺失的一块拼图：过去 Agent 的能力上限，很大程度取决于第三方软件愿不愿意为它开放接口；有了这套方法，主动权第一次回到了使用者手里。

需要说清楚的是：它生成的 CLI 并非软件官方原生接口，覆盖度和稳定性会有波动，也重度依赖强力的基础模型和可获取的源码。这几点后面会展开。

想看完整拆解——从底层原理、七阶段流水线，到怎么在 Claude Code 里三步装好、怎么让它越用越全，再到它到底能碰哪些软件、又有哪些坑——往下翻。

一、先把问题讲透：Agent 想用你电脑里的软件，到底卡在哪

我自己折腾各种 Agent 工具的时候，最先撞上的墙不是"模型不够聪明"，而是"模型够聪明，但它够不着东西"。你让它帮你剪个视频、抠张图、导出一份 PDF，它脑子里门儿清该怎么做，可它的手伸不进你的剪辑软件、图像软件、办公软件里。这种感觉很像请了个经验丰富的老师傅，本事一身，却发现车间的工具柜全锁着，他只能干瞪眼。

这几年大家的注意力大多扑在"模型多强"上——参数多大、推理多深、能不能一步到位。可真到落地干活，卡住整个链条的往往不是模型的脑子，而是它的手能不能碰到东西。一个 Agent 再会思考，够不着软件，也只是纸上谈兵。所以"怎么让 Agent 接上真实软件"，是绕不开的一道坎。

我举个特别具体的场景你就懂了。假设我想让 Agent 帮我做一件小事：把一段屏幕录像剪成三秒的动图，再存到桌面。这活儿对人来说不过是打开录制软件、框选区域、点录制、点停止、点导出，前后半分钟。可对 Agent 来说，这中间的每一步——找到软件图标、认出"录制"按钮在哪、判断有没有录完、找到"另存为"、填对文件名——都是一道坎。它脑子里知道流程，手上却步步维艰。

问题的本质是：软件和 Agent 之间，缺一个双方都能听懂的"接口"。人和软件之间的接口是图形界面，它是为人的眼睛和手优化的；可这套东西对 Agent 极不友好。于是要让 Agent 真正动起来，把它和一个具体软件"接上线"，业内基本就两条路。

1.1 第一条路：模拟点击（GUI 自动化）

这条路的思路很直白：让 Agent 学人类的样子操作。它先"看"一眼屏幕截图，识别出按钮、菜单、输入框的位置，然后控制鼠标去点、去拖、去填。

听上去很美——只要是人能点的，理论上它都能点。但真上手你就会发现问题一堆：

• 慢。截图、识别、定位、点击，一轮下来好几秒，做几十步操作能等到你怀疑人生。
• 依赖视觉能力。模型得能"看懂"界面，这对模型要求高，也更烧算力。
• 脆。软件更新一次布局、换一版皮肤、弹个意料之外的窗口，之前调好的流程可能当场崩掉。
• 遇到小众软件抓瞎。界面越非主流、越不规整，识别越容易翻车。

在实际工程里，GUI 自动化（也就是常说的 RPA 那一类，RPA 即"机器人流程自动化"，本质是让程序模拟人操作界面）是"能用，但用起来提心吊胆"的方案。它最大的问题是"不确定"——同一套流程，今天跑得好好的，明天软件弹了个更新提示，或者你换了台分辨率不同的显示器，识别就可能错位，整条链子当场断掉。对追求稳定的自动化来说，这种"看运气"的特性是致命的。

1.2 第二条路：命令行（CLI）

第二条路是绕开界面，直接从底层"喊话"软件。命令行接口（CLI，Command-Line Interface，简单说就是用打字敲命令的方式来指挥程序）把上面几个毛病基本都能治：不用截图不用识别，速度快、结果稳、还能在后台悄悄跑，不打扰你在前台干别的。

CLI 几乎是业内公认最适合 Agent 的操控方式。原因也不玄乎，我把它拆成几点摆出来：

这里多解释一句为什么 CLI 对大语言模型（LLM）特别友好。LLM 本质上是在"读文本、写文本"，而命令行的输入输出恰好也是纯文本，两者是同一种语言。把这层"合拍"拆细了看，CLI 有六个特质特别对 Agent 的胃口：

• 结构化、可组合：文本命令天然匹配模型的输入格式，一条能接一条，自由串成复杂流程。
• 轻量且通用：几乎零额外开销，跨平台就能跑，不挑环境。
• 自描述：一个 --help 就能让 Agent 自动发现这个工具的全部功能，等于自带说明书。
• 久经验证：命令行不是新东西，像 Claude Code 这类工具每天就是靠 CLI 执行海量真实任务，路子早被走通了。
• Agent 友好：结构化的 JSON 输出，Agent 拿到就能用，不用再费劲去解析。
• 确定且可靠：同样的命令给同样的结果，行为可预测，不会像识别界面那样时灵时不灵。

这几点里，我最看重"自描述"和"确定性"。自描述意味着 Agent 面对一个陌生工具时能自己摸清它会什么，不用你手把手教；确定性意味着它每次执行都稳，不会今天点得中、明天点偏了。这两样恰恰是图形界面最给不了的——界面是给人的直觉看的，不是给机器的确定性用的。

1.3 但 CLI 有个硬伤：得软件自己愿意支持

问题来了。CLI 虽好，可它不是白来的——需要软件官方主动开发并对外提供命令。

Agent 火起来之后，不少互联网公司确实开始给自家产品补 CLI 或开放接口，让 Agent 能直接读写它们的文档、表格。可放眼望去，愿意这么做的仍是极少数。我们日常在用的绝大多数软件，尤其是那些经典的单机老工具，压根没有 CLI 这回事。

而且很多软件也有它的难处：本身就是免费开源项目，团队维持日常开发都够呛，让它专门抽人力去做一套 Agent 用的 CLI，实在有心无力。这不是不想做，是没余力做。结果就是一个尴尬的局面——一边是能力越来越强、嗷嗷待哺想干活的 Agent，一边是一大批没接口、进不去的软件，中间隔着一道谁都懒得填的鸿沟。填这道鸿沟，靠软件厂商一个个主动来做，等到猴年马月都不一定齐。

于是就有人开始琢磨：能不能在官方没动手的情况下，让任意软件都"凭空长出"一套 CLI？ CLI-Anything 就是冲着这个问题去的。

二、CLI-Anything 是什么：给"没有 CLI 的软件"补一套 CLI

2.1 一句话定义

就像它名字直白说的——CLI-Anything，给任何东西配 CLI。它是一个能读取软件源代码、并据此自动生成一整套配套命令行接口的项目。跑通之后，你的 Agent 就能通过这套新命令去操控那款软件了。

换个角度理解：过去要给一个软件做 CLI，是"人读代码、人写命令、人写测试"，慢且贵；CLI-Anything 把这套活儿交给了 AI，让 AI 读代码、AI 设计命令、AI 写测试。它相当于一个专门"给软件配 Agent 接口"的自动化流水线。你要做的，只是把软件（或它的仓库地址）指给它，剩下的它包圆。这也是它敢叫"Anything"的原因——它不是为某个特定软件量身定做，而是提供了一套通用方法，理论上对任何有代码的软件都适用。

项目地址在 GitHub 上：github.com/HKUDS/CLI-Anything，采用 Apache 2.0 开源许可，可以自由使用、修改和分发。

2.2 它从哪儿来

CLI-Anything 出自香港大学数据科学实验室（HKUDS）。团队还配了一份技术报告，标题叫《CLI-Anything: Towards Agent-Native Computer Use》（面向 Agent 原生的计算机操作），挂在 arXiv 上（编号 2606.03854），作者是 Yuhao Yang、Tianyu Fan、Chao Huang。

"Agent 原生"（Agent-Native）这个说法值得留意。它背后的判断是：今天的软件是为"人"设计的——菜单、图标、拖拽，全都围着人类的眼睛和手转；而明天的重度用户会是 Agent。既然如此，软件就该有一层专门给 Agent 用的接口。CLI-Anything 想做的，正是这层桥。

这个判断我是认同的。过去几十年，软件的交互一直在往"更符合人类直觉"的方向进化——从命令行到图形界面，从鼠标到触屏，核心都是让人用起来更顺手。可当越来越多的操作要交给 Agent 去执行时，这套为人优化的界面反而成了障碍。它就像给一个不用眼睛的用户配了一堆精美图标——好看，但用不上。CLI-Anything 相当于承认了这个现实：与其逼 Agent 去"看"人类的界面，不如给它另开一扇门，一扇纯文本、结构化、它天生就懂的门。这个思路对不对，很大程度上决定了它值不值得关注。而项目从开源到现在，GitHub 上聚集的关注度（星标已达数万量级）也侧面说明，认同这个方向的人不在少数。

2.3 核心思路：读代码 → 生成 CLI

它的底层逻辑其实一点不复杂，我用一行伪代码概括一下：

输入：软件的源代码（本地路径 或 GitHub 仓库地址）
  ↓ 分析代码，把界面里的每一个功能映射成一条命令
  ↓ 设计命令的分组、参数、输出格式
  ↓ 写代码把这套 CLI 真正实现出来
  ↓ 配上完整测试，验证每条命令都能跑通
输出：一套可安装、可被 Agent 调用的命令行工具

注意，它不是拿 Python 随便糊一个"假装能用"的替身，而是让生成出来的 CLI 去驱动真实的软件后端。这一点是它和很多"玩具级"方案的分水岭，后面第三节会专门讲。

这里顺带说说它想成就的那个更大的图景。官方把愿景概括成三点：无门槛接入——任何软件都能通过结构化 CLI 即刻被 Agent 操控；无缝集成——不需要专门的 API、不需要操控 GUI、不需要重构代码、也不需要复杂的适配层；面向未来——一条命令，就把为人类设计的软件变成 Agent 的原生工具。说白了，它赌的是一件事：软件不该因为"没人来接 Agent"就被挡在自动化时代之外，而这道接入的门槛，本就不该那么高。

2.4 它和 MCP、和"官方 CLI"是什么关系

聊到这儿，估计有朋友会想起 MCP。MCP（Model Context Protocol，模型上下文协议）是这两年很火的一套标准，用来把外部工具、数据源统一接给 Agent。既然有 MCP，为什么还要 CLI-Anything？

其实它们解决的不是同一层问题。MCP 更像"插座标准"——它规定了工具怎么把自己暴露给 Agent，但前提是那个工具得先有一套能对外提供的能力（一套 API、一套服务）。可现实是，你桌面上那些老牌单机软件，压根没有对外的服务，连"插头"都没有，谈何插座。CLI-Anything 干的恰恰是更靠前的一步：先给这些没接口的软件造出一套接口来。造好之后，它以标准命令行的形式存在，任何能调命令行的 Agent、乃至将来包一层 MCP，都能用得上。

再和"官方 CLI"摆一起看，三者的定位是这样的：

一句话：CLI-Anything 填的是"厂商不做、又没有现成 API"的那片空白。它不跟 MCP 抢地盘，反而是给 MCP 之类的上层协议铺了一层"底料"——先把软件变得可被命令行驱动，上层怎么包装都好说。想明白这层关系很重要，不然容易把它们当成互相替代的竞品，其实它们是上下游、能叠着用的关系：CLI-Anything 负责"把没接口的软件变得有接口"，MCP 负责"把有接口的能力标准化地递给 Agent"，各司其职。

三、它是怎么工作的：七个阶段的全自动流水线

我把官方文档翻了一遍，CLI-Anything 生成一套 CLI 的过程，被拆成了七个自动执行的阶段。你只要丢给它一个软件路径，剩下的它一条龙走完。用一张流程图看最直观：

flowchart TD
    A[输入软件源码 / 仓库地址] --> B[1. 分析<br/>扫描源码, 把 GUI 操作映射到底层 API]
    B --> C[2. 设计<br/>规划命令分组, 状态模型, 输出格式]
    C --> D[3. 实现<br/>构建 CLI, 含 REPL, JSON 输出, 撤销重做]
    D --> E[4. 规划测试<br/>生成测试计划, 覆盖单元与端到端]
    E --> F[5. 编写测试<br/>实现完整测试套件]
    F --> G[6. 文档<br/>写入测试结果, 生成技能说明]
    G --> H[7. 发布<br/>生成安装脚本, 装到系统 PATH]
    H --> I[一套可被 Agent 调用的 CLI]

逐个阶段拆开说：

3.1 分析（Analyze）

先把软件的源代码扒一遍，搞清楚它的架构和数据模型，把界面上"点这里能干嘛"逐一对应到底层的函数或 API 上。这步是地基，决定了后面生成的命令能覆盖多少功能。

打个比方，这就像一个新来的工程师接手一套陌生代码：他得先读懂这软件内部是怎么组织的——项目文件长什么样、有哪些核心对象、每个界面操作背后到底调了哪个函数。只有把这层"内部地图"画清楚，后面生成的命令才不会是空中楼阁。软件越复杂、代码越庞大，这一步越吃模型的理解力，这也是它对基础模型要求高的原因之一。

3.2 设计（Design）

有了功能清单，接着规划命令怎么分组、每条命令带哪些参数、输出成什么格式。好的设计会让一堆零散能力被收拢成逻辑清晰的几组命令，而不是一锅乱炖。

这一步还要定一个很关键的东西：状态模型。很多软件的操作是有上下文的——你得先有个"项目"，才能往里加图层、加轨道、加元素。CLI 得把这种状态管起来，让 Agent 敲第二条命令时，工具还记得第一条命令干了啥。设计得好不好，直接决定这套 CLI 用起来顺不顺。

3.3 实现（Implement）

真正动手写代码，把 CLI 造出来。生成的工具默认就带三样东西：交互式 REPL（一个可以像聊天一样一条条敲命令的会话环境）、JSON 结构化输出、以及撤销/重做能力。

撤销/重做这点尤其体贴 Agent。Agent 干活难免试错，走错一步能一键回退，就不至于把整个项目搞乱、从头再来。这相当于给它的每一步操作都上了个"后悔药"。

3.4 规划测试 & 3.5 编写测试

这是我觉得它比一般"生成工具"讲究的地方——它不是生成完就撒手，而是先制定一份测试计划，再把完整的测试套件写出来。测试分好几层：拿合成数据验证单个函数的单元测试、生成真实项目文件跑通全流程的端到端测试，还有把装好的命令当子进程真跑一遍的验证。

为什么这么费劲？因为"自动生成的代码"最不让人放心的就是"看着能跑、实际不对"。一套没有测试兜底的 CLI，你根本不敢让 Agent 拿去批量干活——万一某条命令悄悄出错，产物全废了都没人知道。而有了这几层测试，每条命令是不是真管用，是有据可查的。这也是它敢公布"全部测试 100% 通过"这个数字的前提——不是没测出问题，而是把测出来的问题都在生成阶段解决掉了。

3.6 文档

把测试结果写进文档，同时生成一份给 AI 读的"技能说明"文件（也就是那种 SKILL.md），让 Agent 之后能快速看懂这套 CLI 怎么用。这一步很容易被忽视，但其实很关键：Agent 面对一套陌生 CLI 时，靠的就是这份说明和 --help 来快速上手。文档写得清不清楚，直接影响 Agent 用得顺不顺。每个生成的 CLI 还会附一份该软件的架构说明和一份测试计划文档，方便你后续维护。

3.7 发布

生成安装脚本，把工具装进系统 PATH。装好之后 Agent 用一句标准的 which 命令就能发现它，不需要任何额外配置。这个"零配置发现"的设计很巧妙——Agent 不用你告诉它工具装在哪、叫什么，它自己用系统命令一查就知道有哪些 cli-anything-* 工具可用、每个能干嘛。整套流程走完，一个原本只有图形界面的软件，就彻底变成了 Agent 能自主发现、自主调用的工具。

3.8 一个关键设计：调"真软件"，不造"假替身"

单独把这条拎出来强调，因为它是 CLI-Anything 敢说"零妥协"的底气。

举个例子。假如要给一个图像软件做 CLI，偷懒的做法是：用 Python 的图像库随便实现几个滤镜，假装这就是那个软件的能力。问题是，很多软件的特效是在"渲染"那一刻才真正生效的，你用简陋的导出工具糊过去，特效会被悄无声息地丢掉，最后产物根本不对。

CLI-Anything 的原则是：CLI 只负责生成合法的项目文件，真正的渲染交回给真实软件去做。LibreOffice 导 PDF 就真调 LibreOffice，Blender 渲 3D 场景就真调 Blender，音频处理就真走对应的音频后端。官方甚至把这条写成硬规矩——如果真实后端不在，测试直接判失败，而不是"跳过"糊弄过去。这样才能保证生成的能力是真的，不是纸糊的。

我特别欣赏这个"当接口、不当替身"的定位。市面上不少号称能让 AI 操作软件的方案，实际是把软件的一小撮功能用别的库重新实现了一遍，结果就是"支持是支持了，但只剩皮毛"——真正专业、复杂的能力全丢了。CLI-Anything 反其道而行：它不试图取代软件，只给软件加一层"翻译"。你要的还是那个完整的、专业的软件，只不过多了一个 Agent 能听懂的说话方式。这就是它敢喊"零妥协、功能一个不少"的底气所在。生成的项目文件必须是软件能认的合法格式（比如办公文档的 ODF、视频工程的 MLT XML、矢量图的 SVG），然后原封不动交给软件本体去出片。中间不偷工、不减料。

四、生成出来的 CLI 长什么样：REPL、--json、子命令

原理讲完，来看成品。这里有个很省心的地方：不管你给哪个软件生成 CLI，用法是统一的三种姿势——学会一个，其余的都会用。这种一致性不是巧合，而是设计使然：所有生成的 CLI 都共用同一套交互界面（内部叫 ReplSkin），带统一的横幅、提示符风格、命令历史和输出格式。于是你在 GIMP 的 CLI 里养成的操作习惯，切到 Blender、LibreOffice 的 CLI 也照样管用，不用重新适应。下面就是那三种姿势。

4.1 三种用法

• 子命令模式：像普通命令行工具一样，一条命令干一件事，适合写脚本、串流水线。
• REPL 交互模式：直接运行工具名（不带任何参数）就进入一个交互会话，可以一条条敲命令、保留上下文状态，适合 Agent 边想边做。
• JSON 输出模式：加个 --json，输出就变成结构化数据，专门喂给 Agent 消费。

4.2 一个 LibreOffice 的实际例子

拿它给 LibreOffice 生成的 CLI 举例，感受一下 Agent 在背后是怎么"说话"的（下面命令来自官方演示）：

# 新建一个 Writer 文档
$ cli-anything-libreoffice document new -o report.json --type writer
✓ Created Writer document: report.json

# 加一个一级标题
$ cli-anything-libreoffice --project report.json writer add-heading -t "Q1 Report" --level 1
✓ Added heading: "Q1 Report"

# 插一张 4 行 3 列的表格
$ cli-anything-libreoffice --project report.json writer add-table --rows 4 --cols 3
✓ Added 4×3 table

# 通过 LibreOffice 无界面模式导出成真实 PDF
$ cli-anything-libreoffice --project report.json export render output.pdf -p pdf --overwrite
✓ Exported: output.pdf via libreoffice-headless

你看，整个过程没有任何"打开软件—点文件—点新建—点插入表格"的界面操作，全是纯文本命令。而最后那步导 PDF，是真的把活儿交给了后台的 LibreOffice。

4.3 为什么 --json 对 Agent 这么关键

再看一眼加了 --json 的返回：

{
  "name": "Q1 Report",
  "type": "writer",
  "pages": 1,
  "elements": 2,
  "modified": true
}

对人来说，一句"已创建文档"就够了；但对 Agent 来说，它需要的是能直接解析、能据此做下一步判断的结构化数据。有了 JSON，Agent 不用再去"猜"命令执行成没成、现在文档什么状态，一切都明明白白摆在字段里。这就是"Agent 原生"落到实处的样子。

那这三种模式实际怎么选？我给个简单的判断：要写固定脚本、串流水线，用子命令模式，一条命令一件事，好组织；让 Agent 边想边做、需要保留上下文，用 REPL 模式，它能记住前几步的状态；要把结果交给程序或 Agent 继续处理，一律加 --json，省得再去解析人类可读的文本。绝大多数交给 Agent 的场景，其实是"REPL + JSON"的组合——既有连续会话的记忆，又有机器能吃的结构化输出。

REPL 模式跑起来更像下面这样，会有个带横幅的交互界面，提示符还会跟着当前项目状态变（这里以 Blender 为例）：

$ cli-anything-blender
╔══════════════════════════════════════════╗
║       cli-anything-blender v1.0.0        ║
║       Blender CLI for AI Agents          ║
╚══════════════════════════════════════════╝

blender> scene new --name ProductShot
✓ Created scene: ProductShot

blender[ProductShot]> object add-mesh --type cube --location 0 0 1
✓ Added mesh: Cube at (0, 0, 1)

blender[ProductShot]> render execute --output render.png --engine CYCLES
✓ Rendered: render.png via blender --background

五、动手上手：在 Claude Code 等 Agent 里怎么装、怎么用

这一节最实用，我把上手路径按新手能照抄的程度铺开。

5.1 先看环境要求

• Python 3.10 及以上（生成的 CLI 是 Python 包，这是硬门槛）。
• 目标软件要装好。你想让 Agent 操控哪个软件，这个软件本身得在你机器上装着。
• 一个支持的 Agent 工具。官方对 Claude Code 支持最完整，此外还适配了 OpenCode、OpenClaw、Codex、Qodercli、GitHub Copilot CLI 等，Cursor、Windsurf 也在路上。

这里要提前打个预防针：别用太弱的模型去驱动它。前面反复强调过，生成 CLI 是个吃模型推理能力的重活，官方点名建议用前沿级别的大模型。如果你手头的 Agent 接的是个小模型，很可能生成到一半就崩、或者产出一堆需要返工的半成品。所以在开工前，先确认你的 Agent 底座模型够强，这一步能帮你省掉后面一大堆麻烦。另外，虽然生成 CLI 可以只靠仓库地址读源码，但要真正跑起来操控软件，目标软件本体还是得装在本机——这两件事别搞混。

5.2 Claude Code：三步走

在 Claude Code 里，CLI-Anything 是以"插件"形式集成的，三步搞定：

# 第一步：添加插件市场
/plugin marketplace add HKUDS/CLI-Anything

# 第二步：安装插件
/plugin install cli-anything

# 第三步：给某个软件生成 CLI（这里以 gimp 为例）
/cli-anything ./gimp

第三步一敲，前面讲的七阶段流水线就自动跑起来了。这个过程不算快——它要读代码、设计、实现、写测试、生成文档，跑上几分钟很正常，但换来的是一套带完整测试的成品，值。

给用非官方模型的朋友提个醒：如果你的 Claude Code 接的不是官方模型，插件功能可能不被支持，/plugin 那套命令会不认。碰到这种情况也别慌，直接把项目地址丢给 Agent、让它自己照着说明装就行，比如对它说：

帮我在电脑里安装这个项目：https://github.com/HKUDS/CLI-Anything ，并参考它的中文说明完成配置。

Windows 用户注意：Claude Code 是通过 bash 执行命令的，Windows 下建议装 Git for Windows（自带 bash 和 cygpath）或者用 WSL，否则可能报 cygpath: command not found。

5.3 其他 Agent 平台怎么装

如果你用的不是 Claude Code，路子也不复杂，核心都是"把命令/技能文件放到对应目录"。这里给几个常见平台的接入方式，照着敲即可。

OpenCode（把命令文件和方法论手册一起拷进命令目录）：

git clone https://github.com/HKUDS/CLI-Anything.git

# 全局安装（所有项目可用）
cp CLI-Anything/opencode-commands/*.md ~/.config/opencode/commands/
cp CLI-Anything/cli-anything-plugin/HARNESS.md ~/.config/opencode/commands/

装完会得到 /cli-anything、/cli-anything-refine、/cli-anything-test、/cli-anything-validate、/cli-anything-list 五个斜杠命令。这里有个容易踩的坑：那份 HARNESS.md 是所有命令都要引用的方法论规范，必须和命令文件放在同一个目录下，漏了它命令会不完整。

OpenClaw（以原生技能文件 SKILL.md 安装）：

git clone https://github.com/HKUDS/CLI-Anything.git
mkdir -p ~/.openclaw/skills/cli-anything
cp CLI-Anything/openclaw-skill/SKILL.md ~/.openclaw/skills/cli-anything/SKILL.md

装好后一句自然语言就能触发，比如 @cli-anything build a CLI for ./gimp。

Codex（跑内置安装脚本）：

git clone https://github.com/HKUDS/CLI-Anything.git
bash CLI-Anything/codex-skill/scripts/install.sh

装完重启 Codex，让它重新发现这个技能，之后直接用自然语言下达任务即可。

可以看出来，不管哪个平台，方法论内核是同一套七阶段流程，生成出来的 Python 工具结构也一模一样。所以你完全不必纠结"用哪个平台生成的 CLI 更好"——它们本质上是同一个东西，选你顺手的 Agent 就行。

5.4 用生成好的 CLI

不管你用哪个平台生成，用法完全一致：

# 把生成的 CLI 装进 PATH
cd gimp/agent-harness && pip install -e .

# 验证装好了没
which cli-anything-gimp

# 看它有哪些能力
cli-anything-gimp --help

# 直接进 REPL 交互
cli-anything-gimp

# 给 Agent 用的 JSON 输出
cli-anything-gimp --json <命令>

实际使用时你甚至不用记这些命令——用自然语言告诉 Agent 你想干嘛就行，比如"用刚才生成的 CLI，帮我把这张图转成灰度并导出到桌面"，剩下的命令拼装交给它。

5.5 CLI-Hub：不想自己造，直接装现成的

如果社区已经有人给你要的软件做好了 CLI，你完全不必从头生成。CLI-Anything 配了一个叫 CLI-Hub 的注册中心兼包管理器，可以一条命令装现成的：

# 装上包管理器
pip install cli-anything-hub

# 浏览 / 搜索 / 查看 / 安装
cli-hub list
cli-hub search video
cli-hub info gimp
cli-hub install gimp

它本质是 pip 的一层轻量封装：cli-hub install gimp 就是去帮你装那个独立的 cli-anything-gimp 包。每个 CLI 都是一个独立的、可 pip 安装的包，Hub 只是帮你从注册表里按名字找到它、跟踪安装状态而已。装完直接用，省掉了自己跑一遍生成流水线的时间。

这套包管理设计有个细节挺讲究：所有生成的 CLI 都被收在一个统一的命名空间下（cli_anything.*），彼此之间互不冲突。也就是说，你机器上同时装 GIMP、Blender、LibreOffice 三套 CLI，它们能在同一个 Python 环境里和平共处，不会打架。命名也统一规范：cli-anything-gimp、cli-anything-blender……看名字就知道是操作哪个软件的。这种整洁，对后续维护和 Agent 自动发现工具都是加分项。

顺带一提，Hub 里还有个"matrix（能力矩阵）"的概念，是把一整套跨多个工具的工作流打包成"能力×提供方"。比如做一条视频，可能要转写、配图、渲染好几步、好几个工具，matrix 会把这些意图统一编排起来。任务跨多个软件时，这个思路能省不少事。

5.6 refine：让覆盖面越用越全

单跑一次生成，不一定能把软件的功能全覆盖到。这时候可以用优化命令做"查漏补缺"：

# 全面优化：让 Agent 自己找覆盖差距并补上
/cli-anything:refine ./gimp

# 定向优化：指定你最想补强的方向
/cli-anything:refine ./gimp "我想要更多图像批处理和滤镜相关的命令"

refine 会把"软件的完整能力"和"当前 CLI 已覆盖的能力"做一次差距分析，然后针对缺口补命令、补测试、补文档。它是增量的、非破坏性的，可以反复跑，一次比一次全。

这里给个实用建议：refine 支持带"聚焦方向"。如果你在用的过程中发现某类操作老是缺（比如"我总需要批量处理图片，可现在的命令不够用"），就把这个方向明确写给它，让它专门往那儿补，比漫无目的地全面扫一遍更高效。把生成理解成"先出个能用的初版"，把 refine 理解成"按你的真实需求持续加料"，这套用法就顺了。

小结一下不同 Agent 里的接入形态：在 Claude Code 里它是插件，在别的一些 Agent（比如 OpenClaw、Codex）里则是以 SKILL.md 技能文件的形式安装。形态不同，实际用起来差别不大——照官方指引装，或者干脆把仓库地址交给 Agent 让它自己装，都行。

六、它到底能操控哪些软件：一张能力地图

光说原理容易飘，看它实测过哪些软件更踏实。官方在二十来款有代表性的复杂软件上做了验证，累计测试用例接近两千项、标称 100% 通过。

这里插一句怎么看这个"测试数"。它不是营销话术里的凑数，而是每个软件的 CLI 到底被验证了多少条能力的实打实指标。比如 Blender 的 CLI 有两百多项测试、s&box 有两百多项，说明这两套 CLI 覆盖的功能点相当密；而像 Zoom 这种走 REST API 的，测试数就少一些，因为它本身能操作的