你有没有想过，教一个AI用好各种工具，比如订机票、改数据库记录、发邮件确认，到底难在哪里？

过去一年多，大家给出的答案基本一致：造更多可执行的环境。意思是搭建更多像真实软件系统一样的沙箱，让AI在里面点来点去、调用各种接口，然后根据结果打分、训练。这个思路听起来没错，环境越丰富，AI见过的场面越多，自然越能应付真实世界的复杂任务。

但东华师范大学、复旦大学、上海奇迹智能等机构的研究者们在这篇叫WEFT的论文里，提出了一个让人愣一下的问题：如果环境没问题，但任务本身是假的，或者裁判打分打错了呢？

你辛辛苦苦让AI在一个环境里折腾了二十步，最后系统告诉它"你失败了"。AI会老老实实地从这次"失败"里学习，调整自己的行为。可问题是，如果失败的真正原因是环境里的数据库更新根本没保存成功，或者任务要求AI去查一个压根不存在的客户，又或者验证脚本本身写错了逻辑，把正确答案判成了错误答案呢？

这时候AI学到的不是"我做错了"，而是一个彻头彻尾的错误信号。它被冤枉了，还乖乖地把这个冤屈刻进了自己的参数里。

这才是WEFT这篇论文真正想解决的事情：训练信号的可靠性，比训练环境的数量更重要。

一场容易被忽略的系统性误判

研究者把这个问题讲得很清楚。一个AI完成工具调用任务,靠的不是环境这一个零件,而是四个零件一起运转:环境、任务、执行框架（也叫agent harness）、评估器。

智能体交互系统*：由环境、任务、执行框架和评估器四个部分共同构成的完整系统，AI的每一次"行动-反馈"循环都依赖这四者协同工作。

这四个零件任何一个出问题，都会污染最终的学习信号。论文举了一个很形象的例子：任务是"更新客户记录并发送确认"，AI依次做了找客户、更新记录、发确认三个动作。找客户和更新记录都做对了，但验证器把发确认这一步判定为失败。深挖下去发现，根本不是AI的问题，有可能是客户确实不存在，有可能是更新操作没有真正落盘，也可能验证器的检查逻辑本身写错了。

无论是哪种情况，如果直接把这次失败归咎于AI的策略，然后用它去做强化学习训练，等于是在惩罚一个本来做对了的行为。这就好比你请了一个很负责的员工去办事，结果因为公司内部系统故障导致流程卡住，你却给他打了一个差评还扣了工资。他下次再遇到类似情况，可能会因为"学到了教训"而变得缩手缩脚，不敢再按正确方式去做事。这不是在训练一个更聪明的员工，这是在训练一个被冤枉出心理阴影的员工。

如果继续放任这种情况扩大环境规模，会发生什么？环境越多，这种错误归因的概率不会减少，反而可能因为任务和验证逻辑更复杂而增加。规模扩大本身不解决信号可靠性的问题，甚至可能放大它。

WEFT怎么做：三条腿一起走

WEFT的全称是Whole-system Evolution For Tool-use Post-training，直译是"面向工具使用后训练的全系统进化"。它把整个思路从"扩大环境"升级成"扩大并持续修复整个交互系统"，具体靠三件事撑起来：可扩展的系统构建、执行驱动的自我进化、以及稳定的训练方法。

先说系统构建这部分。

从工具文档到可执行环境

WEFT先从公开的工具文档和业务需求出发，构建MCP工具定义，描述清楚每个工具的输入输出格式。

MCP*：Model Context Protocol，一种让AI模型调用外部工具服务的标准化协议，可以理解成AI和各种软件系统对话的通用语言。

研究团队区分了两类状态：数据库状态和工作区状态。一个专门的"环境合成agent"会分析整套工具，推断出共享的实体关系、读写依赖、状态转换逻辑，再据此生成实际的后端代码，用FastAPI框架搭建出真正能跑起来的服务。

这里有个很关键的步骤叫执行验证。生成的接口不是写完就完事，而是真的拿正常输入和边界情况去调用它，检查返回结果和数据库变化是否吻合。查询操作要核对返回值和当前状态一致，更新操作要核对数据库差异和后续读取结果一致。任何不一致都会触发对应环节的修正，直到这个MCP服务通过验证，才被认证为"可独立执行的MCP服务器"。

