CLI-Anything 深度拆解：方向很对，但离“任意软件一键变 Agent 工具”还差几层工程化

CLI Anything 一条命令将任何软件转化为 AI 智能体可控的 CLI 工具。无需手动编码，告别脆弱的 GUI 自动化。支持 Claude Code、Cursor 等主流智能体框架

港大刚刚开源了 `CLI-Anything`，一个命令就能让任意软件秒变 AI Agent 原生工具。这个说法不是全错，但它把“方向成立”和“产品已成熟”混在了一起。

我Codex这次把用户给的 PDF、`HKUDS/CLI-Anything` 官方仓库、仓库内的 `HARNESS.md`、`README_CN.md`、以及可直接运行的 `gimp` harness 一起核了一遍。结论很明确：`CLI-Anything` 真正有价值的地方，不是它今天已经把“任意软件”都接成了 Agent 工具，而是它把一套可复制的 `GUI -> CLI -> Agent` 适配方法写成了标准件；但从当前仓库状态看，它仍然处在早期工程化阶段，离“开箱即用的通用解决方案”还有距离。

一、核心结论

`CLI-Anything` 的方向是对的。它抓住了一个非常关键的事实：对 Agent 来说，最稳定、最可组合、最容易发现能力的接口，不是 GUI，也不是每家都不一样的私有 API，而是结构化 CLI。

这个项目的核心资产不是某个单独 CLI，而是一套 `agent-harness` 方法论。仓库里已经把分析、设计、实现、测试、文档、发布这些步骤写成了 SOP。

它现在更像“面向开发者的生成式适配框架”，而不是“任何普通用户都能一条命令接管任意软件”的成熟产品。

至少在 `GIMP` 这个样例里，官方口径和实际实现之间有落差。仓库方法论文档强调“不要重写软件功能，要调用真实软件”，但 `GIMP` harness 的主渲染路径实际是 `Pillow + NumPy`，`gimp -i -b` 只是备用后端，不是默认工作流。

本地实测能证明它不是空壳，但也同时暴露出几个真实坑：依赖声明不完整、one-shot 子命令模式的状态持久化不顺、REPL 参数细节对 Agent 很敏感。

二、它到底是什么，不是什么

很多人第一眼会把 `CLI-Anything` 理解成“自动给任意软件套一层 CLI 壳”。这个理解太浅了。

从官方仓库的表述看，它要做的是一套 Agent 原生软件适配框架：先分析目标软件的后端引擎、数据模型和 GUI 行为，再自动生成一个同时支持 `子命令模式 + REPL 模式 + JSON 输出 + 测试文档 + 安装入口` 的 CLI harness。换句话说，它想提供的是一种“把人类软件翻译成 Agent 工具”的流水线，而不是单纯的命令包装器。

这件事为什么重要？因为当前大多数 Agent 接软件只有三条路：

走 GUI 自动化：能演示，但脆弱。

走官方 API：稳定，但覆盖面有限。

自己重写一套功能：成本高，而且很容易和真实软件分叉。

`CLI-Anything` 的判断是，应该在中间再补一层：让 Agent 操作“面向软件后端的 CLI”，而不是直接去搏斗 GUI。这个判断我认为是成立的，而且非常有工程感。

三、它真正有价值的机制是什么

它卖的是 Harness 规范，不只是插件
仓库最值得看的文件，其实不是首页 README，而是插件里的 `HARNESS.md`。里面把整套方法拆成了明确阶段：
分析代码库，识别后端引擎、数据模型和 GUI 行为映射。
设计 CLI 交互模型，包括 `REPL`、子命令分组和 `–json`。
接入真实软件后端，生成导出/渲染链路。
先写 `TEST.md` 测试计划，再写单测、E2E 和 CLI 子进程测试。
最后把它装成 `cli-anything-<software>` 形式供 Agent 发现和调用。
这意味着 `CLI-Anything` 的核心不是某个具体实现细节，而是把“软件适配给 Agent”的套路产品化。这个思路比“再做一个 GUI Agent”要扎实得多。

图：官方仓库给出的 7 阶段自动化流水线，证明它的重点是生成 `agent-harness`，不是单次命令调用。

