26次工具调用、一个脚本、0.02美元——“代码模式”的惊人 Token 节省

问题当每次工具调用都在污染上下文

AI 代理每次调用工具——无论是获取工作流列表、检查调度还是读取 API 结果——完整的原始 JSON 响应都会进入模型的上下文窗口，并且一直留在那里。后续每次对话都会重新发送。在需要 26 次顺序调用的任务中，就有 26 个数据包在内存中累积，每个都在消耗 Token 和金钱。

这是业界数月来一直在绕圈子的问题。Anthropic 在 2025 年 11 月发表了一篇文章，展示了通过给代理一个沙盒脚本环境并生成 API，可以将 150,000 Token 的任务减少到仅 2,000——减少了 98.7%，因为原始数据根本不需要经过模型上下文。Cloudflare 在 2025 年 9 月以“代码模式”为名推出了同样的理念，后来报告称 2,500 多个 API 端点的 Token 使用量从 117 万降到了约 1,000。

但那些是供应商的基准测试。Agent Swarm 想用自己的生产数据、用自己的工作流来测——然后公开每一个数字，包括那些需要诚实脚注的。

实验Workflow Triage——一个脚本 vs 26 次顺序调用

Agent Swarm 的测试对象是 workflow-triage，一个扫描整个生产集群的脚本——所有工作流和定时任务——标记哪些已死、失败或正常。内部它做 26 次独立的 API 调用：一次 workflow_list、一次 schedule_list、每个工作流一次 workflow_listRuns（共 24 个）。

脚本路径

脚本在自己的沙盒子进程中运行，内部完成所有 26 次调用，只向代理返回一个摘要对象——25,811 个字符。原始数据从不褾碰模型宝贵的上下文窗口。墙上时间：13.12 秒。

原始顺序路径

代理手动做同样的事需要 26 次单独的工具调用。每次原始的 JSON 响应都会留在上下文中直到对话结束。Agent Swarm 通过直接调用相同的 SDK 方法测量了实际负载大小：workflow_list 返回 16,304 个字符，schedule_list 返回 72,105 个字符，在 4 个采样工作流（312 次运行）中，平均每次 workflow_listRuns 响应为 3,447 个字符。应用到所有 24 个工作流实际的 920 次运行上，仅运行数据就约 317 万字符。原始路径的预计总 Token 数约 815,000，墙上时间约 2 到 6.5 分钟。

结果99.2% 的减少——以真金白银计算

脚本自己的数据是 100% 实测的——durationMs: 13120 和 25,811 字符的输出直接来自一次实时运行。原始路径的字符数是实测后推算的：他们调用了脚本所用的完全相同的 SDK 方法，采样了最小和最大的工作流，并将实测平均值应用到集群自己记录的运行次数上。

技术代码模式与脚本工作流

Agent Swarm 的方法比这篇博文更早。集群中的每个 claude/codex/opencode 会话都带有一个规则手册——system.agent.context_mode——告诉代理：10 项以上或批量分发意味着用脚本，而不是 N 次单独的工具调用。同样的机制也驱动着他们的脚本工作流功能，整个自动化流水线作为可组合脚本在代理上下文之外运行。

核心洞察很简单：与其让代理调用 26 次工具并在上下文中填满原始 JSON，不如让代理调用一个工具——脚本执行器——而脚本在内部完成 26 次调用。模型只看到精炼后的结果。这和批处理比逐行提取更便宜是同一个原理：批量完成工作，只传输答案。

为什么重要超越一个基准

这些数字并非 Agent Swarm 独有。同样的模式适用于任何代理需要多次 API 调用的场景：跨服务获取用户数据、轮询多个端点、聚合分页列表的结果、跨集群运行健康检查。只要原始数据大于分析结果，将处理移到脚本内部就能节省上下文——从而节省资金和时间。

Anthropic 最初的 98.7%、Cloudflare 在 2,500 个端点上的 99.9%，以及现在 Agent Swarm 在生产负载上的 99.2%——这个模式是收敛的。代码模式，无论叫什么名字，正在成为高效 AI 代理的标准架构模式。