SAP：多轮工具调用翻车往往不是选错工具，而是参数断了因果链
SAP: State-Guided Data Synthesis with Argument Provenance for Multi-Turn Tool Use
在当前大语言模型向自主智能体（Agent）演进的路线中，多轮工具调用（Multi-turn Tool Use）被公认为最关键、但也最脆弱的一环。很多时候，智能体面对复杂长链路任务并非“不知道该调用哪个 API”，而是在漫长的交互和多轮环境反馈中，把函数参数填错了。
ArXiv URL：https://arxiv.org/abs/2609.06124v1
模型要么凭空捏造一个上游从未返回过的订单号，要么机械地重复几轮前早已失效的旧输入，甚至在上游接口报错后产生虚假替代值。参数一旦脱节，后续执行便全盘皆输。
这一痛点直指现有合成数据训练体系的盲区。当前主流的多轮工具调用数据合成方案，大多聚焦在“工具选择的依赖图”，却忽视了“参数值在跨轮次之间的因果传递”。华为与独立研究者共同提出的 SAP（State-Guided Data Synthesis with Argument Provenance） 框架，正是为了补齐这块拼图。该方案将多轮工具交互形式化为状态机引导的闭环生成，把参数溯源（Argument Provenance）作为强约束硬编码进合成管线，并据此训练出仅 4B 参数量的 SAP-4B 模型，在多轮工具评测基准 BFCL v4 和复杂状态对话基准 $\tau^2$-bench 上展现出了超越同体量基线的竞争力。
为什么参数依赖是多轮交互的致命短板？
在长程智能体任务中，工具调用的本质是与动态外部环境持续进行状态交换。然而，当前开源的多轮训练集普遍存在“依赖链条浅、跨轮参数少”的问题。
如果把多轮交互中参数值的传递抽象成有向依赖图，参数的取值通常来自三个源头：初始环境状态、前面轮次工具返回的结构化字段，或者用户在早期对话中提到的上下文。研究者在诊断 ToolACE、APIGen-MT 等代表性开源多轮训练集时发现，跨轮次传递的平均链条长度（Mean Chain Length）与最大链条长度（Max Chain Length）普遍偏低，真正涉及跨轮次依赖的参数占比相当有限。这种数据训练出来的模型，面对单步或两三步的简短调用尚能应付，一旦遭遇深层上下文的交织引用，就会高频出现参数幻觉。
现有合成数据方法在解决这一问题时面临两难困境：
一种是意图优先（Intent-First）范式。它先让模型构思用户意图，再事后反推工具调用与对话。这类方法依赖大模型委员会或基于规则的蓝图做后验校验。由于缺乏底层的执行因果链支撑，生成质量受限于判定模型本身的推理可靠性；更致命的是，一旦某一步校验失败，通常必须整条轨迹推倒重来，生成成本居高不下且容易在长链路任务中丢弃局部正确的样本。
另一种是轨迹优先（Trace-First）范式。它在预先构建的工具依赖图上随机游走生成可执行路径，再倒推用户的自然语言 Query。这种方式虽然能保证执行成功率，但其依赖图高度绑定在特定工具生态内部，迁移到全新垂直领域时，人工重构或挖掘工具拓扑的成本极高。
SAP 针对这一痛点的核心思路可以概括为：不在事后做过滤，而是在合成时就把参数因果写进状态转移里；不绑定静态工具图，而是用轻量抽象的状态机把控交互节奏。
将交互抽象为状态机：POMDP 与 FSM 的分工
SAP 首先在形式化上厘清了交互环境与规划节奏的边界，将多轮数据合成表述为部分可观测马尔可夫决策过程（POMDP）：$\mathcal{M}=(S, A, O, T)$。真实物理环境或数据库具有隐式状态 $S$，模型无法直接透视全局，只能通过观测值 $O$（包括工具执行返回 $r$ 和用户消息 $u$）来感知环境，并采取动作 $A$（工具调用或回复）。
为了指导交互自然推进，SAP 在环境 POMDP 之上架设了一层对话阶段级有限状态机（FSM）：
\[\mathcal{F}=(\Sigma, \sigma_0, \Sigma_f, \Delta)\]这里的状态集合 $\Sigma$ 并不是底层具体的数据库配置，而是领域无关的对话交互阶段，例如“会话开启（$\sigma_{\text{init}}$）”、“用户已鉴权（$\sigma_{\text{logged_in}}$）”、“信息已检索（$\sigma_{\text{search_done}}$）”等。状态机转移边 $\delta = (\sigma, \mathcal{C}\delta, \sigma’, \mathcal{T}\delta)$ 则代表了一个交互轮次：包含当前轮要调用的有序工具列表 $\mathcal{C}\delta$，以及为工具内每个参数打上的溯源标签映射 $\mathcal{T}\delta$。
这种解耦带来了显著的泛化优势。研究者无需为每一个新的 API 集合手工画死“接口 A 必须接接口 B”的精细依赖图，只需让大模型依据 API 接口文档，将各工具归类到通用的交互阶段转移中。当业务场景更换时，只需替换工具文档和对应的轻量底层沙箱，状态机即可动态重建。
五类溯源标签体系与因果不变量
SAP 方法中最核心的机制创新，是显式的参数溯源标签体系（Provenance Tag）。在每一次工具调用中，参数 $p$ 的取值必须被严格归类为以下五种来源之一：
-
初始状态注入（$P_i$）：参数值来源于初始环境状态 $c_0$，通常通过只读工具的返回或用户开篇陈述带入。
-
上游工具返回（$P_o$）：参数值来源于此前某一轮某个工具调用返回对象的特定字段（记为 $P_o(k’, j’, f’)$）。这是长程因果依赖的核心。
-
当轮用户输入（$P_c$）：参数值由用户在当前轮次的消息中首次显式提供。
-
历史用户输入（$P_u$）：参数值由用户在更早的历史轮次中提供过，当前轮次属于再次引用。
-
运行时降级填充（$P_f$）：仅在生成规划执行时出现的动态标签。如果原本声明的 $P_o$ 上游依赖在实际执行中未能满足（例如上游检索落空），规划器不会直接崩溃，而是记录 $P_f$ 并安全降级为利用可用的 $P_i$ 或新 $P_c$ 替代，同时作为诊断标记留存。
在这一分类体系下，SAP 确立了严格的溯源不变量（Provenance Invariant）：在任何参数值被正式写入轨迹前，它的因果来源必须被明确声明；对于上游依赖型参数（$P_i, P_o, P_u$），所引用的上游实体必须在执行历史中已真实存在，或已在虚拟历史中完成预注册。
跨轮参数依赖由此不再是模型自由发挥后撞大运撞出来的副产物，而是从轨迹构建之初就被强行锁死的逻辑骨架。
三 Agent 闭环与局部容错执行
为了把上述约束落到实处，SAP 构建了一个由三位专项大语言模型 Agent 与一个沙箱执行器 $\varepsilon$ 构成的协同闭环系统。
第一步，骨架生成智能体 $\mathcal{A}_{\text{FSM}}$ 介入。它根据精简的工具文档和初始环境概要，生成带有溯源标签的 FSM 状态转移骨架。此时，参数只打上了分类标签，尚未填入具体的字面量。
第二步，**规划与执行智能体 $\mathcal{A}{\text{plan}}$ 联合执行器 $\varepsilon$** 工作。管线在 FSM 上采样一条从初始状态到终结状态的游走路径，$\mathcal{A}{\text{plan}}$ 逐轮将带有标签的抽象调用转换为带有真实参数值的调用。每生成一个轮次的调用，沙箱执行器 $\varepsilon$ 立即执行该调用并捕获返回结果。
这一步的设计打破了传统意图优先方法“一旦出错全部重掷”的低效循环：
-
同轮并行化：$\mathcal{A}_{\text{plan}}$ 会分析同一轮次内的多个调用，不存在 $P_o$ 依赖的调用会被打散为并行组，交由执行器并发执行。
-
局部重试与环境回滚：如果某一次工具调用执行报错，系统只针对该出错调用进行局部重新生成与重试，其他已执行成功的先验步骤保持不变；若重试仍不通，则调用沙箱回滚机制恢复现场。这使得极其复杂的长轨迹合成成功率大幅攀升。
-
解开 $P_u$ 的先有鸡还是先有蛋困境：历史用户输入（$P_u$）在逻辑上必须先由用户说出，但在该阶段用户的对话文本尚未生成。SAP 通过引入虚拟历史 $\Delta_v$ 巧解该矛盾：规划阶段先确定参数值并临时按 $P_c$ 登记，将这一需求预埋在第 $k^\star$ 轮的虚拟槽位中，交由后续的对话生成 Agent 去渲染。
第三步，**对话生成智能体 $\mathcal{A}{\text{msg}}$** 登场。当整条轨迹的所有工具调用、参数绑定及实际执行返回全部固化后，$\mathcal{A}{\text{msg}}$ 才开始自后向前“看图说话”，补全每一轮的真实用户消息 $u_k$ 与助手自然语言回复。
因为所有调用结果已经是板上钉钉的事实，$\mathcal{A}_{\text{msg}}$ 绝无可能产生脱离环境执行的虚假意图。对于包含具体数值的 $P_c$ 或 $P_u$ 锚点，用户消息必须显式提及对应字面量；而对于引用此前返回的 $P_o$ 与后续调用的 $P_u$，用户则通过符合人类习惯的指代短语（如“就刚才查到的那个航班”）自然带过，从而极大地拉升了对话文本的真实度与多样性。
挑战场景注入：对抗真实世界的偶发异常
如果训练数据全是一帆风顺的“完美调用”，模型在现实部署中遇到用户漏说参数或接口下线时就会手足无措。针对这一缺陷，SAP 在轨迹产出后，引入了两个专门的重写算子（Rewrite Operators）注入挑战场景：
其一是缺参探查（MissParam, $\Psi_{\text{param}}$）。算子在某个生成轮次中，故意把用户消息里原本提供的 $P_c$ 具体字面量抹去，改写为含糊不清的指代，同时清空当轮助手的工具调用，迫使助手生成“追问缺省参数”的反问句；紧接着插入一个披露轮次（Reveal Turn），由用户补全缺失信息，模型再恢复调用。
其二是缺函数应对（MissFunc, $\Psi_{\text{func}}$）。算子动态隐藏某个后续原本要调用的核心工具，观察模型在无对应 API 时的妥协响应，随后在下一轮通过用户消息重新开放该工具。
重写后的轨迹必须经过执行器二次重放（Replay），确保环境最终状态与原基线轨迹完全一致，才会被持久化保留。最后，所有数据还需通过代码级静态确定性检查与 Agent 级语义判定两道质检过滤，彻底消灭因果断裂与格式坏死。
实验评测与结果分析
基于 SAP 管线，研究团队合成了约 9,000 条高质量多轮交互轨迹，并选用开源的 Qwen3-4B-Instruct-2507 作为基座进行全参数监督微调（SFT），训练出 SAP-4B。
在基准评测中，研究者选取了当前多轮工具调用领域极具公信力的两大基准：测试 API 综合调用能力的 BFCL v4 Multi-Turn（下分基础、缺函数、缺参数、长上下文四个子集），以及侧重长程真实交互、维持世界状态一致性的 $\tau^2$-bench（Retail 电商与 Airline 航空领域）。
从评测数据来看，在 4B 到 8B 的开源小参数量模型梯队中，SAP-4B 展现出了极为亮眼的表现：
在 BFCL v4 多轮综合测试中，SAP-4B 的平均得分显著拉开了与原始基座 Qwen3-4B-Instruct 的差距，并且全面压制了此前同量级开源工作中表现突出的 CM2、ToolACE-2 以及 AWM 等方案。特别是在注入了挑战算子的 MissParam（缺参）与 MissFunc（缺函数）子项上，SAP-4B 展现出出色的鲁棒性，验证了合成阶段针对性对抗注入的有效性。
而在更考验复杂长轮次世界状态追踪的 $\tau^2$-bench 上，SAP-4B 的 Retail 领域成功率和 Airline 领域表现大幅跃升。这种提升直接证明：参数溯源训练赋予了小模型更强韧的长程追踪直觉。模型在调用工具时，不再是在漫长的上下文中盲目“抓取”形似参数的 Token，而是学会了精确定位其在先前调用输出中的对应槽位。
必须客观看待的是，尽管 SAP-4B 已经逼近甚至部分反超了 8B 规模的专用工具调用模型，但面对 Claude Sonnet 4.5、Gemini-3 Pro 这类在两个基准上分别拿到 60+ 与 70+ 分数的闭源前沿巨无霸时，开源小模型依然存在不可忽视的绝对差距。这表明仅靠 9k 条高质量 SFT 数据能够在范式上纠偏模型的调用行为，但在极其错综复杂的多轮推理与容错规划中，底座模型本身的通识规模红利仍是不可替代的坚固底座。
消融实验揭示的因果价值
为了验证各组件的具体贡献，论文在匹配数据规模的条件下开展了剥离实验。消融结果揭示了两个核心结论：
当在管线中剥离逐参数的溯源标签声明（Provenance Tags）时，模型在 BFCL v4 多轮评测上的各项分数均出现了明显下滑。这意味着，如果在合成阶段放弃对 $P_i, P_o, P_u$ 的严格前置绑定，仅仅依赖大模型在代码填空时的自发发挥，数据中就会不可避免地混入“虚假依赖”或“上游未定义即使用”的有毒样本，从而弱化微调后模型对真实执行状态的敏感度。
而当剥离两项挑战场景重写算子（$\Psi_{\text{param}}$ 与 $\Psi_{\text{func}}$）后，模型在基准的基础场景（Base）上受影响相对温和，但在对应的 MissParam 与 MissFunc 子项上遭遇了滑铁卢式的得分崩塌。这有力地说明：大模型默认的工具调用倾向是“只要看到工具就硬填、只要看到参数就默认完整”。面对现实世界中信息模糊、参数短缺的常态，如果不在训练集中主动注入反问追问与状态等待的因果闭环，模型就很难自主学会这种防御性的调用行为。
对未来智能体数据工程的启示
SAP 这项工作跳出了以往大模型微调中“堆砌意图多样性”和“扩大提示词花样”的常规操作，直奔多轮 Agent 最容易暴死的地带——参数因果断裂。
它的核心启示在于：工具调用的高阶智能，本质上是环境状态驱动的严谨数据流转。 过去很多研究寄希望于通过单纯增大模型参数或依靠自回归预测来让 LLM 隐式学会参数对齐，但在多轮长链路下，这种软性概率关联极易失准。SAP 证明，在数据生成的最底层引入状态机分阶段解耦，将参数依赖变为显式的因果溯源，并依托环境沙箱进行实时的局部容错重试，可以用极高的数据生成效率、极低的样本量（仅约 9k 条），彻底扭转小参数量模型在多轮调用中的“参数抓瞎”状态。
对于正在构建垂类 Agent、代码生成助手或复杂业务流机器人的团队而言，这一思路具有很高的工程借鉴价值：与其耗费昂贵算力在端到端的后验校验中反复丢弃数据，不如将 API 之间的调用逻辑与参数流向在生成源头进行结构化约束。只有当训练数据里的每一个参数都“查有实据”，模型在真实战场上才有可能做到步步为营。