从 LOOP 到图探索：AutoResearch 如何成为长期运行的研究系统

蓝天和花岗岩巨石之间的一座石屋 — 巨石之间的石屋（Photo by Lucas Favre on Unsplash）

算法工程师一天能做多少次有效迭代？

表面上看，工作流程并不复杂：改代码、提交训练、等待、看日志、比较指标，然后决定下一步。问题在于，训练并不会因为人暂时离开而停止，但人的注意力会被别的事情带走。原文把这种状态描述得很具体：一天通常只能完成两三次实质性迭代，真正需要判断的环节，反而被等待和任务切换挤压了。

美团技术团队分享的 AutoResearch 系统，起点是 Karpathy 的 AutoResearch 原型，终点则不再是一个简单的“自动改代码、自动跑实验”脚本。三个月里，系统经历了三次重构：先把 LOOP 搬上云端，再用状态机解决长周期运行，最后用 CyclicGraph Engine 把单线探索改成可以分叉和汇合的研究流程。

这篇文章的重点，不在于复述一套名词，而在于解释：为什么一个能跑的自动化循环，最后必须长成一套带状态、带证据、带边界的运行系统。

“我们如何在三个月内经历三次架构重构，最终跳出 LOOP 架构，从‘跑起来’走到‘能自动化、自进化’。”
——《从 LOOP 到图探索》，原文第 3 节，来源：美团技术团队

一、LOOP 解决了什么，又没有解决什么

Karpathy 的 AutoResearch 有一个很简洁的结构：program.md 描述研究规则，train.py 是 Agent 可以修改的训练代码，prepare.py 负责评估，而且评估文件被冻结，不能被 Agent 改写。

这套设计有两个值得注意的地方。

第一，它把“研究动作”压缩成了一个可以重复的循环：修改、训练、评估、保留或回滚。第二，它没有把裁判交给 Agent 自己。训练代码可以改，评估函数不能改，这实际上是在系统层面阻止“篡改裁判”。

这就是 LOOP 的基本形态：每一轮只有一条主路径。变好就 keep，变差就 reset，然后从当前最好的版本继续走。

这种设计很适合作为起点，因为它简单、容易审计，也能快速验证一个问题：Agent 是否能够在没有人工逐轮操作的情况下持续做实验。

但企业环境很快会把问题放大。训练平台不再是本地单机，训练任务可能运行几个小时；指标不再只有一个教学用指标；报告、状态和任务 ID 还要和云端平台同步。更关键的是，单线程循环只能维护一条探索路径。

原文对这三个问题的归纳是：自然语言规则带来可信度问题，本地环境和企业云端存在差异，而 keep/reset 的单线程 LOOP “同一时刻只能维护一条时间线”。

分析： LOOP 的问题不是它错了，而是它把研究过程简化成了“沿着当前最优路径继续走”。当实验成本变高、等待时间变长、可能的研究方向变多时，这种简化就不够用了。

二、V1、V2、V3：系统是怎样被问题推着往前走的

V1：先把一个 Agent 放进企业云端

V1 很直接：用定时任务和 Shell 脚本定期触发，一个 Agent 串行完成检查、提取、分析和代码修改，报告保存到云端协作文档。

它完成了第一步迁移，但也暴露出明显问题：所有事情都挤在一个长会话里，训练和分析的状态同步不及时，上下文越积越大。

所以，“自动触发”并不等于“自动运行得好”。如果每次触发都继续往同一个上下文里堆信息，系统只是把人工操作换成了自动操作，并没有解决长期运行的问题。

V2：把会话和状态分开

V2 的改动看起来朴素，却是后续演进的基础：每次触发都创建新会话，状态持久化在 JSON 文件中；系统拆成 Monitor 和 Iterator 两个角色，再通过 phase 字段决定当前阶段由谁执行。

这里的关键不是 JSON，而是状态不再依赖某个 Agent 是否一直在线。

训练需要几个小时，Agent 没必要在会话里等着。它可以提交训练任务、记录必要状态，然后退出。下一次被触发时，再读取任务结果，继续往下走。

这与《Loop Engineering 实践指南》中的经验相互印证：长周期任务的状态应放在文件或数据库中，而不是只依靠上下文窗口。上下文可以帮助模型理解当前问题，但不适合作为唯一的事实源。（原文）

V3：从一条路径变成一张探索图

V3 的变化更大。主 Agent 不再亲自沿着一条路径反复试错，而是先提出几个互斥的假设，把它们交给不同的子 Agent 独立验证。训练完成后，主 Agent 再把结果收回来，比较之后决定下一轮方向。

