1. 先聊清楚为什么专门做一套“工具调用数据”的合成方案ToolLoop这个名字核心就是“Closed-Loop Tool-Use Data Synthesis”也就是面向工具调用场景的闭环数据合成。做Agent、做Function Calling微调的朋友应该都有体会工具调用数据的质量直接决定了模型能不能在真实环境里正确编排一连串动作。而这件事的难点远不是找几个API填几段Json就能糊弄过去的。目前在社区里有一个比较共识的判断经过人工标注的、高质量的多轮工具调用数据实在太稀缺。标注成本高是一方面更麻烦的是长链条工具调用逻辑很难靠几个标注人员稳定复现。比如一个“帮我对比三个云服务商的GPU实例并推荐最便宜的”请求背后涉及实例查询、价格计算、区域对比、甚至历史折扣识别人工标注一条可用轨迹可能要半小时起步。于是大家转向合成数据想靠大模型自动生成批量数据。问题是直接让大模型一口气生成完整轨迹容易出现幻觉参数、工具选择错误、前后逻辑断裂本质上是因为单次生成长度过长模型其实控制不住。ToolLoop的思路恰好是把这件事拆开用“分解式生成”加“动态自我反馈”形成闭环。简单说不再让模型一口气从用户问题编到最终回答而是先拆解意图再逐步规划工具调用顺序随后让工具执行结果回灌最后进行质量判优和自动修正。整个流程是可自检、可迭代、可持续优化的这也是它区别于“一次性生成一批数据”这类粗暴方案的地方。这篇内容适合正在做Agent数据工程、准备微调工具调用能力或者被合成数据质量问题折磨过的算法工程师和AI应用开发者。我会把整个闭环的设计思路、关键实现细节、Prompt组织方式以及我在实操中踩过的坑都梳理出来。哪怕你没打算复现完整系统里面关于“如何设计工具调用数据的生成框架”和“如何用执行反馈反哺生成质量”的思路应该也能直接借鉴到你自己的Pipeline里。2. 分解式生成把长轨迹拆成可验收的子任务2.1 核心思路从整体生成切换到分解生成先回忆一个很常见的失败场景。你给GPT-4或者其他开源模型一条指令“帮我查一下今天上海的天气再推荐三家适合带宠物去的餐厅。”如果让它直接一次性输出完整的工具调用序列模型大概率会自己脑补一个天气API编造一个“晴25℃”的结果然后根据并不存在的知识生成餐厅推荐。这种轨迹拿去微调轻则污染数据重则让模型学会“一本正经地编造工具结果”。ToolLoop的破法在于“Decomposed Generation”。它把一个完整的用户请求拆成多个有序的子任务先判断需要哪些信息再选择每一个信息应该由哪个工具提供随后构造工具的输入参数并真实执行最后把多个工具的执行结果汇总成最终答案。每一步只解决一个小问题生成长度短了可控性自然就上来了。我用一个类比来解释端到端生成相当于让一个实习生一口气把一篇行业研究报告写完写之前不给提纲、不给素材、不核对数据全靠脑补分解式生成则是先让实习生列大纲确认大纲后再一个章节一个章节收集资料每收集完一份资料就回来确认一次最后再汇总。后者虽然流程长了但每一步都能检查、能返工最终成品质量显然更稳。2.2 四层分解意图、规划、参数、总结在ToolLoop的设计里分解不是随意切几刀而是按工具调用的天然逻辑分成四个层面。第一层是意图分解。模型需要先判断用户请求里藏着几个独立的信息诉求。比如“对比A、B、C三个套餐再算一下我下个月账单”这个请求意图层会拆出“套餐对比”和“账单估算”两个子意图。这一层不涉及工具细节重点关注有没有漏掉诉求、有没有把不同诉求混在一起。第二层是规划与路由。针对每一个子意图决定该调用哪个工具、调用顺序是什么。比如“套餐对比”对应查询套餐接口但需要先拿到用户的套餐ID所以得先调用“查询用户订阅”接口再调用“套餐详情”接口。规划层输出的是一张有序的工具调用草图这一步也是整个流程中计算消耗最大的一环。第三层是参数构造。工具调用之所以经常失败大量问题出在参数层。模型很容易漏填必填字段、类型写错、或者传入一个上下文里根本不存在的ID。ToolLoop在这一步会结合意图层和规划层的产物以及对话历史中的具体实体值生成严格的Json参数。参数层只做这一件事所以出错率能压得很低。第四层是结果综合。工具执行完成后所有返回值会汇总到这一步由模型生成给用户看的最终回答。结果综合层不关心调用过程只负责把结构化数据转成自然语言并检查是否覆盖了意图层拆出的全部子意图。2.3 为什么这样拆能提升数据质量我自己实操后的感受是分解式生成最大的价值不是每一层变得简单了而是“每一步都有独立的验收标准”。端到端生成时你很难说清一条错误轨迹到底错在哪个环节。是意图理解错了工具选错了还是参数写错了一旦没法定位错误后续的纠错就只能靠重新生成来碰运气。但ToolLoop四层拆完后每一层产出物都可以做结构化校验。意图层可以比对期望子意图集合规划层可以检查工具是否存在、依赖顺序是否合理参数层可以直接用工具的Json Schema做类型校验结果综合层则可以对比工具返回值里的关键信息有没有被正确引用。这种设计带来的直接收益是错误从“整条轨迹废掉”变成了“某一个子任务需要重跑”。调试成本是线性下降的。另外用户可以针对某一层单独优化Prompt或者替换模型不需要动整个Pipeline迭代起来特别灵活。2.4 分解粒度怎么控制拆多细才算合理这里要提醒一句分解不是越细越好。如果每个子任务都切到极细比如把“生成一个Json字段”都单独拆一步那前后文的传递依赖会变得极其复杂反而会让合成效率下降。我踩过这个坑早期版本在参数构造层又拆分出了“提取实体”和“生成Json”两个子模块结果实体抽取模块经常漏上下文还增加了链路耗时。在实践中我的经验判断标准是“一个子任务是否能独立做输入输出验收”。意图分解、工具规划、参数构造、结果综合这四层每一层都能给出明确输入和可校验输出这就够了。如果某些场景特别复杂比如金融分析里有多轮嵌套计算你可以在规划层内部再增加一个循环步骤而不是盲目增加更多抽象层级。从更底层的逻辑看分解式生成解决的核心问题是“大模型单次生成长度与成功率之间的负相关”。你生成的Token越多、决策节点越多模型保持一致性的概率就越低。把决策节点拆开就是对模型能力边界的一种尊重。3. 动态自我反馈执行-检查-修正把轨迹盘出真金3.1 静态合成与动态合成的原则区别纯静态的合成数据管线流程通常是大模型生成轨迹 → 人工或规则过滤 → 直接进入训练集。这种方案的问题在于生成出来的轨迹严重依赖初始模型能力。如果模型本身不会正确调用某个工具它生成的多半也是错误调用方式而静态规则只能筛掉明显的格式错误筛不掉“看起来格式正确但逻辑错误”的坏样本。ToolLoop的“Dynamic Self-Feedback”思路是把轨迹放到真实工具环境里跑一遍让执行结果反馈回来影响轨迹的保留、修正或丢弃。这个思路借鉴了强化学习中的轨迹采样逻辑你生成了一批候选动作序列但只有真正跟环境交互过并拿到高奖励的那批动作才有训练价值。有一个关键差异值得强调静态方案里“工具执行结果”是模型编造的动态方案里“工具执行结果”是环境真实返回的。这个差异决定了模型能否学到真正的因果关系。比如某个工具因为参数格式错误抛了异常静态数据里模型可能压根不知道这个异常的存在但动态方案会把异常信息注入到修正阶段让模型下一轮生成时避开同样的坑。3.2 反馈信号的来源与采集反馈信号的来源主要有三个层次。第一层是工具层信号。调用成功还是失败、返回码是什么、异常信息说了什么、参数校验有没有报错、执行耗时是否异常。这些信号直接从真实环境获取最客观也最直接。第二层是结果层信号。工具调用成功了但返回结果到底有没有满足用户请求ToolLoop会引入一个Critic模型把工具输出和原始用户意图做一致性比对。比如用户问“哪台GPU实例性价比最高”工具返回了一份实例列表Critic会检查最终回答里是否真的给出了性价比比较的结论而不只是把列表罗列出来。第三层是成本层信号。同一类请求是否能少调用一个工具是否能用更短的参数完成同样的功能这类信号对标的是真实场景中的延迟和费用优化。ToolLoop里会记录每次合成的工具调用次数、Token消耗在后期做轨迹排序时这些成本信息会作为惩罚项参与打分。3.3 反馈注入与轨迹修正的完整闭环反馈采集到之后关键动作是“修正”而不是“丢弃”。ToolLoop维护了一个修正循环步骤拆开是第一步执行器按规划层的调用序列真实执行工具采集每一步的中间返回结果和异常信息。第二步Critic模型对结果进行质量打分输出“通过”“不通过”“需修正”三类结论。第三步不通过的轨迹回到修正模块修正模块会结合用户原始请求、已生成的规划序列、工具真实返回的异常信息生成一份修正后的轨迹版本。第四步修正后的轨迹重新进入执行器开启新一轮循环。整个闭环会持续迭代直到轨迹通过Critic验收或者达到最大修正轮数。达到最大轮数仍不通过的轨迹会被丢弃避免低质量数据硬塞进训练集。这个流程里最核心的工程细节是“修正哪一部分”。常见的失败场景是规划层选错了工具但参数构造层正确执行了错误规划。如果整个轨迹回炉重造等于把正确部分也丢掉了。ToolLoop的修正模块会定位到具体出错层级优先只让对应层重新推理。这个能力依赖一个额外的小型错误定位模型或者你可以在Prompt里让修正模型先分析错误环节再重新生成。我想用一个埋头干活的人来比喻这个闭环他接到一个任务不是闷头做完就交差而是每做一步都跟环境对一下反馈错了就定位是哪个环节错了只改那一步改完再试。看似慢但整体产出的良品率远高于“一口气做完再整体推翻”。3.4 一个可参考的反馈迭代实现框架考虑到很多读者会关心工程实现我给出一个简化版的伪代码框架展示反馈闭环的主流程def tool_loop_synthesis(user_request, tools, max_iterations3): # 阶段一分解生成 decomposed decompose_request(user_request) plan generate_plan(decomposed, tools) params generate_params(decomposed, plan, tools) for iteration in range(max_iterations): # 阶段二执行工具收集真实反馈 execution_log execute_plan(plan, params, tools) # 阶段三Critic 验收 critique critic.evaluate( user_requestuser_request, planplan, execution_logexecution_log ) if critique.verdict pass: synthesis_result generate_final_answer(user_request, execution_log) return build_training_sample( user_requestuser_request, planplan, paramsparams, execution_logexecution_log, final_answersynthesis_result ) elif critique.verdict fix and iteration max_iterations - 1: # 阶段四只修正错误层级不整体回炉 error_layer localize_error_layer(critique.feedback) if error_layer plan: plan regenerate_plan(decomposed, tools, critique.feedback) elif error_layer params: params regenerate_params(decomposed, plan, tools, critique.feedback) continue else: return None # 到达最大迭代次数或无法修正放弃该样本 return None注意这里的execution_log必须是工具真实返回的数据或异常而不是模型生成的伪结果。那如果某个工具是真实付费API每次都真实调用成本太高怎么办我的经验是用“Mock执行器 抽样真实验证”组合方案日常批量合成阶段用高仿真度的Mock服务完成闭环上线前随机抽取10%到20%的样本切到真实API执行比对。这样能把成本压下去同时保留动态反馈的核心价值。4. 实操落地从数据格式到Prompt再到训练评测4.1 数据格式设计兼容主流SFT/RLHF链路讨论完设计回到实际工程。ToolLoop最终产出的是标准工具调用训练数据数据格式要能被SFT监督微调和后续的RLHF/DPO流程直接消费。我用的组织方式是OpenAI Function Calling风格的messages结构同时在每条样本里保留完整元信息方便后续做数据筛选。一条最终训练样本包含四个部分用户请求原始输入不做任何改写。模型消息系统提示词、模型生成的思考过程、工具调用请求包含函数名与参数。工具返回工具真实返回的结构化内容带request_id便于溯源。最终回答基于所有工具返回合成的自然语言回复。我用一个最小示例说明结构{ messages: [ { role: user, content: 帮我查一下订单NO2025001的物流状态并预估到达时间 }, { role: assistant, content: null, tool_calls: [ { id: call_logistics_001, type: function, function: { name: query_logistics, arguments: {\order_id\: \NO2025001\} } } ] }, { role: tool, tool_call_id: call_logistics_001, content: {\status\: \in_transit\, \current_city\: \武汉\, \last_update\: \2025-01-10\, \estimated_delivery\: \2025-01-14\} }, { role: assistant, content: 你的订单NO2025001目前正在运输中已经到达武汉预计1月14日送达。 } ], metadata: { synthesis_source: tool_loop, iterations: 2, critic_score: 0.96, tools_used: [query_logistics] } }这里有个细节metadata里的critic_score非常有用。后续你可以按分数阈值配置训练集高分样本用于SFT正样本低分但结构正确的样本可用于DPO的负样本这样一套合成管线就能同时支撑多种训练策略。4.2 分解生成时需要的Prompt模板Prompt设计是整个Pipeline里工程含量最高的环节。ToolLoop里不同的子任务需要单独设计Prompt不能一套打天下。意图分解阶段的Prompt核心是让模型列出所有子任务并要求每个子任务跟原始请求中的一句表述绑定方便后续追溯。规划阶段的Prompt需要把可用工具列表和字段Schema放进去并要求输出有序调用序列。参数构造阶段的Prompt强调“只能使用用户请求和规划结果中出现的实体”从根本上减少幻觉。结果综合阶段的Prompt强调“严格基于工具返回值回答”并要求明确引用工具输出中的数字或状态字段。我以一个规划阶段的Prompt模板为例供参考你是工具调用规划专家。请根据用户请求从可用工具列表中选择合适的工具并生成有序调用序列。 用户请求 {user_request} 前置意图分解结果 {decomposed_intents} 可用工具列表及其参数Schema {tools_schema} 输出要求 1. 先列出你需要调用哪些工具并说明每个工具对应上述哪个子意图 2. 用Json数组输出调用顺序格式为[{tool: 工具名, intent_id: 对应子意图编号}] 3. 如果某个子意图不需要调用工具单独标注reason 4. 只输出规划结果不要额外解释。 注意如果工具之间有数据依赖如A接口返回的ID是B接口的入参必须保证A在B之前调用。实际跑下来这个模板最有效的部分就是最后那条“注意”。加进去后工具依赖顺序的错误率降低了大概三成。类似这种针对性约束是Prompt工程里最值钱的投入。4.3 质量筛选与人工抽检的平衡即使有闭环修正也不能保证100%样本都是高质量的。ToolLoop的实践经验是自动化过滤 分层人工抽检必须结合。自动化层面我总结了一套硬性过滤规则包含工具调用异常且修正后仍失败的样本直接丢弃最终回答里出现工具上下文中不存在的数字或实体名称的样本丢弃Critic评分低于0.7的样本不进训练集。这些规则简单但能把明显的坏样本挡在门外。人工抽检层面建议按比例分层抽检。不要简单随机抽而是按Critic分数分层高分区间抽2%中分区间抽10%低分区间但没触发自动丢弃的抽50%。这样人工精力大多花在看边界案例上性价比最高。我试过完全不看边界样本直接把低分样本丢进训练集结果模型学到了一种奇怪的“自信胡扯”风格因为那些低分样本往往是“格式正确但内容不准确”的典型。4.4 用合成数据微调的评估指标建议微调完成后的评估建议分两层来设计。第一层是工具调用成功率。构建一个评测集里面每条样本都有固定的工具列表和预期调用序列。跑一遍模型看它生成的工具调用是否与预期一致、参数是否满足Json Schema校验、调用顺序是否满足依赖关系。这一层指标能快速判断工具编排能力有没有提升。第二层是任务完成质量。拿最终的端到端任务粒度做评估比如“用户读完回复后是否能直接采取行动”。这个指标可以通过LLM-as-Judge以大模型作为裁判或者人工评分获得。我建议两种方式都做大模型裁判跑全量人工评分跑抽样。两者之间的分数差就是你评测集的稳定程度。另外强烈建议做一组“错误注入对比评测”。故意构造一些带有冗余工具的请求看看微调后的模型是否能跳过无用调用。合成数据很容易让模型形成“逢问必调”的习惯因为训练集里大部分样本都调了工具。ToolLoop闭环执行和成本层信号能在一定程度上缓解这个问题但评测时仍然要主动观察别等上线后才暴露。5. 踩坑实录与经验清单5.1 实测中容易翻车的四个环节第一工具喜好偏移。合成Pipeline如果只覆盖少量固定工具微调后的模型会倾向于遇到任何问题都去调用这几个工具。哪怕用户问“现在几点”它都可能调一次时钟API。这个现象的本质是合成数据的工具分布太窄。我建议在合成阶段至少准备30个以上不同领域的Mock工具哪怕部分工具在实际场景中很少使用也要在训练数据里偶尔出现。第二修正循环漂移。动态自我反馈虽然能修正轨迹但修正轮数过多时轨迹会越来越偏离原始请求最后生成一份“为了通过Critic而长成”的数据。这种数据看起来质量很高实际用起来非常机械。解决方案是给轨迹修正加“语义距离”限制如果修正后的轨迹与用户原始请求的语义相似度低于阈值直接中止修正。第三工具返回值格式混乱。真实环境的工具返回值结构可能非常嵌套直接塞进Json样本里会让模型学出一堆无关字段。实操中我会对工具返回值做“字段白名单”清洗只保留用户请求可能涉及的关键字段减少噪音。第四多轮对话的参考链断裂。ToolLoop的闭环不仅针对单轮请求也设计了多轮上下文扩展。多轮场景下第一轮的输出会成为第二轮的上下文但合成时很容易出现第二轮的回复依赖于第一轮中不存在的信息。这类错误在意图分解阶段不容易暴露需要额外增加一轮上下文一致性校验确保每一轮回答的实体都能在前置轮次中找到出处。5.2 排查与修复方法如果合成数据里出现大量工具调用参数缺失优先检查参数构造阶段的Prompt是否把对话历史喂全了。很多模型丢失实体不是能力问题而是上下文里压根没有这个实体。排查方法是在合成日志里打印参数构造层的输入重点看用户请求、规划结果中涉及的实体是否完整出现在上下文里。如果修正循环始终不收敛大概率是Critic的判定标准出了偏差。我遇到过一种情况Critic认为“工具返回结果与用户问题不相关”实际上是因为一个工具返回了空数组而规划层又依赖这个空数组继续下一步。问题不在生成器而在工具Mock逻辑。先确认工具返回是否符合真实行为再考虑调整模型。如果最终回答经常引用不存在的工具返回字段问题通常出在结果综合层的Prompt上。这个阶段必须明确指定“只能引用execution_log中出现的字段名”并在生成后做一个简单的字段引用校验用代码扫一遍最终回答中包含的数字和实体跟execution_log比对不一致就重新生成。5.3 一些个人经验与判断在多次跑通类似工具调用数据管线之后我的一个整体判断是这条路线最大的收益不是省掉了人工标注而是把数据生产变成了一条“可测量、可迭代”的流水线。你每优化一次Critic规则、每增加一个Mock工具接下来的批量化数据质量都会同步提升。这与纯靠人工标注的质量不稳定形成鲜明对比。还有一条很现实的经验合成数据的多样性重要性甚至高于单条样本精度。我试过用两万条ToolLoop合成数据微调一个7B模型工具调用成功率比用六十万条粗糙合成数据的效果还要好。关键就在于ToolLoop数据里包含了大量失败-修正-成功的轨迹对模型通过对比学到了“为什么之前失败怎么改是对的”。这种对比信号是均匀分布的正样本数据给不了的。如果后续想扩展这套方案可以往两个方向探索一是把工具返回的中间状态也纳入训练目标让模型学会根据不完整或冲突的中间结果动态调整后续工具调用二是引入用户对最终回答的显式偏好打分把反馈信号从“工具执行成功”进一步升级为“用户任务达成”。后者更贴近真实业务价值但实现复杂度也会上一个台阶。说到Dynamic Self-Feedback我个人的体会是反馈的价值不在于“多”而在于“准”。宁可每一轮反馈都精准定位到错误层级也不要设计一堆反馈信号让生成器无所适从。测试时你会发现“少而准”的反馈机制最终收敛速度反而比“多而全”的反馈更快而且代码维护成本低不少。最后分享一个小技巧合成数据Pipeline上线后一定要把每次任务的信息记录下来包括用户请求、生成轨迹、工具执行日志、Critic评价、修正轮数。这不仅是调试的抓手更是未来数据版本回溯和模型问题定位的基础。很多细节问题在没有完整日志的时候排查起来就像大海捞针但一旦日志齐全多数问题几分钟就能锁定。