循环语言模型改善组合式工具调用

TL;DR 循环语言模型通过在推理时重复计算，提升多步、依赖感知的工具调用准确性；自适应分配计算量可在保持性能的同时降低推理成本，为 agentic 系统提供新架构选择。

问题

问题背景

当前 agentic systems 正走向以 工具调用 为核心的执行范式，模型需要在开放环境中协调多个 API 完成用户目标。

现有方法局限

• 传统 非循环模型 在单轮工具调用上表现尚可，但面对 组合式工具调用（需要多步、依赖传递、中间状态维护）时，往往在一步失误后导致级联错误，缺少迭代反思与修正机制。
• 已有 循环语言模型 研究多聚焦于数学 / 逻辑推理基准，其循环计算在工具使用场景下的增益并不明确，且缺少与匹配训练配方下的对照实验。
• 固定深度的循环推理在简单任务上可能导致冗余计算，或需要手工设定深度，难以平衡成本与准确率。

为什么这个问题难 / 重要

• 组合工具使用要求模型在 跨 API 调用之间保持状态一致性，如参数传递、返回结果解析、下一步规划；每次调用都可能引入错误，且错误会沿依赖链传播。
• agentic 工作流 的可靠性直接决定产品可用性，业界对能稳定完成多步编排的模型需求强烈；但额外推理开销必须匹配任务复杂度，否则成本不可控。
• 该问题需要架构改进与推理策略协同：循环计算 + 自适应深度 是一种有前景的方向，但如何在标准 SFT 设置下验证并保持广泛适用性仍是难题。

行业类比

类似 多步骤数据分析助手：先查数据库，再根据返回结果调用绘图 API，最后生成报告——任何一步参数错误都会导致整个流程失败，模型需要具备在关键节点迭代修正的能力。

核心洞察

• 循环语言模型的增益高度依赖调用结构的组合复杂度，而非所有工具调用都能受益。与之前将循环模型应用于推理基准不同，本文严格控制 SFT 数据配方，区分 isolated API invocation 与 multi-step compositional tool use，发现循环计算主要增强跨步骤的状态维护和依赖关系追踪，对单步调用边际效益小且依赖模型。这提示实际部署中应根据任务结构选择是否启用循环深度，避免统一增加计算。
• 自适应推断深度是实现循环模型工具调用性能与计算成本平衡的关键机制。固定增加 recurrent depth 虽然单调提升多步工具调用准确率，但线性增加计算开销；adaptive inference 根据输入困难度动态决定迭代次数，在接近固定深度精度的同时大幅降低平均 FLOPs/latency。这为资源受限的 agentic 系统提供了比盲目加深更实际的工程路径，与以往仅关注 fixed-depth 或单次推理的 baseline 形成对比。
• 通过 retrofitted 与 native 循环模型在匹配 SFT 下的对比，证明架构本身而非数据增强带来 compositional tool use 提升。既有工作大多将循环机制作为模型固有结构或简单增加推理步，但较少在工具调用领域控制训练配方进行 head-to-head 比较。本文同时纳入原生循环和事后改造的循环模型，发现两者在同等 SFT 后均优于非循环基线，表明循环计算可移植到现有模型，而无需重新预训练，为工程落地提供低成本升级路径。

方法

输入与目标

给定用户指令 user query、可用工具集 tool schemas（API 文档 / function signature）以及对话历史，模型需输出一组有序的工具调用（API calls），并维护中间状态与依赖关系。

关键模块：Looped Transformer

核心是 递归计算：transformer 层的权重在循环步骤上共享。模型将输入嵌入后，重复通过同一组层进行前向计算，每次迭代产生新的 hidden state，相当于在固定参数下进行多步隐式推理。

• 原生循环模型（native looped）：如 Ouro 架构，从预训练起即采用循环层设计。
• 改造循环模型（retrofitted）：将标准预训练 LLM 的若干层绑定为循环单元，加入 recurrent 连接，再经 SFT 获得循环能力。

训练阶段，对以上变体采用 匹配的监督微调配方（同样的数据集、优化器、步数），使用 function-calling 数据（如 Hermes Function-Calling Dataset）进行 next-token prediction 训练，使循环过程学会规划中间调用、传递依赖结果。

输出与推理

推理时，模型在每步循环后经过输出头生成候选工具调用序列。设定 固定循环深度（如 2、4、8 次）或启用 自适应推理：根据 token 置信度 / 内部状态稳定性判断何时提前停止，从而在准确率与计算量之间权衡。最终输出为完整的多步工具调用流程，满足 compositional tool use 要求。

