← 返回 PaperDaily 大模型与智能体

OOD准确率最高涨9点！北航ToolLIFT：让LLM换套工具照样干活

ToolLIFT把“具体工具”抽象成“功能角色”，让LLM在没有见过的新工具集上也能规划出像样的工作流。OOD基准上最高涨近9个点，泛化能力肉眼可见，工具规划方向的小伙伴值得一读。

龙哥读论文发布于 2026-09-03 00:20:03 阅读 4 查看原文

#Agent #大语言模型 #强化学习 #人工智能

原论文信息如下：

论文标题:
ToolLIFT: Lifting Tool-Specific Trajectories into Function-Level Graphs for Generalizable Tool Planning 发表日期:
2026年08月论文作者:
Xiuhui You, Jiayi Luo, Zichao Shen, Qingyun Sun, Ziwei Zhang 发表单位:
School of Computer Science and Engineering, Beihang University 原文链接:
https://arxiv.org/pdf/2608.03468v1.pdf

先来想一个场景：公司换了一批新软件，你之前用旧软件积累的所有操作经验瞬间作废，是不是有点崩溃？大语言模型（LLM，Large Language Model）智能体也面临同样的问题——它明明学会了怎么调用各种工具完成任务，可一旦工具库换了，之前学的“协作套路”就全白搭了。有没有一种办法，让LLM智能体在工具全换了的情况下，还能把过去学到的工作流经验迁移过来？这正是北京航空航天大学团队这篇ToolLIFT论文要解决的核心问题。

图1：使用不同工具集实例化的工具使用轨迹可以共享功能级工作流结构：尽管具体工具不同，它们的功能角色和关系遵循相同的模式。

一个关键洞察：工具不同，功能相同

论文先抛出一个非常反常识的观察：类比任务虽然使用的具体工具不同，但功能级的工作流结构往往高度相似。举个例子，无论是用Python的requests库抓网页，还是用浏览器自动化工具Selenium获取页面内容，本质上都是在做“发起请求—解析响应—提取信息”这一套流程。工具变了，角色没变。

现有方法把历史轨迹直接建成“工具级图”——每个节点是一个具体工具API，边是工具间的转移关系。这种图看起来直观，但有一个致命问题：它把所有协作经验都绑定在了具体工具的身份上。一旦遇到新工具集，旧图里的节点全部失效，经验就断了。更麻烦的是，历史轨迹中那些少用的工具在图上只有稀疏连接，泛化能力极差。

ToolLIFT的出发点很简单：把“工具”升维成“功能”，把“工具转移”抽象成“功能转移”。具体工具千变万化，但功能角色和它们之间的搭配模式是可迁移的。这个思路带来的收益非常直接：哪怕某个工具在历史轨迹里一次都没出现过，只要它能映射到一个已知的功能簇，就能继承该功能簇积累的协作经验。

三大挑战：从图构建到跨集泛化

论文将基于图的工具规划问题拆成三个必须攻克的难点，每个都切中现有方法的命门。

难点一：经验如何跨越工具集迁移？历史轨迹里出现过的工具构建出来的工具级图，遇到新工具基本歇菜。论文指出，解决思路是把协作经验提升到功能层面，让新工具通过功能映射继承历史经验。

难点二：选择具体工具时如何保持全局视野？传统的逐步规划方法走一步看一步，很容易陷入局部最优——前面选的工具从局部看没问题，但放到整个工作流里可能是死路。ToolLIFT认为，应该先确定工作流骨架，再做工具实例化，让全局结构约束局部选择。

难点三：参数级数据流如何保持可靠？工具调用最让人头疼的就是参数来源。上下文越来越长，中间工具输出堆积如山，LLM很容易把参数来源搞混，出现幻觉，引用了一个根本不存在的输出。论文指出现有强化学习（Reinforcement Learning, RL）方法没有直接监督参数来源的正确性，因此提出新的奖励机制专门解决这个问题。

ToolLIFT如何将轨迹“提升”为功能级工作流图

ToolLIFT的整体框架分为三大模块，对应图2中的三个子图。下面把这个框架拆开来看。

图2：ToolLIFT总览。(a) 将工具特定轨迹提升为功能级工作流图（FWG），捕获跨工具集共享的功能级协作结构。(b) 在FWG的全局结构上进行功能级工作流规划，并在约束下实例化具体工具，保持个体工具选择与整体工作流一致。(c) 显式分配参数来源以实现源可追溯的数据流，并通过源门控和技能特定奖励联合优化参数填充与源追踪。

