面向对象：产品、研发、平台、解决方案团队 资料来源：HKUDS/CLI-Anything 仓库，核对时间：2026-05-28 仓库地址：https://github.com/HKUDS/CLI-Anything

一句话说明

CLI-Anything 的核心想法很直接：把原本主要给人点按钮、拖拽、看界面的软件，包装成 AI Agent 可以稳定调用的命令行工具。这样 Agent 不需要“看懂界面”，而是通过明确的命令、参数和 JSON 输出去完成任务。

可以把它理解成“给软件加一层 Agent 可用的遥控器”。

它解决的是什么问题

今天很多软件天然是给人使用的：用户打开界面、点击菜单、修改配置、导入导出文件。AI Agent 要操作这类软件时，通常有三种困难：

1. 图形界面对 Agent 不稳定：按钮位置、弹窗、主题、分辨率变化都会影响操作。

2. 软件能力不容易被发现：Agent 很难知道某个软件到底支持哪些功能、每个功能怎么调用。

3. 输出不利于自动判断：界面上的结果适合人看，但不适合程序自动校验是否成功。

CLI-Anything 的思路是把这些能力整理成命令行：

• 用 --help 让 Agent 自动发现能力。

• 用结构化参数表达操作意图。

• 用 JSON 输出表达执行结果。

• 用测试和真实后端验证，保证生成结果不是“看起来成功”，而是真的可用。

仓库主要包含什么

1. CLI-Hub：CLI 的安装和发现入口

CLI-Hub 是一个类似“CLI 应用商店”的入口。用户或 Agent 可以通过命令浏览、搜索、安装、更新、卸载 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

仓库当前登记了两类 CLI：

类型	数量	说明
CLI-Anything 自建/社区 harness	64	针对具体软件封装的 Agent 可调用 CLI
公共 CLI	16	第三方或官方 CLI，由 CLI-Hub 统一管理

2. Agent Harness：把软件变成 CLI 的方法论

仓库提供了一套标准流程，用来把一个现有软件封装成 Agent 可操作的 CLI。它不是简单写几个脚本，而是强调“真实软件集成 + 可测试 + 可发布”。

核心流程可以概括为 7 个阶段：

1. 分析代码库：找到核心逻辑、数据模型、文件格式和已有后端工具。

2. 设计 CLI 架构：规划命令分组、状态管理、JSON 输出和交互模式。

3. 实现 CLI：基于 Python Click 构建命令、REPL、会话、撤销/重做等能力。

4. 规划测试：先写 TEST.md，明确单元测试和端到端测试范围。

5. 编写测试：覆盖核心逻辑、命令调用、真实文件生成和真实软件后端。

6. 写入测试结果和文档：记录执行结果、覆盖范围和限制。

7. 打包发布：生成可安装包，并让命令进入 PATH。

仓库还包含一个 Phase 6.5：自动生成 SKILL.md。它的作用是让 Agent 知道这个 CLI 什么时候该用、怎么安装、有哪些命令、如何处理输出和错误。

3. 已支持的软件类型很广

CLI-Anything 已经覆盖了很多类型的软件和系统，包括：

方向	示例
图像与设计	GIMP、Krita、Inkscape、Blender、FreeCAD
文档与办公	LibreOffice、Calibre、Zotero
视频与音频	Kdenlive、Shotcut、OpenScreen、Audacity
自动化与开发	n8n、PM2、WireMock、LLDB
AI 与知识工具	Ollama、ComfyUI、NotebookLM、Novita
通讯与平台	Zoom、Feishu/Lark CLI 等

这些例子说明它不只适合“开发者工具”，也适合多媒体、办公、创作、数据处理、自动化平台等复杂软件。

它的关键设计思想

CLI 是人和 Agent 都能理解的接口

相比图形界面，CLI 有几个天然优势：

• 命令文本适合大模型生成。

• 参数结构清晰，便于组合成工作流。

• --help 可以自描述，Agent 能主动学习。

• JSON 输出方便程序判断成功、失败和后续动作。

• 命令可以被测试、记录、复现和审计。

不是“绕过软件”，而是调用真实软件

CLI-Anything 强调真实后端集成。例如封装 LibreOffice 时，不只是生成一个中间文件，而是要调用真实 LibreOffice headless 导出，并校验 PDF、DOCX、XLSX 等结果是否真的有效。

这点对我们很重要：如果未来用于自己的软件，不能只做一个演示型 wrapper，而要接到真实业务能力、真实数据模型和真实权限体系上。

Agent 需要的不只是命令，还需要“说明书”

SKILL.md 是给 Agent 看的使用说明。它通常包含：

• 什么时候应该使用这个 CLI。

• 安装前提和环境要求。

• 命令分组和示例。

• 推荐使用 JSON 输出。

• 常见错误和处理方式。

• 哪些操作危险、需要确认。

这相当于给我们的软件补一份“Agent 使用手册”。

可以怎么用于我们自己的软件

适合优先接入的场景

如果我们的软件里有以下能力，就很适合参考 CLI-Anything 的方式封装：

