【时快讯】LongWoF-Bench：当AI学会了做一件事，这份经验能传给下一个AI吗

你有没有想过这样一个问题：一个人辛辛苦苦解决了一道特别难的题，把所有的弯路、陷阱、正确解法都摸清楚了，结果第二天这个人失忆了，第三天换了个人来做同一道题，还得从头再摸索一遍。

这听起来很荒谬，但这几乎就是现在大语言模型工作的常态。

(相关资料图)

一个模型好不容易通过反复试错，把一个复杂任务的坑都踩过一遍，最终交出了正确答案。可是这次成功的经验呢？往往就随着这次对话窗口的关闭而彻底消失了。下一次遇到类似任务，不管是同一个模型还是别的模型，都得从零开始重新摸索。这篇来自清华大学EvoMap团队的论文，探讨的正是这个问题：能不能把这种来之不易的"成功经验"提炼出来，存起来，让后面的模型直接拿去用？

**核心问题：什么样的任务最考验模型的"记性"**

论文首先给这类任务起了个名字，叫"可验证长工作流任务"。

长工作流任务：指的不是简单一问一答就能搞定的事，而是需要模型执行一连串相互依赖的操作，最后交出一个成品，这个成品必须严格满足全部预设条件才算成功。

这里有个反直觉的地方，值得说清楚。很多人以为"长工作流"难在步骤多、上下文长，模型记性不够好。但论文里明确指出，难点根本不在这里。真正的困难在于，前面某一步做的决定，会一路影响到后面每一步。哪怕后面90%的步骤都做得挺合理,只要中间有一个接口没对上、一个边界条件算错了、一个先后顺序搞反了，整个成果就全盘作废。

举个论文里的真实例子。有个任务叫"钻孔化验数据合并"，要求把重叠的采样区间处理好再按固定长度分箱汇总。产出模型Claude Opus一开始想的办法是"后面的区间覆盖前面的"，听起来挺合理对不对？可这个方案反复被验证系统打回来，因为正确的做法其实是把每个区间在所有断点处切开，对每一段取所有覆盖它的化验值做平均，再按长度加权汇总。这种细节，如果没有亲身踩过坑，是很难第一次就想对的。

这就是论文强调的：任务是否"长"，不看步骤数量，看约束之间是否环环相扣。一步错，步步错，最后全错。

为了系统研究这个问题，团队搭建了一个叫LongWoF-Bench的评测基准。

LongWoF-Bench：一套包含778个可由机器自动验证对错的任务集合，覆盖代码生成、智能体环境搭建、数学推理、规则遵循这四大类。

这778个任务里，341个是代码生成，127个是智能体环境合成（比如搭建一套完整的巡航控制系统），151个是数学推理，159个是规则遵循。每个任务都配了一个私密的自动评分程序，模型看不到评分标准里的具体判断逻辑，但完成任务所需的全部信息，其实都已经在公开的任务说明里给出了。换句话说，这不是刁难模型，藏了什么模型根本不可能知道的暗坑，而是纯粹考验模型能不能把已知信息严丝合缝地执行到底。

**方法核心：Skill和Gene,两种截然不同的"经验包"**

论文对比了两种给模型"加持经验"的方式，这是全文最核心的设计。

Skill：一种把"这件事该怎么做"提炼成操作手册的方式，里面通常是流程、接口规范、推荐做法这些静态的、事先总结好的程序性知识。

Gene：EvoMap框架里的一个核心概念，指从真实执行、并且通过验证器确认成功的完整轨迹里,提炼出来的经验包，里面保存的是具体的策略、纠错过程、边界条件、以及曾经导致失败又被修正的教训。

这两者听起来有点像，但本质区别很大。Skill更像是一本教科书，是别人事先总结好"应该怎么做"；而Gene更像是一份带着伤疤的实战笔记，记录的是"我曾经这样做失败了，后来这样改就通过了"。

这里必须讲清楚Gene是怎么产生的。团队用了一个叫Evolver的框架。

Evolver：一套"执行—验证—修正"的循环流程，模型先在不知道评分细节的情况下尝试完成任务，如果失败,下一轮会拿到经过脱敏处理的验证反馈，据此修改方案，如此反复直到通过验证为止。

注意这里被反复打磨的对象是任务的解决方案本身，不是Gene。只有当某次尝试真正通过了验证，团队才会把这条成功轨迹里的关键信息提炼成一份Gene，存进一个叫EvoMap的知识库里，供后续任何模型调取复用。

如果打个比方，这就像是一个厨师反复试做一道新菜,尝了咸淡、调了火候、试错了好几次，终于做出一道让评委满意的菜。这时候他把整个试错过程和最后成功的配方写成菜谱,存进了后厨的公共食谱本里。下一个厨师翻开食谱本，不需要再从头试错咸淡火候，直接照着做就大概率成功。而如果没有这份"带着试错记录的菜谱"，只给一份泛泛而谈的"如何做好一道菜"的通用教程,后面的厨师照样得自己摸索这道具体菜的具体坑在哪里。

