让所有软件变得 agent-native：CLI-Anything 想解决什么

2026-08-10

CLI-Anything 的 README 一级标题就是 “CLI-Anything: Making ALL Software Agent-Native”（README.md:1），副标题两句话把它的判断摆了出来：“Today’s Software Serves Humans. Tomorrow’s Users will be Agents” 与 “Bridging the Gap Between AI Agents and the World’s Software”（README.md:8-9）。这是 HKUDS 的项目，配套技术报告是 arXiv 2606.03854，标题 “CLI-Anything: Towards Agent-Native Computer Use”（README.md:1717-1727、CITATION.cff:14-21），许可证 Apache License 2.0（LICENSE:1-2）。

按 GitHub API，截至 2026-08-10，仓库 HKUDS/CLI-Anything 有 46825 star、4359 fork、79 个 open issue，建仓日 2026-03-08，最后一次 push 是 2026-08-03。我们本地 clone 的快照是 39634a6。这几个数只是身份信息，不能拿来推导它成熟不成熟。

真正值得花时间的是另一件事：它对「让软件变得 agent-native」这个问题给出的答案形态。这个形态一旦看懂，你对这个仓库里所有数字的读法都会变。

它想补的缺口

它的假设很直白：现在的软件是给人用的——菜单、面板、拖拽、对话框，全都建立在「有一双眼睛在看屏幕」之上。agent 要用这些软件，要么去做视觉操控，要么等厂商提供 API。README 自述的适配对象是 “Make any software agent-ready for Pi, OpenClaw, nanobot, Cursor, Claude Code, etc.”（README.md:38），也就是说它不打算做一个新 agent，而是站在 agent 与软件之间那一层。

这一层它选了命令行。registry.json 的 meta.description 原文把自己描述为 “CLI-Hub — Agent-native stateful CLI interfaces for softwares, codebases, and Web Services”（registry.json:3-5）。注意其中的 stateful：它要的不是把 GUI 功能翻译成一次性命令，而是给出有状态的命令行接口，让 agent 能开工程、改、存、导出，中间保持上下文。

分发方式跟着这个选择走。README 开头把 CLI-Hub 定位成包管理器入口：pip install cli-anything-hub，然后 cli-hub install <name>（README.md:12）。也就是说，从 agent 的视角看，「获得操控某个软件的能力」被降级成了「装一个 pip 包」。

反直觉的那一处：答案的粒度是「一个软件一份独立产物」

看到「让所有软件 agent-native」这句话，多数人第一反应是某种通用机制——一层协议、一个适配器、一套能自动把 GUI 映射成命令的东西。CLI-Anything 不是。它的交付单元是：按软件逐个产出的一份独立产物——一份 harness（一个 Python 包形态的命令行工具）、一份给 agent 读的 SKILL.md、一份测试计划。 这份产物由 cli-anything-plugin 的 7 阶段生成流程产出：README 的 Quick Start 给的两个入口，一个是用现成生态（装 cli-anything-hub），另一个就是造新 CLI，写法是「装插件跑 7 阶段生成器」（README.md:183-187）。造出来之后登记进注册表，由 CLI-Hub 分发。

这一点在仓库结构上是硬证据。我们采集时（2026-08-10，快照 39634a6），find . -type d -name agent-harness | wc -l 数到 69 个 harness 目录，每个目录里是一整套针对那个软件的代码与文档。harness 内部那棵标准目录树长什么样，另有一篇专门讲，本篇只关心一件事：它是按软件逐个产出的，粒度是单个软件，不是一层能横扫所有软件的通用协议。

于是产生了三个直接后果，也是本篇最想让你带走的部分。

第一，覆盖面是供给侧计数，不是能力计数。 我们用 Python 解析 registry.json，clis 数组长度是 79。这 79 条按 category 分成 31 类，条数最多的是 ai（8 条），其次 web / devops / video / graphics 各 6 条。但 79 是「已经有人为它写过 harness 并登记」的软件数，不是「你装上就能操控」的软件数。

