为自我改进而进行的 Harness 工程

2026-07-10

AIAgentSelf-ImprovementHarness EngineeringLLM

译注：本文翻译自 Lilian Weng 的博客 Harness Engineering for Self-Improvement，发布于 2026年7月4日。译文仅供学习交流，版权归原作者所有。

**递归自我改进（Recursive Self-Improvement, RSI）**的概念可以追溯到 I. J. Good (1965)，他将"超智能机器"定义为在所有智力活动中超越人类并能设计更好的机器来改进自身的系统。Yudkowsky (2008) 用"递归自我改进"一词来描述一个特定的反馈循环：AI 利用其当前的智能来改进产生其智能的认知机制。

在现代 AI 中，这个反馈循环可能意味着模型直接改写自身的权重，或者更广义地说，模型改进训练流水线和部署系统，从而催生出在经济价值任务上具有更好性能的下一代模型。前沿实验室的 AI 研发速度已被证明显著加速（Anthropic；OpenAI）。

我特意提到*"部署系统"*，因为在原始模型和现实世界上下文之间的这一层似乎与模型本身的原始智能（即预训练后的评测结果）同样重要。Harness 是 AI 部署的重要组成部分，正如 Claude Code 和 Codex 等成功的编程智能体产品所展示的那样。一个 harness 是围绕基础模型的系统，它编排执行过程，决定模型如何思考和规划、调用工具并行动、感知和管理上下文、存储产物，以及评估结果。

本文将聚焦于 harness 工程相关的研究以及它如何促进 RSI。近期关于自动研究、自我改进智能体和进化程序搜索的大量工作都可以围绕这一问题来组织。其他关于模型自我博弈、合成数据、测试时训练以及持续学习更广泛主题的工作也符合 RSI 的愿景（例如 Yuan et al. 2024、Chen et al. 2024、Zhao et al. 2025、Choi et al. 2026），但它们不是本文的重点。

Harness 设计模式

与早期智能体框架"智能体 = LLM + 记忆 + 工具 + 规划 + 行动"相比，harness 工程还额外包括工作流设计（例如循环工程）、评估、权限控制和持久状态管理。它不再仅仅是提示模板，而更接近于运行时和软件系统设计：模型如何观察、行动、记忆、自检和改进。

设计应当刻意保持简单和通用以实现泛化能力，可能需要参考已有的软件工程实践以受益于预训练知识。操作系统与 harness 之间也存在很强的类比关系。与操作系统类似，harness 应当封装复杂的逻辑同时保持接口简洁。与此同时，配置、工具接口和其他协议可能会在行业内逐步标准化。

模式 1：工作流自动化

定义一个模型可以在其中操作、测试和迭代的工作流是自动化的关键设计。Karpathy 的 autoresearch 仓库 (GitHub) 是如何构建此类工作流的一个简洁示例。一个常见的工作流遵循目标导向的循环：规划、执行、观察/测试、改进、再次执行，直到目标达成。该过程可能会主动向用户发出请求，以明确任务规范或执行偏好。

A simplified Codex agent loop

简化的 Codex 智能体循环：智能体调用工具，工具响应影响模型的下一次生成。（图片来源：OpenAI Codex 智能体文章）

工作流图还强调模型分析自身的轨迹和失败案例，然后通过"智能体运行时"而非静态提示模板来迭代改进其进展。

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

在长周期智能体系统中，一个反复出现的模式是对丰富状态和产物的简单控制。harness 不应将整个工作流和所有日志都载入上下文中；相反，它应将持久状态保存在文件中。在长周期智能体展开过程中，实验日志、代码差异、论文摘要、错误追踪和过去的展开轨迹等产物通常远超模型训练所用的上下文窗口长度。

学习如何读取、写入和编辑文件系统（通常通过 bash 命令）是 LLM 的一项基础技能，因此以文件这种简单形式管理持久记忆自然能从核心模型能力的提升中受益。

模式 3：子智能体与后台任务

一个 harness 可以派生多个子智能体并行执行并监控后台任务。当主智能体需要搜索多个假设、并发运行实验，或委派隔离的子任务而不污染主上下文时，这非常有用。父智能体随后需要一个小型进程管理器：启动任务、检查日志、取消失败的运行，并将结果合并回主智能体线程。

