CLI-Anything：让 AI Agent 操控一切软件，港大这个项目是认真的吗？

我在 GitHub 上泡了五年多，看到这个数字的第一反应是警惕：又一个靠”Agent”概念冲上热榜的项目。今年上半年带 Agent 标签的新仓库，十个里有八个是套壳 Demo，README 写得天花乱坠，跑起来第三条命令就报错。

但 CLI-Anything 不太一样。它做的事情既激进又务实：**直接把 Blender、GIMP、OBS Studio 这些图形软件，一键转成 AI Agent 能调用的命令行接口。**不是让 Agent 去”看懂”屏幕上的按钮，而是直接给软件加一层 CLI 皮，Agent 用 blender render --scene house.blend 就能完成操作。

这个思路拆穿了很简单：今天的软件是为人类设计的，菜单、对话框、拖拽。但明天的用户可能是 AI Agent，它不需要图形界面，只需要命令和 JSON 输出。CLI-Anything 做的就是把前者翻译成后者，而且整个过程是全自动的。

这篇文章想搞清楚的不是它支持了多少款软件这种表面数据，而是三个更核心的问题：这套自动化流水线产出的 CLI 质量到底怎么样？它在什么场景下是真需求，什么场景下是过度设计？以及值不值得你现在就开始跟这个项目？

为什么值得关注

先说我真正改观的那个瞬间。翻完它的测试报告之后，我开始认真对待这个项目了。

整个仓库有 2,461 个测试，100% 通过率。注意，不是单元测试的 Mock 数据——是真的启动 Blender，真的调用 GIMP 的 API，真的让 LibreOffice 后台渲染一个文档，然后验证 CLI 的输出是否符合预期。Blender 208 个测试，Inkscape 202 个，Audacity 161 个。如果目标软件没装，测试就直接失败，不跳过不标记。这种”零妥协依赖”的测试策略在开源项目里相当少见，它意味着团队不是在炫技，是真的想把质量做扎实。

测试之外，这套自动化流水线本身的设计也值得拆开看看。整个流程分 7 个阶段：Phase 1 扫描源码映射 GUI 操作到 API，Phase 2 自动设计命令组和状态模型，Phase 3 生成带 REPL、JSON 输出、撤销/重做的 Click CLI，后续四个阶段覆盖测试计划、测试实现、文档和 PyPI 发布。它不是在”写一个 wrapper”，而是在完整复现一个人类工程师从零构建 CLI 的全流程，只不过跑得更快。

第三个亮点是 Agent 原生设计。每条命令都内置了 --json 标志输出结构化数据，Agent 通过 --help 和 which 命令发现能力。配合自动生成的 SKILL.md 文件，Claude Code 和 Pi 等主流 Agent 平台能零配置接入。这不是”顺带支持一下 Agent 调用”，而是从一开始就以 Agent 为第一用户来设计接口。

最后说说 CLI-Hub。它本质上是一个”Agent 工具的包管理器”：cli-hub search 搜索可用 CLI，cli-hub install 一键安装，cli-hub launch 启动运行。这层生态设施的存在说明团队不是在做一次性 Demo，而是在铺 Agent 时代的软件分发基础设施。从 25 个 Open PR 来看，社区贡献已经启动，虽然距离 npm 那种自驱生态还很远。

不过也别急着被测试数和自动化震撼。有个社区贡献者实际跑了 GIMP CLI 的完整流程后，发现了一个很诚实的 bug：创建图层和添加文字的命令虽然返回了成功，但数据并没有写入会话文件。代码级定位结果是 layer_new 函数调了 snapshot() 保存到 undo 栈，却漏掉了 save_session() 的调用。这个 bug 影响范围不小，layer_remove 等修改操作都有同样的问题。能定位到这种细粒度 bug 的社区反馈，比一万条”这个项目很好”式的评论更有价值。

