AI 的练习题，
谁来出？

先把事情做通，再给 AI 出题

研究回看｜模型需要练习怎样调用工具。练习题从哪里来，会影响它最后学会什么。

假设你要教一位新同事整理订单。最省事的教材，是拿一笔已经完成的订单，把查询库存、确认数量、生成清单的过程写下来，再配上客户最初的要求。新人可以沿着记录走一遍，也容易知道自己在哪一步做错。

给 AI 准备工具使用数据，也有类似的选择：先编一句用户要求，让系统寻找答案；或者先构建一条能够执行的路径，再为它补上合理的提问。前者从需求出发，后者从已知的操作出发。

Google Research 九月十日介绍的 ToolGrad 选择了后者。系统先逐步构造工具调用链，依据执行反馈挑选下一步，再生成与这条路径相符的用户请求。它把出题和解题的顺序调了过来。^[1]

论文初稿发表于 2025 年八月，当前第三版修订于 2026 年六月，并标注为 ACL 2026 Findings。九月的介绍让这项方法重新进入视野，研究本身已有更早的积累。^[2]

一句简单要求，可能没有可用答案

“帮我找一家明天能送货的供应商。”读起来很自然，但工具库里可能只有公司介绍，没有库存和配送日期。出题者若不知道这些缺口，便会造出一道现有系统做不了的题。

如果先拿现有查询接口确认能返回什么，再形成相应请求，训练材料就更容易完整。比如接口确实能查询某种零件的库存、取得指定仓库的地址，那么题目便可以围绕这些信息展开，不必让标注程序反复寻找根本不存在的配送承诺。

这样做节省的，是为了找到可用训练答案而进行的探索。但一条路径越容易成功，也越可能绕开麻烦：需要澄清的需求、信息缺失、系统故障，都不如顺畅完成的样本容易整理。

出题便同时承担了另一项工作：决定模型会反复遇见哪些世界。有充足信息、有合适工具、每次返回都正常的世界，适合教会基本动作；面对日常工作，还得补上另一半材料。

成功答案可以成为教材，不能包办考试

假设一套题库全是完整订单：客户编号唯一，商品名称规范，库存充足。模型学会把订单送进正确接口，表现可能很好。换成“和上次一样，再加两个”，问题就变了。它需要找到上次是哪笔订单，判断“两个”指哪项商品，还要确认当前库存。

这些难点来自人的表达和系统中的上下文。字段全部填对，仍可能理解错了订单。

如果训练和考试都由同一种出题流程产生，模型可能熟悉了出题者的措辞，却没有获得同样广泛的任务能力。把同一订单换个公司名、改个数量，并没有改变其中的推理结构。题目看上去多了，实际训练的仍是同一种动作。

因此，一套有用的课程可以先用成功路径教基本功，再用独立收集的需求检查遗漏。两部分不必争夺同一个位置：前者降低准备成本，后者告诉团队便宜的教材有没有把重要困难省掉。

小模型的机会，在任务是否讲得清楚

ToolGrad 团队用生成的数据对不同大小的 Gemma 3 模型进行后训练，在其工具调用实验中报告了改进。^[1] 这给小模型提供了一条值得关注的路线：用针对性很强的练习，改善一个明确能力。

对业务团队而言，接下来可以问得更具体。日常请求是否集中在少数操作？正确结果能否被程序检查？工具变化快不快？如果任务边界稳定，训练数据里的每一个好例子都可能反复发挥作用。

反过来，一套流程每周更换接口，客户表达又十分开放，维护教材可能比最初生成教材更费时间。昨天正确的字段，今天已被替换；过去一步能完成的操作，现在分成了查询和确认。模型会不会写出曾经有效的答案，也要进入评估。

把这项研究放回产品开发，最值得借鉴的部分是可检查的过程：先找出任务实际依赖哪些信息和动作，让每一步有明确结果，再决定哪些经验适合教给模型。只有一句顺畅的最终回复，很难承担这份教材的工作。

