CLI-Anything：给 AI 生成命令行接口的开源方案，GUI agent 之外的第二条路

开源AgentAI开发者工具

让 AI 操作专业软件的尝试，大多停在「看屏幕、找按钮、挪鼠标」这一步。GUI agent 截一张图，用视觉模型定位按钮坐标，模拟一次点击，界面一变就全盘失效。香港大学数据智能实验室（HKUDS）的开源项目 CLI-Anything 走了另一条路：不模拟人的操作方式，把软件本身改造成 AI 擅长使用的形态。这个项目在 GitHub 上已经拿到 5 万多个 star，最近仍以每天数百的速度增长，背后的技术报告发表在 arXiv 上（编号 2606.03854）。

CLI-Anything 官方 teaser：从 GUI 困境到 agent-native 的三格漫画

截图点击为什么走不通

先看 GUI agent 的工作方式。它拿到一个任务，比如「用 Blender 渲染一个模型」，接下来的流程是截屏、识别界面元素、计算坐标、移动光标、点击。这条链路上的每一环都依赖像素级的精确性：按钮挪了 10 个像素，窗口弹出时机晚了两秒，或者界面换了主题配色，整套流程就得重新校准。

这类系统在演示视频里行云流水，在真实环境里经常翻车，原因不在模型不够聪明，而在交互协议本身。视觉通道是有损的——屏幕截图丢掉了软件内部的状态信息，模型只能从像素反推「软件现在处于什么状态」，再猜「下一步点哪里」。arXiv 论文里把这称为有损的视觉到计算翻译（lossy visual-to-computational translation）：模型本来擅长处理结构化数据和精确的程序化控制，GUI 却逼着它模仿人类的感知局限。

CLI-Anything 的出发点是一次范式调换：与其让 AI 学会用人的方式操作软件，不如让软件提供 AI 用得顺手、人类也能看懂的接口。这个接口在大多数软件上已经存在，就是命令行。

为什么是 CLI

命令行接口有几个特性，恰好对上了 LLM 的能力结构：

文本命令与 LLM 的输入格式天然一致，多个命令可以串成复杂工作流；--help 标志自描述，agent 不需要额外文档就能发现一个工具的全部能力；执行结果确定性强，同样的命令给同样的结果，agent 的行为因此可预测。这套东西不是新发明——Claude Code 每天通过 CLI 跑数千个真实工作流，已经验证了 LLM 与命令行的兼容性。

CLI-Anything 的贡献不在提出「用 CLI」这个想法，而在把「给任意软件生成一个像样的 CLI」这件事自动化了。项目把它要解决的问题称为 agent-software gap：AI agent 推理能力很强，却用不了真正的专业软件。现有方案要么是脆弱的 UI 自动化，要么依赖残缺的 API，要么是功能缩水的重实现——只覆盖原软件不到一成的功能。

CLI-Anything 七阶段自动生成管线

七阶段管线：从源码到 PyPI

CLI-Anything 以 Claude Code、Cursor、Codex 等 AI 编码代理插件的形式运行。装好插件后，一条命令 /cli-anything <软件路径或仓库> 触发完整的生成流程，七个阶段自动走完：

  1. Analyze：扫描目标软件的源码，把 GUI 操作映射到底层 API
  2. Design：设计命令分组、状态模型、输出格式
  3. Implement：用 Click 框架实现 CLI，带 REPL 交互、JSON 输出、撤销/重做
  4. Plan Tests：生成测试计划，覆盖单元测试和端到端测试
  5. Write Tests：实现完整测试套件
  6. Document：更新测试结果文档
  7. Publish：创建 setup.py，安装到系统 PATH

生成的每个 CLI 遵循统一的包命名规则（cli-anything-gimp、cli-anything-blender），pip install -e . 之后 agent 用标准的 which 命令就能发现它们。每个命令内置 --json 标志，机器读结构化数据，人看普通表格输出。

每个生成的 CLI 还附带一份 SKILL.md 文件——YAML 头部声明工具名和描述，正文列出全部子命令、用法示例和针对 agent 的指引。这份文件在第 6.5 阶段由 skill_generator.py 自动生成，直接从 Click 装饰器、setup.py 和 README 里提取元数据。agent 生态里的技能发现机制（比如 npx skills）可以直接消费这些文件。

生成完还可以迭代。/cli-anything:refine 命令做差距分析：对比软件的完整能力和当前 CLI 的覆盖范围，缺什么补什么，每轮增量执行、不破坏已有部分。

项目自己的证据：2464 个测试

衡量这套自动化生成靠不靠谱，项目给出的答案是测试数量。README 里列了一张测试总表：30 个 CLI harness 累计 2464 个测试全部通过，其中 Blender harness 208 个（150 单元 + 58 端到端）、GIMP 107 个、Inkscape 202 个、LibreOffice 158 个、OBS Studio 153 个。

测试分四层：单元测试验证每个核心函数；原生端到端测试验证项目文件生成管线（ODF ZIP 结构、MLT XML、SVG 良构性）；真实后端端到端测试调用真软件验证输出（LibreOffice 导出的 PDF 要检查 %PDF- 魔数，Blender 要真的渲染出 PNG）；最后是 CLI 子进程测试，用 subprocess.run 调安装好的命令验证 JSON 输出。

