命令行可能是 AI Agent 最友好的互動界面

文章作者、來源：少數派

Between 2025 and 2026, top AI companies successively released a category of products: CLI-form Agent tools.

Anthropic 發布了 Claude Code，一個在終端中運行的 AI 編程助手。OpenAI 發布了 Codex CLI，Google 發布了 Gemini CLI。在這波浪潮中，幾乎每家值得關注的 AI 公司都押注了命令行。

這很反直覺。命令行是 1970 年代的產物，GUI 的出現讓電腦走入大眾，現在移動互聯網讓觸控操作成為默認。按照通常的邏輯，技術的方向應該是越來越「可視化」、越來越「易用」。為什麼在 AI 時代，最古老的交互形式反而捲土重來？

答案不是情懷，是工程邏輯。

GUI 對 AI 並不友好

GUI 是為人類視覺導航設計的。按鈕、彈窗、拖拽、懸停效果——這些交互範式建立在人類的視覺直覺上。人類看一眼介面，掃描按鈕位置，憑直覺判斷下一步操作。這套機制對人類來說極其自然，幾乎不需要學習成本。

但 LLM 的運作方式根本不是這樣。LLM 的輸入是 token，輸出也是 token。它的「思考」發生在語言空間中，而不是在像素空間中。

讓 AI 操控 GUI，意味著要跨越一道巨大的鴻溝：

成本極高。AI 需要依賴電腦視覺或 Accessibility Tree 才能「理解」介面——哪個按鈕可點、哪個輸入框在哪裡、當前彈窗是什麼意思。這不是 AI 的強項，反而是額外負擔。

狀態是隱含且不可預測的。同一個按鈕，今天可以點擊，明天可能因某個條件而變灰。這種隱含狀態對人類來說是「上下文」，對 AI 則是不確定性——它無法可靠地推斷「此操作在什麼條件下可用」。

操作無法組合。無法將兩個 GUI 操作通過管道連接起來。「搜索結果 → 過濾 → 導出」在 GUI 中是三次點擊，無法作為一個整體進行傳遞、重用或自動化。

難以測試和驗證。AI 執行了一個 GUI 操作，如何確認它成功了？需要截圖、解析介面狀態，整個回饋迴路又慢又脆弱。

Compared to that, each feature of the CLI seems specifically designed for AI.

CLI 對 AI Agent 的三大優勢：可組合性

Unix 哲學的核心是：「每個程式只做一件事，並把它做好；讓程式能夠協同工作」。

This design principle from decades ago has taken on new meaning in the AI era.

CLI 工具透過標準輸入輸出串聯。linkly search "React 性能優化" | head -5 可將搜尋結果傳給下一個命令。linkly search "架構設計" --json | jq '.results[].doc_id' 可提取所有文件 ID 用於後續處理。

對於 AI Agent 而言，可組合性意味著可以將多個命令鏈接成複雜的多步驟工作流，每一步的輸出都是結構化的文本，可供下一步消費。無需 GUI 的「點擊 → 等待 → 截圖 → 解析」循環，僅有乾淨的輸入與輸出。

可預測性

每個命令的行為完全由參數決定。linkly search "資料庫" --limit 10 今天執行是這個結果，明天執行（假設資料庫沒變）還是這個結果。沒有隱式狀態，沒有「這個功能上次為何有效現在又無效」的困惑。

這對 AI 至關重要。AI 在推理一個工具時，需要建立一個心智模型：這個工具的輸入是什麼，輸出是什麼，有什麼副作用。GUI 的隱式狀態使這個心智模型充滿不確定性。CLI 的顯式參數讓這個心智模型可靠而精確。

linkly read 42 --offset 80 --limit 100——這個命令的含義完全由參數決定。AI 可以精確推論它的行為，不需要猜測任何隱式上下文。

可審計性

所有 CLI 操作都是可記錄的文本序列。AI 執行了什麼命令、得到了什麼輸出，都是人類可讀的文本。

這種透明性有兩個好處。

