Google介绍ToolGrad：先跑通工具调用，再生成训练问题

这项工作收录于ACL 2026 Findings。对网站团队，值得借鉴的是记录样例的方法：把一次实际完成的任务、工具返回的对象和验收结果放在一起，下一次才能复用或比较。 它并非可以直接安装的WordPress插件，也不要求普通站长立即开始训练模型。

为什么把工具调用放在问题前面？

传统合成数据的思路可以先拟一个任务，再让系统搜索完成路径。但拟出的任务未必有足够输入，也未必能由当前工具完成。系统反复尝试后，可能仍没有可作为正确示范的过程。

ToolGrad先构造有效的工具使用链，再标注相应问题。已有过程提供了更明确的信息：调用了哪些接口，参数怎样衔接，结果是什么，因而更容易写出与之相符的任务。论文索引与摘要

用一个简单例子理解：如果只有“整理产品资料”五个字，尚不清楚文件在哪、要保存成什么、是否需要网站草稿。若已经有读取某份资料、创建草稿并读回的过程，就能准确描述这一次做成的任务。但也正因为问题是倒着写的，必须避免把没做过的动作顺手添进问题。

文本反馈怎样让调用链变长？

官方方法分为提出候选API、执行候选、选择合适的一步、更新问题与回复四个职责，名称分别为Proposer、Executors、Selector和Updater。执行报告给下一轮提供语言反馈，使链条逐步延伸。“文本梯度”指这种反馈方向，不是这一步直接计算数值梯度更新模型权重。

这里真正需要保留的是步骤之间的联系。比如创建文件返回文件ID，后续读取应该沿用该对象。若训练材料只剩“读取资料、创建文件、检查结果”三个动作名，中间到底读取哪个文件就被省略了。

对工具使用而言，成功调用还不够：返回值要能被下一步正确使用，最后结果要与问题一致。一串独立接口都返回成功，却操作了不同对象，仍无法组成正确任务。

把一条网站草稿流程倒写成问题

下面是自拟例子，不是ToolGrad仓库中的WordPress功能，也不是本站执行记录。假设测试产品B15的资料包含材质和尺寸，没有交货日期；目标是创建供编辑审核的草稿。

过程	应保留的记录	它证明什么
读取B15资料	输入文件版本、实际字段、缺失项目	正文能够使用哪些事实
创建草稿	请求内容、草稿状态、返回文章ID	创建了哪个对象、要求保存为何种状态
按ID读回	保存后的正文、来源、实际状态	服务器留下的结果是否符合请求
返回预览	对应这篇草稿的预览入口	编辑是否能够继续审阅

根据这样的记录，问题可以写成：“根据B15测试资料生成一篇草稿，保留来源，不补写缺失交期，返回编辑预览入口。”它与执行记录中的输入、动作和结果一致。

如果倒写成“完成B15产品页发布并优化全部SEO设置”，就增加了流程没有证明的能力。草稿不等于发布，保存正文也不等于已经配置特色图、结构化数据或其他SEO字段。问题写得越宏大，样例的对应关系反而越容易失真。

这也是团队整理工作样例时可立即检查的一项：把用户要求逐句与执行记录对照。每个完成声明应该能找到依据；没有完成的部分应从样例任务中去掉，或明确留作另一项任务，而不是由最后的总结补齐。

什么样的“成功记录”不该作为正确示范？

如果要求草稿，读回状态却是公开发布，即使接口没有报错，也没有完成正确任务。若状态正确，却把另一个型号的参数写入B15正文，失败发生在内容对应关系。若交期缺失却被自动补成七天，则错误来自未经支持的信息。

这些情况适合保存为失败样例，并标明失败位置。后续修正提示词或工具连接时，可以检查同类问题是否减少。把失败记录全部删掉，只保留顺利的路径，会让团队失去最有用的回归检查材料。

还可以加入一类边界情况：创建请求超时，但服务器可能已经保存。下一步该先查已有对象还是直接再创建，会影响是否出现重复草稿。这个问题不应靠一条成功样例来推断，需要用可控测试单独定义预期结果。

上述验收条件来自网站任务本身。研究框架提供生成工具链的方法，却不会自动替每家公司定义“草稿”“正确产品事实”或“重复”的业务含义。

训练样例生成得顺利，和真实任务做得好是两回事

读研究结果时，应区分三个对象：生成过程能否产出有效样本、模型学过这些材料后在函数调用评测上表现如何，以及它能否完成你的网站任务。它们相关，但不能直接相互替代。

Google的实验把生成数据用于Gemma模型训练，并在另一套工具评测中比较结果。样本生成的高通过率，首先说明这种生成办法更容易产出可用材料；真实用户的需求事先已确定，可能不完整，也可能超出工具权限，不会自动配合已有调用链改写。

因此，团队即使借鉴“先跑通再记录”，仍需要留出独立测试。比如训练或示范使用B15，测试时换成另一个产品；资料里故意缺少某项字段，检查系统是否保留待确认；把创建改成更新已有草稿，检查是否仍按原模板重复新建。

这些测试不必追求很多，先覆盖实际经常发生的差异。测试输入与验收条件应在运行前确定，不能看见结果后再把题目改得刚好匹配。关于题目设计，可以继续看AI助手评测中的测试质量。

站长与开发团队，分别怎样利用这项研究？

如果只是维护日常自动化，先把常见任务做成可复用记录：输入资料、工具步骤、关键返回值、成功标准和实际结果。更换模型、连接方式或提示词之后，用相同条件重跑，比较改动影响在哪一步。这项工作本身就有价值，不必先微调模型。

需要研究训练数据的开发团队，则可以阅读作者官方仓库。其中MCP文件系统演示不要求GPU或ToolBench API密钥，但需要Gemini API密钥与运行环境；评测与微调属于另外的部分。能启动演示，与复现训练结果应分别记录。

MCP把工具能力接出来，ToolGrad讨论如何围绕有效调用生成学习材料，而网站业务还要提供自己的资料、对象和验收要求。工具接入与工作说明的关系，也可结合Agent Plugins、Skills与MCP进一步梳理。

最终留下的成果应是一组能被重新检查的任务：知道它用了哪份资料、操作了哪个对象、为什么算完成，以及换一个条件后还需要验证什么。只有“成功了”的一句记录，无法承担这些用途。