# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Akshay 🚀 (@akshay_pachaar) · 平台：X (Twitter) · 日期：2026-05-10

> 原始來源：https://x.com/akshay_pachaar/status/2053166970166772052

## 中文摘要

# MCP vs CLI 是個錯誤的辯論

在 2025 年的大部分時間裡，AI 工程師們一直在爭論 Agent 應該如何呼叫工具。

其中一派主張使用 MCP（Model Context Protocol），這是 Anthropic 發布的一種用於將 Agent 連接到外部服務的協定。另一派則主張跳過協定，直接給 Agent 一個 Shell 就好。

雙方都有站得住腳的論點，但也都沒抓到重點。

# 雙方各自的正確之處

懷疑論者衡量了 MCP Server 在 context 中實際產生的代價：

- Playwright MCP 會消耗 13.7K token

- Chrome DevTools MCP 會消耗 18K token

- 一個包含 5 個 Server 的設定，在開始任何工作前就會燒掉 55K token

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778373601625-iaHH5N7nNaUAAjmDTjpg.jpg)

擁護者則以多租戶（multi-tenant）應用場景進行反擊：

- CLI 在多租戶應用程式中會失效

- 沒有型別合約（typed contracts），導致 Agent 只能猜測輸出結果

- 在面對不熟悉的 API 時，Agent 會浪費大量的互動次數來解析文字

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778373601571-diaHH5NwWaAAA1MpHjpg.jpg)

如果你讀到這裡，心想「好吧，那到底誰贏了？」，這就是問錯問題了。

# 重新定義問題

2025 年 11 月 4 日，Anthropic 發布了「Code execution with MCP」，徹底改變了這場對話。

問題從來都不是協定本身，而是那種「在工作階段開始時，就將所有工具的完整描述載入到 context 中」的習慣。再加上這些工具回傳的資料，在每一步都透過模型傳遞，單一工作流程的 token 用量可能會膨脹到 150K。

解決方案是改變模型的工作方式。模型不再透過 context 來呼叫工具，而是編寫程式碼，透過 Runtime 來呼叫工具。模型只會看到它所匯入（import）的內容。

在 Anthropic 的範例中，Google Drive 的轉錄內容被更新到 Salesforce CRM。舊的做法是載入兩個工具的 Schema，並將轉錄內容兩次傳遞給模型。新的做法則是寫幾行 TypeScript，只匯入需要的東西。同樣的任務，只需要 2K token，減少了 98.7%。

Cloudflare 更進一步，他們將擁有 2,500 個端點的 API 從 1.17M token 的 Schema 縮減到 1K token，方法是只公開兩個函式：`search` 和 `execute`。Agent 撰寫程式碼來搜尋目錄，然後只執行符合條件的項目。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778373601919-iaHH5OqqkagAAOMcxjpg.jpg)

# 新模式：Code Mode

Code Mode 是一種 Runtime，Agent 在其中編寫結合了兩種原語（primitives）的程式碼。

Bash，適用於任何已經安裝二進位檔的工具，如 git、curl 或 grep。模型在訓練資料中見過這些工具，並且知道如何組合它們。需要找出所有匯入 pandas 的 Python 檔案嗎？Agent 只要寫一行：

```bash
grep -r "import pandas" --include="*.py" .
```

不需要工具定義，Shell 直接搞定。

型別化模組匯入（Typed module imports），適用於 Salesforce、Stripe 或你內部服務等專有 API。可以將這些想像成 Agent 可以按需引入的小型 TypeScript 檔案。每個檔案描述一個工具，並明確定義其輸入和輸出。Agent 只會載入它實際使用的檔案。

這第二部分才是關鍵。型別簽章（type signatures）會隨著匯入一起傳遞。Agent 為它選擇的工具獲得了嚴格的合約，而對於沒用到的工具則無需支付任何 token 代價。

實際運作起來是這樣的：

```typescript
// 這是由 Agent 撰寫的。型別只會在這些 import 行載入。
import { searchFiles } from "@tools/github";
import { sendMessage } from "@tools/slack";

const files = await searchFiles({ pattern: "*.py", path: "./src" });
const summary = files.map(f => f.path).join("\n");

await sendMessage({
  channel: "#engineering",
  text: `Found ${files.length} Python files:\n${summary}`,
});
```

這裡發生了三件以前做不到的事：

GitHub 和 Slack 的工具定義只有在 import 行時才會進入 context。Runtime 提供的其他所有工具都保持在 context 之外。

檔案列表是在程式碼中處理的，而不是傳遞給模型。模型永遠不會看到原始的路徑列表，它只會看到程式碼建立的摘要。

Agent 在實際的程式碼中組合迴圈和轉換邏輯，不需要在每一步都透過模型進行來回傳輸。

一個好理解的畫面：在舊模式中，Agent 走進一個房間，桌上擺滿了所有工具；在 Code Mode 中，Agent 走進一個房間，牆上掛著工具目錄，它只會拿起自己需要的工具。

這是在同一個 Runtime 中，結合了 MCP 的型別合約與 CLI 的延遲載入（lazy loading）。Agent 根據任務進行選擇。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778373601634-iaHH5PFRPaEAApTP3jpg.jpg)

# 總結

三種方法並列，說明了完整的故事。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778373601690-diaHH5PiCaYAALNZGjpg.jpg)

MCP 給了我們型別合約，但會預先載入所有東西；CLI 給了我們延遲存取，但沒有合約。Code Mode 汲取了 MCP 的型別合約與 CLI 的延遲載入，並將兩者放入同一個 Runtime 中。

圖表的底部是實用的結論：Code Mode 並不是要取代這兩種方法，它是一個同時使用兩者的 Runtime。對於任何在 $PATH 中有二進位檔的工具使用 Bash；對於專有 API 則使用型別化模組匯入。

Agent 針對每個任務做出決定。搜尋檔案用 bash，更新 Salesforce 用型別化匯入。同一個工作流程可以在幾行程式碼中混合使用兩者。

這也是為什麼將辯論定調為「MCP 與 CLI 之爭」會錯失重點的原因。這兩種方法都存活了下來，它們只是不再擔任 Runtime 的角色，而是成為了 Runtime 所組合的原語。

# 這意味著什麼

「MCP 已死」是這場辯論中錯誤的結論。

Anthropic 剛報告 MCP SDK 下載量已達 3 億次，高於年初的 1 億次。該協定並沒有消亡，它是目前成長最快的 Agent 基礎設施。

消亡的是「預先載入所有工具」的做法，那本來就是個壞主意。

如果你在 2026 年開發 Agent，規則很簡單：工具定義應該放在程式碼中，而不是 context 裡。模型寫幾行程式碼來呼叫它們，剩下的交給 Runtime 處理。

這才是這場辯論真正的核心所在。

---

感謝閱讀！

如果你覺得有收穫，請分享給你的社群網路。

找到我 → @akshay_pachaar✔️

獲取更多關於 LLM、AI Agents 和機器學習的見解與教學！

## 標籤

MCP, CLI, Agent, 產業趨勢, Anthropic