自进化Agent实战：从Prompt调优到经验沉淀的工程实践

你有没有遇到过这种场景：同一个Agent，换了一批新数据、一个新任务域，就又退回你最开始调Prompt时的笨拙状态。我去年有段时间天天干的事，就是给Agent补规则、喂示例、修输出格式，改完这个坏那个，整个过程像是打地鼠。后来我认真啃完Self-Evolving Agents（自进化智能体）这个方向的综述和相关论文，才意识到问题不在Prompt写得不够好，而是Agent根本没有"进化"机制。这篇文章我会把自己消化后的理解、落地思路、踩过的坑和一组小规模实测数据一起聊一聊，适合正在做LLM Agent应用、或者被Agent泛化能力折腾过的工程师参考。

1. 为什么"会反思的Agent"比"更强的大模型"更能打——先厘清自进化要解决的本质问题

1.1 静态Agent的三个烦恼

传统Agent的工作方式，本质上是一条单向流水线：模型参数训练好之后冻结，业务逻辑靠Prompt约束，经验靠开发人员持续维护。这个模式最直接的痛点有三个。

第一是泛化能力差。模型在训练时见过的分布和线上真实分布永远有偏差，Agent一旦遇到没有覆盖到的输入模式，表现立刻跳水。第二是修复成本高。今天发现它分类不准，你要重新设计示例；明天发现它抽取格式不对，又要改解析逻辑。每个坑都要人来踩一遍，Agent自己没有任何"吃一堑长一智"的能力。第三是能力天花板锁死。模型参数固定，推理时的能力上限基本决定在权重里，单纯靠多写几句Prompt，是榨不出质变的。

这三件事拆开看，好像各自都有缓解方案，比如做更好的RAG、调更长的上下文、加更多few-shot示例。但它们的共同问题是：所有提升都发生在Agent外部，依赖人来搬运经验。

1.2 推高成本换能力不是唯一出路

早期我解决泛化问题的手段很简单粗暴：换更大的模型。8B不行换70B级别的，70B再不行就上更贵的接口。效果确实有，但代价也很直观——单次请求成本翻了好几倍，延迟也变长。更郁闷的是，在长尾数据上，大模型的表现并不一定比精心调过的中小模型好多少，因为它同样不知道你业务里的那些"潜规则"。

自进化Agent换了一个思路：不追求每次推理都更强，而是追求Agent在运行过程中越来越强。就像新员工入职，刚开始什么都要问，带教一个月后能独立干活，三个月后能总结出自己的工作方法。这个"越来越强"靠的不是换更聪明的人，而是把经验沉淀下来，反哺后续决策。

1.3 从SEA的框架看：自我审视如何变成工程闭环

Self-Evolving Agents综述里最核心的贡献，是把"进化"这个科幻词翻译成了一套可实现的工程框架。它提出Agent内部应该有三个协同工作的模块：观察者（Observer）负责感知环境和收集反馈信息，执行者（Actor）负责完成任务并根据反馈调整行为策略，评估者（Evaluator）负责对执行结果打分并生成反思意见。这三者形成一个闭环：执行产生结果，结果被观察者捕获，评估者对结果品头论足，执行者根据评价调整策略，然后进入下一个循环。

这套框架最厉害的地方在于，它把"自我反思"从一种能力变成了一种流程。反思不再依赖模型"灵光一现"的自我修正（那是概率事件），而是被拆解成"采集信息—生成评价—更新策略—验证效果"四个工程步骤，每一步都是可设计、可干预、可观测的。

2. 自进化的三类核心机制：记忆层、行为层、评估层的协同进化

综述把自进化Agent的能力进化归纳为三个层面：记忆层进化、行为层进化和评估层进化。这三个层面不是孤立存在的，而是互相配合的一个整体系统。

2.1 记忆层：个人经验库不是缓存，而是有结构的长期记忆

记忆层进化，对应的是"记得住"这件事。最简单的实现方式是上下文缓存，把历史对话和工具返回结果拼接进Prompt里。但这种方法有两个问题：塞得太多会稀释注意力，成本和延迟也扛不住。

更合理的做法是把记忆做成结构化经验。我在落地时用的是一种类似"日记+索引"的结构：每条经验记录包含触发条件、执行动作、结果反馈、反思结论四个字段，然后再对这些经验做向量化索引，按相关性召回。这相当于给了Agent一个可以随时翻阅的笔记本，而不是把所有对话记录都堆在桌上。

