CLI-Anything：任意软件一键适配 Agent CLI-字节棱镜 (Byte Prism)

CLI-Anything 是香港大学数据科学实验室（HKUDS）黄超团队于 2026 年 3 月开源的项目，形态是 Claude Code 插件，承诺用一条命令把任意软件包装成 AI Agent 可调用的命令行接口。它在 GitHub 上线 3 周内就拿到 3.8 万以上 Star，是近期最受关注的 Agent 基础设施类项目之一 [1][3][4]。它目标覆盖 Claude Code、Cursor、OpenClaw、nanobot 等多套 Agent 框架 [2]，野心不只是”让 AI 能用某款软件”，而是把 CLI 这个老接口重新抬回 AI 时代的中心位置。

这个项目值得专门拆解，是因为它正面回应了 Agent 落地最棘手的那块短板——「推理」和「干活」之间那道沟。当下大模型能写代码、能查文档、能规划任务，但只要遇到 GIMP 图层、Blender 节点、Premiere 时间线这类 GUI 重型专业软件，Agent 几乎只能围观。CLI-Anything 想做的就是补齐这一块：它既不靠给软件补写 API 适配器，也不靠教 Agent 截图点击，而是让 Agent 通过命令行直接调度真实的软件后端 [2]。换句话说，它把”软件能不能被 Agent 用”这件事，从 GUI 层面搬回了 CLI 层面。

AI Agent 卡在「会用」这一步：推理 ≠ 干活

过去两年 Agent 的能力边界不断外推，从自动写脚本到自动修 bug、再到自动跑测试，看起来已经”无所不能”。但只要把任务落到某款专业软件内部的具体操作——给 GIMP 调图层混合模式、给 Blender 串节点、给 Premiere 剪时间线——Agent 就基本失灵。原因是这类软件的交互方式天然以 GUI 为中心：状态藏在面板里、操作依赖鼠标拖拽、反馈依赖视觉界面，文本接口（如果有的话）也只是 GUI 的极简残影，远不足以支撑 Agent 完成任务。

这件事之所以重要，是因为 Agent 想从”对话玩具”走向”生产力工具”，必须跨过这道坎。一个只能在浏览器里点点网页、能在 IDE 里改改文件的 Agent，能覆盖的实际工作流其实非常有限；而设计、剪辑、建模、办公这些真正占用人时间的工作，几乎都落在 GUI 重型软件里 [2]。如果 Agent 始终只能在外围打转，它的”通用助手”叙事就始终缺一角。CLI-Anything 的判断是：这道沟不需要造新桥，把 CLI 这条老路重新铺平就够了。

API 包装和截图点击都走不通，CLI-Anything 选了第三条路

要让 Agent 用上 GUI 重型软件，市面上能想到的方案大致两条：写 API 包装器，或者做 UI 自动化（截图+点击）。前者的问题在于覆盖面——Photoshop、Blender 这类软件根本没打算为外部程序提供完整 API，即使有官方接口，覆盖的操作也是残缺不全；一旦软件升级，包装器就可能整体失效，维护成本极高。后者更脆弱：分辨率一换、主题一改、窗口位置一动，截图脚本就崩，几乎不可能在生产环境稳定运行 [2]。

CLI-Anything 的第三条路，是直接生成 CLI。它的论据有四条：CLI 命令是文本，天然适合 LLM 解析和组合；CLI 启动开销极低、不依赖额外运行时；CLI 自带 --help 自描述，等于把文档内嵌进接口本身；现实里 Claude Code 每天已经通过 CLI 跑着数千个真实工作流 [2]。换句话说，CLI 不是 CLI-Anything 的发明，它是 Agent 时代被低估的”老朋友”——只是之前没人系统性地用它把 GUI 软件桥接过来。当模型越来越擅长理解文本和工具调用时，一条结构化、低开销、可描述的命令行接口，恰好踩中了 LLM 最舒服的输入形态。

一条 `/cli-anything ./gimp` 背后：Claude Code 读完源码后做的 7 件事

CLI-Anything 最有意思的设计，是把”为某款软件生成 CLI”这件事拆成了 7 个阶段，让 Claude Code 自动走完全流程 [2]。一条命令 /cli-anything ./gimp 触发后，模型会依次完成：①分析——扫描软件源码，把 GUI 操作映射到底层 API；②设计——规划命令结构、状态模型、输出格式；③实现——基于 Click 框架生成 CLI 代码，支持 REPL 交互、JSON 输出、undo/redo；④规划测试——产出 TEST.md 测试计划；⑤编写测试——单元测试加端到端测试；⑥文档——更新测试结果与说明；⑦发布——生成 setup.py，安装到系统 PATH。

这个流程的关键不在”自动化”三个字，而在它最终交付的是一个完整的 CLI 工程：可安装、可执行、可测试、有文档。这不是简单的命令转换，而是模型对软件架构的完整重写——它必须先理解这个软件有哪些核心概念、有哪些状态、操作之间有什么依赖，才能设计出合理的命令结构。所以它的天花板取决于 Claude Code 本身对源码的阅读能力，而不是某种固定规则。换个角度说，CLI-Anything 把”如何为一个 GUI 软件设计 CLI”这件事，外包给了一个会读代码的 Agent。

