从LOOP到图探索 - 算法模型的AutoResearch自进化系统架构演进之路
美团技术团队分享 AutoResearch 自进化系统的三次架构演进，从单线程 LOOP 经异步状态机升级为 CyclicGraph Engine 图探索。系统通过主 AI 智能体拆分假设、子 AI 智能体隔离并行验证、主 AI 智能体汇总决策推进研究，并以代码硬约束、原始指标与代码 diff、人工审核保障可信度。
将假设拆分、并行验证与结果收拢组织成研究闭环，并以状态文件和证据链约束执行，为长周期自主实验提供可迁移的工程方法。
点亮👆“☆”星标，不错过推送内容~
全文速读
算法工程师的一天是“改代码—提交训练—等待—看日志—决定下一步”，过程中还经常被打断。我们团队从 Karpathy 的 AutoResearch 出发，经过三次架构重构，搭建出一套可在企业云端训练平台使用的算法研究自进化系统：系统从单线程 LOOP 探索升级为 CyclicGraph Engine 图探索架构，用状态机保证长周期运行的稳定性，并通过“业务知识库 + 真实大闭环 + 经验自动沉淀”实现系统自进化、越用越好用。
在结构、目标与场景均不相同的两个业务建模项目中，单任务完成耗时较人工基线分别减少约 85% 与 83%，其中一个算法模型已将系统自主推导的方案推全上线，并取得线上收益；另一个多目标项目中，系统产出的方案在全部 12 个预估目标上同时超过人工基线。两个项目唯一的共同点是同一套系统架构，说明增益来自架构本身。本文分享这套系统的设计理念、架构演进与可信度设计，希望对大家有所帮助或启发。
🎈我们还在文末增加了读者互动环节，欢迎大家晒出自己的见解、思考，分享实践经验，一起交流学习。
本文目录
1 背景：算法工程师的时间都去哪了？
2 设计理念：我们想造一个什么样的系统？
3 三次架构演进：从 LOOP 到 CyclicGraph Engine
4 垂直耦合：把 AutoResearch 长在业务场景里
5 可信度设计：无人值守时，凭什么相信系统？
6 与 Agent 基座解耦，享受 Agent 红利
7 真实使用体验：从一句需求到自主迭代
8 效果、验证与边界
9 结语：从 Karpathy 出发，走到更远的地方
10 参考文献及补充说明
1 背景：算法工程师的时间都去哪了？
一个算法工程师的典型工作流是：修改代码、推送代码、提交训练、等待、查看日志提取指标、与上一轮对比、决定下一步。等待的间隙，工程师会切换到其他任务，但切换有成本，时间利用不充分；如果训练在凌晨完成，还要等到第二天继续。一天下来，大约完成 2~3 次实质性迭代。真正需要判断力的环节，反而被切换和等待挤压得所剩无几。
2025 年底，Andrej Karpathy 开源了 AutoResearch：一个在单张 H100 上训练 5000 万参数教学级 GPT 的实验原型。仓库只有三个文件：program.md 用自然语言描述研究规则，train.py 是 Agent 唯一可自主修改的训练代码，prepare.py 负责评估。正是这个极简组合，让 LLM 驱动的研究在夜间和周末自动运行。约两天内，系统运行约 700 次实验，产出约 20 个针对 val_bpb 的正向提交。这套循环背后有一个刻意的信任设计：负责评估的 prepare.py 被冻结为不可修改文件，Agent 只能改训练代码而不能改评估函数，从机制上杜绝了“篡改裁判”的可能；而 keep/reset 的 Git 棘轮机制让每一步改进都可审计、可回滚。
这让我们看到了“让 Agent 自主迭代”的可能性。但把它搬进企业场景后，三个问题很快暴露：
可信度问题：规则全部以自然语言 Prompt 声明，模型幻觉会导致执行不完全可信；
运行环境差异：本地单机与企业云端训练平台差异巨大，Agent 需要异步执行，评价指标要体现业务差异性；
LOOP 架构的根本局限：keep/reset 本质是可回滚的单线程串行 LOOP，效果改善就 commit、退化就 reset，同一时刻只能维护一条时间线。多数 AutoResearch 实践者（包括最初的我们）都沿用了这套单线程思路。
本文要讲的，是我们如何在三个月内经历三次架构重构，最终跳出 LOOP 架构，从“跑起来”走到“能自动化、自进化”：V1 回答“能不能跑”，V2 回答“能不能稳定地跑”，V3 回答“能不能跑得又快又准”。
2 设计理念：我们想造一个什么样的系统？
在展开架构细节之前，先说清楚我们的五条设计理念，后面所有取舍都由此推导：
高效、高性价比。Agent 的夜间与周末算力是“闲置产能”，系统要能把人的注意力从执行中解放出来，只保留在高价值判断上。
与底层 Agent 基座解耦。Agent 基座能力在快速进步，每几个月就有性价比更优的选择。系统不应该绑死在任何一家基座上，而是通过良好的 Harness 设计“搭便车”——基座升级，系统免费受益。
系统自进化，越用越好用。经验、工具、Skill 不应该每次从零开始，而应在使用中自动总结、经人工校验后沉淀回系统。
用真实的大闭环获取优质数据。离线指标提升只是中间站，方案上线后的真实反馈回流知识库，才是垂直场景里最稀缺的数据。系统在使用中不断积累业务知识，形成自进化的飞轮。
可信优先。无人值守的长周期循环里，一次错误会成为下一轮决策的输入，逐轮放大。凡是能用代码表达的约束，一律不放在 prompt 里。
3 三次架构演进：从 LOOP 到 CyclicGraph Engine
三个版本不是提前规划的路线图，而是被真实问题驱动的演进。
| 3.1 V1 把 LOOP 搬上企业云端
定时任务 + Shell 脚本周期性触发，单个 Agent 串行完成检查、提取、分析、改代码的全链路，报告归档到云端协作文档。V1 实现了企业云端的 AutoResearch，但上下文爆炸、状态同步不及时等问题造成了低效。
| 3.2 V2 异步循环与显式状态机
每次触发创建全新会话，状态持久化在 JSON 状态文件中，解决了长会话带来的上下文爆炸问题。架构拆分为 Monitor 与 Iterator 两个角色，依靠状态文件的 phase 字段互斥路由，同一时刻只有一个角色工作。状态文件只保留决策所需的最小信息，目标是把探索结果压缩为可复用的决策依据；这是针对 ML 迭代场景的定制设计，与通用图编排框架的“全量状态”思路不同。另一个关键决策是“无状态触发 + 有状态文件”：Agent 不同步等待训练（训练动辄数小时，长会话等待既浪费上下文也不可靠），而是靠定时触发的新会话在下一次唤起时从状态文件恢复现场，这为 V3 的异步并行打下了地基。
| 3.3 V3 CyclicGraph Engine 图探索架构
V3 打破了 V1、V2 沿用的单线程 LOOP 限制，核心机制是 Spawn-Converge：
Spawn：决策层的主 Agent 把一个大问题拆成 3~4 个互斥的差异化假设（例如“特征不足”与“结构不足”），派发给执行层；
执行：子 Agent 通过上下文隔离并行地各自修改代码、提交训练，互不知情，因而不会被彼此的中间结论带偏；
Converge：训练完成后，主 Agent 汇总对比几份独立结果、提炼洞察，并决策下一轮方向组合。
需要强调的是，这与“多开几个实验同时跑”有本质区别。并行只是手段，配套的是三步闭环：主 Agent 先拆互斥假设，子 Agent 各自独立验证，主 Agent 最后收拢对比做决策。如果只并行、不收拢，就退化成了多开实验。
调度层面，系统自 V2 起逐步演进为状态机驱动：异步触发 + 状态恢复，Agent 不同步等待训练，而是依靠状态机在下次触发时查询结果。这是对“训练需要数小时”这一物理约束的合理架构回应，也显著提升了系统稳定性与流程灵活度。
| 3.4 图架构带来的探索效率跃升
图架构的效率收益可以直接量化。在同一个建模项目上：LOOP 架构下 10 次迭代耗时 3 天（0.14 次/小时）且未取得突破；切换为图架构后，12 次迭代仅耗时 4.7 小时（2.55 次/小时）并达成目标，迭代速度相差 18 倍（完整效果见第 8 节）。
差异并非来自单次训练变快，而是来自四点：正交并行把每轮的信息获取量提升约 3 倍；“汇总—分发”的组织形式提高了单位时间内的有效决策数；边界探针快速确定参数的上下界；单变量控制避免了因变量混淆产生的无效迭代。
4 垂直耦合：把 AutoResearch 长在业务场景里
通用 Agent 不懂你的业务。让系统真正可用的关键，是把它垂直耦合到具体业务场景，而这靠的是业务知识库 + 真实大闭环。
| 4.1 业务知识库 系统的“入职培训”
初始化一个新项目时，系统会要求提供基础业务知识库（建模目标、样本口径、历史结论、约束边界），并结合自动化的初始调研构建方向池，保证知识库的起点是干净的。
| 4.2 渐进式调研机制
系统的调研方式分三层：
初始化调研：项目启动时建立方向池，对调研来源做筛选；
渐进式调研：研究过程中按需补充，而不是一次性塞满上下文；
强制调研：当指标边际提升缓慢、连续多轮在同一方案内打转时，触发逃逸机制，强制切换维度并重新调研——避免系统在局部最优里空转烧资源。
| 4.3 真实大闭环 自进化飞轮的燃料
离线指标提升只是中间站。方案上线后的真实反馈（线上实验结论、业务口径的指标变化）会回流进知识库，成为系统在垂直场景内最稀缺的优质数据。离线指标升降是明确的、可机器判读的；线上闭环数据则校准“离线好”与“线上好”之间的偏差。在系统使用过程中，通过知识、经验与工具的持续积累与回流，实现系统在垂直场景的自进化。
5 可信度设计：无人值守时，凭什么相信系统？
长周期自动循环中，Agent 的不可靠行为分为两类，成因和治理手段完全不同：
认知层幻觉：输出在语言上自洽、在事实上错误，例如把训练波动归因为某个并不存在的因素，或把参数填成不存在的取值。它不会报错，只会悄悄把后续决策引向错误方向。
执行层偏差：工具调用失败、返回结果与预期不符，例如平台接口超时、任务 ID 过期、日志字段缺失导致指标解析为空。
治理原则是一句话：凡是能用代码表达的约束，一律不放在 Prompt 里。Prompt 里写“不要重复已证伪方向”并不足够，Agent 仍可能认为“这次情况不同”；但已证伪方向一旦写入状态文件的硬约束列表，下一轮就会在代码逻辑层面被直接跳过。针对执行层偏差，系统在三个环节设防：关键状态以状态文件为唯一事实源，易过期字段（如任务 ID）每轮强制重新读取，禁止复用上下文旧值；所有平台调用封装为幂等化工具，返回值做结构化校验，字段缺失或格式异常即判定失败，而非带着空值继续执行；区分代码故障与基础设施故障，前者计入证伪记录并触发方案调整，后者自动重试且不占用轮次预算。
| 5.1 原始证据优先：指标与 diff 都要“原件”
系统保留每一轮探索的原始指标提升和原始代码 diff。Agent 的分析可能有幻觉，但指标数据和代码修改本身是确定真实的。任何一轮的结论都可以回溯到证据链，而不是回溯到某段叙述。这一点来自我们对幻觉复合效应的观察：循环里错误结论一旦被喂入下一轮上下文，就会在错误前提上叠加错误推理，步步错但步步“看起来合理”；唯一的反制，是让训练结果这样的物理事实成为不可绕过的校验锚点——模型可以幻觉“学习率太小”，但训练跑完后的指标曲线不会配合它幻觉。
| 5.2 上下文隔离与交叉验证
子 Agent 探索时上下文相互隔离，或改用不同模型，从两条路径验证同一个假设，检测分歧。汇总时主 Agent 对照几份独立结果再做决策，天然带一层交叉验证。交叉验证并非每轮都做（成本太高），而是在主 Agent 置信度偏低、连续多轮指标同向恶化、或归因涉及方向性决策时触发；分歧结论同时保留并转入人工审查，而非简单投票取多数。
| 5.3 二级人机校验 Skill 草稿机制
系统在执行过程中会自动总结工具使用经验与踩坑处理方法，沉淀出可复用的 Skill 草稿，经过“系统初筛 + 人工审核”的两级校验后，正式写入系统工具集。一个真实例子：早期批次中训练平台参数服务器连接异常的处理经验被系统自动整理为 Skill 草稿，人工审核后反哺至工具集，此后系统自主应对数百次同类基础设施故障，全程无需人工介入。已入库的 Skill 也会在后续使用中通过审核机制持续自完善。这背后是一条反幻觉的晋升链：经验先作为带证据的低层级记录存在，满足复用规则并通过人工审核后才晋升为正式 Skill，未经外部验证的结论永远不进入知识库，只暂存在临时区。
| 5.4 归因：自进化系统的“慢变量”
Agent 的归因（“为什么这个方向有效”）仍是开放难题。我们的答案不是某个单点技术，而是三方面积累：知识库的积累让归因有业务依据，调研的积累让归因有论文依据，真实实验数据的积累让归因有证据依据。归因能力是慢变量——Harness 建设得好，它会随使用时长持续变好；这本身就是自进化系统设计的一部分。
| 5.5 Harness 决定系统上限
我们把套在通用 Agent 外、让它在生产流程中稳定行动的一组运行规则（状态文件、工具返回校验、失败恢复、经验库、硬约束、提示词）称为 Harness。外部也有同方向的实证：LangChain 的编码 Agent 全程使用同一个模型，仅调整 System Prompt、Tools、Middleware 三个 Harness 维度，在 Terminal Bench 2.0 的 89 个跨领域任务上得分从 52.8% 提升至 66.5%。同一个模型，换一套工作机制，差异达到 14 个百分点。我们的三次重构，本质上就是在与底层通用 Agent 解耦的前提下，打磨这套领域特定的 Harness，它决定系统是加速发现真理，还是加速传播错误。基座模型的能力红利人人可得，而 Harness 是差异化竞争力的所在。
6 与 Agent 基座解耦，享受 Agent 红利
系统与底层 Agent 基座彻底解耦，核心设计是“无状态触发 + 有状态文件”：状态全部落在 JSON 文件里，每次触发都是全新会话。这个设计带来三重收益：随时可触发——不受会话生命周期限制，定时、手动、事件驱动任意唤起；零空转——Agent 不同步等待动辄数小时的训练，触发即工作、完成即退出，长周期任务中也能充分利用计算资源；基座自由——不依赖任何基座的会话记忆或专有能力，Agent 基座升级后，系统可无缝切换。
在前端交互层，我们尝试过 IM 机器人、内部 Agent 平台、自建沙箱等多种形态，框架设计与交互形态完全解耦——换个入口，系统照常运转。
7 真实使用体验：从一句需求到自主迭代
对使用者来说，开启一个新项目非常轻：
用户：我要开始一个新项目，需要给你提供什么？
系统：需要提供基础业务知识库（若有缺失，会询问补充）、需要优化的业务指标、报告归档的云端文档目录、迭代上限和阈值指标（主要用来防止无限制消耗资源），并给出一份可直接填写的需求模板。
用户：填写模板文档，把链接发给系统。
系统：启动自动迭代。中途用户可随时询问进度、打断；如果不打断，系统会在达成目标或达到上限时自行停止。
项目启动后的典型体验是：周五启动，周一回来发现系统已自主完成十余轮迭代，核心指标显著改善，期间零人工介入。这直接修正了我们对人机分工的初始设定（“AI 执行、人监督每一轮方向”）；实践后收敛出的分工边界是：人的价值集中在少数几个高杠杆节点上，而非分散在每一轮的执行监督中。
8 效果、验证与边界
| 8.1 效果：效率增益来自架构本身
在两个模型结构、优化目标、场景均不相同的建模项目上，系统给出了高度一致的答案：单任务完成耗时较人工基线分别减少约 85% 与 83%。两个项目唯一的共同点是同一套系统架构，这说明增益来自架构，而不是某个项目的特殊性。其中一个项目中，系统自主推导出的优化方案（不在任何参考论文中）已通过全部验证并推全上线，取得线上收益；另一个多目标项目中，全部 12 个预估目标均超过人工基线。
| 8.2 与传统 AutoML 的差异
最关键的一点：工程界主流的 AutoML 默认“正确答案在预定义搜索空间内”。而在我们的实际案例中，正确答案恰恰不在初始空间内——系统需要先证伪并退出一个错误的问题框架，再从论文的数学结构中推导出新的候选方案。这是能力层级的差异（从“执行给定方向”到“自主生成假设”），而非搜索效率的差异。
| 8.3 三层验证：自主方案上线和反哺经验
验证覆盖三件事：离线指标、线上实验、可解释性检验。前两件决定上线和推全——离线指标达标后，用线上 A/B 实验结果的置信区间判断是否推全；第三件决定能不能进硬约束库——若 Agent 给不出合理的推导，即使指标好也不入库，避免错误经验污染知识库，无法判断是否可入库时转人工审核。
| 8.4 适用边界与诚实的局限
这套架构适用于同时满足三个条件的场景：有明确的可量化指标；单次实验成本可接受；实验结果可逆。它不适用于评价高度主观、搜索空间完全开放、或单次实验成本极高且不可逆的场景。
基础设施依赖：训练资源是最大的外部瓶颈，系统只能降低资源消耗，无法从根源消除资源紧张；
经验迁移的幻觉风险：涉及垂直业务领域的经验库跨项目复用，可能把局部经验错误泛化，当前靠人工审核卡点拦截；
归因可解释性有限：系统能推导出有效方案，但“为什么有效”的归因解释仍不够严谨，需人工交叉验证后才能进入硬约束库。
下一步的方向：一是提升自进化稳定性 —— 自进化技术架构方向已确定，后续持续打磨状态机与流程稳定性；二是知识迁移中的幻觉问题 —— 如何稳定复用跨业务的经验，保证经验库干净稳定；三是探索更友好的交互与使用体验。
9 结语：从 Karpathy 出发，走到更远的地方
Karpathy 的 AutoResearch 是一个在单张 H100 上跑教学级 GPT 的实验原型。我们所做的，是把这套理念搬进企业云端的真实业务场景：在工程化过程中发现单线程 LOOP 的根本局限，用 CyclicGraph Engine 的图探索架构打破它；用状态机保障长周期运行的稳定性；用业务知识库和真实大闭环，让系统在垂直场景里越用越好用。
我们相信，Agent 自主研究的真正价值不在于“比人更快地搜索已有空间”，而在于“能够证伪错误的前提，并主动扩展搜索空间”。当系统能够从论文的数学结构中推导出人类未给定的方案，并在真实业务中验证有效时，它已经从“执行工具”走向了“研究伙伴”。这条路才刚刚开始。
最后回到方法论本身。三个月三次重构给我们的最大启发是：自主研究系统的核心工程量不在模型侧，而在 Harness 侧——状态机、硬约束、证据链、晋升门槛这些“不性感”的基础设施，才是决定系统可信度的分水岭。评估这套系统的正确方式也不是看它跑得多快，而是看它犯错之后能否被证据纠正、被约束拦住、被经验库记住。可复现、可审计、可回滚，是自主研究系统比效率更重要的底座。
10 参考文献及补充说明
[1] Andrej Karpathy. AutoResearch. GitHub, 2025
[2] Ryan Lopopolo. Harness engineering: leveraging Codex in an agent-first world. OpenAI, 2026
[3] LangChain. The Anatomy of an Agent Harness. LangChain Blog
[4] 统计口径说明：本文统一以“一个训练任务”作为一次迭代的计数单位（并行方向分别计入），含因指标崩溃被证伪的探索性失败；人工基线按实际投入迭代的工作日折算；系统侧仅统计正常执行批次，基础设施故障导致的批次不计入分母。18 倍为图架构相对本系统自身 LOOP 架构的提升；85% 与 83% 为相对人工基线的单任务耗时减少，两者分母不同。
欢迎大家在文末评论区积极留言，可以围绕 AutoResearch、AI在系统架构优化中的应用等话题，展开讨论或分享一些实践经验。我们会精选3条评论，分别为大家送一个美团定制的手机磁吸支架。
活动截止日期：2026年10月28日12:00
---------- END ----------
推荐阅读
❤️❤️❤️ 如果这篇文章对你有帮助，欢迎大家帮忙点赞、评论，分享给更多的小伙伴。⬇️
来源：美团技术团队 · mp.weixin.qq.com