单任务耗时少约 85% 与 83%：美团用图探索评 AutoResearch 会不会改对

单任务耗时少约 85% 与 83%：美团用图探索评 AutoResearch 会不会改对

美团平台技术团队 2026 年 10 月 22 日的原文《从 LOOP 到图探索 —— 算法模型的 AutoResearch 自进化系统架构演进之路》。AutoResearch 在这里指让 Agent 自己改训练代码、提交实验、看指标再决定下一步。这篇要看的不是又一个夜间自动跑实验的故事，而是他们用什么卡住裁判、怎么计一次迭代，以及两个业务上的耗时和 12 个目标到底对的是哪条基线。

三次重构：先把单线程跑上云，再拆成互斥假设

起点是 Andrej Karpathy 在 2025 年开源的 AutoResearch：单张 H100 上训练约 5000 万参数的教学级 GPT。仓库三个文件。program.md 用自然语言写研究规则。train.py 是 Agent 唯一可以改的训练代码。prepare.py 负责评估，并且被冻成不可改文件，用来挡住「改裁判」。keep 留下变好的提交，reset 丢掉变差的，形成可回滚的 Git 棘轮。原文写，约两天跑了约 700 次实验，对 val_bpb 有约 20 个正向提交。

搬进企业云端后，作者认为三件事对不上。规则如果只写在提示词里，幻觉会让执行不可信。本地单机和云端训练平台不一样，训练要异步，指标还要带业务口径。keep/reset 同一时刻只有一条时间线。

三个月三次重构，不是事先画好的路线。V1 用定时任务加 Shell 周期触发，一个 Agent 串行做检查、提取、分析和改代码，报告进云端文档。能跑，但上下文膨胀，状态也不同步。V2 每次触发开新会话，状态落在 JSON 文件，拆成 Monitor 和 Iterator，靠 phase 字段保证同一时刻只有一个角色在干活。Agent 不等待数小时的训练，下次定时唤起再从状态文件恢复。V3 叫 CyclicGraph Engine。决策层把一个大问题拆成 3 到 4 个互斥假设，例如「特征不足」和「结构不足」，子 Agent 上下文隔离、并行改代码并提交训练，主 Agent 再汇总。原文强调，只并行、不收拢，就退回多开几个实验。

同一建模项目上的速度对照写在第 3.4 节。LOOP 下 10 次迭代用了 3 天，大约 0.14 次/小时，没有突破。换成图架构后，12 次迭代用了 4.7 小时，大约 2.55 次/小时，并达成目标。迭代速度相差 18 倍。原文说快的不是单次训练，而是正交并行把每轮信息量提高约 3 倍、汇总再分发、边界探针，以及单变量控制。

可信度靠代码约束，不靠提示词里的「不要」

设计理念写了五条：把夜间和周末算力当闲置产能；和底层 Agent 基座解耦，靠 Harness 跟着基座升级；经验经人工校验后沉淀；用上线后的真实反馈回流知识库；能写成代码的约束不放进提示词。Harness 在文中指套在通用 Agent 外面的状态文件、工具返回校验、失败恢复、经验库、硬约束和提示词。

知识库在项目开始时要建模目标、样本口径、历史结论和约束边界，再自动调研出方向池。调研分三层：启动时建池并筛来源；过程中按需补，不一次塞满上下文；指标边际变慢、连续多轮在同一方案里打转时强制换维度。离线升降可以机器判读。线上实验结论用来校准「离线好」和「线上好」不是一回事。

无人值守时的错误分成两类。认知层幻觉不会报错，例如把波动归到不存在的因素。执行层偏差是超时、任务 ID 过期、日志字段缺失。已证伪方向写进状态文件的硬约束列表，下一轮在代码里跳过，而不是只在提示词里写「不要重复」。任务 ID 这类易过期字段每轮重读。平台调用做成幂等工具，返回值做结构化校验，缺字段就算失败。代码故障计入证伪并改方案；基础设施故障自动重试，不占轮次预算。

每一轮留原始指标和原始代码 diff。分析可以有幻觉，指标和 diff 当作不可绕过的锚点。子 Agent 互相隔离，或换模型走两条路径。交叉验证不每轮都做，只在主 Agent 置信度偏低、连续多轮指标同向变差，或归因涉及方向选择时触发。分歧保留，转人工，不按多数投票。

