香港科技大学出手：只用85个"训练场"，AI工具调用能力提升15%的秘密

这项由香港科技大学（广州）LARK实验室联合华威科技公司、剑桥大学、伦敦大学学院共同完成的研究，以预印本形式发表于2026年5月，论文编号为arXiv:2605.18703v1。感兴趣的读者可通过该编号在arXiv平台查阅完整论文。

一、AI"工具达人"的养成困境

现在的AI助手越来越能干——它们不只是回答问题，还能帮你订机票、查股票、发邮件、管日程。这种"调用外部工具"的能力，让AI从一个会聊天的玩伴，变成了能办事的助理。

但要训练出这样一个"工具达人"AI，其实比看起来难多了。

打个比方：你要培训一个新员工，让他学会操作公司的各种业务系统。最好的办法当然是让他在真实的系统里反复练习——犯错、纠正、再试。这种"在实战中学习"的训练方式，在AI领域叫做"智能体强化学习"（Agentic RL）。

问题是，这种训练方式有两个绕不开的拦路虎。

第一个拦路虎是"训练场地"太难建。你需要给AI搭建一个能真实运行的练习环境——里面有各种可以调用的工具，工具调用后还会影响系统状态（比如下单之后库存会减少）。现有的解决办法要么成本极高，比如直接连接真实的商业API，网络一抖动训练就乱套；要么用另一个AI来"模拟"工具行为，但AI本身会产生幻觉，给出错误的反馈，让被训练的AI学错东西；要么用程序模拟工具，但已有方案要么只能处理"无状态"的简单操作，要么依赖提前收集好的文档资料，扩展性很差。

第二个拦路虎是"训练数据"太假。即便有了训练环境，还需要大量"用户与AI对话"的样本数据。已有数据集的一个通病是：生成的"用户请求"太过详细，就像一份说明书，把每个步骤都写清楚了，比如"请先查询北京的目的地ID，再用这个ID查询酒店列表，然后……"。真实用户才不会这么说话！真实用户只会说"帮我找找北京有什么好酒店"，剩下的需要AI自己去推断。这种"过于规范化"的训练数据，让AI学会的是照葫芦画瓢，而不是真正理解人类的意图。

这项研究提出了一个叫做EnvFactory的框架，尝试同时解决这两个问题。

二、搭建"训练工厂"：让AI自己建造练习场

EnvFactory框架的第一大核心组件叫做EnvGen，顾名思义就是"环境生成器"。它的目标是自动化地建造出大量可以运行的工具练习场地。

整个建造过程可以用"装修公司承接新项目"来理解。

第一步是"勘察选址"。一个叫做"搜索智能体"的AI会主动去互联网上探索，寻找真实存在的工具和API——它会翻阅API文档、技术报告、使用示例。与此同时，它还会审视现有的环境清单，判断哪些领域还没有覆盖到，从而决定下一个要建造什么样的练习场。这种"主动探索"的方式，让系统不需要提前准备一本工具说明书，而是像侦探一样自己去发现。

第二步是"绘制蓝图"。找到合适的"地块"后，系统会生成结构化的元数据，包括这个环境有哪些工具、每个工具的功能描述和输入输出规格，相当于装修前画好的户型图。

第三步是"建造数据库"。有了蓝图，另一个叫做"代码智能体"的AI开始动工——它负责设计数据库结构，规定哪些信息需要存储、存储成什么格式。关键在于，这个数据库是"有状态"的，意味着工具的使用会真实地改变数据库内容。比如你调用"预订酒店"工具后，数据库里的房间余量就会减少，下一次查询时会反映出这个变化。这比只能做简单查询的"无状态"工具要真实得多。

第四步是"装修施工"。代码智能体继续工作，把每个工具的具体功能用Python代码实现出来，然后封装成标准化的接口（研究团队采用了Anthropic公司制定的MCP协议作为默认接口格式），让AI助手可以像调用真实服务一样调用这些工具。

第五步也是最关键的一步，叫做"验收检查"。一个"测试智能体"会对刚建好的环境进行全面检测，检查四件事：工具的接口描述和实际行为是否一致；工具能否正常导入和执行；执行结果是否符合预期；工具执行后数据库的状态变化是否正确。一旦发现问题，测试智能体会写出详细的"整改报告"，指出是哪段代码出了问题，并给出修改建议。代码智能体根据报告修改后重新提交，整个过程反复迭代，直到所有检测项目全部通过为止。

