核心概念

「MCP 好還是 CLI 好？」這個問題本身就問錯了。

2025 年 11 月，Anthropic 發布了一篇文章「Code execution with MCP」，指出這場爭論的真正問題從來不是協議本身，而是「一開始就把所有工具說明書全部載入」這個壞習慣。新的解法叫 Code Mode——讓 agent 用寫程式的方式動態呼叫工具，而不是在工作前先讀完所有工具手冊。

MCP 的問題：Token 暴食

MCP（Model Context Protocol）把所有工具的完整規格（schema）一開始就塞進 AI 的 context window。聽起來合理，但代價驚人：

工具 預載 Token 消耗
Playwright MCP server 13,700 tokens
Chrome DevTools 18,000 tokens
五個 server 同時掛載 ~55,000 tokens（尚未開始工作）
完整工作流程跑完 ~150,000 tokens

Token 是 AI 的工作記憶容量，每次對話都有上限。工具說明書佔掉太多空間，留給實際任務的空間就變少，同時直接墊高每次呼叫的費用。

CLI 的問題：無格式規範

直接給 agent 命令列工具（CLI）省了 context 空間，但沒有標準化格式。Agent 要自己猜工具的輸出結構，遇到不熟悉的 API 容易浪費多輪才對齊，多人協作或跨系統整合時更容易出錯。

轉折：Code Mode

Anthropic 的核心洞察是：問題不在 MCP 協議，而在「全量預載」這個習慣。

Code Mode 讓 agent 改用寫程式的方式呼叫工具——主動寫幾行程式碼，只 import 這次需要的工具。這個 runtime 混合兩種機制：

1. Bash 指令 系統上已裝好的工具（git、curl、grep）直接寫一行 shell 指令執行。不需要任何工具定義，也不佔 context 空間。

2. Typed module import 專有 API（Salesforce、Stripe、內部系統）用 import 方式動態載入。每個工具是一個小型 TypeScript 檔案，輸入輸出格式明確定義。Agent 只載入這次要用的那幾個，其他完全不佔空間。

一個直覺比喻：舊做法像 agent 走進房間，桌上攤滿所有工具規格書（token 全燒）。Code Mode 像 agent 走進房間，牆上貼了工具目錄，需要什麼才從櫃子裡拿。

關鍵要點

Token 節省的數量級差距

Anthropic 的範例任務：從 Google Drive 讀取會議記錄 → 更新至 Salesforce CRM。

  • 舊做法：預載兩套工具完整規格 + 文件內容經 AI 處理兩次
  • Code Mode：TypeScript import 所需函式，同樣任務只用 2,000 tokens
  • 節省幅度：98.7%

Cloudflare 的極端案例更能說明問題：他們有 2,500 個 API 端點，完整規格是 117 萬個 token。Code Mode 方案只開放兩個函式給 agent：search（搜尋需要的端點）和 execute（執行）。結果：117 萬 → 1,000 tokens。

MCP 的角色沒有消失，只是改變

Code Mode 把 MCP 和 CLI 各自的優點拆開重新組合：

  • MCP 貢獻的是 typed contracts（標準化工具格式規範）
  • CLI 貢獻的是 lazy loading（用到才載入）

兩者從「二選一方案」變成「同一個 runtime 裡的兩種零件」。同一個工作流程裡，搜索檔案用 bash，呼叫 Salesforce 用 typed import——兩三行程式碼混在一起跑。

MCP 生態仍在快速擴張

「MCP 已死」是誤讀。Anthropic 數據顯示 MCP SDK 累積下載量已突破 3 億次（2025 年初才 1 億），是目前 AI agent 基礎設施成長最快的一塊。消失的不是 MCP，是「全量預載」這個壞習慣。

2026 年 AI Agent 工程原則

一個可以記住的指導原則：工具定義放在程式碼裡，需要的時候才載入。AI 負責寫幾行程式碼呼叫它們，runtime 負責執行。

實務應用

建置 Agent 工具層時的考量

不要在 agent 啟動時掛載所有可能用到的 MCP server。應改為：

  • 常用系統工具（文件搜索、版本控制）：直接 bash 指令
  • 專有 API：建立小型 typed module，agent 按需 import
  • 如果工具數量多（如 Cloudflare 的 2,500 端點）：建立 search + execute 兩層抽象，讓 agent 先搜尋再執行

評估現有 agent 架構的診斷問題

agent 開始工作前，有多少 token 已經被工具定義佔掉了？

如果答案超過一萬 token，幾乎可以確定有優化空間。檢查哪些工具是「預防性載入」（怕可能用到）而非「確定性載入」（這個任務一定要用）。

連結相關頁面

多 Agent 系統協作架構：MCP 與 A2A 協議 說明了 MCP 作為協議層的完整設計；AI Agent 設計模式 涵蓋 agent 架構的整體框架；2026 年 Agentic AI 七大趨勢 提供了更廣的產業背景。

延伸觀點

Anthropic 工程部落格「Code execution with MCP」正式確認了文章的核心論點，並提供兩個額外維度值得注意。

隱私是 Code Mode 的隱藏優勢。直接工具呼叫的做法，所有中間結果都會進入 model context，意味著 API key、使用者資料、內部 ID 等敏感資訊全部暴露在 AI 可見的範圍。Code Mode 讓中間結果留在執行環境裡，不進 context window，本質上是一種隱私保護架構。

工具數量少比多好（Anthropic「Writing effective tools for AI agents」）。兩篇 Anthropic 文章一致指向：把多個相關操作合併成一個工具、設定回傳 token 上限（如 25,000 tokens）、只回傳高信噪比資訊——比「暴露所有 API 端點」的做法效果更好。這與 Code Mode 的懶加載哲學一致：少即是多。

MCP 工具說明書品質普遍低落（arXiv 2602.14878）。研究分析現有 MCP server，發現 97.1% 的工具描述至少包含一個「壞味道」——最常見的問題是沒說清楚工具限制、參數格式不明確、用途描述模糊。後果是 agent 需要多花 67% 的互動步驟來探索，間接放大了 token 消耗。改善工具描述可讓任務成功率提升 5.85 個百分點。這說明採用 Code Mode 之外，工具說明書本身的品質也是不容忽視的效率瓶頸。

共識結論：token 效率問題的解法不是單一的，而是三層並行——架構層（Code Mode 懶加載）、工具層（精簡工具數、限制回傳大小）、描述層（清楚的用途與參數說明）。三層都做到，才能真正把 agent 的工作記憶用在正事上。

反向連結

以下頁面引用了本頁：