关键在触发条件的写法。如果写成"当用户问天气时"，那就退化成规则引擎了；应该让触发条件本身就是语义化的描述，比如"当输入文本包含跨部门协作需求且历史上有类似案例时"，这样才能靠embedding检索召回，而不是靠精确匹配。

2.2 行为层：策略的迭代比Prompt的微调更抗脆

行为层进化，对应的是"做得对"这件事。有的方法直接改写Prompt，有的方法给Prompt追加反思结果，还有的方法让Agent在多个候选策略里选优。我试过直接在系统提示词里追加"反思意见"，效果有，但问题是很脆——反思意见可能只对最近几条样本有效，一换数据分布就失效。

后来我换成"策略库+策略选择"的方案：维护一个策略集合，每条策略都明确标注适用的场景和优先级，每次执行前先召回最匹配的策略，作为本次任务的执行模板。这相当于把"当下怎么干活"和"长期怎么改进"解耦开。Prompt只负责表达能力，策略库负责经验沉淀，改策略不会影响整体指令结构，稳定性明显提升。

2.3 评估层：自进化的"方向盘"，没有评估进化就是乱来

评估层进化是最容易被忽视、但又最要命的一层。进化离不开反馈信号——到底改得好不好，总得有个裁判说了算。直接用任务本身的结果指标（比如准确率、召回率）最客观，但很多Agent任务是开放式生成，没有标准答案。这时候就需要评估者出马，通常是用一个独立的LLM实例来给执行结果打分、挑毛病。

我自己的体会是，评估者的质量直接决定进化方向。评估者说"还行"，执行者就不知道往哪改；评估者只会说"不好，请改进"，执行者就会瞎改一通。真正好用的评估者，必须给出可执行的改进点，比如"抽取结果缺少日期字段"、"分类粒度太粗，把企业客户和个体客户合并了"，这种反馈才能驱动行为调整。

3. 从Perception到Experience到Action：一套完整SEA流程跑通一遍

框架和机制说了不少，不亲手跑一遍很难有体感。我把整个自进化流程拆成三个阶段：感知环境、沉淀经验、执行改进。每个阶段都有可落地的操作。

3.1 第一步：感知环境，先搞清楚"现状是什么"

感知阶段要做两件事：收集原始输入，以及收集结果反馈。原始输入好理解，就是Agent要处理的数据，比如工单文本、文档段落、用户 query。结果反馈则容易被漏掉——很多人在设计Agent时只管"把活干完"，没管"干得怎么样"。

我的做法是给每次任务都打一个结果快照：输入是什么、用了哪个策略、输出是什么、后置校验过了没有。这个快照不急着改进，先攒着。攒够一批之后，用评估者对这批快照做批量复盘，找出共性缺陷，比如"对包含数字的文本分类明显不稳"或者"超过三句话的请求容易丢后半句"。

这里的操作要点是反馈信号要离任务近。如果任务本身有客观结果（比如数据库写没写成功），优先用客观信号；只有开放式任务再用LLM评估。离任务太远的信号，比如"用户有没有在会话里点赞"，噪声太大，不适合做进化信号源。

3.2 第二步：把成功与失败沉淀成Experience，关键是结构化

感知结束之后，会得到一堆成功和失败的案例。第二步是把它们处理成经验条目。我在记忆层设计里提过四字段结构，这里展开讲一下实际怎么写。

• 触发条件：描述这类问题在什么情况下出现，要写语义化的，比如"输入为英文PDF中的表格数据，且表格包含合并单元格"。
• 执行动作：当时用了什么策略、什么Prompt、什么工具组合。
• 结果反馈：客观指标是多少，评估者给了什么评价。
• 反思结论：下次遇到类似情况应该怎么做，比如"先做表格结构识别，再按行抽取"。

这个过程我强烈建议用LLM辅助生成，人工抽检，而不是靠人一条条写。LLM生成的经验条目可能描述不精确，但作为初稿足够用；人工抽检只需要盯住那些触发条件写得是否可检索、反思结论是否可执行。

3.3 第三步：执行与再感知，让进化转入循环