这套流程最终建造出了85个涵盖7个领域的可运行工具环境，包括电商、金融、旅行、办公、生活方式、学术研究和通用工具，共包含842个不同的工具。更重要的是，整个过程完全自动化，不需要人工编写一行代码或提供一份文档。

三、绘制"工具地图"：理清工具之间的依赖关系

有了这85个练习场和842个工具，下一步需要搞清楚这些工具之间的关系——有些工具必须在另一些工具执行之后才能用，因为它需要用到前一个工具的输出结果作为输入。

研究团队把这些关系画成了一张"工具依赖图"（Tool Dependency Graph），就像一张城市交通地图，标注了哪些路是单行道，哪些地方必须先经过某个路口才能到达另一个地方。

构建这张地图分两步走。第一步是用数学方法计算"语义相似度"——如果工具A的某个输出参数，和工具B的某个输入参数在语义上非常接近（用一个叫BAAI/bge-m3的文本嵌入模型计算余弦相似度），就在A和B之间画一条箭头，表示"B可能需要A的输出"。这一步效率高，但不够精准。

第二步是用AI来"逻辑审查"。对于每个环境里的工具，系统让一个大语言模型仔细分析工具之间的逻辑关系，补充那些语义上看不出来但逻辑上确实存在的依赖关系，同时删掉那些相似度计算错误添加的多余箭头。比如在Notion笔记环境里，有一个叫delete_all_notes的工具，它不需要任何输入参数，也没有有意义的输出参数，纯粹语义计算会把它孤立在图之外。但逻辑上，它显然应该在"创建笔记"或"获取笔记列表"之后执行才有意义，所以AI审查这一步会手动补上这条逻辑边。

这张工具依赖图是后续生成训练数据的"导航系统"，没有它，就没法知道该给AI设计什么样的合理任务。

四、生成"真实感"数据：拓扑感知采样与查询精炼

工具地图建好之后，接下来的工作是生成训练数据，也就是大量"用户提出请求、AI调用工具解决问题"的对话记录。这个组件叫做QueryGen，核心是两大创新：拓扑感知采样和校准精炼。

先说拓扑感知采样。在工具依赖图上随机游走，挑选一组工具组成一条"任务链"，这个思路听起来简单，实际上有个很大的陷阱。用常见的随机游走方式，很可能挑出一组"无法完成"的工具组合——比如挑了"预订酒店"这个工具，但没有挑选必须先执行的"获取酒店列表"，而"预订酒店"需要用到"酒店ID"这个参数，这个参数只能从"获取酒店列表"的结果里得到。如果直接用这组工具生成训练任务，AI在训练时根本无法完成任务，也就学不到任何有用的东西。

研究团队的解决方案是给采样过程加上"依赖检查"。每次决定把一个工具加进任务链之前，系统会检查这个工具的每一个必填参数：这个参数是用户能直接提供的吗（比如"城市名称"，用户自然知道）？还是必须由某个先前工具的输出结果来提供（比如"酒店ID"，用户不可能知道）？如果是后者，系统会沿着依赖图向前追溯，把那个能产生这个参数的工具也加进任务链。这个追溯过程会递归进行，深度最多三层。另外，为了增加数据的多样性，系统还会以10%的概率主动引入一些"额外的依赖工具"，即便当前参数已经可以被满足，也故意再加一个能提供它的前序工具，制造出更丰富的工具组合模式。

这样采样出来的工具链，每个工具的每个参数都能被满足，保证了生成的训练任务在逻辑上是可完成的。图中展示了一个酒店预订加WhatsApp通知的例子：任务链包含了"搜索目的地"、"获取酒店列表"、"获取酒店详情"、"预订酒店"、"获取WhatsApp联系人"、"取消预订"六个工具，其中目的地ID、酒店ID、房型ID等参数都通过依赖追溯被正确地安排了顺序。

有了工具链，接下来是生成对应的"用户请求"。这分为好几个步骤。首先，系统会根据工具链构造一个用户画像和故事背景，比如"Maya是一名正在安排团队短途旅行的职员，她需要……"。然后，系统把工具链随机切割成若干个对话轮次，每轮包含一到五个工具，对应用户在这一轮可能提出的请求。接下来，系统根据当前数据库状态和对话历史，生成一个初步的用户请求。

但初步生成的请求往往太"机器人"了，会把所有细节都写得清清楚楚，比如"请查找北京的目的地，获取五月十八日到二十日的酒店列表，查看樱花花园酒店的详情，并在WhatsApp里找到我的同事"——这听起来更像是给程序写的操作说明，不像真人说话。

