CLI 論點

一週內三個 Hacker News 討論串，合計 1,638 點。結論只有一個：IDE 是給人用的，CLI 是給代理用的。¹²³

Boris Tane 的規劃/執行分離法（716 點）完全在終端機中運作。¹「Making MCP Cheaper via CLI」分析（304 點）測量出將 MCP 工具呼叫替換為 claude --print 可減少 94% 的 token 消耗。³ Vercel 的 just-bash 專案（87 點）證明了移除代理 80% 的工具反而讓一切更快、更便宜、更可靠。⁴ 另一項基準測試發現，CLI 方法在等效任務上使用的 token 比 MCP 少 35 倍。¹⁰

這個模式不斷出現，因為架構本身就在推動它。代理需要組合性、可腳本化和最小開銷。CLI 三者兼備，IDE 一個都沒有。

摘要

CLI 優先的代理架構在 token 開銷上比基於 MCP 的方法低 94%，執行速度快 3.5 倍，並且可與標準 Unix 工具組合使用。規劃/執行分離之所以有效，是因為 CLI 產出的是可攜式 markdown 檔案，而非 IDE 狀態。Remote Control 讓 CLI 代理可被遠端監督，同時不犧牲組合性優勢。每個嚴肅的代理系統最終都會匯聚到終端機，因為終端機正是自動化原本就存在的地方。

規劃/執行分離

Boris Tane 記錄了一個三階段工作流程，454 位 HN 留言者以各自的變體驗證了它：研究、規劃、實作。¹ 關鍵觀察：在您審閱並批准書面計畫之前，絕不讓代理撰寫程式碼。

工作流程在每個階段都會產生 markdown 產出物。research.md 記錄程式碼庫分析，plan.md 記錄包含程式碼片段的實作策略。開發者在編輯器中審閱、加入行內註解，然後將帶有註解的計畫送回，並附上明確指示：「先不要實作。」註解循環會重複一到六次，然後才開始撰寫任何一行程式碼。

整個循環透過終端機中的 claude 運作。沒有 IDE 外掛，沒有視覺化差異比較工具。Markdown 檔案輸入，markdown 檔案輸出。這些產出物能在上下文視窗壓縮後倖存，因為它們以檔案形式存在，而非對話狀態。

我的自主循環在機器規模上實作了相同的分離模式。PRD 檔案定義了包含驗收標準的使用者故事。每個故事都會生成一個全新的代理，接收當前 git 狀態和先前代理完成成果的簡報。代理進行實作，獨立驗證器執行測試（絕不信任代理的自我報告），三個程式碼審查者同步評估差異。整個編排透過 bash 腳本中的 claude --print 呼叫運作。沒有框架，沒有執行環境，沒有伺服器。

規劃/執行分離在終端機中有效，因為終端機讓這種分離成為結構性的。規劃產生檔案，執行消費檔案。兩個階段之間的界線是磁碟上的檔案——可見且可稽核——而非埋藏在 IDE 外掛中的狀態轉換。

為什麼 CLI 在代理方面勝過 IDE

論點建立在三大支柱上：成本、組合性和上下文效率。

成本：94% Token 削減

Kan Yilmaz 在四種情境下測量了 MCP 與 CLI 的 token 開銷。³ 數據說明了一切：

MCP 將工具結構描述注入每個對話中。擁有 84 個工具時，僅結構描述的開銷就在代理開始工作前消耗了 15,540 個 token。CLI 呼叫不會帶來結構描述開銷，因為模型已經理解標準命令列介面。¹⁰ 一位使用者記錄了 MCP_DOCKER 在 135 個工具中消耗了 125,964 個 token。¹⁴

Jannik Reinhard 在 Intune 合規任務上進行了平行基準測試：MCP 使用 145,000 個 token，而 CLI 僅需 4,150 個 token 即可產出等效結果。¹⁰ CLI 代理有 95% 的上下文視窗可用於推理，而 MCP 代理將大部分預算花在工具定義上。

組合性：Unix 管道早已可用

Vercel 的 v0 團隊移除了其代理 80% 的工具，並以單一 bash 環境取代。⁹ 結果：

Andrew Qu 解釋了其中的邏輯：「我們在解決模型本身就能處理的問題。」¹³ 檔案系統、grep、管道和重導向本身就具備組合性。模型理解這些工具。為 cat | grep | jq 原生就能處理的操作建構自訂 MCP 工具，只會增加開銷而不增加能力。

