跳转至

从 LOOP 到 CyclicGraph Engine：美团算法模型 AutoResearch 自进化系统的三次架构重构

📊 Level ⭐⭐ | 15.9KB

来源：美团平台技术部（美团技术团队公众号，2026-10-22）。文章把 Karpathy 的 AutoResearch 理念搬进企业云端训练平台，用三个月三次架构重构把「单线程 LOOP 自进化」升级为「图探索（CyclicGraph Engine）」，并给出可信度设计与两个真实业务建模项目的量化效果。

核心判断一句话：自主研究系统的工程量不在模型侧而在 Harness 侧——状态机、硬约束、证据链、晋升门槛这些「不性感」的基础设施，才是决定系统可信度的分水岭；而真正的能力跃迁不是「比人更快地搜索已有空间」，而是「能证伪错误的前提并主动扩展搜索空间」。

起点：Karpathy AutoResearch 的极简设计与它的三处不适配

Karpathy 2025 年底开源的 AutoResearch 是一个单张 H100 上训练 5000 万参数教学级 GPT 的实验原型，仓库只有三个文件：program.md 用自然语言描述研究规则、train.py 是 Agent 唯一可自主修改的训练代码、prepare.py 负责评估。关键在于信任设计——评估函数被冻结为不可修改文件，Agent 只能改训练代码不能改裁判；keep/reset 的 Git 棘轮让每一步改进可审计可回滚。约两天内系统运行约 700 次实验、产出约 20 个针对 val_bpb 的正向提交。

搬进企业场景后暴露三个问题：其一是可信度——规则全部以自然语言 Prompt 声明，模型幻觉会导致执行不完全可信；其二是运行环境差异——本地单机与企业云端训练平台差异巨大，Agent 需要异步执行、评价指标要体现业务差异性；其三是 LOOP 架构的根本局限——keep/reset 本质是可回滚的单线程串行循环，同一时刻只能维护一条时间线。多数 AutoResearch 实践者（包括最初的作者团队）都沿用了这套单线程思路。

三次演进：V1 能跑 → V2 能稳定跑 → V3 跑得又快又准

三个版本不是提前规划的路线图，而是被真实问题驱动的演进。V1 用定时任务 + Shell 脚本周期性触发，单个 Agent 串行完成检查、提取、分析、改代码全链路，报告归档到云端协作文档——实现了企业云端的 AutoResearch，但上下文爆炸与状态同步不及时造成低效。

V2 转为异步循环 + 显式状态机：每次触发创建全新会话，状态持久化在 JSON 状态文件中，解决长会话的上下文爆炸；架构拆为 Monitor 与 Iterator 两个角色，依靠状态文件的 phase 字段互斥路由，同一时刻只有一个角色工作。状态文件只保留决策所需的最小信息（把探索结果压缩为可复用的决策依据），这是针对 ML 迭代场景的定制设计，刻意区别于通用图编排框架的「全量状态」思路。另一个关键决策是「无状态触发 + 有状态文件」：Agent 不同步等待动辄数小时的训练，而是靠定时触发的新会话在下一次唤起时从状态文件恢复现场。

V3 是 CyclicGraph Engine 图探索，用 Spawn-Converge 打破单时间线：Spawn 阶段主 Agent 先把问题拆成互斥假设，分派子 Agent 各自独立修改代码、提交训练、互不知情，因而不会被彼此的中间结论带偏；Converge 阶段主 Agent 汇总对比几份独立结果、提炼洞察并决策下一轮的探索方向组合。作者特别强调这与「多开几个实验同时跑」有本质区别：并行只是手段，配套的是「拆互斥假设 → 独立验证 → 收拢对比决策」三步闭环，只并行不收拢就退化成多开实验。

效率账：18 倍从哪来

同一建模项目上，LOOP 架构 10 次迭代耗时 3 天（0.14 次/小时）且未取得突破；切换为图架构后 12 次迭代仅 4.7 小时（2.55 次/小时）并达成目标，迭代速度相差 18 倍。差异不来自单次训练变快，而来自四点：正交并行把每轮信息获取量提升约 3 倍；「汇总—分发」的组织形式提高单位时间内的有效决策数；边界探针快速确定参数上下界；单变量控制避免因变量混淆产生无效迭代。