这个过程像什么？

像是你开了一家新餐厅，不是菜单印出来就能营业，而是每道菜都要先在后厨试做、试吃、检查食材是不是真的按菜单描述的来，确认没有食物中毒风险之后，才敢挂牌营业。如果省略这一步，直接把菜单发给顾客，后厨却经常上错菜、用错料，顾客投诉的锅最后却甩给了"顾客点菜方式不对"，那整个餐厅的信任链条就从根上断了。

环境搭好之后，WEFT接着做任务拼装。单个工具能完成的最小、可独立验证的操作叫原子任务，比如"创建一个客户记录"。

原子任务*：一个MCP能独立执行并验证完成情况的最小操作单元，通过有限的工具调用实现一个明确意图。

团队用三套检查来筛选和打磨原子任务库：真实执行验证、工具链去重、工具覆盖率统计。去重这一步挺有意思，如果一条调用链是另一条调用链的子序列，就会被判定为冗余并剔除，保证任务库里的每个任务都真的提供了独特的信息。

然后是把这些原子任务串成一个有向无环图，代表一个共同的业务目标，比如"更新设计稿并通知团队"可能需要先在Figma改图、再在Notion记录、最后发Slack通知。节点之间的依赖关系、信息流动、实体绑定都要通过确定性检查确认没有冲突。

初始状态的构建也分三轮进行：先建立最基本可执行的状态，再补齐跨工具的关系和约束，最后加入历史记录和干扰项让环境更真实。这个三轮递进的过程，有点像写小说先搭骨架、再填情节、最后加细节描写让人物活起来。

多视角和多框架：同一个任务，换着花样练

构建好的任务不会只用一种方式呈现。WEFT设计了两种任务披露模式：

Agentic模式*：给AI一份完整的任务简报，让它自主规划全部步骤。

SimUser模式*：用一个模拟用户agent按依赖顺序逐步提出请求，AI需要边听边做，而不是一开始就知道全部要求。

同一个任务目标，用不同的信息披露方式反复练习，就像教孩子骑自行车，有时候你把路线图一次性讲完让他照着走，有时候你分段提示"先骑到那棵树，再右转"。两种方式锻炼的其实是不同的能力，一种练整体规划，一种练临场应变。

论文的实验数据证实了这个设计的价值：单独用SimUser训练，效果在三个基准上都比单独用Agentic模式差。但把两种视角混合起来训练，反而比单用Agentic模式平均提升了3.18个百分点。

这说明一个单独表现不佳的训练视角，混进训练组合里依然能提供额外价值，关键是多样性本身在起作用。

除了披露方式，WEFT还会把同一个任务路由给不同的执行框架，包括ReAct、OpenClaw、Hermes，各自保留自己的提示词风格、记忆机制、规划循环和错误恢复逻辑。固定任务集的情况下，叠加这几种框架训练带来了9.71个百分点的平均提升。

这个思路挺朴素但也挺有效：当新的、可验证的任务越来越难获取时，光靠换着花样"讲"同一件事，也能从中榨出更多训练价值。好比同一道菜，让学徒分别练习"看菜谱做"、"听师傅口述做"、"模仿师傅手法做"，哪怕食材没变多，厨艺的扎实程度却完全不同。

执行驱动的自我进化：让系统自己改自己

这是WEFT整篇论文里我觉得最有意思的部分。

系统跑完一轮训练之后，会留下大量的执行轨迹和状态证据，比如每一步调用了什么工具、数据库前后发生了什么变化、最终返回了什么结果。WEFT不满足于只拿这些数据训练模型，它还用这些数据反过来诊断整个交互系统本身哪里出了问题。

具体流程是这样的：先用执行证据验证任务到底完成没完成，这一步靠的是预先生成的确定性检查清单和配套的评分规则，这两者由一个专门的"验证器生成agent"根据任务的完成条件自动产出，并在参考执行上反复测试修正。

