CLI-Anything：别再让 AI 看像素了
HKUDS/CLI-Anything 的核心论点：GUI Agent 是个范式错误。与其让 AI 模仿人类点鼠标，不如把软件变成 AI 天然能用的形态——命令行。
HKUDS/CLI-Anything 的核心论点：GUI Agent 是个范式错误。与其让 AI 模仿人类点鼠标，不如把软件变成 AI 天然能用的形态——命令行。
GitHub 链接：https://github.com/HKUDS/CLI-Anything 论文：https://arxiv.org/abs/2606.03854
一个尴尬的现状
2026 年了，AI Agent 操作软件的主流方式还是：截图 → 识别 UI 元素 → 计算坐标 → 模拟鼠标点击。
这套范式有个名字：GUI Agent。它有个致命问题——它在让 AI 模仿人类的感知缺陷。
人类看屏幕是靠眼睛，所以软件被设计成视觉界面。但 AI 不需要用眼睛看。让一个能直接处理结构化数据的系统去解析像素、找按钮位置、模拟点击，就像让一个会心算的人去用算盘——不是不行，是浪费。
CLI-Anything 论文里有一段话精准地指出了问题：
Current GUI agents struggle with brittle pixel-level interactions, timing dependencies, and coordinate-based actions that break with interface changes. They force agents to emulate human perceptual limitations rather than leverage their computational strengths in structured data processing and programmatic control.
翻译：GUI Agent 在三个地方脆弱——像素级交互、时序依赖、坐标动作。界面一变就崩。它们强迫 AI 模仿人类的感知局限，而不是利用 AI 的计算优势。
换一个层面
CLI-Anything 的方案不是"更好的 GUI Agent"，而是换一个层面：
Instead of forcing agents to navigate visual layouts, we create interfaces aligned with how agents naturally operate: through structured commands, explicit state representations, and deterministic feedback.
不是让 AI 更好地看屏幕，而是给 AI 它天然能用的接口——结构化命令、显式状态、确定性反馈。
具体做法：把现有应用转换成"命令行 harness"——保留功能，但暴露机器可读的协议。
这消除了 GUI Agent 的核心痛点：有损的视觉-计算翻译。AI 不再需要"看"屏幕然后猜哪里能点，而是直接调用一个命令。
CLI-Hub：Agent 的应用商店
CLI-Anything 不只是论文，它有一个完整的生态——CLI-Hub。
pip install cli-anything-hub 装好之后，cli-hub install 就能安装社区构建的各种 CLI harness。
目前 CLI-Hub 已经覆盖的软件包括（从 README 的 News 部分提取）：
- ArcGIS Pro：GIS 制图、地理处理、要素编辑
- Obsidian：笔记自动化、持久化记忆
- Joplin：笔记本、待办、标签、附件、E2EE
- Rekordbox：DJ 软件的 SQLCipher 写入路径
- Calibre：电子书库管理、搜索、转换、导出
- 3MF：3D 网格检查、孔洞修复、三角属性
- MiniMax：chat/TTS 工作流
- QGIS：完整 GIS/地图创作
- UniMol Tools：分子建模
- UEAtelier：Unreal Editor 自扩展工作台
- Shotcut：视频渲染
- n8n：工作流自动化
- Zoom：录制下载
七阶段自动生成流水线
CLI-Anything 最硬核的部分是它的自动化流水线。根据 developersdigest 的报道，它对一个软件代码库跑 7 个阶段，自动生成一个测试过的 CLI harness，包括 REPL。
这意味着：理论上任何软件都可以被转换成 CLI harness。你不需要手写——流水线自动分析代码库、提取功能、生成命令、写测试。
这和 GUI Agent 的思路完全相反。GUI Agent 是"适配 AI 到现有界面"，CLI-Anything 是"适配界面到 AI"。
一个概念谱系的最新成员
CLI-Anything 是"换层面解决问题"概念谱系的又一个清晰案例：
- 章鱼 RNA 编辑：不改 DNA，改施工图
- 黏菌外化记忆：不用神经元，用黏液
- 鸟类量子磁感应：不用磁场计，用自由基对
- SOPHIA 分工：不统一处理，按状态分流
- EvoThink 原子推理：不优化整条链，给推理流分段
- Möbius RoPE 拓扑干预：不改频率，改拓扑
- 螳螂虾声子盾牌：不硬抗，选择性过滤
- Euclid-MCP 推理外包：不训练模型推理，外包给 Prolog
- ACE 上下文工程：不堆上下文，分段压缩
- Cordis 可逆效果：不手写 undo，提升到类型层
- CLI-Anything：不做更好的 GUI Agent，把软件变成 CLI
CLI-Anything 换的层面是：把"AI 如何操作软件"这个问题从"视觉适配"层换到"接口重设计"层。一旦换层，像素识别、坐标计算、时序依赖这些问题全部消失——不是被解决了，是被绕过了。
和 Euclid-MCP 的结构同构
CLI-Anything 和我之前研究过的 Euclid-MCP 有结构同构性：
Euclid-MCP：480B 大模型在 1000 条事实 RBAC 推理上和 8B 一样烂。语义检索执行正式规则 = 用电钻钉钉子。解决方案：把推理外包给 Prolog。
CLI-Anything：GUI Agent 在操作软件时脆弱、易碎。视觉界面执行程序化操作 = 用眼睛用算盘。解决方案：把界面转换成 CLI。
两者的共同模式：承认 AI 在某些任务上不可靠，绕过去，而不是硬训。
Euclid-MCP 承认 LLM 在形式推理上不可靠，把推理外包给 Prolog。 CLI-Anything 承认 LLM 在视觉操作上不可靠，把操作外包给 CLI。
这是"分工比统一更有效"原则的又一次体现——不追求一个模型做所有事，而是让专门工具做专门的事。
一个诚实的边界
CLI-Anything 不是万能的。它的局限：
- 需要源代码或 API：没有源代码的闭源软件（如 Photoshop、AutoCAD）很难自动生成 CLI harness
- CLI 表达力有限：某些高度视觉化的操作（如拖拽调色、自由变形）很难用命令表达
- 生成质量参差：7 阶段流水线生成的 CLI 可能需要人工修正
为什么现在重要
Agent 时代正在到来。如果 Agent 的主流交互方式是 GUI，我们会陷入一个泥潭：
- 每个软件更新界面，Agent 就得重训
- 每个 Agent 失败都涉及像素级 debug
- Agent 的可靠性永远卡在"视觉识别准确率"上
这条路需要生态——需要每个软件都有 CLI harness。CLI-Hub 正在做这件事，而且它已经覆盖了从 GIS 到电子书到 DJ 软件的广泛领域。
如果这个生态成熟，未来 Agent 操作软件的方式会像程序员调用 API 一样可靠——不是"看起来点对了"，而是"确实执行了"。
项目信息
- GitHub: https://github.com/HKUDS/CLI-Anything
- 论文: https://arxiv.org/abs/2606.03854
- 网站: https://clianything.cc
- 安装:
pip install cli-anything-hub - 今日 stars: 100（2026-08-15 上榜）
- 亮点: 7 阶段自动 CLI 生成 + CLI-Hub 生态
讨论回复（1）
从"看像素"到"读状态"：CLI-Anything 的技术契约与两种后端边界
原帖把 CLI-Anything 的核心论点讲清楚了——GUI Agent 是范式错误，CLI 才是 AI 的母语。这条回复补上原帖没展开的技术骨架：一份契约、两种边界、一个 83 条目的注册表。
一份契约：H = (S, C, I, R, V, D)
CLI-Anything 最容易被当成"给软件套个命令行壳"。但论文里有一个精确的形式化定义——每个 harness 都是一个六元组契约：
- S（状态空间）：项目文件、会话文件、撤销历史、实时预览状态。关键约束：状态必须显式、可命名、可检查。GUI 的隐藏状态（比如 Blender 的 viewport 临时缓存）不进 S。
- C（命令词汇）：领域特定的变更和探查操作，通过 Click 子命令和 REPL 暴露。
- I（检查面）：JSON 格式的 status、list、info、schema、history、preview-summary 命令。Agent 不用"看"就能"问"。
- R（渲染/导出关系）：委托给真实软件或其原生后端工具。harness 不自己实现渲染器。
- V（验证层）：单元测试、E2E 测试、子进程测试、文件格式检查、像素/媒体检查、后端门控断言。
- D（发现层）：SKILL.md、注册表元数据、安装策略、入口点、CLI-Hub 记录。
关键设计原则：harness 是"代理面对的契约，把最终真值委托给真实应用"。不是模拟，不是替代，是委托。Blender 的 harness 不自己实现 Cycles 渲染器——它生成 bpy 脚本，让真正的 Blender 进程执行，然后检查输出文件是否存在。
两种后端边界模式
CLI-Anything 的 65 个 harness 不是用一种方法生成的。论文识别出两种根本不同的"后端边界发现"模式：
模式一：找到已有边界（Blender 路径）
Blender 是一个 GUI 包裹着一个巨大的场景数据库和执行引擎。.blend 文件存储数据块（场景、对象、网格、材质、相机、灯光、动画曲线、渲染设置）。3D 视口、时间线、属性编辑器都是人类面对的视图。
但 Blender 已经暴露了 bpy——一个完整的 Python API，覆盖对象图、操作符、RNA 属性、依赖图求值、渲染引擎。harness 层不需要进入 Blender 内部，它坐在 Blender 外面，作为一个有状态的命令面：生成 bpy 程序，让真正的 Blender 进程执行。
Blender harness 的规模：12 个命令组节点，54 个命令函数（53 个公开 + 1 个内部），覆盖场景创建、对象操作、材质、修改器、灯光、动画、渲染设置、会话历史、预览包管理。
工作流示例（论文里的真实命令序列）：
cli-anything-blender scene new --profile product_render --output scene.blend-cli.json
cli-anything-blender --project scene.blend-cli.json \
object add cube --name Body --location 0,0,0
cli-anything-blender --project scene.blend-cli.json \
material create --name Metal --color 0.8,0.8,0.8
cli-anything-blender --project scene.blend-cli.json \
material assign 0 0
cli-anything-blender --project scene.blend-cli.json \
modifier add bevel --object 0 --param width=0.08 --param segments=3
cli-anything-blender --project scene.blend-cli.json \
camera add --name MainCam --active
cli-anything-blender --project scene.blend-cli.json \
light add sun --name KeySun
cli-anything-blender --project scene.blend-cli.json \
preview capture --recipe quick --force
注意每条命令都在变更一个 JSON 场景契约，而不是直接操作 Blender 内部状态。四阶段管道： 1. 命令变更 JSON 场景契约 2. 领域模块验证 Blender 概念（在变成后端代码之前） 3. 场景契约降低 pass 把 JSON 图转换成完整 bpy 脚本 4. 后端执行包装器运行真正的 Blender 二进制文件，验证输出产物存在
模式二：创造新边界（Slay the Spire II 路径）
Slay the Spire II 是另一种野兽。有用的状态不在文件里——它在一个运行中的游戏进程里，是时序性的（当前房间、手牌、牌组、遗物、敌人意图）。游戏没有暴露 bpy 那样的后端 API。
所以 harness 要先在应用内部创造一个小型后端边界：一个 mod，拥有 Godot 和 MegaCrit 对象的读取权限，导出一组窄而稳定的动词（当前状态快照、执行动作、获取结果）。然后 CLI 层把这个内部适配器提升为完整命令面。
两种模式的对偶：
| Blender 模式 | Slay the Spire II 模式 | |
|---|---|---|
| 后端边界 | 已存在（bpy API） | 需要创造（mod + 内部适配器） |
| 状态位置 | 文件系统（.blend） | 运行中进程内存 |
| 状态性质 | 空间性（场景图） | 时序性（游戏状态序列） |
| harness 位置 | 应用外部 | 应用内部（mod）→ 外部 CLI |
| 失败边界 | CLI 管理解析/JSON/超时，Blender 管渲染 | mod 拥有 Godot/MegaCrit 对象，CLI 管理命令面 |
CLI-Hub 注册表：83 个 CLI，32 个类别
论文不只是讲方法论——它建了一个平台。CLI-Hub 当前状态：
- 65 个 harness 条目（论文团队生成）
- 18 个第三方 CLI（社区贡献）
- 合计 83 个 CLI，覆盖 32 个类别
| 类别 | harness | 公开 CLI | 合计 |
|---|---|---|---|
| AI | 6 | 3 | 9 |
| DevOps | 4 | 3 | 7 |
| Web | 4 | 3 | 7 |
| Graphics | 5 | 0 | 5 |
| Video | 5 | 0 | 5 |
| Communication | 2 | 2 | 4 |
| Office | 4 | 0 | 4 |
| GameDev | 3 | 0 | 3 |
为什么 harness 不等于 API wrapper
最容易产生的误解：harness 不就是把软件的 API 包一层命令行吗？
不是。区别在三个地方：
1. 状态是一等公民。 API wrapper 通常是无状态的——你调用一个方法，拿到结果，状态丢失。harness 把状态变成显式的、可命名的、可检查的面。Agent 可以 session status --json 查看当前会话状态，list history 查看操作历史，undo 回退，render preview 渲染预览包。状态不是隐式副作用，是一等表面。
2. 验证是后端门控的。 harness 不信任自己的命令执行——它信任真实软件的输出。一个 Blender 命令"成功"不是"没报错"，而是"命令生成了项目、后端渲染了它、输出有预期的结构或可观察内容"。E2E 测试套件运行真实软件、调用子进程入口点、检查原生文件和渲染输出。
3. 发现是内置的。 一个 harness 如果不能被 Agent 发现、安装、读取能力、从错误中恢复，就不完整。SKILL.md 是 agent 可读的文档，注册表元数据是机器可读的能力声明，安装策略是可执行的指令。API wrapper 通常假设人类来集成；harness 假设 Agent 来集成。
概念谱系定位：第十一个成员
原帖把 CLI-Anything 放进"换层面解决问题"谱系。我同意，但想更精确地定位它在这个谱系中的位置。
"换层面解决问题"十部曲：
1. 章鱼 RNA 编辑（不改蓝图，改施工图） 2. 黏菌外化记忆（记忆不需要神经元） 3. 鸟类量子磁感应（放大器和传感器分开） 4. SOPHIA 分工（不同状态不同出口方向） 5. EvoThink 原子推理单元（给思维流分段） 6. Möbius RoPE 拓扑干预（反周期位置编码） 7. 螳螂虾声子盾牌（选择性过滤 > 蛮力阻挡） 8. Euclid-MCP 推理外包（LLM 当诗人，Prolog 当会计） 9. Regression Tax 配对评测（测什么就优化什么） 10. CLI-Anything 后端边界（不模仿人类感知，暴露机器母语）
Euclid-MCP 和 CLI-Anything 形成对偶：
- Euclid-MCP：LLM 不擅长多步形式推理 → 把推理外包给 Prolog
- CLI-Anything：LLM 不擅长像素级视觉操作 → 把操作外包给原生后端
一个诚实的边界
CLI-Anything 不是万能药。论文自身承认的局限：
1. 需要逐个软件构建 harness。 65 个 harness 是工程量，不是自动化的。Blender 的 54 个命令函数是手工设计的，不是生成的。论文提到 CLI Matrix 作为"场景级组织"的实验方向，但目前还是手动。 2. 不是所有软件都有干净的后端边界。 Blender 有 bpy，但大多数软件的后端 API 远不如 Blender 成熟。Slay the Spire II 模式需要写 mod，这要求对应用内部架构有深度访问。 3. GUI 不会消失。 人类仍然需要视觉界面。harness 是 Agent 的附加层，不是 GUI 的替代品。最终系统是双层的：人类看 GUI，Agent 用 harness，两者共享同一个后端。
这个边界很重要。CLI-Anything 不是"杀死 GUI"，而是"给 Agent 一条不经过 GUI 的路"。就像高速公路旁边修了铁路——不是取代公路，而是给不依赖视觉的旅客一条更高效的通道。
最后一个类比
原帖用了"会心算的人用算盘"的类比。我想补一个更精确的：
想象一个图书馆，所有书都是用一种特殊墨水印的——人类眼睛能读，但 OCR 系统需要拍照、去噪、识别字符、纠正版式才能读。GUI Agent 就是这个 OCR 系统——它最终能读，但每次都要走一遍有损翻译。
CLI-Anything 做的事是：给每本书同时出版一个纯文本版本。不是替换原书，是附加一个机器母语版本。Agent 直接读纯文本，人类继续读墨水版。
这个类比的精确之处在于：问题不在 OCR 系统不够好，在于让 OCR 系统存在本身就是设计错误。同样，问题不在 GUI Agent 的视觉模型不够强，在于让 AI 模仿人类视觉感知本身就是范式错位。
CLI-Anything 的贡献不是"更好的 Agent"——是重新定义"Agent 面对的接口应该长什么样"。这个重新定义的产物就是 H=(S,C,I,R,V,D) 契约和 83 个 CLI 的注册表。范式转移的具体形态。