关键的设计选择是使并行性显式化和可检查的。如果子智能体输出仅存在于瞬态的聊天上下文中，它们很快就会过时并被隐藏。如果它们被存储为文件、日志和状态记录，模型可以在中断后恢复，并对自身的执行历史进行推理。

案例研究：编程智能体 Harness

主流编程智能体的核心接口在 Claude Code、Codex、OpenCode 和 Cursor 风格的智能体中已经趋于稳定。它们通常使用如下循环：

Coding agent with tools

通过访问一组工具，编程智能体能够在给定仓库中开发和调试问题，类似于人类开发者配备 IDE 的方式。

（非完整列表；仅用于演示。）

| 分组 | 工具定义 | |------|----------| | 文件系统 | - 文件发现：glob、grep、ls<br>- 文件读取：read、read_many<br>- 文件修改：write（写入全新文件）；edit（字符串精确匹配替换）；multi_edit；apply_patch（应用结构化补丁/差异） | | Shell 执行 | 运行命令：bash、PowerShell | | IO | lsp，git 工具如 git_status、git_diff、git_commit | | 外部上下文 | MCP 工具、Skills | | 网页搜索 | web_search、web_fetch、浏览器工具 | | 产物 | 读取文档、图像；生成 HTML、图像 | | 后台进程 | 例如：CronCreate、CronDelete、CronList | | 智能体委派 | 例如：spawn_agent、resume_agent、wait_agent、list_agents、close_agent、interrupt_agent 等 |

Harness 层与核心智能

很难预测 RSI 的未来在多大程度上依赖于 harness 工程，但 RSI 近期路径不太可能以模型直接改写自身权重为起点。我对一个实用的近期路径的预测如下：

  1. ●harness 工程将向元方法论方向发展（即改进获取更好答案的机制，而不仅仅是改进答案本身）。harness 系统本身成为优化目标，启发式规则更少，通用机制更多。
  2. ●反过来，成熟的 harness 使得模型自我改进循环的自动研究成为可能，而更智能的模型则防止 harness 过度工程化，保持系统的可持续性。

最终，许多 harness 改进可能会被内化到核心模型行为中，但与外部上下文和工具的接口应该保留。我们已经在提示工程中看到了这种模式的更柔和版本：随着指令微调和模型推理能力的提升，手动提示技巧变得不再那么核心，但指定目标、约束、上下文和评估的需求并没有消失。

Harness 优化

harness 系统中被优化对象的演进大致为：指令提示 → 结构化上下文 → 工作流 → harness 代码 → 优化器代码。随着模型变得更智能、更强大，我们朝着更复杂的目标和更通用的方法迈进。

上下文工程

随着智能体任务周期显著增加，简单地将所有工具响应和模型生成附加到上下文中很快就会失控。上下文管理是一个为 LLM 构建更结构化和简洁的上下文并管理持久状态的层。毫无疑问，长上下文研究将继续取得进展，但目前长上下文智能和上下文工程有时交织在一起。

Agentic Context Engineering（ACE）（Zhang et al. 2025）将上下文视为一个不断演化的操作手册，而非一个不断加长的提示。它包含三个组件来维护一个由要点组成的上下文操作手册，每个要点都有一个标识符和描述。

  1. ●生成器（Generator）：生成任务轨迹，参考要点。
  2. ●反思器（Reflector）：从成功和失败的轨迹中提炼洞见。
  3. ●管理者（Curator）：通过增量式、逐条目的条目更新结构化上下文。

ACE framework

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

为了在迭代重写过程中防止上下文崩塌和简洁性偏差，ACE 的一个关键设计选择是管理者不重写完整的提示文本块。它输出的是结构化的、逐条目的要点集合，形式为（标识符，描述），这些要点通过确定性逻辑合并到一个结构化上下文日志中。上下文条目定期被精炼和去重。

ACE 从展开过程中学习洞见这一事实帮助我们走向自我管理的记忆，但更新规则和整体工作流仍然是手工设计的。为了走向更加自我改进的循环，Meta Context Engineering（MCE）（Ye et al. 2026）将机制（如何管理上下文）与产物内容（上下文中包含什么）分离，在元优化层面运行技能演化，在基础层面运行上下文优化。

