停止让工具流经LLM：2026年代码模式转型

从 Tool-Calling 到 Code Mode：让 Agent 写一个脚本，而不是把五十个工具调用逐个念给 LLM —— 上下文 token 下降约 99%。

太长不看： 经典 Agent 循环把每个工具定义都加载进上下文窗口，并把每个中间结果通过模型回传。只要接上几十个工具，用户还没开口，上下文就满了。2026 年的方向 —— Code Mode —— 是让 Agent 写一个简短的脚本直接调用工具，批量数据留在沙箱里，只有最终答案返回。一个极小的可运行演示把上下文从 36,781 个 token 砍到 222 个 —— 减少 99.4%。同样的结果，无需 API key。

心智模型：不是让一个员工大声朗读 50 份手册的每一页和电子表格的每一行，而是把工作需要的 3 份手册交给他，让他们在自己的桌子上做计算。你只收回最终答案 —— 而不是原始数据。

问题：tool-calling 随工具数量增加无法 scale

Function/tool-calling 是目前大多数 Agent 的行动方式。用五个工具时效果绝佳。但整个工具面（tool surface）在每次请求时都会被序列化进上下文窗口，模型请求的每个中间结果也会通过上下文回传。

所以一个类似"统计每个套餐层级的未解决工单数量并保存报告"的任务看起来是这样的：

1. 把所有 50 个已连接工具的 schema 加载进上下文
2. 调用 list_tickets → 2,000 行数据通过模型返回
3. 调用 get_customers → 400 行数据通过模型返回
4. 模型在脑中合并并计算这些数据块

模型为 50 个它大部分不需要的 schema 付了费，也为 2,400 行它只需要聚合而不需要读取的原始数据付了费。Anthropic 测量了一个真实的 Google Drive → Salesforce 任务，token 用量达 150,000 个；Cloudflare 在 2,500 个端点的 API 上达到了约 117 万个 token 的工具定义用量。

模式：写代码来调用工具

Code Mode（Anthropic 的"Code execution with MCP"、Cloudflare 的"Code Mode"）翻转了这个循环：

• 工具变成代码 API —— 一个类型化函数的文件系统，每个工具一个函数
• 渐进式披露（Progressive disclosure）—— Agent 只读取任务需要的少数签名
• 模型输出一个脚本，而不是一串工具调用
• 沙箱运行它。中间数据存在于沙箱中；只有最终结果返回

以下是这个"模型"在演示中写的完整脚本 —— 2,000 张工单和 400 个客户在沙箱内部完成连接，从不接触上下文：

tickets = list_tickets("open")            # 2000 rows: fetched and joined entirely in the sandbox
plan = {c["id"]: c["plan"] for c in get_customers()}
counts = {t: 0 for t in ("free", "pro", "enterprise")}
for tk in tickets:
    counts[plan[tk["customer_id"]]] += 1
rows = [{"tier": t, "open_tickets": counts[t]} for t in counts]
result = save_report("open_by_tier", rows)

沙箱只暴露工具 API —— 没有内置函数，没有导入 —— 所以脚本可以组合工具，但无法触及进程的其余部分：

api = {"list_tickets": list_tickets, "get_customers": get_customers, "save_report": save_report}
sandbox = {"__builtins__": {}, **api}
exec(script, sandbox)      # only the script text + final answer ever cross the context window

Code Mode — write code that calls tools, don't stream tools through the model

  Task: count open tickets per plan tier over 2000 tickets / 400 customers.
  Tools connected to the agent: 50 (this task needs 3).

   classic tool-calling    36,781 context tokens   (all schemas + raw data pass through)
   code mode                  222 context tokens   (3 signatures + one script + answer)
   ------------------------------------------------
   context reduction        99.4%

  Same result either way: [free: 720, pro: 596, enterprise: 684]

差距不是常数 —— 随工具数量和数据规模复合增长。

现实检验：精确数字来自上面的简单模型 —— 把它当作方向性参考而非基准。形态是真实的，并在生产环境中被测量过：Anthropic 的 Drive→Salesforce 任务从约 150k token 降到约 2k token，独立复现在 78% 到 99.9% 之间，取决于工具数量和数据规模。

为什么这是 2026 年的方向

已验证的部分：LLM 非常擅长写代码，而代码 API 是表达"做这五件事并组合结果"的一种密度高得多的方式，相比五次独立的 tool-call 往返。Anthropic、Cloudflare 和一项关于 MCP 设计选择的独立研究都汇聚到同一个发现 —— token 用量在工具数量上变得大致恒定，因为模型只读取它打开的东西。

走向：随着 Agent 连接到数百个 MCP 服务器，"预先加载所有内容"变得根本不可行，tool-calling 层将转移到计算机上。预计沙箱 —— 而不是 tool-calling —— 将成为默认的动作原语（action primitive），工具 schema 同步到文件系统并按需披露。

这个演示有多忠实？

这是一个极简模型，不是基准："token"是 chars/4 的代理，"模型"写一个固定脚本，沙箱是一个受限的 exec。真实系统用 LLM 生成脚本并更激进地隔离它（gVisor、容器、V8 isolates）—— 这是该模式的主要成本：你现在要运行不受信任的、模型生成的代码，所以沙箱化和限制是强制的。不过 token 经济学的数字完全符合生产报告。

python3 demo.py   # standard library only

来源与延伸阅读

Wang et al. — From Tool Orchestration to Code Execution: A Study of MCP Design Choices (arXiv 2602.15945) — benchmarks the "context-decoupled execution model" and shows token use becomes roughly constant in tool count.

Anthropic — Code execution with MCP: building more efficient AI agents (the 150k → 2k token result)

Cloudflare — Code Mode: the better way to use MCP and give agents an entire API in 1,000 tokens (typed API from MCP schemas, executed in a V8 isolate)

Code Execution With MCP: Cut Tool Tokens up to 98% (independent reproductions across tool counts)