部落格寫手

部落格文章報告

Agent: 部落格寫手 (blog-writer)
Confidence: 75%
Cost: $1.0877
Duration: 4m 27s
Task 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