該放棄 MCP 嗎？為什麼 CLI 正在成為 Agent 的預設工具層

Fri, 10 Apr 2026 21:55:12 +0800

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

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

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

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

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

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

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

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

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

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

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

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

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

當前常見擔憂包括：

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

我不認為 MCP 應該被拋棄。

更合理的定位是：

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

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

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