WEFT:为通用智能体扩展工具使用后训练
近期扩展工具使用后训练的工作大多聚焦于可执行环境的合成,但环境只是更广义智能体交互系统的一部分——该系统还包含 environment、task、agent harness 与 evaluator。孤立地扩展环境并不能保证模型性能获得同等提升,因为可靠的学习信号依赖于系统各组件之间的协同交互。 为此,作者提出 WEFT(Whole-system Evolution For Tool-use Post-training),将三个环节耦合起来: - 可扩展的智能体交互系统构建:在环境广度、任务复杂度与交互多样性上同步扩展; - 执行驱动的自演化:迭代利用执行轨迹与状态证据归因失败,修正相应组件,并通过新的 rollout 评估改动、为下一轮演化提供证据; - 稳定的规模化后训练:prefix-preserving sampling 保留已验证的进展,atomic-turn credit assignment 定位学习信号,而 MegaMCP 在共享工具服务上为并发 rollout 维护隔离且可恢复的状态。 实验表明 WEFT 在多种模型与基准上均有效。WEFT-8B 与 WEFT-14B 在 BFCL V4、τ^2-Bench 与 Claw-Eval 上优于所有评估过的同规模 environment-scaling 基线;其中 WEFT-14B 相比 Agent-World-14B 分别提升 6.41、2.23 与 12.27 个百分点。WEFT-35B-A3B 进一步在更具挑战性的长程工作流基准 Toolathlon-Verified 与 AutomationBench 上延续了这一增益。
论文精读
TL;DR **WEFT** 通过协同扩展环境、任务、agent harness 与 evaluator 并迭代执行轨迹驱动的自进化,解决仅扩展环境无法稳定提升工具能力的问题,其 **14B** 模型在 **BFCL V4** 等指标上超越同尺寸基线 6.41 个百分点。
问题
问题背景
当前工具使用后训练(tool-use post-training)的规模化工作主要聚焦于合成可执行环境,试图通过扩大环境库来提升通用智能体的工具调用能力。
现有方法局限
- 将 代理交互系统 简化为单一环境组件,忽略任务、代理 harness、评估器之间的协同。
- 仅扩展环境(如 Agent-World 等方法)并不能保证模型性能同步提升,因为可靠学习信号取决于全系统交互的一致性。
- 环境与任务不匹配、评估反馈噪声、harness 逻辑不一致等问题导致后训练增益有限,甚至出现不稳定。
为什么这个问题难/重要
- 技术挑战:可靠学习信号需要环境、任务、harness、评估器四者一致交互,但大规模构建时难以保证每一轮 rollout 的连贯性。
- 训练稳定性:规模化后训练面临优化可靠性与执行可靠性双重问题,如采样破坏已验证进展、并发 rollout 状态相互干扰。
- 业界关注:通用智能体(general-purpose agents)是行业重点,工具使用能力直接影响落地效果,但现有后训练数据构造方式难以规模化且缺乏全系统视角。
行业类比
类似在自动驾驶仿真中只扩展场景库,却忽略车辆模型、传感器仿真与评分逻辑的匹配,训练出的策略在真实部署时泛化不足。
核心洞察
- 工具使用后训练需从“环境缩放”转向“整体交互系统缩放”。因为学习信号质量取决于环境、任务、代理 harness、评估器的协调一致性,单纯扩环境无法保证模型能力提升。现有工作(如 Agent-World 等)主要合成更多可执行环境,但忽视了任务定义、执行框架、评估反馈与环境的耦合。WEFT 指出环境只是系统的一部分,不相干的组件可能导致奖励稀疏、噪声大,甚至错误归因。因此它整体演化系统构造,覆盖环境广度、任务复杂度、交互多样性,确保训练信号可靠。
- 执行驱动自演化与稳定后训练机制的结合,解决了大规模工具后训练中“部分成功难以分配奖励”和“训练不稳定”两个核心难题。WEFT 利用执行轨迹和状态证据定位失败责任组件,并通过新 rollouts 验证修正,形成闭环;同时 prefix-preserving sampling 和 atomic-turn credit assignment 保留有效进展、局部化学习信号,避免灾难性遗忘。这区别于简单使用 RLHF/DPO 或仅依赖环境奖励,更适用于长程多轮工具调用场景。
方法
输入与系统定义
WEFT 的输入是一组 agentic interaction system 组件,包括 environment(执行环境)、task(任务定义)、agent harness(智能体交互框架)与 evaluator(评估器)。这些组件共同构成一次工具调用交互的完整闭环,而非孤立地提供可执行环境。
关键模块
- 可扩展系统构建:从三个维度扩展训练系统——环境广度(覆盖更多工具与 API)、任务复杂度(从单步到多步工作流)、交互多样性(多样化的查询与反馈模式)。该模块生成大量系统配置,用于后续进化与训练。
- 执行驱动自我进化:利用执行轨迹与状态证据对失败进行归因,定位到具体组件(如环境定义、任务指令、harness 逻辑或评估标准),并自动修订对应组件。修订后通过新 rollout 重新评估,所得证据进入下一轮进化,形成迭代闭环。
- 稳定后训练:针对大规模训练中的优化与执行可靠性提出三项技术:
- Prefix-preserving sampling:保留已验证的决策前缀,避免重采样破坏正确进展;
- Atomic-turn credit assignment:以单轮工具交互为原子单位分配奖励信号,使学习信号局部化,减少信用分配偏差;
- MegaMCP:在共享工具服务上进行并发 rollout 时,维护隔离且可恢复的状态,防止跨任务干扰。
输出
输出为经过 WEFT 后训练的工具使用模型(如 WEFT-8B / WEFT-14B / WEFT-35B-A3B),在 BFCL V4、τ²-Bench、Claw-Eval 等基准上优于同规模仅扩展环境的方法。
与同类环境扩展方法的核心差异:WEFT 对整个 agentic 交互系统进行联合进化,并通过执行反馈与稳定性机制保障学习信号可靠,而非仅依赖合成更多环境。
实验
实验设计
WEFT 在多个工具使用基准上进行评估,覆盖 BFCL V4、τ^2-Bench、Claw-Eval 以及更长周期的 Toolathlon-Verified、AutomationBench。模型尺寸包括 8B、14B 与 35B-A3B(MoE 架构)。对比基线为匹配尺寸的 environment-scaling 方法,如 Agent-World-14B。实验重点考察不同模型规模下,WEFT 相比仅扩展环境的方案是否能带来稳定提升。
关键发现
- WEFT-8B 与 WEFT-14B 在三个核心基准上均优于所有匹配尺寸的环境扩展基线。
- 具体地,WEFT-14B 相比 Agent-World-14B 在 BFCL V4 上提升 +6.41 个百分点,在 τ^2-Bench 上提升 +2.23 个百分点,在 Claw-Eval 上提升 +12.27 个百分点。
- WEFT-35B-A3B 进一步在长周期工作流基准 Toolathlon-Verified 与 AutomationBench 上扩大优势,验证了方法在更复杂任务上的可扩展性。
与基线的对比解读
WEFT 的核心差异在于不孤立扩展执行环境,而是对 环境、任务、智能体 harness、评估器 进行整体协同演化。仅扩展环境的基线(如 Agent-World)可能在环境覆盖度上很高,但学习信号因组件间交互不一致而衰减,导致性能增益不匹配。WEFT 通过 执行驱动的自演化 与 前缀保留采样、原子轮次信用分配、MegaMCP 并发隔离 等稳定训练策略,将提升从环境规模转化为实际模型能力。这解释了为何 WEFT 在多个基准上一致超越同尺寸基线,尤其在高交互复杂度的 Claw-Eval 上优势最明显(+12.27),说明交互多样性与状态一致性比单纯环境数量更重要。
行业影响
落地场景
WEFT 的全系统演化方法适合工具密集型 Agent:电商智能客服与订单自动化、企业级 RPA/工作流助手、数据分析 Agent、代码生成与运维 Copilot。这些产品依赖多轮工具调用与长 horizon 任务,需要稳定的工具使用后训练。
商业价值
主要收益在执行可靠性与训练成本。通过 prefix-preserving sampling 保留已验证进度、atomic-turn credit assignment 局部化学习信号,减少失败重试与人工标注成本。在 BFCL V4、τ²-Bench 等指标上,WEFT-14B 比同规模环境扩展基线提升 6.41、2.23、12.27 pct。对产品而言,更高工具调用成功率直接降低客户流失与支持工单。
与现有产品/工作流接口
WEFT 可嵌入现有 post-training 栈:数据侧接入 MCP 工具服务与执行沙箱,训练侧与现有 RL/DPO 框架结合。MegaMCP 的并发隔离状态管理适合 Kubernetes/服务网格上多租户 rollout,可直接对接 LangChain/LlamaIndex 的 tool executor。演化循环可编排进 ML pipeline,用执行 trace 作为评估信号。
具体 use case:
- 电商订单处理 Agent:处理退换货、物流查询、优惠券核销等多步工具调用,WEFT 的全系统演化能针对真实订单系统环境持续改进,减少错误下单或错误退款。
- 企业 SaaS 工作流自动化:如 CRM/ERP 中跨系统数据同步与审批流,WEFT 的稳定后训练支持长 horizon 任务,避免中间步骤失败导致整体任务中断。
局限
- WEFT 的 execution-driven self-evolution 依赖大量执行 rollouts 和 trace 分析来定位失败组件,这一过程计算密集且需要持续维护可复现的交互环境。论文提出的 MegaMCP 虽解决了共享工具服务下的并发状态隔离问题,但额外引入的容器化与状态恢复机制会增加基础设施复杂度,对资源有限的团队不够友好。实际部署时,如何控制自进化循环的成本与频率,避免过度的仿真开销,文中未给出明确的超参数设置或成本量化。
- 实验主要基于 BFCL V4、τ^2-Bench、Claw-Eval 及 Toolathlon-Verified、AutomationBench 等基准,这些基准覆盖的工具类型和任务结构相对固定,且多为单轮或有限多轮交互。真实世界中的工具 API 可能频繁迭代、文档缺失、行为漂移,且涉及多模态输入输出或需要长周期记忆与规划,WEFT 在这些开放场景下的鲁棒性和泛化能力尚未得到验证。此外,基准的评估指标可能无法完全反映智能体在真实用户任务中的实用性。
- WEFT 强调整体系统的协同演化,但其自进化过程依赖对失败原因的可判定归因,即通过 execution traces 和 state evidence 明确将错误定位到环境、任务、harness 或 evaluator。然而,在复杂智能体系统中,失败常常来自组件间的耦合或时序竞争,难以精确分离责任方。当失败模式模糊时,revise 策略可能产生误导性修正,导致学习信号噪声放大。与纯环境扩展基线相比,WEFT 在系统构建上要求更高,其效果提升可能部分来源于对特定基准的过拟合,而非通用的工具使用能力提升。