Anthropic 自己的文件也證實了這個模式。Claude Code 遵循 Unix 哲學：將日誌導入其中、在 CI 中執行、與其他工具串聯。⁵ 無頭模式（claude -p）支援結構化 JSON 輸出、結構描述強制執行，以及透過擷取的工作階段 ID 恢復工作階段。Anthropic 將無頭模式定位為 CI/CD 和腳本化工作流程的主要整合途徑。⁵

Simon Willison 點出了其中的含義：撰寫程式碼現在很便宜。⁶ 沒人想聽到的推論是：驗證現在才是昂貴的部分。CLI 代理可與現有的驗證基礎設施組合。測試執行器、程式碼檢查器、型別檢查器、安全掃描器、部署管線——全部都是命令列工具。IDE 代理每個都需要一個外掛，CLI 代理只需要用管道連接它們。

上下文效率：在訊號而非雜訊上推理

上下文視窗是有限的。每個花在工具結構描述、對話歷史和 MCP 開銷上的 token，都是無法用於推理的 token。CLI 架構在設計上就保持上下文預算的精簡。

一個全新的 claude --print 呼叫接收的是聚焦的提示詞（約 2K token），而非繼承完整的對話上下文（約 100K+ token）。每次操作都從乾淨的狀態開始。沒有累積的狀態，沒有過時的工具定義，沒有對話漂移。

我的基礎設施在 17 個生命週期事件中執行 84 個勾點，全部透過 CLI 呼叫編排。每個代理生成時都會收到簡報：當前 git 狀態、先前代理完成成果的摘要，以及其單一任務的驗收標準。簡報取代記憶。模型執行清晰簡報的效果，遠優於在 30 步累積的上下文中摸索。

一篇關於代理系統中 Unix 哲學的學術分析將此原則形式化：將多樣化的介面摺疊為統一的抽象，接受某些專業化的損失以換取組合性和可處理性。¹¹ 類檔案抽象和基於程式碼的規格降低了認知和工程負擔。CLI 代理繼承了 50 年的設計成果。

Remote Control 改變了等式

對 CLI 優先代理最明顯的反對意見是：您會失去 IDE 的視覺回饋。Anthropic 在 2026 年 2 月 25 日推出了答案。Remote Control 可從任何瀏覽器或 Claude 行動應用程式連線到本機 Claude Code 工作階段。² 此功能在 Hacker News 上獲得 531 點和 313 則留言。

Remote Control 不會將任何東西移至雲端。代理持續在本機執行。終端機工作階段透過 TLS 向 Anthropic 的 API 註冊並輪詢工作。所有流量都透過出站 HTTPS 傳輸，不需要開放入站連接埠。²

此功能解決了監督的落差。在 Remote Control 之前，CLI 代理只有兩種模式：有人監督（坐在終端機前）或無人監督（離開並祈禱）。Remote Control 創造了第三種模式：非同步治理。核准提示會傳送到您的手機。您可以在任何地方核准、拒絕或重新導向。

我的勾點系統按影響範圍對操作進行分類。本機操作（檔案寫入、測試執行）自動核准。共享操作（git 提交）發出警告。外部操作（推送、部署）交由人工審查。Remote Control 將「延遲」路徑從阻塞等待轉變為非同步通知。代理繼續處理下一個故事，而我從手機審查上一個故事。

IDE 成為顯示層，而非執行環境。您透過 Remote Control 監控進度，在品質關卡標記問題時介入。CLI 代理執行工作，IDE 向您展示結果。

Bash 代理模式

Vercel 的 just-bash 是一個模擬的 bash 環境，具有記憶體內虛擬檔案系統，專為 AI 代理打造。⁴ 此設計體現了關於代理架構的三個信念：

隔離優於沙箱。 每次呼叫都在隔離環境中執行。環境變數、函式和工作目錄在呼叫之間重設。檔案系統則持久保存。延遲載入機制意味著檔案在首次讀取時載入並快取，絕不會載入代理在讀取前寫入的檔案。代理無法跨操作污染自己的環境。

現有工具優於自訂工具。 Grep 已有 50 年歷史，能精確處理自訂搜尋 MCP 工具所複製的功能。jq 解析 JSON，curl 擷取 URL。模型從訓練資料中已經認識這些介面。自訂工具需要結構描述注入和文件，標準工具兩者都不需要。

最小架構優於框架架構。 Andrew Qu 捕捉到了這個原則：「模型越來越聰明，上下文視窗越來越大，所以也許最佳的代理架構就是幾乎沒有架構。」¹³

