Cloudflare 昨天发了一篇技术博客，提出了一个优雅到让人拍大腿的方案：用 2 个工具 + 1000 tokens，覆盖 2500+ 个 API 端点。比传统 MCP 方案节省 99.9% 的 token。
原文：Code Mode: give agents an entire API in 1,000 tokens
问题：MCP 的 context window 困境
MCP（Model Context Protocol）已经成了 AI agent 调用外部工具的标准协议。但它有一个根本矛盾：agent 需要很多工具才能干活，但每加一个工具就吃掉一块 context window。
Cloudflare API 有 2500+ 端点。如果按传统 MCP 的做法，每个端点定义成一个 tool，光是工具描述就需要 117 万 tokens——比任何模型的 context window 都大。
之前 Cloudflare 的解法是按产品拆分：DNS 一个 MCP server，Workers 一个，R2 又一个……但 2500 个端点手动维护几十个 server？不现实。
解法：让 agent 写代码而不是选工具
Code Mode 的核心思想非常简单：不要给模型一个工具列表让它挑，给它一个 SDK 让它写代码。
整个 MCP server 只暴露两个工具：
search(code)— agent 写 JavaScript 搜索 OpenAPI spec，按需发现端点execute(code)— agent 写 JavaScript 调用 API，可以链式执行多个操作
工具定义加起来约 1000 tokens，固定开销，不随 API 规模增长。
search：渐进式发现
agent 不需要一次看到所有 2500 个端点。它先搜索：
async () => {
const results = [];
for (const [path, methods] of Object.entries(spec.paths)) {
if (path.includes('/zones/') &&
path.includes('rulesets')) {
for (const [method, op] of Object.entries(methods)) {
results.push({ method: method.toUpperCase(), path, summary: op.summary });
}
}
}
return results;
}2500 个端点瞬间缩小到它需要的那几个。OpenAPI spec 从未进入 context window——agent 只是通过代码去查询它。
execute：一次调用完成多步操作
传统 MCP 下，查询 + 修改可能需要 4-5 次 tool call，每次都要来回传递上下文。Code Mode 下，agent 写一段代码一次搞定：
async () => {
const ddos = await cloudflare.request({
method: "GET",
path: `/zones/${zoneId}/rulesets/phases/ddos_l7/entrypoint`
});
const waf = await cloudflare.request({
method: "GET",
path: `/zones/${zoneId}/rulesets/phases/http_request_firewall_managed/entrypoint`
});
return { ddos: ddos.result, waf: waf.result };
}安全：V8 沙箱隔离
让 agent 写代码执行，安全怎么办？Cloudflare 用了自家的 Dynamic Worker Loader——每段代码跑在独立的 V8 isolate 里：
- 没有文件系统访问
- 没有环境变量泄露（防 prompt injection）
- 外部网络请求默认禁止，需要显式开启
- OAuth 2.1 权限控制，agent 只能用用户授权的能力
这比 CLI 方案（给 agent 一个 shell）安全得多。Shell 的攻击面是整个操作系统，V8 isolate 的攻击面只有一个沙箱。
四种 context 压缩方案的对比
文章梳理了当前业界的四种方案，这个对比很有价值：
- Client-side Code Mode — agent 在客户端写代码执行。需要客户端有沙箱环境。Anthropic 的 Programmatic Tool Calling 就是这个路线。
- CLI 方式 — 把 MCP server 转成命令行工具，agent 通过 shell 渐进发现。OpenClaw 和 MCPorter 用的就是这种。缺点：需要 shell，攻击面大。
- Dynamic tool search — 动态搜索匹配当前任务的工具子集。Claude Code 内部用的方式。缺点：搜索函数本身需要维护和评估，匹配到的工具仍然消耗 token。
- Server-side Code Mode — 就是 Cloudflare 这次发布的方案。固定 token 成本，不需要客户端改动，渐进发现内置，沙箱执行安全。
我的思考
这本质上是"编译"思想
传统 MCP 是"解释执行"——每个操作都是一次 tool call，模型一步一步走。Code Mode 是"编译执行"——模型先写一段程序，一次性批量执行。同样的逻辑，从 N 次网络往返变成了 1 次。这和数据库领域从逐行查询到批量 SQL 的演进一模一样。
对 MCP 生态的影响
如果 Code Mode 成为主流，MCP 的生态会发生结构性变化：
- 工具定义变得不重要了——不需要精心设计每个 tool 的参数和描述，只需要一个好的 SDK
- OpenAPI spec 成了一等公民——只要你有 OpenAPI spec，就能自动生成 Code Mode MCP server
- MCP server 的维护成本大幅下降——不用每加一个 API 端点就更新工具定义
局限性
Code Mode 不是银弹。它要求模型具备写正确 JavaScript 的能力。对于 Claude、GPT-4 这种前沿模型没问题，但小模型可能会在代码生成阶段就出错。另外，调试也变得更复杂——当 agent 写的代码出 bug，你需要理解它试图做什么，而不是简单地看 tool call 的参数。
呼应极简哲学
有意思的是，这和我之前写的 Pi Coding Agent 的理念高度一致——少即是多。Pi 用 4 个工具 + 1000 tokens 的 system prompt 在 benchmark 上不输复杂框架。Cloudflare 用 2 个工具 + 1000 tokens 覆盖了 2500 个 API 端点。
这不是巧合。前沿模型越来越强，不需要我们用复杂的工具定义来"教"它怎么做。给它一个最小化的接口和足够的自由度，它自己能找到最优路径。
未来方向
文章最后提到了 MCP Server Portals——多个 MCP server 聚合在一个网关后面，统一用 Code Mode 暴露。想象一下：一个 agent 同时访问 Cloudflare API + GitHub API + 数据库 + 内部文档，全都通过 2 个工具、固定 1000 tokens 完成。这才是 agent 基础设施应该的样子。