對於 AI 自身：可以進行自我檢查。「上一步 linkly search「合同模板」返回了 0 個結果，說明關鍵詞不對，換成合同範本再試。」這種基於文本的自我糾錯是 AI Agent 能夠可靠運作的基礎。

對於人類：可以進行事後審查。你可以查看 AI 執行了哪些命令、每一步的輸入和輸出是什麼，整個推理鏈路一目了然。GUI 操作的「點了什麼」很難追溯，CLI 操作的日誌天然就是審計記錄。

Linkly AI CLI 的設計實踐

LinklyAI 是我們自行開發的本地搜尋引擎和知識庫建立軟體。在設計 Linkly AI 的 CLI 工具時，我們一開始就將 AI Agent 視為主要使用者之一。

Linkly AI CLI 的核心命令只有四個：

這四個命令完全符合 Unix 哲學：每個只做一件事，具有明確的輸入輸出契約。AI Agent 可以將它們任意組合為複雜的檢索流程。

一個典型的 Agent 工作流程如下：

每一步的輸出都是結構化文本，可以直接被 AI 消費和推理。沒有任何 GUI 操作，沒有任何視覺解析的負擔。

CLI 的另一個優勢是可以與系統中的其他命令自由組合，帶來超越單個工具能力邊界的新功能。

過濾和提取：--json 輸出可直接接 jq 提取欄位，結果再傳給下一個工具：

• # 搜尋文件，僅取 doc_id 列表，再批量獲取大綱
• linkly 搜尋 "資料庫設計" --json | jq -r '.results[].doc_id' | xargs -I{} linkly outline {}

與 grep 組合進行二次過濾：先用語義搜索縮小範圍，再用精確關鍵詞過濾：

• linkly 搜尋 "架構設計" | grep -i "微服務|分佈式"

統計與分析：配合 wc、sort、uniq 等進行文檔統計：

• 統計知識庫中有多少篇 PDF
• linkly search "" --json | jq '.results[].type' | sort | uniq -c

與腳本結合：在 shell 腳本裡批量處理，自動化重複任務：

GUI 工具無法參與這些組合。CLI 工具的輸出是文字流，天然可被任何其他工具消費，這讓整個系統的能力遠大於各個工具的簡單相加。

CLI 和 MCP 並不是對立的。linkly mcp 一條命令可以把 CLI 變成一個 stdio MCP 伺服器，供任何支援 MCP 的 AI 客戶端使用：

Json：

這比直接配置 HTTP MCP 伺服器簡單得多——用戶無需知道埠號，無需手寫 JSON 中的 URL，只需告訴 AI 客戶端「執行這個命令」。

CLI 已成為 MCP 生態的入場券，對用戶幾乎零配置摩擦。

更宏觀的趨勢

Claude Code 選擇優先發布 CLI 形態而非 IDE 插件，這個決定背後有清晰的工程邏輯：IDE 插件受限於宿主環境，CLI 工具可以在任何有終端的地方運行，可以被任何 Agent 調用，可以和任何其他工具組合。

這揭示了一個更根本的規律：AI Agent 調用工具的本質，就是在執行命令。工具調用（function call / tool use）從語義上就是 CLI——給定名稱和參數，返回結果。CLI 工具天然就是 Agent 可以調用的函數，不需要任何轉換層。

「Terminal as the new IDE」這個說法早在 AI 興起之前就有人提出，但在 AI 時代它獲得了全新的含義。不只是「在終端裡寫代碼」，而是「Agent 透過終端與世界互動」。

過去，CLI 是技術人員的專屬工具。未來，CLI 可能會成為 Agent 的通用語言——人類透過自然語言與 Agent 對話，Agent 則透過 CLI 與系統互動。

小結

GUI 的地位不會受到太大影響，它仍然是人類直接操作電腦的最佳介面。但當你的 AI 工具需要調用另一個工具時，CLI 是最自然的橋樑，會有更多軟體為了順應 Agent 的習慣推出更多 CLI 工具。

想在終端中搜尋你的文檔？看看這兩篇文章：不離開終端，讓 AI 搜尋你的文檔 和 一行命令，讓 30+ AI 工具讀取本地文件。