Lilian Weng推荐的Harness项目:autoresearch到底好在哪里

2026-07-29

alt text 上个文章中[[deep-read-lilian-weng-harness-engineering]]提到的autosearch, 原文是这么说的:

定义一个让模型能够运行、测试和迭代的工作流是自动化的核心设计。Karpathy 的 autoresearch 是此类工作流构建方式的简洁范例。常见的工作流遵循以目标为导向的循环：规划、执行、观察/测试、改进，然后再次执行，直至达成目标。该过程可能会主动向用户发起请求，以明确任务要求或执行偏好。

核心是什么

这个仓库里面非常非常的简单,repo 被刻意保持得很小，真正重要的只有三个文件：

train.py agent 唯一会修改的文件。包含完整的 GPT 模型、optimizer（Muon + AdamW）和训练循环。所有内容都可以调整：模型架构、hyperparameter、optimizer、batch size 等。该文件由 agent 修改并持续迭代。
program.md 单个agent的基线指示。让你的 agent 读取这个文件，然后开始运行。该文件由人类修改并持续迭代。
prepare.py 固定常量、数据准备（下载训练数据、训练 BPE tokenizer）以及安装运行时工具（dataloader、evaluation）。不会被修改。

flowchart TD
    H["人类编写或调整 program.md"] --> A["外部 Agent 读取工作协议"]
    A --> S["创建实验分支并检查数据缓存"]
    S --> B["运行原始 train.py 建立 baseline"]
    B --> I["提出一个实验想法"]
    I --> M["只修改 train.py"]
    M --> C["先创建候选 Git commit"]
    C --> R["运行 train.py 内部 300 秒训练循环"]
    R --> E["prepare.py进行评估"]
    E --> O["Agent 从脚本输出读取 val_bpb(评估的得分)"]
    O --> L["记录到 results.tsv"]
    L --> D{"val_bpb 是否更低"}
    D -->|"是"| K["保留 commit，分支前进"]
    D -->|"否"| X["reset 回上一个有效 commit"]
    K --> I
    X --> I

通过外部Agent( 可能是你的CC Codex cursor 或者是任何Agent) 来进行外层循环 (program.md中的指示但愿你的Agent会听话) ,然后内层循环就是通过train.py脚本反复进行训练; 我第一次见到这么精简的仓库,拉到本地之后, 在MacBookPro上跑了一共8小时,指标从1.44(基线)最终下降到了1.36(毕竟只是一台笔记本,推理效率已经不错了) alt text 图中的白点都是被抛弃了的实验(得分基于之前的最高分),图中的绿点则为超过的当时的最高分的实验,完全都是Gpt-5.6-sol的想法; 这些有进展的实验分别是通过减小训练批次缩短训练上下文加宽模型增强 Attention来实现的. 我们无需关心他做的这些更改而是应该聚焦到这个仓库实现训练自进化的方式.

所以翻回去重新去看这三个文件 program.md：就相当于Harness 的控制协议,里面规定了Agent可操作的范围和空间:只能改train.py,先commit再实验,超过保留,未超过就reset;持续循环,直到用户手动打断; prepare.py相当于基础设施和评估脚本:这里的内容不重要 ,重要的是一定要有一个衡量指标任务一定要有个得分才行;并且这是整个 Harness 最关键的边界：Agent 可以改变训练方法，但不能改变“考试题”和“评分规则”。 train.py：实验对象里面的内容是训练模型但是我们其实不关心;它里面可以是任何我们需要进化的对象;

拓展到其他领域

所以引申出来我如果要通过这套harness方案去进化一个prompt: 那么我要有一个"program.md" 告诉外部Agent只能修改我的prompt,然后描述一整套循环流程;
要有一个"train.py" 承载我当前的prompt; 要有一个"prepare.py" 里面可以用各种手段对这个prompt进行测评以及打分 ; 这样我只需要让我的Agent去阅读program.md 然后就可以放手去等结果了; 这个项目几乎是用最低的复杂度演示了一个自进化harness要有的必要东西了,缺一不可.简单来说就是抽象为这套结构:

人写 program.md
↓
Agent 修改一个受限对象
↓
运行真实实验
↓
固定 evaluator 打分
↓
Git keep / revert
↓
记录经验并继续

