CLI-Anything 是由香港大学数据智能实验室 HKUDS 主导的开源项目,截至 2026 年 3 月已在 GitHub 收获 20.5k Star、1.8k Fork,定位明确——"让所有软件变成 Agent-Native"。项目当前覆盖 17 款专业软件,包含 GIMP、Blender、Inkscape、Audacity、LibreOffice、OBS Studio、Kdenlive、Shotcut、Zoom、Draw.io、Mermaid、AnyGen、NotebookLM、ComfyUI、AdGuard Home、Ollama、Mubu 等,累计 1,839 个测试 100% 通过率,分布在 1,355 个单元测试与 484 个端到端测试。它给 Agent 操控软件提供了一条不同于 MCP 和 GUI Automation 的第三条路径,值得独立开发者和 Agent 工具链玩家深入评估。 核心机制:7阶段自动化流水线 + HARNESS.md 方法论
CLI-Anything 的核心命题是:把任意软件代码库扔给它,输出一个完整的可 pip 安装的 CLI 包,让 Agent 通过结构化命令调用真实软件后端。整个流程被拆解为 7 个阶段——分析(扫描源码、映射 GUI 动作到 API)、设计(命令组架构、状态模型、输出格式)、实现(基于 Click 框架构建 REPL、JSON 输出、撤销重做)、测试规划、测试编写、文档生成、PyPI 发布。每个生成的 CLI 都遵循统一的 cli_anything.命名空间,附带 ReplSkin 统一交互层。
3月16日上线的 Phase 6.5 引入 SKILL.md 自动生成机制——每个 CLI 包内自带 Agent 可发现的 Skill 定义文件,REPL 启动横幅直接显示绝对路径,pip 安装即生效,与 Anthropic Skill 体系深度对齐。3月17日又发布 CLI-Hub 中心化注册中心,社区贡献者只需提交一个 registry.json PR,Hub 自动更新,相当于给 Agent 工具链做了一个 npm-like 的分发层。
Benchmark 逐项拆解:17 款软件覆盖度对比
测试数据分布很能说明问题。Blender 208 个测试(150 单元 + 58 E2E)覆盖 3D 渲染全链路;Inkscape 202 个测试聚焦 SVG/XML 直操;Audacity 161 个测试通过 Python wave + sox 处理音频;LibreOffice 158 个测试涉及 ODF 生成 + headless 渲染输出真实 PDF;OBS Studio 153 个测试覆盖 JSON 场景 + obs-websocket 推流。视频领域 Kdenlive 155 个、Shotcut 154 个测试均基于 MLT XML + melt 渲染器,需要处理 29.97fps 非整数帧率的累积舍入误差。Mermaid 仅 10 个测试、NotebookLM 21 个、Zoom 22 个属于实验性覆盖。
关键设计原则是"Zero Compromise Dependencies"——CLI 不做软件替代品,而是生成合法项目文件后委托真实软件渲染。LibreOffice 必须调用 headless 二进制输出真 PDF,Blender 必须调起 bpy 引擎做真实 Cycles 渲染,测试在后端缺失时会 Fail 而非 Skip。这个工程原则在测试链路上对应"Output Verification"——验证 PDF 魔法字节、ZIP/OOXML 结构、像素分析、音频 RMS 等级,而非简单看进程退出码为 0。
竞品对比:MCP、Anthropic Skill、GUI Agent 三路径之争
CLI-Anything 与三类主流 Agent-Software 桥接方案存在直接竞争关系。
对比 Anthropic MCP(Model Context Protocol):MCP 是协议层标准,要求软件方主动实现 MCP Server,工作量集中在供应商侧,目前 Asana、Notion、GitHub 等 SaaS 服务接入较多,但桌面软件如 GIMP、Blender 几乎无 MCP Server。CLI-Anything 反向操作——不等软件方接入,直接读源码生成桥接层,覆盖广度上有先发优势,但缺乏协议层标准化。
对比 Anthropic Agent Skills:Skill 是 Anthropic 力推的能力封装范式,重在文档化的 SKILL.md + 脚本组合,强调可读性和组合性。CLI-Anything 与 Skill 是互补关系,3月16日的 Phase 6.5 已经把 SKILL.md 作为输出物之一,可以理解为"Skill 生成器 + CLI 后端"组合套餐。
对比 GUI Agent(如 Claude Computer Use、Anthropic Operator、字节 UI-TARS):GUI Agent 走截图 + 点击路径,泛化能力强但脆弱,每次界面改版都可能失效。CLI-Anything 走代码生成 + 后端直调路径,可靠性远高于 GUI Automation,但前提是软件有可访问的源码或 SDK,闭源 SaaS 软件无法直接套用此方案。 优势:可靠性、覆盖广度、Agent 平台中立
CLI-Anything 最突出的优势是工程可靠性。1,839 个测试 100% 通过率、必须调用真实后端、强制 Output Verification 的硬约束,让生成的 CLI 具备生产级稳定性,这在 Agent 工具链领域并不常见。其次是 Agent 平台中立性——Claude Code、OpenCode、Codex、Qodercli、OpenClaw、Goose 全部支持,对独立开发者意味着不被单一 Agent 厂商锁定。再次是社区分发机制,CLI-Hub 让新软件的接入门槛降到一个 PR 的程度,配合 SKILL.md 自动生成,整条链路对 Agent 自进化体系有较好对齐。 对独立开发者而言,"喂源码即得 CLI"的范式也意味着可以把零散的 SaaS API 文档塞给 /cli-anything 命令,自动整合成统一 CLI,对 Token 消耗和工具调用复杂度都是一种优化。
局限:模型门槛、源码依赖、迭代需求
CLI-Anything 在 README 的 Limitations 章节直接列出了三条硬约束。一是依赖前沿模型——Claude Opus 4.6、Claude Sonnet 4.6、GPT-5.4 级别才能稳定生成,小模型产物需要大量人工修正,这意味着每跑一次 /cli-anything 的 API 成本不低。二是依赖可用源码——只提供编译二进制、需要反编译的软件,生成质量会显著下滑,对企业内部闭源软件、Adobe 全家桶等纯 GUI 商业软件几乎无解。三是单次运行难以覆盖全部能力,需要多次 /refine 迭代补齐,意味着从"喂源码"到"生产级 CLI"中间还有一段人工运营路径。
此外,CLI 路径本身有边界——交互密集的图形操作(如 Blender 雕刻、Photoshop 自由变换)很难完整 CLI 化,最终仍需要 GUI Agent 或专用 SDK 配合。框架本身用 Python + Click 实现,对非 Python 生态的 Agent 集成不够友好。OpenCode、Codex、Goose 三个平台仍标注为 Experimental,稳定性待长期验证。
选型建议
如果手头在做的是基于开源软件的 Agent 工作流(图像/3D/音视频/办公/网络管理),CLI-Anything 是当前可选项里覆盖最广、可靠性最高的方案,特别适合 Claude Code、OpenClaw 用户直接套用现成 harness。如果目标是接入闭源 SaaS 或商业 GUI 软件,需要先评估是否有开源替代品,或考虑 MCP 接入路径。如果只是做单一软件的轻量集成,自己写 CLI 可能比跑 7 阶段流水线更经济。HKUDS 在 Roadmap 中明确提到将支持 CAD、DAW、IDE、EDA 等更多品类,并研究闭源软件和 Web 服务的封装机制,后续值得持续跟踪。