于是研究团队加入了"校准精炼"这个环节，对初步生成的请求做四种变换。第一种是"隐式引用"，把具体的ID或参数替换成上下文引用，比如把"酒店ID H1234"替换成"你刚才找到的那家酒店"，把已经提过的信息省略掉。第二种是"动作压缩"，把逻辑上可以推断的中间步骤合并掉，不明说每一步。第三种是"歧义引入"，加入合理的指代歧义，比如"那个地方"可能指上文提到的多个选项中的某一个，让AI需要通过追问来确认。第四种是"目标扩展"，在主要请求之外加入一两个相关的附加目标，使请求更像真实用户的综合需求。

经过这四步精炼，"帮我规划五月十八日到二十日的京都团队旅行。查找京都目的地，获取那段时间的酒店，查看樱花花园酒店的详情，在WhatsApp上找到我的团队成员"就变成了"我在计划五月十八日到二十日的京都团队旅行。你能帮我比较一下可以住的地方，进一步了解一下樱花花园酒店，还有在WhatsApp上找到我的团队成员，这样我可以把选项分享给他们吗？"——这才是真实用户的说话方式。

生成用户请求之后，系统会在沙盒环境中部署AI助手和模拟用户，让它们真实地走完整个对话，得到实际的工具调用轨迹和数据库状态变化。每个任务会生成K条候选轨迹，最后挑选出最优的那条作为训练用的"标准答案"，同时过滤掉多余的工具调用和不必要的用户交互。

五、训练与奖励：如何评判AI做对了没有

有了训练数据，就可以开始正式训练AI了。研究团队采用两阶段训练流程：先做监督微调（SFT），让模型学习正确的工具调用格式和基本交互模式；再做强化学习（RL），让模型在真实环境中反复练习，通过奖励信号不断优化策略。

强化学习的难点在于：怎么判断AI的工具调用是对的？这个问题比看起来复杂。因为合法的工具调用往往不是唯一的。比如两个独立的只读操作，先调用哪个都行；又比如"查询最多返回多少条结果"这个参数，10条和20条都可能是合理的。如果硬要和标准答案一模一样才给满分，AI会被训练得过于死板。

研究团队设计了一个组合奖励函数，包含三个部分。第一部分是"轨迹相似度奖励"，衡量AI的工具调用序列和参数选择与标准答案的吻合程度；第二部分是"状态等价奖励"，不管过程如何，只要最终数据库的状态和标准答案一致，就认为做对了；第三部分是"长度惩罚"，对那些绕了很多弯路、多调了很多不必要工具的轨迹扣分。三个部分的权重用α参数来平衡，研究发现α取0.5时效果最好——纯看过程（α=1）或纯看结果（α=0）都不如两者结合。

六、实验结果：用"少"打败"多"

接下来是见真章的时候了。研究团队在四个基准测试上评估了训练效果，分别是BFCL v3（测试工具调用准确率）、τ?-Bench（测试多轮对话能力）、VitaBench（测试真实应用场景中的任务完成度）和MCP-Atlas（测试真实MCP服务器上的工具调用成功率）。测试的基础模型是Qwen3系列（1.7B、4B、8B三个规模）。

拿来比较的竞争对手有两个：AWM使用了526个环境和3315条训练数据，EnvScaler使用了191个环境和11572条训练数据，而EnvFactory只用了85个环境和2575条训练数据。

结果相当亮眼。在BFCL多轮对话测试上，Qwen3-4B的基础版本得分33.50，用EnvFactory训练后提升到48.50，足足涨了15个百分点，同时超过了AWM的40.75和EnvScaler的45.00。Qwen3-8B同样从41.25提升到49.00，也是三者中最高的。

在MCP-Atlas这个用真实服务器测试的"硬核"基准上，Qwen3-8B的任务通过率从5.15提升到13.75，平均覆盖率从14.86提升到25.98，均超过了使用更多环境和数据的竞争对手。

在需要多轮对话的τ?-Bench上，Qwen3-4B的得分从25.25提升到30.13，Qwen3-8B达到33.67，都是最好成绩。VitaBench上Qwen3-4B从7.67飞升到16.00，翻了一倍多。

