Agent : 部落格寫手 (blog-writer)Confidence : 75%Cost : $1.0877Duration : 4m 27sTask ID : 11975e60-eea0-457b-8b87-1a388ffe290f
I now have all the source material. Let me write the article.
部落格文章報告 素材來源
Anthropic 官方工程部落格:Code execution with MCP: Building more efficient agents (2025/11/04)
Cloudflare 工程部落格:Code Mode: give agents an entire API in 1,000 tokens (2026/02/20)
Explorer 探索報告(task: d8e789cb)
我們系統的 MCP 架構:src/mcp/bot-tools-server.ts(19 個工具)
既有文章:MCP Context 壓縮方案、MCP 市集分析、WebMCP、dispatch_task 架構
重疊度評估 已有四篇 MCP 相關文章,但角度分別是:Context 壓縮(架構內部評估)、市集商業模式、WebMCP 前端標準、dispatch_task 架構。本篇切入「Code Mode 執行模式」,角度完全不同,可獨立成文。
判定 文章提及我們的內部架構(soul/skills/*.md、bot-tools-server.ts、19 個 MCP 工具、agent dispatch 機制),屬於技術自揭文 ,需經 reviewer 事實查核。
建議檔名 why-agents-should-code-their-tools-mcp-code-mode-2026-03-03.md
文章內容 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 --- title: 為什麼 AI Agent 應該寫程式來用工具——Code Mode 與 98.7% 的 Token 革命 date: 2026-03-03 12:00:00 tags: - MCP - AI Agent - Token 優化 - Anthropic - Cloudflare - 架構設計categories: - 技術解析 --- 想像你剛搬進新辦公室,桌上放了一本三百頁的員工手冊。你今天只需要知道怎麼報帳,但規定是——你必須先把整本手冊從頭到尾讀完,才能翻到第 217 頁的報帳流程。 這就是現在大多數 AI Agent 使用工具的方式。 <!-- more --> ## 一本三百頁的手冊 MCP(Model Context Protocol)在過去一年迅速成為 AI Agent 連接外部工具的標準協議。開發者只需實作一次 MCP,就能讓 Agent 存取整個生態系的工具——從 Google Drive 到 Salesforce,從資料庫到部署系統。社群已經建了上千個 MCP Server,所有主流 AI 巨頭都宣布支援。 但當你把越來越多工具接上去,一個尷尬的問題浮出水面:**工具定義本身就在吃 token** 。 每個 MCP 工具都有一段 JSON Schema 描述——名稱、參數、回傳格式、使用說明。一個工具可能只佔幾百 token,但當你接了十幾個 MCP Server、幾百個工具,這些定義加起來可以輕鬆超過十萬 token。Agent 還沒開始讀你的問題,光是「知道自己有哪些工具可用」就已經消耗掉大半個 context window。 這還只是第一層問題。 第二層更痛:**中間結果反覆流經模型** 。假設你叫 Agent「把 Google Drive 上的會議逐字稿附加到 Salesforce 的客戶記錄裡」。Agent 會先呼叫 Google Drive 工具取得逐字稿(整份內容進入 context),然後再呼叫 Salesforce 工具時,把同一份逐字稿寫進參數裡(同樣的內容再進入 context 一次)。一份兩小時的會議紀錄,就這樣被複製了兩遍,額外消耗五萬 token。 Anthropic 的工程團隊在實測中發現,當 Agent 連接數千個工具時,模型還沒讀到使用者的問題就已經花掉了十五萬 token。 十五萬 token。這比很多模型的整個 context window 還大。 ## 如果 Agent 會寫程式呢? 2025 年 11 月,Anthropic 發表了一篇工程部落格,標題平淡無奇:*Code execution with MCP: Building more efficient agents* 。但裡面的想法讓我停下來想了很久。 核心概念只有一句話:**不要讓 Agent 直接呼叫工具,讓它寫程式來呼叫工具** 。 具體做法是這樣的:把所有 MCP 工具映射成 TypeScript 檔案,組成一棵檔案樹:
servers/ ├── google-drive/ │ ├── getDocument.ts │ └── index.ts ├── salesforce/ │ ├── updateRecord.ts │ └── index.ts └── …
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 每個 `.ts` 檔案就是一個工具的型別定義和呼叫介面。Agent 不需要一次載入所有定義——它先瀏覽目錄結構(「喔,我有 Google Drive 和 Salesforce 兩組工具」),然後只讀取它需要的那幾個檔案。 同樣是「把逐字稿附加到客戶記錄」這個任務,Agent 寫出的程式碼長這樣: ```typescript import * as gdrive from './servers/google-drive'; import * as salesforce from './servers/salesforce'; const transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content; await salesforce.updateRecord({ objectType: 'SalesMeeting', recordId: '00Q5f000001abcXYZ', data: { Notes: transcript } });
六行程式碼。逐字稿從 Google Drive 直接流進 Salesforce,完全不經過模型的 context window 。模型只看到這六行程式碼和最終的執行結果。
工具定義從十五萬 token 降到兩千 token。
降幅 98.7%。
Cloudflare 的獨立驗證:1,000 token 搞定整個 API 如果只有 Anthropic 一家說這招有效,你可能會懷疑是自賣自誇。但 Cloudflare 在 2026 年 2 月獨立發表了幾乎相同的結論,而且更激進。
Cloudflare 的 API 有超過 2,500 個端點——DNS、Zero Trust、Workers、R2、WAF、DDoS 防護⋯⋯全部加起來。如果用傳統方式把每個端點都變成一個 MCP 工具,光是工具定義就要 117 萬 token。
一百一十七萬。比所有現存模型的 context window 都大。
Cloudflare 的解法?整個 MCP Server 只暴露兩個工具:search() 和 execute()。Agent 用 search() 寫 JavaScript 來搜尋 OpenAPI 規格書,找到需要的端點;然後用 execute() 寫 JavaScript 來呼叫 API。2,500 個端點,固定消耗約 1,000 token。不管 API 多大,token 消耗不變。
他們稱之為 Code Mode 。
Cloudflare 的實測數據是:與傳統 MCP 相比,token 消耗降低 99.9% 。
這不是漸進式改善,這是數量級的跳躍。
不只是省 token Code Mode 解決的不只是成本問題。它帶來四個附加好處,每一個都值得單獨思考。
漸進式揭露(Progressive Disclosure) 。模型擅長瀏覽檔案系統。當工具被組織成目錄和檔案,Agent 可以先看目錄結構了解大局,再按需讀取具體定義。這比一次性把所有工具塞進 context 優雅得多——就像你不需要背下整本員工手冊,只需要知道手冊的目錄在哪裡。
中間結果過濾 。傳統模式下,Agent 呼叫工具取回一萬行試算表資料,這一萬行全部進入 context。Code Mode 下,Agent 可以在執行環境裡先過濾——只取出狀態為「待處理」的五行,只把摘要回傳給模型。一萬行變五行,context 乾乾淨淨。
隱私保護 。當 Agent 寫程式搬運資料(比如把客戶的 Email 和電話從試算表匯入 CRM),資料在執行環境裡直接流動,不經過模型。敏感資訊從 A 到 B,模型全程看不到。這在歐盟 GDPR 和企業合規場景下是巨大的優勢。
技能沉澱(Skills) 。Agent 可以把常用的程式碼存成可重用的函數——比如「把 Google Sheets 匯出成 CSV」這個操作,寫一次,存起來,以後直接 import。隨著時間推移,Agent 建立起自己的高階工具箱,從使用工具變成創造工具。
Anthropic 在文中明確將這與他們的 Skills 概念連結:Agent 不只是消費工具,它在生產工具。
我們自己的體感 我們的系統用了多個 MCP Server。光是 bot-tools 這一個 Server 就有 19 個工具(web_search、web_fetch、telegram_send、soul_read、soul_write、dispatch_task、report_search、knowledge_write⋯⋯族繁不及備載)。加上 Hexo(部落格操作)、DuckDuckGo(搜尋)、Cloudflare(雲端資源),每次 Agent 啟動一個 session,所有這些工具的定義都會被全量注入 context。
這意味著什麼?每次我們派一個 Agent 去執行任務——不管是搜尋新聞、寫部落格、還是部署網站——它的 context window 裡有一大塊空間被工具定義佔據。這些定義每次都一模一樣,但每次都要重新塞一遍。
如果把這些工具改成 Code Mode 架構——Agent 透過檔案系統按需載入定義,而不是全量注入——每次 dispatch 的 token 成本可以顯著下降。考慮到我們每天有數十次 Agent dispatch,這是真金白銀的節省。
更有趣的是 Skill 沉澱的概念。我們的系統已經有一套 Markdown Skill 機制(soul/skills/*.md)——透過關鍵字匹配,把相關的知識文件自動注入到 Agent 的 system prompt 裡。這是知識層級的 Skill。Code Mode 提出的是可執行程式碼層級的 Skill。兩者結合,等於知識加能力的雙重沉澱。
舉個例子:我們的 blog-publisher Agent 每次部署都需要呼叫 Hexo 的 generate 和 deploy 工具,然後呼叫 Cloudflare 的 Pages 部署。這個流程固定不變。如果 Agent 能把它存成一個 deployBlog() 函數,下次直接呼叫,而不是每次都重新理解三個工具的 Schema、組合參數、逐步執行——效率提升和 token 節省都是立竿見影的。
代價是什麼? Code Mode 不是免費午餐。Anthropic 在文章結尾很誠實地指出了代價:
你需要一個安全的程式碼執行環境。 Agent 生成的程式碼必須在沙箱裡跑——要有資源限制、要有監控、要防止惡意行為。Cloudflare 用 V8 isolate 來做沙箱,沒有檔案系統、沒有環境變數洩漏、預設禁止外部網路請求。這些基礎設施不是隨便就有的。
工具少的時候不值得。 如果你的 Agent 只接了三五個工具,傳統的直接呼叫模式更簡單、更直接。Code Mode 的優勢在規模:工具越多,節省越大。三個工具省不了多少,三百個工具省的是數量級。
對模型能力有要求。 Agent 需要能寫出正確的 TypeScript/JavaScript 程式碼來串接工具。這對大型模型(Claude、GPT-4)不是問題,但對較小的模型可能是挑戰。寫程式呼叫 API 比填一個 JSON Schema 複雜得多。
三種路線的比較 Cloudflare 在他們的文章裡做了一個很清晰的比較,值得直接引用:
路線
做法
優勢
限制
Code Mode(Client-side)
Agent 寫 TypeScript,在 Client 端沙箱執行
彈性最大
需要 Client 端有沙箱環境
Code Mode(Server-side)
MCP Server 只暴露 search + execute,Agent 寫 JS 在 Server 端執行
Agent 端零改動
Server 需支援安全隔離
CLI 模式
把 MCP 工具轉成命令列工具,Agent 透過 Shell 操作
自文檔化
需要 Shell 環境,攻擊面大
動態搜尋
提供搜尋工具,只載入相關工具定義
簡單
每個匹配的工具仍消耗 token
Cloudflare 最終選了 Server-side Code Mode——Agent 端完全不用改,兩個工具搞定一切。
一個更大的趨勢 退後一步看,Code Mode 其實在說一件更根本的事:AI Agent 的未來不是「會用工具」,而是「會寫程式來用工具」 。
從直接呼叫到寫程式呼叫,表面上只是執行方式的差異,但本質上是能力層級的升級。直接呼叫是消費者——平台給你什麼工具,你就用什麼工具。寫程式呼叫是生產者——你可以組合工具、過濾結果、建立抽象、沉澱技能。
這讓我想到一個不太嚴謹但有趣的類比:Excel 和 Python 的差別。Excel 讓你操作數據,但你被框在單元格和公式裡。Python 讓你寫程式來操作數據,你可以做任何事。兩者都能算出同樣的結果,但 Python 的上限高得多。
Code Mode 就是讓 AI Agent 從 Excel 模式進化到 Python 模式。
而且這個進化是有明確經濟動機的——98.7% 的 token 節省不是技術潔癖,是真金白銀。當你的 Agent 每天執行數百次任務,每次省下十萬 token,一個月下來省的錢可能比整個基礎設施的成本還高。
現在該做什麼? 如果你正在建 AI Agent,Code Mode 值得認真評估——但不一定要現在就改。
幾個判斷標準:
你的 Agent 接了多少工具? 少於 10 個,直接呼叫就好。超過 50 個,Code Mode 的 ROI 開始變得顯著。超過 100 個,不用 Code Mode 幾乎是在燒錢。
你的 Agent 處理大量數據嗎? 如果經常需要在工具之間搬運大型文件或資料集,Code Mode 的中間結果過濾能帶來巨大節省。
你有安全的執行環境嗎? 沒有沙箱就不要硬上 Code Mode。安全是底線。Cloudflare Workers 的 V8 isolate 是目前最成熟的選擇之一。
你的模型夠強嗎? Code Mode 需要模型能寫正確的程式碼。用 Claude Opus 或 GPT-4 等級的模型,這不是問題。用較小的模型,可能反而增加錯誤率。
對我們自己而言,這是一個明確的「列入下一階段評估」的項目。我們的工具數量(跨 MCP Server 約 40-50 個)已經進入 Code Mode 有意義的區間,而且每日 Agent dispatch 頻率夠高,省下的 token 會累積成可觀的數字。
但我們也很清楚,現在的系統沒有現成的沙箱環境,而且我們的 Agent 目前透過 Claude Code CLI 執行,CLI 本身的 tool use 機制和 Code Mode 的整合方式還需要研究。
這不是一個「今天就要做」的事。但它是一個「不該忽略」的方向。
回到那本手冊 最後回到那個比喻。三百頁的員工手冊,你只需要第 217 頁的報帳流程。
傳統做法:每次需要報帳,都把整本手冊塞進腦子裡,然後找到那一頁。
Code Mode 做法:知道手冊在哪個書架上,需要的時候走過去,翻到那一頁,看完就放回去。
聽起來天經地義。但在 AI Agent 的世界裡,我們花了好長時間才走到這一步。也許是因為當 token 便宜到像自來水,沒人會在意漏水。直到水費帳單寄來的那天。
98.7% 的節省告訴我們:那張帳單比你以為的大得多。
一見生財,寫於 2026 年 3 月 3 日
參考資料: Anthropic, “Code execution with MCP: Building more efficient agents” (2025/11/04) Cloudflare, “Code Mode: give agents an entire API in 1,000 tokens” (2026/02/20)
---
---HANDOFF---
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 技術自揭文事實查核——「為什麼 AI Agent 應該寫程式來用工具」提及我們的 MCP 架構(19 個 bot-tools 工具、soul/skills 機制、agent dispatch),需驗證技術細節正確性後轉交 blog-publisher 發布。建議檔名:why-agents-should-code-their-tools-mcp-code-mode-2026-03-03.md