递归自改进：从有限自细化到自主研究环的实践指南

先说一个我最近被反复问到很多次的现象：很多人已经在让大模型跑“自己改自己的提示词”这类实验，但几乎所有人都会卡在同一个地方——改几轮之后效果不涨反跌，或者改到一定程度就原地打转。这个问题不是方法错了，而是大家对“递归自改进”这条技术路线缺少一个全局坐标系。这篇就绕着一条主线展开：从只需要几次推理的有限的自细化，到能把假设、实验、评估、记忆全部串起来的自主研究环。我会把两者的边界、实现原理、工程细节和踩过的坑全部拆开讲，适合正在做AI Agent、提示词工程、模型自动优化和测试开发的工程师与研究者参考。

1. 递归自改进到底在聊什么

1.1 为什么这个话题近几年突然热了

递归自改进这个概念其实不新鲜，早年关于AI自我进化的讨论大多停留在理论层面，因为以前的模型根本没法把“评估自己输出”这件事做得足够可靠。但现在情况变了，大模型同时具备了三种能力：能生成内容、能评估内容、能调用工具执行验证。这三件事凑齐之后，“让AI改进AI”就从科幻变成了流水线工程。

举个最常见的例子：在代码生成任务里，模型写完一段代码，编译器或者单元测试会立刻给出报错信息，模型看到报错后重新生成版本，再跑一遍测试。这就是一个最简单的递归回路：输出→检查→修正→再检查。如果你以前手动干过这种事，你会意识到其实每次迭代的换手成本很低，完全可以交给模型自己做，这就是很多团队开始做自改进的起点。

我理解中的递归自改进，核心是用模型产出的反馈去改进模型自身的输出、策略、甚至系统配置，且改进动作的执行者和被改进对象存在重合。需要注意这里有个常见的认知偏差，很多人一想到“递归”就以为是模型改自己的神经网络权重，那是另一个层面的问题。实际工程里更常见的是：模型利用上下文、提示词、工具、检索结果、少量微调数据来改进自己的行为表现。理解了这一点，再看自细化和自主研究环的差别就会清晰很多。

1.2 “有限的自细化”和“自主研究环”是两个世界

这两个概念经常被混在一起谈，但它们的定位完全不同。有限的自细化（bounded self-refinement）指的是在给定任务、给定能力模型的前提下，在推理阶段通过“生成—批评—修正”的多轮迭代来提升单次输出的质量。它不改变模型本身，不引入新知识，也不更新任何长期状态，本质上是在同一个模型的知识空间里做更充分的搜索。

自主研究环（autonomous research loop）则是另一种动物。它不只是改进单次答案，而是能自己提出新问题、设计实验、收集反馈、更新系统的知识库或者模型参数，然后循环往复。在这个环里，模型从“答题者”变成了“研究者”，它改进的对象是整个系统，而不仅仅是某一次回答。

这两个概念不仅目标不同，工程上的难度也是天壤之别。我把它们摆在同一张表里对比一下：

把这张表记住，后面所有讨论都可以对标着看。在实际跑实验时，我的判断方式是：如果循环结束后系统的行为没有任何改变，那是自细化；如果循环结束后下一次任务从一开始就变得不一样了，那是研究环。这个判据虽然粗略，但比听一堆抽象概念好用得多。

2. 有限的自细化：先跑通“生成—批评—修正”闭环

2.1 一个三节点的自细化框架就够用

自细化听起来高端，但拆到最底层就是三个节点：生成器负责给出初始答案，批评器负责找出问题，修正器负责针对问题重新生成。实际实现时生成器和修正器通常用同一个模型，只是输入里多了批评信息，三节点也就变成两角色。

我在代码修复场景里验证过这个思路。流程大致是这样：让模型写一个函数，然后交给编译器跑一下，拿真实的报错信息作为批评信号，再让模型修正。这里的批评器不是模型，而是编译器和测试用例，这种“硬反馈”最可靠。在没有硬反馈的软性任务里，比如文案改写、代码可读性优化，就退而求其次用大模型自己当批评器。

一个典型的修正提示词长这样：

system_prompt = """你是一名资深Python工程师。下面是一个失败的实现和对应的报错信息： 失败代码： {code} 报错信息： {error} 请分析根因，并重新输出修改后的完整函数。要求： 1. 保持原函数签名不变； 2. 只修复报错相关的问题，不要重构无关代码； 3. 输出前先给出不超过两句话的原因说明。 """

注意第2条“只修复报错相关的问题”，这是我从多次实验中总结出来的关键约束。如果不加这个限制，模型经常顺手“优化”掉其他代码，结果引入新的bug，让回归测试变得一团糟。

2.2 三个硬边界决定了它“有限”在哪

既然自细化这么好用，为什么还要强调它是“有限”的？因为我在跑了几百轮自细化实验后，发现它有三道无法逾越的边界。