上一期讨论了机器人如何从示范学习。这一期把镜头移回屏幕：数字助手的示范也需要有人编排，而教材中那些没写出来的情况，常常会在上线后找上门。

桌面入口近了，训练材料也更具体了

近期回看｜两条九月十日的材料，分别涉及助手怎样进入工作，以及开发者怎样复查研究。

Gemini 为 Windows 提供桌面入口

Google 宣布 Gemini Windows 应用面向 Windows 10 和 11 全球提供，可通过 Alt + Space 打开。公告还介绍了从 Google 应用取信息、处理多步骤任务，以及生成图像和视频的入口。^[5]

桌面应用减少了切换窗口的距离。读一份材料时临时问一句、整理几条要点后回到原文，会比先打开浏览器标签页更顺手。这个变化首先体现在交互成本上，不能据此判断模型在本地运行，或者已经取得当前窗口里的全部内容。

试用时，有三个动作可以直接观察：呼出后能否回到原来的位置，引用了哪些材料，生成的结果放在哪里。多步骤任务和视频功能还需要查看各自的开放条件，安装了应用并不意味着所有能力都按同一方式提供。

ToolGrad 把演示与完整复现分开

作者仓库给出了基于文件系统 MCP 服务的快速演示，也另列数据生成、评测和后训练流程。快速演示不需要 GPU 或 ToolBench 密钥，但需要 Gemini API 密钥；模型训练和完整复现有另外的环境要求。^[3]

这种分层有助于第一次接触研究的人先看清过程。可以先读一条轨迹：系统提出了什么调用，执行后得到什么，为什么选择下一步。理解它怎样造出一条样本，再判断是否值得投入完整实验。

读代码时也要看输入的边界。文件系统示例能解释机制，却不会自动覆盖订单系统里的权限、并发修改和外部依赖。准备自己的试验，可以保留同样的记录形式，换成可控制的模拟对象。

工具调用的正确，分成哪几层？

技术背景｜一个请求能被解析、一个接口成功返回，以及一件事真的完成，各有不同的检查方法。

假设助手要整理一笔模拟订单。工具要求客户编号是字符串、数量是整数。模型把“两个”写进数量字段，系统可能在第一步就拒绝。改成数字二，格式关过了，后面的错误仍可能存在。

客户编号填成另一个人的，接口照样能返回；库存数字读取正确，但忘记订单要求的交付地点，结果也可能不适用。把这些情况都归为“调用失败”，很难知道应该改模型、工具说明，还是业务规则。

第一层：程序能否读懂

字段名称、类型和必填项决定调用能不能被接受。这里适合做确定性检查：数量是不是整数，日期是否符合约定格式，必填编号是否存在。

检查器不需要理解整段对话，就能指出这些错误。清楚的工具描述也可以提前减少歧义，例如把“日期”拆成下单日期和交付日期，而不是期待模型从一个模糊字段里猜出含义。

不过，格式检查只能回答输入长得对不对。一个合法日期可能是错误日期；一个存在的客户编号可能属于另一笔业务。

第二层：结果有没有满足任务

任务目标最好落在可观察的状态上。若用户要的是订单摘要，就检查摘要中的商品、数量和对应订单；若要保存草稿，就检查草稿对象是否存在，以及是否仍处在草稿状态。

“工具返回成功”提供了一条证据，结果对象提供另一条。某些接口的成功只表示请求已接收，后续处理仍可能失败。训练样本若把接收回执直接写成完成，会把这种混淆教给模型。

在模拟环境里，可以把目标状态写得很明确：只新增一份草稿，没有正式下单；字段来自这笔订单，没有混用另一笔；原始记录保持完整。这样，评估就不必只依赖另一个模型读最终回复打分。

第三层：前后状态能否接上

第一步查库存返回十件，第二步准备五件清单，第三步收到库存已变成三件的消息。若模型仍沿用第一次查询，单看每一步调用都可能合法，整条流程却已经过时。

这里需要保存变化发生的时间，以及哪些后续动作依赖旧结果。重新查询只是其中一种处理；另一种是停止提交，明确告知当前条件已变化。具体选择由任务规则决定。