Skill 草稿要过系统初筛和人工审核才进工具集。原文举的例子是：早期训练平台参数服务器连接异常的处理，被整理成草稿，审核后写进工具集，之后同类基础设施故障自主处理了数百次。未经外部验证的结论只留在临时区，不进知识库。归因被写成慢变量：知识库、调研和实验数据三边积累，没有单点技术把「为什么有效」一次做完。

文中引用 LangChain 的一组对照，当作 Harness 能改结果的外部例子，不是美团自己的实验：同一模型，只调 System Prompt、Tools、Middleware，在 Terminal Bench 2.0 的 89 个任务上从 52.8% 到 66.5%，差 14 个百分点。

和传统 AutoML 的对照在图里，不在正文表格。三列是对比维度、传统 AutoML、本文 AutoResearch。搜索空间：传统由人预先定义并固定；这边可以证伪并退出错误框架，再从论文的数学结构扩展。多目标：传统加权成一个标量，权重人工指定且固定；这边每轮重新看多个指标的关系。异常：传统靠人处理，同类问题会重复；这边把故障经验沉淀成 Skill。正文把差异说成能力层级，不是搜索效率：正确答案可以不在初始空间里。

使用者侧给了一条最短路径。系统先要基础业务知识库、要优化的指标、报告目录、迭代上限和阈值，并给一份模板。填完把链接发回去就开始。中途可以问进度或打断。不打断的话，到达目标或上限就停。原文写的典型体验是周五启动，周一回来已有十余轮，期间没有人盯每一轮。这被用来改分工：人留在少数高杠杆节点，而不是每一轮都监督。

两个业务的耗时不能和 18 倍相加

第 8 节是效果。两个模型结构、优化目标和场景都不相同的建模项目，单任务完成耗时相对人工基线分别减少约 85% 与 83%。原文说两个项目唯一的共同点是同一套架构，所以把增益归于架构。其中一个项目里，系统推出的方案不在参考论文中，通过验证后推全上线，并取得线上收益。另一个多目标项目，全部 12 个预估目标同时超过人工基线。

上线和入库是两道门。离线达标之后，用线上 A/B 的置信区间决定是否推全。能不能进硬约束库，还要看 Agent 能不能给出合理推导。指标好但说不清，不入库。说不清是否可入库，转人工。

适用条件写了三条，要同时满足：指标可量化；单次实验成本可接受；结果可逆。评价很主观、搜索空间完全开放，或单次实验极贵且不可逆，不适用。训练资源仍是外部瓶颈，系统只能少消耗，不能变出卡。跨项目复用经验库可能把局部经验说成普遍规律，目前靠人工审核拦住。归因不够严谨时，不能进硬约束库。

统计口径在参考文献第 4 条，不在效果段落里。一次迭代按一个训练任务计，并行方向分开计，指标崩溃被证伪的探索也计入。人工基线按实际投入的工作日折算。系统侧只统计正常执行批次，基础设施故障的批次不进分母。18 倍是图架构相对这套系统自己的 LOOP。85% 与 83% 是相对人工基线的单任务耗时。两个分母不同。

这些数不能被读成什么

85% 和 83% 都带「约」，原文没有给出各自的绝对工时、迭代次数和人工基线的人数。线上收益没有 GMV、点击或绝对提升，不能写成上线涨了某个百分点。12 个预估目标超过人工，没有列出 12 个指标的名称和差值，也不能把「同时超过」读成每个目标的幅度一样。

18 倍不能和 85%、83% 相加，也不能套到所有项目。0.14 次/小时和 2.55 次/小时来自同一个建模项目的前后两种架构，样本是 10 次对 12 次，不是多项目平均。正交并行「约 3 倍」同样是这一处的说法。

Karpathy 的约 700 次实验和约 20 个正向提交，是教学原型上的 val_bpb，不是美团业务指标。LangChain 的 52.8% 到 66.5% 是别人的 Terminal Bench 2.0，不是这套 CyclicGraph Engine 的分数。AutoML 对照图没有搜索耗时或命中率，不能补成一张性能表。

「数百次」同类基础设施故障没有分母，不能换成可用率。周五到周一的「十余轮」是体验描述，没有说是哪一个项目、核心指标改善了多少。置信区间的具体阈值、迭代上限的默认数字，正文都没有给。下一步仍是稳定性、跨业务经验的幻觉，以及交互，这些还没有新的对照实验。

出处：美团平台技术团队，从 LOOP 到图探索 —— 算法模型的 AutoResearch 自进化系统架构演进之路，2026-10-22，https://tech.meituan.com/2026/10/22/LOOP-AutoResearch.html