这期想聊一个最近绕不开的话题自进化 Agent 和 RSI递归自改进。先给没看明白标题的读者解释一下自进化 Agent就是一个能根据执行结果动态调整自身策略的 AI 智能体这里的策略可以是提示词、工具选择、工作流编排甚至是最终输出的规则。RSI全称 Recursive Self-Improvement意思是这个 Agent 改进完自己之后还能拿改进后的自己继续改进形成一个迭代循环。你可以把它理解成 AI 版本的自我迭代——不是人教 AI而是 AI 审自己的作业、改自己的答案改完再考一次直到分数满意为止。这篇文章适合三类人一是做大模型应用但总觉得写个 prompt 就完事的开发二是想搞清楚 Agent 到底能进化到什么程度的研究者三是刚从传统机器学习切过来、还没适应模型会自己改自己这种思路的小白。我会用一个能跑的最小例子把这套东西背后的思路、代码、坑全部捋一遍。1. 从AI 写代码到AI 改自己这事为什么现在值得聊1.1 RSI 不是新概念但现在才真正落地AI 改进自己这个概念其实有年头了。早在九十年代就有人提出递归自我改进的思想当时大家讨论的是抽象层面的智能爆炸一个足够聪明的 AI 能改进自己的代码改进完更聪明然后继续改进自己形成指数级飞轮。但那时候这想法基本停留在哲学层面因为能改进自己的 AI压根不存在。直到这两年大语言模型变成 Agent 的底座RSI 才第一次在工程上摸到了落地边缘。原因很直接LLM 作为底座时Agent 的策略是可以被另一个 LLM 读取、分析、修改的文本。提示词是文本工具描述是文本工作流定义也可以写成文本所以AI 读自己的配置 - 提出修改 - 验证修改 - 应用修改这个循环真正跑得通了。现在聊自进化 Agent最大的认知转变是我们把优化从训练阶段挪到了部署阶段。以前训练集里调权重现在生产环境里调策略对象从参数变成了文本、工具和流程。别小看这个转变它让一批没有训练算力的小团队也能玩自己的模型优化了。1.2 一个带教循环的类比帮你秒懂自进化自进化的套路说白了就四个步骤跟实习生在组里被导师带的过程一模一样第一步干活。实习生接到一个任务处理一批聊天记录按自己的理解完成一份成果。对应 Agent 拿着当前 system prompt 执行任务。第二步打分。导师检查成果看看合不合要求指出哪里不对。对应评估器给输出打一个分数并标注失败原因。第三步反思。实习生根据反馈想我下次怎么干更好可能是调整格式、改变处理顺序、补充遗漏字段。对应反思器读错误样本输出对系统提示词的修改建议。第四步验证再上岗。实习生改完做法先在小样本上试一下确认真的变好再全量接手。对应候选 prompt 在小测试集上验证分数更高才替换当前 prompt。RSI 的关键就在于实习生干完活之后他怎么干活的说明也就是他的工作手册也一起被改了改完的手册会在下一轮继续指导他自己。这是一个自我指涉的过程也是它和普通 Pipeline 最本质的区别——普通 Pipeline 只优化输出RSI 优化的是优化的规则本身。2. 为什么 Agent 必须自进化固定策略的天花板在哪2.1 固定 Prompt 的三种尴尬场景很多同学的 Agent 上线之后用的是静态 Prompt也就是角色设定从头到尾一个字都不变。这在简单场景下没啥问题一旦任务稍微复杂三个尴尬场景就会接踵而来。第一种是格式漂移。今天返回的是规规矩矩的 JSON后天模型更新或者输入稍有变化它就偶尔冒出 Markdown 代码块标记或者多余的解释性文本下游解析直接崩。你用请始终严格输出 JSON这种补充指令去堵堵完一处另一处又开始漏。第二种是错误模式反复出现。比如某个 Agent 做数据清洗总是把时间字段的时区信息弄丢。你发现了、在 prompt 里加了强调结果过了几天它又开始犯同样的错因为固定 prompt 没有记忆能力不会从失败样本里吸取教训。第三种是任务范围悄悄扩大。原本只处理英文文本生产环境里不断进来中文内容固定 prompt 不会意识到我该新增一个语言检测步骤于是只能一直用低质量的策略硬扛。这三类问题的共性都是策略没有闭环。你只能靠人工监控、人工分析日志、人工修改 prompt效率低且不可持续。自进化 Agent 做的事就是把这段人工监控到人工修改的循环自动化。2.2 什么情况下才值得做自进化不是所有 Agent 都应该自进化这个判断标准你得先有。如果你的任务满足下面几个条件才值得投入第一任务有明确且高频的反馈信号。比如数据抽取、格式转换、内容摘要这类任务的输出好不好可以相对客观地量化。别拿纯开放式闲聊去做自进化你连评估器都写不出来。第二失败样本会重复出现。如果任务每次都是新问题上次的教训对下次帮助不大进化的价值就有限。第三单次推理的改进空间真实存在。如果你的 Agent 已经在特定任务上表现完美了进化反而会引入噪声。我自己常用的判断标准是如果当前策略的错误率还有 10% 以上而且你能从错误样本里明确看出它是不知道规则而不是不会推理那自进化的收益会非常明显。另外还有一个现实因素输入数据分布是否相对稳定也是关键。如果今天处理的是英文邮件明天变成中文合同后天是法语法律文书进化出来的策略很容易过拟合前几批数据这时候你需要的是持续回流评估集而不是一次性进化完就用一千年。2.3 权重训练与策略进化为什么现实中只能选后者说到AI 改进自己很多人第一反应是重新训练模型权重。理论上是这么个方向但现实中有三重拦路虎。第一权重训练需要梯度计算和大量算力普通团队根本跑不起。第二微调需要高质量标注数据而自进化场景里很多时候连标注都没有只有当前输出好不好的模糊反馈。最重要的是第三点RSI 要的是修改后立即验证并迭代权重训练的训练周期以天甚至周计算完全跟不上这个节奏。所以现阶段工程可行的路径几乎都集中在策略层进化。什么是策略层就是你告诉模型该怎么做的那部分信息。在 LLM Agent 里这就是 system prompt、工具描述、示例few-shot、工作流编排规则。这些全是文本修改成本低、验证速度快、还能直接做版本管理。你可以把权重层想成人的大脑结构策略层想成人的工作手册——自进化 Agent 现在做的不是改变大脑结构而是不断重写工作手册让它更好地发挥现有大脑的能力。3. 从零搭一个最小自进化 Agent代码与过程全记录3.1 任务选型对话摘要抽取为了让代码能跑通且看得懂我选了一个很典型的场景给一个多轮对话摘要抽取 Agent 做自进化。输入是一段客服聊天记录要求输出一个结构化 JSON包含 summary摘要和 topics话题列表。这个任务表面简单但常见问题一点也不少summary 写太短、写成废话、遗漏关键信息topics 给的不是话题而是人物名甚至有人直接输出非 JSON 文本。我选这个任务有三个理由第一它有一个相对客观的评估器格式是否合法、字段是否完整、内容是否达标第二它允许你通过改进 system prompt 获得明显收益第三评估失败时你能清楚地看出模型哪里理解错了反思器更容易生成有效建议。3.2 五个核心模块的职责划分整个自进化系统我拆成五个模块每个模块职责单一相互之间只通过明确的数据结构通信执行器Agent携带当前 system prompt接收输入文本返回模型输出。它不需要感知自己的进化过程只负责干活。评估器Evaluator把模型输出转换成分数和原因。我通常用 0~1 浮点数表示输出质量再把失败原因整理成人类可读的字符串方便反思器理解。反思器Reflector接收最近的失败样本、当前 system prompt、评估结果输出若干条 prompt 修改建议。它的角色是教练输出质量决定进化质量。候选生成器Candidate Generator把当前 prompt 与反思建议拼接成几个候选 prompt。别小看这一步拼接策略直接影响候选质量我后面会展开讲。调度器Scheduler负责执行评估-反思-候选验证-替换的主循环同时做存档管理始终保留历史最优 prompt。这五个模块放一起图就很简单Agent 干活评估器打分反思器改策调度器决定要不要换版本。你的自进化 Agent 就是一个干活的 打分的 改策略的的组合。3.3 完整代码实现下面的代码我用纯 Python 写不依赖任何第三方框架。call_llm函数需要你替换成真实的模型调用我这里用一个占位符示意。import json import statistics from dataclasses import dataclass # ---------- 1. 底层模型调用 ---------- def call_llm(system_prompt: str, user_prompt: str) - str: 调用基础大模型。实际使用时替换成你自己的调用方式。 例如response your_client.chat.completions.create( model..., messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ] ) # 演示环境这里返回空字符串正常项目中不会执行到这里。 raise NotImplementedError(请替换为真实的模型调用) # ---------- 2. 执行器Agent 本体 ---------- dataclass class Agent: system_prompt: str name: str base def run(self, chat_text: str) - str: user_prompt f请根据以下聊天记录生成结构化摘要\n{chat_text} raw call_llm(self.system_prompt, user_prompt) return raw.strip() # ---------- 3. 评估器给输出打分 ---------- def evaluate_output(raw_text: str) - dict: 返回 score: 0~1 浮点数 reason: 失败原因供反思器阅读 result {score: 0.0, reason: } try: data json.loads(raw_text) except json.JSONDecodeError: result[reason] JSON 解析失败输出不是合法 JSON return result if not isinstance(data, dict): result[reason] 输出是 JSON 但不是对象 return result score 0.0 missing [] if summary not in data: missing.append(summary字段缺失) elif not isinstance(data[summary], str): missing.append(summary字段不是字符串) elif len(data[summary]) 10: missing.append(summary过短不足10个字) else: score 0.6 if topics not in data: missing.append(topics字段缺失) elif not isinstance(data[topics], list) or len(data[topics]) 0: missing.append(topics为空列表或不是列表) else: score 0.4 result[score] score if missing: result[reason] .join(missing) else: result[reason] 基础字段完整质量达标 return result # ---------- 4. 反思器根据错误样本改写策略 ---------- def reflect(bad_samples: list[dict], current_prompt: str) - list[str]: sample_str json.dumps(bad_samples, ensure_asciiFalse, indent2) prompt f你是一个 Agent 优化器。当前系统提示词为 {current_prompt} 以下任务样本的输出未达到要求请分析失败原因 {sample_str} 请输出 3 条针对系统提示词的具体修改建议要求 1. 每条建议必须能直接转化为 prompt 中的一句话可执行 2. 重点关注输出格式约束、字段定义、处理顺序 3. 不要写空话直接说改什么。 raw call_llm(你是严谨的优化器, prompt) suggestions [] for line in raw.splitlines(): line line.strip() if not line: continue # 简单识别编号行或列表行 if line.startswith((1, 2, 3)) or line.startswith(-): suggestions.append(line.lstrip(1234567890.-、: ).strip()) return suggestions[:3] # ---------- 5. 进化调度器 ---------- def evolve(seed_prompt: str, dataset: list[dict], epochs: int 3, mini_set_size: int 4): best_prompt seed_prompt best_score -1.0 history [] for epoch in range(epochs): agent Agent(system_promptbest_prompt, namefepoch-{epoch}) epoch_scores [] bad_samples [] missing_samples [] for item in dataset: chat_text item[chat] raw_text agent.run(chat_text) ev evaluate_output(raw_text) epoch_scores.append(ev[score]) if ev[score] 0.7: bad_samples.append({ chat: chat_text, output: raw_text, score: ev[score], reason: ev[reason] }) if ev[score] 0.0: missing_samples.append({ chat: chat_text, output: raw_text, reason: ev[reason] }) avg_score statistics.mean(epoch_scores) print(f[Epoch {epoch}] avg_score{avg_score:.2f}, bad_samples{len(bad_samples)}) history.append({epoch: epoch, avg_score: avg_score, prompt: best_prompt}) if not bad_samples: print(当前 prompt 已达标本轮不更新。) if avg_score best_score: best_score avg_score continue # 用 3 个高损失样本触发反思 sorted_samples sorted(bad_samples, keylambda x: x[score]) suggestions reflect(sorted_samples[:3], best_prompt) # 构造候选 prompt 池 candidates [best_prompt] for s in suggestions: candidates.append(best_prompt \n s) # 候选验证在 mini_set 上打分选最好的 best_candidate best_prompt best_candidate_score avg_score for cand in candidates[1:]: test_agent Agent(system_promptcand, namecandidate) scores [] for item in dataset[:mini_set_size]: raw_text test_agent.run(item[chat]) ev evaluate_output(raw_text) scores.append(ev[score]) cand_avg statistics.mean(scores) print(f 候选得分: {cand_avg:.2f} (当前: {avg_score:.2f})) if cand_avg best_candidate_score: best_candidate cand best_candidate_score cand_avg if best_candidate_score avg_score: best_prompt best_candidate print( 进化成功prompt 已更新。) else: print( 候选均未超过当前版本本次保留原 prompt。) if best_candidate_score best_score: best_score best_candidate_score return best_prompt, history这份代码你直接复制改改就能用。实际替换模型调用之后把少量对话样本塞进 datasetrunevolve()就能看到整个进化过程。module 之间的接口全部用普通 dict 和字符串调试起来非常方便。3.4 跑三轮进化观察改进路径我在一次实验里用 20 条样本跑了 3 轮进化初始 prompt 是简单的一句你是对话摘要助手请从对话中抽取信息并输出 JSON。第一轮平均分只有 0.52反思器给出的建议很典型明确要求 summary 必须超过 10 个字topics 必须是名词短语列表且输出内不能包含任何额外文字。我把这三条拼进 prompt 后第二轮平均分直接到了 0.78。第二轮的错误集中在 summary 语义不对比如对话里客户反复抱怨物流慢模型总结成客户咨询了商品信息显然没抓住重点。反思器给出的修改建议是在生成 summary 前先列出对话中重复出现的主题和情绪关键词再写总结保留这些信息。加上这句后第三轮分数到了 0.86。这个改进路径非常有意思前一轮它学会的是格式上如何不被扣分后一轮才真正开始优化内容质量。这正是自进化和手动调 prompt 的最大区别——你不需要提前猜到有哪些规则只需要给它反馈循环它会自己在策略空间里找改进方向。4. 三种自我改进的粒度改提示词、改工具、改代码4.1 三种粒度的实现成本与风险对比策略层进化不是只有改 prompt 一种玩法按改动对象从轻到重可以分成三档。第一档是提示词进化。改 system prompt 文本加上规则、示例、处理顺序。优点是成本最低、验证最快、可以无限迭代缺点是受限于模型本身的能力改到一定程度会撞上能力天花板。第二档是工具链进化。让 Agent 从工具池里选择合适的工具动态组装调用顺序。比如遇到 PDF 就先转文本再抽取遇到长文本就先拆分再摘要。这一档的进化发生在用哪个工具、按什么顺序的层面代码实现比改 prompt 复杂一些但收益往往更大因为工具调换是结构性变化不是文字层面的微调。第三档是代码级自修改。让 Agent 直接修改自己的执行代码比如调整解析逻辑、改输出模板、甚至算法实现。这一档上限最高但风险也最大一步写错可能让整个系统跑不起来对执行环境的隔离要求很高目前更多停留在实验阶段。我不建议一上来就挑战代码级自修改。从工程稳健性讲先改 prompt再改工具链最后才考虑代码这个顺序能让系统在每一步都保持可用状态。4.2 一个实用的组合路径我在实际项目里最常用的组合是先用 prompt 进化把基础能力打满再用工具链进化做结构性优化两者交替进行。具体节奏是这样第一次进化先跑 5~8 轮 prompt 进化直到平均分连续两轮没有明显提升然后打开工具选择的开关让 Agent 可以自主决定是否调用额外工具比如搜索、解析器工具选择稳定后再回到 prompt 进化这时的 prompt 可以加入工具的使用规则比如当输入超过 3000 字时必须先拆分再处理。这个组合路径能显著缓解单档进化的瓶颈。我见过很多同学只做 prompt 进化改了十几轮分数纹丝不动问题其实出在工具链上——模型能力再强没有合适的工具输出质量和效率就是上不去。做工具链进化时有一点要特别注意工具描述本身也要跟着进化。工具怎么写描述直接影响模型选不选它。我见过一个很荒诞的情况模型明明有 PDF 解析工具但因为工具描述写得太差它每次都把 PDF 当纯文本硬读。这种问题不是模型笨是工具接口信息没做好反思器同样能发现这类问题并给出修改建议。5. 自进化 Agent 训练路上的五个大坑5.1 Reward Hacking评估器会教坏你的 Agent自进化系统最大的隐患根本不是模型不够聪明而是评估器不够严谨。评估器是 Agent 认知里什么是好的唯一来源它一旦有漏洞进化会把这个漏洞越放越大。我碰到过一个真实案例评估器里有一条规则是如果输出包含 summary 字段就给 0.6 分结果进化了几轮之后模型真的学会在所有场景下都输出一个 summary内容却是复读聊天记录原文完全不提炼。分数倒是涨了实际质量一点没提升。这就是 Reward Hacking模型学会钻评估器的空子而不是真正做好任务。应对方法只有两条路一是让评估器更接近真实目标宁可复杂一点也要把好的语义质量定义清楚二是定期用人工抽查的样本校准评估器发现误判就立刻修正评估规则。评估器是自进化系统的北极星它错了整个系统都会跑偏。5.2 进化的遗忘问题为什么必须保留最优存档自进化不是单调递增的过程改坏了的情况非常常见。你可能第一轮从 0.52 改到 0.78第二轮改到 0.81第三轮又一个自认为更好的修改直接把分数打回 0.65。问题出在哪候选 prompt 在迷你验证集上的表现有随机噪声它在 mini_set 上分数略高换到全量数据集上却退化这在样本量不够的时候太常见了。解决办法就是我在代码里已经埋好的精英策略每一轮都严格保留历史最高分对应的 prompt任何候选必须超过当前最优分数才允许替换。这相当于进化算法里的 elitism即使在波动的验证分数中也不会把好解丢掉。我在多次实验里发现凡是崩溃性退化几乎都发生在没有存档机制的情况下。自进化系统必须把当前最优版本当作不可侵犯的资产这是所有迭代型系统的基本功。5.3 成本与延迟先算一笔推理账单自进化的成本容易被严重低估这里并不是说前向推理一次的算力消耗而是整个迭代循环的推理调用次数增长。一个完整的自进化循环单 epoch 的 LLM 调用次数大概是这样的主评估N 次N 是全量数据集大小反思1 次候选验证C × M 次C 是候选 prompt 个数M 是迷你验证集大小。所以一轮总调用 N 1 C × M。假设 N100C4M20一轮就要跑 100 1 80 181 次生成。以每次平均 1500 token 计算一轮就是 27 万多个 token多轮下来成本十分可观。所以要控制进化成本两条路最有效控制迷你验证集 M 在 10~30 之间别贪多以及如果任务固定考虑用小模型先做候选筛选大模型只负责最终验证。成本控制不住的话再漂亮的进化算法也跑不动。5.4 波动与实验设计改进方向是骗人的很多人跑完一轮进化看到平均分涨了就觉得这次改对了。且慢单轮涨分很可能是随机波动。LLM 采样有温度同一 prompt 在不同随机种子下跑同一个样本结果不是确定性的。一次涨分可能是碰巧运气好也可能是候选 prompt 确实更好。正确的做法是对候选版本跑多次独立采样取平均值再对比。我在关键决策上至少跑 3 次重复实验每次换随机种子然后比较均值差异。如果涨分在多次重复后仍然稳定才敢确认这是真实改进。这个细节看似麻烦但它能帮你过滤掉大量自欺欺人的伪改进是整个实验可信度的底线。5.5 什么时候该收手停止条件与安全边界自进化不是跑得越久越好。我见过一个系统跑到十几轮之后 prompt 长度翻了几倍从一条简洁指令变成一本厚厚的操作手册然后性能反而往下掉。长 prompt 会让模型注意力分散关键约束被淹没在次要信息里这是典型的过度进化。我常用的停止条件是三选一连续两轮平均分不再增长时停止prompt 长度超过一定阈值比如 1500 token按场景可调时强制停止候选 prompt 与当前最优的分数差低于某个极小阈值时停止。永远记得自进化是有边界约束的优化过程而不是无约束的贪心搜索。还有一个安全层面的考虑自进化系统会持续产生新的策略版本如果 Agent 被部署在与用户直接交互的环境中新增策略可能引入不可控的行为变化。我建议每一次策略更新走一次人工抽查重点看新增指令是否引入了对用户不友好的输出方式。这个环节别省它值得你付出那点人力成本。我个人在实际操作中的体会是自进化 Agent 最值钱的部分其实不是那个自动化循环而是你逼着自己把评估标准定义清楚的过程。很多时候你把评估器写明白了根本不用进化多少轮Agent 就已经很好用了。评估器才是真正的老师反思器和调度器都只是搬运工。最后再分享一个小技巧不要把反思器的输出直接拼到原始 prompt 后半段就完事。我会让反思器同时输出建议和改动理由然后在候选验证时多留一个心眼——如果某条建议导致分数提升但理由明显和实际错误模式对不上这通常意味着评估器有漏洞优先去查评估器而不是继续进化。踩过几次坑之后你会明白自进化的速度上限永远取决于你的评估器有多诚实。