顺序也可能带来副作用。先确认再创建，与先创建再确认，在草稿系统里或许都行；涉及正式对象时，则可能产生不同结果。教材需要记录工具改变了什么，不能只列调用名称。

文本反馈怎样帮助出下一道题

ToolGrad 用提出候选、执行、选择和更新四个模块，逐轮扩展工具链。它所说的文本“梯度”，是用于指导选择的文字反馈；这一步并不是普通神经网络训练里对参数求数值梯度。^[1]

可以用一个假设例子理解：几种候选调用都能运行，但其中一种能接上前一步得到的订单编号，另一种只是查询无关目录。反馈要指出哪种调用使任务更完整，再据此更新这条样本中的用户要求和答案。

这类反馈若只奖励“多调用一个工具”，就可能鼓励无意义的绕路。衡量一条轨迹时，步骤数需要和每一步提供的信息放在一起看。重复读取同一份材料十次，形式上很长，却没有增加同样多的任务难度。

总分之外，留下分类结果

BFCL 官方页面说明，其总准确率由各子类别无权重平均形成，并区分了不同版本新增的能力范围。^[4] 一个总分可以方便浏览，具体项目还需要看自己最常用的部分。

假设系统九成工作都是查询，偶尔生成草稿。它对复杂长链任务的成绩有参考价值，但频繁误读客户编号更值得先修。另一套系统专做多轮流程，前后状态能否保持一致就更重要。

因此，内部评测表可以保留格式、对象匹配、状态更新和最终结果四列。每次升级后看哪一列改善、哪一列退步，比只记一次综合分更容易找到下一步工作。

用十二笔模拟订单，做一套自己的练习题

试用方案｜先建立可以检查答案的小题库，再决定是否需要微调模型。本方案未作实测。

准备一个隔离的测试空间，用虚构客户和商品建立十二笔订单。数量不求多，先让每笔订单代表一种不同情况。任务限定为查询和生成草稿，所有输出都留在测试空间。

先写业务答案，暂时不写提示词

选四笔信息完整的订单，两笔同名客户订单，两笔缺少商品编号的订单，两笔已经取消的订单，再加两笔库存发生变化的订单。每个对象都用独立编号，名称可以相似。

对每笔写一句预期结果：哪些字段应出现在草稿里，哪些情况需要补充信息，哪些订单应保持取消状态。遇到库存变化，是按新库存调整还是等待确认，也在这时定下来。

如果两位同事对正确答案意见不同，先解决规则分歧。否则模型输出哪一种都可能被另一人判错，评测表最后记录的是团队尚未决定的业务规则。

保留一条完成路径，再写几种问法

从完整订单开始，手动确认查询与草稿生成能完成。把每一步输入、返回值和最后对象保存下来。这就是第一份参考轨迹。

随后写三种表达：明确说出编号的完整请求，日常口语，以及需要借助前文才能理解的短句。数量、客户和目标保持一致，只改变表达方式。若短句缺少足够前文，正确动作就应是询问，而不是猜。

让 AI 辅助改写问法可以减少机械劳动，但每条都要回到原订单核对。有时改写会悄悄加上“直接提交”或“沿用旧地址”，一句话的变化就改变了允许执行的范围。

给异常样本留正式位置

缺编号的订单用于观察是否补问；取消订单用于检查是否仍创建草稿；同名客户用于检查是否依赖唯一编号。库存变化则分别保留变更前后的查询结果，让系统有机会发现冲突。

不要把没有产出草稿的回合一概计作失败。有些题的正确结果就是指出缺口，并保留对象原状。题库若只奖励交出一个文件，模型便可能为了交付而替你补造缺失信息。

可以先将结果记成“正确完成”“正确暂停”“错误动作”和“环境故障”。之后再按业务目标计算比例，避免把本来不同的结果塞进同一个成功率。

留几笔订单，直到最后才打开

用于调提示词的订单和最后评估的订单分开保存。修改规则时，不反复查看保留组的答案；否则团队会不知不觉把系统调成擅长这十二笔订单。

