CLI-Anything 全面入门：让 AI 操作软件的原理与实践

AI 已经能写代码、能对话，但让它真正操作专业软件——画流程图、建 3D 场景、处理工程文件——仍然是个难题。大多数软件只提供图形界面，Agent 无法像人一样点击按钮、拖拽图层。B 站 UP 主介绍的开源项目 CLI-Anything 试图解决这个问题：把软件操作封装成命令行工具，让 Agent 通过调用命令完成任务并检查结果。

功能定位：三层架构搭起桥梁

CLI-Anything 不是一个新训练的大模型，写代码和做决策的仍然是你选择的 Agent。它提供的是三层能力：

• 生成器：Agent 分析目标软件的可调用接口，自动编写适配该软件的命令行工具；
• 生成好的工具：负责实际执行任务，如创建画布、添加节点、连线、导出；
• CLI Hub：帮助用户发现、安装和管理现成工具。

仓库中已有面向 DrawIO、Blender、办公与媒体工具的适配。但 UP 主特别提醒：目录里有某个软件，不代表所有功能都已覆盖，真正能做什么要看命令、依赖和测试记录。

CLI（命令行接口） 是一种通过文本命令而非图形界面操作软件的交互方式。程序对外暴露一组带参数和选项的命令，执行后以文本或结构化数据（如 JSON）返回结果。对 AI Agent 而言，CLI 的核心优势是可发现、可组合、可校验：命令说明能被读取，输出格式固定，Agent 无需依赖屏幕截图或坐标点击即可判断操作是否成功。CLI-Anything 正是利用这一点，把图形软件原本只能通过鼠标完成的操作，映射为语义明确的命令，让 Agent 通过"读取说明—选择命令—解析返回值"的循环稳定推进任务。

如何上手：先找现成工具，再考虑生成

使用前先问一个问题：我需要的工具已经有人做好了吗？有就直接通过 CLI Hub 安装——Search 搜索、Info 看说明、Install 安装、Launch 启动。安装前要看清来源和依赖，有的工具需要本地文件权限，有的连接服务，还有的要求原桌面软件已安装。

UP 主用一个 DrawIO 实例演示了实际流程：创建 900×420 画布保存为可编辑工程文件，通过 Project 参数明确指定操作对象；添加 API 和 DB 两个节点，设置类型、位置、大小和编号；执行 connect add 连线；最后用 Project info 查询状态，返回两个图形和一条从 API 到 DB 的边。

这个例子的关键在于 Agent 的工作方式：先读工具说明选命令，再根据返回的 JSON 继续操作。返回结构化结果——节点编号、类型、坐标——让下一条命令可以精确引用，而不是靠猜。

如果目录里没有需要的适配，就走生成器路线。以 Claude Code 为例，添加插件市场后安装 CLI-Anything 插件，把目标软件源码或项目路径交给斜杠命令，Agent 会分析接口并生成命令行代码、测试与说明。第一版通常只覆盖最明显的操作，可以用 refine 命令指定希望补齐的工作流，再重新测试。

底层原理：生成与运行分离

拆开来看，第一阶段是生成工具——编码 Agent 读取软件资料，设计接口并写代码；第二阶段是运行工具——调用已生成的命令修改文件或访问后端服务。普通命令执行不需要每次重新生成代码，命令本身是具体程序，可以单独运行和测试。

生成过程被组织成七个阶段：分析、设计、实现、制定测试计划、实现测试、记录结果、打包安装。规范里还补充了技能文档生成，让 Agent 知道怎样使用产物。接口设计、测试依据、安装入口和使用说明都是交付的一部分。

以 DrawIO 的真实代码为例，CLI 负责解析命令组、参数和选项，ShapeAdd 对应具体函数，取得当前绘画后把类型、坐标和标签传给图形操作模块，最后统一输出结果。可以把它理解成翻译层：外面是易调用的命令，里面仍是明确的业务函数，而不是靠截图猜下一步点哪里。

连续操作需要记住状态。DrawIO 的 Session 持有当前 XML 工程，修改前保存快照，支持进程内撤销和重做；分开运行的命令则通过工程文件接续。但 UP 主提醒，保存了绘画编号不代表全部撤销历史都会跨进程保留，具体行为要看实现。

编码 Agent 指具备读写文件、执行命令和运行测试能力、能够自主完成编程任务的 AI 智能体，如 Claude Code。与普通对话模型不同，它可以主动浏览项目、修改源码并反复运行验证，因此适合承担"分析目标软件接口并生成 CLI 适配层"这类需要多轮迭代的工程工作。生成器路线中提到的斜杠命令（slash command），就是在编码 Agent 的会话里以 /xxx 形式触发的预设指令，用于把特定任务（如分析源码、生成命令、运行测试）固化成可重复调用的流程，降低用户描述成本。

端到端测试（E2E 测试） 与单元测试互补：单元测试在隔离环境中验证单个函数或参数处理的正确性，速度快但无法证明产物真实可用；端到端测试则从完整流程出发，调用真实软件或真实依赖，检查最终输出的文件、图片或服务状态是否符合预期。CLI-Anything 中，导出功能往往依赖桌面程序存在，若环境缺少该依赖，相关 E2E 测试可能被跳过而仍显示"通过"，因此评估时必须区分"执行通过"与"被跳过"，并确认关键产物能被实际打开和校验。

适用边界：命令行不会绕过软件限制

真正的执行路径因软件而异：有的适配写入原生工程格式，有的调用脚本接口，有的访问服务 API。以 DrawIO 导出为例，代码找到桌面程序、拼出 Export 和 Format 参数、再启动子进程，最终渲染仍交给原软件——这也是它和只生成一张看起来相似的示意图的区别。

测试至少要分两层：单元测试检查参数、状态和文件结构；端到端测试尽量调用真实软件检查产物。还要看清哪些测试被跳过——缺少桌面程序时，图片导出测试可能根本没有执行。所以不要只看通过数量，要看覆盖的任务、外部依赖，以及最终文件是否真的能打开、内容是否正确。

名字里有 anything，并不意味着任何软件都能无条件接入。有没有源码、SDK、文件格式或可调用的后端，决定了能走多远；图形界面的复杂交互也不一定都能映射成命令。更现实的做法是先选一个具体任务，确认输入和输出，再逐步扩大覆盖。登录凭据、服务权限、许可证和平台依赖仍然需要分别准备；只有界面才能完成的步骤，仍可能需要人工或界面自动化配合。

CLI-Anything 的价值在于把软件能力整理成 Agent 更容易发现、调用和检查的命令型接口。实际评估时，可以从小流程开始：创建工程、添加元素、查询状态、验证导出，拆成几步检查哪些命令已覆盖、哪些依赖还缺、错误能否被识别。小流程能稳定重复，再扩展到批量任务，才更容易判断是否值得投入。