FlowEvo：让AI智能体像老师傅一样，把成功经验存进工具箱

你有没有想过这样一件事：一个厨师第一次做红烧肉，摸索出了完美的火候和调料比例,结果第二天换了一道菜,他把昨天的经验全忘了,从零开始试错。

这听起来很荒谬对吧？但这恰恰是当下大语言模型智能体（LLM Agent）的真实处境。

大语言模型智能体：基于GPT-4o-mini这类大语言模型构建的自动化程序，它能像人一样拆解任务、调用工具、编写代码来完成复杂目标。

这些智能体在解决一个任务时，往往会现场"搭积木"，把推理、写代码、检查结果这些步骤临时拼装成一套流程，业内管这个叫"工作流"（workflow）。问题是，一旦任务做完，这套辛辛苦苦拼出来的流程就直接被扔掉了。下一次遇到类似任务，模型又得重新摸索一遍。这不仅浪费大量计算资源（也就是真金白银的token开销），还会导致同一类问题每次表现都不太稳定。

这篇来自东南大学、伦斯勒理工学院和香港科技大学团队的论文，提出了一个叫FlowEvo的框架，试图解决这个"每次都从零开始"的老大难问题。它的核心思路很朴素：让智能体自己把做成功的事情，编译成可以随时调用的"技能"，存进一个持续积累的技能库里。这不是让模型重新训练，参数一个字节都不变,而是在推理阶段动态积累经验，有点像给模型配了一个越用越厚的笔记本，只不过这个笔记本里存的不是文字，而是能直接运行的代码。

核心问题：为什么"存经验"这么难

在FlowEvo出现之前，业内其实已经有两条路子在尝试解决这个问题，但都各有硬伤。

第一条路是把之前的推理过程、成功案例存成文字，供后续任务参考。比如ExpeL（Zhao et al., 2024）这类方法，会把智能体走过的路径总结成经验教训，塞进提示词里。这条路的问题在于，文字描述终究只是描述,它没法被直接验证，也没法被直接调用。模型看到"上次这样处理成功了"这句话，还是得靠自己重新推理一遍怎么做，相当于你看着菜谱上写"火候要控制好"，但具体几分钟、多大火，还得自己重新试。

第二条路是把工具、代码片段做成可执行的技能库，比如给智能体配备一套现成的函数工具。这条路虽然解决了"可执行"的问题，但这些工具库通常是研发人员离线手工准备好的，针对一个固定的任务分布设计，跟智能体自己实际解题的过程是脱节的。智能体现场遇到的具体问题，未必能匹配上这些提前准备好的工具。

这就是论文点出的核心矛盾：文字记忆能灵活生成但不可执行验证,工具库可执行但不是从智能体自己的实战中长出来的。FlowEvo想要的，是把这两条路的优点捏到一起,让技能既是从真实成功案例里提炼出来的,又是能被直接调用、验证、追踪效果的可执行代码。

我们先看看论文里给出的一个数字对比，来体会一下这个差距有多大。在ALFWorld这个交互式家务模拟环境的测试中，之前最强的基线方法AFlow只能达到59.2%的成功率,而FlowEvo做到了85.6%,足足高出26.4个百分点。更夸张的是，它用的token数量只有基线方法的三分之一左右。这不是简单的性能微调,这是同一个GPT-4o-mini模型，仅仅因为"记住了怎么做"，效果就发生了质的飞跃。

工作流到技能的编译：把一次成功变成可复用的资产

FlowEvo的第一个核心机制，是它怎么把一次成功的解题过程，转化成一个可以反复调用的"技能记录"。

具体来说，当智能体成功完成一个任务后，系统会分析这次的执行轨迹（trace），从中提取出可执行的部分,识别出程序的入口点，推断出调用接口的具体形式，抽取一些可以用来做回归测试的用例，再打上任务类型标签、来源信息等元数据。这个过程叫编译（compile），跟程序员把源代码编译成可执行文件是一个意思,只不过FlowEvo编译的是"一次成功的问题求解过程"。

编译出来的技能不是简单存一份代码就完事,论文里定义每个技能记录包含五个部分：可执行主体、明确的调用接口、一组用来验证行为是否正确的测试、辅助的元数据信息，还有这个技能当前所处的生命周期状态。这五样东西凑在一起，才能保证一个技能既能被安全调用,又能被后续持续追踪表现好坏。

这里有个细节值得多说一句：不是所有编译出来的候选技能都能直接进入"生产环境"使用。系统会先做去重检查,然后通过一个准入层，从三个维度审核：接口是否规范能调用、功能是否真的正确（靠回放测试验证）、是否符合安全约束（比如不能包含危险的系统调用）。通不过审核的技能，要么被拒绝直接执行，只能作为背景参考信息使用，要么被放进一个"影子状态"供内部诊断，不会真正流通出去。