可信度设计：无人值守时凭什么相信系统

作者把长周期循环里 Agent 的不可靠行为分为两类，成因与治理手段完全不同：认知层幻觉是输出在语言上自洽但事实错误（把训练波动归因于并不存在的因素、把参数填成不存在的取值），它不报错，只会悄悄把后续决策引向错误方向；执行层偏差是工具调用失败或返回结果与预期不符（平台接口超时、任务 ID 过期、日志字段缺失导致指标解析为空）。

治理原则浓缩为一句话：凡是能用代码表达的约束，一律不放在 Prompt 里。Prompt 里写「不要重复已证伪方向」并不足够，Agent 仍可能认为「这次情况不同」；但已证伪方向一旦写入状态文件的硬约束列表，下一轮就在代码逻辑层面被直接跳过。针对执行层偏差在三个环节设防：关键状态以状态文件为唯一事实源，易过期字段（如任务 ID）每轮强制重新读取、禁止复用上下文旧值；平台调用封装为幂等化工具并对返回值做结构化校验（字段缺失或格式异常即判失败，而非带着空值继续）；区分代码故障与基础设施故障——前者计入证伪记录并触发方案调整，后者自动重试且不占用轮次预算。

原始证据优先：系统保留每一轮探索的原始指标提升与原始代码 diff。Agent 的分析可能幻觉，但指标数据与代码修改本身是确定真实的——任何一轮结论都可回溯到证据链而非某段叙述。作者观察到「幻觉复合效应」：循环里错误结论一旦被喂入下一轮上下文，就会在错误前提上叠加错误推理，步步错但步步「看起来合理」；唯一反制是让训练结果这类物理事实成为不可绕过的校验锚点。

上下文隔离与交叉验证：子 Agent 间上下文隔离，或改用不同模型从两条路径验证同一假设并检测分歧；交叉验证不每轮都做（成本太高），只在主 Agent 置信度偏低、连续多轮指标同向恶化、或归因涉及方向性决策时触发，且分歧结论同时保留并转人工审查而非投票取多数。

Skill 草稿的两级晋升：系统会自动总结工具使用经验与踩坑处理，沉淀为可复用 Skill 草稿，经「系统初筛 + 人工审核」后正式写入工具集。真实案例：早期批次中训练平台参数服务器连接异常的处理经验被自动整理为 Skill 草稿，人工审核后反哺工具集，此后系统自主应对数百次同类基础设施故障、全程无需人工介入；已入库 Skill 也会在后续使用中通过审核机制持续自完善。其背后是一条反幻觉的晋升链——经验先作为带证据的低层级记录存在，满足复用规则并通过人工审核才晋升为正式 Skill，未经外部验证的结论永远不进入知识库。

归因是慢变量：Agent 的归因（「为什么这个方向有效」）仍是开放难题。其答案不是某个单点技术，而是三方面积累——知识库让归因有业务依据、调研让归因有论文依据、真实实验数据让归因有证据依据；Harness 建设得好，归因会随使用时长持续变好，这本身就是自进化系统设计的一部分。

垂直耦合：知识库、强制调研逃逸与真实大闭环

通用 Agent 不懂你的业务，可用的关键是把系统垂直耦合到具体场景，靠的是「业务知识库 + 真实大闭环」。初始化新项目时系统要求提供基础业务知识库（建模目标、样本口径、历史结论、约束边界），并结合自动化初始调研构建方向池。调研分三层：初始化调研建立方向池并筛选来源；渐进式调研在研究过程中按需补充而非一次性塞满上下文；强制调研在指标边际提升缓慢、连续多轮在同一方案里打转时触发逃逸机制，强制切换维度重新调研，避免在局部最优里空转烧资源。

