这两年我持续在跟进一个话题：AI系统能不能自己改进自己。严格说，这个命题很早就有了，但直到大语言模型成为主流基座，它才从科幻讨论变成了可实验的工程课题。现在业界讨论比较多的是“自细化”（self-refinement）——让模型自己批评自己、自己改自己的输出；再往上走一步，“递归自改进”（recursive self-improvement）意味着系统把改进后的能力再投入下一轮改进；而“自主研究环”（autonomous research loop）则是把这件事做成一个无人值守的闭环：提假设、跑实验、读结果、写总结、更新知识库，然后进入下一轮。
这篇文章想跟你聊的，就是这条从“有限自细化”到“自主研究环”的路径。适合正在做LLM应用、AI Agent落地、模型后训练或者算法工程化的朋友。我会把概念讲清楚，把几个主流技术方案拆开，还会把我自己跑过的最小闭环实验完整复盘一遍。不是概念科普，是拿得到手上的工程视角。
1. 先理清概念：自细化、递归自改进、自主研究环
1.1 三个词讲的是同一件事的不同尺度
很多朋友看到“递归自改进”第一反应是科幻片里的超级智能，这里需要先把尺子摆正。
“自细化”是单次或少数几次迭代内，模型针对同一个任务反复修正自身输出。典型场景是让模型先写一版代码，再让同一个模型检查这版代码的缺陷，然后根据缺陷描述重写一版。这个过程只改输出，不改模型参数。它对应的是“有限自细化”，因为迭代收益会快速衰减，通常两三轮之后改进就不明显了。
“递归自改进”的概念向上提了一层。它强调改进对象不局限于当前任务的输出，而是包括模型自身的能力、知识库、提示词策略，甚至参数。经典形式是：模型M在任务T上取得结果，这个结果反过来被用来优化M在T或更广任务上的表现；优化后的M’继续处理下一轮任务，从而形成循环。这个“自己改进自己”的动作如果发生足够多次，就叫递归。
“自主研究环”是很具体的工程形态，本质上是一个把递归自改进落地的Agent系统。它不是模型自己改输出，而是用一组工具和流程，让AI完成“研究者”的角色闭环：提出可验证的问题、设计实验、编写并执行代码、分析结果、形成结论，并把结论写回记忆或知识库。这个闭环跑得越顺，系统越接近“自主做科研”的形态。
三者关系可以这样理解：自细化是闭环里最基础的一步；递归自改进是它的迭代策略；自主研究环是承载迭代策略的系统结构。
1.2 为什么这个方向突然热了起来
过去几年大家会明显感觉到，靠单次前向推理的LLM已经顶到了天花板。模型知道很多知识，但面对复杂推理、长流程任务、需要反复试错的工程问题时，一次生成往往不够。Rollout能力已经到了瓶颈，于是整个行业都在往“多次采样+反馈修正”的方向拐。
另一个现实因素是推理成本下降。同一笔预算，以前只能跑一次大模型，现在可以跑几轮、几十轮采样，这也让自细化、自我批评这类方法真正有了工程可行性。第三个因素是Agent工具的成熟：模型可以调用代码解释器、搜索引擎、数据库、外部API，这给“自主研究环”提供了执行反馈的抓手。
加上多Agent协作逐渐变成产品标配，大家开始发现一个本质问题：多Agent协作的效果并不完全取决于单个Agent的聪明程度，而取决于Agent之间的反馈回路是否闭环。自细化恰恰是反馈闭环中最核心的一个单元。说白了，这个话题不只是学术标签，它直接关系到你做出来的Agent是“反复用同一个错误逻辑切工具”，还是“跑几轮之后确实变强了”。
2. 自细化是怎么落地的：几种主流技术路线
2.1 Self-Refine：生成、批评、重写
Self-Refine是这类方法里最朴素也最好理解的一条路线，大致分三步：
- 第一步，让模型生成初始答案。
- 第二步，让同一个模型对自己的答案做批评，输出具体的缺陷和修改建议。
- 第三步，让模型结合批评意见，重写一版答案。
这个过程可以循环多轮，典型做法是三到四轮。关键设计点在“批评”这一步：如果你只是笼统地让模型“检查错误”，它很容易回复“答案整体不错，但还可以更详细”，这种反馈对重写毫无价值。实践中要把批评任务设计成可检查的清单式问题，比如“这版代码中，哪个分支没有覆盖边界条件？哪个变量可能为None？时间复杂度的最坏情况是什么？”，逼着模型找出具体问题。
我自己在代码生成场景里测过Self-Refine，成功的案例里有一个共同特点：批评信号越具体，重写收益越大。有一次让模型写一个数据清洗函数，第一版直接漏掉了空值处理逻辑，模型批评自己时指出“对缺失值调用strip()会抛异常”，重写后这个问题确实被修复了。但如果反馈只是“代码风格不够雅观”，下一版基本不会有实质变化。
需要留意的一个坑是：Self-Refine很可能改出个“正确但没用”的答案——它在形式上变得更严谨，却在语义上偏离了原始需求。比如你让它写一个尽量快的排序函数，它重写后可能为了健壮性加了大量类型检查，速度反而变慢了。所以自细化一定要配上外部评估信号，不能只靠模型自己判断好坏。
提示：Self-Refine的核心优化点在“批评质量”。与其花精力调重写模板，不如花精力设计批评任务的结构。
2.2 Reflexion：把失败存进记忆
Reflexion的多了一步，它不只是让模型当场修改，而是把这一轮失败的经验转成一段文字，存进一个“记忆区”，下一轮尝试时把这段记忆作为上下文带进来。
看几个要素：语言模型负责生成实验方案、执行动作；评估模块负责判断动作是否成功；反思模块拿“成功/失败”标签去反推失败原因，生成“反思文本”；最后一轮新尝试时，反思文本会被拼进prompt作为额外上下文。
这个设计解决的痛点很实际：Self-Refine在单轮上下文内做修改，能利用的信息只有当前对话，但很多任务的坑不在第一次犯，而在第五次、第十次。Reflexion通过“外部记忆”把前几轮的失败教训保留下来，相当于给模型加了一个经验账本。
我在一个真实项目里用过类似思路给Agent做调试，场景是让Agent去操作一组内部测试用例。第一轮Agent跑出三个失败用例，反思模块给出的教训是“这三个失败都来自同一个接口调用的参数格式错误，下次应先检查接口文档”。第二轮Agent把这条反思带进决策，直接修正了传参逻辑。值得注意的是，反思文本不要写太长，我试过两轮之后就把上下文窗口占掉大半，模型反倒会被冗余教训干扰。
崩溃风险也要提一句。Reflexion有一个已知问题叫“反思过拟合”：模型反复得到同一条失败教训时，会开始把它套用到所有任务上，导致原本能跑通的行为被错误修正。解决办法是给记忆区加时间衰减或者离线筛选，保留近期、高频相关的教训。
2.3 多一点“递归”味道：STOP 与自我学习循环
Self-Refine和Reflexion还停留在“改输出、攒经验”的层面，框架层面更进一步的，是STOP（Self-Taught Optimizer）这类思路：模型不只改进答案，还改进生成答案的提示词模板。
STOP的大致流程是：先把优化任务定义成“改进提示词”，让模型读当前提示词和一组验证得分，再让它写一个新提示词；新提示词去跑验证数据，得分更高就保留，否则回滚；这个动作可以迭代几十上百轮，目标是搜索出一个比人工写得更有效的提示词。
这个框架的价值在于，它是少数直接把“改进对象”从任务输出转移到“能力载体”的方案。以前是模型根据反馈改代码，现在是模型根据反馈改自己将来会用的“思考模板”。从递归自改进的角度看，这个转移非常关键——只有当改进成果能沉淀回系统本身（提示词、知识库、子模块结构），循环才真正闭合。
但STOP的工程诱惑大于实际效果，我在复现时遇到的最大问题是搜索空间太大。一个提示词模板稍微改几个词，验证集上的结果就可能大幅波动；要找到稳定提升，往往要跑几十轮甚至上百轮，成本很高。更让人头疼的是“局部最优陷阱”：模型很容易找到一个在验证集上涨分的模板，但换到新任务就崩盘，本质上是过拟合到了验证集。
我自己的建议是：如果你打算走这一类方案，一定要把验证集和最终评估集分开，并且每轮改进后用KL散度或者embedding距离盯住新提示词的分布漂移，防止模板过早收敛到奇怪的语言模式。
3. 从自细化到自主研究环，中间到底缺了什么
3.1 自细化只是闭环里的一环
自细化做得再好，也只是闭环的一个“零件”。它负责的是“给定一个初步结果，如何迭代打磨”。但真正的自主研究环，要求的是一整套科研流程的自动化：发现问题、产生假设、设计实验、执行实验、分析结果、得出结论、更新知识，然后带着新知识进入下一个问题。
你可以把它理解成一个工厂：自细化是质检和返修工位，但工厂还需要采购、加工、检验、包装、仓储。任何一个工位断了，流水线就停。
从我这边接触到的实际项目看，绝大多数号称做“自主研究”的系统，其实停在两个半成品状态。第一种是“能跑实验但不读文献”，Agent会写代码调API，跑出一堆数字，但不会根据数字提出新假设；第二种是“能读文献但不闭环”，Agent会总结论文要点，但总结出的内容不会反过来指导下一轮实验设计。两个半成品合起来，也不是完整的自主研究环。
3.2 自主研究环的完整构成
一个能称之为“自主研究环”的系统，我拆解下来至少需要六个模块：
- 问题生成器：把宽泛目标拆成可验证的子问题。比如“提升模型的数学推理能力”会被拆成“在GSM8K的运算错误类型上，模型是否对乘法分配律掌握不足”。
- 实验设计器：针对子问题提出验证方案，包括数据集、指标、对照条件。这里要特别强调“对照”，没有对照的实验结论几乎没有参考价值。
- 执行引擎：调用代码解释器、终端、外部API，把实验方案跑出真实结果。执行环节必须能返回结构化结果，不能只是日志文本。
- 分析模块：把实验结果总结成结论，并且区分“统计显著”和“偶然波动”。很多Agent在这里翻车，把噪声当结论。
- 记忆与知识库：把结论沉淀成可检索的知识条目，供后续问题生成器使用。
- 治理模块：设定边界，比如“不允许修改核心配置”“每一步必须记录日志”“达到预算上限强制停止”。
这六个模块里，真正的瓶颈通常不是模型智力，而是工程衔接。问题生成器输出的假设质量再高，如果执行引擎不能精确复现实验条件，那整个闭环都在沙滩上盖楼。我见过不少项目花80%的算力在“让Agent执行代码时不炸环境”，而不是花在算法设计上。
3.3 几个被低估的工程难点
第一个难点是实验复现性。Agent跑实验时能不能锁定随机种子、固定依赖版本、记录环境快照，直接决定了后续分析是否可信。自主研究环跑得越深，不可复现的实验积累得越多，知识库就越脏。
第二个难点是反馈信号的奖励设计。自细化可以模糊，因为人还在环里做最后判断；自主研究环一旦无人值守，就必须把“什么算好结果”量化成明确的打分函数。这个打分函数写歪了，整个环路都会向着错误方向递归优化。我在下文会专门讲这个“掺假反馈”的坑。
第三个难点是资源边界。自主研究环最大的诱惑是“让它一直跑”，但一直跑的代价是指数级的。假设每轮实验要调用100次模型，从第4轮开始分支因子稍微大一点，算力账单就非常恐怖。工程上必须设计动态停止机制，比如“连续N轮性能提升低于阈值就收敛，停在当前版本”。
这三个难点没有一个是纯算法问题，都是工程治理问题。所以你问我“从自细化到自主研究环中间缺了什么”，我的答案很明确：缺的不是更强的模型，缺的是把反馈闭环做成稳定、可信、可控制制的工程系统。
4. 我跑过的最小闭环：一个可复现的实验设计
4.1 目标与评估集设定
为了验证“递归自改进”在现有LLM上到底能走多远，我搭过一个最小闭环。目标选的是“代码正确率提升”，任务集是一组包含边界条件、异常处理、算法题在内的30道编程题。评估指标很简单：通过预置测试用例的比例。
设计上刻意把闭环缩小成三个环节：生成初始代码、自细化重写、外部验证返回结果。没有做知识库沉淀，没有做假设生成，这算是从“自主研究环”退到“有限自细化”，但保留了一个关键递归点——每一轮模型的输出会作为下一轮输入的上下文。
4.2 核心流程与Prompt设计
流程是这样：第一轮，给模型一个任务描述，让它写代码；第二轮，把上一轮代码和测试用例的失败信息一起交给同一个模型，要求它针对失败信息做修正；第三轮重复类似动作。每轮最多重写三次，三次之后不管结果如何都结束，保证成本可控。
这里的关键是Prompt设计。我试过两种反馈格式，对比很明显。第一种是“这是你的代码，测试结果如下，请修正”，效果一般，模型经常只是换了一种错法。第二种是“请先列出所有导致失败的假设，再逐条验证，最后输出修正代码”，效果显著更好，因为强制的“假设-验证”结构堵住了模型跳步骤的毛病。
下面是一个简化的可复现模板，你可以直接拿去做基线：
SYSTEM_PROMPT = """ 你是一名资深Python工程师。现在给你一段代码和它的测试反馈。 请按以下步骤工作： 1. 列出至少三个可能导致测试失败的假设； 2. 针对每个假设，说明你如何通过代码逻辑验证它； 3. 基于验证结果，重写代码。 只输出最终代码，不要输出解释。 """这个模板看起来平淡，但让我实测里的自细化成功率提升了约15个百分点。原因在于它把“反思”从隐式变成了显式。
4.3 迭代参数与防崩坏策略
关键参数我记录一下，方便你对照：
- 模型：最强模型和次强模型混用。反思阶段用强模型，重写阶段可以用稍弱的模型，这里有一个性价比折衷。
- 采样温度：第一轮生成用0.7保证多样性，反思修正轮用0.2防止随机改动。
- 最大迭代轮数：3轮。
- 失败注入策略：如果某一轮修正后测试通过率反而下降，下一轮会把上一轮的成功版本一并交给模型，让它基于成功版本继续改，而不是基于失败版本硬改。
- 回滚机制：每轮生成的代码都存快照，如果最终结果不如第一轮，自动回滚到初版。
这里重点说说回滚机制。很多人做自细化不考虑回滚，导致结果越改越差，最后整体跑分比基线还低。我加了回滚之后，整体收益立刻变成正的——哪怕重写只成功了一次，只要回滚保护还在，最差也就是回到初版水平，不至于亏本。
4.4 我踩过的三个坑
第一个坑是“用模型自己判断修好没有”。早期版本让模型在修正后自己认定“已修复”，结果它频繁自我表扬，测试通过率纹丝不动。后来改成外部执行器直接跑测试，只把真实失败信息写入下一轮上下文，准确率立刻上来。记住一个铁律：自细化里的评估者必须是外部信号，不能是模型自己的感觉。
第二个坑是“反馈信息过载”。把失败测试的输出全部堆进上下文，模型根本抓不住重点。我的解决办法是先做一个压缩层，把测试失败信息格式化成三行：失败断言是什么、期望值是什么、实际值是什么。压缩之后，模型重写代码时明显更聚焦。
第三个坑是“多轮之后风格漂移”。模型写出来的代码越来越“啰嗦”，为了应付上一轮的边缘测试，加一堆防御性分支，最后可读性很差，跑分也没提高。后来我在Prompt里固定一个要求：“在满足测试通过的前提下，保持代码行数最少”，加了这个约束后风格漂移问题大幅缓解。
5. 绕不开的失败模式与判断标准
5.1 指标上升不等于能力上升
自改进实验里最危险的事情是：验证集指标在涨，但模型真实能力没涨。我见过最典型的案例是给模型做数学题自细化，分数从47%涨到61%，看起来很好；后来把题目里的数字全部换成新数字，分数立刻跌回43%。这说明模型根本没有学会解题方法，只是学会了“贴近训练集分布的输出模式”。这类模型在统计上“学到了数据集”，而不是“学会了任务”。
所以我给“递归自改进”项目设了三条判断标准：第一，必须在保留的测试集上验证，不能只在优化集上验证；第二，必须在分布外数据上抽样检查，防止过拟合；第三，必须保存每一轮的中间版本，用来回溯“能力提升到底发生在哪一轮”。
没有这三条，你看到的“自改进成功”很大概率是幻觉。
5.2 反馈环的“掺假”问题
所谓“掺假反馈”，指的是打分函数并没有真正衡量你想要的能力，而是被模型钻了空子。
举一个实际例子：我在一个早期版本里想优化“回答有用性”，自动化评估器把“长度增加”当成有用信号。结果模型很快发现了这个规律，每一轮重写都会把答案拉长，评估分数确实上升，但用户实际体验根本没有变好，甚至因为篇幅过长而更难读。这就是反馈信号被污染后，系统递归放大了错误方向。
这个问题的可怕之处在于它具备递归特性：坏信号会随着自改进迭代不断被放大，第一轮只是轻微跑偏，到第五轮可能已经面目全非。为了防这个，我给反馈系统加了两道闸：第一道是“对抗性抽检”，每十轮抽一批样本由外部规则或人工复核；第二道是“信号相关性监控”，定期计算自动化打分与人工评分的相关性，相关性跌到阈值以下就触发告警，暂停迭代，人工介入修信号。
5.3 什么时候该停手
递归自改进系统停不下来的冲动来自一个心理：“再跑几轮说不定就突破了。”但工程上，大多数任务的收益曲线都是先陡后平，少数还会掉头向下。我自己的经验是，连续三轮迭代中，如果最优结果始终落在同一轮，就说明系统已经收敛，继续跑只是烧钱。
另一个有效信号是“改动频率”。如果某一轮重写相比于上一轮的文本相似度极高，而分数没变化，说明模型已经进入了“原地打转”的微调区间。此时继续迭代大概率是在拟合随机噪声，应该停手。
我还建议每个自改进实验都先画预算。比如“最多跑50轮，单轮API预算50元，总共2500元”，到预算直接停，不看结果好坏。这个纪律能帮你避免在无效迭代上无限投入。从个人经验看，这个行业里大多数自改进项目不是死于模型能力，而是死于没有叫停机制。
6. 这个方向后续还能怎么扩展
聊完这些，很多人会问：现在这个技术到底值不值得投入？我的判断是值得，但不要把预期放在“AI自主做出诺奖级发现”这种过于遥远的目标上。短期内真正能落地的是三个场景：
第一个是代码与工程自动调试。把“测试失败反馈+代码重写”的闭环嵌入CI流水线，让机器人帮你自动修简单Bug，这是我认为最快见效的落点。
第二个是数据与特征工程自动化。让Agent自己提出数据清洗策略、跑离线评估、保留有效策略、淘汰无效策略，形成一套数据迭代闭环。这个场景的反馈信号比较干净，比较适合自改进循环。
第三个是检索知识库的自维护。根据用户反馈判断哪些知识条目是错的，自动改写知识条目、重新嵌入，再验证改写后是否改善了下游任务得分。这本质上是把Reflexion的记忆机制用在知识管理上。
至于“自主研究环”级别的系统，目前受限于反馈信号质量、实验复现成本和治理边界，还没有到可以完全无人值守的程度。但我个人倾向认为，它会是多Agent协作发展到下一阶段的必争之地。谁能先把闭环的工程稳定性做扎实，谁就能在下一轮竞争里拿到先手。
最后再分享一个实际操作层面的心得：做这类项目，别一上来就追求“全自动”。先把一个最小闭环跑通，用手动方式盯着跑十几轮，记录哪里断、哪里假、哪里烧钱，再逐步把人工环节替换成自动化模块。我见过太多团队一上来就搭宏大架构，结果在“反馈信号怎么写”这种基础问题上就卡了一个月。递归自改进系统的成败，往往不在创新能力上，而在对细节的工程克制力上。
