翁莉博客更新：Harness 工程与模型自我改进：从 Prompt 到系统的进化

原文：Harness Engineering for Self-Improvement

作者：Lilian Weng（Lil'Log，2026 年 7 月）

递归自我改进（Recursive Self-Improvement, RSI） 这个概念最早可以追溯到 I. J. Good（1965），他把「超智能机器」定义为一种在所有智力活动上都能超越人类、并且能够设计出比自己更好的机器的系统。Yudkowsky（2008） 则用 “recursive self-improvement” 来专门指代这样一个反馈回路：一个 AI 利用自己当下的智能，去改进那台生产它自身智能的认知机器。

在当代 AI 语境下，这个反馈回路既可以直接体现在模型改写自身权重上，也可以更广义地指：模型改进训练管线与部署系统，进而带来一个在经济价值任务上表现更好的下一代模型。前沿实验室的研究节奏已经明显加速（参见 Anthropic、OpenAI 的相关表述）。

之所以特意强调「部署系统」，是因为原始模型与真实世界之间的那一层，可能和模型自身的原始智能（即 pretraining 之后的 eval 表现）同等重要。像 Claude Code、Codex 这样成功的编码 Agent 产品已经证明，Harness 是 AI 部署中的关键组件。

所谓 Harness，可以理解为：

本文聚焦于 Harness 工程 相关的研究，以及它对 RSI 的贡献。近期关于 auto-research、自我改进 Agent、进化式程序搜索的许多工作，都可以放在这个框架下讨论。此外还有一类工作围绕模型自我博弈、合成数据、测试时训练以及更广义的 持续学习（例如 Yuan et al. 2024、Chen et al. 2024、Zhao et al. 2025、Choi et al. 2026），同样契合 RSI 愿景，但不在本文重点讨论范围内。

Harness 的设计模式

相比 早期的 Agent 框架——「agent = LLM + memory + tools + planning + action」——Harness 工程还额外包含工作流设计（如 loop engineering）、评估、权限控制以及持久化状态管理。它不再只是 prompt 模板，而更接近一个运行时和软件系统的设计：模型如何观察、行动、记忆、自我检查、自我改进。

设计上应尽量简单、通用，从而带来更好的泛化能力，并且尽量向已有软件工程实践看齐，以复用预训练知识。Harness 与操作系统之间也有很强的类比：一个好的 Harness 应该像 OS 一样，把复杂逻辑封装起来，同时保持接口简洁。与此同时，配置、工具接口、协议等也会在行业内逐步标准化。

模式 1：工作流自动化

为模型定义一个可运行、可测试、可迭代的工作流，是实现自动化的关键设计。Karpathy 的 autoresearch 仓库（github.com/karpathy/autoresearch）就是一个干净利落的示例。

一个常见的工作流是目标驱动的循环：规划 → 执行 → 观察/测试 → 改进 → 再执行，直到目标达成。在执行过程中，Agent 还可以主动向用户询问以澄清任务定义或执行偏好。

简化的 Codex Agent 循环：Agent 调用工具，工具返回结果又会影响模型的下一次生成。（图源：OpenAI codex agent post）

这类工作流的核心在于让模型能够分析自身的执行轨迹与失败案例，并在一个「agent runtime」中不断迭代，而不是依赖某个静态的 prompt 模板。

模式 2：文件系统作为持久化记忆

在长跨度 Agent 系统中，一个反复出现的模式是：用简单方式管理丰富的状态与中间产物。Harness 不应该把整个工作流和所有日志都塞在上下文里，而应该把持久化状态放在文件里。

在长跨度 Agentic rollout 中，实验日志、代码 diff、论文摘要、错误堆栈、历史轨迹等中间产物往往远远超过模型训练时的上下文窗口长度。

学习如何读、写、编辑文件系统（通常通过 bash 命令），是 LLM 的一项基础能力；以文件形式管理持久化记忆，也自然会随着模型基础能力的提升而受益。

模式 3：子 Agent 与后台任务

Harness 可以派生多个子 Agent 并行执行，并监控后台任务。这在以下场景很有用：