MCE 中的一个技能 $s \in S$ 定义了一个上下文函数 $c_s = (\rho_s, F_s)$，将输入 $x$ 映射到上下文 $c = F_s(x; \rho_s)$，其中：

  • ●$\rho_s = {\rho_1, \dots, \rho_m}$ 是静态组件（提示、知识库、代码库）。
  • ●$F_s = {F_1, \dots, F_k}$ 是动态算子（搜索、选择、过滤、格式化）。

双层优化是在给定技能 $s$ 的训练数据上找到最佳上下文 $c_s^*$，而外层循环找到在验证集上提供最佳性能的最优技能：

内层：$c_s^* = \arg\max_{c_s} J_\text{train}(c_s; s)$

外层：$s^* = \arg\max_{s \in S} J_\text{val}(c_s^*)$

技能数据库追踪先前技能、上下文函数和评估指标的历史 $H_{k-1} = {(s_i, c_i, J_i^\text{train}, J_i^\text{val})}{i=1}^{k-1}$。一个元级别智能体对先前的技能执行智能体级别的 crossover（交叉操作），以在给定任务 $\tau$ 时创建新技能：$s_k = \text{crossover}(\tau, H{k-1})$。

然后，基础级别的上下文工程师执行技能 $s_k$，并在当前技能的指导下从展开反馈 $R_k$ 中学习上下文函数：

$$c_k = \text{engineer}(\tau, s_k; c_{k-1}^*, R_k)$$

MCE framework

Meta Context Engineering（MCE）框架：元级别技能演化搜索上下文管理机制，而基础级别优化任务上下文。（图片来源：Ye et al. 2026）

MCE 不像 ACE 那样强制执行如何结构化上下文的启发式规则。它使用自由形式的技能来存储任务最重要的知识，并迭代地共同演化技能和技能条件化的上下文。在实现上，上下文函数 $c$ 实例化为专用目录中的一组文件，包含静态（skill.md）和动态（上下文和数据展开）组件。元级别和基础级别优化都在具有标准工具集的智能体编码环境中执行：

$$\mathcal{T} = {\text{Read, Write, Edit, Bash, Glob, Grep, TodoWrite}}$$

Meta-Harness（Lee et al. 2026）又深入了一层：被优化的对象是代码——决定和优化哪些信息应该被存储、检索并呈现给模型的代码。其名称中的"Meta-"意味着它是一个用于优化 harness 的 harness。

Meta-Harness algorithm

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

创建新 harness 的提议者本身就是一个编码智能体，最终输出是 Pareto 前沿上的 harness 候选集合。

  • ●整个执行历史通过文件系统访问，因此编码智能体使用 grep 或 cat 等命令来读取它，而不是将所有内容塞入单个提示上下文中。
  • ●提议的 harness 是文件系统中的一个字典，包含其自身的源代码、分数、展开轨迹和状态更新。
  • ●Meta-harness 循环迭代地创建新的 harness，只保留合格的那些。

Meta-Harness performance

Meta-Harness 在（左）少量迭代下的文本分类和（右）TerminalBench-2 上的性能。请注意，TerminalBench-2 实验中的搜索是从 Terminus-KIRA 和 Terminus-2 这两个非常强大的 harness 初始化的。（图片来源：Lee et al. 2026）

尽管如此，重要的一课是清楚的：一旦 harness 设计成为可执行的搜索空间，强大的编码智能体就可以利用人类工程师使用的同一设计空间。

工作流设计

harness 工程中的工作流设计可以由领域专家手工制作。以自动研究为例，已经提出并测试了各种框架。AI Scientist 系统（Lu et al. 2026）构建了一个提出研究想法、编写代码、运行实验、分析结果、撰写手稿并进行同行评审的流水线。Meng et al. (2026) 在 ScientistOne 中将可验证性作为核心设计约束，其中每一项声明（引用、数值、方法论、结论）都必须追溯到证据来源，并通过 Chain-of-Evidence 检查进行审计。

AI Scientist pipeline

AI Scientist 用于想法生成、实验、手稿撰写和同行评审的流水线。（图片来源：Lu et al. 2026）

Autodata 智能体（Kulikov et al. 2026）被设计为一个数据科学家，用于生成训练和评估数据。主智能体管理一个提出问题的挑战者、一个弱求解器、一个强求解器和一个验证器/裁判，旨在合成"恰到好处"难度的数据——即强求解器成功但弱求解器失败的数据。