之后是归因阶段，一个专门的"归因agent"检查任务图、执行轨迹、检查点结果和状态证据，判断失败到底是AI自己判断错了，还是环境、任务定义或验证器出了问题。如果是环境的锅，就去修后端代码；如果是任务设计或初始状态有问题，就去改任务图和初始状态；如果是验证逻辑有误，就去修验证器。只有确认是AI自身策略失误的情况，才保留任务原样，交给训练去纠正。

修改完之后，系统不会直接相信自己改对了。它会用更新后的版本重新跑一批新的rollout，检验这次改动到底有没有解决问题，还有没有引入新问题。这个循环可以反复进行，论文里实验了三轮。

这整套设计像什么？

像一个医院在不断复盘病例。某个病人治疗失败了，医院不会立刻把这个失败简单记为"治疗方案失败"，而是组织一场病例讨论会，查清楚到底是诊断错了、药品本身有问题、还是检测设备读数不准。查清楚之后，相应环节被单独修正，然后用新一批病人去验证修正后的流程是不是真的管用。如果每次治疗失败都不做这种复盘，直接把所有失败都归咎于"医生水平不够"去罚钱扣奖金，那医院永远不知道设备坏了、药品过期了这些真实问题，医生也会被错误地惯出各种自我设限的保守行为。

实验数据很直接地证明了这套复盘机制的价值。在固定任务集和rollout预算不变的前提下，三轮自我进化把训练轨迹里的工具调用错误率从1.76%降到了0.96%，相对下降45.5%。随之而来的是三个下游基准分数提升了3.65到5.25个百分点。

值得留意的是，前两轮进化就吃掉了AutomationBench和Claw-eval的大部分提升，而Toolathlon-Verified这个更考验长程多步骤执行能力的基准，一直到第三轮都还在持续改善，这跟工具错误率单调下降的趋势完全同步。这意味着错误越少，长链条任务受益越明显，因为一步错可能导致后面全盘崩溃，而短任务对单次错误的容忍度本身更高。

稳定训练：怎么把这些轨迹变成真正有用的学习信号

有了可靠的任务和环境，接下来要解决的是怎么把执行数据变成高质量的训练样本。

WEFT在监督微调（SFT）阶段用了一个叫前缀保留拒绝采样的技巧。

前缀保留拒绝采样*：把一个长任务拆成多个原子任务轮次，教师模型按依赖顺序逐个执行，每完成一步就用验证器检查。如果某一步失败，只回退重做这一步,之前成功完成的部分和对应的环境状态都原样保留,而不是把整条轨迹推倒重来。

这个设计解决的核心矛盾是什么？如果任务很长，二十步的操作序列里有一步出错就要整条重来，那每次重试的成本都极高，而且大概率会在之前已经做对的地方重复犯同样的错误，浪费大量计算资源。保留前缀相当于在登山时设置了营地，一次失足滑倒不用从山脚重新爬，只需要从上一个营地重新出发。

论文的对比实验证明了这一点：固定任务池、验证器和最终接受的轨迹数量不变，前缀保留采样在三个重试次数设置下，全部跑赢了整条轨迹重来的端到端采样。在允许三次重试的设置下，Toolathlon-Verified提升1.85分，AutomationBench提升2.17分。注意这里接受的样本数量是一样的，提升来自同样数量样本里更高的训练价值，这说明保留下来的那些"中间进度"不是无意义的冗余，而是真正承载了有用信息的训练素材。

到了强化学习阶段，WEFT又解决了另一个问题：验证器本身也可能不靠谱，有可能冤枉了正确答案，也有可能放水了错误答案。为了防止这种不靠谱的信号污染训练，团队设计了一个任务与验证器一致性过滤机制：用一个基于评分规则的大模型裁判，独立给每个任务的试点rollout打分，再和执行验证器给出的分数算皮尔逊相关系数和斯皮尔曼相关系数,只有两者高度一致的任务才会被选入正式的强化学习训练集。

这就好比招聘面试时,除了面试官打分,再找一位独立的人力资源专家做盲评,只有两人意见高度一致的候选人才会进入下一轮，避免某个面试官个人偏见主导了整个录用结果。

接下来是WEFT最核心的强化学习设计:原子轮次信用分配。

