别再让 AI 盯着屏幕点鼠标了：CLI-Anything 给每个软件配一条命令行

看着 AI agent 操作桌面软件，会有一种特别的绝望。它先截个图，猜菜单位置，点一下，点空了，再截一张图。二十秒过去，它把一个滑块挪了两像素，什么也没学会。

来自香港大学数据智能实验室（HKUDS）的 CLI-Anything 主张：这套路子从根上就错了。别教 agent 看屏幕，给软件一条命令行，让 agent 自己敲。

它的口号只有一句：让所有软件都变成 agent-native。实现方式没那么花哨，但更有意思——只要你有某个应用的源码，把一条命令指向它，一条七阶段流水线就会为它生成结构化的 CLI 封装，测试、文档、用 pip 就能装的包，全都齐了。

七个阶段

整条流水线跑在编码 agent 里，用 /cli-anything <source path or repo> 调用。分析：扫描源码，把 GUI 操作映射到 API 调用。设计：确定命令分组、状态模型、输出格式。实现：搭一个基于 Click 的 CLI，带 REPL、JSON 输出和撤销/重做。规划测试：把测试计划写进 TEST.md。写测试：把测试套件实现出来。写文档：把结果记回同一个文件。发布：生成 setup.py，把命令装进你的 PATH。

另外还有一个第 6.5 阶段，会生成 SKILL.md，让产出的 CLI 能被 agent 当作一个 skill 发现，而不需要人工去接线。此外还有 /cli-anything:refine 命令，做差距分析，一步步把覆盖面扩上去。

命名规则是故意定死的：命令放在 cli_anything.<software> 命名空间下，包名统一叫 cli-anything-<software>。无聊的约定才让工具链能互相拼装，而这个项目显然已经在想象一个存在几百个这种封装器的世界了。

真后端，不是玩具级重写

真正把这东西和周末项目区分开的细节是：这些封装器驱动的是软件本尊。LibreOffice 出的是真 PDF，Blender 渲的是真 3D 场景，GIMP 对图片做的事就是 GIMP 会做的事。另一条路——用 Python 重写应用的一部分行为——做出来的东西看起来能用，直到你需要某个被重写时跳过的功能。

代价是你得把这些应用装上。好处是产出和人类操作员做出来的东西没有区别，因为用的是同一个引擎。

每条命令在被要求时都会吐 JSON，这就是“agent 能解析的 CLI”和“agent 得眯着眼看的 CLI”之间的区别。有带状态的 REPL 做交互式操作，也有普通子命令给脚本用，另外还有持久化的项目状态和撤销/重做。

它覆盖了什么

范围是刻意做宽的，读起来像一份“大家一直想自动化、一直没成功”的软件清单：GIMP、Blender、Kdenlive 做创意；LibreOffice 处理办公文档；Godot 和 s&box 做 3D 和游戏；QGIS、FreeCAD 面向科学与工程；AI 这边是 ComfyUI 和 Ollama；调试则有 LLDB、RenderDoc、Nsight。

如果你做图像相关的工作，ComfyUI 这一项值得停一下。ComfyUI 本来就有 API，但那是图 API——节点、连线，外加一坨 JSON blob，而它的 schema 取决于你装了哪些自定义节点。一个暴露意图级命令、有明确状态模型和 JSON 输出的 CLI 封装，正是 agent 需要的东西：不用去逆推某人的 workflow 文件，就能跑一条图像流水线。

关于测试的那个说法

仓库报告了大约 2,461 个测试：1,732 个单元测试、579 个端到端、19 个 Node.js 测试，声称 100% 通过。E2E 那一层跑在真实后端上，在这里这是唯一有意义的 E2E。如果 LibreOffice 不再产出 PDF，测试就会挂，你会在 agent 生成四十个坏文件之前知道。

把“100%”当成一张快照，而不是一份保证。生成出来的测试套件有个老毛病：会把生成器自己的假设一并写进去。但那个四层结构——单元、原生 E2E、真实后端 E2E、CLI 子进程——形状是对的。

诚实列出来的局限

README 里列了，这是个好兆头。

它依赖前沿模型。Claude Opus 4.6 或 Sonnet 4.6、GPT-5.4 这个级别。模型弱一点，产出的 CLI 就不完整，或者干脆是错的，需要大量人工修复——也就是说，这工具好不好用，绑在一份你未必有的订阅上。

它依赖源代码。流水线分析的是源码；如果你手上只有编译好的二进制，质量和覆盖率会明显下降。这就悄悄排除了大部分商业软件，而人们真正想自动化的，大部分恰恰是这些。

一次运行很少能覆盖全部。做好心理准备，得跑好几遍 /refine，harness 才能到生产级。有些 CLI 要求上游应用已经装好。各平台成熟度也不一样——Goose、OpenCode、Codex、Hermes、Reasonix 都标着实验性，Windows 用户还会撞上 bash 和 cygpath 的兼容问题。

没人愿意问的维护问题

生成的封装器是一份承诺。你一旦采用 cli-anything-libreoffice，就在 agent 和应用之间加了一层，而这一层必须在 LibreOffice 改动文档模型、或者 Blender 给某个 operator 改名之后，继续能用。

落到实践上就是三件事。生成的 harness 要放在你自己的仓库里，别依赖别人的，这样你才能打补丁。升级底层应用时要重跑流水线，并 diff 结果。还有，把 TEST.md 当契约看——测试是你能在 agent 产出四十个畸形文件之前发现问题的唯一原因。

经济上算得过来，因为重新生成很便宜。这才是真正的洞察：封装器不必永远完美，因为生成它的东西可以再生成一次。传统 SDK 维护成本高，是因为那玩意儿是人写的。这个不是。

CLI-Hub 这一注

项目里有个包管理器 cli-anything-hub，用来浏览和安装社区做的封装器。这是整件事上行空间最大、风险也最明显的一块。一个生成式 CLI 的 hub，就是一个以你的权限运行、会碰你文件的代码 hub。

它会变成有用的生态，还是变成一桩供应链事故，完全取决于项目是否把审查当作发布的一部分。目前的答案是“部分如此”：测试是生成的，文档是生成的，审查则是社区爱怎么做就怎么做。

为什么这件事不止关乎这个仓库

两年来，computer use 一直是行业最爱的 demo、最不爱做的产品。demo 能成，是因为有人精心写好了任务脚本。产品卡住，是因为像素级控制在骨子里就是脆的，而且这种脆弱永远不会真正消失。

CLI-Anything 提出了另一种分工：与其让 agent 更擅长当人，不如让软件更擅长当机器。每一棵有源码树的应用程序都成了生成接口的候选者，而这种接口是可测试的——截图循环永远做不到这一点。

取舍是真实的。生成的 CLI 只和写它的模型一样好，而且上游应用一变，总得有人来管这个封装器。但方向是对的。一个 agent 敲下 cli-anything-blender render --scene scene.blend --out frame.png 并拿到确定性输出，做的事从根本上就比一个在视口里乱点、然后祈祷的 agent 有用得多。