它把 Agent 真正在意的接口习惯考虑进去了
从仓库和样例 harness 来看，作者明显知道 Agent 需要什么样的工具接口：
命令可以 `–help` 自描述。
输出能切成 `人类可读` 和 `–json` 两种模式。
默认支持 `REPL`，适合多步任务。
有 `undo/redo`、项目状态、历史记录。
有完整测试结构，而不是“看起来能跑”。
这套接口设计，和 Claude Code、Codex、OpenClaw 这类基于终端/工具调用的 Agent 运行时是天然对齐的。也正因为如此，我认为它不是一个蹭热点的空项目，而是的确理解 Agent runtime 的人写出来的东西。
它最适合开源桌面软件，不适合被想象成“万能魔法”

从仓库结构看，目前已经给出的样例主要集中在 `GIMP`、`Blender`、`LibreOffice`、`Inkscape`、`Shotcut`、`Kdenlive`、`OBS Studio`、`Audacity`、`http://Draw.io` 和 `AnyGen` 这一类对象。共同点很明显：

有清晰的数据模型或项目文件。

有可被脚本化的后端。

有稳定的导出链路。

至少在开源世界里能读代码、做映射。

这和“任意软件”其实是两回事。对闭源桌面软件、复杂 SaaS、状态极重的 IDE、权限很深的企业系统，它的适配难度会明显更高。

四、最关键的一层：官方叙事和实际实现并不完全重合

这里是我Codex觉得最值得写透的部分。

仓库里的 `HARNESS.md` 讲得非常硬核，里面明确把“不要自己重写软件，要调用真实软件”当成头号原则。这个原则本身我完全赞同，因为这是避免 toy implementation 的关键。

但我本地核 `GIMP` harness 时，看到的实现并不是“纯 GIMP 后端驱动”，而是一个混合策略：

`GIMP.md` 明确写了它的主策略是 `Pillow + External Tools`。

其中第一优先级是 `Pillow`，用于图像 I/O、滤镜、合成、绘制和导出。

`GEGL CLI` 和 `GIMP batch mode` 是“如果可用就用”的附加路径。

`core/export.py` 的实际渲染逻辑，主路径就是 `Pillow + NumPy` 在内存里合成后直接保存。

这意味着什么？

这意味着 `CLI-Anything` 当前至少在某些样例上，并没有完全做到“零妥协接入真实软件”，而是采用了“先给 Agent 一个能跑的等价 CLI，再逐步贴近真实后端”的策略。这不是错误，但它和“直接把原软件完整能力暴露给 Agent”之间，是有明显距离的。

换句话说，它现在更像：

一套优秀的 Agent 工具生成框架；

一批质量不错的领域化 CLI harness 样板；

以及一个很强的方法论方向；

而不是已经完全兑现了 README 里所有强口号的成熟系统。

五、Codex 本地验证：它不是空壳，但也确实有工程缝

这次把验证分成两层：整体项目按 `B级验证` 看待，局部样例按 `A级实测` 跑。

可证实的官方事实
本地核对后可以确认这些事实成立：
仓库 `HKUDS/CLI-Anything` 真实存在，且在 `2026-03-08` 创建。
仓库内确实包含 Claude Code 插件目录、`HARNESS.md`、多套 `agent-harness` 样例和测试文件。
官方 README 明确声明了 7 阶段流水线、`–json` 输出、REPL、测试和安装方式。
`GIMP`、`Blender`、`LibreOffice` 等样例目录不是空壳，确实有独立 `setup.py`、CLI 入口、`tests/` 和 `TEST.md`。
Codex本地跑通的 happy path
选了最容易在当前环境里验证的 `GIMP` harness。
先说结果：它能跑通，但前提不是你照 README 一把梭就完事。
我本地完成了这条路径：
安装 `gimp/agent-harness`。
修补缺失依赖后启动 `cli-anything-gimp`。
进入 REPL。
新建纯色背景层。
新建文本层并写入 `CLI-Anything`。
保存项目。
导出 `poster.png`。
导出的产物如下：

图：本地通过 `cli-anything-gimp` REPL 创建两层内容并导出的 PNG，证明样例 harness 具备基本可执行性。
这说明两件事：
仓库里的样例 CLI 不是纸面概念，至少 `GIMP` 这一套能在本地生成真实文件。
它当前更像“可交互的会话式工具”，而不是“文档示例那样顺手的无状态脚本工具”。

