从生成方案到决定下一步：AutoResearch 如何无幻觉闭环研究过程

AutoResearch 把问题发现、方案生成、蜂群实验和独立验证串成一条可持续推进的研究流程。在 Django 修复任务中，它将官方新增功能测试从 2/7 推进到 7/7，同时保持 203/203 个回归测试通过；在三项 Kaggle 实验中，它也能区分达标、接近目标与平台期，并据此继续、换方向或停止。

AutoResearch 是一套自动化研究系统。它持续观察论文、开源项目、社区讨论和技术异常，从中发现值得研究的问题，组织多个模型把想法变成实验，再让外部结果决定下一步。

这条流程要解决一种比凭空编造更隐蔽的错误：代码真实存在，本地测试也确实通过，系统却把“这部分做对了”误判为“整个问题已经解决”。

图 1｜本地测试全绿，只能证明已经覆盖的检查通过；独立评测负责发现尚未覆盖的关键缺口。

在一次真实 Django 修复任务中，GPT-5.6 的 716 个 migration 测试和 39 个 optimizer 测试全部通过，官方新增功能测试却是 0/7。AutoResearch 第一轮也没有完整解决问题：本地测试全绿，官方结果只有 2/7。区别发生在失败之后。系统继续根据外部结果改写问题，沿着 2/7、4/7、7/7 推进，直到新增功能测试和回归测试同时通过。

1. 四个动作构成研究主循环

图 2｜找题、造题、做实验、让证据裁决，四个动作构成 AutoResearch 的主循环。

AutoResearch 的主循环包含四个连续动作：

1. 发现问题：从开放信息中筛出可以追溯的新现象、新结果或未解决矛盾。
2. 形成可验证的 Idea：把线索改写成有成功标准、资源边界和失败条件的研究假设。
3. 组织蜂群实验：让计划、实现、运行和审查由不同角色协作完成。
4. 让证据裁决：外部结果决定继续迭代、改写方向或停止。

失败不会自动关闭工作流。它会成为下一轮的输入，促使系统收紧问题边界或改变实验路径。

2. 在回答之前，先找到值得研究的问题

AutoResearch 关注 arXiv、Hugging Face Daily Papers、OpenReview、GitHub Trending，也关注 Reddit、Hacker News、研究博客、中文技术媒体和 Twitter/X。不同渠道的数据格式、热度含义和信息密度差异很大，采集后需要先转成统一结构，再进行质量过滤、同批去重和跨天去重。

第一层模型负责快速判断一条信息中是否存在可以转化为研究课题的洞察。留下的候选再交给能力更强的模型，从新颖性、技术可行性、资源需求和验证方法等维度继续筛选。候选足够多时，系统再次排序，选出优先进入 Idea Forge 的研究种子。

这条漏斗把开放的信息流压缩成少量值得投入实验资源的候选。研究问题保留明确来源，后续方案才能回到最初观察进行复核。

3. Idea Forge：把线索变成实验计划

研究种子只是来自外部世界的现象或问题。Idea Forge 还会从知识库中选择一个已有研究方向，将两者组合成候选方案。当前知识方向包括多模态融合、视觉 Token 管理、大模型推理与测试时计算（test-time compute）、Agent Memory 等。

Gemini、GPT 和 Claude 分别提出并审查候选 Idea。三类模型的训练背景和判断偏好不同，有的更敏感于新颖性，有的更关注技术可行性，有的会先发现资源与评估漏洞。候选方案进入执行前需要完成四项检查：

• 交叉评审：三个模型独立判断，同一 Idea 至少获得两票才能继续。
• 时新性检查：排除陈旧模型、旧年份和已经过时的技术表述。
• 知识共识检查：确认方案真正使用了对应知识方向，没有把热门词机械拼接。
• 多阶段计划：第一阶段先做能够快速判定方向的预实验，后续再扩大实验、增加消融并完成评估。

多数票只用于尽早暴露盲点。最终方案仍要落到可测假设、明确预算和能够判定成败的实验上。

4. 从计划到实验：蜂群如何协作

图 3｜研究种子经过交叉评审和计划后，进入计划、实现、运行、审查与外部评测组成的协作流程。

进入执行阶段后，AutoResearch 把工作拆成连续的任务单元。协调角色维护全局状态，规划角色把目标改写成可证伪的实验方案，实现角色负责编写代码，实验执行角色运行代码并整理结果，评审角色从不同角度寻找遗漏。

简单任务可以减少角色，复杂任务可以增加 Subcoder、Monitor 或独立验证角色。角色名称并不决定结果，关键是计划、实现、运行和审查不再挤在一次模型回答里。

计划、代码、实验记录和评审意见保留在同一个持久工作区。循环执行机制会继续处理没有完成的单元，直到外部指标和停止条件允许工作流关闭。规划会被实验结果推翻，评审也会误判；角色给出的结束建议不能关闭工作流。是否继续、何时结束，由可复现结果和独立成功标准决定。

5. 系统验证一：把研究目标推进到可验证结果

AutoResearch 在三个 Kaggle 题目上采用相似的实验协议：先以低成本预实验验证方向，再根据结果设计主实验；每个阶段都有成功标准、代码审查、运行记录和停止判断。三个题目分别使用准确率、均方根对数误差（RMSLE）和 F1 作为主要指标，指标方向与 Kaggle 官方赛题一致 [1][2][3]。

图 4｜同一套实验协议产生三种结局：Titanic 达标，House Prices 接近目标，Disaster Tweets 进入平台期。三张图的纵轴彼此独立，不作跨任务数值比较。

5.1 Titanic：严格对照确认特征工程的提升