准入层：技能进入正式技能库之前必须通过的三层审查机制,分别检查接口规范性、功能正确性和安全合规性,类似于食品出厂前的质检环节。

这个设计让我想起一个很生活化的场景。假设你是个手艺人，带徒弟。徒弟做出一件成品，你不能徒弟一说"我这次做成了"就直接把这个做法写进祖传秘籍。你得先看看他做的东西接口对不对（比如榫卯尺寸是不是标准件，方便以后拼装），再看看这个方法是不是真的稳定可靠（不能是蒙对的），还得确认这个方法没有隐患（比如会不会用了危险材料）。三条都过了，这个手艺才配写进秘籍供后人直接照搬使用。如果不做这层审查会怎样？那些侥幸做对但方法本身不靠谱的技能，会混进技能库里，下次被调用时大概率会出岔子,反而拖累整体表现,这正是论文后面要重点解决的"负迁移"问题的根源。

技能到工作流的反哺：直接执行还是提供思路

有了技能库之后，下一个问题是：新任务来了，怎么用这些存好的技能？

FlowEvo设计了一套分层路由机制,面对一个新任务，系统先用检索器给候选技能打分,考量的维度包括文字层面的相似度、任务模式是否匹配、接口是否兼容、以及这个技能历史上的实际效用表现。检索完成后，系统会在三种路径里做出选择。

第一种是动态生成,也就是压根没检索到合适的技能，那就跟传统方法一样，现场从零构建工作流。第二种是直接执行,检索到的技能足够可靠，直接把它当作一个可调用的子程序执行,不需要模型重新思考怎么做。第三种是技能条件生成,检索到的技能有一定参考价值，但还不足以直接放心执行，这时候系统会把技能的结构化信息（比如函数签名、任务模式、一小段代码示例）作为上下文提供给生成过程，让模型"参考着写"而不是"照搬着跑"。

这三条路径的区分特别关键，因为论文明确指出,他们要证明技能积累带来的提升，不能简单归结为"直接复制之前存下的答案"这一种情况。换句话说，如果FlowEvo只靠第二条路径（直接执行）就拿到了所有的性能提升，那说明它其实只是个"缓存系统"，遇到一模一样的题就搬答案，遇到新题照样抓瞎。真正有价值的是第三条路径,技能即使不能直接复用，也能通过提供结构化线索，帮模型少走弯路。

论文里有个很能说明问题的案例。在ALFWorld测试里有个任务类型叫look_at_obj_in_light（在灯光下查看物体），这类任务的技能被检索匹配上了18次，但一次都没能通过直接执行完成任务,直接执行成功率是0%。可是即便如此，跟完全没有技能库的基线方法比，这个任务类型的表现依然提升了28个百分点。这说明什么？说明哪怕一个技能"用不了"，光是把它的结构信息喂给模型做参考，也能实实在在地提高成功率。这就是技能条件生成这条路径独立发挥作用的直接证据。

这里我想打个比方，帮大家更好理解这两种模式的区别。直接执行有点像你去修一台你以前修过的同款冰箱,拿出上次的维修记录，照着步骤原样再做一遍就行。技能条件生成则像是你去修一台没见过的新型号冰箱，但你手里有本厚厚的维修笔记，里面记着各种冰箱压缩机的常见故障模式和排查思路,你不能直接照抄，但这本笔记能让你少走很多弯路,比如提醒你先检查温控器，而不是上来就拆压缩机。如果没有这本笔记（也就是没有技能条件生成这条路径），你可能得把所有可能性从头试一遍，效率会低很多。

技能生命周期管理：防止"经验"变成"包袱"

这是我觉得整篇论文里设计得最巧妙、也最容易被忽视的一部分。

积累经验听起来天经地义是件好事，但论文里非常坦诚地指出了一个现实：技能积累并不总是有益的。有些技能可能表面上看起来管用，实际上会造成负迁移,也就是用了这个技能反而比不用效果更差。

负迁移：指之前学到的经验或技能，在应用到新场景时反而拖累了表现,不是没有帮助，而是产生了反作用，类似于学开手动挡车的习惯反而干扰了学自动挡车。

论文里给出了一个非常具体的翻车案例。在一次实验中，pick_two_obj_and_place（拿取两个物体并放置）这个任务类型对应的技能，在有技能引导的情况下成功率只有14%（14次里对了2次），而不用这个技能、完全靠模型自己现场发挥的情况下，成功率反而是33%（3次里对了1次）。这个差值是负的0.19，一旦低于系统设定的负0.1这个阈值，这个技能就会被判定为"有害"，触发抑制机制,自动被降级，不再参与直接执行的推荐。