两阶段训练的效果也得到了验证：先做SFT再做RL，比单独做任何一步都更好。SFT阶段奠定基础，让模型掌握工具调用的基本格式和逻辑；RL阶段在此基础上进一步提升推理能力和执行鲁棒性，在VitaBench和MCP-Atlas上的额外提升尤其明显。

研究团队还测试了"只做RL、不做SFT冷启动"的方案——结果发现可以有一定改善，但效果不如先SFT后RL稳定，说明SFT的"预热"对于后续RL的平稳收敛很重要。

在环境数量的缩放实验中，团队用50个、75个、85个环境分别训练，发现随着环境数量增加，性能稳步提升，但增益在后期有所收窄（50到75的提升大于75到85的提升），提示随着新环境与已有环境在工具逻辑上越来越重叠，边际效益开始递减。这意味着EnvFactory的质量控制做得很好——早期加入的环境都足够"新颖"，能真实带来增量信息。

七、精炼查询有没有用？有，而且有具体证明

研究团队还做了一组专门验证"校准精炼"效果的消融实验，对比了用精炼查询和未精炼查询各训练250条SFT数据的效果。测试场景分为四类：基础场景、缺少功能的场景（Missing Function）、缺少参数的场景（Missing Parameter）和长上下文场景。

结果显示，精炼后的训练数据在几乎所有场景上都表现更好，尤其是在Missing Function和Missing Parameter这两种"歧义"场景上优势更明显。这说明校准精炼确实成功地让训练数据带上了"隐式意图"的特质，让AI学会了在信息不完整时主动推断或追问，而不是等着用户把每个参数都说清楚。

说到底，EnvFactory这项研究的价值可以用一句话概括：用更少的"练习场"和"练习题"，训练出更能干的AI工具调用助手。它的关键不在于堆砌数量，而在于每一个训练环境都经过了严格验证，每一条训练数据都经过了仿真执行确认是可完成的，每一个用户请求都经过了精炼处理让它更像真人说话。

这对于AI工具调用领域的研究者是个好消息，因为它证明了"质量驱动"的路线比"数量堆砌"的路线更有效率。对于普通用户来说，这意味着未来能帮你订机票、管日程、查资料的AI助手，在理解你随意说出的请求时会更加得心应手，而不是需要你像写操作手册一样一步一步说清楚才能执行。

目前这套框架的一个技术局限是：因为采用了"有状态"的MCP服务器设计，每一次对话都需要独立的连接通道，大规模并发生成数据时会形成吞吐量瓶颈。研究团队通过异步管道让许多独立会话并发运行来缓解这个问题，但在更大规模的场景下仍需要进一步优化。此外，由于框架依赖在线资源和大语言模型生成的建议，存在无意间引入数据偏见的风险，这也是未来需要持续关注和改进的方向。

有兴趣深入探究这套框架的读者，可以通过arXiv编号2605.18703查阅完整论文，项目代码也已在GitHub上的LARK-AI-Lab/EnvFactory仓库中开源。

Q&A

Q1：EnvFactory框架和之前的AI工具训练方法相比，最大的不同是什么？

A：EnvFactory最大的不同在于两点：一是它能从真实的网络资源中自动发现并构建工具环境，不需要提前准备文档或人工编写代码；二是它通过"校准精炼"把过于详细的训练指令变成像真人说话一样的模糊请求，让AI真正学会理解人的意图，而不只是照说明书执行。这两点结合起来，使它用85个环境就达到了竞争对手用191甚至526个环境才能达到的效果。

Q2：拓扑感知采样解决了什么具体问题？

A：拓扑感知采样解决的是"工具依赖"问题。很多工具的执行需要用到前一个工具的输出结果，比如预订酒店需要酒店ID，而酒店ID只有通过查询酒店列表才能得到。普通的随机选取工具方法可能选出一组逻辑上无法完成的任务，让训练数据变得无效。拓扑感知采样会自动追溯并补充所有必需的前序工具，确保每条训练任务在逻辑上都是可完成的。

Q3：强化学习阶段为什么要设计组合奖励函数？

A：因为工具调用任务往往没有唯一的正确答案。两个独立操作的先后顺序可以互换，某些参数在合理范围内取不同值都可以。如果只看执行步骤和标准答案是否完全一致，会把很多同样正确的做法错误地惩罚掉；如果只看最终数据库状态是否一致，又可能放过了绕了很多弯路的低效做法。组合奖励函数同时考虑轨迹相似度、状态等价性和执行长度三个维度，在灵活性和效率之间取得平衡，实验证明这种组合比任何单一奖励都更有效。