1. 从“AI自动研究”说起一个正在发生的范式转移“递归式自我改进”这个词第一次看到会觉得有点科幻甚至有点吓人。但如果你最近半年一直在跟大模型、AI代理这些方向打交道就会发现它其实已经不是一个纯理论话题了——它正在以一种非常具体、非常工程化的方式出现在我们的工作流里。我先把话说清楚这篇文章不聊那些宏大的、关于“AI会不会失控”的哲学讨论也不碰任何敏感话题。我想聊的是一个非常实际的问题——当一个AI系统开始参与到“改进AI系统本身”这件事里它的工作方式是什么样的我们作为从业者能从中借鉴什么以及现在就能上手试的东西有哪些。所谓“AI自动研究”核心指的是让大模型驱动的代理去完成一部分原本需要人类研究员来做的工作读论文、提假设、写实验代码、跑实验、分析结果、根据结果调整下一步方向。而“递归式自我改进”指的是这个循环的产物——比如更好的提示词、更好的工具调用策略、更好的代码模板——会被反馈回系统本身让下一轮的研究效率更高。听起来很绕但拆开看其实就三件事自动做实验、自动分析结果、自动把经验沉淀下来。这三件事每一件单独拿出来都不新鲜但把它们串成一个闭环并且让闭环自己迭代这就是最近真正有意思的地方。这篇文章适合谁看如果你是一个已经在用LLM做开发、做研究、做自动化流程的人想搞清楚“AI代理做研究”到底能做到什么程度、怎么落地那这篇就是写给你的。如果你只是听说过这些词但还没动手也没关系我会把每个环节拆到能直接抄作业的程度。2. 递归式自我改进到底在改什么拆解核心机制2.1 三个层次的“自我改进”别搞混了很多人把“自我改进”当成一个东西实际上它至少分三个层次难度和风险完全不同。第一层是提示词层面的改进。系统根据上一轮实验的结果自动调整下一轮给模型的指令。比如第一轮让模型“写一个排序算法”发现生成的代码总是忘记处理边界条件于是第二轮自动在提示词里加上“请特别注意空数组和单元素数组的情况”。这一层最容易实现效果也最直接本质上就是自动化的提示词工程。第二层是策略层面的改进。系统不只是改提示词还会改自己的工作流程。比如发现某类问题先查文档再写代码比直接写代码效果好于是自动把“先检索再生成”这个策略固化下来。这一层需要系统有一定的“元认知”能力能对自己的行为做归因。第三层是代码和架构层面的改进。系统能修改自己的工具函数、甚至修改自己的调度逻辑。这一层最接近大家想象中的“递归式自我改进”但也是目前工程上最谨慎的——因为一旦系统能改自己的核心代码可控性就会急剧下降。目前实际能跑起来的系统绝大多数停留在第一层和第二层之间。第三层有研究性质的尝试但离稳定可用还有距离。我后面讲的实操方案也主要聚焦在前两层。2.2 为什么是现在三个条件同时成熟了这件事之所以最近才变得可行是因为三个条件同时到位了。条件一是模型的指令遵循能力够用了。两三年前的模型你让它“根据实验结果调整下一步方案”它大概率会给你一段看起来像那么回事但完全没法执行的废话。现在的模型在结构化输出、工具调用、多步推理上的稳定性已经能支撑一个基本的自动研究循环。条件二是工具生态起来了。以前要让模型跑实验你得自己写一大堆胶水代码。现在有现成的代码执行沙箱、有标准化的工具调用协议、有成熟的代理框架搭一个能跑实验的代理工作量从几周降到了几天。条件三是成本降下来了。一个自动研究循环可能要跑几十上百轮每轮都要调模型。如果每轮成本是几块钱那根本跑不起来。现在用中等规模的模型配合好的提示词很多研究辅助任务已经能控制在可接受的成本范围内。这三个条件缺一个递归式自我改进就只能停留在论文里。现在三个都差不多了所以你会看到各种demo和开源项目冒出来。2.3 一个最小可用的自动研究循环长什么样我用一个具体例子来说明。假设你想让AI帮你研究“如何用LLM做单元测试生成”这个问题。一个最小循环是这样的给定初始问题“为Python函数自动生成单元测试要求覆盖边界条件。”代理提出假设“如果先让模型分析函数的输入空间再生成测试覆盖率会更高。”代理设计实验写一段代码对比“直接生成”和“先分析再生成”两种策略在同一个测试集上的覆盖率。代理执行实验调用代码执行工具跑出结果。代理分析结果发现“先分析再生成”确实覆盖率更高但在处理递归函数时效果下降。代理更新策略在下一轮中对递归函数增加“先识别递归结构”的步骤。回到第2步基于更新后的策略继续提假设。这个循环跑十轮你就能得到一个针对特定问题、经过实证验证的策略集合。这个策略集合本身就是有价值的产出——它可能比你自己拍脑袋想出来的方案更全面因为它系统地尝试了很多你没想到的组合。注意这个循环里最关键的不是模型有多强而是“实验设计”和“结果分析”这两个环节的严谨性。如果实验设计有漏洞或者结果分析被模型的幻觉带偏整个循环就会在错误的方向上越走越远。3. 搭建一个自动研究代理从零到能跑3.1 工具选型别一上来就追求全自动我见过太多人一上来就想搭一个“全自动AI研究员”结果卡在工具链上两周就放弃了。我的建议是先用最笨的办法跑通一个最小循环再逐步替换组件。具体来说第一版可以这样搭模型用一个中等规模的模型做主力比如7B到14B级别的指令微调模型本地跑或者调API都行。不要一上来就用最大的模型成本扛不住而且很多研究辅助任务不需要那么强的能力。代码执行用一个简单的子进程执行器把模型生成的代码写到临时文件里跑捕获stdout和stderr。注意一定要设超时和资源限制否则一个死循环就能把你的机器拖垮。结果存储用一个JSON文件或者SQLite数据库每轮实验的输入、输出、分析结果都存下来。这个记录后面会非常有用因为你需要它来做跨轮次的对比分析。调度一个简单的while循环就够了不需要上复杂的编排框架。每轮结束检查一下是否达到终止条件比如跑了20轮或者连续3轮没有改进。这个最小版本可能只有两三百行代码但它能让你在一天之内看到“自动研究循环”到底是怎么运转的。跑通之后你再根据实际瓶颈去替换组件——比如发现代码执行太慢就换成更高效的沙箱发现模型分析结果不靠谱就换更强的模型或者加验证步骤。3.2 提示词设计让模型“像研究员一样思考”自动研究代理的提示词和普通对话提示词完全不是一个东西。普通提示词追求“回答准确”研究代理的提示词追求“过程可追溯、结论可验证”。我实测下来比较有效的结构是这样的你是一个研究助理正在研究以下问题[问题描述] 当前已有的发现 [列出之前轮次的关键结论] 上一轮实验的结果 [粘贴上一轮的实验输出和分析] 你的任务是 1. 基于已有发现和上一轮结果提出一个可验证的假设 2. 设计一个能验证该假设的实验方案 3. 写出实验代码 4. 预测实验结果这很重要强迫模型做显式推理 输出格式 假设[一句话] 实验方案[步骤列表] 代码[Python代码] 预期结果[描述]这个结构里最关键的是第4步“预测实验结果”。我试过去掉这一步结果模型经常生成一些“跑完才知道有没有意义”的实验。加上预测之后模型会更有意识地去设计有区分度的实验而不是随便跑一个看看。另外提示词里一定要明确要求模型“如果上一轮结果与预期不符优先分析原因而不是直接进入下一轮”。这个约束能避免循环在错误方向上狂奔。3.3 实验执行环境安全第一效率第二让模型生成的代码在你机器上跑这件事本身就有风险。我踩过的坑包括模型生成了一个无限循环、模型试图删除文件、模型生成了一个占满内存的数组。所以执行环境必须做隔离。我的做法是用容器每个实验在一个临时容器里跑跑完就销毁。Docker是最省事的方案一个基础镜像加上必要的依赖就行。设资源上限CPU时间限制在30秒内存限制在512MB磁盘写入限制在100MB。超过就杀掉把超限信息返回给模型让它知道自己的代码有问题。禁网实验容器不联网。大部分研究辅助实验不需要网络禁网能避免很多意外情况。只读挂载除了一个专门的输出目录其他路径都只读挂载。这些限制看起来麻烦但跑起来之后你会发现模型很快就学会了在限制内工作。而且因为超限信息会返回给模型它下一轮会自动调整代码这本身就是一个自我改进的过程。3.4 结果分析与策略更新最容易出幻觉的环节实验跑完了结果也有了接下来让模型分析结果并更新策略。这个环节是整条链路上最容易出问题的因为模型很容易“看到它想看到的结果”。我的应对方法是加一个验证步骤让模型先输出分析结论然后单独再调一次模型把原始实验数据和第一轮的分析结论一起给它让它扮演“审稿人”角色专门挑毛病。具体提示词你是一个严格的审稿人。以下是实验原始数据和一份分析报告。 请指出 1. 分析报告中哪些结论缺乏数据支持 2. 实验设计是否存在混淆变量 3. 是否有其他合理解释被忽略 如果分析报告没有问题请明确说“未发现明显问题”。这个“审稿人”步骤能过滤掉相当一部分幻觉。我实测下来大约能拦住60%到70%的过度解读。剩下的那些就需要你在关键节点人工介入了。策略更新的时候不要直接覆盖旧策略而是追加。每一轮的新策略都带着“基于第N轮实验”的标签存下来。这样你最后得到的是一棵策略演化树而不是一个黑盒。这棵树本身就有研究价值——你能看到模型是怎么一步步走到最终方案的。4. 实操全流程一个完整的研究循环记录4.1 问题设定与初始配置我拿一个真实跑过的例子来演示。问题是“如何让LLM生成的单元测试更好地覆盖边界条件”初始配置模型一个14B级别的指令微调模型本地部署执行环境Docker容器Python 3.11pytest测试对象20个手写的Python函数涵盖数值计算、字符串处理、数据结构操作评估指标分支覆盖率用coverage.py测量最大轮次15轮终止条件连续3轮覆盖率提升小于1%初始策略很简单“直接让模型为每个函数生成测试用例。”4.2 第一轮到第三轮快速发现明显改进第一轮跑完平均分支覆盖率是62%。模型的分析结论是“生成的测试主要集中在正常路径边界条件覆盖不足。”第二轮策略更新为“在生成测试前先让模型列出该函数的所有边界条件然后针对每个边界条件生成至少一个测试。”这一轮覆盖率跳到了78%。模型分析发现“显式列出边界条件确实有效但对于有多个参数的函数边界条件的组合爆炸导致部分组合被遗漏。”第三轮策略更新为“先列出边界条件然后按参数逐个生成边界测试最后再生成组合测试。”覆盖率到了83%。到这里改进速度开始放缓。4.3 第四轮到第八轮进入瓶颈期第四轮到第六轮覆盖率在83%到85%之间波动。模型尝试了几种策略增加测试数量、改变测试生成顺序、引入类型提示信息效果都不明显。第七轮模型提出了一个有意思的假设“也许问题不在于测试生成策略而在于评估指标本身。分支覆盖率可能无法反映边界条件的实际覆盖情况。”这个假设让我有点意外——模型开始质疑评估框架本身了。我让它设计了一个补充指标对每个函数人工标注出关键边界条件然后测量这些边界条件被测试覆盖的比例。第八轮跑完发现分支覆盖率85%的情况下关键边界条件覆盖率只有71%。这说明之前的优化方向有一部分是在“刷指标”而不是真正解决问题。这是整个循环里最有价值的一个发现。如果没有自动化的多轮实验我可能不会想到去质疑评估指标本身。模型的“天真”反而让它跳出了我的思维定式。4.4 第九轮到第十五轮策略收敛基于第八轮的发现后续策略调整为“以关键边界条件覆盖率为主要优化目标分支覆盖率作为辅助指标。”第九轮到第十二轮关键边界条件覆盖率从71%提升到了89%。主要改进来自对每个参数单独生成边界测试后再生成两两组合的测试对数值参数自动识别边界值0、负数、最大值、最小值对字符串参数自动识别空串、超长串、特殊字符。第十三轮到第十五轮覆盖率稳定在90%左右连续三轮提升小于1%触发终止条件。最终产出的策略集合包括策略编号策略描述引入轮次关键边界覆盖率S1直接生成测试162%S2先列边界条件再生成278%S3按参数逐个生成边界测试383%S4引入关键边界条件评估指标871%S5以关键边界覆盖率为优化目标985%S6参数两两组合测试1088%S7自动识别数值和字符串边界值1289%S8组合S5S6S71390%这个策略集合可以直接迁移到类似的测试生成任务上。而且因为每一轮都有记录你能清楚地看到每个策略的贡献和局限。4.5 成本与时间记录整个15轮跑下来实际耗时大约6小时包括模型推理时间和实验执行时间。模型调用成本折算下来大约在几十块钱的量级。如果换成更大的模型成本会上升但收敛速度可能更快总成本未必更高。时间分布上模型推理占了大约70%实验执行占了20%结果分析和策略更新占了10%。所以如果你要优化整个循环的速度优先优化模型推理环节——比如用更快的推理框架或者对简单任务用小模型、复杂任务用大模型。5. 常见问题与排查技巧实录5.1 模型陷入重复循环怎么办这是最常见的问题。模型连续几轮提出几乎相同的假设或者反复尝试同一个策略的微小变体。排查思路先看实验记录确认是不是因为上一轮结果没有提供足够的新信息。如果是说明实验设计缺乏区分度需要调整提示词要求模型“设计一个能明确区分两种策略的实验”。如果实验设计没问题但模型还是重复那就是模型本身的能力瓶颈。这时候可以尝试换一个更强的模型做策略更新环节或者人工介入给一个方向性提示。我的做法在提示词里加一条规则——“如果连续两轮假设相似度超过80%必须强制引入一个全新的维度”。这个规则能逼着模型跳出局部最优。5.2 实验结果不可复现怎么办模型生成的代码有时候带有随机性或者依赖了未固定的环境状态导致同一段代码跑两次结果不一样。排查思路检查代码里有没有随机种子、时间戳、文件系统状态等不确定因素。在执行环境里固定随机种子禁用网络确保文件系统状态一致。我的做法在每个实验跑之前先跑一次“空实验”——用相同的代码跑两次对比结果。如果两次结果不一致就把这个实验标记为“不可靠”不纳入策略更新依据。5.3 模型过度解读实验结果模型看到覆盖率从83%提升到85%就得出结论“策略X显著有效”但实际上这个提升可能在统计上不显著。排查思路在结果分析环节加入统计检验。对于连续指标要求模型计算置信区间对于离散结果要求做显著性检验。我的做法在提示词里明确要求——“任何结论必须附带效应量和置信区间。如果置信区间跨零不得声称策略有效。”这个约束能大幅减少过度解读。5.4 策略更新后效果反而下降有时候模型根据一轮实验结果更新了策略下一轮效果反而变差了。这通常是因为模型把噪声当成了信号。排查思路回看策略更新那一步的推理过程看模型是不是基于单轮结果就做了激进调整。我的做法要求模型在更新策略前必须至少有两轮一致的结果支持。如果只有一轮结果只能做“试探性调整”并且下一轮必须设计一个验证实验来确认这个调整是否真的有效。5.5 常见问题速查表问题现象可能原因排查方法解决技巧连续多轮假设相似实验缺乏区分度检查实验设计强制引入新维度结果不可复现代码有随机性跑空实验对比固定种子、禁用网络过度解读结果缺少统计约束检查分析报告要求置信区间策略更新后变差把噪声当信号回看更新推理要求两轮一致支持循环提前终止终止条件太松检查终止逻辑增加最小改进阈值模型输出格式错误提示词不够明确检查输出解析加格式示例和校验6. 这套东西现在能用来做什么不能用来做什么6.1 适合的场景有明确评估指标的优化问题自动研究循环最适合的场景是那些有明确、可自动计算的评估指标的问题。比如代码生成用测试通过率、覆盖率做指标提示词优化用任务准确率做指标超参数搜索用验证集损失做指标数据清洗策略用下游任务效果做指标这些场景的共同点是实验可以自动跑结果可以自动算好坏可以自动判断。只要满足这三个条件自动研究循环就能跑起来而且往往能发现一些人工容易忽略的策略组合。6.2 不适合的场景需要人类判断的开放问题反过来如果评估指标本身需要人类判断或者问题定义模糊自动研究循环就不太适用。比如创意写作什么叫“更好”很难自动评估产品设计涉及用户偏好和商业考量战略决策需要整合大量外部信息这些场景不是完全不能用但循环的“自动”程度会大幅降低需要频繁人工介入。与其叫“自动研究”不如叫“研究辅助”。6.3 一个容易被忽略的价值策略的可解释性自动研究循环产出的不只是最终策略还有整个策略演化过程。这个过程本身就有很高的参考价值。比如在我前面那个测试生成的例子里模型在第八轮质疑评估指标本身这个“元认知”步骤是人工设计流程时很容易忽略的。因为人类研究员往往带着自己的假设进入问题而模型没有这个包袱它会更“天真”地去尝试各种可能性。所以即使最终策略没有超过人工设计的方案这个演化过程也能给你提供新的视角。我现在的做法是不管自动循环有没有找到更好的策略都会把演化树保存下来作为后续人工设计的参考。7. 我踩过的几个坑和对应的解法7.1 坑一一开始就追求全自动我第一个版本想做一个完全不需要人工介入的系统结果跑了三天产出了一堆看起来合理但实际没法用的策略。问题出在模型在某个环节产生了幻觉但因为没有人工检查点这个幻觉被后续所有轮次继承和放大。解法在关键节点设人工检查点。我的做法是每5轮人工看一次策略演化树确认方向没有跑偏。这个检查点不需要深入分析只需要判断“大方向对不对”。如果不对就回滚到上一个检查点调整提示词后重新跑。7.2 坑二实验环境太宽松早期版本我没有设资源限制结果模型生成了一个OOM的代码把整个容器搞挂了还丢了一部分实验记录。解法严格执行资源隔离。每个实验在独立容器里跑设CPU、内存、磁盘、时间上限。超限就杀掉把超限信息返回给模型。这个反馈本身就能让模型学会写更高效的代码。7.3 坑三提示词太长导致模型“忘记”早期指令随着循环轮次增加提示词里累积的上下文越来越长模型开始忽略早期的一些约束条件。解法把提示词分成“固定部分”和“动态部分”。固定部分包含核心约束和输出格式每轮都完整保留动态部分只包含最近几轮的关键信息更早的信息压缩成摘要。这样既控制了长度又保留了关键上下文。7.4 坑四没有记录“失败实验”早期我只记录成功的实验失败的实验跑完就丢了。后来发现失败实验里往往包含更有价值的信息——它们能告诉你“什么路走不通”避免后续轮次重复踩坑。解法所有实验都记录包括失败的。在策略更新时明确要求模型参考失败实验的记录避免重复尝试已经被证伪的假设。8. 后续可以怎么扩展这套东西跑通之后有几个方向可以继续深挖。方向一是多代理协作。目前是一个代理在跑整个循环。可以拆成“假设生成代理”、“实验设计代理”、“结果分析代理”三个角色各自用不同的提示词和模型互相制衡。这样能进一步减少单点幻觉的影响。方向二是引入外部知识。目前循环完全基于实验数据。可以加入论文检索、文档查询等工具让代理在提出假设前先查一下有没有现成的研究成果。这样能避免重复造轮子也能站在更高的起点上。方向三是策略的跨任务迁移。在一个任务上跑出来的策略集合能不能迁移到类似任务上比如测试生成任务上跑出来的策略能不能用到代码补全任务上这个问题目前还没有很好的答案但值得试试。方向四是把循环本身作为研究对象。不同模型、不同提示词结构、不同终止条件对循环的收敛速度和最终效果有什么影响这个问题可以设计对照实验来回答而且实验本身也可以用自动研究循环来跑——这就有点递归的味道了。最后分享一个我在实际操作中的体会自动研究循环最大的价值不是替代人类研究员而是把人类从重复性的试错中解放出来让人能专注于真正需要判断力的环节。模型负责穷举和验证人负责定义问题和判断方向。这个分工目前来看是最稳的。