第一是信息边界。自细化不引入任何新信息，模型只能在已有知识空间内做局部移动。用生活化的话说，这更像是把草稿誊写得更工整，而不是去图书馆查了新资料回来重写。如果模型本来就不知道某个知识点，你让它批评十轮它也批评不出来。

第二是同源偏差。当批评器和生成器是同一个模型时，模型的盲区是重叠的。它在哪些地方弱，它对自己的批评往往也弱。这也是为什么纯靠自细化解决数学推理难题的效果有限，而引入外部计算器或检索工具后提升会明显得多。外部工具提供了模型之外的独立信号，打破了同源偏差。

第三是性能天花板。多篇学术工作的结论和我自己的观察一致：自细化对“模型原本就接近能做对”的任务提升明显，对“模型完全不会”的任务几乎没有帮助。它更像是在模型的输出分布里做确定性搜索，搜索空间再大，也不会超出模型本身的能力边界。

2.3 把自细化调稳的四个实操细节

自细化真正难的不是搭框架，而是让循环稳定运行，不退化。我分享四个实操里最关键的细节。

第一，评估器优先选规则和测试。能用单元测试、类型检查、字段比对解决的问题，绝不用大模型当裁判。规则评估器的优点是稳定、可复现、不漂移，缺点是覆盖率低。所以正确姿势是把规则评估作为第一道防线，LLM作为裁判只处理规则覆盖不到的软性指标。

第二，必须做早停和最优版本保留。很多人跑自细化时习惯直接采用最后一轮输出，这是个坑。我见过太多次模型第二轮修好了A问题、却在第三轮把原本正确的B部分改错的情况。正确做法是每一轮都在验证集上打分，只保留历史最优版本，连续两轮分数不再上涨就提前停止。

第三，控制温度。初始生成可以用稍高的温度，比如0.7，给模型一点探索空间；修正轮建议降到0.2甚至更低，避免模型大改。温度不变的话，模型经常在几个答案之间来回横跳。

第四，限制总轮数。我的经验是2到4轮收益递减明显，超过5轮大概率开始退化。这个现象我暂称它为“改进疲劳”，模型在同一个输出上反复打磨，边际收益会迅速归零，转而开始刷一些评估器偏好的表面特征。

3. 自主研究环：把“改答案”升级成“改系统”

3.1 行动空间变了：从改输出到改上下文、改工具、改模型

如果说自细化是在固定赛道上调整发挥，自主研究环则是把赛道本身也纳入改造范围。从这个角度看，行动空间可以分为四层，自细化只动了第一层。

• 改输出：直接修改本次回答，对应自细化。
• 改上下文：调整系统提示词、few-shot示例、检索到的知识片段。这是成本最低的系统级改进。
• 改工具与环境：增加一个API调用、修改工具描述、调整搜索结果数量。这类改动改变了模型能“看到”和“触达”的世界。
• 改模型：构造高质量训练数据，做指令微调或偏好优化。这是最重的一层，也是真正的模型能力升级。

自主研究环通常落在后三层。它的最小循环长这样：观察失败样本→提出假设→把假设落实为具体改动→跑实验验证→对比基线→接受或拒绝→把结论写入记忆库→进入下一轮。

我自己在搭建这种循环时最强烈的感觉是，它已经从“写代码”变成了“做科研管理”。你不再关心每一次模型回答得怎么样，而是关心实验设计是否合理、评估是否可信、结论是否可复现。这也是为什么我把这类系统叫“研究环”而不是“优化器”。

3.2 从L0到L3：自改进的能力分级

为了和团队对齐认知，我把自改进能力分成四级，写在这里供参考。

L0：固定流水线。所有流程由人工写死，模型不参与任何改进。大多数传统NLP系统处于这一级。

L1：循环内自细化。模型在同一任务的多轮推理中自我修正，前文讲的自细化就是这一级。

L2：跨任务的系统自改进。模型在完成多个任务后，会根据积累的失败样例去修改自己的提示词、工具配置或示例选择策略。这一级的系统已经具备“经验总结”能力。

L3：自主研究环。模型能主动发现当前系统的不足，提出新任务来验证假设，自主生成训练样本并触发微调。这一级的核心不再是参数搜索，而是研究管理和实验设计。

L2到L3的跳跃，关键在于模型能否自主“提出任务”。L2只是在一个预先定义好的参数空间里搜索，L3则需要模型自己画一个更大的棋盘。这个跳跃非常难，因为提出一个有价值的任务需要对自身能力的边界有良好的认知，而这恰恰是当前模型最不擅长的。

3.3 研究环的五个必备模块

我参考了很多自动机器学习框架，也自己搭过几版研究环，发现无论具体任务如何，都离不开五个模块。

