夜雨聆风
2.8k Stars,一条命令让任何软件秒变 Agent 原生,元芳你怎么看?大人:RPA已死@!
其实，这也是我最近在想一个问题。
现在的 AI Agent 能力越来越强——能写代码、能查资料、能规划任务——但每次真正要让 Agent 去「操作」一个软件的时候，总会卡住。我记得有人问我，openclaw可以操作微信吗？的原理是什么呢，我的解释是，这依赖模型的多模态的能力，他可以直到你的终端上装了什么 App，能够看到当前屏幕是什么 App 在工作，也就能理解现在是个什么状态，然后基于你的指令做一些模拟点击，输入的动作。
我也想过，如果你想让 Claude 帮你自动处理一批 GIMP 图片，发现没有接口。想让 Agent 控制 Blender 渲染一组 3D 文件，发现只能截图点点点。想接入 LibreOffice 批量生成 PDF，发现要么手写 Python 胶水代码，要么用 RPA——而 RPA 这玩意儿，哪怕 UI 改了一个像素，整个流程就崩了。
所以我一直觉得，今天的 Agent 能力，和「真实软件世界」之间，有一道很深的沟。
然后我看到了港大数据智能实验室（HKUDS）发布的这个项目：CLI-Anything。 clianything[1]，我意识到，这个团队可能解决了我一直想解决的问题，让 agent无痛操作各种软件。
先说我看到它之后的第一反应
一条命令，把任何软件转成 AI Agent 可控的 CLI 工具。 clianything[2]
我第一反应是：这话说得也太大了吧，会不会是忽悠我的，怎么这么轻而易举就实现了呢？
然而，我看到而且它列出了 1436 个测试，100% 通过率，覆盖了 9 款真实软件的端到端验证。 这不是 README 吹牛，是有测试数字撑着的。
好，那就认真研究一下它到底做了什么。因为这个测试数据在我看来，的确很牛逼，我猜你也开始这么认为。
问题的本质：Agent 和软件之间的「语言不通」
先想清楚问题在哪里。
今天一个 AI Agent 想控制一个软件，大概有几条路：
路线 A：GUI 自动化（RPA）截图 → 识别按钮 → 模拟点击。这个方案几乎人人都试过，也几乎人人都被坑过。UI 改版、分辨率变化、弹窗出现——任何一个变化都可能让流程静默地出错。更要命的是，这种方式没法「批量」，速度慢，不稳定。
路线 B：MCP（Model Context Protocol）MCP 是 Anthropic 推出的协议，思路很好，但问题是：你得手动给每个软件写 MCP Server，这本身就是一个不小的工程量。而且 MCP 引入了额外的通信层，对于简单场景显得有点「重」。我理解大多数 mcpserver 可能还需要厂商自己提供，不然你就得破壳人家的应用，这技术难度对于我这种小白来讲，着实会有点大，精力也有限。
路线 C：直接调 API很多软件根本没有对外暴露的 API，尤其是桌面软件。
所以你会发现，每条路要么太脆弱，要么太麻烦，要么根本走不通。
所以，我在之前的认知中，这个事情就这么卡住了，所以，港大他们做了啥，解决了这个难题呢？
CLI-Anything 的思路：为什么是 CLI？
这里要停下来认真想想。
CLI-Anything 选择了 CLI（命令行接口）作为 Agent 和软件之间的「通用语言」，这个选择背后有一些很朴素的道理：
-
• 文本命令天然契合 LLM 的格式。大语言模型本来就是处理文本的，你给它一个 gimp-cli resize --width 800 --input photo.jpg，它一眼就能理解这个命令的意图，比让它去理解 UI 控件容易多了。 -
• CLI 可以链式组合。 cli-gimp resize ... | cli-gimp export --format png这样的管道流，天然就是「多步骤工作流」，Agent 可以把复杂任务拆解成一系列 CLI 调用，不需要任何特殊框架。 -
• –help 就是自描述文档。Agent 不需要你额外写 API 规范，直接运行 --help就能动态发现这个工具有哪些能力、接受哪些参数。 -
• –json 输出结构化数据。每条命令内置 --json参数，返回干净的 JSON，Agent 解析零歧义；人类调试时看格式化的表格。
你看，其实 CLI 这个思路并不新鲜，但把它作为 Agent 接入层的「标准协议」，然后再用 AI 自动生成这个 CLI——这才是 CLI-Anything 真正聪明的地方。
下面，我们来说说CLI-Anything的核心机制：7 阶段全自动流水线
说了上面那么多，你可能还是不直到，CLI-Anything到底是怎么自动生成 CLI 的？
官方给出了一个 7 阶段的流水线。我把它整理成一个数据流程图：
┌─────────────────────────────────────────────────────────────────────┐│ CLI-Anything 7阶段自动化流水线 │└─────────────────────────────────────────────────────────────────────┘ 输入：任意软件代码库（本地路径 或 GitHub 仓库地址） │ ▼ ┌─────────────┐ │ Phase 1 │ 分析（Analyze） │ 扫描源代码 │ ─── 识别 GUI 操作 → 映射到底层 API 调用 └──────┬──────┘ │ ▼ ┌─────────────┐ │ Phase 2 │ 设计（Design） │ 架构规划 │ ─── 设计命令组 & 状态模型 & 会话管理结构 └──────┬──────┘ │ ▼ ┌─────────────┐ │ Phase 3 │ 实现（Implement） │ 代码生成 │ ─── 构建 Click CLI + REPL 交互层 + JSON 输出支持 └──────┬──────┘ │ ▼ ┌─────────────┐ │ Phase 4 │ 规划测试（Plan Tests） │ 生成测试计划│ ─── 输出 TEST.md，覆盖单元测试 & 端到端测试场景 └──────┬──────┘ │ ▼ ┌─────────────┐ │ Phase 5 │ 编写测试（Write Tests） │ 测试实现 │ ─── 合成数据单元测试 + 真实软件后端端到端测试 └──────┬──────┘ │ ▼ ┌─────────────┐ │ Phase 6 │ 文档（Document） │ 文档生成 │ ─── 更新 README、TEST.md，生成完整 API 文档 └──────┬──────┘ │ ▼ ┌─────────────┐ │ Phase 7 │ 发布（Publish） │ 打包发布 │ ─── 创建 setup.py，pip install -e . 安装到 PATH └──────┬──────┘ │ ▼ 输出：生产级 CLI 包（如 cli-anything-gimp、cli-anything-blender） 支持 --help / --json / REPL / 持久会话状态有几个细节值得注意：
Phase 1 的「映射」是最难的一步。软件的 GUI 操作和底层 API 之间往往不是一一对应的，比如 GIMP 的「调整色阶」按钮，背后可能是调用了好几个不同的底层函数。这一步用 AI 去分析源代码，找出这个对应关系，是整个流水线的核心智力密度所在。
Phase 3 选择了 Click 框架。Click 是 Python 生态里非常成熟的 CLI 框架，用它生成的命令，天然支持 --help 的标准化输出，格式对 Agent 非常友好。
Phase 5 分两层测试。合成数据的单元测试 + 真实软件后端的端到端测试，两层覆盖。这也是为什么它能跑出 1,436 个测试 100% 通过的成绩，而不是那种只在 Mock 数据上测试的「假通过」。
好的，新手环节来了，其实上手就这四步，5 分钟跑通
说了这么多原理，来看操作。
前提：需要安装 Claude Code（Anthropic 的编程 Agent 工具）。
Step 1：把 CLI-Anything 插件市场加入 Claude Code
/plugin marketplace add HKUDS/CLI-AnythingStep 2：安装插件
/plugin install cli-anything就这，对的，就这～～
Step 3：指向你想要「接管」的软件
# 指向本地代码库/cli-anything ./gimp# 或者直接指向 GitHub 仓库/cli-anything https://github.com/blender/blender然后等 7 个阶段跑完，全自动，不需要人工介入。
Step 4：安装并使用生成的 CLI
pip install -e .# 现在就可以用了cli-anything-gimp --helpcli-anything-gimp resize --width 1920 --input photo.jpg --jsoncli-anything-blender render --scene my_scene.blend --output ./output/
生成的 CLI 是标准 Python 包，Claude Code、Cursor、nanobot 等任何能跑 shell 命令的 Agent 框架都能直接调用。
我们不妨深想一层：它解决的不只是「工具接入」问题
我在看这个项目的时候，反复在想一件事：
它本质上在做什么？
它在做的事，用一句话概括：把「为人类设计的软件」翻译成「为 Agent 设计的接口」。
这两类接口的需求其实是截然不同的：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
--help
|
|
|
|
|
|
|
|
|
今天绝大多数软件是为人类设计的，但 Agent 数量在快速增长，未来很大一部分「操作者」不是人，而是 Agent。CLI-Anything 做的，就是在这两个时代之间架了一座桥。
一个我觉得值得深想的问题
CLI-Anything 现在依赖 Claude Code 作为驱动，这意味着你得先有 Claude Code 的访问权限。不过我觉得 Codex 应该完成类似的工作也不是太大的问题。Claude Code，Codex，龙虾🦞，本质上都是一个 agent 而已。只不过，我们愿意说 Claude Code 配合起 opus4.6 模型，是当前最强 agent，没有之一。
但它生成的 CLI 本身是独立的标准 Python 包，一旦生成完成，就和 Claude Code 没有绑定关系了——你可以在任何 Agent 框架里跑它。
这个设计思路有点意思：用一个 AI 工具，生成另一个 AI Agent 可以使用的工具。生成阶段和使用阶段是解耦的。
这意味着理论上，社区可以逐步积累一个「CLI 接口包」的生态——你不需要每次都重新生成，直接用别人已经生成好的 GIMP CLI、Blender CLI、LibreOffice CLI 就行了。官方网站上提到，他们已经在 9 款主流应用上做了完整验证。 这个生态如果建起来，价值会相当大。
有很多人吐槽，openclaw🦞烧 token，其本质上，就是这种操作软件的不便性带来的痛点，加入有一条这样的高速通道，api 直打具体动作，那么油耗将会急剧降低。
不过话说回来，它现在的限制也很实在：目标软件必须安装在本地系统上。 这不是妥协，官方的解释是”真实集成意味着真实能力”——生成的 CLI 调用的是真实后端，LibreOffice 生成的是真实 PDF，Blender 渲染的是真实 3D，不是玩具实现。但这也意味着，如果你想在云端 Agent 里用它，需要在运行环境里提前装好这些软件。
这个取舍，怎么看都觉得目前阶段是合理的。当然，我觉得 SAAS 的概念依然可以延续，为什么软件不能在云端，难道不是在云端才是一种更加合适的方式，未来用户一人一个 超级 agent 就够了。装那么多得软件干啥。
引用链接
[1] clianything: https://clianything.org[2] clianything: https://clianything.org/zh