我的工具框架在生產規模上驗證了這個模式。大約 15,000 行 bash 程式碼編排 Claude Code。跨 17 種事件類型的 84 個勾點。調度器、品質關卡、語意搜尋整合、自主循環。沒有 Python 執行環境，沒有框架依賴。Bash 的粗糙之處（沒有原生 JSON、沒有非同步、沒有正式的資料結構）確實存在但可以解決。jq 處理 JSON。循序處理實際上是一個優點：關卡應該按順序執行，而不是競爭。

這個模式之所以有效，是因為代理編排從根本上就是讀取 stdin、做出決策、寫入 stdout。這個描述完全符合 bash 的設計目的。任何更複雜的情況都表示是任務分解有誤，而非工具選擇有誤。

成本即架構決策

成本決策會產生複利效應。在無狀態操作中選擇 CLI 而非 MCP，每次呼叫可節省 94%。³ 以每天 100 次操作計算，僅工具定義開銷的節省就達到每月 $228。³ 這些節省釋放出更多操作的預算，進而產生更多節省。架構自己回本。

三個成本層獨立地產生複利效應：

Token 層。 系統提示詞壓縮。我在一個 CLAUDE.md 檔案和 8 個規則檔案中執行約 3,500 個 token 的系統提示詞。約束條件的效果優於解釋說明。「拒絕匹配敏感路徑的工具呼叫」與 15 行解釋為何憑證應受保護的說明做的是同樣的事。Anthropic 的最佳實務文件強調了同一點：上下文視窗的效能會隨著填充而降低。⁷ 每個浪費的 token 產生雙重成本：一次是直接的 API 費用，一次是推理品質的降低。

代理層。 全新生成優於長對話。自主執行中的每個故事都會獲得一個具有乾淨上下文視窗的新代理。Geoffrey Huntley 記錄了一個類似的模式稱為「The Ralph Loop」，在 Sonnet 上以每小時 $10.42 執行自主開發。¹² 上下文永遠不會膨脹，因為每個代理都從全新狀態開始。系統提示詞的快取命中成本低 90%（Opus 4.6 上每百萬 token $0.50 對比 $5.00），因此跨全新生成重複的系統提示詞只帶來最小的開銷。⁸

架構層。 無狀態操作用 CLI，有狀態操作用 MCP。用於一次性評估的 claude --print 呼叫不會增加連線開銷。當工具需要持久狀態或串流時，MCP 才合理。大多數代理操作都是一次性評估、分類或程式碼生成任務。CLI 以更低成本和更簡單的除錯處理所有這些任務。

上週我的自主循環中的一個具體範例：一夜之間處理了五個 PRD 故事。¹⁵ 每個故事生成一個全新代理（約 2K token 簡報）、執行實作（平均約 15K token），然後生成三個審查代理（每個約 2K token）。每個故事的總計：約 23K token。在長時間運作的 MCP 對話中，同樣的工作流程到第三個故事時，每個故事會攜帶約 100K+ token 的累積上下文。五個故事透過 CLI：總計約 115K token。五個故事透過 MCP 對話：總計約 500K+ token。成本比率隨著每個額外故事而複利增長。

MCP 仍然勝出的場景

CLI 論點並非普遍反對 MCP。在 CLI 力有未逮的特定場景中，MCP 佔優勢。

有狀態工具伺服器。 跨呼叫維持連線池的資料庫瀏覽器受益於 MCP 的持久伺服器模型。每次 CLI 呼叫都重新連線會增加延遲和認證開銷。如果工具需要在呼叫之間維持狀態，MCP 是正確的選擇。

結構化驗證。 MCP 工具結構描述強制執行輸入/輸出合約。CLI 呼叫接受任意文字。當代理必須提供符合精確結構描述的結構化輸入（API 金鑰格式、日期範圍、列舉選項）時，MCP 結構描述會在工具處理之前捕捉格式錯誤的輸入。CLI 驗證需要工具本身或包裝腳本來強制約束。

多租戶存取控制。 MCP 伺服器可以集中強制執行每位使用者的權限。CLI 工具繼承作業系統使用者的權限。在不同代理需要不同存取層級的團隊環境中，MCP 提供更細粒度的授權。

串流回應。 產生增量輸出的長時間運作操作（日誌追蹤、建置進度、資料庫匯出）透過 MCP 的串流協定效果優於阻塞至完成的 CLI 呼叫。

決策規則：如果操作是無狀態的一次性操作，使用 CLI。如果操作需要持久狀態、結構化合約或串流，使用 MCP。在我的工具框架中，大約 90% 的操作是無狀態的。需要 MCP 的 10% 確實從中受益。最佳化那 90% 能獲得最大回報。

