1. 从“模型训练”到“自我迭代”自进化 Agent 到底在解决什么问题很多人第一次听到“自进化 Agent”和“RSI”这两个词会觉得离自己很远像是实验室里的概念。但如果你最近在折腾 Agent 开发、工作流编排或者用 Coze、Dify、n8n 这类工具搭过稍微复杂一点的多步骤任务你大概率已经隐约碰到过它的边界了一个 Agent 跑完一轮任务之后除了留下日志和结果它本身没有任何变化。下次遇到同类问题它还是从零开始该踩的坑一个不落。这就是自进化 Agent 想解决的核心痛点。传统 Agent 的工作模式是“静态能力 动态执行”模型权重固定提示词固定工具集固定变的只是输入。而自进化 Agent 追求的是“执行即训练”让 Agent 在完成任务的过程中把经验沉淀回自己的提示词、工具选择策略、甚至模型参数里。RSI也就是 Recursive Self-Improvement递归自我改进是这条路径上更激进的一步Agent 不仅能改进自己还能改进“改进自己的能力”。我先把结论放在前面现阶段真正能落地的自进化绝大多数不是去改模型权重而是改工作流结构、提示词策略和记忆检索方式。深度强化学习那套端到端自我博弈对算力和环境要求太高个人开发者和小团队基本玩不动。所以这篇笔记的重点会放在“工程上可复现的自进化”上而不是纯理论。适合读这篇内容的人有三类一是已经会用 Coze、Dify、n8n 搭工作流但想让工作流自己越跑越好的二是做 Agent 开发想理解自进化机制怎么落到代码里的三是学深度学习想搞清楚 RSI 这个概念和实际工程之间的差距在哪。下面我会从设计思路、核心机制、实操落地、问题排查四个层面把这件事拆开讲。2. 自进化 Agent 的整体设计与思路拆解2.1 为什么大多数 Agent 是“一次性”的先看一个典型的工作流用户提问Agent 判断意图调用检索工具拿到上下文生成回答结束。整个过程里唯一被保存下来的通常只有对话历史。而对话历史在下一轮任务里要么被截断要么被塞进上下文窗口变成一堆越来越长的噪声。我实测过一个简历筛选工作流跑了两百多份简历之后Agent 对“三年经验”和“3 年工作经验”这种表述的识别还是不稳定。原因很简单它没有把“上次这种写法我判断错了”这件事变成一条可复用的规则。它只是把错误留在了日志里而日志不会自动变成能力。自进化的第一步就是打破这个“执行完就归零”的循环。你需要给 Agent 设计一个经验回流通道让执行结果不只是输出给用户还要输出给 Agent 自己。2.2 自进化的三个层次别一上来就想着改权重我把自进化按改动对象的深度分成三层从易到难层次改动对象实现难度典型手段L1 提示词自进化系统提示词、few-shot 示例低失败案例自动追加为反例L2 工作流自进化节点结构、工具选择、路由逻辑中根据成功率动态调整分支L3 参数自进化模型权重、策略网络高深度强化学习、自我博弈L1 是个人开发者最应该先做的。它的本质是把每次失败的任务自动提炼成一条约束追加到系统提示词里。听起来很朴素但效果立竿见影。L2 需要你的工作流本身是“可编排、可读写”的比如 Dify 的工作流可以通过 API 修改节点配置n8n 可以把工作流定义存成 JSON 再回写。L3 就是深度强化学习的领域了需要奖励函数、环境模拟、大量采样普通项目基本不需要碰。注意不要被“自进化”这个词带偏以为必须让模型自己训练自己。工程上 90% 的收益来自 L1 和 L2L3 是研究课题不是产品需求。2.3 RSI 的递归性到底体现在哪RSI 的关键词是“递归”。普通自进化是 Agent 改进自己的任务能力而 RSI 是 Agent 改进自己“改进任务能力”的那套机制。举个例子L1 阶段你写了一个脚本把失败案例转成提示词约束。这个脚本的规则是人写的。到了 RSI 阶段Agent 会去评估“这个提炼脚本本身好不好用”——比如它发现提炼出来的约束太啰嗦导致提示词膨胀、推理变慢于是它自己修改提炼脚本的规则让它输出更精简的约束。这就是递归改进的对象从“任务能力”上升到了“改进机制”。我在实际项目里做过一个简化版让 Agent 每周回顾一次自己的提示词库把重复的、矛盾的、长期没被触发的约束合并或删除。这个动作本身不需要模型训练只需要一个定时工作流加一个评估提示词但效果很明显提示词长度降了三分之一任务成功率反而升了。2.4 方案选型为什么我推荐“外置记忆 规则引擎”而不是端到端端到端的自进化理论上最优雅但工程上最难调试。你不知道它为什么变好也不知道它为什么变差。而“外置记忆 规则引擎”的方案把进化过程显式化经验存在向量库或结构化表里进化规则写在代码或工作流里每一步都可追溯、可回滚。我踩过的一个坑是早期我让模型自己决定要不要把某条经验写进长期记忆结果它把大量一次性的、场景特定的信息也写了进去导致记忆库污染检索出来的全是噪声。后来改成“规则引擎先过滤模型再提炼”稳定性好了很多。规则引擎负责判断“这条经验是否具备跨任务复用价值”模型负责把有价值的经验转成自然语言约束。分工明确各司其职。3. 核心细节解析与实操要点3.1 经验采集什么该记什么该扔自进化的原料是经验但不是什么经验都值得记。我总结了一个筛选标准按优先级从高到低重复失败同一类错误出现两次以上说明是系统性问题必须记。边界成功在极端输入下依然成功的案例说明策略有效值得固化。用户纠正用户明确说“不对应该是这样”这是最高质量的信号。普通成功正常完成的任务除非有特殊策略否则不记记了就是噪声。采集方式上我建议在每次任务结束时加一个“复盘节点”。这个节点不参与主流程只做一件事判断本次执行是否触发了上述任一条件。触发则写入经验库不触发则丢弃。这个判断可以用一个轻量模型来做也可以用规则匹配比如检测输出里是否包含“错误”“重试”“修正”等关键词。提示经验库一定要带时间戳和命中次数。时间戳用于淘汰过期经验命中次数用于判断经验的价值。一条经验如果半年没被检索到基本可以归档了。3.2 经验提炼从“日志”到“约束”的转换原始经验是日志是“用户问了 X我答了 Y结果错了”。这种形式没法直接用于改进。你需要把它转成约束形式是“当遇到 X 类情况时应该做 Z而不是 Y”。这个转换过程我试过两种方案。一种是纯提示词让模型读日志、写约束。优点是灵活缺点是输出不稳定有时候写得太泛有时候写得太窄。另一种是模板填充先定义约束的槽位触发条件、错误动作、正确动作、适用范围让模型只负责填槽。后者稳定性明显更好因为结构被固定住了。我现在的做法是混合模板负责骨架模型负责语义。比如触发条件这个槽模板要求必须包含“输入特征”和“判断依据”两部分模型填完之后我再用一个校验节点检查是否两者齐全。不齐全就打回重填最多重试三次。3.3 经验注入怎么让 Agent 用上这些约束经验提炼出来之后怎么注入到 Agent 的执行流程里是个关键问题。全量塞进系统提示词是最简单的但提示词会越来越长推理成本上升而且模型对长提示词中后段的注意力会下降。我实测下来最有效的方式是按需检索 分层注入。具体做法是把约束按领域分类存进向量库。每次任务开始时先用任务描述去检索最相关的 5 到 10 条约束只把这部分注入到当前轮的提示词里。这样既保证了相关性又控制了长度。分层注入的意思是约束分两级一级是“硬约束”比如安全规则、格式要求永远注入二级是“软约束”比如特定场景的处理技巧按需注入。硬约束数量控制在 10 条以内软约束动态检索。这个比例是我反复调出来的硬约束太多会僵化太少会失控。3.4 工作流自进化的实现要点如果你用的是 Dify 或 n8n 这类可编程工作流工具L2 级别的自进化是可以做的。核心思路是把工作流的定义节点、连线、参数当成数据让 Agent 能够读取和修改。具体来说你需要暴露两个接口一个是“读取当前工作流结构”一个是“提交修改后的工作流结构”。Agent 在复盘时如果发现某个分支的成功率持续偏低就可以提出修改建议比如调整路由条件、替换工具、增加重试节点。修改建议经过人工审核或自动测试后再回写到工作流定义里。这里有个坑不要让 Agent 直接改生产环境的工作流。我一般会维护一个“影子工作流”Agent 的修改先应用到影子上跑一批测试用例通过率不低于当前版本才允许上线。这个机制借鉴了灰度发布的思想能有效防止自进化把系统改崩。4. 实操过程与核心环节实现4.1 环境准备与基础组件我用的技术栈比较轻量不需要 GPU 集群一台普通云服务器就能跑。核心组件如下工作流引擎Dify 或 n8n负责编排任务流程。向量库Chroma 或 Qdrant存经验约束做相似度检索。结构化存储SQLite 或 PostgreSQL存经验元数据时间戳、命中次数、状态。复盘模型任意中等规模模型负责经验提炼和约束生成。调度器cron 或工作流自带的定时触发负责周期性回顾。这套组合的好处是全部可自托管数据可控成本低。我试过用纯 API 方案但经验库的读写频率很高走 API 延迟太大还是本地组件靠谱。4.2 复盘节点的完整实现复盘节点是整个自进化循环的入口。它的输入是本次任务的完整轨迹用户输入、Agent 的每一步动作、工具返回、最终输出、以及如果有的话用户反馈。处理流程分四步触发判断检查是否满足采集条件重复失败、边界成功、用户纠正。不满足直接结束。经验提炼把轨迹喂给复盘模型按模板生成约束草稿。约束校验检查草稿是否包含触发条件、错误动作、正确动作、适用范围四个要素。缺失则重试。写入经验库校验通过后生成向量嵌入连同元数据一起写入。这里的关键参数是重试次数和超时时间。我设的是最多重试 3 次单次超时 30 秒。超过就放弃记录一条“提炼失败”的日志不影响主流程。实测下来提炼成功率在 85% 左右失败的多数是轨迹太短、信息不足的情况。4.3 约束检索与注入的代码示例检索环节我用的相似度阈值是 0.75低于这个值的约束不注入。这个阈值是调出来的太低会引入无关约束太高会漏掉相关约束。注入时按相似度排序取前 8 条加上硬约束总长度控制在 2000 token 以内。def retrieve_constraints(task_description, top_k8, threshold0.75): embedding embed(task_description) results vector_store.search(embedding, top_ktop_k * 2) filtered [r for r in results if r.score threshold] filtered filtered[:top_k] hard get_hard_constraints() return hard [r.text for r in filtered]注入的位置也有讲究。我试过放在系统提示词开头、结尾、以及用户消息之前。实测放在系统提示词末尾、用户消息之前效果最好因为模型对靠近当前任务的信息注意力更集中。4.4 周期性回顾与约束清理约束库不能只增不减。我设了一个每周运行的回顾任务做三件事合并重复相似度高于 0.9 的约束合并成一条。淘汰低效命中次数为 0 且创建超过 90 天的约束归档。检测矛盾两条约束如果对同一触发条件给出相反动作标记出来人工确认。这个回顾任务本身也是一个工作流可以用同一套复盘机制来优化。比如它发现“合并阈值 0.9 导致有些该合并的没合并”就可以建议调整阈值。这就是 RSI 的雏形改进机制本身也在被改进。4.5 效果验证怎么知道自进化真的有用不能凭感觉说“好像变好了”。我设了三个指标指标含义目标任务成功率一次通过的任务占比周环比不下降平均重试次数完成任务的平均重试轮数周环比下降约束命中率注入的约束被实际用到的比例保持在 30% 以上约束命中率这个指标特别重要。如果注入的约束很少被用到说明检索不准或者约束写得太泛。我遇到过命中率掉到 10% 的情况排查发现是约束库被一批场景特定的经验污染了清理之后恢复到 35%。5. 常见问题与排查技巧实录5.1 经验库污染最常见的翻车现场症状是Agent 开始出现一些莫名其妙的“坚持”比如非要按某种格式输出但那个格式只适用于某个特定场景。原因通常是经验采集时没有做场景隔离把一次性的特殊处理当成了通用规则。排查方法随机抽 20 条约束人工判断是否具备跨场景复用价值。如果超过 5 条不具备说明采集环节的过滤太松。解决方法是加强触发判断特别是“边界成功”这一类要严格限定“极端输入”的定义不能随便一个成功案例都算。5.2 提示词膨胀导致推理变慢约束越积越多提示词越来越长推理延迟肉眼可见地上升。我遇到过提示词从 1500 token 涨到 6000 token延迟翻了一倍多。解决办法就是前面说的分层注入和定期清理。另外约束的表述要精简。我要求每条约束不超过 50 个字超过就拆成多条或者压缩。这个要求写进了提炼模板里模型生成时会自动遵守。5.3 自进化把系统改崩了这是 L2 级别自进化最容易出的问题。Agent 改了一个路由条件结果导致某个分支永远走不到或者陷入死循环。我的应对策略是三道防线第一所有修改先应用到影子工作流第二影子工作流必须跑通全部回归测试用例第三上线后监控关键指标异常自动回滚。这三道防线缺一不可我因为偷懒跳过第二道吃过一次亏一个分支被改得永远返回空跑了半天才发现。5.4 常见问题速查表问题可能原因排查动作解决方向约束命中率低检索阈值不当 / 约束太泛抽查注入的约束与任务的相关性调整阈值精简约束表述任务成功率下降约束矛盾 / 注入过多检查是否有互斥约束启用矛盾检测控制注入数量复盘节点超时轨迹过长 / 模型响应慢查看轨迹长度和模型延迟截断轨迹换更快的模型经验库增长过快采集条件太松统计每日新增约束数收紧触发判断增加人工审核自进化后行为异常工作流被改坏对比修改前后的工作流定义回滚加强影子测试5.5 几个我踩过的坑和对应的技巧第一个坑是“过早优化”。我一开始就想做 L2 的工作流自进化结果基础的经验采集和提炼都没做好改出来的工作流一塌糊涂。后来退回去先把 L1 做扎实跑了两个月成功率稳定了再碰 L2顺利很多。所以顺序很重要L1 是地基。第二个坑是“忽视负样本”。早期我只记录失败案例后来发现有些成功案例里的策略也很值得固化比如某个工具在特定输入下比默认工具更高效。所以采集要正负兼顾不能只盯着错误。第三个技巧是“给约束打标签”。每条约束除了内容还打上领域标签如“格式”“工具选择”“边界处理”。检索时可以按标签过滤精度更高。这个标签体系不用很复杂五六个大类就够了太细反而增加维护成本。第四个技巧是“保留人类否决权”。自进化再自动也要留一个开关让人能一键禁用某条约束或回滚某次修改。我现在的系统里所有自动生成的约束默认是“待观察”状态命中三次且没有负面反馈后才转为“生效”。这个缓冲期能挡掉大部分误判。6. 关于 RSI 的一点个人判断把 L1 和 L2 跑顺之后我确实动过念头去碰 L3也就是让模型自己更新策略网络。但算了一笔账就放弃了要构造一个稳定的奖励环境需要大量模拟任务要训练策略网络需要 GPU 和时间要验证效果需要对照实验。这套成本对个人项目来说不现实。我的判断是RSI 在工程上的现实形态短期内就是“机制的自省”而不是“权重的自训”。Agent 能评估自己的提示词库、工作流结构、检索策略并做出可验证的改进这已经是很有价值的递归了。至于真正的权重级 RSI等工具链和算力成本降下来再说。如果你也在做类似的事情我的建议是从最小闭环开始一个复盘节点一个经验库一个检索注入环节。跑通之后再逐步加清理、加标签、加影子测试。别一上来就追求全自动半自动加人工审核反而走得更稳。