与同类方法差异

相比于标准 Transformer 在固定深度下前向计算，looped 模型通过权重共享的迭代计算实现自适应计算量，在推理时动态分配深度，更贴合多步依赖的 agentic 任务。

实验

实验设计

论文在 API-Bank、BFCL、NESTful 三个基准上评估 原生 looped 与 retrofitted looped 语言模型，对比对象为使用相同 监督微调 recipe 训练的非循环基线。推理时通过改变 recurrent depth 观察性能曲线，并设置 fixed-depth 与 adaptive 两种推断策略。

关键发现

• 循环计算对 组合式工具调用 和 依赖感知 带来一致收益；对孤立 API 调用的增益较小且依赖具体模型。
• 多步工具使用准确率随 recurrent depth 增加而上升。
• adaptive inference 能在需要时分配额外计算，计算-性能权衡优于固定深度。

与基线的对比解读

在匹配 SFT 条件下，looped 模型相对 non-looped 基线的优势主要体现在需要维护中间状态与工具间依赖的任务。这表明循环机制对 agentic 规划与执行有结构性帮助，而非单纯增加参数或数据。工程上可将 adaptive depth 作为推理时动态分配算力的开关，适合成本敏感的 agent 系统。

行业影响

落地场景

循环语言模型在需要多步、有依赖关系的工具调用 工作流中优势明显，适合集成到：

• 电商订单处理助手：查询库存 → 计算运费 → 生成支付链接，多 API 协调且依赖中间状态。
• 企业服务自动化：IT 工单系统自动诊断、调用知识库、触发修复操作。
• 金融分析与合规报告：汇总多个数据源 API，按依赖顺序生成报告。

商业价值

• 降本：自适应推理仅在复杂步骤增加迭代，避免固定深度推理的冗余计算，节省推理成本。
• 增收与体验提升：模型在组合工具调用 的准确率更高，减少因工具调用错误导致的任务失败，提升用户完成率和付费意愿。
• 通过 retrofitted 方式改造现有模型，无需重新训练大规模基座即可获得收益，降低落地成本。

与现有工作流接口

• 可直接替换现有 agent 框架中的非循环 backbone，或对现有 transformer 进行 retrofit，与标准 Supervised Fine-Tuning 流程兼容。
• 推理时支持 fixed-depth 或 adaptive inference 策略，易于集成到 vLLM、TensorRT 等推理引擎。
• 已有标准化评测集（BFCL、API-Bank、NESTful）可用于回归验证。

具体落地 use case

• 电商智能客服：用户询问“我的订单现在到哪了？”，模型需依次调用订单查询 API → 物流跟踪 API → 地址解析 API，结果相互依赖；循环模型保持中间状态，减少工具调用错误。
• 企业知识管理助手：回答 HR/IT 问题，先调用身份认证 API 获取权限，再检索知识库文档，并根据结果决定是否发起审批流程；自适应递归深度在简单问题快速响应，复杂问题多轮迭代。

局限

• 基准覆盖有限：论文在 **BFCL v3**、**NESTful** 和 **API-Bank** 三个数据集上评估，主要聚焦于 API 调用语法、多步组合和依赖追踪，但未涉及真实应用场景中的复杂状态管理、工具反馈循环、长期规划或动态工具集变化。此外，这些基准的工具 schema 相对固定，与开放域工具生态的多样性仍有差距，因此结论向任意工具调用场景的泛化需要谨慎。
• 循环计算带来额外推理开销：虽然论文通过 **自适应推理** 缓解了固定深度循环的冗余计算，但自适应门控本身需要训练或启发式设计，可能引入额外复杂度；且最优循环深度因任务和模型而异，实际部署时需要针对具体工作负载进行调参。论文未报告推理延迟、吞吐量等系统指标，无法全面评估其在实时代理系统中的可行性。
• 与显式循环代理框架的对比不足：**ReAct**、**Toolformer** 等方法通过显式思考-行动循环实现组合工具调用，而本文的循环发生在模型内部参数共享层，两者在计算图、状态维护和训练范式上有本质差异。论文未直接与这些方法在相同参数量和训练数据下进行对比，因此循环语言模型相对于已有代理范式的优势边界尚不明确；retrofitted 方法对基础模型的依赖也可能限制其普适性。