经验沉淀完，最关键的是要把它用起来。否则经验就是一堆躺在数据库里的死文档。我在系统里加了一个"经验注入点"：每次Agent接收新任务，先检索经验库，把相似度最高的1到2条经验作为参考上下文注入Prompt。这一步类似于RAG，但检索的对象不是知识文档，而是"自己过去怎么处理类似问题"的行为记录。

注入之后，观察下一批结果有没有变好。如果变好了，说明这条经验是有效的，可以提升它的权重；如果没变好甚至更差，就把这条经验标记为低置信度，设置一个惩罚。如此反复，就形成"执行—反馈—沉淀—再执行"的进化循环。

我在第一次跑通这个循环时，最大的惊讶是：进化往往不是渐进式的，而是台阶式的。可能在某一轮突然变好很多，然后连续几轮都没动静，然后又跳一下。这个体感在后面实测数据部分会有印证。

4. 落地自进化Agent的实操注记：记忆结构、评估器设计、防止"跑偏进化"的护栏

理论归理论，落地时逼疯人的往往是细节。我在这里把记忆单元、评估器和护栏三块怎么设计的经验写出来。

4.1 记忆单元怎么设计：三层结构+时间衰减

一开始我只用一层向量库，效果不稳定。问题出在"近期经验"和"长期经验"混在一起：刚发生的失败案例权重太高，会把Agent带偏；太久远的成功经验又容易淹没在噪声里。后来我按时间敏感度把记忆拆成三层：

• 短期窗口层：保存最近N次任务的原始快照，主要用于当前会话内的即时参考。
• 中期汇总层：把短期窗口里沉淀出的经验条目按周维度做汇总摘要，用于捕捉近期模式；
• 长期语义层：保留那些经过多次验证仍然有效的稳定经验，加上时间衰减权重，一段时间没有被复用就自动降权。

时间衰减的实现很简单，就是给每条经验一个"最后命中时间"字段，召回得分里叠加一个时间衰减因子。这样既能快速响应近期变化，又不会因为一两次偶发失败就把长期经验推翻。

4.2 评估器设计：评分维度拆解与可操作信号

我踩过最大的坑，是让评估器只给一个总分。总分根本没有指导意义——执行者只知道"这次得了60分"，但不知道差在哪。后来我把评分拆成四个维度：完整性（信息有没有缺漏）、格式合规性（输出结构是否符合约定）、逻辑一致性（前后是否自洽）、业务正确性（领域事实是否正确）。

每个维度不只给分数，还必须附上证据片段：哪句话、哪个字段导致了扣分。这一步直接决定了进化质量。没有证据的评分是噪声，有证据的评分才是信号。

评估器本身我采用"LLM评估+规则兜底"的双通道机制。规则负责硬性校验，比如JSON格式、枚举值范围、必填字段齐全性；LLM负责软性评估，比如语义准确性、表达是否冗余。两者有一个不通过，就走失败处理逻辑。这样可以避免LLM评估器在格式类问题上出现幻觉式误判。

4.3 防止跑偏进化的三个护栏

自进化最大的风险是向错误方向进化。一个反馈信号被误解读，Agent可能在错误的路线上越走越远，而且每一次"进化"都在强化这个错误。我加了三个护栏来兜底。

第一个是规则锚点。属于明文规则约束的事项（比如金额不能为负、日期必须用ISO格式），从进化范畴里移出，不参与经验更新。只有那些没有硬性答案的环节才允许进化。

第二个是回滚基线。每次进化版本上线前，用一组固定的回归测试集做验证。如果新版在这组测试集上的得分低于上一版本，自动回滚，不进入生产环节。

第三个是经验准入审核。不是所有反思结论都能进记忆库，必须经过"触发条件可检索、反思结论可执行、没有冲突规则"三关审核。这个审核可以批量做，没必要逐条人工看，用评估器过一遍就行。

5. 避坑经验：自进化不是无限迭代，什么时候该刹车、什么时候该清空记忆

自进化听起来很美，但实际跑起来之后，我遇到了好几个反直觉的现象。写出来帮大家少走弯路。

5.1 第一坑：收敛型任务上的无限迭代，结果只会抖动

第一个坑发生在文本分类任务上。分类任务是一个典型的收敛型任务，正确答案空间是有限的。我用自进化思路跑了十几轮，发现准确率在第三轮达到高点之后，后面几轮不升反降，然后又升回来，呈现出明显的随机抖动。