第一阶段使用 9 个基础特征建立基线，Gradient Boosting 的 5 折交叉验证准确率为 0.8272。第二阶段加入 Title、FamilySize、IsAlone、Age 分箱和 Fare 分箱等特征。

Control 与 Treatment 使用相同随机种子、相同数据折和相同模型。Control 保留基础特征，Treatment 加入扩展特征。Control 完整复现第一阶段结果，Treatment 达到 0.8428，越过 0.8300 的目标线。两组实验的主要差异只有特征集合，因此结果支持特征工程带来本轮提升。

5.2 House Prices：先找到贡献最大的改动

目标是把 5 折交叉验证 RMSLE 降到 0.1200 以下。系统先在小样本上建立 Ridge 基线，再只改变预测目标，对房价做 log1p 变换，RMSLE 从 0.2008 降到 0.1566。加入少量派生特征后为 0.1563，继续堆特征的收益已经很小。

进入全量实验后，模型族从线性模型切换到 LightGBM，结果降到 0.1258；扩展特征和交互项最终做到 0.1251。目标没有达到，但实验已经定位主要增益来源：目标变换和模型族切换贡献了绝大部分改善，追加特征只有边际收益。系统据此停止机械扩张调参范围。

5.3 Disaster Tweets：平台期触发停止

目标是 F1 达到 0.8350。系统从 TF-IDF 和逻辑回归开始，建立 0.7680 的词法基线，再尝试 SBERT、DistilBERT 微调和软投票集成，最高达到 0.8049。

随后参数量从 66M 增加到 125M，换用 RoBERTa-base，最好成绩为 0.8005，没有超过 DistilBERT。连续 21 次实验后，最优结果仍为 0.8049。更大的模型没有带来增益，系统停止沿同一路线追加实验，并将下一步收敛为三类选择：增加有效数据、增加训练资源，或改变建模路线。

6. 系统验证二：从局部修复推进到完整解决

第二组实验来自 SWE-bench Lite 的 django__django-16820。SWE-bench 将模型生成的补丁应用到真实仓库，并运行仓库测试判断问题是否解决 [4]。这项任务源于 Django 对 Meta.index_together 的弃用处理，涉及 migration optimizer 和 autodetector 对 RenameIndex、AddIndex、RemoveIndex 及循环外键的协同处理；Django 上游讨论也记录了这些索引操作与复杂迁移优化之间的关系 [5]。

图 5｜GPT-5.6 在本地测试通过、官方新增测试 0/7 后结束；AutoResearch 根据 2/7 与 4/7 的反馈继续改写问题，最终达到 7/7，并保持 203/203 个回归测试通过。两组的时间与反馈条件不同，这里比较的是失败后的流程。

GPT-5.6 找到一个真实缺口：CreateModel.reduce() 缺少对 RenameIndex(old_fields=...) 的折叠逻辑。补丁通过 39 个 optimizer 测试、716 个 migration 测试和 203 个官方回归测试，官方新增功能测试仍为 0/7。补丁解决了 RenameIndex 子问题，没有覆盖 AddIndex、RemoveIndex、autodetector 和循环外键。

AutoResearch 第一轮同样把重点放在 RenameIndex。代码审查发现 no-match guard 缺失，修复后 41 个 optimizer 测试、11 个 squashmigrations 集成测试和 719 个 migration 测试通过，首轮官方结果为 2/7。

外部结果将研究视角从单个 reduce() 分支扩展到 optimizer 与 autodetector 的协同，第二版提升到 4/7。下一轮继续追踪索引状态如何进入迁移流程、如何折叠并最终收敛。最终，官方新增功能测试达到 7/7，同时保持 203/203 个回归测试通过。

7. AutoResearch 自动化的是研究决策

这两组实验说明 AutoResearch 的核心能力落在五个环节：

1. 把研究问题变成可执行对象：Idea 必须落到预实验、成功标准、资源预算、消融方案和交付物。
2. 把不同模型放在合适的位置：轻量模型筛选大量候选，能力更强的模型深入判断，多类模型交叉提出和审查 Idea。
3. 让阶段性结果指向下一步：达到目标、接近目标和负结果都会留下证据，分别触发扩展、调整或停止。
4. 把完成条件交给独立指标：内部角色达成共识、本地测试全绿，都不能替代预先定义的完整成功标准。
5. 允许系统停止：当方向进入平台期或投入产出比下降时，系统关闭当前路径，并留下重新启动所需的状态和结论。

模型负责提出、实现和质疑，证据负责决定下一步。

8. 成功是一条没有断掉的证据链

大模型已经很擅长快速生成候选答案。AutoResearch 进一步设计了答案之后的完整回路：问题怎样变成实验，结果由谁审查，失败如何改写下一步，什么证据足以支持继续，以及系统在什么条件下停止。

这套方法可以称为循环工程（Loop Engineering）：需要设计的不只有角色和提示词，还包括状态如何保留、证据如何流动、判断如何被复核。角色可以犯错，回路必须让错误暴露，让缺少证据的“成功”无法关闭工作流。

9. 参考文献

1. Kaggle. (2012). Titanic - Machine Learning from Disaster. Kaggle Getting Started Competition.
2. Kaggle. House Prices - Advanced Regression Techniques. Kaggle Getting Started Competition.
3. Kaggle. Natural Language Processing with Disaster Tweets. Kaggle Getting Started Competition.
4. Jimenez, C. E., Yang, J., Wettig, A., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. The Twelfth International Conference on Learning Representations.
5. Django Software Foundation. (2023). Fixed #34529, Refs #34525: Reduced index operations with Meta.indexes / index_together when optimizing migrations. django/django Pull Request #16820.