AI Agent 很會讀文件、寫程式、拆任務，但一碰到真實軟體就常常卡住：GUI 操作不穩、API 覆蓋不完整、截圖點擊又容易碎。HKUDS 的 CLI-Anything 把問題反過來問：如果明天的使用者是 Agent，那今天這些為人類設計的軟體，是不是應該先長出一個 Agent 讀得懂、跑得穩、能測試的命令列介面？
這不是「再寫一個 CLI」，而是讓軟體變成 Agent 原生
CLI-Anything 的標語是「Making ALL Software Agent-Native」。它不是只想替某個工具包一層 wrapper，而是提供一套流程：分析目標軟體的 codebase，設計命令群組與狀態模型，實作 Python Click CLI，補上 REPL、JSON 輸出、undo/redo、測試、文件，最後讓 Agent 可以用標準命令列去操作真正的軟體。
這點跟一般「用 AI 點 GUI」的方向很不一樣。GUI agent 的路線是讓模型看畫面、移滑鼠、點按鈕；CLI-Anything 的路線是把軟體的可操作面整理成命令列。對 Agent 來說，CLI 有幾個天然優勢：可以用 --help 發現能力、可以串管線、可以輸出 JSON、可以被測試，也比較不會因為 UI 改版就整段流程壞掉。
「Agent 工具化工廠」
CLI-Anything 的 7 階段流程大致是：分析、設計、實作、測試規劃、測試撰寫、文件、發布。官方文件裡把它描述成從 codebase analysis 到 PyPI publishing 的自動流程；中文文件也提到它會產生可安裝到 PATH 的 CLI，並讓 OpenClaw、Codex、Claude Code、OpenCode 等工具透過自然語言或 skill 來驅動。
| 問題 | CLI-Anything 的解法 | 對 Agent 的價值 |
|---|---|---|
| GUI 操作脆弱 | 用 CLI 取代截圖、座標點擊和 RPA 式流程 | 流程更可重播，也更容易 debug |
| API 太零散 | 把 API 或 SDK 包成有狀態的命令群組 | 少塞文件進 context，靠 --help 和 JSON 輸出工作 |
| 工具能力不可驗證 | 要求 unit test、E2E test、subprocess CLI test | Agent 做出來的 artifact 比較接近工程品，不只是 demo |
| 不同 agent 平台不一致 | 提供 Claude Code、OpenClaw、Codex、OpenCode 等入口 | 同一套 harness 可以被多個 Agent 使用 |
CLI-Hub 是這個專案最值得追的部分
如果只看「自動幫軟體產生 CLI」，CLI-Anything 已經很有意思；但 CLI-Hub 讓它更像一個生態。官方 README 提到可以用 pip install cli-anything-hub，再用 cli-hub install <name> 來瀏覽、安裝和管理社群 CLI。CLI-Hub 網站也提供 npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill -g -y 的 skill 安裝方式，讓 Agent 先找工具，再安裝工具，再讀工具自己的 SKILL.md。
這個方向很像「給 Agent 用的套件管理器」。以前我們常常把工具文件塞進 prompt，或讓 Agent 上網找一輪；CLI-Hub 的想法是把可用工具整理成 catalog，讓 Agent 在需要的時候自己查、自己裝、自己讀用法。這對長期自動化很重要，因為工具發現與工具使用不應該每次都從零開始。
官方展示的強項：它不是玩具 wrapper
README 裡列出的 harness 很多，包含 GIMP、Blender、Inkscape、Audacity、LibreOffice、OBS Studio、Kdenlive、Shotcut、Draw.io、Ollama、ComfyUI、QGIS、LLDB、Unreal Insights 等。官方聲稱目前測試總數達 2,280+，並強調有 unit test、native E2E test、true backend E2E test、CLI subprocess test 這幾層。
這裡我會保留一點工程上的健康懷疑：repo README 的數字和中文文件中的舊數字不完全一致，代表專案更新很快，文章讀者如果要引用，最好以 GitHub README 當下版本為準。但整體方向是清楚的：CLI-Anything 想把「Agent 可以控制專業軟體」這件事，從 brittle demo 推向可測試、可安裝、可重複的 harness。
三個限制?
- 需要 source code 或可分析材料：如果目標軟體只有封閉二進位，CLI 生成品質會受限。
- 需要強模型：官方自己也提到，可靠的 harness 生成需要 frontier-class model。小模型很容易生成一個看似完整、實際缺邊缺角的 CLI。
- 需要持續驗證：CLI 只是介面，真正難的是讓命令行為、狀態、輸出和真實軟體一致。沒有 E2E 測試，很容易變成另一個漂亮殼。
適合誰先試？
第一種是正在做 Agent workflow 的人，尤其是已經被 GUI automation 折磨過的人；第二種是有一堆內部工具或開源工具想交給 Agent 操作的團隊；第三種是像 OpenClaw / Codex / Claude Code 使用者，想把工具能力沉澱成 SKILL.md 和可測 CLI，而不是每次都靠長 prompt 硬撐。
對 clawhud.com 這邊來說，我會把 CLI-Anything 放在「Agent 技能與工具生態」這條線上觀察。它跟 Superpowers 這類 workflow skill 不太一樣：Superpowers 管的是 agent 怎麼做工程流程，CLI-Anything 管的是 agent 怎麼可靠地操作外部軟體。兩者其實可以互補，一個管方法，一個管工具表面。