模型上下文協議（Model Context Protocol，簡稱MCP）是一個開放標準，用于連接AI代理與外部系統。

自2024年11月MCP發布以來，采用速度非常快：社區已經構建了數千個MCP服務器，所有主流編程語言都有可用的SDK，行業已將MCP視為連接代理與工具和數據的事實標準。

然而，隨著連接工具數量的增長，預先加載所有工具定義并通過上下文窗口傳遞中間結果，會拖慢代理速度并增加成本。

最近，Anthropic提出了MCP新范式。

如何讓代理更高效地與MCP服務器交互，如何管理更多工具的同時使用更少的token？

工具導致的過度token消耗讓代理效率降低

隨著MCP使用規模的擴大，有兩種常見模式會增加代理成本和延遲：

? 工具定義過載上下文窗口

? 中間工具結果消耗額外token

大多數MCP客戶端會預先將所有工具定義直接加載到上下文中，使用直接工具調用語法將它們暴露給模型。

這些工具定義可能包含詳細的描述、參數說明和返回類型，每個工具定義都要占用大量token空間。

工具描述占用的上下文窗口空間越多，響應時間和成本就越高。當代理連接到數千個工具時，它們需要在讀取請求之前處理數十萬個token。

更嚴重的問題是，大多數MCP客戶端允許模型直接調用MCP工具。

例如，你可能要求代理："從Google Drive下載我的會議記錄，并將其附加到Salesforce的潛在客戶記錄中。"

模型會進行這樣的調用：首先調用Google Drive獲取文檔，返回完整的會議記錄文本（可能包含數萬token），這些內容被加載到模型上下文中。然后，模型需要再次將這些完整文本寫入Salesforce更新調用的參數中，這意味著同樣的內容要流經模型兩次。

對于2小時的銷售會議記錄，這可能意味著處理額外的5萬個token。

更大的文檔甚至可能超過上下文窗口限制，導致工作流中斷。

在處理大型文檔或復雜數據結構時，模型在工具調用之間復制數據時也更容易出錯。

代碼執行讓MCP的上下文效率大幅提升

隨著代碼執行環境在代理中變得越來越普遍，一個解決方案是將MCP服務器作為代碼API呈現，而不是直接工具調用。

代理可以編寫代碼來與MCP服務器交互。這種方法解決了兩個挑戰：代理可以只加載它們需要的工具，并在執行環境中處理數據，然后再將結果傳回模型。

實現方式有多種。一種方法是從連接的MCP服務器生成所有可用工具的文件樹。每個工具對應一個TypeScript文件，例如：

? servers/google-drive/getDocument.ts - 從Google Drive讀取文檔

? servers/salesforce/updateRecord.ts - 更新Salesforce記錄

代理通過探索文件系統來發現工具：

• 列出./servers/目錄以找到可用的服務器（如google-drive和salesforce）
• 讀取它需要的特定工具文件（如getDocument.ts和updateRecord.ts）來理解每個工具的接口。

這讓代理只加載當前任務所需的定義。這種方式可以將token使用量從15萬個token減少到2000個token——時間和成本節省了98.7%。

Cloudflare也發布了類似的發現，將MCP的代碼執行稱為"代碼模式"。

核心洞察是相同的：大語言模型擅長編寫代碼，開發者應該利用這一優勢來構建能夠更高效地與MCP服務器交互的代理。

MCP代碼執行的優勢

通過按需加載工具、在數據到達模型之前進行過濾，以及在單一步驟中執行復雜邏輯，MCP的代碼執行使代理能夠更高效地使用上下文。

使用這種方法還有安全和狀態管理方面的好處。

漸進式披露：模型非常擅長導航文件系統。將工具作為文件系統中的代碼呈現，允許模型按需讀取工具定義，而不是預先全部讀取。或者，可以在服務器中添加search_tools工具來查找相關定義。

例如，在使用上述假設的Salesforce服務器時，代理搜索"salesforce"并只加載當前任務所需的工具。在search_tools工具中包含詳細級別參數，允許代理選擇所需的詳細程度（如僅名稱、名稱和描述，或包含模式的完整定義），也有助于代理節省上下文并高效查找工具。

上下文高效的工具結果：在處理大型數據集時，代理可以在返回結果之前在代碼中過濾和轉換結果。

例如，獲取一個包含1萬行的電子表格。沒有代碼執行時，所有行都會流經上下文。有了代碼執行，代理可以在執行環境中進行過濾，只看到5行而不是1萬行。類似的模式適用于聚合、跨多個數據源的連接，或提取特定字段——所有這些都不會使上下文窗口膨脹。

更強大且上下文高效的控制流：循環、條件語句和錯誤處理可以使用熟悉的代碼模式完成，而不是鏈接單個工具調用。

例如，如果你需要在Slack中等待部署通知，代理可以編寫一個while循環來輪詢消息，直到找到"部署完成"的消息。這種方法比在代理循環中交替使用MCP工具調用和sleep命令更高效。

此外，能夠編寫出條件樹并執行它，也節省了"首次token時間"延遲：不必等待模型評估if語句，代理可以讓代碼執行環境來完成這項工作。

隱私保護操作：當代理使用MCP進行代碼執行時，中間結果默認保留在執行環境中。這樣，代理只能看到你明確記錄或返回的內容，這意味著你不希望與模型共享的數據可以在工作流中流動，而永遠不會進入模型的上下文。

對于更敏感的工作負載，代理框架可以自動對敏感數據進行標記化。

例如，假設你需要從電子表格將客戶聯系信息導入Salesforce。代理編寫的代碼會處理所有行，但MCP客戶端會在數據到達模型之前攔截數據并對PII（個人身份信息）進行標記化。真實的電子郵件地址、電話號碼和姓名從Google Sheets流向Salesforce，但永遠不會通過模型。這可以防止代理意外記錄或處理敏感數據。你也可以使用它來定義確定性安全規則，選擇數據可以流向和來自哪里。

狀態持久化和技能：具有文件系統訪問權限的代碼執行允許代理在操作之間維護狀態。代理可以將中間結果寫入文件，使它們能夠恢復工作并跟蹤進度。代理還可以將自己的代碼持久化為可重用函數。一旦代理為任務開發了工作代碼，它可以保存該實現以供將來使用。

這緊密聯系到"技能"（Skills）的概念——可重用指令、腳本和資源的文件夾，用于提高模型在專門任務上的性能。

在這些保存的函數中添加SKILL.md文件會創建一個結構化技能，模型可以參考和使用。隨著時間的推移，這允許你的代理構建一個更高級能力的工具箱，演化出它最有效工作所需的腳手架。

需要注意的是，代碼執行也引入了自己的復雜性。運行代理生成的代碼需要一個安全的執行環境，具有適當的沙箱、資源限制和監控。這些基礎設施要求增加了操作開銷和安全考慮，而直接工具調用可以避免這些。

代碼執行的好處——降低token成本、減少延遲和改進工具組合——應該與這些實現成本進行權衡。

總結

MCP為代理連接到許多工具和系統提供了基礎協議。然而，一旦連接了太多服務器，工具定義和結果可能會消耗過多的token，降低代理效率。

雖然這里的許多問題感覺是新的——上下文管理、工具組合、狀態持久化。

但它們有來自軟件工程的已知解決方案。代碼執行將這些已建立的模式應用于代理，讓它們使用熟悉的編程構造來更高效地與MCP服務器交互。如果你實現了這種方法，我們鼓勵你與MCP社區分享你的發現。