在 Autodata 中，挑战者的提示根据求解器和验证器的反馈迭代更新。此处的限制在于合成的任务被用于微调弱求解器而非强求解器；如果循环不能迭代地改进强模型，它更类似于在生成的提示分布上进行间接蒸馏，RSI 的味道较弱。

工作流的设计空间是巨大的，自然我们可以将工作流设计表述为搜索问题，因此我们应该能够通过算法而非手工找到好的解决方案。沿着这个方向，Automated Design of Agentic Systems（ADAS）（Hu et al. 2025）将智能体设计本身形式化为一个优化问题——"元智能体搜索"，其中元智能体提出新的智能体工作流设计：

  1. ●使用简单智能体（如 CoT 和 self-refine）初始化一个智能体工作流档案库。
  2. ●让元智能体编写新的智能体，全部以代码实现，灵感来源于档案库中的现有解决方案。
    • ●元智能体首先生成新工作流的高层描述，然后用代码实现。
    • ●草稿程序经过元智能体的两个自我精炼步骤以检查新颖性。
  3. ●评估每个新候选，将成功的候选添加回档案库。
  4. ●重复步骤 2-3 直到达到最大迭代次数。

AFlow（Zhang et al. 2025）将智能体工作流表示为一个图，其中节点表示调用 LLM 的动作，边表示代码中的逻辑操作。工作流优化依赖 MCTS（蒙特卡洛树搜索）：

  1. ●用模板中的起始工作流 $W_0$ 初始化树。
  2. ●使用分数和均匀探索的软混合选择工作流节点。
  3. ●通过让 LLM 基于评估性能生成修改后的工作流来扩展。
  4. ●执行并评估新工作流。
  5. ●如果新工作流在 $N$ 轮预算内表现出改进，则将其添加回树中。
  6. ●重复步骤 2-5，直到前 $k$ 名平均分数达到平台期或预算用尽时停止。

AFlow 在 QA、代码和数学任务上的实验显示，与手工设计的工作流和 ADAS 相比有不错的改进。

自我改进的 Harness

上下文工程和工作流设计都只是 harness 的组成部分。我们需要搜索整个设计空间，并共同优化上下文管理逻辑、工作流、权限以及许多其他 harness 组件。正如我们在 Meta-Harness、ADAS 和 AFlow 等工作中所看到的，代码是定义程序和系统的通用语言。简而言之，harness 是编程提示、工具调用、子智能体、控制流、记忆和工作流逻辑如何协同工作的代码。如果 LLM 能够优化执行智能体的代码，它就能获得比手工提示大得多的设计空间。

Self-Taught Optimizer（STOP）（Zelikman et al. 2023）是递归脚手架改进的早期示例之一。在步骤 $t=0$ 时，种子改进器 $I_0$ 接受初始解 $s$、效用函数 $u$ 和黑盒语言模型 $M$，并返回改进后的解 $s'$，即 $s' = I(u, s; M)$。STOP 的目标不是直接改进 $s$，而是改进改进器 $I$ 本身。

首先，将元效用定义为给定改进器函数 $I$ 在一组下游任务 $\mathcal{D}$ 上的平均效用：

$$\hat{u}(I) \triangleq \frac{1}{|\mathcal{D}|}\mathbb{E}_{(u,s)\sim \mathcal{D}}[u(I(u,s; M))]$$

因为改进改进器函数本身就是一个优化问题，我们可以用元效用衡量 $I_{t-1}$ 的性能，然后递归地获得新版本 $I_t$：

$$I_t = I_{t-1}(\hat{u}, I_{t-1}; M)$$

在 Zelikman et al. (2023) 的实验中，改进后的改进器发现了各种策略，如遗传算法、分解和改进部分、多臂提示赌博机、模拟退火、温度变化和束/树搜索。这类似于 harness 工作流可以作为优化对象。

一个警示性结果：STOP 在 GPT-4 上迭代改进了平均下游性能，但在较弱的模型（如 GPT-3.5 和 Mixtral）上则出现了退化。仅靠递归结构是不够的。基础模型必须足够强大才能改进机制。这意味着 harness 改进可以更好地部署模型，但智能仍然是核心。

