CLI-Anything：把任何软件一键变成 AI 可调用接口

与其让 AI 智能体学着点鼠标，不如把软件直接改造成智能体天生就会用的样子——这是港大 HKUDS 实验室 CLI-Anything 的核心主张。这个仓库目前在 GitHub 上有 52.8k 星，一天还在涨近 600。它提供一条命令：/cli-anything ./gimp，智能体就自动读源码、设计命令体系、写出一个带 REPL 和 JSON 输出的完整命令行工具，连测试和文档一起生成。

七条流水线工序，一条命令跑完

生成过程被固化成 7 个阶段的 SOP：分析（扫描源码，把 GUI 操作映射到内部 API）→ 设计（规划命令组、状态模型、输出格式）→ 实现（构建基于 Click 的 CLI，带 REPL、JSON 输出、撤销重做）→ 测试规划 → 写测试 → 补文档 → 发布（生成 setup.py 装进 PATH）。每个改造完成的软件还附带一份专属架构文档和测试计划。README 里的数字是：18 款专业软件演示，2,280 个测试全部通过。

看仓库目录就知道野心多大：blender、gimp、inkscape、freecad、audacity、godot、comfyui、qgis、calibre、joplin、drawio、chromadb、iterm2……全是 GUI 重度软件。它们的共同点是：功能强大但没有智能体友好的操作面——Blender 有 Python API 但智能体不知道怎么用，GIMP 的 Script-Fu 文档劝退所有人。CLI-Anything 的方法论是在软件之上架一层”智能体原生”的命令行外壳，让模型用文本就能驱动像素级工具。

图 1

为什么是 CLI，而不是截图点鼠标

当前智能体操作电脑的主流路线是”计算机使用”（computer use）：截图、找坐标、模拟点击。这条路演示很惊艳，生产很脆弱——分辨率一变、按钮一挪，整个流程就崩。CLI-Anything 代表的另一条路线赌的是：文本接口才是智能体的母语。命令有明确的语义、结构化的 JSON 输出、可回滚的 undo/redo，出错还能读报错信息自我修正。arXiv 技术报告（2606.03854）的标题直接写明立场：”Towards Agent-Native Computer Use”（迈向智能体原生的电脑使用）。

这个思路并非凭空出现。HKUDS 团队的前作 LightRAG 在检索增强领域广为人知，他们一贯的方法论就是把复杂系统抽象成轻量可组合的接口。CLI-Anything 把同一刀法用在软件生态上：与其训练更会点鼠标的模型，不如把软件世界改造成模型本来就擅长的形状。配套还上线了 CLI-Hub（clianything.cc）作为成品 CLI 的分发中心，并支持以 Claude Code 插件、Cursor 插件、Pi 扩展多形态安装。

谁该认真看这个项目

对工具链作者，这份 SOP 的价值是把”给软件写个 CLI”从几周苦活压缩成一次生成加几轮 refine。对企业内部系统，README 明确把”社区为内部/定制软件贡献 CLI harness”列为方向——你的审批系统、CRM 私有部署，都可以按这套方法长出智能体接口。对普通用户，18 个现成 harness 意味着今天就能让智能体剪视频（audacity）、建 3D 模型（freecad）、跑生图工作流（comfyui）。

局限也要说清：生成的 CLI 覆盖度取决于源码质量和 GUI-API 映射的完整度，复杂交互（比如 Blender 的雕刻模式）未必能全部命令化；路线图上的”闭源软件 API 打包”才是硬骨头，因为大量商业软件根本不给你映射的机会。推测起来，这两条路线最终会合流：开放软件走向 agent-native CLI，封闭软件被倒逼开放 API——就像当年 Web 服务被移动时代倒逼出 REST 接口一样。软件界面为谁设计的问题，正在被重新回答。

核心观点：评估智能体落地能力时，别只看模型基准分——看看目标软件有没有 CLI 化的可能。如果你是软件作者，现在按这套 SOP 给自己的产品生成一个 agent 原生接口，就是下一个时代的 App Store 门票。