1. 一句话定位
CLI-Anything 是一个把现有软件转换成 Agent-native CLI 的开源项目。
它不是普通的命令行工具，也不是某一个 GUI 自动化框架，而是一套“让任意有代码库的软件变成 AI Agent 可操作工具”的方法论、插件、示例 harness 和 CLI 生态。
可以这样向客户解释：
过去我们让 AI Agent 像人一样看屏幕、找按钮、点击坐标，这种方式很容易受界面变化、窗口大小、加载延迟影响。CLI-Anything 的思路是反过来：为软件补一层结构化命令行接口，让 Agent 直接用命令、状态和 JSON 结果操作真实软件。
2. 它主要解决什么问题
2.1 GUI Agent 的天然脆弱性
arXiv 技术报告的摘要把问题讲得很清楚：当前主流 computer use 方案往往让 Agent 通过截图、视觉识别、坐标点击来操作应用。这会带来几个问题：
| 问题 | 具体表现 | 对客户的影响 |
|---|---|---|
| 像素级交互脆弱 | UI 换皮、按钮移动、弹窗变化就失败 | 自动化稳定性差，维护成本高 |
| 时间依赖强 | 页面加载慢、动画延迟、网络波动都会影响点击 | 任务成功率不可控 |
| 状态不可显式读取 | Agent 只能“看见”界面，难以获得完整结构化状态 | 难以做可靠判断和回滚 |
| 输出难验证 | GUI 操作完成不代表文件/结果真实正确 | 生产环境风险高 |
| 难规模化 | 每个软件、每个版本都要重新适配视觉路径 | 企业落地成本高 |
CLI-Anything 的方案是：不要让 Agent 模拟人的视觉限制，而是让软件暴露更适合 Agent 的接口。
2.2 Agent 缺少真实专业软件能力
很多企业想让 Agent 使用专业软件，但会遇到两类极端：
- 直接 GUI 自动化：能用现有软件，但不稳定。
- 重新写一个轻量替代品：稳定一些，但功能远远不如真实软件。
CLI-Anything 强调“真实软件集成”：CLI 生成合法的项目文件或脚本，然后调用真实后端渲染/导出。例如：
- LibreOffice：生成 ODF，再用
libreoffice --headless导出 PDF/DOCX/XLSX/PPTX。 - Blender：生成 bpy 脚本，再用
blender --background --python渲染。 - Inkscape：操作 SVG，再用 Inkscape 导出。
- Shotcut/Kdenlive：生成 MLT XML，再用
melt或ffmpeg渲染。 - OBS：通过 obs-websocket 控制真实 OBS。
这个原则很关键：它做的是“真实软件的结构化接口”，不是玩具级重写。
3. 它主要能做什么
3.1 使用 CLI-Hub 安装已有 CLI
CLI-Hub 是 CLI-Anything 的生态入口，用于浏览、搜索、安装、更新、卸载和启动社区已有 CLI。
pip install cli-anything-hub
cli-hub list
cli-hub search image
cli-hub info gimp
cli-hub install gimp
cli-hub launch gimp售前解读：
- 如果客户要验证“Agent 能不能使用专业软件”，可以先找 CLI-Hub 是否已有对应工具。
- 这比从零构建 harness 更快，适合 demo 和 PoC 初期。
- 需要注意：有些 CLI 仍依赖真实上游软件，比如 GIMP、Blender、LibreOffice，本机或服务器仍要安装这些软件。
3.2 为新软件生成 Agent 可用 CLI
如果 CLI-Hub 没有目标软件，可以使用 CLI-Anything 的 7 阶段生成流程：
| 阶段 | 官方流程 | 售前理解 |
|---|---|---|
| 1. Analyze | 扫描源码，找到 GUI 动作、数据模型、后端接口 | 搞清楚这个软件真正的能力在哪里 |
| 2. Design | 设计命令组、状态模型、输出格式 | 把软件能力整理成 Agent 能理解的操作面 |
| 3. Implement | 用 Click 实现 CLI、REPL、JSON 输出、undo/redo | 生成可交互、可脚本化的命令工具 |
| 4. Plan Tests | 先写 TEST.md 测试计划 | 避免只做 demo，不做验证 |
| 5. Write Tests | 写单测、端到端测试、真实后端测试 | 验证真实工作流 |
| 6. Document | 更新测试结果和文档 | 让工具可交接、可维护 |
| 6.5 Skill | 生成 SKILL.md | 让 Agent 后续能自动发现和使用 |
| 7. Publish | 生成 setup.py，安装到 PATH | 进入团队可复用状态 |
典型命令：
/cli-anything ./gimp
/cli-anything https://github.com/blender/blender
/cli-anything:refine ./gimp "batch processing and filters"
/cli-anything:test ./inkscape
/cli-anything:validate ./audacity3.3 已验证的 harness 示例
README 显示项目已经覆盖多类软件，包括：
| 类别 | 示例 | 客户价值 |
|---|---|---|
| 创意与媒体 | GIMP、Blender、Inkscape、Audacity、Kdenlive、Shotcut、OBS | 让 Agent 自动生成图片、视频、直播场景、音频处理 |
| 办公与知识管理 | LibreOffice、Zotero、Joplin、Calibre | 自动生成报告、处理文档、管理资料库 |
| 图表与可视化 | Draw.io、Mermaid | 自动生成架构图、流程图、说明材料 |
| AI/ML 平台 | ComfyUI、Ollama 等 | 用命令驱动模型推理和工作流 |
| 开发与调试 | LLDB、RenderDoc、Nsight Graphics、Unreal Insights | 让 Agent 参与调试、性能分析、图形分析 |
| 企业工具 | Zoom、CloudAnalyzer、AdGuard Home 等 | 会议、云成本、安全/网络工具自动化 |
README 的最新英文页面展示了 2,461 项测试 100% 通过，其中包括单元测试、端到端测试、Node.js 测试等。中文 README 中的数字略低，说明中文文档可能滞后；售前引用时应以英文 README 的最新状态为准，并注明核查日期。
4. 适用场景
4.1 企业内部软件 Agent 化
适合客户：
- 有大量内部工具、后台系统、桌面软件或开源定制系统。
- 想让 AI Agent 直接执行业务任务，而不是只回答问题。
- 现有系统没有完善 API，或者 API 粒度过低、文档复杂。
典型价值：
- 把分散的功能整理成统一 CLI。
- 让 Agent 用
--help和--json自发现能力。 - 用测试保证命令结果可靠。
示例：
某企业有内部报表工具、数据清洗工具、文档生成工具。通过 CLI-Anything，可以把这些工具包装成统一 CLI，让 Agent 自动生成报表、导出文件、检查结果，而不是每次依赖人点击页面。
4.2 替代脆弱 RPA / GUI 自动化
适合客户：
- 当前使用 RPA、录屏点击、浏览器自动化脚本。
- 自动化经常因为界面变化失败。
- 希望降低维护成本和提升任务成功率。
售前话术：
RPA 的问题不是不能做，而是长期维护成本高。CLI-Anything 的思路是把“点哪里”变成“调用什么命令”，把 UI 结果变成 JSON 和文件验证，这更适合 Agent，也更适合生产环境。
4.3 AI Agent 工具生态建设
适合客户：
- 正在建设企业内部 Agent 平台。
- 需要为 Agent 提供稳定工具集。
- 想把多个业务系统、开源工具和桌面软件变成可调用工具。
CLI-Anything 的价值在于：它不是只给一个 Agent 用，而是让工具本身变得 Agent-native。只要 CLI 和 SKILL.md 产出稳定，Claude Code、Codex、OpenClaw、OpenCode、Hermes、Reasonix 等兼容环境都可以复用类似能力。
4.4 内容生产自动化
适合场景：
- 自动生成 PPT/文档/PDF。
- 自动制作视频剪辑、字幕、封面。
- 自动渲染 3D 产品图。
- 自动生成流程图、架构图、培训材料。
CLI-Anything 在这类场景有优势，因为它倾向于调用真实软件导出真实成果，而不是只生成一个看起来像的中间文件。
4.5 软件厂商做 Agent-ready 改造
对软件厂商来说，CLI-Anything 可以作为一个产品化启发：
- 为自己的软件补 CLI 层。
- 提供 JSON 输出和可验证状态。
- 提供 SKILL.md 或 Agent 使用说明。
- 提供端到端任务样例和测试套件。
这类能力未来可能成为“软件是否适合 Agent 使用”的重要指标。
5. 不太适合的场景
| 不适合场景 | 原因 | 建议 |
|---|---|---|
| 目标软件完全闭源且无脚本/API/文件格式入口 | CLI-Anything 主要依赖源码、真实后端、项目文件或已有 CLI | 先评估是否有官方 API、SDK、MCP 或自动化接口 |
| 只想做一次性简单网页点击 | 用 Playwright/RPA 可能更快 | 不必为一次性任务生成完整 harness |
| 客户缺少强模型和工程团队 | README 明确提到需要强基础模型，弱模型可能生成不完整 CLI | 由实施团队先代建，再交付维护规范 |
| 目标软件依赖复杂 GUI 状态且无稳定后端 | 很难保证真实输出和测试稳定性 | 先做技术可行性评估 |
| 对合规和安全要求极高但缺少审查流程 | 自动生成 CLI 可能触及文件写入、系统调用、真实软件执行 | 纳入代码审查、权限控制、沙箱和审计 |
6. 架构与关键设计
6.1 推荐售前理解架构
能力发现"] Agent --> CLI["cli-anything-
JSON + Human 输出"] CLI --> State["Session / Project State
undo / redo / history"] CLI --> Native["原生项目文件
ODF / SVG / MLT / bpy / JSON"] Native --> Backend["真实软件后端
LibreOffice / Blender / GIMP / ffmpeg"] Backend --> Artifact["真实产物
PDF / 图片 / 视频 / 音频 / 报告"] CLI --> Tests["Unit + E2E + Subprocess Tests"]
6.2 核心原则
| 原则 | 含义 | 为什么重要 |
|---|---|---|
| 真实软件是硬依赖 | 不用玩具替代真实软件 | 保证产物和客户真实工作流一致 |
| 双交互模式 | REPL + 子命令 | 兼顾 Agent 长会话和脚本自动化 |
| JSON 输出 | 每个命令支持 --json | Agent 可稳定解析 |
| 自描述接口 | --help、which、SKILL.md | Agent 可以发现和学习工具 |
| 强测试 | 单测 + 真实后端 E2E + CLI 子进程测试 | 避免“看起来能跑”的假自动化 |
| 输出验证 | 检查 magic bytes、ZIP/OOXML、像素、音频、时长 | 证明产物是真的正确 |
| 无优雅降级 | 后端缺失就失败并给出安装说明 | 防止生产环境偷偷生成错误结果 |
7. 怎么用
7.1 作为 CLI-Hub 用户
pip install cli-anything-hub
cli-hub list
cli-hub search diagram
cli-hub info drawio
cli-hub install drawio
cli-hub launch drawio适合做演示和快速验证。
7.2 作为 Claude Code 插件用户
/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything ./gimp
/cli-anything:refine ./gimp "batch processing and filters"7.3 作为 Codex Skill 用户
git clone https://github.com/HKUDS/CLI-Anything.git
bash CLI-Anything/codex-skill/scripts/install.sh然后在 Codex 中自然语言触发：
Use CLI-Anything to build a harness for ./gimp
Use CLI-Anything to refine ./shotcut for picture-in-picture workflows
Use CLI-Anything to validate ./libreoffice7.4 使用生成后的 CLI
cd /agent-harness
pip install -e .
which cli-anything-
cli-anything- --help
cli-anything-
cli-anything- --json 示例：LibreOffice CLI 生成 PDF。
cli-anything-libreoffice document new -o report.json --type writer
cli-anything-libreoffice --project report.json writer add-heading -t "Q1 Report" --level 1
cli-anything-libreoffice --project report.json writer add-table --rows 4 --cols 3
cli-anything-libreoffice --project report.json export render output.pdf -p pdf --overwrite
cli-anything-libreoffice --json document info --project report.json8. 售前可以怎么讲
8.1 面向业务方
CLI-Anything 的价值是让 AI 真正使用企业已有工具，而不是只在聊天窗口里给建议。它可以把文档、设计、视频、图表、开发工具等软件转成 Agent 可调用的命令，从而把“AI 会说”推进到“AI 会做”。
8.2 面向技术负责人
它不是传统 RPA，也不是屏幕点击脚本。它强调结构化命令、显式状态、JSON 输出、真实后端执行和端到端验证。对企业 Agent 平台来说，这类工具接口比 GUI 点击更容易维护、监控和复用。
8.3 面向 CIO / 管理层
企业已经有大量软件资产。CLI-Anything 提供了一种低侵入的 Agent 化路径：先从开源或内部工具开始，把高频流程封装成可测试 CLI，再逐步纳入企业 Agent 平台。这样可以减少重复人工操作，也避免一开始就重构所有系统。
9. 常见客户问题
| 客户问题 | 回答建议 |
|---|---|
| 它是不是 RPA？ | 不是传统 RPA。RPA 通常模拟人点击 GUI；CLI-Anything 更强调为软件生成结构化命令接口，调用真实后端并验证输出。 |
| 它能处理闭源商业软件吗？ | 如果商业软件有 API、脚本接口、CLI、可编辑项目文件或 MCP 服务，就有机会；如果只有黑盒 GUI，难度会明显上升。 |
| 生成的 CLI 是否可靠？ | 取决于目标软件复杂度、基础模型能力和测试质量。项目方法论要求真实后端 E2E 测试和输出验证，但生产前仍需人工审查。 |
| 它会替代软件官方 API 吗？ | 不一定。官方 API 质量高时应优先使用；CLI-Anything 更适合把 API、项目文件和真实软件后端组合成 Agent 友好的工作流。 |
| 它适合企业内部工具吗？ | 适合，尤其是有源码或稳定脚本接口的内部工具。可以把内部工具包装成统一 CLI，再供 Agent 调用。 |
| 安全风险是什么？ | CLI 可以读写文件、调用真实软件和执行外部命令，所以必须有权限边界、审计日志、沙箱和代码审查。 |
| 为什么不直接用 GUI Agent？ | GUI Agent 适合临时操作和无接口系统，但在长期生产任务上，结构化 CLI 更稳定、可测试、可回放。 |
10. PoC 建议
10.1 PoC 选题
建议选一个“真实、有价值、但边界清晰”的任务：
- 自动生成一份客户周报 PDF。
- 自动从素材生成一段短视频。
- 自动生成一张系统架构图。
- 自动把会议录制下载、转写、归档。
- 自动驱动内部报表工具导出数据。
不建议一开始选整个 ERP、整个 CAD 或全部办公流程。
10.2 PoC 阶段
| 阶段 | 工作 | 验收 |
|---|---|---|
| 第 1 阶段：可行性评估 | 看目标软件是否有源码、CLI、API、项目文件或脚本接口 | ���否找到真实后端入口 |
| 第 2 阶段：最小 harness | 生成 3-5 个核心命令 | Agent 能完成一个闭环任务 |
| 第 3 阶段：真实输出 | 调用真实软件生成 PDF/图片/视频/报告 | 产物可打开、可检查、格式正确 |
| 第 4 阶段：测试补齐 | 单测、E2E、CLI subprocess 测试 | 自动化测试通过 |
| 第 5 阶段：Agent 集成 | 生成 SKILL.md，接入企业 Agent 平台 | Agent 能自发现和调用 |
| 第 6 阶段：安全加固 | 权限、审计、沙箱、错误处理 | 满足企业上线要求 |
10.3 建议指标
| 指标 | 含义 |
|---|---|
| 任务成功率 | 同一个任务重复执行是否稳定 |
| 端到端耗时 | 比人工/RPA 快多少 |
| 失败可诊断性 | 失败时是否有明确错误和日志 |
| 输出正确率 | 文件格式、内容、像素/音频/时长等是否达标 |
| 覆盖命令数 | 对目标业务流程覆盖程度 |
| 维护成本 | 软件升级后需要改多少命令/测试 |
| Agent token 消耗 | JSON/CLI 是否比裸 API 或 GUI 观测更省 |
11. 风险和注意事项
11.1 对模型能力有要求
README 的限制部分明确提到，它依赖强基础模型来可靠生成 harness；较弱模型可能生成不完整或错误的 CLI，需要大量人工修正。
售前不要承诺“一键生成所有软件 CLI 且无需人工”。更稳妥的说法是：
CLI-Anything 提供自动化生成和方法论，但生产质量仍需要代码审查、测试补齐和迭代 refine。
11.2 源码和后端入口决定上限
目标软件如果有清晰源码、项目文件格式、官方 CLI、脚本接口，成功率会高很多。反之，如果只有闭源 GUI，且没有 API/SDK/文件格式文档，CLI-Anything 的发挥空间会受限。
11.3 自动生成代码需要安全审查
企业场景必须考虑：
- 是否会访问敏感文件。
- 是否会执行外部命令。
- 是否会写入生产数据。
- 是否需要权限隔离。
- 是否有审计日志。
- 是否能回滚和重放。
11.4 测试是成败关键
CLI-Anything 很强调测试，这一点要在售前中讲透。没有真实后端 E2E 和输出验证，生成 CLI 很容易变成“看起来能跑”的 demo。
12. 我的售前判断
CLI-Anything 的战略意义大于单个工具本身。
它抓住了 Agent 落地中的一个关键问题：大模型已经能推理和规划，但企业真实工作都沉淀在现有软件里。如果 Agent 只能看屏幕点击，可靠性很难进入生产；如果每个系统都单独开发 API，又成本太高。CLI-Anything 提供了第三条路：把软件能力包装成 Agent-native CLI。
适合重点关注的客户类型：
- 正在建设企业 Agent 平台的客户。
- 有大量内部工具、脚本和桌面软件的技术型客户。
- RPA 维护成本高、想升级到 Agent 自动化的客户。
- 内容生产、文档生成、设计/视频/图表自动化需求强的客户。
- 软件厂商，希望自己的产品更容易被 AI Agent 使用。
售前定位建议：
不要把 CLI-Anything 讲成“万能一键自动化神器”，而要讲成“Agent 工具化和软件 Agent-native 改造的方法论与工程框架”。它的价值在于结构化、可测试、可复用、可接入 Agent 平台。
13. 参考资料
- GitHub 仓库：HKUDS/CLI-Anything
- 英文 README：README.md
- 中文 README：README_CN.md
- 方法论手册：HARNESS.md
- 技术报告：CLI-Anything: Towards Agent-Native Computer Use
- CLI-Hub：https://hkuds.github.io/CLI-Anything/
- Teaser 图：teaser.png
- Architecture 图：architecture.png
信息核查日期：2026-06-30。GitHub API 匿名访问触发限流，因此本笔记未写入实时 stars/forks；项目状态、安装方式、测试数量和限制说明主要基于官方 README、中文 README、HARNESS.md 与 arXiv 摘要整理。