关键保证：CLI 调的是原生后端，不是替身

CLI-Anything 在介绍里特别强调一句”CLI 调用的是真正的软件后端，不是替代品”[2]。这一条不是技术细节，而是整个项目立得住的根基。两个最有说服力的例子：LibreOffice CLI 实际通过 libreoffice-headless 生成 PDF，Blender CLI 实际通过 blender --background 调用渲染管线。换句话说，Agent 调用 blender-cli render scene.blend，输出的就是 Blender 自己在 GUI 里点出来的那张图；不是某个 Python 库模仿出来的形状相似但内核不同的替代品。

有了这条保证，LLM 就能放心把复杂任务交给 Agent。Agent 调度 Blender 渲染，渲染出的资产能直接进下游流程；Agent 调度 LibreOffice 转 PDF，PDF 能直接发出去。如果只是表面上的”能跑通”但内核是替代品，在生产环境根本用不了——任何一个细微的格式差异都可能让后续环节炸掉。”调真后端”这件事，是 CLI-Anything 和那些”AI 帮你点软件”类产品最本质的区别：前者把软件原有的能力完整暴露给 Agent，后者只是用一层 UI 模仿包了层壳。

现在能用什么 + 三分钟跑通一个 demo

截至项目发布时，已经预置覆盖的开源软件包括 GIMP、Blender、LibreOffice 等常用 GUI 程序 [2][4]，Photoshop、Premiere Pro 等闭源商业软件除外（下一节专门讨论边界）。仓库地址是 github.com/HKUDS/CLI-Anything，配套还有一个 CLI-Hub 入口（clianything.cc），用于浏览和管理已生成的 CLI 工具。

最小上手路径并不复杂：先把 CLI-Anything 当作 Claude Code 插件装好，然后在 Claude Code 里执行一条 /cli-anything ./目标软件目录，等待 7 个阶段跑完，再把生成的 CLI 安装到 PATH。整个流程对小型工具基本是分钟级，对 GIMP、Blender 这种规模的项目则会更久——耗时由 Claude Code 阅读代码的速度决定。上线 3 周内冲上 3.8 万以上 Star [1][3][4]，部分原因也在于它的上手足够轻：开发者很容易在自己常用的工具上跑一遍 demo，亲眼看到 Claude Code 把一款 GUI 软件”读”成 CLI。

它解决不了什么：闭源商业软件的边界

但 CLI-Anything 不是银弹，它有一条清晰的边界：当前全流程依赖源码扫描，意味着 Photoshop、Premiere Pro、3ds Max 这类不开源的商业 GUI 软件，不能直接走自动生成流程 [2]。这不是 bug，是方法的局限——模型读不到源码，就没法自动映射”图层→命令”的对应关系，自然也就没法凭空设计出可靠的 CLI。

项目自己的定位是”方法论+工具链”，而不是万能钥匙 [2]。对于闭源软件，社区可能的延伸方向有几个：手动维护一份 API 映射表（指定某个 GUI 操作对应哪个底层调用）、对二进制协议做反编译辅助来推断接口、或者干脆让用户先用 GUI 操作一遍录下调用轨迹再生成 CLI。但这些都还不是项目当前主线的能力，对闭源软件保持耐心比较合理——它的核心战场是开源 GUI 工具这片长尾，这块已经被它打穿了。把这条边界讲清楚，比假装能覆盖一切更可信。

FAQ

不开源源码的商业软件（Photoshop、Premiere Pro）能用 CLI-Anything 接入吗？
目前不能直接走自动生成流程。CLI-Anything 的 7 阶段流水线依赖源码扫描来映射 GUI 操作到底层接口 [2]，Photoshop 等闭源软件拿不到源码，自动映射无法运行。可行的思路是先手工维护一份 API 映射表，再借助项目的方法论生成 CLI 骨架——但这已经不是它的开箱即用范围。

自动生成的 CLI 在 Claude Code、Cursor、OpenClaw、nanobot 这些 Agent 框架之间是同一套调用方式吗？
是。CLI-Anything 生成的 CLI 是标准的命令行工具，基于 Click 框架，支持 --help、JSON 输出、REPL、undo/redo 等 [2]，任何能调命令行的 Agent 框架都能直接调用。框架之间不需要适配差异，因为 CLI 本身就是 Agent 时代最通用的契约——这也是为什么项目一次生成、多框架受益。

跟手动敲命令行 / 写 Python 脚本相比，CLI-Anything 多出来的主要开销在哪一层？
主要开销在”生成”这一步，而不是”运行”。运行一个生成好的 CLI 和手动敲命令几乎没有差别——它本质就是个 Click 程序。真正的成本是首次生成时让 Claude Code 读完源码、跑完 7 个阶段——这一步对 GIMP、Blender 这种大型项目按小时计算，远比手动写一个 demo CLI 慢。但生成一次之后，CLI 可以无限复用，并且天然具备自描述、可组合、可测试的优势，长期收益远大于一次性生成成本。