原文把这个机制称为 Spawn-Converge：先 Spawn，分派探索分支；再 Converge，把分支结果收拢起来。

图 1：根据原文描述重绘的架构演进示意。图中强调的是问题和运行结构的变化，不是美团系统的完整实现图。

三、Spawn-Converge 的关键，不是“同时跑”

把三个实验同时跑起来，并不自动构成图探索。

假设一个模型的指标没有提升。最简单的并行方式，是让三个 Agent 各自尝试一些参数、特征或结构变化。这样做可能更快，但也可能只是把三个相似的尝试同时做了一遍。

Spawn-Converge 先要求系统把问题拆开：指标没有提升，可能是特征不足，也可能是模型结构不足，还可能是目标定义本身有问题。三个方向不是三个随机实验，而是三个需要区分的解释。

随后，子 Agent 在隔离上下文中执行。A 不应该因为 B 的中间判断而改变自己的假设，B 也不应该把 A 尚未验证的解释当成事实。每个分支留下代码 diff、原始指标和执行结果。

最后，主 Agent 重新接管任务。它要比较的不是“谁的总结写得更像”，而是不同假设在相同评价条件下得到了什么证据，哪些假设被支持，哪些被证伪，哪些结果互相冲突。

图 2：Spawn-Converge 的重点是“分叉之后还要收拢”。

所以，图探索和普通并行的差异，可以概括成一句话：普通并行增加实验数量，Spawn-Converge 试图增加每一轮获得的有效信息。

这也解释了上下文隔离的作用。《The Thin Orchestrator》案例指出，让不同 specialist 只接触自己的领域知识，有助于减少串扰；但隔离并不能替代数据质量、工具校验和最终验收。（原文；博客解读）

四、长周期运行靠的不是“更聪明”，而是 Harness

文章里有一句设计原则很值得单独拿出来看：

“凡是能用代码表达的约束，一律不放在 Prompt 里。”
——《从 LOOP 到图探索》，第 2 节与第 5 节，来源：美团技术团队

这句话并不是说 Prompt 没有用，而是说不同类型的约束应该放在不同层里。

例如，“不要再次尝试已经证伪的方向”如果只写在 Prompt 里，Agent 仍然可能判断“这次情况不同”。如果它进入状态文件和路由逻辑，系统就可以直接跳过这个方向。

文章把系统的不可靠行为分成两种：

认知层幻觉：模型给出一个听起来合理、但事实不成立的解释；
执行层偏差：接口超时、任务 ID 失效、日志字段缺失，导致工具返回结果不完整或不符合预期。

两种问题要分开处理。前者需要原始证据和交叉验证，后者需要幂等工具、结构化返回值和明确的重试策略。

文章描述的具体做法包括：

关键状态以状态文件为准；
易过期字段每轮重新读取；
平台调用封装为幂等工具；
返回值做结构化校验，字段缺失就判定失败；
区分代码故障和基础设施故障；
保留每轮的原始指标和代码 diff；
工具经验先形成 Skill 草稿，经过系统初筛和人工审核后再进入正式工具集。

这与《从零设计生产级 Multi-Agent Harness》的思路是一致的：Agent 负责局部判断，Harness 负责任务生命周期、状态、工具权限、预算、失败处理和终止条件。（原文）

分析： 在短任务里，模型能力可能是主要矛盾；在长周期任务里，问题往往变成“几十次局部动作能不能被组织成一条可靠的路径”。这时，Harness 不是外围包装，而是系统本身的一部分。

五、系统完成了实验，不代表它找到了正确答案

自动运行很容易被误认为自动进步。

美团文章对方案采用了三层验证：离线指标、线上实验和可解释性检验。离线指标决定方案是否值得继续，线上实验检验离线提升是否真的转化为业务收益，可解释性检验则决定经验能不能进入硬约束库。

原文特别强调，指标好并不自动意味着经验可靠。如果一个方案效果很好，但系统无法给出合理推导，就不应该直接把它写进长期规则库。

这和《验证与测量》对 Agent 评估的分层可以放在一起看：（博客文章）

层次	检查什么	放到 AutoResearch 中是什么
组件	工具、参数和输出是否合规	训练任务是否提交成功，返回值是否完整
轨迹	行动顺序是否合理	是否重复尝试、是否陷入循环、分支是否真的不同
任务	是否完成目标	离线指标是否达到要求
端到端	是否产生业务结果	线上实验、成本和最终收益