这个类比背后的反事实很清楚：如果不做Gene这种基于真实验证过的经验提炼，只靠事先写好的Skill手册，模型面对具体任务里那些细枝末节的陷阱，还是得自己一次次撞上去。

**实验发现一：验证过的经验，比写好的手册更管用**

团队用了7个不同的模型家族去做对比测试，包括Claude Opus 4.8、Claude Sonnet 4.6、Gemini 3.1系列、MiniMax M3以及两个Qwen模型。测试聚焦在252个任务上，这些任务都是Claude Opus亲自跑通验证、拿到"合格证"的。

结果相当一致：在不给任何提示的情况下，7个模型平均通过率是41.0%；给了Skill手册之后，提升到51.2%；而给了从真实验证轨迹提炼出的Gene，通过率直接冲到62.9%。

Gene在全部7个模型上都稳定超过Skill，超出幅度在8.7到15.5个百分点之间。

以Claude Opus自己为例，用Skill时通过率是63.9%，换成Gene之后飙升到79.4%，一下多通过了15.5个百分点。更值得留意的是，这份Gene是Opus自己生产的，但它同样能让完全不同厂商的Gemini、MiniMax、Qwen模型显著受益。这说明验证过的执行经验一旦被固化成结构化的Gene，不再依赖生产它的那个模型，可以真正跨模型家族流通。

**实验发现二：不是所有的Gene都一样管用,来源才是关键**

这是整篇论文里最扎实的一处反转。团队还测试了另外526个任务，这些任务是Opus在给定的探索次数内没能验证通过的，团队只好换一种方式，参考别的答案信息蒸馏出一份"备用Gene"。

结果这批"备用Gene"表现反而不如Skill,而且是全线落后，每个模型都低了3.3到11.3个百分点。

这个对比揭示了一个容易被忽视的道理：Gene有没有用，关键不在于它长什么样、结构多精巧，而在于它背后的经验有没有真的经过验证系统的检验。没有经过真实验证的信息,即便包装得和真正的Gene一模一样,也缺了那个最核心的东西,就是"这个方案确实被证明有效，这个坑确实是真的坑"。

团队还做了另一组更精细的对照,专门挑出Opus和Gemini都各自独立验证通过的180个共同任务，比较用Opus生产的Gene和用Gemini生产的Gene，哪个效果更好。结果是Opus生产的Gene在全部7个消费模型上都更胜一筹，领先幅度4.4到11.7个百分点。这进一步说明，生产经验这个过程本身的质量,也就是谁去闯关、闯得多干净利落，同样会影响这份经验的最终价值。

这里可以引申出一个挺有意思的类比。想象两个学生复习同一门课，一个是学霸做的错题本，把每道题的坑点标注得清清楚楚；另一个是学渣东拼西凑硬凑出来的笔记，表面格式一模一样,但内容含糊,遇到没见过的题就不知道怎么迁移。同学之间传阅笔记的效果,肯定不一样。如果两份笔记外观完全相同，你光看格式根本分不出高下，只有真的拿去做题才知道差别在哪。这恰恰对应了论文里这个反直觉发现：光靠"结构做得像不像Gene"判断不了它有没有用,得看这份经验到底是不是真刀真枪拼出来的。

**实验发现三：省钱又省事,重复利用经验能砍掉近一半的成本**

光有效果好还不够，团队接着算了一笔账，看看用Gene到底能不能省钱。

在同样一次性作答的条件下，Skill通过了161个任务，一共花了803099个token；Gene通过了200个任务，只花了723480个token。也就是说，Gene多通过了39个任务，反而还少花了79619个token，相当于节省了9.9%的成本。

更有意思的对比是把"重新发现经验"和"复用已有经验"放在一起比。当初Opus为了摸索出这252个任务的正确解法，反反复复试错，总共调用了404次模型，花了1333968个token才把全部任务打通。而现在别的模型直接拿这份Gene去用，只需要252次调用（每个任务一次），花723480个token，就通过了200个任务。这相当于省了45.8%的探索成本。

这笔账背后藏着一个朴素的道理：探索的成本没有被消灭，只是被摊薄了。第一次发现正确做法确实很贵，但一旦发现了，后面所有想用的人都不用再重复交这笔学费。

这就好比修一条山路。第一次开路的人得自己拿着柴刀在荆棘丛里摸索、试错，走错方向再折返，非常耗时耗力。可这条路一旦真正开通了、后来者走的时候完全不用再重复开路的辛苦，直接沿着现成的路走过去就行。而如果每次都让不同的人去重新开路（这就相当于用Skill这种静态手册去应对具体陷阱，但手册里没记录这条路上具体哪块石头会绊人），那每个人都得自己重新摔一跤才知道哪里有坑。