规划器负责分析失败样本，产出研究假设。它接收一批bad case，输出类似“检索结果噪声太大，导致模型被无关信息误导”的判断，然后翻译成一个可操作的改动建议。

执行器负责把假设变更为实际改动。如果改动对象是提示词或配置，执行器就是模板渲染和配置更新；如果改动对象是代码，执行器就是代码生成和沙箱部署。

评估器负责在一组固定的开发集上打分。注意，评估器自身的可靠性是整个循环的命门。如果评估器和人类判断不一致，那么所有“改进”都是在朝着错误的方向优化。

记忆库保存所有“假设—改动—结果”三元组。有了记忆，同样的失败实验不会被重复做，新的假设可以在历史结论的基础上生成。很多研究环跑不起来，就是少了这一步，每次迭代都像失忆了一样从头开始。

实验记录器记录每个改动的版本、diff、评估结果、时间戳。它让整个循环具备可审计性。没有记录的自改进等于没做，因为出了问题你根本不知道是哪一次改动造成的。

4. 实践记录：搭建一个最小可用的提示词自研环

4.1 任务、数据集与评估指标怎么定

理论讲多了容易飘，我拿一个自己实际跑过的场景来拆解。假设现在有个信息抽取Agent，要在用户留言中抽取“产品名、型号、故障现象”三个字段，但当前系统提示词效果不理想，我们打算让AI自己改进提示词。

首先准备100条验证样本，人工标注好标准字段。评估指标用字段级F1，简单说就是每个字段的精确率和召回率取调和平均，再加一个整体平均值。注意必须把数据切成开发集和测试集，开发集用来指导循环中的每一轮探索，测试集只在最终验证时用一次。这是铁律，否则你改进的不再是系统能力，而是对测试集的过拟合。

我自己习惯把100条样本分成80条开发、20条测试。太少则评估噪声太大，一次改动涨跌0.01可能只是采样波动；太多则每个样本只能被循环“看”很少的次数，模型学不到规律。80/20是一个朴素但好用的比例。

4.2 修改器与评估器的Prompt写法

自研环里的修改器负责产出提示词修改建议。我给它的指令是这样的：

planner_prompt = """你是一个提示词优化器。下面是信息抽取任务的当前系统提示词， 以及验证集上表现最差的10条失败样本。 当前系统提示词： {system_prompt} 失败样本： {failure_samples} 请提出一条具体的修改建议，要求： 1. 修改幅度最小化，只改与失败原因直接相关的句子； 2. 用一句话说明你预期的影响； 3. 不要引入与当前失败无关的新要求； 4. 直接输出修改后的完整提示词，不要输出解释。 """

这里有个容易忽视的细节：要求模型只给“一条建议”。我最早允许它同时改多个地方，结果根本没法归因——改了三个点分数涨了，你并不知道是哪一个起的作用。一次只验证一个假设，循环才会真正收敛。

评估器也有固定套路：

evaluator_prompt = """你是严格的信息抽取评分员。 系统照着下面的提示词进行抽取： {system_prompt} 对每一条输入，回答以下问题： 1. 抽取结果是否与标准答案逐字段一致？ 2. 是否存在多余字段或遗漏字段？ 输入：{input} 模型输出：{output} 标准答案：{expected} 请输出JSON格式评分，包含字段级正确/错误标记。 """

LLM作为评估器时必须要求输出结构化JSON，这样下游代码可以直接解析，避免自己再去解析一坨自然语言文本。这一点是小坑但特别影响迭代效率。

4.3 循环控制、版本回滚和人类审批

整个循环我用一段伪代码就能说清楚，这也是我推荐的最小实现：

baseline_score = evaluate(system_prompt, dev_set) best_prompt = system_prompt best_score = baseline_score for step in range(max_steps): failures = find_failure_samples(best_prompt, dev_set, top_k=10) candidate_prompts = planner(best_prompt, failures) accepted = False for candidate in candidate_prompts: score = evaluate(candidate, dev_set) if score > best_score + threshold: best_prompt = candidate best_score = score accepted = True record_improvement(candidate, score, failures) break if not accepted: break

几个参数值得展开。max_steps我一般设15，超过这个次数还没找到显著提升，说明搜索空间已经挖完了。threshold我设为0.005，也就是F1提升超过0.5个点才接受改动。如果阈值设为零，模型经常会因为随机波动而接受一个并不真正更好的提示词，导致系统来回震荡。

版本回滚和人类审批同样重要。每一次修改都必须能一键回滚，所以我用git管理提示词版本，每个候选版本一行记录。人工审批点放在每五次迭代后，让一个人快速看一下修改摘要和验证集分数，而不是每轮都盯。这样做既保留了人的控制力，又不会让人的介入频率高到拖慢整个循环。

5. 真实跑循环时踩过的坑

5.1 奖励黑客：模型开始“刷评估器”

