同一个问题，三个不同的切面
过去两年，智能体工程里最常被抱怨的能力短板是「工具调用不准」。模型明明有工具可用，却选错工具、漏掉前置步骤、或者拿到结果之后不知道下一步该干什么。围绕这个短板，行业先后的解法大多集中在两处：把模型换得更大，或者把提示词写得更细。
但近期出现的三篇研究提示了另一条路：工具调用其实是一条可以被切开处理的链。链的起点是训练数据——模型见没见过足够复杂的工具调用样本；链的中段是执行前的清单——面对成千上万个接口，到底把哪些工具、以什么顺序摆到模型面前；链的终点是过程审计——任务跑完之后，能不能说清楚它为什么成功或失败。三篇研究各自只动其中一段，而且都不改变模型本身。
需要先说明边界。三篇论文的评测都在公开基准上完成，实验环境与真实生产系统仍有差距；论文作者也大多把结论限定在自己的实验设置内，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。本文只讨论它们已经公开的方法与数据。
一段：把造数据的顺序倒过来
训练模型调用工具，需要大量「用户请求—工具调用链—最终回答」的三元组。传统做法是先编一个像样的用户请求，再让一个搜索型智能体去尝试找到能满足这个请求的工具路径。这个流程有个天然缺陷：搜索可能失败。一旦走进死胡同，此前消耗的算力就白费了，样本也只能丢弃。
Google Research 与东京大学、日本理化学研究所、东北大学的研究者提出的 ToolGrad，把顺序倒了过来。它先去实际执行 API，构造出一条已经被验证可用的工具调用链，然后再让模型为这条链写一个匹配的用户请求。作者把这种思路叫做「答案先行」。
之所以可行，是因为一条已经跑通的调用链比一个假想的请求信息量更大，也更没有歧义——从链到请求只需要一次模型调用，而不需要一次开放式搜索。整个框架由四个模块循环构成：提议模块从采样到的接口里挑出几个可能扩展当前流程的候选；执行模块并行测试这些候选并生成执行报告；选择模块审阅报告，挑出表现最好的一次调用追加到流程里，它给出的方向性反馈就是所谓的「文本梯度」；更新模块则重写合成请求与回答，让它们与新扩展的接口集合对齐。默认配置下，一条流程跑十轮迭代，每轮采样五十个接口。
作者在 ToolBench 的接口库上做了对比，该库包含一万六千多个真实 API。结果显示，生成通过率从传统方法的 63.8% 提升到 99.8%；每个样本包含的真实工具调用数从 2.1 提升到 3.4，说明链更长；而完成一个样本所消耗的工具调用步数反而从 34.3 降到 20.0。模型的调用次数基本持平，从 64.5 微降到 63.9——也就是说，这项工作的主要贡献不是少花模型调用，而是把预算花在了更可能成功的地方。那 0.2% 的失败来自三轮选中接口在十次迭代内都没能返回成功响应，最终保存为空样本。
更有意思的是下游效果。研究者用 Gemini 2.5 Flash-Lite 生成了仅五百条样本的 ToolGrad-500，再用它去后训练 Gemma-3 的 10 亿、40 亿与 120 亿参数版本。在伯克利函数调用排行榜上，该榜单使用的工具集与 ToolBench 不同，属于带未见工具的分布外测试。结果是每个参数规模都有提升，其中 120 亿版本拿到 83.1 分，与 Gemini 2.5 Pro 的 83.2 分几乎持平，高于 Claude 4.5 Opus 的 82.8 分与 GPT-5 的 74.4 分，也超过了生成它训练数据的教师模型本身。代码以 Apache 2.0 许可开放，数据集与三个模型都已托管在模型社区，并提供了包管理器安装方式，复现脚本在单张 A100 40GB 上验证通过。
另一段：执行前把「菜单」排对
工具调用的第二段发生在推理时。当接口库有几千个方法，不可能把所有定义都塞进上下文，于是系统会先挑一个短清单给模型看，模型只能调用清单里的工具。这个短清单，论文把它叫做「工具菜单」。
问题在于，现有的菜单构造方式大多按「与请求的相关性」排序。这对单步任务没问题，但对多步任务会出事：一个任务的最终动作往往很容易匹配请求，而真正制造最终动作所需输入的前置工具，反而因为字面上不相关被排在后面甚至被漏掉。模型于是看得见终点，看不见通往终点的路。
中佛罗里达大学与罗切斯特大学的研究者提出的 State-Path Tool Menu，把菜单理解为「执行先验」——不是按相关性排，而是按一条从当前可观测状态通往目标结果的执行路径来排。它的编码器负责表达哪些工具能从当前状态运行、它们的输出如何满足后续输入、以及哪些顺序在训练路径里反复出现；检索器负责覆盖一个可执行的入口、缺失输入的生成工具以及最终动作；重排序器则把生成者排在消费者前面。
在 ToolBench 上，只更换菜单、不改动智能体本体，在线成功率从 0.737 提升到 0.898，多解出四十九个任务。论文里一个对比很能说明问题：用三十二个工具的状态路径菜单，覆盖链条的完整度优于官方列表用一百二十八个工具的效果。增益在不同执行器家族之间也保持为正，三个执行器分别获得 16.1、12.8 与 6.9 个百分点的提升。作者还把在 ToolBench 上学到的关系权重原封不动迁移到另一个基准的两千个困难任务上，未使用目标库的轨迹或标签，三项指标仍有小幅提升，其中入口工具的覆盖率提升最明显，说明不同工具库之间存在对「可执行入口」的共同理解。
论文也写清了局限。它固定在执行前选好一份菜单，还没有做到根据执行中的观测动态更新；构造器依赖输入输出字段足够有信息量，也依赖路径关系在训练中反复出现，因此在稀疏或文档不足的工具库里会逐步退化。作者还在伦理声明里提醒，让路径更可见这件事本身是双刃的——如果请求或工具库本身不安全，更清晰的路径也会让有害的工具序列更容易被执行，所以实际部署需要权限校验、沙箱执行，以及对高影响动作的人工复核。
第三段：跑完之后怎么审
工具调用的第三段发生在任务结束之后。现有的科学智能体评测大多只看最终产物——生成的代码、提出的假设、写出的论文。这种只看结果的方式有个盲区：它无法区分「有方法地推理」与「碰巧猜对」，也无法诊断失败到底出在哪一步。
OpenDiscoveryTrace 想补的就是这个盲区。它由 Aayam Bansal 与 Keertan Balaji 完成，发布在预印本平台，并获得 ICML 2026 科学智能体方向工作坊的最佳数据集奖。数据集收录了 558 条完整的科学智能体推理轨迹，每条轨迹的每一步都按九个结构化字段记录，包括思考、工具调用、观测、错误、修订触发以及模型自报的置信度。任务共 124 项，覆盖药物发现、材料科学、基因组学与科学文献分析。
样本构成是刻意平衡的。三个前沿模型各贡献 124 条轨迹，覆盖全部领域与难度；四个开放权重模型各贡献 30 条；此外还有 60 条带实时检索的变体轨迹。基于 363 条由模型评判的轨迹所做的初步分析，给出了一个只看结果永远看不到的对比：三个前沿模型的成功率其实相当接近，都在 84% 到 89% 之间；但错误数量差异巨大——其中一个模型平均每条轨迹产生 2.5 个错误，另一个只有 0.08 个，统计检验的效应量达到 0.613。错误类型也截然不同：错误多的那个模型有 66.7% 的错误属于工具误用，而错误少的那个模型有 83.6% 的错误属于推理错误。
这个发现的意义不在于排名。它说明两件事。其一，成功率相近的模型，其失败方式可能完全不同，而对失败方式的了解直接决定了该往哪里投入改进资源——是修工具调用，还是修推理。其二，模型自报的置信度一旦被逐步骤记录下来，就可以被检验：它是在错误发生前升高，还是真的跟正确答案同步。作者也坦率说明，模型评判这一方法本身带有已知偏差，因此这批分析应当被当作初步结果来看。
数据集、轨迹模式、智能体执行框架与五项基准任务均以开放许可发布，基准还给出了逻辑回归、随机森林、长短期记忆网络与 Transformer 四类基线。对任何在自建智能体上做可观测性的人来说，这套九字段的轨迹结构本身就有参考价值：如果日志里同时记录了思考、调用、观测、错误与置信度，出问题时就已经具备了定位所需的信息。
三段合起来看意味着什么
把三篇研究放在一起，能看到一条清晰的分工线。ToolGrad 处理的是「模型见过什么」——它不改变推理时的任何逻辑，只让训练样本更容易通过验证、链更长、预算更集中在成功路径上。State-Path 处理的是「模型看到什么」——它不改变模型能力，只改变执行前呈现给模型的工具顺序。OpenDiscoveryTrace 处理的是「我们事后知道什么」——它不参与执行，只让过程变得可审计。
三者都不需要换模型，这本身是一个值得注意的信号。它说明在当下的能力水平上，工具调用的可靠性提升有相当一部分并不来自模型本身，而来自数据、上下文组织与可观测性这三层工程。这也与近期的其他研究相呼应：已经有工作表明，让子任务在独立的上下文窗口里隔离求解，比把技能包直接注入主上下文更稳；也有工作指出，智能体对工具输出存在系统性过度信任，会采纳被污染的结果。这些结论指向同一个方向——工具这条链上的每一段，都还有独立的优化空间。
中立思辨
需要辩证看待几件事。其一，三篇论文的结论都建立在公开基准上，而公开基准与真实生产环境的差距是已知的：真实接口的文档质量参差、权限与配额限制复杂、失败模式更分散，基准上的增益能否等比迁移到生产，尚无公开的对照实验。其二，ToolGrad 的通过率数字很漂亮，但作者自己也指出模型调用次数几乎没有下降，意味着成本优势主要来自「少浪费」而不是「少调用」，对预算极度敏感的团队，收益可能没有想象中大。其三，State-Path 固定一份菜单的做法在多步任务上有效，但真实任务的状态会随执行变化，静态菜单在长流程中后期可能失效，论文也把动态更新列为未来工作。其四，OpenDiscoveryTrace 的初步分析依赖模型评判，而模型评判对错误类型的分类准确度本身需要验证，因此错误比例的绝对值应当谨慎引用，其相对差异的结论更可信。其五，把过程全部记录下来会带来存储与隐私成本，尤其是当轨迹里包含工具返回的真实业务数据时，日志本身可能成为新的合规负担。其六，三段优化各自有效，但组合起来是否叠加、是否存在相互抵消，目前没有研究给出答案，团队在同时采用时需要自行做消融验证。
趋势研判
短期看，这三条线会分别落地：造数据的方法会先被做垂直领域微调的团队采用，因为它直接降低了自建工具调用能力的门槛；菜单排序会被做企业级智能体的平台采用，因为它是纯推理期的改动、不需要重训练；过程审计则会被监管敏感行业先采纳，因为那里的合规要求本就要求可追溯。中期看，三者可能收敛成一套标准的工具调用工程流水线：用合成数据补齐能力，用状态路径组织上下文，用轨迹数据集验证可靠性。长期看，真正的问题可能不在工具调用本身，而在「谁来定义工具调用的正确性」——如果每个团队都用自己的轨迹集来验证自己的智能体，行业就缺少可比的标准，而这恰恰是过程级评测想要解决却尚未解决的问题。
对开发者来说，一个务实的起点是把工具调用失败的原因分类统计。到底是没看到该用的工具、看到了但顺序不对、调用了但结果被误读，还是根本不该调用。这四类失败的修法完全不同，而在动手之前先分清楚，比直接换一个更大的模型要省得多。