基于代码执行的智能体工具调用：从工具调用到代码编排的范式演进

一、它是什么

基于代码执行的智能体工具调用（Code Execution with Tool Servers）是一种新型的智能体工具调用范式：模型不再以“逐次发起工具调用”的方式与外部系统交互，而是将外部工具服务器暴露的接口视为可编程的代码 API，通过在受控执行环境中编写并运行代码来完成任务编排。

在这种范式下，工具的定义不再被全量注入模型上下文，而是以类似“模块/库”的形式存在于执行环境中。模型只需按需引用、读取或检索相关接口定义，然后编写代码调用它们。工具返回的中间数据也主要在执行环境内部流转，而不是全部回灌到模型上下文中。

从技术视角看，它把“模型决定调用哪个工具”的问题，转化为“模型编写代码来编排工具”的问题；从工程视角看，它把智能体从“对话式调度器”升级为“可执行程序的作者”。

二、为什么它会出现：传统工具调用的三个结构性瓶颈

要理解这一范式的价值，需要先看清传统工具调用流程的固有代价。典型的工具调用循环如下：

1. 将所有可用工具的定义（名称、描述、参数结构）全部放入模型上下文；
2. 模型阅读全部定义，决定调用哪个工具、传什么参数；
3. 工具执行，结果被写入上下文；
4. 模型阅读结果，决定下一步；
5. 循环往复，直到任务结束。

这个流程在工具数量少、返回数据小时尚可接受，但一旦接入真实业务系统，就会暴露三个瓶颈：

瓶颈一：上下文空间被工具定义挤占。
当智能体接入多个工具服务器、每个服务器包含数十个工具时，仅工具定义就可能占用数十万 token。这意味着大量上下文预算被“静态说明”消耗，真正用于推理和任务内容的空间被严重压缩。

瓶颈二：中间数据在模型上下文中反复搬运。
假设一个任务需要把某文档的完整内容写入某业务系统的记录字段。传统流程中，文档内容先作为工具返回结果进入上下文，模型再将其作为参数写出，同一份数据在上下文中出现两次。若内容为五万 token，一个简单任务就可能消耗十万级 token，并需要模型两次生成。

瓶颈三：控制流只能用自然语言表达。
“请循环处理每一条记录”“如果失败就重试”这类要求，在传统范式中只能写成提示词。模型需要把自然语言意图“翻译”成一系列离散的工具调用，既容易出错，也难以表达分支、循环、异常处理等复杂逻辑。

三、核心思路：把工具服务器变成代码 API

新范式的核心转变可以用一句话概括：工具不再是被“调用”的对象，而是被“编程”的对象。

在传统范式中，模型看到的是工具定义列表，输出的是工具调用指令。在新范式中，模型看到的是可导入的代码模块，输出的是可执行代码。一个示意性结构如下：

// 按需导入外部系统对应的代码模块
import * as docSystem from './servers/document-service';
import * as bizSystem from './servers/business-record-service';
// 以代码方式编排任务
const doc = await docSystem.getDocument({ documentId: 'abc123' });
await bizSystem.updateRecord({
  objectType: 'MeetingNote',
  recordId: 'REC-001',
  data: { Notes: doc.content }
});

这段代码与直接调用工具在语义上等价，但执行路径完全不同：

• 工具定义按需从文件系统或接口目录中读取，而非全量注入上下文；
• 文档内容在执行环境内部从一次调用传递到下一次调用，不经过模型上下文；
• 循环、条件、重试、并发等控制流由编程语言原生表达。

四、关键对比：两种范式的差异

维度	传统工具调用	基于代码执行的调用
工具暴露方式	全部定义注入上下文	按需从文件系统或接口目录读取
中间数据流转	全部经过模型上下文	主要在执行环境内部传递
控制流表达	自然语言提示词	完整编程结构（变量、循环、异常）
上下文开销	随工具数量与数据量线性增长	与任务逻辑相关，而非与数据量强相关
复杂任务编排	多轮往返，易出错	单次代码生成，可测试、可复用
可审计性	调用日志分散	代码本身即执行记录

这一对比揭示了新范式的本质：它把“上下文问题”转化为“工程问题”。工具定义的管理、数据的传递、控制流的表达，都从模型上下文中解放出来，交由代码执行环境承担。

五、工作原理：三个层次的解耦

基于代码执行的工具调用之所以可行，依赖于三个层次的解耦。

第一层：接口定义与模型上下文解耦。
工具服务器不再把全部接口定义推送给模型，而是将其组织为可检索、可按需读取的结构。模型在需要时获取相关接口说明，避免静态占用上下文。

第二层：数据流转与模型上下文解耦。
工具执行结果默认留在执行环境中，由代码直接消费。只有当任务确实需要模型“看到”某段内容时，才将其引入上下文。这从根本上削减了重复搬运。

第三层：控制流与自然语言解耦。
循环、分支、异常处理、并发调度等逻辑由编程语言表达，模型负责生成逻辑正确的代码，执行环境负责稳定运行。这使得智能体能够处理真正复杂的多步骤任务。

六、典型适用场景

这一范式并非适用于所有场景，但在以下情形中优势明显：

• 跨系统数据搬运与转换：如把文档内容写入业务记录、把日志字段同步到分析表；
• 批量与循环处理：如对一组记录逐条校验、更新、重试；
• 多工具编排任务：需要按条件选择不同工具、组合多个返回结果的流程；
• 数据量较大的中间结果处理：中间数据不需要模型理解，只需被正确传递；
• 需要可测试、可复现的智能体流程：代码天然具备版本化与测试能力。

相反，如果任务只是单次、简单、无需复杂编排的工具调用，传统方式可能更直接。

七、相关概念区别

与传统工具调用的区别：前者是“模型直接指挥工具”，后者是“模型编写指挥工具的程序”。

与工作流引擎的区别：工作流引擎通常由人预先定义流程，而基于代码执行的智能体由模型动态生成执行逻辑，具备更强的适应性。

与函数调用能力的区别：函数调用是模型输出结构化的调用指令，仍属于传统范式；基于代码执行的调用则把执行主体从模型转移到执行环境。

八、使用注意事项

• 执行环境隔离：代码执行必须运行在受控沙箱中，限制文件、网络与系统资源访问；
• 权限与凭证管理：工具接口的鉴权信息不应直接暴露在模型生成的代码中，需由执行环境统一注入；
• 错误处理与可观测性：需记录代码执行日志、调用链路与异常信息，便于审计与排障；
• 接口定义的稳定性：工具接口的命名与结构应保持稳定，避免模型生成的代码频繁失效；
• 成本与延迟权衡：虽然上下文开销降低，但代码生成与执行本身也有成本，需结合任务规模评估。

九、总结

基于代码执行的智能体工具调用，是对传统工具调用范式的一次结构性升级。它把工具从“上下文中的定义”变成“执行环境中的 API”，把中间数据从“上下文搬运”变成“环境内流转”，把控制流从“自然语言描述”变成“编程结构表达”。其核心价值不在于让模型更聪明，而在于让智能体的工程结构更合理：上下文更省、编排更强、流程更可测。

理解这一范式的关键，是认识到它解决的不是“模型能力”问题，而是“智能体架构”问题。当工具数量增长、任务复杂度提升、数据规模扩大时，这种架构优势会愈发明显。对于正在构建智能体系统的开发者而言，它提供了一条值得关注的工程路径。