「真实后端」是整个项目的硬性原则。README 写得很明确：CLI 必须调用真实应用做渲染，不给 GIMP 配 Pillow 替身，不给 Blender 写自定义渲染器。后端软件缺失时测试直接失败（fail），不是跳过（skip）。CLI 生成合法的项目文件，把渲染交给真软件。

HARNESS.md：18 个应用喂出来的工程经验

比代码更值钱的可能是项目里的方法论文件 HARNESS.md，它把 18 个生产级 harness 的构建经验压缩成几条关键教训：

渲染间隙（Rendering Gap）：GUI 应用在渲染时才应用效果。CLI 只操作项目文件、用粗糙的导出工具收尾，特效会被静默丢弃。解法是「原生渲染器 + 滤镜翻译 + 渲染脚本」三层结构。

滤镜翻译（Filter Translation）：在格式间映射效果（比如 MLT 到 ffmpeg）时，要处理重复滤镜合并、交织流排序、参数空间差异和不可映射效果四类问题。

时间码精度：非整数帧率（29.97fps）会累积舍入误差，要用 round() 而非 int()，测试里留 ±1 帧容差。

输出验证：导出命令退出码为 0 不代表导出成功。要验证魔数、ZIP 结构、像素分析、音频 RMS 电平、时长——每一项都可能出错。

这几条教训指向同一个事实：给专业软件包一层 CLI，难点在理解软件的渲染管线和数据格式，命令语法的生成只是最后一环。这也是项目选择「生成接口」而不是「重实现功能」的原因：重实现必丢功能，接口化能保住全部能力。

用起来的三种方式

第一种，直接用现成的。项目配套的 CLI-Hub 是个注册表加包管理器：pip install cli-anything-hub 之后，cli-hub list 浏览、cli-hub install gimp 安装、cli-hub launch gimp 运行。社区贡献的 harness 覆盖 Blender、GIMP、LibreOffice、OBS Studio、Kdenlive、FreeCAD、QGIS、Obsidian、Joplin、Calibre、Zoom、n8n 等，注册表还收编了一批公共第三方 CLI。

第二种，给 agent 装上「自助安装」能力。CLI-Hub 提供一个 meta-skill（npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill -g -y），装上后 agent 接到任务会自己去注册表找合适的 CLI、安装、读它的 SKILL.md、然后干活。

第三种，注册表里没有的就现生成。把目标软件的源码或仓库路径交给 /cli-anything，七个阶段跑完得到一个新 harness。项目在 When to Use 文档里列了适配场景：开源仓库（VSCodium、WordPress、Calibre）、AI/ML 平台（ComfyUI、Ollama、Stable Diffusion WebUI）、数据分析工具（JupyterLab、Superset、Metabase）、开发工具（Jenkins、Gitea、pgAdmin）、科学计算（FreeCAD、QGIS、ParaView）、企业办公（NextCloud、GitLab、Grafana）等十几个类别。

实际效果可以看官方 demo：一个 agent 用 FreeCAD harness 组装「好奇号」火星车模型，全程发布预览包、刷新实时预览、记录命令到画面的轨迹历史；另一个 agent 用 Draw.io harness 纯靠 CLI 命令画出完整的 HTTPS 握手时序图（TCP 三次握手、TLS 协商、加密数据交换、四次挥手），4 分钟出图加 PNG 导出；还有 agent 用 Slay the Spire II harness 玩卡牌游戏——读游戏状态、选卡、规划路线，全部通过命令行完成。

边界与适用性

这套方案有两个前提值得说清楚。

其一，目标软件要有可编程的入口。CLI-Anything 生成的是「调用真实后端的接口层」，软件本身得暴露 API、脚本接口或者可从源码分析出调用路径。对完全封闭、无任何脚本能力的 GUI 程序，这条路的可行性取决于逆向分析的成本。商业闭源软件的授权边界也需要单独评估——项目里 ArcGIS Pro 的 harness 就明确写的是封装官方 ArcPy SDK，而不是从源码生成。

其二，生成质量依赖背后的编码 agent。七阶段管线是让 Claude Code、Cursor 这类 agent 执行的，管线设计再好，最终代码质量仍受底层模型能力约束。2464 个测试通过率 100% 是项目核心 harness 的成绩，社区新贡献的 harness 质量则靠贡献流程里的评审和测试基线兜底。

对想在自家工具链上落地的开发者，项目的建议路径是从 CLI-Hub 装现成的开始，确认工作流跑通后再考虑给内部工具生成 harness。内部系统的接口化有个额外收益：--json 输出让 agent 的操作结果可以直接进下游程序，这是 GUI 自动化做不到的。

GUI agent 和 agent-native 接口这两条路线大概率会长期并存——前者处理「只能看不能碰接口」的场景，后者在软件可以被结构化封装时提供数量级的可靠性优势。CLI-Anything 给后一条路线补上了最关键的一块：接口生成的自动化。项目仓库在 GitHub 的 HKUDS/CLI-Anything，技术报告 arXiv:2606.03854，Apache 2.0 协议。

来源：