• 主 Agent 需要同时探索多个假设；
• 需要并行运行多个实验；
• 需要把一些独立子任务隔离出去，避免污染主上下文。

此时父 Agent 就需要一个小型的「进程管理器」：启动任务、检查日志、取消失败任务、把结果合并回主 Agent 线程。

关键设计是：让并行性显式化、可检视。如果子 Agent 的输出只存在于临时对话上下文里，它们很快就会变得过时、被隐藏；如果把它们作为文件、日志、状态记录持久化下来，模型就能在中断后恢复，并对自己的执行历史进行推理。

案例研究：编码 Agent 的 Harness

主流编码 Agent（Claude Code、Codex、OpenCode、Cursor 类）之间的核心接口已经趋同，大致都采用如下循环：

借助一整套工具，编码 Agent 可以在给定仓库中进行开发和调试，就像人类工程师使用 IDE 一样。下表是一份 示意性（非完整） 的工具集合（详细可参考 这里）：

Harness 层 vs. 核心智能：谁更重要？

很难预测未来的 RSI 究竟会有多依赖 Harness 工程，但短期内 RSI 不太可能是模型直接改写自身权重。作者对近期路径的预测是：

1. Harness 工程会朝「元方法论」方向演化：优化的不再是答案本身，而是产出更好答案的机器。Harness 系统自身成为优化目标，启发式规则减少，通用机制增多。
2. 成熟的 Harness 会反过来使能 auto-research 与自我改进循环；同时，更聪明的模型能防止 Harness 被过度工程化，让整个系统保持可持续。

最终，许多 Harness 层的改进可能会被内化到模型的核心行为里，但与外部上下文和工具打交道的接口应该会保留下来。类似的情况在 prompt engineering 中就发生过一次：随着指令微调和推理能力提升，手工 prompt 技巧的重要性下降了，但明确目标、约束、上下文和评估的必要性并没有消失。

Harness 的优化对象

Harness 系统中被优化的对象大致经历了这样一条演化路径：

指令 prompt → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码

随着模型越来越强，优化目标也从具体走向抽象，从针对性走向通用。

上下文工程（Context Engineering）

一旦 Agent 任务跨度显著变长，简单地把所有工具响应和模型输出堆进上下文，就会迅速失控。上下文管理层的作用，是为 LLM 构造更结构化、更精炼的上下文，并管理持久化状态。长上下文研究会继续推进，但当前阶段，长上下文能力与上下文工程往往交织在一起。

Agentic Context Engineering（ACE，Zhang et al. 2025） 把上下文视为一个不断演化的 playbook，而不是一段越写越长的 prompt。它围绕一个由要点（bullet point）构成的上下文剧本，包含三个组件：

1. Generator：基于要点生成任务轨迹；
2. Reflector：从成功与失败的轨迹中提炼洞见；
3. Curator：以增量、条目化的方式更新结构化上下文。

Agentic Context Engineering（ACE）的框架。（图源：Zhang et al. 2025）

为了避免迭代重写中出现「上下文坍塌」和「简洁性偏差」，ACE 的一个关键设计是：Curator 不重写整段 prompt，而是输出一组结构化的 (identifier, description) 条目，再通过确定性逻辑合并进上下文日志中。条目会周期性地被精炼与去重。

ACE 已经能从 rollout 中学习洞见，向「自管理记忆」迈出一步，但更新规则和整体工作流仍然是手工设计的。Meta Context Engineering（MCE，Ye et al. 2026） 更进一步：把「如何管理上下文的机制」与「上下文中放什么内容」分开，在元层做 skill 演化，在基础层做上下文优化。

一个 MCE skill 定义了一个上下文函数，把输入映射到上下文，其中包含：

• 静态成分：prompt、知识库、代码库；
• 动态算子：搜索、筛选、过滤、格式化。

双层优化：内层在训练数据上寻找给定 skill 下的最佳上下文；外层在验证集上寻找最佳 skill。

Meta Context Engineering（MCE）框架：元层演化上下文管理机制，基础层优化任务上下文。（图源：Ye et al. 2026）