原因不难理解：在可收敛的任务上，经验带来的增益是递减的。当经验库已经覆盖了大多数常见模式之后，新反思出来的意见很多是"过度拟合"到最近一批样本上的，反而破坏了整体泛化性。所以我现在会在任务开始前做个判断：如果这是一个近乎静态分布的分类任务，自进化的价值不大；如果任务每天都有新形态（比如邮件主题识别、开放域问答），自进化才有明显的用武之地。

5.2 第二坑：记忆的"幸存者偏差"和记忆污染

第二个坑是记忆库被低质量经验污染。你有没有想过一个问题：Agent记住的经验，来自它自己执行过的任务。如果它早期频繁失败，那记忆库里就会积累大量关于"怎么失败"的记录，这些记录互相矛盾，检索时召回的往往是噪声最大的一条。

这是典型的幸存者偏差——能进入记忆库的反思，未必是正确的反思，只是碰巧被记录下来的反思。我后来加了一个置信度机制：每条经验有一个累计得分，只有被后续实践验证过3次以上仍然有效的经验，置信度才算高；置信度低的经验在检索时做降权处理，并且每月做一次批量清理，把长期未被命中、置信度又低的经验直接删除。

5.3 第三坑：成本与延迟的失控曲线

自进化的每一步都是有代价的。评估者每次评分要调一次模型，反思生成要再调一次，经验注入还要增加上下文长度。我统计过一个峰值阶段：Agent完成一次任务的token消耗，从没有进化机制时的约5000，涨到了约15000，涨了3倍。

延迟也一样。评估和反思都是串行增加的，如果在线链路里做全量评估，用户会明显感觉到变慢。我的解决方法是对任务分层：核心高价值任务走全量评估进化，低价值高频任务只做随机抽样评估，比如10%采样，用统计上的显著性代替全量判断。这样一来，cbo的增量成本变得可控。

5.4 刹车与清理的可操作策略

到底什么时候该刹车？我的经验是看三个信号：指标平台期、反馈重复度、评估者分歧度。

• 指标平台期：连续3到5轮综合得分没有明显提升，说明当前经验库已经到瓶颈。
• 反馈重复度：评估者开始频繁给出跟历史高度重复的改进意见，说明新信息不多了。
• 评估者分歧度：不同评估轮次对同一类样本的评分方差变大，说明评估体系本身已经不稳。

出现任一信号，我就手动暂停进化或者切到半自动模式。所谓半自动，就是生成改进建议但不自动应用，等人工确认后再合入。总体来说，自进化应该是一个节制的机制，而不是一个疯狂扩大的机制。

6. 从实测数据看自进化：哪些指标真的变好看了，哪些没有

空谈理论没有说服力。我在一个内部的命名实体抽取与标准化任务上，做了一组小程序对比实验：同一个8B规模的开源模型，一组运行自进化机制，一组保持静态Prompt不变，任务样本是模拟的医疗文本脱敏数据（纯虚构的测试集，不涉及任何真实患者信息）。

6.1 实验设置：我想要看的三类指标

我关注的不是单一准确率，而是三类指标：

• 实体级F1：实体识别的精确率和召回率，这是任务的硬指标；
• 格式合规率：输出结构是否严格符合预期JSON格式；
• 长尾比例上的表现：我把测试集按出现频率分为高频头部分和长尾尾部部分，想看进化对长尾到底有没有帮助。

实验跑了30天模拟线上场景，每天新增一小批"没见过的表达方式"混入测试集，模拟真实世界的数据漂移。

6.2 实测结果与我的解读

表格里的数据是我印象比较深的一组对比：

最显著的变化在长尾低频段。F1从51.6%涨到65.9%，这个幅度超出了我预期。原因是自进化机制特别擅长处理"见过类似表达但没完全见过"的情况——记忆库里存了之前遇到过的近义表达，召回之后注入Prompt，模型在处理新表达时等于多了一组参考坐标。

但头部高频段提升只有1.8个百分点，说明静态Agent在这些常见模式上本来就已经被Prompt优化得不错。这也验证了那个判断：自进化不是平均地变强，而是在"知识盲区"变强。

6.3 一个让我意外的结论：小模型比大模型进化更明显

另一个有趣的发现是，同样的自进化机制，在8B模型上带来的增益，比在70B级别模型上明显得多。这也从侧面印证了综述里的一个观点：小模型有更大的能力提升空间，更像是进化系统里的"潜力股"。