更新的工作 Self-Harness（Zhang et al. 2026）依赖 LLM 智能体通过提出-评估-接受的循环来改进自身的 harness。Self-Harness 的循环包含三个阶段：

  1. ●弱点挖掘：将失败聚类为由验证器锚定的失败模式。
    • ●使用当前 harness $h_t$ 在任务上评估并收集执行轨迹以进行分析。
    • ●请注意，两次运行在错误日志中表面上可能共享相同的验证器结果（例如超时或缺少产物），但具有不同的因果机制。因此需要提供有信息量的失败记录，包含终端验证器级别的原因、相关智能体行为的因果状态以及轨迹暴露的抽象智能体机制以揭示根本原因。
  2. ●Harness 提案：基于挖掘到的失败模式提出有界的 harness 编辑。
    • ●在同一模型在 $h_t$ 下作为提议者被调用。
    • ●模型被提供有界的提案上下文：(1) 当前 harness 的可编辑表面，(2) 来自评估系统的验证器锚定的失败模式，(3) 需要保留的通过行为的日志，以及 (4) 先前尝试编辑的摘要。
    • ●Harness 编辑应优先处理可寻址的重复错误模式（例如非特定任务的困难），并可通过窄范围更改解决。
    • ●Harness 编辑候选应当是独特且多样化的。
  3. ●提案验证：验证并合并合格的编辑以创建新 harness $h_{t+1}$。
    • ●候选编辑通过在保留的 $D_\text{in}$（测试是否解决了弱点）和排除的 $D_\text{out}$（检查是否引入了其他未知问题）划分上进行回归测试来评估。
    • ●只有在保留数据和排除数据上都不退化的候选才会被接受。
    • ●接受的候选被合并以更新 harness 到 $h_{t+1}$，被拒绝的候选被记录但不会改变活跃的 harness。

在 Terminal-Bench-2 上使用 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 运行，Self-Harness 被证明能够为不同基础模型的不同弱点学习特定于模型的 harness 指令，并改进排除数据的通过率。

这类 self-harness 工作确实引起了我的担忧：如果允许程序编辑操作系统，抽象边界就被打破了。可编辑表面需要适当设计，权限控制和安全层需要存在于这个循环之外。围绕奖励黑客行为的所有挑战依然存在。

进化搜索

进化搜索是一种受自然选择启发的优化方法。它通过对种群中的解进行变异并仅保留群体中具有高"适应度"的个体来进化。进化搜索特别适用于以下情况：(1) 搜索空间很大或形状不规则，(2) 很难用梯度直接优化但容易评估解。Harness 搜索似乎很好地契合这里。

进化搜索已在先前的研究中用于提示工程。Promptbreeder（Fernando et al. 2023）通过丰富的变异操作集优化任务特定提示，有趣的是，变异提示（即告诉 LLM 变异任务提示的指令）本身也通过进化来改进。GEPA（Agrawal et al. 2025）将基于反思的提示与进化搜索相结合，使用对试错轨迹的自然语言反思来提出提示更新。

Novikov et al. (2025) 引入了 AlphaEvolve 作为一个编码智能体进化搜索系统，它维护一个候选程序池并提示冻结的 LLM 生成改进的差异。随着系统反复评估子程序并保留成功的程序，它在随时间推移中发现更好的解决方案。

AlphaEvolve 设计中的几个关键细节：

  • ●提示包括父程序、结果、指令，有时还有元信息。
  • ●编码智能体可以访问整个代码库，但用于改进的代码区域用 # EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END 清晰标记。
  • ●元提示与指令和上下文协同演化，类似于我们演化解决方案程序的方式。

消融研究显示了进化过程、提示中的上下文、元提示、全文件演化以及使用更强的 LLM 的价值。

近期变体如 ThetaEvolve（Wang et al. 2025）将进化搜索与 RL 和上下文学习相结合。ShinkaEvolve（Lange et al. 2025）引入了三个用于改进 LLM 采样效率的新组件：

  • ●通过设计父采样以平衡性能排名和后代数量来更高效地探索。
  • ●基于嵌入余弦相似度的代码新颖性拒绝采样，丢弃与现有种群过于相似的候选。
  • ●在元草稿板中识别成功解决方案中的好模式以指导未来变异。

