Cloudflare 的 Code Mode：用两个工具替代 2500 个端点

AI Agent 调用外部 API 有一个很现实的矛盾：你给它的工具越多，它能做的事越多，但每多一个工具定义就多占一截 context window。对于像 Cloudflare 这样有 2500 多个 API 端点的服务来说，传统 MCP 做法 - 每个端点定义一个 tool - 要消耗大约 117 万 token。这已经超出了大多数模型的上下文窗口。

Cloudflare 刚发布的 Code Mode MCP 用了一个很巧妙的方式绕过了这个问题。

不是给每个端点建工具，而是让 Agent 写代码

Code Mode 只暴露两个工具：search() 和 execute()。整个工具定义大约占 1000 个 token - 不管背后的 API 有多大，这是一个固定开销。

search() 让 Agent 写 JavaScript 代码去查询一份 OpenAPI 规范。比如 Agent 想找 WAF 相关的端点，它不需要把完整的 2500 个端点定义都加载进来，而是写一段过滤代码，在服务端执行，只拿回匹配的十几个结果。这就是所谓的"渐进式发现" - Agent 按需探索能力，而不是一次性把整张地图摊开。

execute() 则让 Agent 写代码调用实际的 API。它可以在一次执行中串联多个请求 - 先查当前配置，再做修改，不需要每一步都回到模型那边去。

这个思路的精妙之处在于：它把"描述工具"的成本转嫁成了"写代码探索工具"的能力。对于现在的大模型来说，写 JavaScript 是强项，而对着一份 117 万 token 的工具清单做选择反而是弱项。

安全：沙箱里写代码

让 Agent 写代码并在服务端执行，第一反应是"这安全吗"。

Cloudflare 用 Dynamic Worker isolate 来跑这些代码 - 这是 V8 级别的沙箱隔离。没有文件系统访问，没有环境变量泄漏，默认禁用外部网络请求。只有通过显式的 cloudflare.request() 客户端才能发出 API 调用，而且走的是 OAuth 2.1 授权流程，Agent 只能拿到用户明确授予的权限范围内的 token。

这比另一种方案 - 在客户端跑代码（Goose 和 Anthropic 的 Claude SDK 走的这个路线）- 要安全得多。客户端沙箱的安全性取决于用户的本地环境，服务端沙箱的安全性由 Cloudflare 自己控制。

和其他方案比

在 Code Mode 之前，业界有几种处理"大 API"问题的方式，各有局限。

命令行工具方式：像 OpenClaw 和 Moltworker 通过 MCPorter 把 CLI 暴露为 MCP 工具，Agent 可以通过 --help 来渐进式发现能力。问题是需要 shell 环境，攻击面更大。

动态工具搜索：先搜索相关工具，只返回一个子集给模型。比传统方式好，但每匹配一个工具仍然要消耗 token，而且需要维护一套搜索逻辑。

客户端 Code Mode：在 Agent 端执行代码。安全性依赖客户端环境，不是所有场景都适用。

Cloudflare 的服务端 Code Mode 做到了几点：token 成本固定、不需要修改 Agent 端、内置渐进式发现、沙箱执行。最关键的是 - 当 Cloudflare 上线新产品时，同样的 search() 和 execute() 自动覆盖新端点，不用发布新版 MCP server。

一个实际的场景

假设你想用 Agent 给一个 zone 配置 DDoS 防护。传统方式下，Agent 需要预先知道所有 WAF、ruleset 相关的工具定义。Code Mode 下的流程是这样的：

Agent 先调 search() ，写一段 JavaScript 过滤 OpenAPI spec 中包含 /zones/ 和 ruleset 的路径，拿回十几个匹配的端点和它们的参数结构。然后 Agent 进一步查询某个端点的 schema，发现可用的 ruleset phase 包括 ddos_l4、ddos_l7、http_request_firewall_managed 等。

接着调 execute()，在一次执行中先拉取 zone 现有的 ruleset 配置，检查当前状态，再做相应的修改。整个过程只用了四次工具调用。

开源和未来方向

Cloudflare 把 Code Mode SDK 开源了，放在 Cloudflare Agents SDK 仓库里。如果你有一个大型 API，可以用同样的模式构建自己的 MCP server - 两个工具、服务端沙箱执行、渐进式发现。

另一个值得关注的方向是他们提到的 MCP Server Portals - 把多个 MCP server 组合在一个统一网关后面，共享认证和授权，跨服务渐进式发现。这解决的是另一个现实问题：开发者的 Agent 可能同时需要访问 Cloudflare、GitHub、数据库和内部文档，每多一个 MCP server 就多占一份 context。Portal 把这些聚合起来，token 开销不随服务数量线性增长。

这篇文章让我印象深刻的不是具体的技术实现 - V8 沙箱、OpenAPI spec 查询这些都是成熟的技术组件。真正有意思的是 Cloudflare 对问题的重新定义：不是"怎么把 2500 个工具塞进 context window"，而是"怎么让 Agent 按需发现和使用能力"。这个思路的适用范围远不止 Cloudflare 一家的 API。