给 Agent 全量 API 是个坏主意：Cloudflare 的反直觉答案

把所有 API 一股脑喂给 Agent，看起来很聪明，实际上却是灾难。Cloudflare 的 Matt Carey 用一次真实的工程踩坑告诉你：上下文窗口不是瓶颈，思路才是。

“把整个 API 给 Agent”这件事，从一开始就错了

Matt Carey 一上来就戳破了一个行业幻觉：只要 Agent 足够聪明，就应该能直接使用完整 API。问题是，现实中的 API 根本不是为 Agent 准备的。Cloudflare 曾尝试把完整 API 暴露给 Agent，结果发现一个残酷事实——光 OpenAPI 规范就有 230 万个 token，而 Agent 的上下文窗口在 100 万级别就已经开始“窒息”。这不是模型不够强，而是信息组织方式彻底失败。你以为是“能力不足”，其实是“喂法错误”。

从 Tool Calling 到 MCP：标准化解决了共享，却没解决规模

行业早期靠 function calling、tool calling 玩得很开心：几个 Bash 命令、一个天气查询，看起来一切都很美好。后来工具越来越多，大家开始把工具打包、共享，MCP（Model Context Protocol）应运而生。到 2025 年前后，远程 MCP 爆发，理论上“每个人都能用同一套工具”。但问题很快显现：8 个工具还能忍，80 个就开始混乱，800 个直接炸上下文。MCP 解决了“标准”，却没解决“发现”。Agent 依然不知道该用哪个工具。

CLI、搜索、还是写代码？真正的分水岭在这里

Matt 把争论收敛成一个问题：Agent 如何渐进式发现能力？Cloudflare 内部尝试了三条路。第一是 CLI：成熟、强大，但前提是 shell 权限，这对 Agent 和安全团队都不友好。第二是工具搜索：只把相关工具加载进上下文，明显更聪明，但仍然是“选工具”的思路。第三条路最激进——不选工具了，让 Agent 直接写代码。通过 TypeScript 类型定义生成 SDK，模型对着“类型”写代码，代码本身就是最紧凑的执行计划。

代码是最小的上下文，但也是最大的安全雷区

让 Agent 生成代码，听起来优雅，实际却极度危险。运行不受信任的代码，等于主动制造漏洞：文件系统、密钥、网络，全是攻击面。Cloudflare 的解法不是“更严格的审核”，而是基础设施级的隔离——可编程沙箱、可编程护栏，甚至支持“从字符串直接执行 Worker”。在 demo 里，Agent 拿到的是整个 Cloudflare API 的只读访问，但运行环境本身被锁死。这才是 Matt 想强调的重点：未来 Agent 不是在“点工具”，而是在“写程序”。

总结

这场分享真正颠覆的，不是某个协议或产品，而是我们设计 Agent 能力的方式。API 不该被当成一堆可调用函数，而应被视为“可编程的能力边界”。短期来看，你应该重新审视：你的工具是给人用的，还是给 Agent 用的？中期来看，类型、SDK、沙箱会比 prompt 更重要。长期来看，MCP 很可能只是中间层，Agent 直接对你的服务“写代码”。如果你现在还在纠结要不要多加几个工具，可能已经慢了半拍。

关键词： AI Agent， MCP， 上下文窗口， 代码生成， API 设计

事实核查备注： 需要核查：1）Cloudflare OpenAPI 规范 token 数量约 230 万；2）Agent 上下文窗口提到的 100 万级别；3）MCP 与远程 MCP 爆发时间约为去年 4 月；4）TypeScript 类型作为 Agent 生成代码核心依据的表述；5）Worker 沙箱可从字符串执行代码的能力描述。