第一步要回答的问题是：怎么把一堆具体工具塞进“功能”这个筐里？论文用了一个很务实的技术方案：把工具描述拆分成功功能和领域两部分，只用功能描述做聚类，避免领域信息干扰功能分组。具体来说，用大语言模型把每个工具的模式（schema，即工具的接口描述文档）分解为功能描述和领域描述，然后只依据功能描述做表征和聚类。

在技术细节上，先将功能描述用BGE-M3嵌入成向量，再用UMAP降维，最后用K-means聚类。聚类数量L通过轮廓系数（silhouette coefficient）自动选择，兼顾簇内凝聚度和簇间分离度。这样得到的映射函数φ就能把任意工具映射到某个功能簇。

图8：工具功能聚类的可视化。每个点代表一个工具，根据K-Means分配着色（L=30）。标注了三个代表性功能簇及示例工具。

有了工具到功能的映射φ之后，接下来把历史轨迹中工具级的转移关系统计成功能级转移。对每一条历史轨迹，将其中的每个工具替换成对应的功能簇，然后统计相邻功能簇之间的转移频次。形式化地，定义功能簇c到c'的转移计数为：

$公式1：功能转移计数公式 n(c, c') = Σ_{m=1}^{M} Σ_{k=1}^{K_m-1} 1[c_k^(m)=c, c_{k+1}^(m)=c']，其中1[·]为指示函数。$

公式1：功能转移计数公式 n(c, c') = Σ₁ᵐΣₖ 1[cₖ=c, cₖ₊₁=c']，其中1[·]为指示函数。

接着，把计数归一化成转移概率权重：

$公式2：边权重公式 w(c, c') = n(c, c') / Σ_{c''∈C} n(c, c'')，即从功能簇c转移到c'的归一化概率。$

公式2：边权重公式 w(c, c') = n(c, c') / Σ_{c''∈C} n(c, c'')，即从功能簇c转移到c'的归一化概率。

于是，功能级工作流图（FWG）的定义就很清晰了：节点是功能簇集合C，边是有正向转移计数的功能簇对，边上带权重w。这个图本质上就是一个加权的功能转移图，它把分散在成千上万条轨迹里的协作模式凝练成了一张“流程经验地图”。

$公式3：FWG定义 G_fwg = (C, E, w)，其中 E = {(c, c') : n(c→c') > 0}。$

公式3：FWG定义 G_fwg = (C, E, w)，其中 E = {(c, c') : n(c→c') > 0}。

这个构建过程有个容易被忽略的巧妙点：由于功能簇是跨工具集共享的，任何一个训练工具对（concrete tool pair）的转移经验都会贡献到功能级转移统计中。也就是说，每个工具都能从所有同功能工具身上“借”到协作经验，这比工具级图的信息利用效率高了一个量级。

解耦规划与选择：先定流程，再选工具

拿到FWG之后，怎么用它来规划工具调用？ToolLIFT的核心思想是做“解耦”——把规划拆成两个阶段：先规划功能级工作流，再为每个功能选择具体工具。

阶段一：工作流规划。模型根据用户查询q，在FWG上生成一条功能序列——也就是要走哪些功能节点才能完成任务。这一步完全不需要关心具体工具是谁，只看功能层级的“骨架”。规划过程用GRPO（Group Relative Policy Optimization，分组相对策略优化）训练，奖励函数综合考虑了格式正确性R_fmt^(1)和功能级正确性R_func^(1)。功能级正确性采用改进的Jaccard指标（Modified Jaccard, MJ）来衡量预测的功能工作流与参考工作流之间的重合度：

公式4：改进的Jaccard指标 MJ(Ŵ_c, W*_c) = I(Ŵ_c, W*_c) / (|Ŵ_c| + |W*_c| - I(Ŵ_c, W*_c))，其中I(·,·)表示交集大小。

公式5：功能级奖励 R_func^(1) = 2ρ·(MJ(Ŵ_c, W*_c) + I(Ŵ_c, W*_c)) / (1 + |W*_c|) - ρ，其中ρ为奖励缩放系数。

阶段二：工具选择。工作流骨架已经定好，接下来要为每个功能节点选一个具体可用的工具。约束很明确：所选工具必须属于功能映射φ反推出来的候选集合，且其输入输出参数要能衔接上下游功能的需求。通过这种方式，个体工具选择始终受到全局工作流的约束，不会出现“局部合理、整体崩盘”的情况。