原子轮次群体相对信用分配*：把一条多步任务的执行拆分成一个个原子任务轮次,在每个轮次上,让冻结的rollout策略从完全相同的历史和环境状态出发,独立采样多个候选续写段,再根据这个原子任务是否完成，用群体内相对表现计算每个候选的优势值，只把这个优势应用到当前轮次产生的token上，不会污染之前已经完成的步骤。

这里的关键矛盾是，如果用整条轨迹的平均完成率给所有步骤分配同一个优势值，就相当于把一个任务里某一步做得特别好或特别差的责任，摊到了跟它毫不相关的其他步骤上。好比一个足球队踢了一场比赛，中场休息前进了两个球，下半场失了三个球，最后输了比赛。如果教练把这场失利的责任平均分给上半场和下半场的每一名队员,那上半场那两个进球功臣也要跟着挨骂，这显然不公平，也无法准确告诉队员到底哪个环节真正出了问题。

论文的实验数据印证了这一点：固定SFT初始化、任务池、奖励验证方式不变，只对比"整条轨迹级别"和"原子轮次级别"两种GRPO。整条轨迹级别的方法在τ?-Bench上反而比纯SFT掉了3.17分（8B模型）和0.84分（14B模型），而原子轮次级别的方法在三个基准上全部提升，在τ?-Bench上比轨迹级别方法高出5.69分和4.43分。

GRPO*：Group Relative Policy Optimization，一种强化学习算法，通过比较同一批候选结果的相对优劣来计算训练信号，而不依赖一个绝对的价值评估标准。

除了这套信用分配机制，WEFT还加了一层"选择性信用屏蔽"：系统会检测没有进展的重复操作、格式错误的工具调用、违反接口规范的行为，即便这些行为最终凑巧完成了任务，正向的信用也会被清零，只保留负向信用，防止AI学会靠"瞎蒙"或者"钻系统漏洞"碰运气得分的坏习惯。

MegaMCP：让并发训练不再是一场资源灾难

说完算法层面，论文还花了很大篇幅讲一个基础设施问题：当你需要同时跑成百上千个rollout，每个都需要独立的数据库状态和工作区，怎么办？

最直接的做法是每个rollout都单独部署一套完整的MCP服务，包括服务器代码、初始数据库、工作区文件。但这样做的代价极高：每次部署都要重复传输大量数据，每个进程都要占用独立的内存，启动延迟也会累积。

WEFT的解法叫MegaMCP，核心思路是把"可复用的工具服务"和"每次rollout的可变状态"彻底分离开。

MegaMCP*：一套共享的工具服务架构，把MCP服务部署在agent沙箱之外，让多个兼容的会话共享同一批工作进程，同时给每个rollout保留私有的、可快照恢复的数据库和工作区状态。

这个设计像什么？

想象一个共享办公空间。如果每个入驻的小团队都要自己装修一整套办公室、自己拉网线装电表，成本会高到离谱。共享办公空间的做法是公共设施（前台、会议室、网络）大家共用，但每个团队的文件柜是上锁的、互相看不到彼此的资料。MegaMCP就是把工具服务当成这个公共设施，私有数据库和工作区当成那个上锁的文件柜。如果不做这层分离,每次开一个新rollout就等于重新装修一次办公室，装修材料（服务器代码、初始数据库）要重复采购运输,新团队入场前还要等整栋楼重新验收，等待时间全花在了无意义的重复劳动上。

实验数据展示了这个设计的实际效果。在1000个任务规模下，MegaMCP把需要上传到沙箱的数据量从773.5 MiB降到34.8 MiB，降幅95.5%。内存方面，52个实例共享8个进程比每个实例单独占一个进程节省了77.6%的内存，50个会话共享单个进程更是节省了95.7%。冷启动场景下，两套系统都从零开始时，MegaMCP把拿到第一次工具调用结果的中位时间从10.455秒降到了4.794秒，降幅54.1%。

这些数字背后的意义是，独立的rollout状态并不需要每次都重新搭建整套工具服务的基础设施，分离状态和服务这件事本身就能省下大量真实的时间和资源成本，这对需要海量并发训练的大规模强化学习来说是实打实的工程价值。

成绩单：数字说话

