跳到主要内容

代码执行 vs 工具编排

让模型写代码在沙箱串调工具，可节省最高 98.7% token，适合数据量大、控制流确定的场景

核心要点：

  • 工具编排让中间结果全过上下文，费 token、累延迟
  • 代码执行让模型写代码在沙箱串调，只回最终结果
  • 实测 token 节省最高 98.7%
  • subagent-as-tool：子 agent 当工具，隔离上下文
  • 边界：数据量大、控制流确定用代码执行

本文讲一种改变工具调用方式的方案。它建立在 03-MCP-协议 之上，沙箱安全细节见 07-安全与沙箱。

逐个调工具有什么问题？​

核心问题：让 agent 一个接一个调工具完成任务，瓶颈在哪？

标准工具编排把所有中间结果写回上下文，数据量大时迅速耗尽配额，且每次调用都需一轮模型推理[1]。三个成本叠加：

  • 中间结果污染上下文：A 工具的大输出要进上下文才能喂给 B 工具，即便模型并不需要看它。
  • 延迟线性累积：每个工具调用是一次模型往返，串调 N 个工具就是 N 轮。
  • schema 常驻：所有工具定义要预先注入(见 04-工具发现与延迟加载)。

这解释了为什么大数据量的多工具工作流在直接调用下既慢又贵。

代码执行怎么解决？​

核心问题：能不能让模型写一段代码，把串调逻辑一次跑完？

让模型生成代码在沙箱执行，用代码完成循环/过滤/组合调用，只把最终结果返回上下文[1]。Anthropic 的方案是把 MCP 工具暴露为代码 API（如 TypeScript 文件），agent 按需读取并生成调用代码。

效果由一组实测数据印证：同一个 Google Drive → Salesforce 工作流，直接工具调用耗 150,000 token，代码执行仅 2,000 token，节省 98.7%[1]。社区实测进一步显示，数据量大时代码执行在成功率上明显优于直接调用（社区讨论数据，样本有限，未给可复核的精确数字）。

关键机制是中间数据不过模型：代码在沙箱里处理几千条记录，模型只看到最终的少量结果。

subagent-as-tool 是什么？​

核心问题：如果子任务本身需要多轮推理，代码执行不够用怎么办？

把子 agent 当作工具调用——子 agent 在独立上下文里完成任务，只回传结论[2]。当子任务需要 agent 级推理（而非确定性代码）时，这是代码执行之外的隔离手段。

价值在于上下文隔离：子 agent 的所有中间工具调用都不污染父 agent 的上下文，且多个子 agent 可并行。这与多 agent 编排相关，但角度不同——这里只把它当"一个会推理的工具"用，编排拓扑见 04-编排与工作流。

什么时候用代码执行，什么时候直接调工具？​

核心问题：代码执行这么省，是不是该全用它？

不是——代码执行适合控制流确定、数据量大、敏感数据不该过模型的场景；单次调用或模型需要理解工具响应内容时，直接调用更合适[1]。

场景选择
控制流确定、数据量大代码执行
敏感数据不该进模型上下文代码执行
单次工具调用直接调用
模型需要读懂工具返回再决策直接调用
动态 MCP server、带引导指令的返回直接调用

@tbl-agent-tool-code-vs-direct 代码执行与直接工具调用的场景选择：按控制流确定性、数据量、敏感性、是否需要模型读懂返回值判断

代码执行的主要代价是安全：它引入了一批新攻击面（一项 MCP 设计研究识别出 16 类）[3]，必须配沙箱(见 07-安全与沙箱)。可借鉴的判断：数据多、流程定，就让模型写代码；一锤子买卖或要看懂返回，就直接调。

Takeaway​

知识点核心结论
工具编排问题中间结果过上下文、延迟线性累积、schema 常驻
代码执行模型写代码沙箱串调，只回最终结果，token 省最高 98.7%
中间数据不过模型沙箱处理大数据，模型只看少量结果
subagent-as-tool子 agent 当工具，隔离上下文 + 并行
适用边界数据大/流程定→代码；单次/要读返回→直接调；代码执行需沙箱

参考资料​

  1. Anthropic. Code execution with MCP: Building more efficient agents. 2025. https://www.anthropic.com/engineering/code-execution-with-mcp
  2. Claude Agent SDK. Subagents in the SDK. 2025. https://code.claude.com/docs/en/agent-sdk/subagents
  3. From Tool Orchestration to Code Execution: A Study of MCP Design Choices. arXiv:2602.15945, 2026. https://arxiv.org/abs/2602.15945

延伸阅读​