与上述专注于解决方案改进的方法不同，Darwin Godel Machine（DGM）（Zhang et al. 2025）明确目标是使用基于 LLM 的编码智能体进化可编辑的 harness 代码库。准确地说，这个智能体被允许修改自身的 harness。后续工作 Hyperagents（Zhang et al. 2026）引入了一个元智能体来控制如何修改现有任务智能体以创建新智能体。

  1. ●从池中选取一个编码智能体。
  2. ●在每次迭代中，以与其性能成正比、与其后代数量成反比的概率选择父智能体，修改并分支以产生新智能体。
  3. ●被选中的父智能体检查自身的基准评估日志，然后提出对其自身 harness 代码库的改进以生成新版本的编码智能体。代码编辑通过两个基本工具实现：(1) bash（参数：<bash_command>）和 (2) editor（参数：view/create/edit <file_path>）。
  4. ●新编码智能体被评估，只有具有足够高性能的才会被添加回池中。
  5. ●重复步骤 2-4 直到满足某些停止条件。

DGM 是在固定模型下的 harness 演化。在使用 Claude 3.5 Sonnet 作为基础 LLM 和简单的初始 harness 配置的实验中，DGM 发现的智能体在 SWE-bench Verified（20% 到 50%）和 Polyglot（14.2% 到 30.7%）上匹配或超越了手工设计的智能体。

这类方法在候选解可以自动评估且候选适应度容易量化时效果很好，例如矩阵乘法、GPU 内核优化、算法竞赛、数据中心调度。在评估缓慢、模糊或主要依赖启发式的领域中则更困难。进化的计算效率和有效性也是关注点。

与模型权重的联合优化

Harness 演化改变的是模型周围的非参数系统。为了实现完整的自我改进，可以完全允许模型同时更新自身的权重。权重更新可以通过改进模型训练流水线或测试时持续学习来实现。持续学习的主题值得在未来的文章中单独讨论。

SIA（Hebbar et al. 2026）是在同一优化循环中结合 harness 改进和模型参数更新的早期尝试，设计了三个组件：

  • ●元智能体（Meta-Agent）：提出初始 harness。
  • ●任务特定智能体（Task-Specific Agent）：执行任务。
  • ●反馈智能体（Feedback-Agent）：基于最近的轨迹选择是更新 harness 还是模型权重。

SIA 实验中的几个令人困惑的选择使得结果难以解释。例如，任务特定智能体比用于元智能体和反馈智能体的模型弱得多（gpt-oss-120b 对比 Claude Sonnet 4.6），基线也太弱，无法与相关方法进行干净的交叉比较。我认为这个方向很有趣，但证据仍是初步的。训练稳定性和古德哈特效应等许多挑战仍然是开放问题。

未来挑战

AI Scientist 系列工作令人信服地证明了专家设计的 harness 可以协调高度自动化的研究循环，物化为研究论文的撰写。但论文生产不等同于科学发现。系统可以写出看似合理的论文，但仍然存在伪造引用、实现漂移或实验结果薄弱的问题。

Trehan & Chopra (2026) 测试了 LLM 是否能在最少脚手架和基本工具（即 read_file、write_file、llm_search、list_files）的条件下从研究想法到论文。每个想法都有一个专用的工作空间，智能体可以在其中生成和读取文档作为其上下文的一部分。他们在三个领域（世界模型、多智能体 RL、AI 安全与对齐）进行了实验，每个领域有 45-50 篇高质量种子文档以启发新想法。只有四个想法被人类专家选中运行完整流水线，只有一个被完全执行成论文。他们在实验中观察到六个反复出现的失败模式：

  • ●退回到训练数据默认值：使用较旧的库、过时的命令、标准格式或未基于实际代码库或数据集的假设。
  • ●执行压力下的实现漂移：当实现变得技术上复杂时，模型可能会转向更常见、更简单的解决方案，而非提出的方法。
  • ●记忆和上下文退化：长周期项目会丢失关键细节，除非将日志写为持久产物。
  • ●过度乐观：模型在嘈杂或失败的实验上声称成功，类似于 Bubeck et al. (2025) 观察到的"p-hacking 和 eureka-ing"模式，其中模型可能引入"胶带修补"并在信号仍是噪声时宣告胜利。
  • ●领域智能不足：模型缺乏隐性的工艺知识，例如预测实现复杂度、判断实验结果是否合理，或知道哪些基线很重要。
  • ●科学品味薄弱：实验可能可执行，但未能回答正确的问题。

朝着完整的 RSI 迈进，研究人员取得了真正的进展，但几个瓶颈依然存在。

1. 虚弱和模糊的评估器。 许多研究声明没有快速精确的验证器，许多现实世界的任务也是如此。当前自我改进循环在评估指标可测量且客观时效果最好，类似于 RL 的工作方式。