这套机制叫对比评估（contrastive evaluation），具体做法是持续追踪每个技能被使用时的成功率，跟同类型任务里没用这个技能时的成功率做对比,如果这个差值持续为负，就说明这个技能其实在拖后腿，需要被抑制甚至清除出主动检索池。这个机制不需要人工标注哪个技能是好是坏，也不需要专门做留出实验（holdout experiment），完全靠系统自己在运行中持续监控。

如果没有这套机制会怎样？那个负迁移的技能会一直待在库里被反复调用，一次次把本该正确的任务带偏,库越攒越大，问题也越滚越多，最后这个"经验库"反而成了拖累系统表现的包袱。这就好比一个老师傅带徒弟时，教了一个当年好用但后来环境变了就不灵的老办法，如果没人及时纠正，这个错误经验会一代代传下去，越传越糟。有了对比评估机制，相当于系统会定期回头检查："这条经验最近还管用吗？"不管用了就赶紧摘掉，不让它继续误导后面的任务。

论文的消融实验（ablation study，也就是一步步拆掉某个部件看整体效果掉多少的对照实验）也证明了这套curation（技能生命周期管理）机制确实有真实贡献,单单加上这一层管理，成功率就提升了5个百分点,从80.6%涨到85.6%。

消融实验：科研中常用的验证方法，通过逐一去掉系统的某个组成部分，观察整体效果的变化幅度，从而确认每个部件各自的贡献大小。

实验结果：五大测试场景，全面领先

论文选择了五个覆盖不同任务类型的测试基准来验证FlowEvo，一个是交互式环境ALFWorld（文字版家务模拟环境，需要一步步操作完成任务），另外四个分别对应代码生成（HumanEval和MBPP）和数学推理（GSM8K和MATH-500）。

所有方法都用同一个基座模型GPT-4o-mini来测试，这样比较才公平,不然要是拿一个用了更强模型的方法去比一个用弱模型的方法，赢了也说明不了什么问题。论文对照了8个基线方法，包括经验学习类的ExpeL、自生成上下文示例方法，以及工作流优化类的ADAS、AFlow、MermaidFlow、EvoAgentX、DyFlow和ORCH。

| 方法 | ALFWorld 准确率 | HumanEval 准确率 | MBPP 准确率 | GSM8K 准确率 | MATH-500 准确率 |

| ExpeL | 46.3 | 89.0 | 73.8 | 92.1 | 67.5 |

| ADAS | 53.0 | 86.2 | 68.5 | 90.7 | 58.2 |

| AFlow | 59.2 | 87.2 | 65.5 | 91.4 | 63.5 |

| **FlowEvo** | **85.6** | **95.1** | **79.6** | **97.1** | **75.9** |

从这张表能看出来，FlowEvo在全部五个测试场景里都拿到了最高准确率，而且不是小幅领先，是全面碾压式的领先。特别是在ALFWorld这个场景，因为这里没有外部验证器可以借力（也就是没有像代码有单元测试那样的现成判断标准），全靠可执行技能的编译和复用来发力，这也是FlowEvo优势最明显的地方。

在代码生成和数学推理这类任务上，每道题目基本都是独一无二的，直接复用整套解法的机会不多，这时候起作用的主要是技能条件生成这条路径,把过去积累的解题模式当作提示信息，帮模型少走弯路。

跨模型规模测试：小模型受益最大

论文还做了一个很有意思的扩展实验，测试了从70亿参数到6710亿参数不等的10个不同基座模型，覆盖5个不同的模型家族，包括密集架构和混合专家（MoE）架构。

混合专家架构（Mixture-of-Experts，MoE）：一种模型设计方式，模型内部包含多个"专家"子网络，每次推理时只激活其中一部分，从而在保持模型总参数量很大的同时控制实际计算成本。

在这50组模型与数据集的配对测试中，FlowEvo在49组里都跑赢了ExpeL,平均领先11个百分点，中位数领先7个百分点。更有意思的规律是，在GPT-4.1这个模型家族的规模阶梯测试里（同一个模型家族，只是参数量从小到大依次是nano、mini、标准版），模型越小，FlowEvo带来的提升幅度反而越大。最极端的例子是在ALFWorld测试里，最小的GPT-4.1-nano模型，用了FlowEvo之后，比不用的时候提升了53.2个百分点。