MCE 不像 ACE 那样规定上下文的结构，而是用自由形式的 skill 来存储对任务最关键的知识，让 skill 与「以 skill 为条件的上下文」共同演化。实现上，一个上下文函数被实例化为一个专用目录下的一组文件，既包含静态成分（skill.md），也包含动态成分（上下文与数据 rollout）。元层与基础层的优化都在一个带有标准工具集的 Agentic 编码环境中运行。

Meta-Harness（Lee et al. 2026） 又向下深挖一层：被优化的对象是决定并优化「存储、检索、呈现给模型哪些信息」的代码。名字里的 “Meta-” 意味着它是「优化 Harness 的 Harness」。

Meta-Harness 的外层优化算法。（图源：Lee et al. 2026）

提出新 Harness 的 Proposer 本身也是一个编码 Agent，最终输出是位于 Pareto 前沿的一批 Harness 候选。

• 完整执行历史通过文件系统访问，编码 Agent 用 grep、cat 这类命令去读，而不是把所有信息塞进一个 prompt 上下文；
• 每个被提议的 Harness 是文件系统中的一个字典，包含其源代码、评分、rollout 轨迹和状态更新；
• 元 Harness 循环不断产生新 Harness，只有合格的被保留。

Meta-Harness 表现：（左）文本分类任务在少量迭代下的表现；（右）TerminalBench-2 上的表现。注意右图中的搜索是从 Terminus-KIRA 和 Terminus-2 这两个非常强的 Harness 初始化的。（图源：Lee et al. 2026）

真正的启示是：一旦 Harness 设计变成一个可执行的搜索空间，一个足够强的编码 Agent 就能挖掘出人类工程师所使用的那片设计空间。

工作流设计（Workflow Design）

Harness 工程中的工作流可以由领域专家手工设计。以 auto-research 为例，已经有一些成熟框架被提出和验证：

• AI Scientist（Lu et al. 2026） 建立了一条从提出研究想法、编写代码、运行实验、分析结果、撰写论文到执行同行评审的完整流水线。
• ScientistOne（Meng et al. 2026） 把「可验证性」作为核心设计约束：每一条论断（引用、数值、方法、结论）都必须能溯源到某个证据来源，并通过 Chain-of-Evidence 检查审计。

AI Scientist 从想法生成、实验、论文写作到评审的流水线。（图源：Lu et al. 2026）

Autodata（Kulikov et al. 2026） 则被设计成「数据科学家 Agent」，用来生成训练数据与评测数据。主 Agent 管理一个 Challenger（提出问题）、一个 Weak Solver、一个 Strong Solver 以及一个 Verifier / Judge，目标是合成「难度刚刚好」的数据——即强解器成功、弱解器失败的问题。

在 Autodata 中，Challenger 的 prompt 会根据 Solver 与 Verifier 的反馈迭代更新。局限在于：合成任务被用来微调弱解器，而不是强解器；如果这个循环不能迭代地改进强模型，那它更像是通过生成 prompt 分布做间接蒸馏，RSI 味道相对较淡。

Autodata 的 Agentic 工作流：围绕 Challenger、Solver、Verifier 三种角色生成合成训练与评测数据。（图源：Kulikov et al. 2026）

工作流的设计空间非常大，自然可以把「工作流设计」本身视为一个搜索问题——由算法来搜好方案，而不是人工去堆。沿着这个方向：

ADAS（Automated Design of Agentic Systems，Hu et al. 2025） 把 Agent 设计本身建模成一个优化问题，即「元 Agent 搜索」，由一个元 Agent 提出新的 Agentic 工作流。

1. 用简单 Agent（如 CoT、self-refine）初始化一个 Agentic 工作流档案；
2. 让元 Agent 参考档案中已有方案，用代码编写新 Agent：
   • 先生成新工作流的高层描述，再用代码实现；
   • 草稿代码经过两轮 self-refine（模型自评+修改，见 Madaan et al. 2023），以检查新颖性；
3. 评估每个新候选，把成功的加回档案；
4. 重复 2-3，直到达到最大迭代次数。