原文的三层验证和《验证与测量》的四层评估并不是同一套分类，前者更贴近算法方案的上线路径，后者更关注 Agent 系统本身的运行质量。两者放在一起，恰好说明了一个问题：不能只看最终指标，也不能只看 Agent 自己的解释。

六、自进化不是“每轮自动写一条经验”

文章中的自进化飞轮，也容易被理解得过于简单。

它不是每次实验结束后，都把一段总结塞进资料系统。系统先需要一份业务资料底座，里面有建模目标、样本口径、历史结论和约束边界。研究过程中，再按需要做初始化调研、渐进式调研；如果连续几轮都在同一个方向里打转，还要触发强制调研，尝试离开局部最优。

更重要的是，离线指标不是终点。方案上线后的真实反馈会回流资料底座，用来校准“离线好”和“线上好”之间的差异。

经验也不是自动晋升的。文章描述了一条比较谨慎的路径：经验先形成 Skill 草稿，经过系统初筛和人工审核，才进入正式工具集。这个机制的意义在于，临时观察和长期规则之间有一道门。

《Knowledge Self-Evolution Cycle》提供了一个相近的解释框架：资料管理会从临时检索，发展到持久编译，再进一步走向带关系和索引的工程化图谱。（原文）

如果沿着 Context Graph（上下文图）的思路继续往前推一步，系统长期需要保存的就不只是“哪个方案有效”，还包括：当时做了什么决策、为什么这么做、结果怎样、在什么条件下可以再次使用。（原文）

但这里需要划清边界：Context Graph 是对“经验如何形成组织记忆”的延伸分析，不是原文对该系统实现细节的直接描述。

七、AutoResearch 和 AutoML：差别在搜索空间之外

文章把 AutoResearch 与传统 AutoML 区分开来：传统 AutoML 通常在预先定义的搜索空间里寻找更好的组合，而文章描述的系统试图处理另一类问题——初始的问题框架可能就是错的。

可以把它理解成两种不同的工作：

AutoML：地图已经画好了，寻找更短的路线；
AutoResearch：先判断地图是否画对，必要时重新画一张地图。

这是文章作者对自身系统的定位，不是对所有 AutoML 方法的完整分类。它的解释价值在于：当 Agent 参与研究时，评价标准不应只有“搜索得快不快”，还要看它是否能识别错误前提，并提出原来搜索空间里没有的候选方向。

八、它适合什么，不适合什么

文章给出了三个适用条件：有明确的可量化指标，单次实验成本可接受，实验结果可逆。

这三个条件其实决定了系统能否安全地自动循环。

指标不清楚，系统就不知道什么叫变好；实验太贵，错误探索的代价可能超过自动化收益；结果不可逆，则不能把“试错”当成普通迭代。

因此，它不适合高度主观的评价任务，也不适合单次实验成本极高、失败后无法回退的场景。文章还明确提到，训练资源仍是外部瓶颈，跨业务经验迁移可能产生错误泛化，系统对“为什么有效”的归因也还不够稳定。

这些限制并不削弱架构的价值，反而帮助确定它的适用范围：它更适合反馈清楚、实验可控的研究问题，而不是所有需要“自主探索”的任务。

九、从这个案例可以看到什么

第一，长周期 Agent 的问题，不能只靠换模型解决。模型负责单步推理和执行，但状态、调度、验证、失败恢复和经验晋升，需要由系统结构来保证。

第二，多 Agent 的价值不在数量，而在分工。没有互斥假设、上下文隔离和结果收拢，多开几个 Agent 可能只是多花几份成本。

第三，资料系统的价值不只是保存结论。一个可复用的经验，至少还要带着证据、适用条件和决策过程。

第四，这套思路对写作系统有一定启发，但不能直接照搬。写作也可以有来源、观点、验证和反馈回流，但“文章是否更好”不像模型指标那样容易量化，人工审稿仍然需要保留在流程里。

结语

从 V1 的串行 LOOP，到 V2 的异步状态机，再到 V3 的 CyclicGraph Engine，系统解决的是三个层次的问题：如何运行，如何稳定运行，如何在多个方向上同时探索并做出下一轮决策。

它的自主性并不是来自完全放开限制，而是来自更明确的限制：状态文件、硬约束、原始证据、验证门槛、人工审核和可回滚机制。

原文最后的总结也把重点放在了这里：自主研究系统的重要底座不是速度，而是“可复现、可审计、可回滚”。

从这个角度看，AutoResearch 的变化并不是让 Agent 代替研究员，而是把研究员从重复等待和低价值操作中释放出来，把注意力留给假设、边界和最终判断。