效果必须可量化

跟codex中的goal 一样 , loop都要有明确的执行完成可衡量的标准, 那么自我进化也要有明确的有多好. 如果要迁移到其他领域最主要考虑的事情就是:有没有固定输入、可重复验证命令和一个可以比较的指标 任何可以被编辑、执行和评分的对象都可以进入 autoresearch loop 并且还要注意量化出来指标的全面性，否则会出现按下葫芦起来瓢的情况。或者说上线一些基础的质量门禁。

链路应该被追踪

这部分可能分成两项，一个是模型的思考过程要被持久化下来，目前项目中是没有的。并且关键测评中的指标变化应该也要被保存下来。这样不仅能看到这一版优化让它的指标提高了，还能看到具体是在哪些 case 上指标提高了，以及在这些 case 的 Agent 流程中，是哪一步让这个指标提高了。

优化

优化它的进展必须要观察每个实验的行为

不仅要观看而且要结合时序去看; 因为“没有提升”的实验依然给出了系统边界和下一步方向;

实验的价值不只是产生更好的代码，还包括排除错误解释、发现瓶颈所在。不是指标提升才有价值, 在Agent快速发展的时候排除效果天花板很低的变量和方向也是一种价值和进步.

鲁棒性

如果某一次电脑过热导致正确的方向但是没有跑出更好的指标那么依然会被放弃 (mbp跑训练时候就很热,训练期间一直放了一个usb风扇) 为了防止随机波动导致的噪音, 至少重试2-3次并且设置规避时间; 甚至在测试类似的自我进化的方案的时候,有没有特别好的抗干扰能力,也是能力的一环.

用更好的模型

无数的实验和分享都不约而同的提到了这一点 ,需要模型的创造力知识都在一个很高的水位,才能更高效的优化内部, 公司内部财保相关的harness分享中也提到: 用GLM-5.1 总会在一个问题上兜圈子, 很长时间都没有一个进展,而是不断重复;用了更大尺寸的模型效果一下就好了起来

用autosearch优化autosearch

优化autosearch 其实就是在优化内部的program.md 和搜索策略, 社区很多这么做的基本都是在两层循环中再加一层:

内层：优化任务结果
外层：分析内层的trace，优化搜索机制
最外层: 用户自己的codeX或者cc

真是邪修啊…似乎可以无限套娃但是问了一下5.6-sol 给我的答案是:

已有的 Bilevel Autoresearch 就实现了前两层：内层优化任务，外层读取代码和实验轨迹，生成新的搜索机制；论文报告其在特定 GPT benchmark 上优于单层循环。但这只能证明二层 meta-optimization 可行，不代表层数越多越好。(github.com) 但是每层依然都需要有一个评价的方案, 内层的任务可以通过val_bpb的高低来评判,外层就需要另一个评价机制, 层数越多能被归因的变量也更多,基本2层就算是拉满了

flowchart TD
    E["固定根评价器<br/>数据、预算、Guard、人工目标"]
    L1["Level 1<br/>优化 train.py"]
    L15["Level 1.5<br/>调整搜索参数<br/>冻结方向、切换策略、避免重复"]
    L2["Level 2<br/>优化搜索机制<br/>memory、bandit、tabu、并行探索"]

    L2 --> L15
    L15 --> L1
    L1 --> E
    E --> L1
    E --> L15
    E --> L2

failFast

真是没想到啊，在这里还能使用到fail。fast这个理论这里需要他有快速失败的能力，比如说已经明显出现了劣化，不需要等到所有指标全部跑完。就已经可以宣告本次修改是无效的了可以设置一个阶梯型的一个漏斗

思考

局部最优和全局最优

每次git只保存最高分的记录相当于是一个贪心算法.简单、快速、容易回滚。缺点是可能陷入局部最优：有些改动单独看会变差，但和另一个改动组合后才会明显变好；Greedy search 可能提前把第一个改动丢弃。单次评估存在噪声时，它也可能错误保留一个“看起来提升”的实验。但是该怎么让他不要局限于局部最优呢? 这个需要思考一下

<< Previous Post

~~Next Post >>~~