Automated Design of Agentic Systems（ADAS）示意。（图源：Hu et al. 2025）

AFlow（Zhang et al. 2025） 则把 Agentic 工作流表示为一张图：节点是 LLM 调用动作，边是用代码实现的逻辑运算。工作流优化基于 MCTS：

1. 用模板初始化起始工作流；
2. 混合评分与均匀探索，选择一个工作流节点；
3. 让 LLM 基于该节点的评估表现生成一个改进版本；
4. 执行并评估新工作流；
5. 如果在预算轮次内表现更好，则加回搜索树；
6. 重复 2-5，直到 top-k 平均分停滞或达到预算上限。

AFlow 在候选工作流树上的优化过程。（图源：Zhang et al. 2025）

在 QA、代码、数学任务上，AFlow 相比手工工作流和 ADAS 都有明显提升。

AFlow 与手工方法、ADAS 的对比实验。（图源：Zhang et al. 2025）

自我改进的 Harness

无论上下文工程还是工作流设计，都只是 Harness 的一部分。我们真正想搜索的是整个设计空间——上下文管理逻辑、工作流、权限、以及其他 Harness 组件的联合优化。正如 Meta-Harness、ADAS、AFlow 所示，✨代码✨ 是定义程序与系统的通用语言。简单说，Harness 就是把 prompt、工具调用、子 Agent、控制流、记忆、工作流逻辑串起来的代码。如果 LLM 能够优化执行 Agent 的代码，它就能触达一片远比手写 prompt 更广阔的设计空间。

STOP（Self-Taught Optimizer，Zelikman et al. 2023） 是递归 scaffolding 改进的早期典型。给定一个初始解、一个效用函数与一个黑盒语言模型，一个种子 improver 输入解并返回一个改进后的解。STOP 的目标不是直接改进解，而是改进 improver 本身。

我们可以先定义一个 improver 在下游任务集合上的平均效用（meta-utility），然后基于这个 meta-utility 递归地更新 improver。

STOP 算法示意。（图源：Zelikman et al. 2023）

在实验中，改进后的 improver 自发发现了各种策略：遗传算法、分而治之地改进各部分、多臂 prompt bandit、模拟退火、温度扰动、beam / tree search 等——这正好类比于「Harness 工作流可以作为优化对象」的想法。

STOP 发现的一些自我改进策略。（图源：Zelikman et al. 2023）

作者也观察到一个警示性的现象：STOP 在 GPT-4 上改善了下游平均表现，但在 GPT-3.5、Mixtral 这类较弱模型上反而变差。仅有递归结构是不够的——基座模型必须足够强，才能改进机制本身。这意味着：Harness 改进能让模型部署得更好，但智能本身仍是核心。

更近一些的 Self-Harness（Zhang et al. 2026），让 LLM Agent 通过「提议-评估-接受」循环来改进自身 Harness。

Self-Harness 通过弱点挖掘、受限 Harness 提议、验证三步来更新 Harness。（图源：Zhang et al. 2026）

Self-Harness 的循环包含三个阶段：

1. 弱点挖掘：把失败聚类为 verifier 支撑的失败模式。
   • 用当前 Harness 在任务上评估，收集执行轨迹；
   • 两次运行可能在错误日志表面上呈现相同的 verifier 级现象（如超时、缺失产物），但因果机制完全不同。因此需要一份富信息的失败记录：终端级 verifier 原因、相关 Agent 行为的因果状态、以及轨迹所暴露出的抽象 Agent 机制。
2. Harness 提议：基于挖掘出的失败模式提出受限的 Harness 修改。
   • 同一个模型被用作 proposer；
   • 输入受限：（1）当前 Harness 中可编辑的表面；（2）来自评估系统的 verifier 支撑的失败模式；（3）需要被保留的通过行为记录；（4）先前尝试的编辑摘要；
   • 优先修复可复现且可解决的错误模式（而非任务本身固有难度），且尽量用窄改动解决；
   • 候选编辑要多样且相互区别。