保留组不只更换名称。可以换一种信息缺失方式，或者让库存变化发生在不同步骤，观察模型是否理解规则。正式上线前还需要更多样本，这一小组只是帮助找出明显漏洞。

先比较提示与工具说明，再考虑训练

运行一次原设置，保存结果。然后只修工具说明中的一个问题，比如明确客户编号来自哪一步，再运行同组样本。若这就解决了多数错误，暂时没有必要增加训练流程。

若反复出现同一种需要学习的模式，再评估是否用审核后的轨迹训练。把准备数据、训练、部署和后续维护的时间一并记录，才能比较两条路线的投入。

这套材料以后也能用于接口升级。字段变了，重放参考轨迹；业务规则变了，更新预期答案。每份样本留下适用版本，下次出错时就能判断是模型退步，还是教材已经过时。

天气图更细了，预报就更有用了吗？

科技纵深｜从 WeatherNext 3 看更新频率、空间分辨率和实际决策之间的距离。

训练数字助手时，人可以设计一间条件清楚的练习室。天气预报的考场每天都在变化：云层移动，风向转变，新的观测不断进入系统。模型不仅需要过去的经验，还需要足够及时地知道现在发生了什么。

Google 九月三日公布 WeatherNext 3，介绍了接入实时卫星观测、每小时生成新预报的做法。公告区分不同变量的空间尺度：部分地表变量为五公里，其他地表变量为十公里，大气变量为二十五公里。^[6]

这些数字很容易在传播中压成一句“预报更精准”。对使用者来说，它们分别回答不同问题：多久更新一次、地图划得多细，以及预测与后来观测有多接近。

一格五公里，仍不是一扇窗的天气

假设两座仓库相距三公里，一座在坡地，一座靠近河岸。地图网格更细，有机会保留更多地形差异；但仓库门口的遮挡、排水和局部阵风，仍然不是一个网格数值能够完整描述的。

空间分辨率决定输出怎样铺在地图上，不能直接换算成每个地址的准确率。把图片放大，也不会自动补出模型原来没有预测的细节。

同样，一天更新二十四次，增加了利用新信息的机会，却不保证每一次都比前一次更准确。更新是否有帮助，要把当时发布的预报与后来发生的天气配对，而不能只看最终那张已经接近现实的图。

比较时，先固定“提前多久”

假设上午九点做一次次日送货安排，下午五点又收到更新。前者承担的是提前一天规划，后者可以用于临近调整。把两份预报放在一起，只选更接近实际的一份，会掩盖作决定时能得到的信息。

比较可以从每天同一时刻保存预报开始：记录地点、未来时段，再用相同观测来源核对。短时和长时预测分别计分，误差才有可比性。

还要把晴天和强降水分开。一个地区大多数日子没有明显降水，总体表现可能被这些平常日子主导；对于露天作业的人，少数坏天气的遗漏却更重要。

同一概率，可以对应不同动作

出门带伞成本很低；提前关闭一处大型露天场地，影响就大得多。两者面对同一条降水信息，未必应采用同样的触发条件。

因此，使用预报的数据产品需要把天气信息和行动规则接起来：何时提醒、何时复核、何时改变安排。阈值由活动成本和后果决定，不应藏在一句通用的“适合出行”里。

模型提供更及时的输入，组织仍要安排谁看更新、由谁作决定。错过一次已经发布的预报，与模型没有预报到，是两类问题。

留住可以回看的预报

Google 的公告给出了数据访问与独立评测入口。^[6] 对长期使用者来说，保存每次实际收到的版本，会比收藏一张最新天气图更有价值。预报时间、有效时间、变量与单位，都是以后解释结果所需的内容。

Operational WeatherBench 提供了独立比较的入口。^[7] 阅读评测时，先核对它覆盖哪些变量、地区和预测时长，再判断是否接近自己的任务。

天气 AI 的进展值得关注，尤其是它把新观测接入预测的方式。至于一条配送路线、一块农田或一次户外活动能获益多少，则要让预测记录和实际决定在同一张时间表上相遇。灾害预警与公共安全安排，应以当地气象部门发布为准。