不过数据好看是一回事，实际用起来顺不顺手是另一回事。上手门槛到底在哪？

上手什么感觉

CLI-Anything 的上手门槛集中在一条硬约束上：你得先装好目标软件。因为它的测试和运行都依赖真实后端，Blender CLI 需要本地装了 Blender，GIMP CLI 需要装了 GIMP。如果你只是想快速感受一下”Agent 操控软件”是什么体验，建议从轻量级的开始。Draw.io（138 个测试通过）和 Ollama（98 个测试通过）装起来不费劲，跑出来的效果也直观。

对于 Claude Code 用户，安装最简单：

/plugin marketplace add HKUDS/CLI-Anything

其他 Agent 平台（Pi、OpenClaw、Codex 等）也有对应的安装脚本，但整合深度参差不齐。Claude Code 是目前唯一被标注为”主要支持”的平台，这也是项目官方的主推方向。装完之后 Agent 就能自动发现并调用已注册的 CLI 工具，不需要额外配置。

如果你有自己的项目想转成 Agent 可用的命令行，流程也不复杂。装好 CLI-Anything Plugin 之后跑一次 /harness 命令，流水线会自动分析你的代码库，生成 CLI 工具链和测试套件。但文档里也诚实地说了一句”一次运行可能无法完全覆盖，可能需要多次 /refine“。这不是客套话，是从社区实际使用反馈里总结出来的。

一个容易被忽略的门槛：项目依赖的模型级别很高。文档里明确写了需要 Claude Opus 4.6 或 Sonnet 4.6 级别的基础模型才能稳定输出。用小模型跑流水线，生成质量会明显下降。对个人开发者来说，这个 API 调用成本不算低。

体验上的门槛聊完了，但比”难不难用”更关键的问题是：什么时候该用，什么时候不该用？

什么时候用，什么时候别用

场景判断是做技术选型最核心的能力，这部分我不会含糊。**应该用的情况：**如果你的日常工作里频繁涉及 GUI 软件的批量操作——比如每天要渲染几十个 3D 场景、批量处理上百张图片、自动化生成图表并导出——并且你已经在用 Claude Code，那 CLI-Anything 能直接把你的 Agent 变成这些软件的批量操作员。港大演示的 FreeCAD 火星车建模、Draw.io 自动绘制 HTTPS 握手图，都是这类场景的样板。

CI/CD 管道里的自动化是另一块高价值场景。传统上，Blender 渲染和 Audacity 音频处理很难塞进自动化流水线，因为它们绑着图形界面。CLI-Anything 生成的 CLI 拆掉了这堵墙，让以前只能手动操作的软件也能进 CI。对于需要自动化多媒体处理的团队，这直接省掉了一套胶水脚本的维护成本。

**不该用的情况同样需要说清楚。**有位社区开发者在实际跑过之后给了一个很精准的判断：对于能直接写代码的 Agent（比如 OpenClaw 带 exec 工具的），CLI-Anything 的价值有限。这类 Agent 可以直接用 Python 调用 Pillow 操作图像、用 subprocess 启动 Blender，不需要中间多一层 CLI 翻译。但对于 CLI 为主的 Agent（比如 Claude Code），CLI-Anything 提供了一个标准化的解决方案。

另外，如果你需要的操作超出了 CLI 预定义的命令范围，就得面对一个选择：改 CLI 源码扩展功能，还是直接用 Python 写脚本。GIMP CLI 目前的命令列表里没有滤镜操作和路径绘制，对于需要精细控制的图像处理任务，这个覆盖度不够用。

功能受限的软件也别贸然上。如果你的目标软件不在支持列表里，自己跑 /harness 生成的 CLI 需要迭代优化，不是一次就能出成品的。而且延迟也是个问题：Agent→CLI→目标软件的调用链，每一步都有开销，Blender 启动本身就要好几秒，不适合对延迟敏感的场景。

场景判断做完了，但还有一个问题决定了这个项目值不值得长期跟：社区还活着吗？