3. 提议验证：在 held-in（验证弱点已被解决）与 held-out（验证没有引入新问题）数据上做回归测试；只有两者都无回归的编辑才被接受，并合并生成新的 Harness。

在 MiniMax M2.5、Qwen3.5-35B-A3B、GLM-5 上对 Terminal-Bench-2 的实验显示：Self-Harness 学到的是「模型专属」的 Harness 指令，针对不同基座模型的不同弱点，并提升了 held-out 通过率。

译者注：Self-Harness 这类工作也带来一个担忧——如果一个程序被允许编辑「操作系统」，抽象边界就会被打破。可编辑面必须被精心设计，权限与安全层必须在这个循环之外。所有关于 reward hacking 的挑战依然存在。

进化式搜索（Evolutionary Search）

进化式搜索 是一种受自然选择启发的优化方法（可参考作者旧文 evolutionary algorithm）：维护一个候选解种群，通过变异生成新个体，只保留高 “fitness” 的个体。它特别适合以下场景：

1. 搜索空间庞大或形状奇特；
2. 梯度优化困难，但候选评估相对容易。

Harness 搜索恰好符合这些特征。

过去在 prompt 工程中已有类似应用：Promptbreeder（Fernando et al. 2023） 通过丰富的变异操作优化任务 prompt，甚至连变异 prompt 本身（指导 LLM 如何变异任务 prompt 的指令）也在演化。GEPA（Agrawal et al. 2025） 将 反思式 prompting 与进化式搜索结合，用对试错轨迹的自然语言反思来提出 prompt 更新。

AlphaEvolve（Novikov et al. 2025） 将其推向编码 Agent：维护一个候选程序池，用冻结的 LLM 生成改进 diff，反复评估子代程序并保留成功者。

AlphaEvolve 工作原理。（图源：Novikov et al. 2025）

其中一些设计细节很关键：

• Prompt 中包含父程序、结果、指令，有时还有元信息；
• 编码 Agent 可以访问整个仓库，但用 # EVOLVE-BLOCK-START / # EVOLVE-BLOCK-END 显式标记待改进代码区域；
• 元 Prompt 与指令、上下文共同演化，方式类似解程序的演化。

消融实验显示了进化过程、prompt 上下文、元 prompt、整文件演化以及更强 LLM 的价值。

AlphaEvolve 各设计的消融实验。（图源：Novikov et al. 2025）

近期的变体：

• ThetaEvolve（Wang et al. 2025） 将进化式搜索与 RL、上下文学习结合。
• ShinkaEvolve（Lange et al. 2025） 引入了三项提升 LLM 采样效率的组件：
  • 更样本高效的探索：父代采样在「表现排名」与「子代数量」之间取得平衡；
  • 基于 embedding 余弦相似度的代码新颖性拒绝采样；
  • 用元便签簿（meta-scratchpad）识别成功方案中的好模式，指导后续变异。

与上述方法聚焦「优化解」不同，Darwin Gödel Machine（DGM，Zhang et al. 2025） 显式地把可编辑的 Harness 代码库作为进化目标，让一个 LLM 编码 Agent 允许修改自己的 Harness。后续工作 Hyperagents（Zhang et al. 2026） 又引入了一个 meta-agent，控制「如何修改已有任务 Agent 来产生新 Agent」。

1. 从池中一个编码 Agent 开始；
2. 每轮按「表现越好、子代越少」的概率挑一个父代，进行变异和分支；
3. 被选中的父 Agent 检视自身评测日志，然后针对自身 Harness 代码库提出改进，生成新版本；代码编辑仅用两个工具：bash 与 editor(view/create/edit)；
4. 评估新 Agent，只有表现足够好的加回池中；
5. 重复 2-4，直到停止条件。

DGM 是在固定模型下的 Harness 演化。在以 Claude 3.5 Sonnet 为基座、初始 Harness 非常简单的实验中，DGM 演化出的 Agent 在 SWE-bench Verified 上从 20% 提升到 50%，在 Polyglot 上从 14.2% 提升到 30.7%，达到甚至超过手工 Agent 的水平。