第二，它必然会长期处在「有的齐、有的不齐」的状态。 逐软件产出的东西没法整齐。79 条里有 68 条的 source_url 是 null（harness 就在这个仓库里），另外 11 条指向独立仓库；有 5 条的 skill_md 字段直接是 null（adguardhome、comfyui、mermaid、sketch、clibrowser），而 skills/ 目录下实际已经存在 cli-anything-adguardhome、cli-anything-comfyui、cli-anything-mermaid 三个目录——目录已建、注册表这一栏还空着。这是两处可各自核对的事实，我们只陈述到这里。

齐件情况另有一篇专门统计，这里只借一个总数说明问题：69 个 harness 里，<APP>.md、包内 README.md、SKILL.md、TEST.md 四份文档全齐的是 51 个，有缺件的 18 个。最极端的是 sketch：它的 agent-harness/ 整体不是 Python 结构，目录下是 package.json、src/cli.js、tests/build.test.js 这一套，*_cli.py 与 SKILL.md 都没有。它在 registry.json 里依然是正常的一条。

第三，注册表条目 ≠ 你本机能用。 这一条 README 自己写了：包装真实桌面软件的 CLI，需要用户自行安装上游应用（README.md:236）。harness 是壳，宿主软件得你自己装。你在注册表里看到 blender、gimp、kdenlive 这些条目，拿到的是驱动它们的命令行层，不是软件本身。

「驱动宿主」这件事要如实说

既然 harness 的工作是驱动本机上真实存在的软件，那它就会在你的机器上执行外部程序与脚本。仓库里这一点是明写的：不同 harness 的做法不止一种，有起子进程调二进制的，有走 HTTP REST 的，也有以 MCP 服务器为后端的——四种做法的具体行号另有一篇讲。共同点是，命令背后真的会有进程被拉起来。

仓库自己也把这当成一个安全面来对待。SECURITY.md 列了 5 类攻击面：子进程参数、Script-Fu 注入、XML/SVG 内容、路径穿越、凭据泄露，并给了对应缓解手段（SECURITY.md:14-22）。其中编解码器白名单被标为 “Breaking Change”：kdenlive / shotcut 的 melt 后端用 ALLOWED_VCODECS / ALLOWED_ACODECS 两个 frozenset 校验，不在名单内直接抛 ValueError（SECURITY.md:34-38）。同时这份文件开头写明它面向人类贡献者与安全评审，“NOT part of the CLI generation methodology — agents should follow HARNESS.md only”（SECURITY.md:3-5）。

这些是仓库文档写了什么，不是我们对安全性的结论——要不要在自己机器上跑，请结合你的环境自行评估。

项目自己划的边界

判断一个项目「想解决什么」，还得看它承认自己没解决什么。README 的 Limitations 一节自陈三条（README.md:1669-1671）：依赖前沿模型（点名 Claude Opus 4.6、Claude Sonnet 4.6、GPT-5.4）；依赖能拿到源码；生成出来的 harness 常需要多次 /refine 迭代。Roadmap 6 项里只有 1 项打了勾（“Produce SKILL.md alongside the CLI for agent skill discovery and orchestration”），其余 5 项未完成（README.md:1675-1681）。

平台侧的状态词也标得很实在。README 列了 10 个 agent 平台分节加 1 个「更多平台」分节，其中 5 个带 Experimental 标签（OpenCode、Goose、Codex、Hermes、Reasonix），另有一批带 Community 标签；Cursor 与 Windsurf 被放在 “More Platforms (Coming Soon)“（README.md:695,700-701）。单个 harness 也有类似标注，比如 NotebookLM 在演示表格里写的是 “NotebookLM CLI wrapper (experimental)“（README.md:1208）。

读它的数字时留个心眼

这个仓库的数字口径有几处对不上，看的时候需要知道该信哪个。

