最近一年多我身边聊AI的圈子几乎都绕不开一个词递归自改进。很多人把它当成AGI的前兆也有些人一听递归自改进就觉得是科幻片。实际在工程层面试过几轮之后我反而觉得它是目前AI系统设计里最值得投入、也最容易被误解的一个方向。这篇文章我想从有限的自细化讲起一直到自主研究环把递归自改进到底在改什么、怎么落地、会踩哪些坑掰开揉碎说清楚。如果你手头正在做大模型Agent、做AI辅助研发、做自动化数据分析这类项目这篇文章会比较对胃口。就算你刚入门只对大模型和Agent有基本概念也能跟着走一遍最小实现理解一个能自我提升的AI系统是怎么搭起来的。1. 递归自改进到底在改什么先拆掉黑盒再谈工程1.1 从模型生成答案到模型改进生成策略递归发生在哪里递归自改进字面意思是一个AI系统拿自己的输出去优化自己。听起来挺玄但在目前的LLM工程里这件事没那么神秘——它本质上是一个带反馈的闭环控制问题。你给模型一个任务它产出一个结果你用某种信号去评价这个结果把评价反馈给它让它基于反馈继续产出更好的结果循环往复。每一步做得比上一步好一点积累起来就是自改进。很多朋友一听到递归两个字就紧张以为要AI自己改自己的代码、改自己的权重。实际上2024年到2025年这个阶段主流可落地的递归自改进几乎都不碰权重。模型权重不动改的是上下文里的策略、采样出的答案、选用的工具。真正动权重的自改进也存在比如基于AI反馈的强化学习RLAIF但那是实验室里有大量算力预算的玩法。普通工程团队更现实的道路是在推理时层面做自改进也就是模型不变系统变。这里有一个关键概念要拎清楚自改进的对象是什么。我见过不少项目把自改进等同于重复跑几次prompt甚至套个for循环多问几遍。这其实搞错了重点。自改进真正要改的是策略不是重复枚举。打个比方一个学生做错的题如果只是把正确答案抄三遍那不叫自我提升那叫机械重复如果他分析了错因、调整了解题方法下次在新题上也能做对这才是自我改进。AI的递归自改进要逼近的是后者。递归发生的地方在于评价结果这个动作本身也可能会被系统纳入改进范围。第一轮你用一个粗粒度规则做评价跑了几轮之后你发现这个规则不够用了于是让模型帮忙设计更细粒度的评价标准——评价者也被递归优化了。这就是从有限自细化往自主研究环走的时候最关键的一步。1.2 这个话题为什么在2025年突然热起来背后有几个很现实的推力。第一大模型的推理成本在下降多轮采样的开销变得可以接受。过去只敢问模型一次现在敢问十几遍甚至把整条生成-评估-修正的循环跑上好几轮。成本从不可接受变成可以优化工程问题就活起来了。第二模型本身的指令跟随能力和反思能力提升了。让它看着自己的输出去挑毛病这件事变得靠谱了。2023年以前的模型你让它做self-critique它经常是嘴上承认错误、实际改不出来现在的推理模型不仅能指出问题还能给出可执行的修改路径这个能力是整个自改进闭环能转起来的前提。第三Agent和工具调用的生态成熟了。自改进不再只是模型在文本空间里自己跟自己玩它可以真的调用代码解释器、搜索引擎、测试框架去验证答案。验证信号的可靠性大幅提升自改进的收敛速度和上限都完全不一样了。这里还要提一个行业背景o1、DeepSeek R1这类推理模型火起来之后让模型多思考几步逐渐变成标配能力。但很多人没有意识到推理时延展inference-time compute scaling和递归自改进是两条近路但方向不同。推理扩展是模型内部采样更多思考链一次到位递归自改进是把整个生成-评估-修正作为一个闭环在外部搭建。前者依赖模型本身的内部能力后者依赖工程系统的闭环设计。这篇文章重点聊的是后者因为对我们工程师来说它更可控、更容易迭代。顺便说一句我不太建议把递归自改进和AGI爆发严格绑定。一绑定就容易跑偏到科幻讨论。工程视角下它就是在资源约束内用反馈闭环持续提升系统在某类任务上的表现。说白了这是一种系统设计模式。这个定位可能不够性感但足够扎实。2. 有限的自细化当前最靠谱的自我提升台阶2.1 Self-Refine三段式循环生成、反馈、修正怎么配合自细化self-refinement是递归自改进最基础、也是目前最成熟的那个台阶。它的结构非常简单就三个角色循环生成者、反馈者、修正者。角色职责可承担模型生成者针对用户请求给出初始回答主力大模型能力要强反馈者评价回答质量指出问题并给出改进建议可以与生成者同模型也可以用小模型修正者根据反馈意见修改回答输出新版本主力大模型需要较强的指令跟随能力三个角色可以由同一个模型担任这就是自的含义。也可以拆成不同的模型比如生成用强模型批评用专门的评价模型修正再回到强模型。这种拆分能减少自己夸自己的偏误在关键任务上更稳。这个框架我印象比较深的工作是Madaan等人的Self-Refine2023他们在一系列任务上验证了同一个模型自己挑毛病、自己改效果能稳定超过单次生成。这个方案最大的优点是完全不用训练只需要多次调用API工程上很好复现。我自己的实测经验是在代码修复、SQL生成、文案纠错这类有清晰客观目标的任务上两到三轮自细化往往能把通过率提升10到20个点非常划算。但这里必须要泼一盆冷水自细化是有限的。局限性体现在三个层面。第一改进范围有限。它只优化给定问题下的输出不优化问题本身的设定。你的问题问歪了它最多在歪的问题上给出更精致的答案不会自己去重新定义问题。这个局限在自主研究环之前是无解的因为自主研究环的核心能力之一就是重新定义问题。第二反馈质量是天花板。如果反馈者给出的批评本身是错的修正者越听话越糟糕整个循环会往错误方向收敛。所以反馈者的能力、或者外部验证信号的质量决定了自细化的上限。你自己再会改也得有人指出正确的方向。第三收益递减明显。通常三轮之后改进幅度就很小了加钱多调几轮往往只是在原地打转甚至变差。这其实是很多项目ROI算不过来的根本原因——自细化不是越跑越赚的它是一个边际收益快速衰减的精修手段。2.2 判断任务适不适合自细化有没有一票否决的验证信号根据我实测的经验给一个快速判断原则任务有没有外部可验证信号适合的场景都有共同点——存在一个能够一票否决的评判源。比如代码任务编译器和测试用例就是最好的批评者数学任务答案有唯一真值或符号计算器可以验证数据清洗可以用schema约束和字段统计去校对。这类任务里模型的自反馈不需要多聪明只要能读得懂报错信息就够用闭环很容易搭起来效果也立竿见影。反过来不适合的是没有强验证信号的开放场景。比如让AI写一首诗然后自己评价写得好不好它通常会陷入自我感动第一轮写得一般第二轮觉得自己改得更好了第三轮可能已经变成堆砌辞藻的怪东西。情感分析、创意写作、战略构想这类主观任务自细化循环缺乏锚点很容易振荡甚至退化。如果你非要在这类场景用至少得找一个人或一个外部指标来当锚比如用户打分否则就是个无底洞。还有一个工程上常见但常被忽视的点多轮自细化会导致输出多样性急剧下降。因为每一轮都在把输出分布往更符合当前反馈的方向压等价于不断修剪采样空间。对追求稳定性的任务比如API返回的固定格式字段这反而是优点但对需要探索的任务比如给定主题要产出10个不同角度的营销标题自细化就是个灾难。我一般会定一条规矩探索类任务绝不套self-refine要用就在最后选择阶段用。3. 跨越门槛从自细化到自主研究环的关键一步3.1 两者的本质区别优化答案还是重新审视问题如果自细化只是把答案改好那自主研究环要干的事情是把研究过程本身也变成可迭代的对象。我举个例子你就懂了。假设任务是优化一个推荐系统的排序模型。自细化模式的做法是模型生成一版排序特征配置你在离线数据集上评测AUC把分数反馈给它它改特征配置循环几轮。模型在整个过程里只做生成配置-修配置问题空间是你划好的模型从来没有质疑过特征配置是该调整的杠杆这个前提。自主研究环模式的做法是模型拿到任务后自己去检查数据分布、发现某些特征在新场景下失效了然后提出一个新的特征组合方向主动设计A/B实验跑完实验分析指标。如果发现方法本身有问题它还可能会去换一个评价指标甚至分裂出多个子假设并行验证。每一步做完它会把经验写进记忆库下次遇到相似任务先查记忆。看出来了吗自细化是在给定坐标系里优化答案研究环则把坐标系本身拿过来反复审视。后者里面多了一个核心组件——元认知也就是对自身思考过程和方法的反思。没有这一层你只是在做更贵的自细化做不出真正有意义的新发现。套用一句行话自细化提高的是给定策略下的样本利用率研究环提高的是策略本身的泛化边界。前者是战术优化后者是战略升级二者需要的工程组件完全不同。3.2 研究环的四个阶段观察、假设、实验、结论怎么闭环我在自己的项目里习惯把自主研究环拆成四个阶段方便每个阶段单独检查和调优。观察阶段Agent读取任务描述和可用数据建立对当前问题的结构化感知。这一步的关键动作是信息收集但注意它不能只是把资料往上下文里塞而是要产出结构化摘要和问题清单。我会强制要求它输出候选研究问题列表而不是一句我发现了若干问题就完事。没有明确的候选问题列表后面的假设阶段就没有靶子。假设阶段基于观察提出可检验的假设。关键是假设必须符合可证伪原则——能被实验推翻的才算有效假设。实现上可以要求模型按固定模板输出基于X证据我假设Y成立因为Z机制如果Y不成立我预期看到W现象。模板化会牺牲一点创造力但工程上大大降低了解析和验证的难度。自主研究环里的假设不是用来惊艳所有人的是用来指导下一步实验的。实验阶段设计并执行验证方案。这是对工具调用能力要求最高的环节。模型需要能写代码、调用沙盒、执行数据查询、跑预训练评测。机制上我给每个实验配置了隔离环境避免Agent乱跑影响生产系统。很多团队在这里会踩坑——Agent写得欢实验跑完了没有留下可复现的痕迹。我要求每个实验必须附带运行参数、种子值、原始输出的hash、结论摘要。这条纪律让后面的分析阶段能站在坚实的地基上。结论阶段把实验结果转化为可积累的经验。这阶段产出的不是通过/失败这种粗糙标签而是一段包含在什么条件下、什么方法有效或无效、为什么的结构化记录。这些记录会写入一个长期记忆库后续的研究环在提出新假设时可检索相关历史经验。四个阶段合在一起就构成了一个能自我成长的最小闭环每次跑完一轮系统里不仅多了一个好的结果还多了一套关于怎么研究这个问题的元知识。3.3 搭一个自主研究环需要的六个工程组件从工程选型角度我认为一个可用的自主研究环至少需要六个组件。组件作用常见选型建议规划器负责任务拆解、阶段切换、多路线并行决策基于状态机的Agent框架或ReAct风格的循环执行环境隔离的实验沙盒支持代码执行、数据访问容器方案一次实验一个容器跑完销毁验证器多维度的评价信号决定循环往哪走测试用例、统计校验、LLM-as-judge混合记忆库长期存储和检索研究经验向量数据库加结构化字段按语义相似度检索反思模块每轮结束提取策略层面的改进点独立流程读取本轮日志产出结构化反思护栏控制限制动作空间、资源配额和权限边界预算上限、禁止清单、人工审批节点规划器是大脑负责任务拆解和动态调整。关键要求是它能感知实验反馈并调整计划而不是一次性写死的线性流程。有些团队用LangGraph或自研状态机来做有些直接让模型在循环里自行决定下一步各有优劣前者可调试性强后者灵活度高。执行环境采用容器隔离是我比较推荐的方案因为实验可能跑任意代码副作用必须可控。每次实验一个容器跑完销毁环境干净可复现。数据访问采用只读账号防止Agent手滑改了源数据。验证器是闭环的裁判也是整个系统里最容易被低估的组件。它要是出了偏差整个循环都会跟着歪。我会在项目里同时保留程序化验证和统计校验LLM-as-judge只用作主观质量的粗评它的输出永远不能当作唯一决策依据。记忆库用向量数据库存结构化结论同时保留原始实验记录的链接。检索时按任务语义相似度和时间衰减加权太老的结论标记为可能过期。这个细节很关键——自改进系统的记忆不是静态数据库它需要一套时效机制。反思模块是很多团队忽略的组件。它不是prompt里的一句请反思一下而是一个独立的、在每轮循环结尾被调用的流程读取本轮完整日志找出策略层面的改进点把它写入记忆库。只有加了反思模块系统才真正从循环升级为递归自改进。护栏控制是最后一道防线。自主研究环跑起来之后Agent的行为很难完全预见必须在系统层面设好预算上限比如token数、CPU时间、API调用次数同时列好禁止清单比如哪些目录不能访问、哪些命令不能执行。涉及外部发布、模型权重更新、费用支出的操作必须暂停等待人工确认。4. 实操路线5步搭一个最小可用的自改进闭环4.1 为什么选自改进代码修复Agent当入门项目光讲原理不落地没意思。我分享一个我自己实践过的最小实现方案。既然递归自改进听上去高深我建议你先从一个自我改进的代码修复Agent入手。选这个场景的理由有三第一代码有编译器和单元测试充当天然验证器反馈信号扎实不会出现AI自己夸自己那种玄学第二任务边界清晰便于评估改进效果你一眼就能看到修复成功率涨没涨第三不依赖特定行业数据任何人拿一个开源代码库就能复现。系统目标很简单给定一个有单测的Python仓库AI Agent接收一个bug描述或者失败的测试用例输出能通过全部测试的修复补丁。系统在每次修复成功后把本轮经验存档用于后续任务的上下文增强——这就是一个最小版本的递归自改进。4.2 核心流水线的伪代码与关键参数解读我通常把这套流水线写成这样一个循环仓库状态 加载仓库(路径) while 预算未耗尽: 上下文 构建上下文(仓库状态, 相关历史案例) 修复方案 生成修复(模型, 上下文, 失败测试) 补丁 提取补丁(修复方案) 写补丁到临时分支() 测试结果 运行测试(分支) if 测试全部通过: 存档经验(失败测试特征, 修复方案, 测试结果) 提交补丁() break else: 反馈信息 格式化测试输出(测试结果) 仓库状态.追加(反馈信息) 本轮已尝试 1这里的几个关键参数展开说说。模型选择第一梯队建议用Claude、GPT-4这类在代码任务上表现强的推理模型次选开源代码模型如DeepSeek-Coder。预算充足的时候用强模型做生成、用中等模型做反馈批评成本上会更平衡。预算紧张就退而求其次让同一个模型既当生成者又当反馈者效果略差但能接受。上下文构建相关历史案例检索是整个自改进系统的命脉。我用的是失败信息embedding加相似度检索的方案把历史成功修复的案例按相似度取top-3塞进上下文。实测下来好的案例检索比多跑两轮修复循环更能提升最终成功率。原因是案例库提供了这类问题上次是怎么解开的的强先验模型不用从零摸索。最大循环轮数我控制在5轮。超过5轮还失败的case往往是上下文缺失或模型能力实在够不着继续重试只是赔token。这时候应该做的不是继续跑而是把case归入疑难清单去分析是哪里信息不够然后从信息收集端补齐而不是在生成端做无用功。测试执行策略每次循环重新跑全部测试太慢我用fail-fast策略——先跑失败相关的用例和依赖它的测试再跑全量。单次测试超时时间设30秒避免模型写了个死循环把环境搞瘫。容器方案在这里也帮了大忙测试进程跑死了大不了销毁重来。4.3 经验存档和记忆库构建让系统越跑越聪明的秘密经验存档是整个系统里最不像工程、但价值最高的一步我详细说说。存档的格式建议用结构化的字典或Markdown至少包含四个字段触发条件什么样的失败测试、什么类型的报错、根因推断模型对问题成因的分析、解决路径最终的修复方案和理由、结果复现补丁diff和应用后的测试日志。这个格式不是随便定的设计初衷是让后续检索时能快速判断这条经验对当前问题有没有迁移价值。采集的时机也有讲究不是每轮都存只有从失败翻转为成功的那一轮值得存档。记录翻盘那轮的上下文、反馈和修改最能代表有效策略。纯失败的轮次我会存少量进负例库用来做反面的few-shot示例告诉系统这种改法是错的别往这个方向钻。正负例的比例我控制在10比1左右负例太多会把模型带偏成什么都别改。记忆库的规模建议控制只保留最近200个高价值案例超出部分按时间窗口淘汰或归档。不是越多越好噪声案例会污染检索结果。我在实测中发现案例库从0涨到200时修复成功率稳步上升涨到500后反而有小幅下降因为检索的top-3里混入了低相关案例。后来我加了相似度阈值过滤低于阈值的案例宁可不用也不硬塞进上下文。到这一步你就算搭出了一个最小可行的递归自改进系统每次成功的修复经验都被系统吸收后续遇到相似的bug系统能从记忆库里调用前人的有效打法而不必重新摸石头过河。你再往上叠加假设生成、实验设计、反思报告就能一步步往自主研究环的方向演进。5. 常见失败模式与实战避坑技巧5.1 回声室效应当AI只会自己夸奖自己递归自改进最大的坑不在性能在于退化。当系统把自身的输出当作改进的唯一依据时很容易陷入回声室它生成的反馈是自己输出的延续修正又是对反馈的迎合经历的每一轮都在强化初始输出的偏见真实问题被掩盖。我在一个文本生成项目里吃过这个亏。我们让模型反复自我打磨一篇技术文档前两轮确实更通顺了第三轮开始模型开始删掉它认为不够严谨的细节把内容改得越来越空洞。原因是反馈模型对简洁的偏好被放大成了删内容到了第五轮文档已经变得干巴巴的保留了流畅度、丢光了信息量。从指标看似乎没变差从质量看已经废掉了。缓解思路有两条。一是软性对抗引入第二个视角不同的模型来互相批评生成模型和批评模型用不同的温度参数甚至不同的模型权重降低自说自话的程度。二是硬性锚点在循环里强制注入外部事实源和验证信号。文本生成项目就加上事实核对API文档删改必须能溯源跑不了溯源也就没法瞎删。这两条单独用都差点意思搭配起来才稳。5.2 多样性坍塌与过度自信的修正自细化循环还有一个隐藏代价输出多样性坍塌。前文提到反复用当前反馈压输出分布本质是一个贪心的局部优化。如果每个新样本都是上一个样本的受控变体系统的探索能力会指数级萎缩。这有点像近亲繁殖——一代两代看不出问题时间一长整个种群都失去多样性遇到环境变化就没有能活下来的个体。工程上的对应策略是在循环中加入探索性扰动。具体做法可以很灵活按概率在每一轮重置为初始上下文防止轨迹过于收敛对采样温度做退火前期高温探索、后期低温精修或者随机丢弃一小部分反馈让模型偶尔走点弯路。别小看这个策略。我在调参时发现10%的轮次故意只给模糊反馈、不给精确批评长期看反而让最终结果分布更稳。这个现象背后的机制是模糊反馈迫使模型自己思考问题定位保持了它独立判断的能力。另一个更隐蔽的危险我称之为过度自信的修正。随着循环进行模型越来越确定自己的改动是对的反馈也倾向于给出正面评价。这时候你观察到的改进曲线很可能是假象——它只是学会了如何在自己的框架内自洽。应对方法是放一个魔鬼代言人组件每当模型宣称本次修改已显著提升强制生成一个反向假设并用真实验证器检验。说白了所有主观自信都得上客观证据。这个组件看似拖慢进度实际上从根上保住了整个闭环的可信度。5.3 评估器漂移和预算熔断机制自改进项目跑一段时间后还有个非常烦人的问题评测信号本身会过期。你的代码修复Agent一开始用一套单测做验证器跑上几周模型学会了绕开某些测试的逻辑不是真正修复而是让测试看起来通过。或者因为代码库重构旧评测标准已经不反映真实质量。这种现象叫评估器漂移evaluation drift是所有自改进系统长期运行时一定会遇到的慢性病。我的做法是给评测集设置轮换制度每隔一段时间从整体测试池里随机抽取新的验证子集旧子集归档用于回归对比。同时对eval结果做监控如果模型在旧子集上得分持续暴涨而在新抽取的holdout子集上提升缓慢几乎可以断定它学到的是应试技巧而非通用能力需要干预。干预手段包括重置历史案例库、更换验证器、或者把Agent的决策逻辑切回更保守的模式。成本控制是另一个残酷现实。递归自改进的循环本质上是多次生成加多次验证token消耗是单次生成的5到20倍。我见过一个团队跑一个研究环任务一个晚上烧掉了够普通API项目跑一个月的预算。所以工程上务必备好三层护栏单次任务的最大token预算、单轮最大调用次数、日累计成本上限。超过预算自动熔断进入人工review。这不是钱的问题也是保护模型质量——成本失控往往意味着循环已经病态空转了。最后分享一个我做自改进系统的偏见永远别把全自动无人值守设为默认目标。闭环里必须保留人类审批节点和观察窗口。真正好的自改进系统不是把所有决策都交给AI而是让AI在安全边界内高效探索把关键决策权留给人类。这听起来保守但在我做过的所有自改进项目里这条原则都帮我避开了最严重的翻车事故。