这类方法在候选可自动评估、fitness 易量化的领域最有效：矩阵乘法、GPU kernel 优化、算法竞赛、数据中心调度等。而在评估慢、模糊、以启发式为主的领域则相对乏力。此外，演化过程的计算效率与效果也是一个持续的关注点。

与模型权重的联合优化

Harness 演化改变的是模型周围的非参数系统。而要走向完整的自我改进，模型也可以在同一循环中更新自身权重——通过训练管线改进，或者测试时的持续学习。持续学习值得未来单独展开一篇文章。

SIA（Hebbar et al. 2026） 是把 Harness 改进与模型参数更新纳入同一优化循环的早期尝试，包含三个组件：

• Meta-Agent：提出初始 Harness；
• Task-Specific Agent：执行任务；
• Feedback-Agent：基于近期轨迹决定下一步是更新 Harness 还是更新模型权重。

SIA 的 Feedback-Agent 决定下一轮迭代类型。（图源：Hebbar et al. 2026）

实验中存在一些混淆因素，使结果不易解读——比如任务 Agent（gpt-oss-120b）比 Meta-Agent 和 Feedback-Agent（Claude Sonnet 4.6）明显更弱；基线也偏弱，难以与相关方法交叉对照。方向本身很有意思，但证据仍是初步的。训练稳定性、Goodhart 效应等挑战仍然开放。

未来挑战

AI Scientist 系列工作是一个很强的证明：专家设计的 Harness 已经能承担大部分 auto-research 循环（以论文写作为形式呈现）。但写论文 ≠ 科学发现。系统完全可能写出一份看上去合理的稿子，同时伴随伪造引用、实现漂移、实验证据薄弱等问题。

Trehan & Chopra（2026） 在最小 scaffolding、基础工具（read_file、write_file、llm_search、list_files）下测试了 LLM 从想法到论文的能力。每个想法都拥有一个专用工作区，Agent 可以在其中生成并阅读文档。他们在三个领域（world models、多智能体 RL、AI 安全与对齐）上做实验，每个领域包含 45-50 篇高质量种子文献作为想法灵感来源。只有 4 个想法被人类专家选出走完整流水线，其中仅 1 个最终完整地产出了一篇论文。作者观察到六种反复出现的失败模式：

1. 偏向训练数据默认值：使用过时的库、命令、格式；假设不基于实际仓库或数据集；
2. 执行压力下的实现漂移：技术复杂时，模型倾向于走向更常见但更简单的方案，而非提议的方法；
3. 记忆与上下文退化：长跨度项目会丢关键细节，除非日志被写入持久化产物；
4. 过度乐观：即便实验噪声大或失败，模型仍宣称成功。Bubeck et al.（2025） 观察到类似的「p-hacking + eureka-ing」模式：模型在信号仍是噪声时用「数值胶带」宣布胜利；
5. 领域直觉不足：缺乏 tacit craft knowledge——预测实现复杂度、判断结果是否合理、知道哪些基线才重要；
6. 弱科学品味：实验可执行，但没有回答正确的问题。

通向完整 RSI 的路上，虽然已有实实在在的进展，但几个瓶颈依然存在：