这个现象背后的逻辑其实挺直观的。小模型自身推理能力有限，很多时候不是"不知道该做什么"，而是"知道该做什么但表达不出来、执行不稳定"。这时候如果有一份现成的、经过验证的可执行技能摆在面前，小模型只需要负责调用它，而不需要自己从头构思复杂的推理链条，效果自然会大幅改善。这就好比让一个刚学做饭的新手照着一份写得极其详细的菜谱做菜，跟让他自己凭空想怎么炒这道菜，结果肯定天差地别。反过来，如果模型本身已经很强，接近满分水平（比如在HumanEval和MBPP上，几个不同规模的GPT-4.1差距都很小），技能库能带来的边际提升自然也就有限,毕竟模型自己已经能想明白该怎么做了。

论文里也诚实地报告了唯一一个"翻车"的组合：Qwen3-8B这个较小模型在MATH-500（高难度数学推理测试集）上，用了FlowEvo反而比ExpeL低了10个百分点。分析下来的原因是，这个小模型在生成数学解题代码时经常写出不符合接口规范的内容，导致大量候选技能在准入审核阶段就被刷掉了，最后技能库太稀薄，没能积累起足够多的可用技能来支撑后续检索,相当于这个"新手厨师"写的菜谱本身就有问题，连质检这一关都过不了，自然存不进秘籍本里。

三大机制的独立贡献

论文做了一套循序渐进的消融实验，从最基础的ReAct方法（一种交替进行推理和行动、但完全不做经验积累的经典方法）出发，一步步加上FlowEvo的各个组件，看每一步带来多大提升。

| 阶段 | 加入的机制 | 成功率 | 相比上一步的提升 |

| 1 | ReAct 基线（无技能库） | 33.6% | — |

| 2 | + 工作流转技能的编译（只存不用） | 38.8% | +5.2 |

| 3 | + 技能反哺工作流（直接执行+条件生成） | 80.6% | **+41.8** |

| 4 | + 技能生命周期管理 | 85.6% | +5.0 |

这张表讲了一个很朴实的道理：光是把成功经验存下来（第二阶段），本身就能带来一点提升,大概5个百分点，因为提炼可复用结构这个过程本身就在规范模型的行为，让辅助的记忆和中间表征变得更清晰。但真正的爆发点在第三阶段,把存下来的技能真正用起来反哺后续任务,一下子从38.8%跳到80.6%，涨了41.8个百分点。这说明整个框架里，真正起决定性作用的是"技能能被用上"这件事，而不是单纯的"记住了"。第四阶段的技能管理再补上5个百分点，并且提供了一层重要的安全保障，防止坏经验持续作恶。

论文对这套系统的鲁棒性也做了压力测试。他们故意去掉编译时要求"轨迹必须验证通过"这个前提条件，结果成功率只掉了1.5个百分点（85.6%降到84.1%）；又故意把20%的成功失败标签故意翻转，制造噪声干扰，结果也只掉了1.7个百分点。用统计检验（McNemar检验，一种判断两组配对数据差异是否显著的统计方法）来看，这两种干扰都没有造成统计显著的差异。这说明FlowEvo这套两层验证机制,编译时靠验证器把关，使用中靠对比评估持续纠错,能够消化掉相当程度的上游噪声，不需要额外的干净标注就能稳定运行。

技能库并不是无限膨胀的。在整个134个ALFWorld任务的运行过程中，技能库最终稳定在7个工作流模板（对应6种任务类型再加一个通用模板）和18个具体示例，前28个任务就覆盖了5种任务类型，后面新增的内容非常有限。这说明去重和淘汰机制运转良好，技能库不会随着任务数量增加而无限膨胀，检索成本始终可控。

从积累曲线看变化过程

论文里画了一张很直观的曲线图，展示了在ALFWorld的134个任务里，随着任务一个接一个执行，token消耗和技能复用率是怎么变化的。

大约在第10个任务的时候，出现了第一次技能直接复用,从这一刻开始，每个任务消耗的token数量断崖式下降，并且此后一直维持在比ReAct基线更低的水平。到134个任务全部跑完，累计的直接复用次数达到101次，复用命中率稳定在大约75%左右，而且这101次直接复用里有99次都成功了，成功率高达98%。

这张曲线让我联想到一个很朴素的生活场景。一个新员工刚入职时，每件事都要问、都要摸索，效率很低，但随着他手头积累的"标准操作流程"越来越多，越到后面越轻车熟路，处理相似任务的速度会明显提上来。FlowEvo展现的正是这样一条学习曲线,只不过它把这个"越用越熟"的过程，量化成了具体的token消耗数字和复用命中率，让我们能清楚看到经验积累到底带来了多少实打实的效率提升。