具体到不同任务类型，节省效果也不一样。代码生成类任务省得最多，达到55.8%；智能体环境合成紧随其后,省了46.8%。这两类任务往往需要反复搭建或修改可执行的代码产物，重新摸索的代价本来就高，所以复用经验带来的节省也最明显。

**实验发现四：不同任务类型,收益天差地别**

论文没有回避一个诚实的事实：Gene并不是对所有任务都同样有效。

在智能体环境合成和规则遵循这两类任务上，Gene几乎对所有模型都带来了扎实的提升，前者提升幅度在15.6到29.7个百分点，后者在2.1到22.9个百分点。这两类任务本身就特别依赖那些容易出错的操作约定，比如接口是否对齐、多个产出物之间是否一致、规则之间谁先谁后、边界条件怎么处理。这恰好是Gene最擅长记录的东西,那些"曾经在这里栽过跟头，后来这样改就对了"的具体教训。

但在代码生成任务上，效果就没那么统一了。有三个模型反而出现了小幅下降，不过下降幅度都不算大，在1.7到4.9个百分点之间。团队推测，这可能是因为有些编程任务需要更广泛的接口和实现覆盖，这时候Skill那种偏综合性的指导反而更合适，而Gene聚焦于个别关键操作约定，覆盖面没那么宽。

数学推理任务的表现则更加两极分化。Claude Opus在这类任务上收益巨大，通过率提升了整整40个百分点，但其他几个模型要么持平要么下降。团队给出的解释挺实在：数学题的失败往往不是因为不知道该用什么方法，而是模型本身在多步骤精确计算上力不从心。Gene能把公式、边界处理约定、解题思路传递过去，但如果一个模型本身推理能力就跟不上，拿到再好的经验也发挥不出来。

这个发现其实挺有价值,它提醒我们Gene不是万能钥匙，它的效果会和消费模型自身能力、任务类型这两个变量产生复杂的交互作用。

**两个具体案例，看经验是怎么被传递的**

论文里挑了两个案例，讲得特别具体，值得单独说说。

第一个是前面提到的钻孔化验数据合并任务。Opus一开始想的是"后面覆盖前面"的简单策略,反复被打回。真正通过验证的做法是把重叠区间切成小段,对每段取所有覆盖它的化验值平均,再按长度加权汇总。没有这份Gene的时候,Gemini Pro犯了同样的错误,用了错误的截断策略,给出了一个无效的矿化评分;而有了这份Gene之后,Gemini Pro一次就通过了。传递过去的不是一句泛泛的"注意处理重叠区间",而是那个具体的、经过验证的处理规则本身。

第二个案例是紧急调度任务，涉及严格的距离阈值和优先级规则（伤者优先、持械但无伤优先、纯距离优先，这三者谁先谁后）。Opus的一个中间版本和没用Gene的Gemini Pro都犯了同一个错误：把"是否持械"看得比实际规则更重要，还搞错了距离恰好等于阈值这种边界情况该怎么算。最终通过验证的方案纠正了这两个问题：等于阈值时不触发升级,并且按正确的优先级顺序判断。有了这份经验后,Gemini Pro避开了同样的坑,直接给出了正确答案。

这两个案例其实说明同一件事:Gene传递的不是抽象的"要小心"，而是精确到"这里曾经错在哪、应该怎么改"的具体修正。

Q&A

Q1：LongWoF-Bench是什么？

A：LongWoF-Bench是清华大学EvoMap团队推出的一个评测基准，包含778个可由机器自动验证对错的复杂任务，覆盖代码生成、智能体环境合成、数学推理、规则遵循四大类，用来考察大模型能不能在满足一连串相互依赖约束的情况下完成任务。

Q2：EvoMap的Gene和常见的Skill有什么区别？

A：Skill是提前写好的操作手册，讲的是"这件事该怎么做"；Gene是从真实通过验证的执行轨迹中提炼出来的经验包，记录的是具体踩过的坑和修正方案。实验显示Gene在7个模型上都比Skill效果好8.7到15.5个百分点，但前提是这份Gene必须来自真正通过验证的经验，光是形式上模仿Gene的结构而没有验证过程支撑，效果反而不如Skill。

Q3：用Gene复用经验能省多少成本？

A：以Claude Opus为例，用Gene比用Skill多通过39个任务，同时还少花了9.9%的token。如果对比"从头摸索"和"直接复用已验证经验"，复用能省下45.8%的探索成本,其中代码生成和智能体环境合成任务省得最多，分别达到55.8%和46.8%。