今天就能建構的系統

三種模式，每種都能在一個下午內建構，每種都與其他模式相互增強。

模式 1：規劃/執行分離

# Plan phase: research and plan, no implementation
claude -p "Research the codebase and write research.md" \
  --allowedTools "Read,Glob,Grep,Write"

# Review: read annotations in research.md, write plan.md
claude -p "Read my annotations in research.md and write plan.md" \
  --allowedTools "Read,Write"

# Implement: follow the approved plan
claude -p "Implement the plan in plan.md" \
  --allowedTools "Read,Write,Edit,Bash"

每個階段都獲得範圍限定的工具權限。規劃代理無法編輯程式碼，實作代理無法瀏覽網頁。檔案邊界強制執行分離。--allowedTools 旗標在 CLI 層級執行強制。不需要設定檔，不需要外掛設定。每次呼叫一個旗標，精確限定為該階段所需的權限。

註解循環是與「只是更好地提示」的關鍵差異。您在編輯器中審閱計畫，劃掉不同意的部分，在邊緣加入註記。代理讀取您標註的檔案並進行修訂。計畫隨著每次迭代而改善，因為兩種不同的智慧（人類領域知識、模型程式碼生成）在同一份文件上匯聚。

模式 2：每個任務全新生成

for story in $(jq -r '.stories[].id' prd.json); do
  # Each story gets fresh context with a focused briefing
  criteria=$(jq -r ".stories[] | select(.id==\"$story\")" prd.json)
  state=$(git diff --stat HEAD~1)
  briefing="Git state: $state --- Story: $criteria"

  claude -p "Implement: $briefing" \
    --output-format json \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    | jq -r '.result'

  # Independent verification: never trust self-report
  python -m pytest -v
done

沒有累積的上下文，沒有對話漂移。每個代理都獲得乾淨的視窗和聚焦的簡報。--output-format json 旗標擷取包含工作階段 ID 的結構化輸出，如果故事需要後續工作，可實現確定性的對話恢復。

獨立驗證步驟比實作步驟更重要。代理會展現我所稱的幻影驗證：聲稱測試通過卻沒有執行。在代理的上下文視窗之外執行 pytest 可以完全消除這種失敗模式。代理無法歪曲它從未產生的結果。

模式 3：平行審查管線

diff=$(git diff HEAD~1)

# Three reviewers with independent context
claude -p "Review for bugs: $diff" --output-format json > /tmp/correctness.json &
claude -p "Review for vulnerabilities: $diff" --output-format json > /tmp/security.json &
claude -p "Review for style issues: $diff" --output-format json > /tmp/conventions.json &
wait

# Merge findings from all three
jq -s 'map(.result)' /tmp/correctness.json /tmp/security.json /tmp/conventions.json

三個代理、三個視角、零共享狀態。審查者之間的分歧恰好浮現出單一審查者遺漏的問題。& 運算子和 wait 內建指令處理平行化。沒有非同步執行環境，沒有執行緒池，沒有編排框架。Bash 工作控制完成所有工作。

這個模式的威力在於：每個審查者都能將完整的上下文視窗用於其單一關注點。一個在正確性、安全性和風格之間分散注意力的單一審查者，表現不如三個擁有專用上下文的專家。CLI 讓這種分割變得輕而易舉，因為每次呼叫都是具有獨立記憶體的獨立行程。

關鍵要點

對於建構代理系統的開發者： - 所有代理生成都從 claude -p 開始。僅在需要持久狀態時才加入 MCP。 - 按階段限定工具權限。規劃代理讀取，實作代理寫入，審查代理讀取差異。 - 在無狀態操作中選擇 CLI 而非 MCP，token 開銷預算可減少 94%。³

對於擴展自主工作流程的團隊： - 全新代理生成可防止上下文漂移並限制每次操作的 token 成本。 - Remote Control 將「無人監督」轉變為「非同步監督」，而無需改變 CLI 架構。² - Vercel 的數據證明了反直覺的結果：更少的工具意味著更高的成功率，而非更低。⁴

對於選擇代理基礎設施的架構師： - CLI 代理可與現有的 CI/CD、測試和部署工具組合，不需要整合工作。 - Unix 哲學（透過管道組合小型工具）先於且優於每個代理專用框架。¹¹ - 當您停止將代理視為聊天工具，開始將其視為基礎設施時，10% 生產力之牆就會被打破。

本文是 AI 工程系列的一部分。另請參閱：Claude Code 即基礎設施、一隻爪的解剖、自主循環，以及 10% 之牆。