场景	适合原因
批量处理	Agent 可以自动跑大量重复任务，例如批量导入、导出、转换、审核
后台配置	比 GUI 更适合用命令表达，例如创建项目、修改规则、启停任务
内容生成	Agent 可以调用软件生成文档、图表、素材、报告、配置文件
数据查询与分析	JSON 输出可直接进入下一步推理或报表生成
运维和排障	命令可记录、可复现、可审计，适合排查问题
工作流自动化	多个命令可以串联成完整业务流程

我们可以做的第一版目标

建议不要一开始就追求“把整个软件都变成 CLI”。更现实的做法是选 3 到 5 个高价值工作流做 MVP。

一个合适的第一版 CLI 可以包含：

1. status：查看当前服务、配置、登录态或项目状态。

2. list/search/get：让 Agent 能查询对象。

3. create/update/delete：让 Agent 能修改对象，但高风险操作要确认。

4. export/import：让 Agent 能把结果带到其他系统。

5. run/execute：触发一个真实业务流程。

6. --json：所有命令支持机器可读输出。

7. --dry-run：危险写操作先预览，不直接执行。

推荐的技术落地结构

可以参考 CLI-Anything 的结构，为我们的软件建立一个独立的 Agent CLI 包：

our-software-cli/ setup.py 或 pyproject.toml our_software_cli/ __main__.py cli.py client.py session.py commands/ project.py user.py workflow.py export.py skills/ SKILL.md tests/ TEST.md test_core.py test_full_e2e.py

如果我们的软件已有 HTTP API，CLI 可以优先封装 API；如果核心能力在本地 SDK、脚本或服务里，就封装本地调用；如果有桌面端但没有 API，则需要先梳理底层数据模型和可调用后端。

推荐的命令设计原则

原则	说明
先读后写	Agent 修改前应能查询当前状态
默认安全	删除、覆盖、发布等操作必须支持确认或 dry-run
JSON 优先	所有核心命令都应支持 --json
错误可恢复	错误信息要告诉 Agent 下一步怎么修
状态可追踪	会话、任务、导出文件路径都要清晰返回
可测试	每个命令都要能被自动化测试验证

对我们产品的潜在价值

1. 让软件进入 Agent 工作流

用户未来可能不是自己点完所有流程，而是对 Agent 说：“帮我把上周数据生成报告，并发给团队。”如果我们的软件有 CLI 和 Agent 说明书，就更容易被这类工作流调用。

2. 降低集成成本

相比为每个平台单独做插件，CLI 是更通用的中间层。Claude Code、Codex、OpenClaw、Cursor、脚本系统、CI/CD 都可以调用命令行。

3. 提升内部自动化效率

内部研发、测试、运营、交付都可以用同一套 CLI 做自动化。例如自动创建测试项目、批量生成演示数据、导出客户报告、巡检配置问题。

4. 形成更清晰的产品能力边界

为了设计 CLI，我们必须把软件能力拆成清晰的命令、参数、状态和结果。这会反过来帮助产品梳理 API、权限、错误码和业务对象。

落地建议

第一阶段：选一个高频工作流试点

选择一个对内部或客户都有价值、但范围可控的工作流，例如：

• 自动创建一个项目并完成基础配置。

• 批量导入数据并输出校验报告。

• 根据模板生成一份业务报告。

• 查询运行状态并给出问题诊断。

目标是做出一个能被 Agent 真正调用的 CLI，而不是只做 demo。

第二阶段：补齐安全和测试

重点补齐：

• 认证和权限。

• --json 输出规范。

• --dry-run 和危险操作确认。

• 单元测试。

• 端到端测试。

• 真实环境下的输出校验。

第三阶段：生成 Agent 使用说明

为 CLI 写 SKILL.md 或类似说明，告诉 Agent：

• 什么场景应该用它。

• 命令怎么调用。

• 输出字段代表什么。

• 常见错误怎么处理。

• 哪些操作需要用户确认。

第四阶段：接入内部 Agent 或工作流平台

把 CLI 放到内部 Agent、CI、运维脚本或交付工具里，让它承接真实任务。通过真实使用再反推命令设计和能力补齐。

风险和注意事项

风险	说明	建议
权限越界	Agent 自动执行写操作可能带来风险	引入最小权限、确认机制和审计日志
命令覆盖不完整	初版 CLI 可能只覆盖少数功能	从高价值工作流开始，逐步扩展
输出不稳定	文本输出变化会影响 Agent 判断	核心结果必须提供稳定 JSON schema
只做壳不接真实能力	demo 可跑，但业务不可用	必须调用真实 API、SDK 或后端
测试不足	Agent 会放大边界情况	引入端到端测试和真实输出校验

建议结论

CLI-Anything 对我们的启发不是“直接照搬一个工具”，而是提供了一套产品工程思路：为软件增加一层稳定、结构化、可测试、可被 Agent 理解的操作接口。

对我们自己的软件来说，最值得尝试的是：

1. 选一个高频业务工作流。

2. 封装成小而完整的 CLI。

3. 所有命令提供 JSON 输出和 dry-run。

4. 写 Agent 使用说明。

5. 用真实端到端测试证明它能完成任务。

这样做的价值在于：我们的软件不仅能被人使用，也能被 AI Agent 稳定、安全、可审计地使用。