使用 MCP 進行程式碼執行：打造更高效的 AI Agent

Anthropic 提出了一種改變 AI Agent 與 Model Context Protocol (MCP) 互動方式的方案，從直接的工具呼叫轉向程式碼執行。透過將 MCP 伺服器呈現為程式碼 API，Agent 可以僅載入必要的工具定義，並在執行環境中處理數據，從而顯著降低 Token 開銷與延遲。

減少 MCP Agent 的 Token 消耗

隨著 AI Agent 擴展到需要使用跨多個 MCP 伺服器的數百或數千個工具時，Token 使用方面會出現兩個主要的低效問題：

1. 工具定義過載

標準的 MCP 客戶端通常會預先將所有工具定義載入到模型的上下文窗口（context window）中。當 Agent 連接到數千個工具時，模型在開始處理使用者請求之前，必須先處理數萬個 Token，這增加了成本與回應時間。

2. 中間結果膨脹

在傳統的工具呼叫迴圈中，每個中間結果都必須經過模型的上下文。例如，如果 Agent 從 Google Drive 下載一份大型會議記錄並上傳到 Salesforce，該會議記錄的全文會在第一次呼叫時載入到上下文窗口中，然後在第二次呼叫時再次寫回上下文。對於大型文件，這可能會消耗數萬個 Token，並可能超出上下文窗口限制，導致工作流失敗或數據複製錯誤。

使用 MCP 實作程式碼執行

Agent 可以透過編寫程式碼來與 MCP 伺服器互動，而非直接進行工具呼叫。其中一種實作方式是生成一個檔案系統樹，其中每個 MCP 伺服器及其相關工具都表示為檔案（例如 ./servers/google-drive/getDocument.ts）。

在此架構中，Agent 透過探索檔案系統來發現工具——列出目錄以尋找伺服器，並讀取特定檔案以了解工具介面。這種「漸進式揭露」（progressive disclosure）方法允許 Agent 僅載入特定任務所需的定義。Anthropic 指出，這可以將 Token 使用量從 150,000 個 Token 減少到 2,000 個 Token，代表在時間與成本上節省了 98.7%。

程式碼執行方法的關鍵優點

上下文高效的數據處理

程式碼執行允許 Agent 在將結果返回給模型之前，先在執行環境中對數據進行過濾、轉換與聚合。例如，與其將一個包含 10,000 列的試算表載入到上下文窗口中進行手動過濾，Agent 可以編寫一個腳本來過濾「待處理」（pending）的訂單，並僅記錄前五列以供審查，從而大幅減少處理的 Token 數量。

進階控制流

透過使用標準的程式設計結構（如迴圈、條件判斷與錯誤處理），Agent 可以在單一步驟中執行複雜的邏輯。這比透過 Agent 迴圈串聯個別的工具呼叫更有效率。此外，在環境中執行條件樹（conditional trees）可以減少「首個 Token 生成時間」（time to first token）的延遲，因為模型不需要依序評估每一個 if 語句。

隱私與安全性

預設情況下，中間結果會保留在執行環境中，這意味著不需要讓模型看到的敏感數據永遠不會進入上下文窗口。此外，MCP 客戶端可以配置為在數據到達模型之前自動對 PII（個人識別資訊）進行 Token 化處理，僅在數據傳遞給另一個 MCP 工具呼叫時才進行反 Token 化。這確保了敏感數據從來源端流向目的地，而模型從未處理過原始的 PII。

狀態持久化與可重複使用的技能

檔案系統存取權限使 Agent 能夠透過將中間結果寫入檔案來，在操作過程中維持狀態。Agent 還可以將其成功的實作方式作為可重複使用的函數，持久化到「skills」資料夾中。當與 SKILL.md 檔案搭配使用時，這些函數會變成結構化的技能，模型可以針對特定任務引用它們，讓 Agent 隨著時間推移，不斷演化出屬於自己的高階能力工具箱。

營運考量因素

雖然程式碼執行提供了顯著的效率提升，但它也引入了工程基礎設施的複雜性。執行 Agent 生成的程式碼需要一個具備沙箱機制（sandboxing）、資源限制與監控功能的安全執行環境，以減化安全風險。這些營運開銷必須與降低 Token 成本與降低延遲的效益進行權衡。