真实大闭环是自进化飞轮的燃料：离线指标提升只是中间站，方案上线后的线上实验结论与业务口径指标变化会回流知识库。离线指标升降是明确、可机器判读的，线上闭环数据则校准「离线好」与「线上好」之间的偏差。

Harness 决定系统上限

作者把「套在通用 Agent 外、让它在生产流程中稳定行动的一组运行规则」（状态文件、工具返回校验、失败恢复、经验库、硬约束、提示词）称为 Harness，并引用 LangChain 的实证：编码 Agent 全程使用同一个模型，仅调整 System Prompt、Tools、Middleware 三个 Harness 维度，在 Terminal Bench 2.0 的 89 个跨领域任务上得分从 52.8% 提升至 66.5%——同一模型换一套工作机制差异达 14 个百分点。三次重构本质上就是在与底层基座解耦的前提下打磨这套领域特定 Harness：基座能力红利人人可得，Harness 才是差异化竞争力所在。

解耦的具体设计仍是「无状态触发 + 有状态文件」，带来三重收益：随时可触发（不受会话生命周期限制，定时/手动/事件驱动皆可）、零空转（触发即工作、完成即退出）、基座自由（不依赖任何基座的会话记忆或专有能力，基座升级可无缝切换）。前端交互层也完全解耦——IM 机器人、内部 Agent 平台、自建沙箱换入口不影响系统运转。

效果、与 AutoML 的能力层级差异、适用边界

两个模型结构、优化目标、场景均不相同的建模项目上，单任务完成耗时较人工基线分别减少约 85% 与 83%；两个项目唯一共同点是同一套架构，说明增益来自架构而非项目特殊性。其中一个项目中，系统自主推导的优化方案（不在任何参考论文中）已通过全部验证并推全上线、取得线上收益；另一个多目标项目中，系统产出的方案在全部 12 个预估目标上同时超过人工基线。

与主流 AutoML 的关键差异在于：AutoML 默认「正确答案在预定义搜索空间内」，而在该团队的实际案例中正确答案恰恰不在初始空间内——系统需要先证伪并退出一个错误的问题框架，再从论文的数学结构中推导出新候选。这是能力层级的差异（从「执行给定方向」到「自主生成假设」），而非搜索效率的差异。验证因此覆盖三件事：离线指标、线上 A/B 实验置信区间（前两件决定能否推全）、可解释性检验（决定能否进硬约束库——若 Agent 给不出合理推导，即使指标好也不入库，避免错误经验污染知识库）。

适用边界被诚实限定为三个条件同时满足的场景：有明确可量化指标；单次实验成本可接受；实验结果可逆。不适用于评价高度主观、搜索空间完全开放、或单次实验成本极高且不可逆的场景。三条明示局限：基础设施依赖（训练资源是最大外部瓶颈，系统只能降耗不能消除紧张）、经验迁移的幻觉风险（垂直经验跨项目复用可能把局部经验错误泛化，当前靠人工审核卡点）、归因可解释性有限。作者还纠正了对人机分工的初始设定——原以为「AI 执行、人监督每一轮方向」，实践后收敛为「人的价值集中在少数几个高杠杆节点上」。

与既有 AutoResearch 工作的关系

与 AutoResearch 四环设计框架 相比，本文提供的是同一问题在生产工艺侧的版本：四环框架回答「自进化循环应该怎么设计」，本文回答「循环在企业云端跑三个月会遇到什么、如何用状态机与图探索绕过去」。与 1688 LLM 训练优化实践 同属第一方生产落地，但 1688 侧重「让 Agent 接手 LLM 训练调优」的单链路，本文侧重多假设并行的探索拓扑与可信度治理。

与 Harness-of-Harness（上海 AI Lab） 构成镜像：HoH 是在不改 harness 底座的前提下把开发过程组织成反复的「规划-编码-测试」循环、追求单线深挖；本文则保持 Harness 可改但把探索从单线程 LOOP 扩成图，追求并行假设的覆盖与收拢。两者都收敛到同一结论——限制来自 Harness 而非模型。

关联

→ 原文存档