传统的“逐步贪心搜索”方法之所以在复杂任务上容易翻车，就是因为每一步只看当前局部状态，没有全局视角。而ToolLIFT的两阶段设计等于先给模型一张“地图”，再让它决定具体“怎么走”——全局规划先行，局部选择后置，这正好对应了解耦的价值。

用强化学习锁定参数来源，减少幻觉

工具规划还有一个特别折磨人的问题：参数到底从哪来？LLM在长上下文里调用工具时，经常会“编造”一个根本不存在的中间变量作为参数值，或者把前面某个工具的输出错当成另一个工具的输出。论文把这个问题称为“源追溯”（source tracing），并且用强化学习来专门解决。

具体做法是让模型在生成工具调用时，对每个参数显式标注来源：要么是“查询上下文直接提供”，要么是“引用前序第j个工具调用的输出”。这个设计把隐式的参数依赖变成了显式的预测目标，模型必须明确回答“这个值是哪来的”。训练时用两阶段GRPO：阶段一训练工作流规划，阶段二训练工具调用生成。

在奖励设计上，论文提出了一个很有意思的“源门控+技能特定”奖励机制。首先判断参数来源类型是否正确（这就是“源门控”，source-gated），只有来源类型正确后才进一步计算参数值匹配的奖励。奖励函数R_corr^(2)由参数匹配奖励r_match和价值正确性奖励r_value加权组合而成：

公式6：参数正确性奖励 R_corr^(2) = 2ρ·(λ_match·r_match + λ_value·r_value) / S_max - ρ，其中λ_match和λ_value分别是匹配和值的权重系数。

另外，论文还给不同的工具调用技能设置了不同的奖励系数——这就是“技能特定”（skill-specific）的含义。搜索类工具、计算类工具、数据操作类工具，它们的参数敏感度不同，奖励权重也应当不同。整体奖励为格式奖励与内容奖励之和：

公式7：总奖励定义 R^(1) = R_fmt^(1) + R_func^(1)，R^(2) = R_fmt^(2) + R_corr^(2)。

这里要特别提一下GRPO的技术细节。GRPO和PPO（Proximal Policy Optimization，近端策略优化）相比的一大优势是不需要额外的价值网络（critic model），而是通过组内相对比较来估计优势值。具体来说，对于每个查询生成一组候选响应，奖励经过KL散度（Kullback-Leibler divergence，用于衡量两个概率分布差异的指标）惩罚项修正后，在组内做标准化，得到每个响应的优势值：

$公式8：经过KL惩罚修正后的奖励 R̃_i^s = R_i^s - β·Σ_t (log π_θ_old(y_{i,t}) - log π_ref(y_{i,t}))。$

公式8：经过KL惩罚修正后的奖励 R̃_i^s = R_i^s - β·Σ_t (log π_θ_old(y_{i,t}) - log π_ref(y_{i,t}))。

公式9：优势估计 Â_i^s = (R̃_i^s - mean_j(R̃_j^s)) / (std_j(R̃_j^s) + ε_a)，即组内标准化。

这种设计在资源受限场景下特别友好，因为它省掉了价值网络的参数量和训练开销。

实验结果与思考：OOD泛化优势显著

实验设置方面，论文使用了两个同分布（ID，In-Distribution）基准和三个分布外（OOD，Out-of-Distribution）基准。同分布基准是HuggingFace和Multimedia，OOD基准则包括DailyLifeAPIs、Seal-Tools和ToolAlpaca。训练数据使用APIGen和ToolACE两个数据集。

表4：两个训练数据集的统计信息。

表5：预处理后的评估集大小。

表1给出了ToolLIFT与多个基线方法的对比结果。可以看出，ToolLIFT在两个ID基准和三个OOD基准上都取得了最好成绩，而且在OOD基准上的领先幅度明显大于ID基准。这表明功能级工作流抽象确实提升了跨工具集的泛化能力。

表1：ID和OOD基准上的工具规划性能。最佳结果加粗，次佳结果加下划线。

参数来源追踪的效果可以用SER（Source Error Rate，源错误率）来衡量。SER计算的是参数来源标注错误的比率——就是模型声称“这个参数来自第j个工具的输出”，但实际上错了的比例。表2展示了不同方法在五个基准上的SER对比，ToolLIFT在几乎所有基准上都有最低的SER。这说明显式的源标注和源门控奖励确实起了作用。