研究团队用WEFT后训练了Qwen3-8B、Qwen3-14B、Qwen3.5-35B-A3B三个不同规模的模型，在BFCL V4、τ?-Bench、Claw-eval、Toolathlon-Verified、AutomationBench五个基准上做了评测。

在7B到32B这个参数规模区间，WEFT-14B拿到了最高的综合得分，相比同规模的环境扩展基线Agent-World-14B，在BFCL V4、τ?-Bench、Claw-eval三个基准上分别高出6.41、2.23、12.27个百分点。WEFT-8B同样全面超越Agent-World-8B，三项提升分别是0.88、0.45、5.28个百分点。

有两个细分能力特别值得一提：BFCL的Memory类别和τ?-Bench的Telecom领域。WEFT-14B相比对应的Agent-World模型，在这两项上分别高出25.35分和20.22分。更有意思的是，这个优势在扩大到35B参数规模的模型上依然保持，WEFT-35B-A3B在Memory上拿到66.02%，是35B到685B这个区间里报告的最高分，比第二名高出11.82分。这说明这不是某个规模下的偶然高分，而是WEFT训练方法本身带来的一种稳定且可迁移的能力增益。

在更考验长程多工具协作能力的高级基准上，WEFT-35B-A3B在Toolathlon-Verified上拿到45.99%，在AutomationBench上拿到26.50%，把评测范围从相对标准化的工具调用场景推进到了更贴近真实工作流的复杂任务。

写在后面

读完这篇论文,最打动我的不是任何一个具体的技术细节,而是研究团队提出问题的角度。

大多数做AI agent训练的工作,默认的优化方向是"给模型看更多数据"。WEFT提出的质疑是,如果数据本身的质量判定出了问题，看再多也没用，甚至是在系统性地给模型喂错误的反馈。这跟我们生活中很多"努力不见效"的情况其实是同构的：如果反馈机制本身是坏的，再多的努力也是在错误的方向上加速。

论文里那个工具调用错误率从1.76%降到0.96%的数据,我反复看了几次。45.5%的相对下降,这个数字告诉我们,即便是经过了精心构造和初步验证的训练环境,仍然有将近一半的隐藏问题是靠单次构建发现不了的，必须靠反复的"跑一跑、看哪里错、改一改、再跑一跑"才能挖出来。这跟软件工程里"没有一次性写对的代码，只有不断迭代打磨出来的代码"是一个道理，只不过WEFT把这个迭代过程也自动化了。

还有一个细节我觉得值得单独说一下：原子轮次级别的强化学习在τ?-Bench上避免了整条轨迹级别训练出现的性能倒退。这说明信用分配的粒度不是一个无关紧要的工程细节，粒度错了，哪怕奖励信号本身是对的，训练出来的模型也可能在某些场景上变得更差。这提醒我，很多时候"学习信号对不对"和"学习信号怎么分配"是两个完全不同的问题，前者解决了不代表后者也顺理成章地解决了。

这篇论文没有解决的问题，我觉得也值得追问：当这套自我进化机制跑得足够多轮之后，会不会出现某种收敛到局部最优的风险，就是系统自己改自己改到一个自洽但未必正确的状态，而没有外部的真实反馈来打破这种自洽？论文里只跑了三轮验证，三轮之后会发生什么，这是个留白。

Q&A

Q1：WEFT是什么？

A：WEFT是一套面向AI工具调用能力训练的完整框架，全称是面向工具使用后训练的全系统进化。它的核心思路是不仅扩大训练环境的数量，还要持续检测并修复环境、任务、执行框架、评估器这四个组成部分里的问题，从而获得更可靠的训练信号。

Q2：WEFT和其他环境扩展方法最大的区别是什么？

A：以往的方法主要靠造更多可执行环境来扩充训练数据，WEFT则认为环境数量不等于信号质量,它引入了执行驱动的自我进化机制，用执行轨迹反过来诊断失败是AI自身的问题还是环境、任务、验证器的问题，再针对性修复，让学习信号更可靠。

Q3：MegaMCP解决了什么问题？

A：MegaMCP解决的是大规模并发训练时的资源浪费问题。它让多个训练任务共享同一套工具服务进程，但各自保留独立可恢复的数据库和工作区状态，大幅减少了重复部署带来的数据传输量、内存占用和启动延迟。