過去一年，關於 Agent 工具鏈的爭論越來越集中在一個問題上：

MCP（Model Context Protocol）是讓工具調用更簡單，還是把原本簡單的事情變複雜？

在大多數日常開發任務中，CLI 正在成為更實用的預設方案。

成本差異不是「體驗問題」，而是數量級問題

MCP 最大的現實壓力是 token 開銷。

在常見場景裡，MCP 在真正執行任務前，往往需要先載入大量工具 schema。以 GitHub MCP Server 為例，初始化就可能消耗數萬 tokens。對長任務而言，這會直接擠壓上下文預算。

社群基準測試也反覆指向同一個結論：

• MCP 單次調用成本常見是 CLI 的數倍到數十倍
• 失敗重試成本也更高（要重建連線、重新載入上下文）

這不是「慢一點」的差距，而是會放大成 API 成本、延遲與穩定性問題。

為什麼模型天然更「會用 CLI」

一個常被忽略的事實是訓練分布。

LLM 在訓練中看過海量終端文本：命令、輸出、報錯、腳本、man page。也就是說，CLI 互動模式本來就接近模型的「母語輸入」。

相對地，MCP 的 JSON-RPC 與 tool schema 是近兩年才大規模出現的新範式。模型當然能學會，但熟悉度與壓縮效率通常仍不如 CLI 這類歷史語料。

這也解釋了為什麼很多時候：

• 同樣目標，CLI 指令更短
• 輸出更適合直接持續推理
• 錯誤恢復路徑更穩定

安全與隔離：MCP 還有補課空間

MCP 不是不能做安全，而是生態還在早期。

當前常見擔憂包括：

• 工具描述投毒（Tool Poisoning）
• 服務行為漂移（Rug Pull）
• 同名工具覆蓋（Shadowing）

CLI 當然也有安全問題（注入、越權、路徑風險），但它的進程模型、權限邊界、審計鏈路已經過數十年工程實踐驗證。對生產環境而言，這種「可預期性」很重要。

這不等於 MCP 沒價值

我不認為 MCP 應該被拋棄。

更合理的定位是：

• CLI 負責執行層（本地、低延遲、高頻調用）
• MCP 負責連接層（遠端服務發現、統一認證、審計與多租戶）

也就是常說的混合架構：CLI + MCP Gateway。

在需要對接大量遠端系統、做統一權限治理與合規審計時，MCP 仍然有明顯價值；但在「讓 Agent 快速完成開發任務」這件事上，CLI-first 往往更符合當前模型能力邊界。

在今天的工程現實裡，CLI 更像 Agent 的工作母語；MCP 更適合作為連接協議，而不是唯一執行協議。