社区怎么样了

截至 2026 年 6 月，CLI-Anything 有 42.6K Stars、4K+ Forks、788 次提交，35 个 Open Issue，25 个 Open PR。Stars 数确实好看，但我更关心维护节奏。翻一下 5 月底到 6 月初的提交记录：Hermes 技能提案、ArcGIS Pro 公共注册、Joplin/Calibre CLI 合并、多个 harness 安全加固、n8n REPL 修复。合入密度相当高，这不是那种”发完论文就不管了”的学术项目。Apache 2.0 协议，商业友好。

项目由香港大学数据科学实验室维护，有 arXiv 技术报告（2606.03854）作为方法论背书。学术机构的项目通常有个风险：核心贡献者集中在实验室内部，Bus Factor 不高。如果研究方向转了或者核心成员毕业离开，项目持续性就会打问号。

中文技术社区的关注度也不低。知乎、CSDN、掘金上 3 月份出现了多篇深度分析文章，讨论热度在 GitHub Trending 榜单霸榜期间达到高峰。有意思的是，这些文章不是那种”一键三连求 Star”的水文，好几篇都做了实际的代码调试和 bug 定位，社区的技术反馈质量相当在线。

不过还是要冷静一下。从 3 月爆火到现在的三个月里，仓库的合并速度确实很快，但这是”初期爆发”还是”可持续节奏”，还需要再观察一两个季度。快速增长阶段的质量控制往往会在后期暴露问题。目前 35 个 Open Issue 对于一个 42K Stars 的项目来说不算少，需要关注 Issue 响应速度是否跟得上。

社区数据和项目事实都摆在这了。那我的真实判断是什么？

我的真实看法

分析到这里，我的核心判断已经很清晰了：CLI-Anything 踩在一个真实的趋势上，而且目前没有真正的竞品。

“Agent 需要能操控软件”不是炒作。Claude Code 已经证明 Agent 可以编程，那下一步自然就是操控所有软件。CLI-Anything 解决的是编程之外的操作需求，用的是最务实的方式：不改软件本身，只加接口层。这种”不侵入改造、只外挂 CLI”的策略比直接魔改软件源码高明得多，它的可移植性和维护成本都更低。

从技术方案看，7 阶段自动流水线的递进关系经得起推敲。先理解源码，再设计接口，再实现测试发布。这基本就是人类工程师写 CLI wrapper 的标准流程，只是用 AI 加速了每一步。不是那种”一个 LLM call 就说搞定了”的玩具。

但话说回来，有两点让我保持谨慎。

第一，对前沿模型的硬依赖。需要 Claude Opus 4.6 级别来保证流水线质量，个人开发者用起来 API 成本不低。如果未来模型能力波动或定价调整，整个流水线的可靠性和经济性都会受影响。这是所有”AI 驱动的自动化工具”的先天软肋。

第二，项目的长期价值取决于生态广度，不取决于实验室自己维护的 CLI 数量。目前 25 个 Open PR 说明社区参与在启动，但距离”第三方自发贡献”的自驱生态还有质变要跨。如果 CLI-Hub 能像 npm 那样让社区自动生长，那它就不是工具集，是 Agent 时代的软件分发基础设施。如果做不起来，它就只是一个”香港大学的高质量学术 Demo”。

我的最终建议分成三档：如果你今天就在用 Claude Code 做开发，工作流涉及 GIMP、Blender、OBS 等已支持的软件，值得现在就试试，前提是接受”早期开发阶段”的成熟度。CSDN 上那位开发者贡献的 bug 定位就是最好的提醒：它不一定完美，但你可以参与把它变好。如果你还在观望，盯两个信号：CLI-Hub 上第三方 CLI 数量何时超过 50 个，以及 Cursor/Windsurf 的支持何时正式上线。如果你根本不用 Claude Code，且手上的自动化需求可以用 Python 脚本覆盖，当前阶段没必要硬上。判断交了，相关的入口链接汇总如下。

