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

Full translation

完整中文译文

从 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）在每次请求时都会被序列化进上下文窗口，模型请求的每个中间结果也会通过上下文回传。

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

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

模型为 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)