CLI-Anything 是一个 AI Agent 驱动的自动化工具。你给它一个软件的源码，它自动生成一套完整的命令行接口，让 Agent 通过发现功能、通过获取结构化输出，像人类点击菜单一样操控专业软件——但全程只用命令行。
它的产出物不是文档，不是配置，而是一个真正能跑的 Python CLI 包。
Agent 与软件之间的鸿沟
现有的方案要么是脆弱的 GUI 自动化（截图、点像素、RPA），要么是覆盖面有限的 API 封装，要么干脆重新实现一个阉割版。每一种都不够好。
为什么是 CLI？
CLI 是人类和 AI Agent 共通的万能接口。这个选择并非偶然：
- 天然匹配 LLM— 文本命令就是 LLM 最擅长的输入输出格式，可自由组合成复杂工作流
- 自描述— 一个就能让 Agent 自动发现全部功能
- 确定且可靠— 输出稳定一致，Agent 行为可预测
- 轻量通用— 几乎零开销，跨平台运行
Claude Code 每天通过 CLI 执行数以千计的真实任务，这本身就是最好的验证。
七阶段流水线
把一个软件的源码扔给 CLI-Anything，它会自动走完七个阶段：
分析
设计
实现
规划测试
编写测试
文档
发布
三层架构
每个生成的 CLI 都遵循同一套分层设计：
调用
调用
指令层-ClickCLI
核心层-业务逻辑
后端层-真实软件
关键在于后端层——CLI-Anything 生成的是合法的中间文件（ODF、MLT XML、SVG），然后交给真实软件去渲染。它做的是软件的结构化接口，而不是替代品。
从 GUI 到 CLI 的映射
以 GIMP 为例，Agent 在分析阶段完成的映射：
Agent 扫描源码识别出软件暴露的 API（GIMP 的 Script-Fu、Blender 的 bpy），按功能域分组，设计成层次化的命令结构。
不是编译器，是 AI Agent
CLI-Anything没有传统意义上的代码生成器或编译器。它的”转换引擎”就是 AI 编程 Agent 本身——Claude Code、OpenCode、Codex 这些工具。
工作流程是这样的：
换句话说，HARNESS.md 是写给 AI Agent 看的”施工图纸”，Agent 是”施工队”，源码是”原材料”，产出物是一个可安装的 CLI 包。
Agent 在分析阶段做了什么
当 Agent 拿到一个软件的源码后，它会按 HARNESS.md 的指引完成五步分析：
- 找到真正干活的后端— GUI 应用通常是”表现层 + 逻辑层”分离的。Agent 要穿透 GUI 外壳，找到核心引擎。比如 Shotcut 的界面是 Qt，但真正做视频处理的是 MLT 框架；GIMP 的滤镜背后是 GEGL 库。
- 建立 GUI → API 的映射表— Agent 逐一分析菜单项、按钮、对话框，找到每个操作对应的底层函数调用。这张映射表就是 CLI 命令的来源。
- 理解数据模型— 项目文件用什么格式？LibreOffice 用 ODF（本质是 ZIP 包裹的 XML），Kdenlive 用 MLT XML，Blender 用 .blend 二进制。Agent 需要知道怎么读写这些格式。
- 盘点已有的 CLI 工具— 很多后端自带命令行入口：、、、。这些是现成的积木，Agent 会优先复用而非重新实现。
- 识别命令模式— 如果软件支持撤销/重做，它大概率实现了命令模式（Command Pattern）。这些命令天然对应 CLI 操作。
从分析到代码：Agent 的生成策略
分析完成后，Agent 不是简单地”翻译”API，而是遵循一套严格的生成策略：
关键原则是：生成合法的中间文件，交给真实软件处理。Agent 不会试图自己实现图像滤镜或视频渲染——它生成 ODF 文件让 LibreOffice 转 PDF，生成 MLT XML 让 melt 渲染视频，生成 SVG 让 Inkscape 导出 PNG。
为什么这个方案能成立
你可能会问：让 AI Agent 读源码、写代码，靠谱吗？
CLI-Anything 的巧妙之处在于它把”不确定性”控制在了极小的范围内：
- HARNESS.md 提供了极其详细的规范— 不是”请生成一个 CLI”这种模糊指令，而是精确到文件命名、目录结构、代码模式、测试标准的完整施工手册
- 三层架构约束了代码结构— Agent 不需要做架构决策，只需要填充每一层的具体实现
- 四层测试验证产出质量— 1,508 项测试不是摆设，Agent 生成的代码必须全部通过
- 所有平台共享同一份方法论— 无论用 Claude Code 还是 Codex，产出的 CLI 结构一致
本质上，CLI-Anything 把”让 AI 写代码”这件高度不确定的事，通过方法论约束变成了一个可重复、可验证的工程流程。
不是一锤子买卖：refine 迭代改进
一次生成不可能覆盖软件的全部能力。CLI-Anything 提供了命令，支持增量式改进：
refine 的工作方式是：Agent 对比软件的完整能力和当前 CLI 的覆盖范围，识别出缺口，然后针对性地补充新命令、新测试、新文档。每次 openclaw docker 教程 refine 都是增量的、非破坏性的——可以反复执行，逐步扩大覆盖面。
这个设计很务实：复杂软件的功能成百上千，一次性全部生成既不现实也没必要。先跑通核心流程，再按需迭代，才是工程上可行的路径。
子命令模式：适合脚本和流水线
REPL 模式：适合多步交互
REPL（Read-Eval-Print Loop）是有状态的交互环境，会记住当前项目、操作历史，支持撤销/重做。直接运行命令即进入：
提示符自带上下文：表示当前项目，表示有未保存的修改。所有 CLI 共享统一的 REPL 界面（），不管操作哪个软件，交互体验都一致。
CLI-Anything 不是纸上谈兵。它在 11 款复杂应用上完成了实测，涵盖创意、办公、通信、图表和 AI 内容生成——这些软件此前对 Agent 几乎不可触及。
1,508 项测试，100% 通过。其中 1,073 项单元测试，435 项端到端测试。
HARNESS.md 是整个项目的灵魂——一份写给 AI Agent 看的标准操作手册。所有平台（Claude Code、OpenCode、Codex）都引用同一份文件，确保无论在哪个 AI 编程工具上运行，产出的 CLI 结构和质量都一致。
贯穿全文的核心模式只有一个：构建数据 → 调用真实软件 → 验证输出。
分析阶段：五步理解一个软件
- 识别后端引擎— GUI 应用通常将表现层和逻辑层分离，找到核心库（Shotcut 的 MLT、GIMP 的 ImageMagick）
- 映射 GUI 到 API— 每个按钮、菜单项背后都有一个函数调用
- 识别数据模型— 项目状态用什么格式存储？XML、JSON、还是二进制？
- 发现已有 CLI— 很多后端自带命令行工具（、、），这些是现成的积木
- 梳理命令模式— 如果应用有撤销/重做，它大概率使用了命令模式，这些命令就是 CLI 操作的来源
设计阶段：统一的命令分组
HARNESS.md 规定了七步实现顺序，不能跳跃：
- 数据层（XML/JSON 操作项目文件）
- 探查命令（、、— 让 Agent 先看再改）
- 变更命令（每个逻辑操作一个命令）
- 后端集成（封装真实软件调用）
- 渲染/导出（生成中间文件 → 调用真实软件转换）
- 会话管理（状态持久化、撤销/重做）
- REPL 界面（用统一的包装）
后端集成的代码模式值得一看：
没装就报错，给出清晰的安装指引。不降级，不跳过，不模拟。
测试阶段：四层验证体系
HARNESS.md 要求先写测试计划（TEST.md），再写代码。测试分四层，层层递进：
“运行没报错”不等于”输出正确”——必须用魔术字节、ZIP 结构、像素分析等方式验证输出。
发布阶段：PEP 420 命名空间包
多个 CLI 共存于同一个 Python 环境，互不冲突，通过独立安装卸载。
十条核心原则
以为例，看看产出物长什么样。
文件结构
三层架构的体现
HTTP
zoom_cli.py
core/meetings.py
core/participants.py
core/recordings.py
utils/zoom_backend.py
Zoom 云服务
Zoom 的特殊之处在于”后端”是云端 REST API 而非本地软件。但架构模式完全一致——是唯一与外部通信的模块，核心层只关心业务逻辑。
源码一瞥
入口文件遵循统一模式——无子命令时自动进入 REPL：
核心层只关心业务，不碰 HTTP：
Agent 的使用流程
规律很简单：只要有源码，就能生成 CLI。
以 Claude Code 为例，三步搞定：
也支持 OpenCode、Codex、Qodercli 等平台，详见项目 README。
CLI-Anything 给我最大的启发不是某个技术细节，而是一个思维方式的转变：
与其让 Agent 学会操作 GUI，不如为软件生成一层结构化的 CLI 接口。
CLI 是人类和 Agent 共通的语言。自描述，结构化输出，发现工具——这套机制已经被验证了几十年，天然适合 Agent 使用。
当 AI Agent 逐渐成为软件的主要用户时，CLI-Anything 提供的不只是一个工具，而是一条从”人用软件”到”Agent 用软件”的标准化升级路径。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/284943.html原文链接：https://javaforall.net
