大廠為何仍熱衷於打造CLI ？
整理版優先睇
CLI 在 AI 智能體時代並非過時產物，而是憑藉操作系統級的可靠性與 Token 效率，成為與 MCP 協議互補的核心執行層。
- 系統可靠性：CLI 作為原生進程運行，具備進程隔離與明確的退出碼（Exit Code），比長連接的 MCP 服務器更穩定且無狀態。
- Token 效率：CLI 採用「按需獲取」模式，透過 --help 漸進式消耗 Token，相比 MCP 預加載所有 Schema 可節省高達 26-43 倍空間。
- 組合性優勢：繼承 Unix 哲學，智能體能利用管道（Pipe）串聯多個 CLI 命令，實現同步、零網絡開銷且高推理成功率的工作流。
- 協議成熟度：MCP 仍處於快速迭代期，面臨安全治理與傳輸複雜度挑戰，而 CLI 是驗證 50 年、AI 現即可靠調用的成熟接口。
- 架構分層：CLI 定位為高效執行層（面向開發者與編碼 Agent），MCP 則是標準化連接層（面向企業集成），兩者將雙軌並行。
Stripe CLI
Stripe 官方開發者工具，支持產品列表查詢、支付流程模擬，提供結構化 JSON 輸出供 Agent 調用。
Cloudflare Wrangler
Cloudflare Workers 開發的唯一完整入口，Agent 可直接透過 CLI 管理 Edge 函數。
Agentic CLI Workflow
利用管道串聯 Stripe、Git 與 Vercel 的自動化部署工作流範例。
點解大廠唔放手？CLI 的四大結構性優勢
雖然 MCP（模型上下文協議）被譽為 AI 的 USB-C，但 Stripe、Vercel 等大廠依然重金投入 CLI。這不是開倒車，而是因為 CLI 擁有協議層無法替代的硬實力。
Unix 哲學的文藝復興：管道與組合性
1973 年確立的 Unix 哲學——「只做一件事並做好它」，在 AI 時代重新發光。Agent 可以像拼積木一樣，用管道將不同工具串聯起來。
# 1. 查詢產品列表並獲取 JSON
stripe products list --limit 5 --json
# 2. 處理代碼變更並建立 PR
git diff --stat && git add -A && git commit -m "fix" && gh pr create --fill
# 3. 直接部署到生產環境
vercel deploy --prod --yes確定性編排：每條命令都有明確退出碼，Agent 可以精確處理成功或失敗分支，唔使估估下。
唔係取代，而係分層：執行層 vs 連接層
未來會是雙軌並行：CLI 負責本地、高效、零依賴的執行；MCP 則負責跨平台的標準化連接。對於 SaaS 開發者來說，提供 CLI 已經由「加分項」變成「基礎設施」。
不是開倒車——CLI在AI智能體時代擁有協議層無法替代的結構性優勢
閲讀提示｜MCP（模型上下文協議）被稱為"AI的USB-C"，旨在統一智能體與外部工具的連接方式。但Stripe、Vercel、Supabase、Cloudflare等SaaS大廠卻在同步強化自家CLI工具。這不是矛盾，是分層。本文用四個獨立視角解釋CLI為什麼在智能體時代不可替代。
• • •
一、一個值得解讀的信號
2024年11月25日，Anthropic發佈了MCP。它的目標非常明確——成為AI智能體連接外部工具和數據源的"通用適配器"，用一個標準協議替代每個AI平台為每個工具單獨寫連接器的N×M問題。
協議一出，OpenAI跟進集成、微軟的VS Code原生支持、Anthropic隨後將MCP捐給Linux基金會下的Agentic AI Foundation（AAIF）。看起來大局已定。
但同一時間線上，一批頭部SaaS公司持續在CLI工具上投入重兵。Stripe同時維護CLI和MCP服務器；Cloudflare的Wrangler CLI是Workers開發的唯一完整入口；Supabase CLI管理着從Postgres到Edge函數的全套本地棧。
需要說明的是：這些CLI工具大多早於MCP出現。它們不是"因為有了AI所以才做CLI"。真正值得關注的信號是——在MCP已經提供標準化連接的今天，這些公司並沒有弱化CLI投入，反而在持續強化。
為什麼？因為CLI擁有協議層無法替代的結構性優勢。以下從四個獨立視角拆解。
二、CLI直接運行在操作系統之上
這是CLI最容易被忽視、但最根本的優勢。
一個CLI工具就是一個操作系統原生進程。它被安裝到PATH中，像ls和grep一樣，隨時可以被調用。不需要啓動服務器進程，不需要建立WebSocket連接，不需要綁定端口，不需要維護心跳。
進程隔離：每次CLI調用都是一個獨立進程，擁有完整的生命週期——啓動、執行、退出。進程之間互不影響。上一次調用崩潰了，不會污染下一次。
退出碼：0代表成功，非0代表失敗。這是操作系統層面最古老、最可靠的成功/失敗信號，每個Shell、每個CI系統、每個AI智能體都能直接理解。
雙通道輸出：stdout承載正常輸出，stderr承載錯誤信息。智能體可以分別處理，無需自己解析混合輸出。
對比MCP：MCP服務器是一個需要持續運行的長生命週期進程。服務器崩潰，所有連接的客戶端都會失去訪問能力。在Serverless和Edge Computing環境中，維護有狀態的長連接在架構上是一個已知的難題。
對AI智能體來說，調用一個CLI工具和調用ls沒有本質區別——fork一個進程，等它結束，讀取輸出和退出碼。這是操作系統已經優化了50年的路徑，不需要額外的運行時、不需要額外的協議握手。可用性接近100%。
三、按需獲取信息，而非預加載
AI智能體運行的核心約束是上下文窗口。無論窗口號稱支持100萬還是200萬Token，在實際工程中它始終是一種稀缺資源——Token等於錢，也等於推理質量的稀釋。
當前很多MCP Host的常見集成方式是：連接到服務器後，將該服務器所有可用工具的完整Schema加載到模型的上下文窗口中。智能體還沒開始幹活，就已經消耗了Token來"閲讀說明書"。
公平地說：上下文膨脹不是MCP協議本身的缺陷，而是實現層面的問題。一個設計良好的MCP集成可以做到按需加載Schema（Lazy Loading）。但在當前生態中，大量第三方MCP服務器的實現確實存在一次性灌入過多Schema的問題，這在社區中被稱為"Context Bloat"。
CLI的信息獲取模式天然不同。智能體需要用某個工具時，執行一條--help命令，按需獲取用法說明。這是"漸進式上下文消耗"——只在需要時加載信息，用完即棄。
這個差距有多大？我們用tiktoken（OpenAI開源的Token計數庫）做了一組實測：
26–43倍
MCP預加載 vs CLI按需獲取的Token消耗差距
MCP預加載模式：一個典型MCP工具的JSON Schema（名稱+描述+參數定義）約消耗463 tokens。一個擁有30–50個工具的SaaS MCP服務器，初始化時一次性灌入約13,890–23,150 tokens——智能體還沒開始幹活。
CLI按需模式：git --help輸出約529 tokens，curl --help約218 tokens。只在需要時調用一次，用完即離開上下文窗口。
測試方法：基於MCP官方規格構造典型工具Schema樣本，CLI輸出來自本機實際運行，Token計數使用tiktoken cl100k_base編碼器（與GPT-4/Claude近似）。更關鍵的是：MCP的token tax在很多實現中是"每條消息都重複注入"的固定開銷，而CLI的--help只在需要時調用一次。
在高頻、多步驟的智能體工作流中，這種按需獲取的模式在Token成本上具有結構性優勢。
四、50年驗證的組合性
1973年，Unix哲學確立了核心原則：每個程序只做一件事；程序的輸出是另一個程序的輸入。50年後，當AI智能體需要編排多步驟工作流時，這套哲學的價值被重新發現。
管道組合：智能體可以把多個CLI命令用管道串聯，搭建出複雜工作流。這種鏈式調用是同步的、本地的、零網絡開銷的，且全程可審計。
輸出格式靈活：許多現代CLI同時支持人類可讀的文本輸出和結構化JSON輸出（如gh issue list --json、stripe products list）。智能體可以根據場景選擇最優格式。
確定性編排：每條命令有明確的退出碼，智能體可以用條件邏輯精確處理成功和失敗分支，而非依賴LLM對自然語言返回值的模糊理解。
$ 智能體逐步調用CLI、根據退出碼決策下一步
# 1. 查詢 Stripe 產品列表（結構化 JSON 輸出）
stripe products list --limit 5 --json
# 2. 查看 Git 變更、提交併創建 PR
git diff --stat && git add -A && git commit -m "fix" && gh pr create --fill
# 3. 部署到生產環境
vercel deploy --prod --yes誠實地補充：REST API也能組合——微服務架構本質上就是API的鏈式調用。CLI管道的差異化優勢在於：它發生在本地操作系統層面，是同步的、無網絡開銷的、且LLM在訓練中見過大量Shell管道模式，對這種編排方式的推理成功率更高。
每一條命令完成一件事，輸出可被下一條消費，錯誤碼明確，全程無需人工介入。CLI天生就是為自動化設計的接口，AI智能體只是最新的自動化用戶。
五、MCP仍在快速成長中
前三個視角解釋了CLI為什麼"好用"。但企業級SaaS公司持續投入CLI，還有一個現實推力——MCP本身正在經歷快速迭代期，部分基礎能力尚在完善中。
安全治理仍在追趕：MCP規格已於2025年引入基於OAuth 2.1的授權框架，但2025年4月安全研究人員仍指出生態中存在多個實際問題——提示注入風險、工具權限可被利用來竊取數據、以及"影子工具"可以靜默替換受信任工具。協議層面的安全設計正在完善，但從規格到生態的全面落地仍需要時間。
傳輸複雜度：MCP的遠程傳輸已從早期的HTTP+SSE演進為Streamable HTTP（SSE現為可選流式機制），但在分佈式雲原生環境中，會話管理、斷線重連、水平擴展等問題仍需額外的架構設計。相比之下，CLI的"fork進程-讀取輸出"模式天然無狀態。
需要強調的是：這些是快速迭代期的正常陣痛，不是致命缺陷。MCP已被Anthropic捐給Linux基金會旗下的Agentic AI Foundation，協議規格從2024年11月至今已迭代多個版本。但對SaaS公司來說，現階段的務實選擇是：提供一個AI智能體現在就能可靠使用的接口——CLI就是那個已經被驗證了50年的答案。
六、不是取代，是分層
把四個視角合在一起，結論就很清晰了：CLI的持續強化並不是要取代MCP，而是行業在智能體時代自然形成的分層架構。
CLI = 執行層
面向開發者和AI智能體的高效執行通道。直接運行在操作系統之上，進程級隔離，零基礎設施依賴。適用場景：編碼智能體、DevOps自動化、本地開發工作流。
MCP = 連接層
面向企業級多用戶產品的標準化連接協議。解決N×M集成問題，提供結構化工具發現和跨平台互操作。適用場景：多租户SaaS集成、合規審計、跨AI平台統一接口。
雙軌並行 = 務實選擇
Stripe是最好的例證——它的官方文檔同時維護着Stripe CLI和MCP服務器兩個入口，分別面向不同的用戶畫像和信任級別。這不是資源浪費，而是覆蓋兩種截然不同的使用場景。
理解了這個分層邏輯，標題的答案就水落石出了：大廠不是"還在"做CLI，而是CLI佔據了協議層到不了的位置——操作系統進程、純文本管道、零依賴執行。這些是50年積澱出來的基礎設施級優勢。
📝 總結
CLI在AI智能體時代不可替代的原因，不是一個，而是四個相互獨立的結構性優勢：直接運行在操作系統之上的可靠性、按需獲取信息的Token效率、Unix管道的確定性組合、以及50年工程驗證帶來的生態成熟度。
MCP解決的是不同層面的問題——標準化連接和工具發現。兩者服務於不同的用戶畫像、不同的信任級別、不同的部署環境。
對SaaS開發者來說，結論很明確：API之外再提供一個CLI，在智能體時代已經不再是加分項，而是基礎設施。
💬 留給你的問題
你的SaaS產品提供CLI入口了嗎？在你的智能體工作流中，CLI和MCP分別承擔了什麼角色？歡迎在評論區分享你的實戰經驗——也歡迎轉發給正在做工具鏈決策的同事。