1. 评估器薄弱且模糊。许多研究论断没有快速精确的 verifier，现实世界的很多任务也是如此。当前的自我改进循环在可度量、目标客观的任务上效果最好，类似 RL 的适用范围。研究品味、新颖性、长期科学价值都难以直接度量。
2. 上下文与记忆的生命周期。随着 Agent 越来越自主，记忆规模不断增长。好的 Harness 既要弥补长上下文生成的局限，又要最大化长跨度任务的成功率。既然人类能维持一生的记忆，我看到一个类比：context engineering 将会、也应当成为智能的核心部分，而不仅仅停留在软件系统层。
3. 负结果。研究者倾向于发表成功结果，文献偏向于成功。基于以人类为主创作的海量数据训练的 LLM，可能不擅长决定何时放弃假设、何时报告负结果，甚至承认失败——因为数据中成功/失败比例失衡。研究型 Harness 应该让保存失败尝试变得容易，因为从失败中学习是缩小任务搜索空间的最佳方式。
4. 多样性坍塌。进化和 RL 循环倾向于开发已知的高奖励模式。我们需要一些 机制 来防止种群坍塌到同一个方案的变体上。这对开放式研究尤其关键——最好的路径在当前评估器下最初可能看起来更差。
5. Reward Hacking。自我改进循环会去优化任何被给出的信号：如果奖励来自单元测试，就会过拟合测试；如果来自 Judge 模型，就会学到针对该 Judge 的 hacking 技巧；如果来自 benchmark 分数，就会利用 benchmark 的伪迹。评估器与权限控制应位于演化 Harness 的循环之外，包括 held-out 测试、轨迹审计、以及在关键决策点上的人工审查——但可扩展、可自动化的监督到何种程度，仍是开放研究问题。
6. 长期成功。外部奖励循环处理的是训练沙箱中可模拟的、单次 rollout 之外的奖励。以编码 Agent 为例：它们已经显著提升了软件工程的日常生产力，但许多优化目标仍然过于短期。它能完成当下的任务，却不太明确自己该如何保护一个由成百上千工程师共同维护的仓库的长期健康。基于沙箱的 RLVR 式训练很少能捕捉可维护性、模块归属、迁移成本、向后兼容以及未来的调试负担。
7. 人类的角色。人类应当上移一层，而不是被移出循环：在正确的时机、正确的抽象层面提供监督；系统设计需要考虑何时、以何种方式建立这些交互触点。上述许多挑战都需要人类的反馈与引导。归根到底，我们是在为人类的更好未来构建这项技术，而不是相反。

引用

请按如下方式引用本文：

Weng, Lilian. "Harness Engineering for Self-Improvement". Lil'Log (Jul 2026). https://lilianweng.github.io/posts/2026-07-04-harness/

BibTeX：

@article{weng2026harness,
  title = {Harness Engineering for Self-Improvement},
  author = {Weng, Lilian},
  journal = {lilianweng.github.io},
  year = {2026},
  month = {July},
  url = "https://lilianweng.github.io/posts/2026-07-04-harness/"
}

附录：一些有用的基准

<details><summary><strong>PaperBench</strong> — 从零复现 ICML 2024 Spotlight / Oral 论文</summary>

• 每个复现任务被拆分成可单独打分的子任务；
• 共 8,316 条评分标准，与论文作者共同开发；
• 当时最佳模型 Claude 3.5 Sonnet 得分 ~21%，未能超过 ML PhD；
• 包含 PaperBench、PaperBench Code-Dev（轻量版）与 JudgeEval。
• 论文：arXiv:2504.01848

</details>

<details><summary><strong>CORE-Bench</strong> — 评估已发表研究的计算可复现性</summary>

• 90 篇跨 CS、社会科学与医学的论文，共 270 个任务；
• 任务：基于给定代码与数据复现结果；
• 含多个难度层级，同时覆盖纯语言与视觉-语言任务；
• 当时最佳（GPT-4o / GPT-4o-mini）在最难任务上仅 21% 准确率。
• 论文：arXiv:2409.11363

</details>

<details><summary><strong>ScienceAgentBench</strong> — 数据驱动的科学发现</summary>

• 从 44 篇同行评审论文（数学、化学、生物、地理）抽取 102 个任务；
• 覆盖数据处理、模型开发、数据分析、信息可视化。
• 论文：arXiv:2410.05080

</details>

<details><summary><strong>RE-Bench</strong> — 前沿 AI Agent vs. 人类专家的 ML 研究工程能力</summary>

• 7 个具挑战性、开放式 ML 研究工程环境；
• 每个环境 = (打分函数, 起始方案, 参考方案)，可用 ≤ 8 张 H100 GPU 运行；
• 例如：优化 kernel、跑 scaling law 实验、修 embedding、微调 GPT-2 做 QA；
• 71 次 8 小时的人类专家尝试数据，82% 得非零分，24% 达到或超过参考方案；
• 最佳 AI Agent 在 2 小时预算下比人类高 4 倍，但在 8/32 小时预算下人类反超。
• 论文：arXiv:2411.15114