资源地址

链接都在这了。最后聊聊：你现在该干什么？

说完了，该你了

CLI-Anything 不是一个让你”Wow 太酷了”然后第二天就忘了的项目。它解决的是一个正在发生的真实问题：Agent 越来越能干了，但软件还没准备好被 Agent 使用。港大这个团队把”软件 Agent 化”这件事做到了当前最扎实的水平，不完美，但方向对。

建议的切入路径：Claude Code 用户直接装插件，用 Draw.io 或 Ollama 跑一个小 Demo，感受下 Agent 操控软件是什么体验。别一上来奔着 Blender 208 个测试去，先从轻量的来，路径更顺。

还在犹豫的话，记住两个信号：CLI-Hub 第三方贡献数，和更多的 Agent 平台支持。任何一个亮了，都说明生态在从”实验室项目”往”社区项目”的方向走。到那时候再入局也不迟。

FAQ

Q1：CLI-Anything 和 MCP（Model Context Protocol）是什么关系？

A1：互补，不冲突。 MCP 解决 Agent 如何调用外部服务（API、数据库），CLI-Anything 解决 Agent 如何操控本地软件。两者覆盖的场景不同，实际上项目 Demo 里已经展示了 FreeCAD 通过 MCP 桥接 Agent 的用法，说明二者可以协同。

Q2：生成的 CLI 能直接上生产环境吗？

A2：取决于目标软件。 GIMP、Blender、Inkscape 等 100+ 测试通过的软件，CLI 质量有基础保障。但社区实际使用中发现过保存 bug（如 GIMP CLI 的图层操作未调用 save_session），说明还需要踩坑和迭代。自己跑 /harness 生成的定制 CLI 更不要直接当成品用，至少做一轮 /refine。

Q3：不用 Claude Code 能用吗？

A3：能，但体验打折扣。 Pi、OpenClaw、Codex 等也有支持，但整合深度和测试覆盖都不如 Claude Code 的主线。Cursor 和 Windsurf 还在”即将推出”。不排斥 Claude Code 的话，用主推平台体验最完整。

Q4：和直接写 Python 脚本操控软件比，优势在哪？

A4：可发现性和可组合性。 Python 脚本只有你知道怎么调用。CLI-Anything 生成的命令行带 --help、--json 和 SKILL.md，任何 AI Agent 都能自动发现。目标是 Agent 协作而非人工自动化时，差异很明显。但如果你的 Agent 本身就能写代码（如 OpenClaw 的 exec 工具），直接用 Python 可能更灵活。

Q5：闭源软件能生成 CLI 吗？

A5：现阶段不行，质量会打折扣。 自动化流水线依赖源码分析来映射 GUI 操作到 API。只有编译好的二进制文件时，生成效果明显下降。路线图里提到了支持闭源软件打包 API 为 CLI 的计划，但还没落地。

Q6：支持多少款软件？都覆盖哪些领域？

A6：18+ 类应用，涵盖 20 余款软件。 包括图像编辑（GIMP）、3D 渲染（Blender）、矢量图形（Inkscape）、音频制作（Audacity）、办公套件（LibreOffice）、直播录制（OBS Studio）、视频编辑（Kdenlive/Shotcut）、图表绘制（Draw.io/Mermaid）、AI 推理（Ollama/ComfyUI）、游戏开发（Godot/s&box）、电子书（Calibre）、笔记（Joplin）等。

Q7：项目团队稳定吗？会不会弃坑？

A7：学术项目，但维护节奏在线。 香港大学数据科学实验室维护，arXiv 论文已发布，788 次提交且近三个月合入密度很高。Apache 2.0 协议无风险。弃坑风险确实存在（学术项目的通病），但目前没有减速迹象。关注未来 3-6 个月的提交频率和 Issue 响应速度。