表2：五个基准上的源错误率（SER，越低越好）。HF、MM、Daily、Seal和TA分别表示HuggingFace、Multimedia、DailyLifeAPIs、Seal-Tools和ToolAlpaca。

模型的目标函数是准确率和F1指标。其中n-F1（名称F1）评估工具名称预测的准确性，l-F1（标签F1）评估参数标签预测的准确性，都是基于集合匹配的F1变体。

公式10：名称F1 n-F1_i = 2|N̂_i ∩ N_i| / (|N̂_i| + |N_i|)，衡量预测工具名称与真实工具名称的集合相似度。

公式11：标签F1 l-F1_i = 2|L̂_i ∩ L_i| / (|L̂_i| + |L_i|)，衡量预测参数标签与真实参数标签的集合相似度。

$公式12：源错误率 SER = Σ_{a∈A} 1[srĉ(a) ≠ src(a)] / |A|，即参数源标注错误的比率。$

公式12：源错误率 SER = Σ_{a∈A} 1[srĉ(a) ≠ src(a)] / |A|，即参数源标注错误的比率。

消融实验（表3）进一步确认了每个模块的必要性。去掉功能级图改用工具级图后，OOD性能明显下降；去掉两阶段解耦改回端到端生成后，长工具链上的准确率显著下滑；去掉源门控奖励后，SER攀升。这些消融结果很有说服力——每个设计都有存在的理由。

表3：在HuggingFace（HF）和DailyLifeAPIs（Daily）上的消融实验结果。

有趣的是，论文还分析了工具使用频率对性能的影响（图3）。在HuggingFace和Multimedia上，把历史轨迹中的工具按使用频率分组，可以看到ToolLIFT在低频工具上的表现明显优于工具级图方法。这是因为功能级共享让低频工具也“继承”了同功能高频工具的协作经验——低频工具的样本稀疏问题被功能聚类的信息共享有效缓解了。

图3：HuggingFace和Multimedia上不同历史工具使用频率的性能表现。

(a) HuggingFace (c) Multimedia上的表现对比。

(b) HuggingFace (d) Multimedia上的表现对比。

工具链长度的影响也很值得关注（图4）。在Multimedia和DailyLifeAPIs上，按工具调用序列长度分组统计准确率，发现ToolLIFT在长工具链场景下的性能衰减明显更慢。这说明全局工作流规划和显式源追踪在长序列场景中的优势会进一步放大——因为步骤越多，局部贪心决策的错误累积越严重，参数来源的混淆风险也越高。

图4：Multimedia（ID）和DailyLifeAPIs（OOD）上按工具链长度的准确率表现。

聚类数量L是FWG构建中唯一需要人为设定的超参数。图5展示了不同L取值下的平均准确率变化，可以看到在L=30附近性能达到峰值，并且在一定范围内（约20到45）性能都比较稳定，说明方法对聚类数量不是特别敏感。图6和图7则展示了工作流扰动概率epsilon_pert的敏感性分析。这个扰动是在训练时以一定概率故意打乱工作流序列，用来增强模型的鲁棒性。结果显示在0.1到0.3之间性能最佳，过大或过小都会带来负面影响。

图5：ID和OOD基准上不同功能簇数量（L）下的平均准确率。

图6：DailyLifeAPIs上对工作流扰动概率epsilon_pert的敏感性分析。

图7：Multimedia上对工作流扰动概率epsilon_pert的敏感性分析。

GRPO训练的奖励曲线也值得一看（图9和图10）。阶段一的奖励曲线在几千步内稳定上升并收敛，阶段二的奖励曲线同样平滑。这说明论文设计的规则奖励在GRPO框架下确实可以稳定优化，没有出现奖励黑客（reward hacking）或剧烈震荡的问题。

图9：阶段一工作流规划的GRPO奖励曲线。

图10：阶段二工具调用生成的GRPO奖励曲线。

论文还提供了成功和失败案例的分析。成功案例中，ToolLIFT生成的功能级工作流和候选工具映射清晰，工具调用计划顺序正确、参数引用无误。而失败案例主要集中在功能映射不准确或参数来源判断错误的场景。这些案例为后续改进指出了明确的方向。

表10：成功案例中候选工具及其对应的FWG功能。