这个方法建立在什么基础上，又推动了什么

FlowEvo这套思路并不是凭空出现的，它站在了好几条研究脉络的交汇点上。

比较直接的一个前身工作是Agent Workflow Memory（Wang et al., 2024b），这篇论文首先提出把工作流层面的经验存下来指导后续生成，但它存的是文本，FlowEvo在这个基础上往前走了一步，把存储对象从文字升级成了可执行代码。另一个方向是Sarukkai等人（2025）的工作，他们证明了即便是简单粗暴地积累自生成的轨迹当作上下文示例，也能改善序贯决策任务的表现,这提示了"积累经验"这件事本身的价值，只是文本记忆有它天然的局限。

在工作流优化这条线上，2024年出现的ADAS（自动化智能体系统设计，Hu et al.）和AFlow（Zhang et al.）都是很有影响力的方法，它们专注于搜索或优化当前任务的工作流结构本身,但这些方法优化出来的东西通常是"为了解决眼前这个任务"，做完就扔，没有把学到的结构留存下来供未来复用，这正是FlowEvo要弥补的空白。

再往前追溯，这类工作还能连到2023年Promptbreeder（Fernando et al.）和STOP（Zelikman et al.）这些更早期的自我进化研究,它们分别探索了让提示词自我演化、让代码脚手架自我重写的思路，为后来"训练无关的自适应"这整条研究路线打下了基础。

在FlowEvo之后，一些更细分的方向也在往前推进。比如Xia等人2026年的SkillRL研究，把技能积累和强化学习结合起来，探索递归式的技能增强训练。另外一篇更晚的工作MetaClaw，尝试让智能体在真实世界的持续使用中做元学习和自我进化，这些都可以看作是沿着"技能能持续自我更新"这条主线往前继续探索的产物。

这篇论文也很坦诚地承认了当前方法的边界。它目前依赖的场景，都是能够用环境反馈或隐藏测试来判断对错的领域，比如代码有没有跑对、数学答案对不对、家务任务完没完成。对于那些完全没有明确对错标准的场景，比如自由对话或者长篇写作，这套框架还没有直接验证过效果。另外，整套自我进化循环要能跑起来，也需要基座模型本身具备一定的能力，能够生成足够干净、能通过接口和安全检查的代码,前面提到的Qwen3-8B在MATH-500上的失败案例就是这个门槛的真实体现。

写在后面

读完这篇论文，最触动我的其实不是那些漂亮的准确率数字，而是那个14%对33%的翻车案例。研究者没有把这个负面结果藏起来，反而专门用来证明自己设计的对比评估机制确实有用。这种坦诚感很难得，因为大多数论文只愿意展示成功案例。

另一个让我反复琢磨的细节是look_at_obj_in_light这个任务,技能直接执行成功率是0%，但整体表现依然提升了28个百分点。这说明"经验"这个东西未必要以"直接可用"的形式存在才有价值，光是提供一个思路方向、一种任务模式的提示，就足够让模型少走很多弯路。这跟我们平时理解的"经验有用等于经验能直接照搬"其实是两码事，值得多想一层。

还有一个问题我没在论文里找到明确答案：当技能库规模真正膨胀到成千上万条的时候，检索和淘汰机制还能维持现在这种优雅的平衡吗？134个任务、18个技能条目，规模其实很小。如果放到一个真正长期运行、面对海量多样任务的系统里，这套对比评估和抑制机制会不会因为计算成本或者判断噪声而失灵？这大概是接下来最值得追问的问题。

Q&A

Q1：FlowEvo是什么？

A：FlowEvo是一个训练无关的智能体框架，它让工作流和可执行技能在推理时同步进化。智能体把成功完成的任务编译成可调用的技能存进技能库，后续任务可以直接执行这些技能或者把它们当作参考信息，从而不用每次都从零开始摸索解决方案。

Q2：FlowEvo和之前的经验记忆方法（比如ExpeL）有什么区别？

A：ExpeL这类方法把经验存成文字描述，模型只能参考文字重新推理，没法直接调用验证。FlowEvo把成功的工作流编译成真正可执行的代码，附带调用接口、测试用例和使用记录，既能直接运行也能作为结构化上下文使用，在ALFWorld等测试中准确率比ExpeL高出几十个百分点。

Q3：FlowEvo会不会因为积累了坏经验而越用越差？

A：论文专门设计了对比评估机制来防止这个问题。系统会持续比较某个技能被使用和不被使用时的成功率差异，如果差异持续为负（说明这个技能在拖后腿），就会自动抑制这个技能。实验中确实发现过一个负迁移案例并被成功抑制，避免了持续伤害后续任务表现。