研究品味、新颖性和长期科学价值则难衡量得多。例如，研究品味通常结合了问题框架、实验设计，以及对哪些令人惊讶的结果值得追求和哪些失败案例值得重试的判断。

2. 上下文和记忆寿命。 随着 AI 智能体变得更加自主和独立，记忆不断增长。一个有用的 harness 需要管理上下文和记忆，以弥补现有长上下文生成的局限性，同时最大化长周期任务的成功率。既然人类能够在有生之年维持记忆，我认为类比的是上下文工程将且应该成为智能的核心部分，而不仅仅是一个软件系统层。

3. 负面结果。 研究人员有动力发表成功的结果，因此文献偏向于成功。在大量数据上训练的 LLM（目前大多是人类创建的，哈哈）可能不擅长决定何时放弃假设、报告负面结果，甚至承认失败，因为数据中成功与失败案例的不平衡。研究 harness 应使失败的尝试易于保留，因为从失败中学习是修剪任务搜索空间的最佳方式。

4. 多样性崩塌。 进化和 RL 循环倾向于利用已知的高奖励模式。我们需要机制来防止种群崩塌到同一解决方案的变体。这对于开放式研究尤其关键，因为最佳路径在当前评估器下可能最初看起来更差。

**5. 奖励黑客。**自我改进循环优化它们获得的任何信号。如果奖励来自单元测试，智能体可能过拟合测试；如果来自裁判模型，它可能学习特定于该裁判的奖励黑客技巧；如果来自基准分数，它可能利用基准伪影。

评估器和权限控制可能应该在演化的 harness 循环之外，在重要的决策点执行排除测试、轨迹审计和人工审查——多少监督可以被扩展和自动化仍然是一个开放的研究领域。

6. 长期成功。 外部优化循环操作的奖励超越了我们可以在训练沙箱中模拟的个体展开。

以编程智能体为例。编程智能体已经提高了软件工程的日常生产力，但许多优化目标仍然过于短期。它通常能完成手头的任务，但不太清楚它应该如何保护由数百或数千名工程师维护的代码库的长期健康。标准的基于沙箱的 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/"
}

附录：一些有用的基准测试

  • ●

    PaperBench：从头复现 20 篇 ICML 2024 Spotlight 和 Oral 论文，包括理解论文贡献、开发代码库和成功执行实验。

    • ●每个复现任务被分解为更小的、可独立评分的子任务。
    • ●共 8,316 个评分标准，与论文作者合作开发。
    • ●最佳模型（Claude 3.5 Sonnet，约 21%）未能超越机器学习博士研究生。
    • ●包括 PaperBench、PaperBench Code-Dev（轻量版）和 JudgeEval。
  • ●

    CORE-Bench：评估已发表研究的计算可复现性。

    • ●基于来自计算机科学、社会科学和医学领域的 90 篇科学论文的 270 个任务。
    • ●任务涉及从提供的代码和数据中复现结果。
    • ●包含多个难度级别以及纯语言和视觉-语言任务。
    • ●当时报告的最佳智能体（GPT-4o 和 GPT-4o-mini）在最难的任务上仅达到 21% 的准确率。
  • ●

    ScienceAgentBench：评估 LLM 智能体在数据驱动的科学发现上的能力。

    • ●从四个学科（数学、化学、生物学、地理学）的 44 篇同行评审论文中提取的 102 个任务。
    • ●涵盖这些领域的基本数据科学任务：数据处理、模型开发、数据分析和信息可视化。
  • ●

    RE-Bench：在现实 ML 研究工程环境中评估前沿 AI 智能体与人类专家的对比。

    • ●7 个具有挑战性的开放式 ML 研究工程环境。
    • ●每个环境 =（评分函数、起始解、参考解）；每个可在 8 个或更少的 H100 GPU 上运行。
    • ●示例：优化内核、运行扩展律实验、修复嵌入、微调 GPT-2 进行 QA 等。
    • ●包含 61 位不同人类专家的 71 次八小时尝试的数据。
    • ●人类专家在 82% 的八小时尝试中获得了非零分数；24% 匹配或超越了强参考解。
    • ●最佳 AI 智能体在 2 小时预算下得分比人类高 4 倍，但人类在更长预算下回报更好，在 8 小时和 32 小时设置下超越了智能体。
  • ●

    MLE-bench：在离线 Kaggle 竞赛上评估机器学习工程智能体。

    • ●包含 75 个从 Kaggle 策划的 ML 工程竞赛。
    • ●测试训练模型、准备数据集、运行实验和向评分脚本提交预测。
    • ●使用 Kaggle 公共排行榜作为人类基线。
    • ●论文中最佳设置（o1-preview 配合 AIDE 脚手架）在 16.9% 的竞赛中达到了 Kaggle 铜牌水平。
    • ●包括资源扩展和污染分析。
  • ●

    KernelBench：评估生成的 GPU 内核的正确性和速度。

    • ●250 个 PyTorch 任务，评估 LLM 是否能编写快速且正确的内核。
    • ●评估指标 fast_p = 生成的内核中正确且比基线更快的百分比。

