1. 从“AI自动研究”说起一个正在发生的范式转移“递归式自我改进”这个词第一次看到的时候我愣了几秒。不是因为它有多玄乎而是因为它精准地描述了我最近半年在折腾的一件事——让AI代理自己去读论文、跑实验、写总结然后基于总结去读下一批论文。整个过程里人类只负责在最开始给一个方向剩下的迭代循环由系统自己完成。这就是“AI自动研究”的核心把研究流程本身当作一个可以被自动化、被代理驱动的系统来设计。它解决的不是某个具体问题而是“研究效率”这个元问题。适合谁来参考如果你已经在用LLM做单点任务比如写代码、做摘要、跑数据分析但还没把它们串成一个能自我驱动的闭环那这篇内容就是写给你的。如果你刚接触AI代理也没关系我会从最基础的架构讲起把每一步的“为什么”说清楚。先给一个最简定义AI自动研究指的是利用LLM和AI代理构建一个系统让它能够自主完成“提出假设→设计实验→执行验证→分析结果→生成新假设”的循环并且每一轮循环的输出会作为下一轮循环的输入形成递归式的自我改进。注意这里的“自我改进”不是指模型权重自己更新而是指研究策略、提示词、工具调用链在迭代中不断优化。我实测下来这套东西目前还处于“火花乍现”的阶段——能跑通能产出一些有意思的结果但离稳定可靠还有距离。不过正是这个阶段最有意思因为很多工程细节还没有标准答案谁先踩坑谁就先积累经验。2. 整体架构设计为什么是“递归”而不是“流水线”2.1 从线性流水线到递归闭环的思维转变大多数人第一次做AI自动化想到的是流水线输入→步骤A→步骤B→步骤C→输出。这种结构清晰、好调试但它有个致命问题——每一步的优化是孤立的。步骤A的输出质量提升了步骤B可能反而因为输入分布变化而表现下降。你永远在打补丁。递归式自我改进的思路完全不同。它不追求单次流程的完美而是设计一个能“从失败中学习”的循环。具体来说系统每一轮运行都会产生三类数据执行轨迹做了什么、评估结果做得怎么样、反思记录为什么好/为什么差。下一轮运行时这三类数据会被注入到提示词或策略中让系统“带着经验”重新开始。我选择递归架构的核心理由是研究本身就是一个试错过程而不是生产流程。你不可能一次性设计出完美的实验方案但你可以设计一个能从错误方案中快速收敛的系统。2.2 核心组件拆解与选型逻辑一个最小可用的AI自动研究系统需要四个组件规划器Planner负责把大目标拆解成可执行的小任务。我试过用纯提示词做规划也试过用树搜索Tree of Thoughts做规划。实测下来对于研究类任务树搜索的探索能力更强但成本也更高。如果预算有限可以用“提示词规划人工审核”的方式起步。执行器Executor负责实际跑代码、调API、读文件。这里的关键是沙箱隔离——执行器必须有权限限制不能让它随便改系统文件或访问敏感数据。我用的是容器化方案每个实验跑在独立的容器里跑完就销毁。评估器Evaluator负责判断执行结果的好坏。这是整个系统里最难做的部分。对于有明确指标的任务比如模型准确率评估器可以直接读指标。对于开放式任务比如“这个假设有没有新意”就需要用LLM as Judge的方式让另一个模型来打分。我踩过的坑是评估器的标准必须非常具体否则它会给出“看起来不错”这种毫无信息量的反馈。记忆库Memory负责存储历史轨迹和反思记录。我一开始用简单的文件存储后来发现检索效率太低换成了向量数据库。但向量检索也有问题——它倾向于找“相似”的记录而不是“有用”的记录。后来我加了一层基于规则的过滤先按任务类型筛选再做向量检索效果好很多。2.3 递归循环的终止条件设计递归不能无限跑下去必须有终止条件。我设计了三个终止信号收敛信号连续N轮评估分数没有显著提升比如提升小于2%。预算信号累计消耗的token数或API调用次数超过阈值。异常信号执行器连续报错或者评估器给出极端低分。这里有个经验终止条件不要设得太紧。我一开始设了“连续3轮无提升就停”结果系统经常在探索到一个新方向时被强行终止。后来改成“连续5轮无提升且最近一轮的探索方向与历史方向重复度超过80%”才比较合理。3. 核心细节解析提示词、工具链与评估机制3.1 规划器提示词的设计要点规划器的提示词决定了整个系统的“研究方向感”。我试过三种写法自由式“你是一个研究助手请根据当前进展规划下一步。”——结果太发散经常跑偏。模板式“请从以下五个方向中选择一个A. 复现基线 B. 消融实验 C. 超参搜索 D. 数据增强 E. 架构修改。”——结果太死板缺乏新意。混合式先让模型自由生成3-5个候选方向然后用一个评分提示词对每个方向打分新颖性、可行性、预期收益最后选最高分的执行。实测下来混合式效果最好。但要注意评分提示词里必须包含“可行性”的硬约束比如“该方向是否能在当前计算资源下完成”。否则模型会提出“训练一个千亿参数模型”这种根本跑不动的方案。3.2 执行器的工具链配置执行器需要哪些工具我的最小配置是代码执行Python沙箱预装numpy、pandas、scikit-learn、torchCPU版。如果要做深度学习实验再加GPU支持。文件读写限制在特定工作目录内禁止访问上级目录。网络请求只允许访问白名单域名比如arxiv.org、huggingface.co防止意外下载恶意内容。日志记录每次执行都要记录输入、输出、耗时、错误信息。这里有个细节工具调用的返回结果要结构化。我一开始让执行器直接返回原始输出结果规划器经常被大段日志淹没。后来改成返回一个JSON包含status、summary、artifacts、errors四个字段规划器的解析准确率大幅提升。3.3 评估器的校准与防偏见评估器是递归改进的“指南针”。如果指南针不准整个系统就会原地打转。我用了三个策略来校准评估器锚点校准在评估提示词里加入几个已知好/坏的例子让模型参照打分。多评估器投票用两个不同模型比如一个通用模型一个代码专用模型分别打分取平均。如果分差超过阈值就触发人工审核。反事实检验让评估器解释“如果这个结果差差在哪里”而不是只给一个分数。解释文本会存入记忆库供后续轮次参考。我踩过的一个坑是评估器倾向于给“看起来复杂”的结果打高分。比如一个实验跑了很久、输出了很多图表评估器就会觉得“这个工作很扎实”。但实际上那个实验可能只是重复了已知结论。后来我在评估提示词里加了一条“请忽略执行时间和输出数量只关注结果的新颖性和可靠性。”4. 实操过程从零搭建一个最小递归研究系统4.1 环境准备与依赖安装我用的技术栈是Python LangChain Docker SQLite起步阶段。为什么不用更复杂的向量数据库因为起步阶段数据量小SQLite足够而且调试方便。等数据量超过1万条再考虑迁移。安装步骤# 创建虚拟环境 python -m venv auto_research_env source auto_research_env/bin/activate # 安装核心依赖 pip install langchain openai tiktoken docker sqlalchemy # 启动Docker服务用于沙箱执行 sudo systemctl start docker这里注意OpenAI的API key要放在环境变量里不要硬编码在代码中。我见过有人把key写在Jupyter Notebook里然后不小心提交到公开仓库结果被刷了几百美元。4.2 规划器与执行器的代码骨架规划器的核心逻辑def plan_next_step(history, memory, budget): prompt f 当前研究目标{research_goal} 历史执行记录{history[-5:]} 相关记忆{memory.retrieve(history[-1])} 剩余预算{budget} 请生成3个候选研究方向每个方向包含 1. 方向描述 2. 预期收益1-10分 3. 可行性评估1-10分 4. 所需资源估算 然后选择综合得分最高的方向输出具体执行步骤。 response llm.invoke(prompt) return parse_plan(response)执行器的核心逻辑def execute_step(step, sandbox): code step[code] result sandbox.run(code, timeout300) # 结构化返回 return { status: success if result.exit_code 0 else failed, summary: summarize_output(result.stdout), artifacts: result.files_created, errors: result.stderr if result.exit_code ! 0 else None }4.3 递归循环的调度与监控主循环的伪代码while not should_terminate(history, budget): # 1. 规划 plan plan_next_step(history, memory, budget) # 2. 执行 result execute_step(plan, sandbox) # 3. 评估 score evaluate(result, plan) # 4. 反思 reflection reflect(result, score, plan) # 5. 存储 memory.store(plan, result, score, reflection) history.append((plan, result, score)) # 6. 更新预算 budget - estimate_cost(plan, result)监控方面我用了一个简单的Web界面Flask Chart.js来实时显示每轮的评估分数和预算消耗。这样一旦发现分数连续下降可以及时介入。4.4 一次完整实验的记录与分析我跑的第一个完整实验是“让系统自动研究‘如何提升小样本图像分类的准确率’”。系统跑了12轮消耗了约200万token。前3轮都在复现基线第4轮开始尝试数据增强第7轮发现了一个有意思的组合CutMix 对比学习预训练。第9轮做了消融实验确认了对比学习预训练是主要贡献。第12轮因为连续3轮无提升而终止。最终结果在CIFAR-10的100样本子集上准确率从基线的62%提升到了71%。虽然不算惊艳但整个实验设计、执行、分析都是系统自动完成的。我唯一做的是在系统提出“用CutMix”时确认了一下这个方向没有安全风险。5. 常见问题与排查技巧实录5.1 系统陷入“复读机”模式怎么办现象连续多轮规划出几乎相同的方向执行结果也高度相似。原因记忆库的检索机制过于依赖相似度导致系统总是看到“自己刚做过的事”缺乏探索新方向的动力。解决在规划提示词里加入“多样性惩罚”——如果候选方向与最近3轮的方向相似度超过阈值就降低其评分。同时在记忆检索时强制包含至少一条“失败记录”和一条“成功记录”让系统同时看到正反两面。5.2 评估器给出“假高分”怎么排查现象评估分数很高但人工检查发现结果毫无价值。排查步骤检查评估提示词是否包含“新颖性”要求。如果没有加上。检查评估器是否被“执行成功”误导。执行成功不等于结果有价值。引入“对抗评估”让另一个模型专门找茬如果找不出实质性缺陷才认可高分。我踩过的最大的坑是评估器把“输出了漂亮的图表”等同于“结果好”。后来我在提示词里明确写了“图表美观度不计入评分只评估数据本身。”5.3 预算消耗过快怎么优化预算消耗主要来自三个方面规划器的LLM调用、执行器的代码运行、评估器的LLM调用。优化策略规划器用更小的模型做初筛只把最有希望的候选方向交给大模型细化。执行器设置超时和资源限制防止某个实验跑飞。评估器对于有明确指标的任务直接用指标计算不调用LLM。我实测下来评估器是最大的预算黑洞。后来我改成“指标优先LLM兜底”预算消耗降低了约40%。5.4 常见问题速查表问题现象可能原因排查方法解决措施系统连续多轮无进展记忆检索偏差检查检索结果是否过于相似加入多样性惩罚和强制失败记录评估分数虚高评估提示词不具体人工复核高分结果加入新颖性要求和对抗评估执行器报权限错误沙箱配置过严检查Docker权限设置按需开放白名单目录预算消耗过快评估器调用过多统计各组件token消耗指标优先LLM兜底规划方向不可行缺少资源约束检查规划提示词加入计算资源硬约束6. 递归式自我改进的边界与我的个人体会6.1 当前系统的能力边界必须说清楚现在的AI自动研究系统离“自主做科研”还有很大距离。它的强项是“在明确框架内快速试错”弱项是“提出真正颠覆性的假设”。我跑了十几个实验系统提出的方向基本都是已有方法的组合或微调没有出现“从零到一”的突破。但这不意味着它没用。对于“调参、消融、复现”这类重复性高但耗时的工作系统可以节省大量人力。我自己的体验是以前跑一组消融实验要两天现在系统半天就能跑完而且记录更完整。6.2 人类研究者的角色变化在这个范式下人类研究者的角色从“执行者”变成了“方向制定者”和“质量守门人”。你需要做的是定义研究目标并把它拆解成系统能理解的格式。设计评估标准确保系统不会“自欺欺人”。定期审核系统输出及时纠正偏差。在系统陷入局部最优时手动注入新方向。我个人的体会是这套系统让我从“做实验”变成了“设计实验系统”工作重心从动手变成了动脑。虽然更累但也更有意思。6.3 一个值得尝试的扩展方向如果你已经跑通了最小系统可以试试加入“跨任务迁移”让系统在一个任务上积累的反思记录被另一个任务复用。比如系统在图像分类任务上学到的“数据增强策略选择经验”可以迁移到文本分类任务上。我试过这个方向初步结果是正向的但迁移效果取决于任务之间的相似度。相似度太低时迁移反而会引入噪声。最后分享一个小技巧在系统运行初期不要追求全自动。我一开始就设了“每5轮人工审核一次”的规则结果发现了很多系统自己发现不了的问题。等系统稳定运行了20轮以上再逐步放宽审核频率。这个渐进式的信任建立过程比一上来就全自动要靠谱得多。