大模型编程能力跃迁：从工具调用到代码执行

近期，大模型在编程任务上的表现差异引发了广泛讨论：同样是面向代码生成与工程任务，为何有的模型能流畅完成多步骤、跨系统的复杂操作，而另一些模型在稍长的任务链上就频频“失速”？表面看是模型能力之争，深入看则是智能体与外部系统交互的范式之争。本文从工程视角拆解这一差异的技术根源，重点分析“工具调用”范式的结构性瓶颈，以及“代码执行”范式为何能显著提升智能体的效率与可靠性。

一、问题起点：智能体如何连接外部系统

当前主流的智能体架构中，模型与外部系统的连接普遍依赖标准化的工具协议。这类协议的价值在于解耦：任何人都可以基于统一协议开发工具服务器，让模型以一致的方式连接到文档存储、CRM、数据库、邮件系统等各类外部资源。生态因此得以快速扩张，工具数量呈爆炸式增长。

但生态繁荣的背后，一个容易被忽视的成本正在累积：大部分智能体仍采用“全量工具定义注入上下文”的方式。也就是说，每次推理前，系统会把所有可用工具的名称、描述、参数结构一股脑塞进上下文窗口，模型读完这一大堆定义后决定调用哪个工具，工具返回结果再塞回上下文，模型读取结果，决定下一步——如此循环往复。

单看这个流程就能判断：这是一个 token 黑洞。

二、量化瓶颈：一个简单任务为何消耗十万级 token

假设智能体连接了两个典型的工具服务器：一个文档存储服务（含数十个工具），一个客户关系管理服务（含数十个工具）。仅工具定义本身，就可能占据数万乃至数十万 token 的上下文空间。这意味着在模型真正开始“干活”之前，上下文窗口已被大量静态描述占用。

再看一个具体任务：“把文档存储中的会议记录下载下来，写入客户关系管理系统中的销售线索”。

在传统工具调用范式下，流程如下：

1. 模型调用文档读取工具，返回一份两小时会议的完整文字记录，假设约 5 万 token；
2. 这 5 万 token 被加载进模型上下文；
3. 模型再把这 5 万 token 的内容，逐字写入客户关系管理工具的更新参数中；
4. 这又是一次约 5 万 token 的生成。

一个逻辑上并不复杂的任务，消耗 10 万+ token，且需要模型两次完整生成。更关键的是，中间数据全程穿过模型上下文——模型既要“读”一遍，又要“写”一遍，token 成本翻倍，延迟翻倍，出错概率也随生成长度上升。

三、范式转变：把工具服务器变成代码 API

新的思路非常直接：不让模型直接调用工具，而是让模型写代码去调用工具。

工具服务器不再以“工具定义列表”的形式暴露给模型，而是以“代码库”的形式暴露：每个服务器对应一个可导入的模块，模型通过编写代码完成任务。

// 导入工具服务器对应的代码库
import * as docstore from './servers/document-store';
import * as crm from './servers/crm';
// 用代码完成任务
const transcript = (await docstore.getDocument({
  documentId: 'abc123'
})).content;
await crm.updateRecord({
  objectType: 'SalesMeeting',
  recordId: '00Q5f000001abcXYZ',
  data: { Notes: transcript }
});

这段代码的关键在于：会议记录这 5 万 token 的内容，从未进入模型上下文。它从文档服务的返回结果，直接在执行环境中流向了客户关系管理服务的入参。模型只需要生成这段简短的调用代码，而不需要“阅读”并“复述”中间数据。

四、两种范式的结构性对比

维度	工具调用范式	代码执行范式
工具暴露方式	全部定义塞进上下文	按需从文件系统读取
中间数据流转	全走模型上下文	只在执行环境内部传递
控制流表达	自然语言提示（“请循环处理……”）	完整编程结构（变量、循环、异常处理）
token 成本	随数据量线性膨胀	与数据量基本解耦
可靠性	长文本生成易漂移	逻辑由代码保证

这张表揭示了差异的本质：工具调用范式把“数据搬运”和“逻辑控制”都压在了模型的自然语言生成能力上；代码执行范式则把这两件事交还给执行环境，模型只负责“写对代码”。

五、为什么这一转变对编程能力影响巨大

第一，上下文窗口的稀缺性被释放。工具定义和中间数据不再挤占上下文，模型可以把有限的窗口用于真正需要推理的内容，例如任务规划、错误诊断、代码结构设计。上下文越干净，长任务链上的稳定性越高。

第二，控制流从“提示”变成“代码”。自然语言描述循环、条件分支、异常重试，本身就存在歧义，模型需要在生成时“脑补”执行语义。而代码中的 for、if、try/catch 是确定的，执行环境负责解释，模型不必在生成阶段模拟执行过程。

第三，中间结果不再经过“生成”这一关。传统范式下，中间数据要进入模型上下文再由模型写出，任何长文本的复述都可能引入截断、遗漏或格式偏差。代码执行范式下，数据在执行环境内部传递，保真度由运行时保证。

第四，工具生态的扩展不再线性推高成本。工具调用范式下，接入的工具越多，上下文压力越大；代码执行范式下，工具以模块形式按需引入，未使用的工具不产生上下文开销，生态扩展的成本曲线明显更平缓。

六、工程落地的关键设计点

要让代码执行范式真正可用，工程上需要关注几个环节：

• 执行环境隔离：代码在受控沙箱中运行，限制文件系统、网络与资源占用，确保安全边界清晰。
• 模块接口标准化：工具服务器以稳定的模块签名暴露，参数结构、返回类型、错误码需要明确约定，便于模型生成正确调用。
• 按需加载机制：模块清单与接口文档存放在文件系统中，模型按任务需要读取，而非一次性注入。
• 错误可观测：执行环境的异常需要以结构化形式回传，模型据此修正代码，形成“生成—执行—修正”的闭环。
• 结果裁剪策略：对超长返回结果提供摘要或分页接口，避免单次返回过大导致后续处理困难。

七、结语

大模型编程能力的差距，很多时候并非单纯“模型聪明与否”的差距，而是交互范式是否与任务复杂度匹配的差距。工具调用范式在工具数量有限、数据量较小的场景下依然简单有效；但当智能体需要跨多个系统、处理长文本、执行多步控制流时，代码执行范式在 token 效率、数据保真与控制精度上的优势就会显现。

理解这一范式转变，对开发者与企业的实际意义在于：构建智能体系统时，不应只关注模型选型，更应关注工具如何暴露、数据如何流转、控制流如何表达。这三件事的设计质量，往往比模型参数规模更能决定系统在真实任务中的表现。