测试总数在英文 README 内部就有三个不同的值：徽章写 Tests-2,461_Passing（README.md:22），表格 Total 行写 2,461（README.md:1332），而测试摘要代码块的 TOTAL 行写 “2,464 passed”（README.md:1384）；页脚又写 “2,280 passing tests”（README.md:1743）。README 给的拆分是 “1,732 unit tests + 579 end-to-end tests + 19 Node.js tests”（README.md:1336），这三个数相加是 2330。四语 README 的测试数与演示数也各不相同：英文徽章 2,461 / Demos 18 Apps，中文徽章 1,741 通过 / Demo 13 款软件，日文徽章 1,540 / Demos 12 Apps，德文徽章 2,269 / Demos 18 Apps。

覆盖面的口径同样有多套。README 正文写 “Tested across 18 diverse, complex applications”（README.md:999），演示表格里带 cli-anything-* 入口的行有 44 行，而 registry.json 是 79 条。这三个数分别对应「README 自称测过的」「README 展示的」「注册表登记的」，不是同一个东西。规范域名也有两套并存：README 与徽章指向 hkuds.github.io/CLI-Anything/（README.md:12），而 docs/hub/llms.txt:5 声明 “Canonical site: https://clianything.cc”。

以上都只是差异陈述，我们不推断原因，也不据此评价项目。

你可以自己跑的核查动作

想判断某个软件在这个项目里到底处于什么状态，clone 之后按这三步走：

python -c "import io,json;d=json.load(io.open('registry.json',encoding='utf-8'));print(len(d['clis']))"
ls -d <软件名>/agent-harness
find . -type d -name agent-harness | wc -l

其中第三条是事实卡里原样记录的统计命令；前两条是按事实卡记录的统计方法组合出来的示例，未经实测，以你本地仓库的实际结构为准。JSON 一律用 Python io.open(..., encoding='utf-8') + json.load 解析后计数，也是我们这批采集时统一用的口径，比目测数组行数可靠。

第一条给你注册表条目总数（我们采集时是 79）；第二条看这条目在仓库里到底有没有对应的 harness 目录——排除掉下面说的两个坑之后，查不到就说明它是那 11 条指向独立仓库的条目之一；第三条给你仓库内 harness 的实际数量（我们采集时是 69）。

第二条有两个坑要提前知道。一是大小写：3mf 这条对应的目录是 3MF/，qgis 对应的目录是 QGIS/（我们采集时如此），在大小写敏感的文件系统上直接按 name 去查会落空，从而把它们误判成那 11 条独立仓库条目。二是反过来的情况：rekordbox 既有目录、skills/ 下也有对应的 cli-anything-rekordbox，但 registry.json 的 79 条里查不到它——目录在、注册表没有。所以这一步查出来的结果只能说明「目录在不在」，不能直接换算成「注册表登记没登记」。

第二步查到目录之后还有两件事要看：这个目录下有没有 SKILL.md 与 TEST.md（对应上面说的缺件），以及它要驱动的宿主软件你本机装没装。注册表能查到、目录也在，这两件仍然是各自独立的前提条件。

这三步跑完，你就不会再把「注册表里有 79 条」读成「79 个软件开箱能用」了。而这恰恰是这个项目最容易被误读的地方——它想解决的问题足够大，但它选的解法是一件一件补，所以任何时刻的覆盖面都得逐条去看，不能看总数。

本文依据 CLI-Anything 官方仓库（github.com/HKUDS/CLI-Anything）的 README、registry.json、 docs/ 与各 agent-harness/ 下的源码整理，核对日 2026-08-10，对应仓库快照 39634a6。本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何一个 harness，也没有在本机驱动过任何一款宿主软件，因此不涉及实际操控效果的任何描述。这类 harness 会在本机执行外部程序与脚本，是否使用请结合自身环境评估。注册表与 harness 内容随上游更新而变动，请以仓库最新内容为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。安全相关做法请结合自身环境评估，本文不构成安全方案建议。