1. 从“AI自动研究”说起一个正在发生的范式转移“AI自动研究递归式自我改进的火花乍现”——这个标题我第一次看到的时候心里咯噔了一下。不是因为它有多玄乎而是因为它精准地描述了一个我最近半年在实操中反复观察到的现象大语言模型不再只是被动地回答你的问题它开始能自己提出问题、自己设计实验、自己评估结果然后基于评估结果去改进下一轮的方案。这个循环一旦跑通哪怕每一轮只进步一点点累积起来的效果也是惊人的。我先把话说在前头这篇文章不聊科幻不聊“AI觉醒”只聊我作为一个一线开发者在搭建和调试AI代理AI Agent自动研究流程时踩过的坑、总结的方法、以及对这个“递归式自我改进”到底能做到什么程度的真实判断。如果你正在做LLM应用开发、AI代理编排、或者对“让模型自己研究自己”这件事感兴趣那这篇内容应该能帮你省下不少试错时间。所谓“AI自动研究”说白了就是让一个基于LLM的智能体系统能够自主完成“提出假设→设计验证方案→执行验证→分析结果→修正假设”这个完整闭环。而“递归式自我改进”则是这个闭环的进阶版系统不仅改进研究对象的方案还会把每次研究的经验沉淀下来用来优化自己下一轮的研究策略。听起来很绕但拆开看核心组件就那么几个一个能规划任务的LLM、一套能执行具体操作的工具集、一个能评估结果好坏的评判机制、以及一个能存储和调用历史经验的记忆系统。我最初接触这个方向是因为一个很实际的需求我需要频繁地测试不同的提示词策略对模型输出质量的影响。手动测试太慢了一天测不了几组而且人脑记不住那么多变量组合。于是我就想能不能让AI自己来跑这个实验它自己生成提示词变体自己调用模型跑测试自己根据预设的评分标准打分然后把高分策略保留下来下一轮基于高分策略再生成新的变体。这个想法落地之后我搭的第一版系统虽然粗糙但确实跑通了一个最小闭环。也就是从那时候起我开始认真思考“递归式自我改进”这件事在工程上到底意味着什么。2. 核心架构拆解一个能跑起来的自动研究系统长什么样2.1 四个核心模块与它们之间的数据流一个能实际运转的AI自动研究系统我倾向于把它拆成四个模块来看。第一个是任务规划器通常就是一个经过特定提示词调教的LLM负责把一个大目标拆解成可执行的小步骤。第二个是工具执行层这里面包括代码执行器、API调用器、文件读写器等等负责把规划器输出的指令变成实际动作。第三个是结果评估器这是整个系统里最容易被低估但最关键的部分它决定了系统能不能判断“这一轮到底有没有进步”。第四个是经验记忆库用来存储每一轮的方案、执行结果、评估分数和反思总结供后续轮次检索调用。这四个模块之间的数据流是这样的规划器从记忆库中检索历史经验结合当前目标生成新一轮的实验方案方案被传递给工具执行层执行层调用具体工具完成任务并返回原始结果评估器对原始结果进行打分和分析生成结构化的评估报告最后规划器根据评估报告生成反思总结连同本轮方案和结果一起写入记忆库。下一轮循环开始时规划器又会从记忆库中检索最新的经验如此往复。我一开始把评估器想得太简单了觉得用一个LLM打个分就行。实际跑起来才发现LLM打分的一致性很差同一份结果两次打分可能差出20分。后来我改成“规则评分LLM评分”的混合模式能用确定性规则算的指标比如代码是否运行成功、输出是否符合格式要求就用规则算只有主观质量类的指标才交给LLM评判并且要求LLM给出具体的评分理由。这样改完之后评分的稳定性明显提升。2.2 为什么选择递归式而不是单轮式单轮式的自动研究就是让AI跑一次完整的“假设-验证-分析”流程然后输出报告。这种方式适合探索性的任务比如“帮我调研一下某个技术方案的优缺点”。但如果你想要的是持续优化单轮式就不够了因为它没有利用上一轮的结果来指导下一轮。递归式的核心价值在于经验累积。每一轮的研究结果不管是成功还是失败都会被结构化地存储下来。下一轮规划时系统会检索相似历史案例避免重复踩坑同时继承上一轮的有效策略。这就像是一个研究员做完一个实验后会把实验记录本翻出来看看而不是每次从零开始。但递归式也带来了新的工程挑战。最直接的问题就是错误累积如果某一轮的评估出了偏差这个偏差会被写入记忆库影响后续所有轮次的决策。我遇到过好几次这样的情况某一轮因为评估标准设置得过严把一个其实不错的方案判了低分结果后续几轮系统都绕着这个方向走白白浪费了很多轮次。后来我在记忆库里加了一个“评估置信度”字段对于置信度低的评估结果在后续检索时降低其权重这才缓解了这个问题。2.3 工具选型为什么我最终选了这套组合在工具选型上我试过不少方案。LLM方面我主要用两个模型搭配一个能力较强的模型做规划器和评估器一个速度较快、成本较低的模型做具体的执行和初筛。这种“强模型规划快模型执行”的分工模式在成本和效果之间取得了比较好的平衡。代理框架方面我早期用过一些通用的Agent框架但后来发现对于自动研究这个场景通用框架的抽象层反而增加了调试难度。最终我选择了一套轻量级的编排方案用Python脚本做主干控制流用函数调用Function Calling的方式让LLM输出结构化的工具调用指令自己写了一个简单的调度器来管理工具执行和结果回传。这样做的好处是每一层的输入输出都完全透明出问题的时候容易定位。记忆库方面我用的是向量数据库加结构化数据库的组合。向量数据库用来做语义检索比如“找出历史上所有关于提示词优化的实验记录”结构化数据库用来做精确查询和统计分析比如“计算最近10轮实验的平均评分”。两者通过一个统一的ID体系关联起来。提示不要一上来就追求全自动。我建议先用“半自动”模式跑通流程AI生成方案人工确认后再执行。等流程稳定了再逐步放开自动执行。这样可以避免早期因为评估不准导致的大量无效轮次。3. 实操过程从零搭建一个最小可用的自动研究循环3.1 环境准备与基础依赖安装我假设你已经有基本的Python开发环境并且能调用至少一个主流LLM的API。下面是我实际使用的一套基础依赖你可以直接参考pip install openai chromadb pydantic tenacity rich这里解释一下每个包的作用。openai是LLM调用客户端如果你用的是其他厂商的模型替换成对应的SDK即可。chromadb是我用的向量数据库轻量、易上手适合快速原型。pydantic用来做数据模型定义和校验自动研究系统里数据结构很多用pydantic可以省去大量手工校验的代码。tenacity用来做重试控制LLM调用偶尔会失败加上重试机制能显著提升系统稳定性。rich用来在终端里打印格式化的日志调试的时候非常有用。环境变量方面你需要设置LLM的API Key和Base URL。我习惯用一个.env文件来管理LLM_API_KEYyour_key_here LLM_BASE_URLhttps://api.your-provider.com/v1然后代码里用os.getenv读取。这样做的好处是切换模型提供商的时候只需要改环境变量不用动代码。3.2 定义核心数据结构让每一轮实验都可追溯在写任何业务逻辑之前我强烈建议先把数据结构定义清楚。自动研究系统里最核心的数据结构是“实验记录”我用的定义大概长这样from pydantic import BaseModel, Field from typing import Optional from datetime import datetime class ExperimentRecord(BaseModel): round_id: int hypothesis: str plan: str execution_result: str evaluation_score: float evaluation_reason: str reflection: str timestamp: str Field(default_factorylambda: datetime.now().isoformat()) parent_round_id: Optional[int] None这个结构里hypothesis是本轮实验的假设plan是具体的执行方案execution_result是原始执行结果evaluation_score和evaluation_reason是评估器的输出reflection是规划器基于评估结果生成的反思总结。parent_round_id用来记录本轮实验是基于哪一轮的结果衍生出来的这样整个实验历史就形成了一棵树方便追溯。我踩过的一个坑是早期没有记录parent_round_id结果当系统跑了几十轮之后我完全搞不清楚某一轮实验到底是从哪个分支演化出来的。加上这个字段之后整个实验脉络就清晰了。3.3 规划器的提示词设计让LLM输出可执行的结构化方案规划器的提示词是整个系统里最需要反复打磨的部分。我最初的提示词写得很随意结果LLM输出的方案经常是“你可以尝试优化一下提示词”这种没法执行的话。后来我改成强制要求输出JSON格式并且给出了具体的字段说明和示例效果才好起来。我目前用的规划器提示词模板大致是这样的你是一个自动研究系统的规划模块。你的任务是基于当前目标和历史实验记录生成下一轮实验的具体方案。 当前目标{goal} 历史实验记录摘要 {history_summary} 请输出一个JSON对象包含以下字段 - hypothesis: 本轮实验的核心假设一句话描述 - plan: 具体的执行步骤要求每一步都是可操作的包含具体的参数和预期输出 - success_criteria: 判断本轮实验是否成功的标准要求可量化 注意 1. 如果历史记录中有失败的方案避免重复 2. 如果历史记录中有部分成功的方案可以在此基础上改进 3. 方案要具体到可以直接执行不要出现“优化”“改进”这类模糊词汇这个提示词的关键在于成功标准必须可量化。我试过让LLM自己定义成功标准结果它经常给出“输出质量有所提升”这种没法打分的话。后来我强制要求它给出具体的数值阈值或者明确的判断条件评估器才能正常工作。3.4 评估器的实现规则打分与LLM打分怎么结合评估器是我花时间最多的模块。纯规则打分太死板很多主观质量维度覆盖不到纯LLM打分一致性太差同一份结果两次打分可能差很多。我最终的方案是分层评估第一层是硬性规则检查比如代码是否能运行、输出是否符合格式要求、是否包含必填字段。这一层是二值判断通过就是通过不通过就是0分直接淘汰。第二层是量化指标计算比如输出长度、关键词覆盖率、与参考答案的相似度等。这些指标可以用确定性算法算出来作为基础分。第三层是LLM主观评分针对那些没法用规则衡量的维度比如逻辑连贯性、论证充分性、表达清晰度。我要求LLM对每个维度单独打分并且给出具体的评分理由。为了提升一致性我会在提示词里给出详细的评分标准并且要求LLM参考历史评分案例。最终得分是三层得分的加权和。权重怎么定我的经验是硬性规则占30%量化指标占30%LLM主观评分占40%。这个比例可以根据具体任务调整但硬性规则的权重不宜过低否则系统容易跑偏。3.5 记忆库的读写策略什么时候存什么时候取记忆库的读写策略直接决定了递归式改进的效果。我的做法是每轮实验结束后立即写入包括方案、结果、评分和反思。写入的时候除了结构化字段还会把方案和反思的文本内容做向量化存入向量数据库。读取的时候分两种场景。规划器生成新方案时会做一次语义检索找出历史上最相似的5条实验记录作为参考。评估器打分时会检索历史上相同维度的评分案例作为打分参考提升一致性。这里有一个细节值得注意检索时不要只看高分的记录。我早期只检索高分记录结果系统一直在高分方案附近打转缺乏探索性。后来我改成“高分记录随机低分记录”的混合检索策略让系统既能利用成功经验也能从失败中学习探索能力明显增强。注意记忆库需要定期清理。跑了几百轮之后向量数据库里会积累大量低质量记录检索效果会下降。我的做法是每50轮做一次清理把评分低于阈值且反思内容空洞的记录归档或删除。4. 递归式自我改进的实际效果与边界4.1 我观察到的“火花”哪些场景下递归改进真的有效跑了几个月之后我积累了一些比较明确的观察。递归式自我改进在以下几类任务上效果最明显第一类是参数调优类任务。比如调整提示词的措辞、调整模型调用的温度参数、调整输出格式的约束条件。这类任务的特点是搜索空间明确、评估标准清晰递归改进能快速收敛到较优解。我做过一个实验让系统自动优化一个文本分类任务的提示词跑了20轮之后分类准确率从初始的72%提升到了89%而且后续轮次的提升幅度明显递减说明已经接近该方案的上限。第二类是代码生成与修复类任务。让系统自己写代码、自己运行测试、自己根据报错信息修复这个闭环非常自然。我试过让系统自动生成数据处理的Python脚本它能在几轮之内把脚本从“能跑但结果不对”迭代到“结果正确且处理了边界情况”。第三类是多方案对比类任务。系统生成多个候选方案分别执行并评估然后基于评估结果生成新的候选方案。这种“生成-评估-再生成”的循环本质上是一种引导式搜索比随机搜索效率高很多。但在以下几类任务上递归改进的效果就很有限需要外部领域知识的任务系统没法自己获取它不知道的知识、需要物理实验验证的任务纯数字环境没法执行、以及评估标准高度主观且不一致的任务评估器本身就不稳定递归只会放大噪声。4.2 递归的“天花板”在哪里三个硬约束第一个硬约束是评估器的精度上限。递归改进的本质是“基于评估结果做优化”如果评估本身不准优化方向就会跑偏。我试过用一个较弱的模型做评估器结果系统跑了30轮评分一直在小幅波动没有实质性提升。换成强模型做评估器之后同样的任务10轮就看到了明显进步。所以我的建议是评估器用的模型能力不能低于规划器这是硬性要求。第二个硬约束是记忆检索的召回质量。如果系统在生成新方案时检索不到真正相关的历史经验那递归就退化成随机搜索了。我遇到过检索结果全是无关记录的情况原因是向量化模型对某些专业术语的语义表征不够准确。后来我加了一层关键词过滤先按关键词粗筛再做语义精排召回质量才稳定下来。第三个硬约束是任务本身的可分解性。如果一个任务没法被拆解成“假设-验证-分析”的循环那递归改进就无从谈起。比如“写一首好诗”这种任务你很难定义什么是“假设”也很难量化评估递归改进就很难发挥作用。4.3 一个真实的递归改进案例提示词自动优化我拿一个实际跑过的案例来具体说明。任务是优化一个“技术文档摘要生成”的提示词目标是让生成的摘要更简洁、更准确、更符合技术写作规范。初始提示词是我手写的评估得分62分满分100。系统第一轮生成的方案是“在提示词中增加‘请用不超过100字总结’的约束”执行后得分68分。第二轮基于第一轮的结果方案是“在约束字数的同时要求‘保留所有关键技术术语’”得分74分。第三轮方案是“增加示例展示期望的摘要风格”得分81分。第四轮方案是“调整示例的数量和多样性”得分83分。第五轮之后提升幅度明显变小最终稳定在85分左右。整个过程中系统自动生成了12个提示词变体执行了12轮评估总耗时约40分钟包括LLM调用时间。如果人工来做同样的探索过程可能需要一整天。更重要的是系统在反思记录里写下了“字数约束和术语保留之间存在张力需要在提示词中明确优先级”这样的洞察这是我在手动优化时未必能这么快总结出来的。5. 常见问题与排查技巧实录5.1 系统跑着跑着就不动了死循环与超时处理这是我最常遇到的问题。系统跑到某一轮之后规划器生成的方案和上一轮几乎一样执行结果也差不多评估得分没有变化然后下一轮又生成类似的方案陷入死循环。排查思路是这样的首先看规划器的输入检查历史记录摘要里是不是包含了太多相似记录导致LLM认为“这个方向已经探索完了”但又没有给出新方向。如果是这个问题可以在提示词里加一句“如果历史记录显示某个方向已经充分探索请尝试一个完全不同的方向”。其次看评估器检查是不是评分标准太宽松导致所有方案都得了差不多的分数系统失去了优化信号。如果是这个问题需要收紧评分标准拉开分差。我还在调度器层面加了一个硬性保护如果连续3轮的评估得分变化小于阈值比如2分就强制触发“探索模式”让规划器生成一个与历史方案差异度最大的方案。这个机制虽然简单但有效避免了系统在局部最优附近空转。5.2 评估分数忽高忽低LLM评分不一致的解法LLM评分不一致是另一个高频问题。同一份输出今天打分85明天打分72这种情况我遇到过很多次。除了前面提到的“规则LLM”混合评估方案我还有几个实操技巧。第一个技巧是固定评分参考系。在评估提示词里附上3-5个历史评分案例明确告诉LLM“这份输出得了X分理由是Y”让LLM有一个具体的参照。这比抽象地描述评分标准有效得多。第二个技巧是多次评分取中位数。对于关键轮次我会让评估器对同一份输出打分3次取中位数作为最终得分。虽然增加了成本但显著提升了稳定性。第三个技巧是评分理由结构化。要求LLM按“优点-缺点-改进建议”的结构输出评分理由而不是给一个笼统的评价。结构化之后我更容易判断评分是否合理也更容易发现评分偏差的模式。5.3 记忆库检索不准向量化模型的选型与调优记忆库检索不准的问题根源往往在向量化模型上。我试过好几个开源的向量化模型发现不同模型对技术文本的语义表征能力差异很大。有些模型对通用文本效果好但对专业术语的区分度不够。我的选型经验是如果你的任务涉及大量专业术语优先选择在相关领域数据上训练过的向量化模型。如果没有领域专用的那就选维度较高、训练数据较丰富的通用模型。另外检索时不要只依赖向量相似度加上关键词过滤和元数据过滤比如按时间范围、按评分区间能显著提升召回质量。还有一个容易被忽略的点查询文本的构造方式。我早期直接用规划器的完整输出作为查询文本效果不好。后来改成提取规划器输出中的核心关键词和意图描述构造一个更聚焦的查询文本检索准确率提升了很多。5.4 常见问题速查表问题现象可能原因排查方法解决措施系统连续多轮得分不变评估标准太宽松或方案同质化检查评分分布和方案差异度收紧评分标准增加探索机制评估分数波动大LLM评分不一致同一输出多次评分对比混合评估参考案例取中位数检索结果不相关向量化模型不适配或查询构造不当人工检查检索结果更换模型关键词过滤优化查询系统执行超时工具调用卡住或LLM响应慢查看各步骤耗时日志加超时控制重试机制降级方案递归多轮无实质进步评估器能力不足或任务不可分解对比评估器与规划器能力升级评估器模型或调整任务设计提示这张表是我从实际调试记录里整理出来的建议你在自己的系统里也维护一份类似的问题日志。每次遇到新问题就记一笔时间长了就是一份非常有价值的排查手册。6. 我对“递归式自我改进”的真实判断6.1 当前阶段能做到什么做不到什么先把结论说清楚当前阶段的递归式自我改进在有明确评估标准的封闭任务上确实能产生实实在在的效果。我亲眼看到系统在提示词优化、代码修复、参数调优这些任务上用几十轮迭代达到甚至超过人工调优的水平。这个“火花”是真实的不是炒作。但它离“AI自己研究自己、自己改进自己”还有很长的距离。核心瓶颈在于系统没法自己定义“什么是更好的”。所有的评估标准都是人给的系统只是在给定的标准下做搜索和优化。如果标准本身有问题系统只会沿着错误的方向越走越远。我试过故意给一个错误的评估标准系统果然在几轮之内就“学会”了钻空子生成一堆符合标准但实际毫无价值的东西。另一个瓶颈是跨领域迁移能力。系统在提示词优化任务上积累的经验很难直接迁移到代码修复任务上。每一类任务都需要重新设计评估器和调整提示词。这意味着“递归式自我改进”目前还是一个任务一个系统没法做到通用。6.2 给想入坑的朋友几条实在建议如果你看完这篇文章想自己搭一个自动研究系统试试我有几条建议。第一条从最小闭环开始。不要一上来就搞复杂的多代理协作、复杂的记忆架构。先写一个最简单的循环LLM生成方案→执行→LLM打分→把结果喂回LLM生成新方案。这个最小闭环跑通了再逐步加东西。第二条评估器比规划器重要。很多人把精力花在优化规划器的提示词上但实际决定系统效果上限的是评估器。评估器不准规划器再强也没用。建议在评估器上多花时间多做对比测试。第三条记录一切。每一轮的输入、输出、评分、耗时、token消耗全部记录下来。这些数据不仅帮你排查问题还能帮你分析系统的行为模式。我现在的系统里日志文件比代码文件还大但每次出问题都能从日志里找到线索。第四条对“自动”保持警惕。自动研究系统跑起来之后很容易产生一种“它在自己进步”的错觉。但实际上它只是在你的评估标准下做搜索。定期人工审查系统的输出确保它没有跑偏这是必须做的功课。6.3 后续可以继续探索的方向这个系统我还在持续迭代。接下来想尝试的几个方向包括引入多评估器投票机制来提升评分稳定性、尝试用更强的模型做“元规划”即规划“如何规划”、以及探索把递归改进应用到多模态任务上的可能性。另外有一个我觉得很有潜力的方向让系统自己发现评估标准的漏洞。具体做法是定期让一个独立的LLM审查历史评估记录找出“高分但实际质量差”的案例然后基于这些案例修正评估标准。这相当于给评估器加了一个“自我审计”的环节理论上能让整个系统的评估能力也进入递归改进的循环。这个想法我还在实验阶段等跑出稳定结果了再单独写一篇分享。最后分享一个我在调试过程中总结的小技巧每次修改系统配置之后不要直接跑完整流程先用一个固定的“基准任务”跑3轮对比修改前后的得分曲线。这样可以快速判断修改是正向还是负向的避免在长流程里浪费时间。这个习惯帮我省下了大量调试时间推荐你也试试。