表11：成功案例中ToolLIFT和ToolRL生成工具调用计划的对比。直接参数按语义内容缩写，而out: (p_j)表示对调用p_j输出的引用。

表12：失败案例中候选工具及其对应的FWG功能。

表13：失败案例中ToolLIFT生成的工具调用计划。

综合来看，这篇论文的实验设计相当扎实。在OOD基准上的领先优势非常突出，充分验证了功能级抽象对于跨工具集泛化的价值。不过也要客观指出，在ID基准上ToolLIFT的提升幅度相对温和，这说明在熟悉的工具集上，工具级经验可能已经比较充分，功能级抽象带来的额外增益有限。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底在解决什么问题？北航提出ToolLIFT，将工具使用轨迹提升为功能级工作流图，让LLM智能体跨未见工具集也能可靠规划。在两个分布内及三个分布外基准上全面超越现有方法，OOD准确率最高提升近9个百…

这篇工作最值得看的点是什么？在ID基准上取得最高Acc，以Llama为骨干在HuggingFace和Multimedia上分别较最强基线提升1.37和1.50个百分点；在OOD基准上优势更明显，以Llama为骨干在DailyLifeAPIs、Seal-Tools、T…

这篇工作的边界或风险在哪里？优点：1）功能级工作流图的抽象思想新颖，有效解决了工具级图难以跨工具集泛化的关键问题；2）解耦工作流规划与工具选择的设计合理，使单个工具选择受全局工作流的约束；3）显式建模参数级别的数据流，配合源门控奖励，有效降低了参数来源错误率；4）实…

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

把工具级图抽象提升到功能级工作流图，角度新颖且直击痛点；解耦规划与源门控奖励也有独到之处，但整体仍建立在现有图规划和RL框架之上。

实验合理度：★★★★☆

五个基准涵盖ID和OOD，消融完整，还有频率、长度、超参敏感性分析，非常全面。遗憾是未报告不同随机种子下的方差，某些基线的实现细节也不够清晰。

学术研究价值：★★★★☆

这个工作为“经验跨工具集迁移”提供了一个可靠的新范式，功能级抽象的思路能启发后续的工具规划、甚至机器人技能迁移等方向的研究。

稳定性：★★★☆☆

依赖LLM做功能描述分解，如果工具描述质量参差不齐，聚类结果可能不稳定。不过论文对聚类数量和扰动概率的敏感性分析显示在一定范围内还算健壮。

适应性以及泛化能力：★★★★☆

OOD基准上的表现充分证明了跨工具集泛化能力；但目前只验证了API调用类工具，对多模态工具或物理世界工具（如机器人操作）的适应性还有待验证。

硬件需求及成本：★★★☆☆

需要两步GRPO训练（工作流规划和工具调用生成），训练成本不低；但推理阶段只需一次前向生成，UMAP和K-means只是离线预处理，整体推理开销相对可控。

复现难度：★★★☆☆

论文提供了较详细的配置表，但代码和训练数据尚未看到开源链接；功能聚类、GRPO训练细节有一定工程门槛，复现需要花时间。

产品化成熟度：★★★☆☆

在API服务编排、企业工作流自动化等场景有落地潜力，但功能簇的质量控制、增量更新机制、工业级API描述的噪声处理等问题还需要工程化打磨。

可能的问题：

ID基准上增益有限，功能抽象对已熟悉的工具集可能反而丢失了工具级细粒度经验；LLM做功能描述分解的成本和误差没有详细分析；未讨论FWG的动态更新策略。

主要参考文献

[1] ToolLIFT: Lifting Tool-Specific Trajectories into Function-Level Graphs for Generalizable Tool Planning. arXiv:2608.03468.

[2] Shao et al. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. 2024.

[3] Zhang et al. ToolExpNet: Experience-Driven Tool Planning with Graph Neural Networks. 2025.

[4] Qian et al. ToolRL: Reward Decomposition for Tool-Calling Reinforcement Learning. 2025.

[5] Chen et al. BGE-M3: Embedding Models for Multi-Granularity Retrieval. 2024.

[6] Healy & McInnes. UMAP: Uniform Manifold Approximation and Projection. 2024.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！

想让你的智能体也学会“换汤不换药”？来龙哥读论文粉丝群，一起研究LLM工具规划、Agent记忆、强化学习这些硬核话题。扫描下方二维码或添加龙哥助手微信号加群：kangjinlonghelper，备注：研究方向+地点+学校/公司+昵称，更快通过哦～
wechat_helper