参考文献

  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." arXiv preprint arXiv:2505.03335, 2025.
  5. ●Yuan, et al. "Self-Rewarding Language Models." arXiv preprint arXiv:2401.10020, 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." arXiv preprint arXiv:2601.21557, 2026.
  9. ●Lee, et al. "Meta-Harness: End-to-End Optimization of Model Harnesses." arXiv preprint arXiv:2603.28052, 2026.
  10. ●Lu, et al. "Towards end-to-end automation of AI research." Nature, 651:914-919, 2026.
  11. ●Meng, et al. "ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence." arXiv preprint arXiv:2605.26340, 2026.
  12. ●Kulikov, et al. "Autodata: An agentic data scientist to create high quality synthetic data." arXiv preprint arXiv:2606.25996, 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." arXiv preprint arXiv:2606.09498, 2026.
  18. ●Fernando, et al. "Promptbreeder: Self-Referential Self-Improvement Via Prompt Evolution." arXiv preprint arXiv:2309.16797, 2023.
  19. ●Agrawal, A. et al. "GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning." arXiv preprint arXiv:2507.19457, 2025.
  20. ●Novikov, et al. "AlphaEvolve: A coding agent for scientific and algorithmic discovery." arXiv preprint arXiv:2506.13131, 2025.
  21. ●Lange, Imajuku, and Cetin. "ShinkaEvolve: Towards Open-Ended And Sample-Efficient Program Evolution." arXiv preprint arXiv:2509.19349, 2025.
  22. ●Wang, et al. "ThetaEvolve: Test-time Learning on Open Problems." arXiv preprint arXiv:2511.23473, 2025.
  23. ●Zhang, et al. "Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents." arXiv preprint arXiv:2505.22954, 2025.
  24. ●Zhang, et al. "Hyperagents." arXiv preprint arXiv:2603.19461, 2026.
  25. ●Yuksekgonul, et al. "Learning to Discover at Test Time." arXiv preprint arXiv:2601.16175, 2026.
  26. ●Riaz, et al. "Epistemic Uncertainty for Test-Time Discovery." arXiv preprint arXiv:2605.11328, 2026.
  27. ●Hebbar, et al. "SIA: Self Improving AI with Harness & Weight Updates." arXiv preprint arXiv:2605.27276, 2026.
  28. ●Trehan and Chopra. "Why LLMs Aren't Scientists Yet: Lessons from Four Autonomous Research Attempts." arXiv preprint arXiv:2601.03315, 2026.
  29. ●Bubeck, et al. "Early science acceleration experiments with GPT-5." arXiv preprint arXiv:2511.16072, 2025.
  30. ●Starace, et al. "PaperBench: Evaluating AI's Ability to Replicate AI Research." ICML 2025.
  31. ●Wijk, et al. "RE-Bench: Evaluating frontier AI R&D capabilities of language model agents against human experts." ICML 2025.
  32. ●Chan, et al. "MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering." arXiv preprint arXiv:2410.07095, 2024.
  33. ●Chen, et al. "ScienceAgentBench: Toward Rigorous Assessment of Language Agents for Data-Driven Scientific Discovery." ICLR 2025.
  34. ●Siegel, et al. "CORE-Bench: Fostering the Credibility of Published Research Through a Computational Reproducibility Agent Benchmark." TMLR 2024.
  35. ●Ouyang, et al. "KernelBench: Can LLMs Write Efficient GPU Kernels?" arXiv preprint arXiv:2502.10517, 2025.
← 返回博客列表