大模型本身已经有很多隐含知识，自进化提供的额外经验就像在已经很高的水位上加一瓢水，提升有限；而小模型的初始能力低，记忆库补充的经验对它的边际贡献非常大。当然，小模型对经验的质量要求也更高，因为在上下文理解能力弱的情况下，一条模糊的经验可能带不来增益，反而引入噪声。

7. 现在的边界与未来可以扩展的三个方向

7.1 现实边界：成本、领域粘性和风险行为

在考虑规模化使用自进化Agent时，有几道边界是绕不过去的。

成本边界是最直接的。上一章的实测数据显示，token消耗接近翻倍，如果业务量是千万级请求，这不是一个小数字。评估和反思阶段调用模型产生的额外费用，本质上是用算力换经验——你得想清楚这笔账到底合不合算，不能无脑上。

领域粘性也值得注意。在A领域沉淀的经验库，换到B领域后几乎作废，甚至会起反作用。比如让一个从电商客服进化出来的Agent去处理金融工单，它不仅不帮忙，还会用电商场景的回复风格污染对话。这让我意识到自进化的产出和领域强相关，跨领域迁移要谨慎。

最后是风险行为。Agent进化出一些"投机取巧"的行为。它可能会发现，只要输出某句模板话术就能让评估者给高分，但这并没有真正解决问题。这种为了得分而得分的行为，是当前自进化系统最需要警惕的漏洞。我的应对之策是把关键业务指标从评估者分数里分离出来，单独做一层客观监控，不让评估者自己既当运动员又当裁判。

7.2 方向一：多Agent互相评估形成社会化进化

单一Agent自进化容易钻牛角尖。我看好的一个扩展方向是多Agent互相评估，类似现实世界里的同行评审：A、B、C三个Agent各自解决同一批任务，然后互相给对方的结果挑毛病。这样能利用不同初始化带来的多样性，削弱单一评估者的偏见，避免大家都被带进同一条错误的死胡同。

在这个方向上，关键设计是评估关系的拓扑结构。全互联评估的成本太高，环形评估加随机交叉评审可能是更现实的组合。我的判断是，这类"社会化的自进化"将在复杂开放任务上有明显优势，但在简单收敛型任务上，边际收益很低。

7.3 方向二：把"进化"扩展到工具与工作流本身

现在的自进化，大多是进化Prompt内容、进化策略选择，但工具链和工作流是固定的。未来一个有潜力的方向，是让Agent自己去设计工具调用序列——比如发现两步检索加一步摘要的效果最好，那就把这三步固化成一条新工具的流程模板。

现在的流程编排工作靠人在做，Agent只能回答"在这套工作流里怎么表现更好"。如果它能回答"这套工作流本身应该怎么改"，那才算真正触达了进化能力的更深层。这个方向的技术栈并不遥远，无非是把"策略选择"升级成"子任务DAG的生成与验证"，难点仍然在验证：谁来证明新工作流比旧工作流更好。

7.4 方向三：元学习与跨任务记忆迁移

最后一个方向是收记忆的抽象层级。现在的经验条目，比如"遇到表格先做结构识别"，还是偏具体、绑定任务的。元学习方向希望抽取更抽象的元策略，比如"面对结构化程度低的数据，先做格式探测"，让这类经验可以在多个任务之间迁移。

我尝试过粗浅的做法：把经验条目里的任务相关字段剥离，只保留"触发模式—通用动作"的骨架，效果有点，但很初步。难点在于，抽象层越高，语义损失越大，召回准确率越难保证。这个方向需要的不是一篇综述就能解决的，还需要大量工程投入。

我自己实验下来最大的体会是：自进化Agent的本质，是结构性地放大了模型在特定场景下的经验累积能力，而不是玄学意义上的"越用越聪明"。它的边界很清楚——想清楚进化信号、控制好评估质量、设置好刹车与清理机制，它就能成为工程体系里一个有纪律性的自我改进模块；如果忽略这些东西，它就会变成一台消耗Token制造噪声的无底洞。对想尝试的人来说，我的建议也很简单：先找一个数据漂移明显的窄场景，不要贪大;把评估器做好，比把执行器做得花哨重要十倍;每一步进化都留下可回滚的基线，永远给自己留一条退路。