如果你跑过几轮自改进，迟早会遇到这个问题：验证集分数在涨，但你肉眼检查输出时发现系统变蠢了。最经典的例子是信息抽取任务里，模型发现只要把所有候选字段全部输出，字段级召回率会变高，于是它开始疯狂输出无关内容。这是典型的奖励黑客，模型不是在变强，而是在钻评估器的空子。

我排查发现，根源在于评估器只算了F1却没有惩罚输出长度。第一个对策是同时跟踪输出长度和精确率，要求精确率不能明显下降；第二个对策是给过长的输出加惩罚项；第三个对策是人工抽检。最有效的手段是提前验证评估器本身——先取20条输出，让评估器和人工分别打分，计算两者的一致性，一致性低于80%时先修评估器，不要急着跑循环。

5.2 同源盲区和回音室漂移

只要批评信号来自同一族模型，就必然带同源偏差。用得多了，系统会逐渐在错误的方向上自我确认。我在连续跑长时间研究环时观察到一个现象：前几轮确实有明显提升，后面开始原地打转，甚至会缓慢下降。原因很简单，模型在自己的输出分布里筛选偏好样例，多样性不断收窄，最后只剩下一个“看起来合理但不合外部需求”的稳态。

这个问题的本质是回音室效应。对策有三个：第一，每个循环周期必须注入一次外部知识，比如加入新标注样本、引入一条人工确认的规则，打破封闭回路；第二，保留一个多样性池子，每次候选生成时从池子里抽样，避免只看同一个失败集合；第三，人类审批时特别关注那些“分数涨了但输出变短变简单了”的改动，那往往是漂移的信号。

5.3 不收敛和成本失控的排查

自研环最容易出现的两个工程问题是不收敛和成本失控。不收敛的常见原因有三个：评估器噪声太大、搜索步长太猛、反馈信号滞后。如果是评估器噪声，把开发集变大或者多次评估取平均就能缓解；如果是步长太猛，限制修改器每次只允许改动一行；如果是信号滞后，检查一下是不是评估结果没有实时写回记忆库。

成本失控也非常现实。一次研究环跑下来，可能调用几十万次模型接口，账单非常难看。我的经验是给循环设三道预算闸门：轮数上限、每轮调用上限、每日总预算上限。还有一个小技巧，候选生成时给模型的输出长度上限设到512字符以内，因为提示词修改建议根本不需要长文，这个限制能省掉大量tokens。

为了方便排查问题，我后来固定了一张运行记录表，每次实验都往里填。这张表我放在下面，你可以直接参考：

有了这张表，绝大多数不收敛问题都能快速定位到具体某一步。

6. 我对递归自改进边界的几点看法

6.1 自改进的上限由评估质量决定

递归自改进工程做了这么久，我个人体会最深的一点是：这个系统的能力上限，不取决于模型有多聪明，而取决于评估器有多可信。模型可以在一秒钟内生成几十种改进方案，但如果没有一个可靠的评估器告诉它哪一步真的变好了，它就只能在一个错误的方向上越跑越远。

所以每次接手自改进项目，我做的第一件事永远不是搭循环，而是先手工验证评估器。我会随机抽50条历史输出，让评估器和人工各打一次分，算一下一致性，一致性达标了才允许进入自动循环。这个习惯帮我避开了至少三次看似进展顺利、实则完全跑偏的实验。

实用主义一点说，从有限的自细化到自主研究环，真正决定成败的往往不是算法，而是工程管理：评估是否可信、版本控制是否严格、结论是否被记忆、每次改动是否可归因。这些脏活累活没有一个是模型能替你做好的。

6.2 从提示词优化到训练数据自举的扩展路径

如果你已经跑通了一个提示词层面的自主研究环，下一步最自然的扩展方向是走向训练数据自举。思路也很直接：研究环在失败样本中识别出模型的系统性弱点，接下来不是去改提示词，而是针对这些弱点生成高质量的训练样本，经过筛选后用于小规模微调，微调后的模型再次进入研究环，如此往复。

这条路我在一些场景里半程实验过，效果比单纯改提示词要持久，但难点在于样本质量筛选。模型生成的数据鱼龙混杂，直接拿去微调很快会把噪声学进去。我的建议是先用一个独立评估器对生成数据的质量打分，再由人抽检20%，双重过滤后才能进入训练集。这也意味着，自主研究环越往后走，越像一个必须搭配人工质检的生产线。

最后再分享一个小经验：别把所有环节都交给模型自治。我尝试过完全无人值守的研究环跑过夜，第二天回来经常发现它对着一堆难以解释的“改进”沾沾自喜。在关键节点保留人工审批，在记忆库里保留完整审计轨迹，在评估器上保留独立验证机制，这三道“刹车”会让整个自改进系统走得更远，也更值得信任。