CLI-Anything 软件 agent 化
39634a6。
本专题共 35 篇。内容依据
官方仓库
的 README、registry.json、docs/
与各 agent-harness/ 下的源码整理。
注册表与 harness 内容随上游更新而变动，请以仓库最新内容为准。
让所有软件变得 agent-native：CLI-Anything 想解决什么
CLI-Anything 自述要「让所有软件变成 agent-native」，但它给出的答案不是一层通用协议，而是按软件逐个产出一份 CLI 加一份 SKILL.md。本文顺着这个选择讲清它想补的缺口在哪，并落到最容易误读的一处：`registry.json` 里的 79 条是供给侧计数，不等于 79 个装上就能用。文中最后还会讲清，「注册表登记」「仓库内有 harness 目录」「宿主软件已装」是三个各自独立的前提，不要混成一件事来判断。
认识与注册表
注册表里是 79 条记录，仓库顶层却有 82 个目录，差的那几个是什么值得先搞清楚。这一组还包括 registry 与 public_registry 的字段差异、矩阵这层抽象干什么用，以及 README 口径的安装说明——先看清它会往你机器上装到哪。
`registry.json` 的结构与那 79 条记录
把 CLI-Anything 仓库根目录的 registry.json 拆开看：顶层只有 meta 和 clis 两个键，clis 数组 79 条，15 个字段里只有 10 个是 79 条全覆盖的。三种 skill_md 取值分别指向哪里，字段缺失会让解析器在哪炸，以及为什么有一条记录不等于这软件你装上就能用。
注册表 79 条、顶层 82 个目录：差的那几个是什么
CLI-Anything 的 registry.json 有 79 条记录，仓库根目录有 82 个目录，很多人会顺手一减得出「差 3 个」。这两个集合的交集其实只有 68 个名字，两侧各自还剩 11 个和 14 个。本文把两份差集逐个列出来，说清大小写比对的坑，并交代 79 条条目距离「79 个能用的能力」还差什么。
`public_registry.json` 与 `registry.json` 差在哪
CLI-Anything 仓库根上并排放着两份 CLI 注册表，79 条和 22 条。本文把两份 JSON 的字段并集、来源口径与安装描述逐项摆开，并落到最容易踩的一处：public 那 22 条里，字段是稀疏的，有卸载命令的只有 5 条。
`matrix_registry.json` 是什么：矩阵这层抽象干什么用
CLI-Anything 除了那张 79 条的 registry.json，还有一张只有 5 条的 matrix_registry.json（数字均为截至 2026-08-10 的仓库快照）。本文拆这张表的 15 个字段、5 条矩阵各引了哪些 CLI，并讲透它最反直觉的一处——注册表里专门有一个字段用来登记「这件事做不到」。
README 口径的安装与使用：先看清它装到哪
照着 CLI-Anything 的 README 敲一条 pip 命令，机器上并不会多出任何一个能操控软件的能力。本文按 README 原文把安装拆成三层：hub 本身、单个 harness 包、你得自己装的宿主软件，并落到 `registry.json` 的字段与那句最容易被跳过的前置提醒。
harness 协议：这个项目真正的设计
八十多个应用之所以能用同一套方式接进来，靠的是一份高度同构的目录约定。这一组拆四件套各自写什么、给 agent 读的那份 SKILL.md 有哪些字段、<app>_cli.py 怎么注册命令，以及 harness 驱动宿主软件的四种方式与各自代价。最后一篇是缺件清单——不是每个 harness 都齐。
一个 harness 的标准目录结构：四件套是哪四件
CLI-Anything 用一份 747 行的 HARNESS.md 规定了每个 harness 该长什么样。本文拆这棵目录树的每一层、说清四份文档分别写给谁看，并落到最容易记反的那一处：`cli_anything/` 目录被明令禁止放 `__init__.py`，而仓库里有 8 个目录放了。
CLI-Anything 的 `<APP>.md` 里到底写什么：一层没有强模板的项目分析与 SOP
CLI-Anything 每个 harness 顶层都有一份写着「项目分析与 SOP」的文档。本文不复述 harness 四件套结构，只讲这一层：实读 67 份文件统计小节频次，对照三份样本的结构差异，说明它固定下来的不是模板而是三个必答问题，以及它与包内 README 的分工和读数口径。
给 agent 读的那份 SKILL.md：字段与正文结构
CLI-Anything 每个 harness 都带一份 SKILL.md，是 agent 判断"这个 CLI 能干什么"的主要依据。本文按仓库快照拆开它的 frontmatter 字段、正文小节顺序，以及它是怎么被生成出来的——它不是运行时反射的结果，而是对源码文本做正则抽取再套模板，这一点决定了你该怎么读它。
`TEST.md` 与测试组织：它到底测了什么
CLI-Anything 规范要求每个 harness 的 tests/ 下放一份 TEST.md，我们采集时实到 57 份。它看着像测试报告，前半段其实是编码之前写的计划稿。本文拆它的两段结构，并落到最反直觉处：规范要求 E2E 必须调起真软件，而样本 harness 的 TEST.md 明写「不需要装宿主软件」。
`<app>_cli.py` 的入口模式与命令注册方式
CLI-Anything 的 `<app>_cli.py` 是 harness 里同构度最高的一层。本文拆它的入口模式与两级命令注册，讲透最反直觉的一处：不带子命令时它不打 help 而是进 REPL，而 REPL 又把输入喂回同一棵 Click 命令树，同一个错误在两种模式下退出行为不同。
`core/` 与 `utils/` 的分工约定：这条线不是按「业务和工具」划的
CLI-Anything 的 harness 规范把 `core/` 和 `utils/` 都点了名，但真正的分界不是「重要的放 core、零碎的放 utils」。本文用四个样本 harness 的模块清单与行数对照，讲清这条线到底怎么划，以及那份「调用真实软件」的 backend 在依赖图上可以退到什么位置。
harness 怎么驱动宿主软件：四种方式与各自代价
同样一条 CLI-Anything 命令，最后可能是起子进程调二进制、调配套工具、发 HTTP 请求，也可能是连一个 MCP 服务器。本文按四个精读样本逐个落到 backend 文件与行号，说清各自要装什么、超时多久、失败长什么样，并拆开最反直觉的一处：backend 文件存在，不代表主命令路径真会调它。
同构度统计与缺件清单：哪些 harness 不齐
CLI-Anything 的 69 个 harness 看着高度同构，四件套全齐的却只有 51 个。本文把 25 项缺失逐一落到 18 个 harness 上点名，说清 sketch 为什么会被口径整排判红、被规范当范例的 browser 为什么缺 TEST.md，并给出可以自己跑一遍的核查命令与判定边界。
cli-hub 与分发层
从注册表到你本机的那一段由 cli-hub 负责：怎么拉取、怎么合并、装到哪些目录。这一组还包括矩阵机制与本地渲染、给 agent 用的那层元技能，以及装进 Claude Code 等宿主时的几种插件形态。
cli-hub 做什么：从注册表到本机的那一段
cli-hub 是 CLI-Anything 的分发入口，把远端注册表里的条目装到你本机。本文按「拉表 → 合并 → 选策略 → 记账」四步拆这条链路，落到 installer.py 的五种安装策略与那个压根不装东西的 bundled，并说清「注册表有 79 条」为什么不等于「有 79 个能用」。
安装策略与落点：cli-hub 会往你机器上写哪些目录
装一个 CLI-Anything harness，文件到底落在哪？本文按 installer.py 的行号拆开 cli-hub 的五种安装策略与默认推断规则，列全 ~/.cli-hub/ 下的账本、缓存与渲染产物，说清「安装记录」和「真实落点」为什么是两件事，并给出可自查的核对动作。
registry 的拉取与合并规则：117 行代码决定你看到多少条
cli-hub 的 registry 层只有 117 行，却同时管着两个远端清单、一份本地缓存和一个 `_source` 标记。本文拆它的拉取顺序、缓存回落条件与合并规则，说清 `_source` 为什么不只是显示字段，并给出你可以自己复现的核对命令。
cli-hub 的矩阵机制与本地渲染：装完不等于能力齐了
cli-hub 的 matrix 层把一条工作流写成 capabilities × providers。本文拆 `matrix.py` 里 8 种 provider kind 为什么只有 2 种归 `matrix install` 管、capability 的「覆盖」怎么算，以及矩阵 skill 渲染的四级查找链。
meta-skill：给 agent 用的那层元技能
CLI-Anything 仓库里有一份不描述任何软件的 SKILL.md，只有 115 行，写给 agent 看的是「先 preflight 再装」和「别为一个能力整装一个 14-CLI 矩阵」。本文拆这份元技能的动作序列与退出码约定，并核对它第 85 行那句自我描述与 `installer.py` 的差异。
插件形态：装进 Claude Code 是怎么装的
CLI-Anything 的 Claude Code 插件目录 26 个文件 5865 行。本文拆清单，说清装进去不会多出一个能跑的工具，并落到四处对不上：`plugin.json` 缺 version、`verify-plugin.sh` 和 setup 脚本漏掉 `list.md`、HARNESS.md 位置两说。
其余宿主适配层各自对接谁
CLI-Anything 仓库根下并排着六个以 agent 宿主命名的适配目录，看着像同一件事的六份移植。本文逐个落到安装脚本的具体行，说清它们「装上」的含义分成复制快照、复制自身、只注册路径、上下文注入四类，以及为什么真正被移植的是路径而不是能力。
skills 目录与生成体系
SKILL.md 的 frontmatter 字段全集、description 怎么写才会被触发、skill 与 harness 是不是一一对应，以及一个新 skill 从生成到校验的流程。还有一篇专门查副本一致性——同一份 SKILL.md 在仓库里往往不止一份。
`skills/` 目录清单与每个包的文件构成：70 个目录、70 个文件
CLI-Anything 的 skills/ 下有 70 个子目录，每个目录里恰好只有一个 SKILL.md，没有 scripts、没有 references、没有随包分发的脚本文件。本文数清这一层的目录清单与文件构成，说明这份「技能包」拿到手里等于什么，以及安装口径的两处不同写法。
SKILL.md frontmatter 字段全集：哪些必填
CLI-Anything 的 `skills/` 下 70 份 SKILL.md 共出现 17 个 frontmatter key，只有 `name` 与 `description` 是 70/70。本文给出字段全集与出现次数，说清「必填」由模板、生成指南与覆盖率三处约定，以及为什么没有任何脚本校验字段集合。
description 决定它会不会被触发：CLI-Anything 里 70 份 SKILL.md 的写法规律
解析 CLI-Anything 仓库（快照 39634a6）skills/ 下 70 份 SKILL.md 的 description 字段，看长度分布、开头三词频次、折叠标量比例，讲清只有 2/70 写成触发条件这处反差与生成器留下的截断痕迹，并给出想改这个字段该改哪一份文件的判定动作与可自行复现的核查清单。
skill 与 harness 是不是一一对应
CLI-Anything 仓库里 harness 目录 69 个、`skills/` 下的 `cli-anything-*` 包也是 69 个，看起来正好一一对应。本文把这两个 69 拆开：一个 harness 没有任何 SKILL.md，另一个 harness 出了两份 skill 包，两处偏差恰好抵消。
生成、同步与校验：一个新 skill 是怎么来的
CLI-Anything 里的 SKILL.md 不是手写的，而是从 harness 目录生成、再同步到仓库根、最后由 CI 单向校验的一条流水线。本文拆开这三段各自的脚本、行号与判定规则，并说清最反直觉的那处：同步脚本自己制造了两份副本的差异，而校验只查一个方向。
副本一致性：同一份 SKILL.md 在仓库里有几份
CLI-Anything 里一个 harness 的 SKILL.md 会同时落在仓库根 `skills/` 和包内两处，全仓 150 份。本文数清这 150 份的分布，说清 68 对副本里 43 对「字节不同」其实一个字都没差，以及真正有内容的差异藏在同步脚本扫不到的两份孤儿里。
代表应用：同一套协议接不同软件
3D、直播、绘画、地理信息、文献、笔记、出图工作流、剪辑、CAD——这些软件的操控方式差别极大，接法自然不同。这一组挑差异最大的几个逐个看它们的模块划分与驱动方式，最后用一张对照表说清：驱动方式基本决定了一个 harness 能做多少。
12 个 harness 对照表：驱动方式决定了它能做多少
把 CLI-Anything 里 12 个代表 harness 的驱动方式、模块数、命令数、测试数摆到一张表上比。真正决定一个 harness 能做多少的是它怎么碰宿主软件：obsidian 只有 14 条命令而 freecad 有 276 条，差距不在作者用不用心，而在宿主给不给接口面。
blender harness：3D 场景是怎么被命令行捏出来的
CLI-Anything 的 blender harness 把 3D 场景做成一份 JSON 工程，再翻译成 bpy 脚本交给 blender 无头执行。本文落到源码行号上讲清这条链路，并把最容易理解反的一处讲透：`render execute` 这条命令其实不启动 Blender，只生成脚本并把命令行还给你。
comfyui harness：工作流软件的 harness 长什么样
CLI-Anything 的 comfyui harness 是我们精读的 12 个代表应用里非测试代码最少的一个，只有 1293 行：没有本地工程状态、不引用共享 REPL 皮肤、全靠 HTTP 打给一台已经在跑的实例。最反直觉的是，工作流软件的 harness 里，工作流那一组反而最小。
kdenlive 与 freecad：剪辑与 CAD 的两种接法
同样是把桌面软件包成命令行，kdenlive 走的是「JSON 转 MLT XML 再交给 melt」，freecad 走的是「生成 Python 宏交给 FreeCADCmd 跑」。按源码行号拆两条链路的差别，落到最反直觉的一处：命令面接近 8 倍的 freecad，测试函数反而比 kdenlive 少 72 个。
krita / gimp / inkscape：三个画图工具的 harness 怎么分工
CLI-Anything 给 Krita、GIMP、Inkscape 各套了一层命令行，三者同属画图却走了三条路。本文按驱动方式、命令面、状态模型与测试口径逐项落到具体文件行，说清一个反直觉的结论：命令最少的那个反而最离不开你本机装的宿主软件。
obs-studio harness：一个不启动 OBS 的直播场景操控面
CLI-Anything 里的 obs-studio harness 有一处和同仓其它 harness 都不一样：它的非测试代码里一处 subprocess、一处 HTTP 请求都没有，只读写场景集合 JSON。本文拆它的命令面、内置枚举、NaN 护栏与状态模型，并给出你可以自己复现的核对命令。
QGIS harness：地理信息这类专业软件怎么接
CLI-Anything 的 QGIS harness 是我们读过的 12 个代表应用里，唯一把宿主运行时直接 import 进自己 Python 进程的。本文落到 `utils/qgis_backend.py` 的具体行号，说清这条双通道怎么把前置条件从「装没装 QGIS」挪到「你用哪个解释器跑」。
zotero 与 obsidian：文献和笔记这两条线
CLI-Anything 里的 zotero 与 obsidian 常被归在同一类，但代码规模差三倍多，驱动宿主的方式几乎相反。本文落到具体文件与行号，讲清 zotero 的三通道与 experimental 写入护栏、obsidian 为什么读本地 vault 也要先走一次 HTTPS。
想让 Agent 真正接管一条完整工作流，而不只是回答问题？
从数字员工到 Agent 工程落地，站内有成体系的教程与课程。