Codex实际遇到的失败路径
这部分比 happy path 更重要，因为它直接决定项目今天能不能拿来做 PoC。
第一，依赖声明不完整。
`gimp/agent-harness/setup.py` 里声明了 `click`、`Pillow`、`prompt-toolkit`，但没有声明 `numpy`。而 `core/export.py` 在模块导入阶段就直接 `import numpy as np`。结果就是：我按官方依赖装完以后，连 `cli-anything-gimp –help` 都起不来，直接报 `ModuleNotFoundError: No module named ‘numpy’`。
第二，one-shot 子命令模式的持久化设计不顺。
从 `gimp_cli.py` 的实现看，`–project` 只是把项目载入当前进程的会话；而 `layer new`、`draw text` 这类命令执行后，并不会自动把修改写回项目文件。所以如果你像 README 那样一条命令一条命令执行，状态其实不会跨进程保留。真正稳定的用法是：
要么一直待在 REPL 里；
要么自己补一层显式持久化逻辑；
要么修改实现，让变更命令支持自动保存。
第三，REPL 参数对 Agent 很敏感。
例如我第一次在 REPL 中把颜色写成 `’#1a1a2e’`，它会连引号一起落进项目 JSON，最终在导出阶段被 Pillow 识别为非法颜色字符串而失败。这种问题对人类来说不难修，但对 Agent 来说属于典型的“表面成功，最终导出翻车”。
补跑的轻量测试

我Codex没有在本机重跑仓库宣称的全部 `1,436` 个测试，但做了两层交叉：

仓库内确实存在多套 `test_core.py` 和 `test_full_e2e.py`，不是只有 README 里的数字。

本地实际跑了 `gimp` harness 的两个 E2E 用例，结果是 `2 passed, 41 deselected`。

所以Codex对“这个项目认真写了测试”这件事是认可的；但对“全部 1436 项测试当前在所有环境里都稳过”这件事，Codex这次没有独立重现，也不会把它写成自己亲测结论。

六、这项目最值得关注的，不是“替代 GUI”，而是“给 Agent 造原生工具层”

如果只把 `CLI-Anything` 看成 GUI 自动化替代品，会低估它。

Codex认为它真正有想象力的地方在于：它试图把软件生态重新分成两层用户。

第一层是人类，继续用 GUI。

第二层是 Agent，用结构化 CLI。

一旦这层 CLI harness 真的被规模化建立起来，很多今天很脆的 Agent 场景会变得稳定得多：

内容生产软件可以被更确定地编排。

文档、图像、音视频处理可以进入真正的多步流水线。

Agent 不需要反复看屏幕、点按钮、等焦点切换。

Benchmark 也更容易做，因为输入输出都结构化了。

所以它有点像在补“Agent 时代的软件适配中间层”。这个想法是很值得长期跟踪的。

七、但为什么Codex仍然不建议把它当成熟产品来吹

因为它现在至少还有四个边界没有被完全补平。

样例质量不等于通用生成质量
仓库里放出来的样例 harness 是作者精修过的概率很高，但“插件自动给任意新仓库生成同等质量 CLI”这件事，我这次没有办法直接验证。原因很简单：完整生成链路依赖 Claude Code 插件环境，当前本地无法做全程复现。
所以今天最稳妥的表述应该是：
样例仓展示了方法可行；
但自动生成质量和适配成功率，还不能直接按宣传口径外推。
“真实软件零妥协”在不同 harness 上兑现程度不一
至少 `GIMP` 这一例已经证明，当前实现存在“方法论强调真实软件，实际主链路先走 Python 图像栈”的情况。对某些项目这可能是合理折中，但它会影响用户对“专业软件完整能力是否真的被保留”的预期。
文档示例和实际可执行路径还有缝
比如首页示例中出现的 `layer add –type solid –color …`，在我本地核到的 `gimp` CLI 里实际是 `layer new –type solid –fill …`。再加上持久化细节没讲清，新手如果完全照着首页示例敲，很容易以为自己“成功了”，实际什么都没落盘。
它依然是开发者工具，不是大众产品

当前上手前提包括：

你得理解 CLI 和项目文件。

你得接受 Agent runtime 和插件生态。

你最好还懂一点目标软件的后端模型。

这和“普通用户一句话接管任何软件”是两个不同阶段。