</details>

<details><summary><strong>MLE-bench</strong> — 离线 Kaggle 上的 ML 工程 Agent</summary>

• 75 个 Kaggle ML 工程竞赛；
• 测试训练、准备数据、跑实验、提交预测；
• 以 Kaggle 公开榜作为人类基线；
• 论文中最好设置（o1-preview + AIDE scaffolding）在 16.9% 的竞赛中至少达到铜牌水平；
• 包含资源伸缩与数据污染分析。
• 论文：arXiv:2410.07095

</details>

<details><summary><strong>KernelBench</strong> — LLM 生成 GPU kernel 的正确性与速度</summary>

• 250 个 PyTorch 任务，评估 LLM 能否写出又快又正确的 kernel；
• 评估指标 fast_p：生成 kernel 中「正确且快于基线」的比例。
• 论文：arXiv:2502.10517

</details>

参考文献

1. Good, I. J. "Speculations Concerning the First Ultraintelligent Machine." Advances in Computers, 6:31–88, 1965.
2. Yudkowsky, Eliezer. "Recursive Self-Improvement." LessWrong, 2008.
3. Choi, et al. "Anchored Self-Play for Code Repair." ICML 2026.
4. Zhao, et al. "Absolute Zero: Reinforced Self-play Reasoning with Zero Data." 2025.
5. Yuan, et al. "Self-Rewarding Language Models." 2024.
6. Chen, et al. "Self-Play Fine-Tuning Converts Weak Language Models to Strong Language Models." ICML 2024.
7. Zhang, et al. "Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models." ICLR 2026.
8. Ye, et al. "Meta Context Engineering via Agentic Skill Evolution." 2026.
9. Lee, et al. "Meta-Harness: End-to-End Optimization of Model Harnesses." 2026.
10. Lu, et al. "Towards end-to-end automation of AI research." Nature, 2026.
11. Meng, et al. "ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence." 2026.
12. Kulikov, et al. "Autodata: An agentic data scientist to create high quality synthetic data." 2026.
13. Hu, Lu, and Clune. "Automated Design of Agentic Systems." ICLR 2025.
14. Madaan, et al. "Self-Refine: Iterative Refinement with Self-Feedback." NeurIPS 2023.
15. Zhang, et al. "AFlow: Automating Agentic Workflow Generation." ICLR 2025.
16. Zelikman, et al. "Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation." COLM 2024.
17. Zhang, et al. "Self-Harness: Harnesses That Improve Themselves." 2026.
18. Fernando, et al. "Promptbreeder: Self-Referential Self-Improvement Via Prompt Evolution." 2023.
19. Agrawal, A. et al. "GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning." 2025.
20. Novikov, et al. "AlphaEvolve: A coding agent for scientific and algorithmic discovery." 2025.
21. Lange, Imajuku, and Cetin. "ShinkaEvolve: Towards Open-Ended And Sample-Efficient Program Evolution." 2025.
22. Wang, et al. "ThetaEvolve: Test-time Learning on Open Problems." 2025.
23. Zhang, et al. "Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents." 2025.
24. Zhang, et al. "Hyperagents." 2026.
25. Yuksekgonul, et al. "Learning to Discover at Test Time." 2026.
26. Riaz, et al. "Epistemic Uncertainty for Test-Time Discovery." 2026.
27. Hebbar, et al. "SIA: Self Improving AI with Harness & Weight Updates." 2026.
28. Trehan and Chopra. "Why LLMs Aren't Scientists Yet: Lessons from Four Autonomous Research Attempts." 2026.
29. Bubeck, et al. "Early science acceleration experiments with GPT-5." 2025.
30. Starace, et al. "PaperBench: Evaluating AI's Ability to Replicate AI Research." ICML 2025.
31. Wijk, et al. "RE-Bench." ICML 2025.
32. Chan, et al. "MLE-bench." 2024.
33. Chen, et al. "ScienceAgentBench." ICLR 2025.
34. Siegel, et al. "CORE-Bench." TMLR 2024.
35. Ouyang, et al. "KernelBench." 2025.