最容易造出的题，可能不是最值得学的题

另一面｜合成数据降低了准备成本，真实需求仍然需要自己的入口。

假设一支团队能在一天内造出上万条查询样本。每条请求都有明确编号，工具按约定返回，答案完整。另一位同事只整理出十条投诉，其中几条连问题该怎么描述都不清楚。

从数据数量看，前者进展快得多。但如果上线后的主要工作恰好是处理投诉，后者可能更接近团队真正需要解决的困难。

ToolGrad 论文讨论的是降低工具使用数据生成成本，并通过实验检验这类数据的训练效果。^[2] 将它用于具体业务时，还需有人决定采样范围。自动生成解决了题目怎样批量形成的问题，题库应该覆盖什么仍是一项产品选择。

从现有工具倒推，容易留下现有流程的形状

假设系统有三个方便调用的接口：查订单、查物流、关闭工单。围绕它们出题，容易形成一条完整路径。客户真正想问的却可能是“为什么这次总被转来转去”，而现有接口根本没有记录转接原因。

模型把三个工具都用对，也无法补上系统没有收集的信息。若评估只围绕已具备的接口，团队可能以为任务已经完成，客户的原问题却还在那里。

这时有用的改进可能是增加一个字段、改变交接流程，或者让某一类问题直接交给有权处理的人。继续生成更多同结构样本，未必会暴露这个缺口。

“不继续做”也需要合适的示范

一笔已经取消的订单，可以作为正常训练材料：查到取消状态，解释原因，保留记录。它没有产生新订单，却完成了用户需要的确认。

作者仓库包含负样本处理流程。^[3] 具体业务还需要定义自己的停止条件，并给这些样本足够清楚的反馈。停止太早，会把本来能完成的工作退回给人；停止太晚，则可能产生额外对象。两种错误都应被看见。

只从成功路径抽取数据时，可以另设一个需求入口，收集那些找不到路径的请求。它们不必立即进入训练，却可以帮助决定下一轮需要增加什么工具、资料或规则。

成本降低之后，谁得到好处

Bill Gates 在八月的文章中强调，AI 能力改善与收益如何分配需要同时讨论，并提出保留部分人类工作领域的主张。^[8] 这是他的政策与社会判断，并非一份工具调用实验得出的结论。

在团队内部，这个问题也可以落得很小：生成答案更快以后，客户是否少等了一会儿？工作人员是否减少了重复录入？还是只是检查更多机器生成的材料？

若节省时间主要发生在第一步，后续人员却要处理更多错误，部门自己的效率报表可能很好看，整条服务并没有更轻松。把等待、修正和交接一起记录，才知道收益停在哪个环节。

便宜的教材很有价值。让真实需求持续进入题库，则能避免团队只把模型训练成现有流程的熟练操作员。

继续读之前，先看清日期与版本

快讯与追踪｜本期以研究回看为主，这三个入口适合接着核查。

ToolGrad：介绍日期与论文日期分开读

九月十日是研究博客的发布日期；论文初稿在 2025 年八月，第三版在 2026 年六月。^[2] 顺着论文版本看，可以避免把重新介绍当成刚刚完成的实验。

BFCL：复现说明与现在的榜单不是同一页

ToolGrad 仓库的复现部分指向 BFCL V1 与 V2；BFCL 官网目前展示 V4，并说明了多轮及智能体评估的演进。^[3][4] 比较分数之前，先对齐评测版本、模型版本与设置。本期没有据此排列九月最新模型的名次。

天气预测：留一份当时能看到的数据

看本期科技纵深时，可以顺着来源进入天气数据与评测入口。若准备做自己的比较，先固定每天保存预报的时刻；只看不断刷新的最新结果，很难知道昨天作决定时模型究竟说了什么。

想直接动手，可从十二笔模拟订单开始。它先检查工具说明和业务规则，之后才讨论训练投入，适合用来判断一项需求究竟缺模型能力，还是缺一份清楚的答案。