Harness 工程：模型之外那层系统如何自我改进

本文译自 Lilian Weng 的 Harness Engineering for Self-Improvement¹，2026 年 7 月发表于 Lil’Log，梳理了 harness 这一层的设计模式与优化方法，以及它和递归自我改进之间的关系。

recursive self-improvement (RSI) 递归自我改进这个概念可以追溯到 I. J. Good (1965)²，他把「超智能机器」定义为一个在所有智力活动上都能超越人类、并且能设计出更好的机器来改进自身的系统。Yudkowsky (2008)³ 用「递归自我改进」这个说法指代一个具体的反馈回路：AI 用它当前的智能去改进那套生产它的智能的认知机制。

在现代 AI 里，这个反馈回路可能表现为模型直接改写自己的权重，或者更宽泛地说，模型改进 训练流水线 和 部署系统，进而催生一个在各类有经济价值的任务上表现更好的后继模型。前沿实验室的研究开发速度已经被证明大幅加快了（Anthropic⁴、OpenAI⁵）。

我特意提到 「部署系统」，因为原始模型与真实世界上下文之间的那一层，看起来和模型的原始智能（即预训练刚结束时的 evals）一样重要。harness 是 AI 部署的重要组成部分，Claude Code 和 Codex 这类成功的 coding agent 产品已经说明了这一点。harness 指的是围绕基础模型的那套系统，它编排执行过程，决定模型如何思考和规划、如何调用工具并行动、如何感知和管理上下文、如何存储 artifact、以及如何评估结果。

这篇文章只聚焦 harness 工程相关的研究，以及它对 RSI 的贡献。近期大量关于 auto-research、自我改进 agent、进化式程序搜索的工作，都可以围绕这个问题组织起来。另一些关于模型 self-play、合成数据、test-time training 以及更广义的持续学习的工作也符合 RSI 的愿景（例如 Yuan et al. 2024⁶、Chen et al. 2024⁷、Zhao et al. 2025⁸、Choi et al. 2026⁹），但不是本文的重点。

Harness 设计模式

和早期的 agent 框架（「agent = LLM + memory + tools + planning + action」¹⁰）相比，harness 工程还额外包含 工作流设计（例如 loop engineering）、评估、权限控制和持久状态管理。它已经不只是 prompt 模板，而更接近 runtime 和软件系统设计：模型如何观察、行动、记忆、自查、并改进自己。

设计应当刻意保持简单和通用以便泛化，并且最好参照已有的软件工程实践，这样能从预训练知识里获益。操作系统和 harness 之间也有很强的类比关系。和 OS 类似，harness 应当把复杂逻辑封装起来，同时保持接口简单。与此同时，配置、工具接口和其他协议可能会逐渐在业界形成标准。

模式一：工作流自动化

定义一个模型可以在其中操作、测试、迭代的工作流，是自动化的关键设计。Karpathy 的 autoresearch 仓库¹¹就是这种工作流如何构建的一个干净例子。常见的工作流遵循一个目标导向的循环：规划、执行、观察/测试、改进、再执行，直到 目标达成。这个过程中也可能主动向用户提问，以澄清任务规格或执行偏好。

这张工作流图还强调，模型要分析自己的轨迹和失败案例，然后通过一个「agent runtime」而不是静态的 prompt 模板来迭代自己的进展¹²。

模式二：把文件系统当持久化记忆

长程 agent 系统里反复出现的一个模式是：用简单的方式控制丰富的状态和 artifact。harness 不应该把整个工作流和所有日志都带在上下文里，而应该把持久状态放在文件里。在长程的 agentic rollout 中，实验日志、代码 diff、论文摘要、错误堆栈、过往 rollout 轨迹这些 artifact，往往会远远超过模型训练时所面对的 上下文窗口长度。

学会读、写、编辑文件系统（通常通过 bash 命令）是 LLM 的一项基础能力，因此以文件这种简单形式来管理持久化记忆，天然能从核心模型能力的提升中获益。

模式三：子 agent 与后台任务

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

关键的设计选择是让并行显式且可检视。如果 subagent 的输出只存在于短暂的对话上下文里，它们很快就会过期并变得不可见。如果它们被存成文件、日志和状态记录，模型就能在中断之后恢复，并对自己的执行历史进行推理。

案例：Coding Agent 的 harness

主流 coding agent 的核心接口已经趋于稳定，Claude Code、Codex、OpenCode 和 Cursor 这类 agent 大体一致。它们常用的循环是这样的：

有了一套工具，coding agent 就能在给定仓库里开发和调试问题，就像人类开发者配备了 IDE 一样。

（不是完整清单，仅作示意。感兴趣的话可以读这个¹³。）

Harness 层，还是核心智能？

很难预测未来的 RSI 会在多大程度上依赖 harness 工程，但 RSI 的近期路径不太可能从模型直接改写自己的权重开始。我对一条务实的近期路径的预测是：

1. harness 工程会朝着元方法论的方向演进（也就是改进那套「获得更好答案」的机制，而不只是改进答案本身）。harness 系统自身会变成优化目标，启发式规则更少，通用机制更多。
2. 反过来，成熟的 harness 让模型自我改进的 auto-research 回路成为可能，而更聪明的模型又能防止 harness 被过度设计，让系统保持可持续。

最终，很多 harness 上的改进可能会被 内化 进模型的核心行为，但与外部上下文和工具之间的接口应该会留下来。我们在 prompt engineering¹⁴ 上已经见过这个模式的一个更温和的版本：随着 instruction tuning 和模型推理能力的提升，手工的 prompt 技巧变得不那么重要了，但 指定目标、约束、上下文和评估方式的需求并没有消失。

Harness 优化

harness 系统里被优化的对象，大致按这个顺序递进：instruction prompt → 结构化上下文 → 工作流 → harness 代码 → 优化器代码。随着模型变得更智能、更强大，我们朝着更复杂的目标和更通用的方法前进。

Context Engineering

随着 agentic 任务的时间跨度显著变长，简单地把所有工具返回和模型生成都追加进上下文，很快就会失控。上下文管理是这样一层：为 LLM 构造更结构化、更精简的上下文，并管理持久状态。长上下文研究毫无疑问会继续进步，但当下长上下文智能和 context engineering 有时是交织在一起的。

Agentic Context Engineering（ACE；Zhang et al. 2025¹⁵）把上下文当作一份不断演化的 playbook，而不是一个越来越长的 prompt。它用三个组件来维护一份由 bullet point 组成的上下文 playbook，每个条目带一个标识符和一段描述。

1. Generator：参照 bullet point 产出任务轨迹。
2. Reflector：从成功和失败的轨迹里提炼洞见。
3. Curator：用增量的、逐条的条目更新结构化上下文。

为了防止反复重写过程中出现上下文坍缩和「越写越短」的偏差，ACE 的一个关键设计选择是 curator 不重写整个 prompt 大块文本。它输出的是一组结构化、逐条的 bullet，形式为（标识符，描述），这些 bullet 再用确定性的逻辑合并进一份结构化的上下文日志。上下文条目会被周期性地精炼和去重。

ACE 从 rollout 里学到洞见这件事，帮我们朝自管理记忆迈进了一步，但更新规则和整体工作流仍然是手工设计的。为了更接近一个自我改进的回路，Meta Context Engineering（MCE；Ye et al. 2026¹⁶）把机制（如何管理上下文）和 artifact 内容（上下文里有什么）分开，在元优化层面跑 skill 演化，在基础层面跑上下文优化。

一个 MCE skill $s \in \mathcal{S}$ 定义了一个上下文函数 $c_s=(\rho_s,F_s)$，把输入 $x$ 映射为上下文 $c = F_s(x;\rho_s)$，其中：

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

这个双层优化要在训练数据上找到给定 skill $s$ 下的最佳上下文 $c_s^*$，而外层循环则寻找在验证集上表现最好的最优 skill：

skill 数据库记录了历史上的 skill、上下文函数和评估指标 $\mathcal{H}_{k-1} = \{(s_i,c_i,J_i^\text{train}, J_i^\text{val})\}_{i=1}^{k-1}$。一个元层面的 agent 在既有 skill 上做 agentic crossover¹⁷，为任务 $\tau$ 创造一个新 skill：$s_k=\text{crossover}(\tau,\mathcal{H}_{k-1})$。

然后一个基础层面的 context engineer 执行 skill $s_k$，在当前 skill 的引导下从 rollout 反馈 $\mathcal{R}_k$ 中学习上下文函数：$c_k=\text{engineer}(\tau,s_k;c_{k-1}^*,\mathcal{R}_k)$。

MCE 不像 ACE 那样为「上下文该怎么组织」强加一条启发式规则。它用 自由形式的 skill 来存放一个任务最重要的知识，并让 skill 和以 skill 为条件的上下文一起迭代演化。实现上，一个上下文函数 $c$ 被实例化为一个专用目录下的一组文件，同时包含静态部分（skill.md）和动态部分（上下文与数据 rollout）。元层面和基础层面的优化都在 agentic coding 环境里用一套标准工具集执行：

Meta-Harness（Lee et al. 2026¹⁸）又往下深入了一层：被优化的对象是那段 代码，它决定并优化哪些信息应该被存储、检索、呈现给模型。名字里的「Meta-」意思是它是一个用来优化 harness 的 harness。

创造新 harness 的 proposer 本身就是一个 coding agent，最终输出是一组位于 Pareto 前沿上的 harness 候选。

• 整个执行历史都可以通过文件系统访问，因此 coding agent 用 grep 或 cat 这类命令去读，而不是把所有东西一股脑塞进一个 prompt 上下文。
• 被提出的 harness 是文件系统里的一个字典，包含它自己的源码、分数、rollout 轨迹和状态更新。
• meta-harness 的循环不断创造新 harness，只保留合格的那些。

不过，重要的教训很清楚：一旦 harness 设计变成一个可执行的搜索空间，一个强大的 coding agent 就能用上人类工程师用的同一套设计空间。

工作流设计

harness 工程里的工作流设计可以由领域专家手工打造。以 auto-research 为例，已经有各种框架被提出并测试过。AI Scientist 系统（Lu et al. 2026¹⁹）搭了一条流水线，用来提出研究想法、写代码、跑实验、分析结果、写稿件、做同行评审。Meng et al. (2026)²⁰ 在 ScientistOne 里把可验证性作为核心设计约束，每一条论断（引用、数值、方法、结论）都必须追溯到一个证据来源，并由 Chain-of-Evidence 检查来审计。

Autodata agent（Kulikov et al. 2026²¹）被设计成一个数据科学家，用来生成训练和评估数据。主 agent 管理一个提出问题的 challenger、一个 weak solver、一个 strong solver 和一个 verifier/judge，目标是合成难度「刚刚好」的数据——也就是 strong solver 能做对、weak solver 会做错的那种。

在 Autodata 里，challenger 的 prompt 会根据 solver 和 verifier 的反馈迭代更新。这里的局限在于，合成出来的任务被用于微调 weak solver 而不是 strong solver；如果这个回路无法迭代地改进强模型，那它更像是在一个生成出来的 prompt 分布上做间接蒸馏，RSI 的味道就淡了。

工作流的设计空间 极其巨大，自然我们可以把工作流设计看成一个搜索问题，因此应该能用算法而不只是手工来找到好的解。沿着这个方向，Automated Design of Agentic Systems（ADAS；Hu et al. 2025²²）把 agent 设计本身表述为一个优化问题，即「meta-agent search」，由一个 meta-agent 提出新的 agentic 工作流设计。

1. 用 CoT、self-refine 这类简单 agent 初始化一个 agentic 工作流档案库。
2. 让 meta-agent 参照档案库里已有的解，用 代码 编写新的 agent。
   • meta-agent 先生成新工作流的高层描述，然后用代码实现它。
   • 草稿程序再由 meta-agent 走两轮 self-refine（即让模型给出反馈，再让同一个模型根据反馈改进先前的输出；Madaan et al. 2023²³），检查它的新颖性。
3. 评估每个新候选，把成功的加回档案库。
4. 重复步骤 2-3，直到达到最大迭代次数。

AFlow（Zhang et al. 2025²⁴）把 agentic 工作流表示成一张图，节点代表调用 LLM 的动作，边用代码实现逻辑操作。工作流优化依赖 MCTS（Monte Carlo Tree Search）²⁵：

1. 用一个模板在树中初始化起始工作流 $W_0$。
2. 用一种「分数与均匀探索的软混合」策略选出一个工作流节点。
3. 让 LLM 以该节点的评估表现为条件，产出一个修改后的工作流，以此扩展它。
4. 执行并评估新工作流。
5. 如果新工作流在 $N$ 轮预算内表现出提升，就把它加回树中。
6. 重复步骤 2-5，当 top-$k$ 平均分停滞或耗尽预算时停止。

AFlow 在问答、代码、数学任务上的实验显示，它相比手工设计的工作流和 ADAS 都有不错的提升。

自我改进的 harness

不管是 context engineering 还是工作流设计，都只是 harness 的一部分。我们需要搜索整个设计空间，把上下文管理逻辑、工作流、权限以及其他许多 harness 组件放在一起优化。正如我们在 Meta-Harness、ADAS、AFlow 这些工作里看到的，✨代码✨是定义程序和系统的通用语言。说白了，harness 就是一段代码，它规定了 prompt、工具调用、subagent、控制流、记忆和工作流逻辑如何协同工作。如果一个 LLM 能优化那段执行 agent 的代码，它能触及的设计空间就比手写 prompt 大得多。

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

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

由于改进改进器函数本身也是一个优化问题，我们可以基于 $I_{t-1}$ 由元效用衡量出的表现，通过一次自我改进更新递归地得到新版本的 $I_t$：

在他们的实验里，改进后的改进器发现了各种策略，比如遗传算法、分解并改进局部、多臂 prompt bandit、模拟退火、变化温度、以及 beam search / tree search。这类似于 harness 工作流如何被表示成一个可优化的对象。

Zelikman et al. (2023) 的发现里有一个 值得警惕的 结果：STOP 在 GPT-4 上跨迭代提升了下游平均表现，但在 GPT-3.5 和 Mixtral 这类较弱的模型上反而变差了。仅有递归结构是不够的，基础模型必须 足够强 才能改进那套机制。这意味着 harness 改进能让模型的部署效果更好，但智能仍然是核心。

Lin et al. (2026)²⁷ 更细致地研究了 harness 演化对模型能力的依赖。他们拆开了两条轴：（1）harness-updating 指产出有用的 harness 编辑的能力；（2）harness-benefit 指利用更新后的 harness 来更好地解决任务的能力。有意思的是，在他们的实验里，从 Qwen3.5-9B 到 Claude Opus 4.6 这一系列不同规模、不同核心智能的模型，被观察到表现出相似的 harness updating 能力；那个 9B 的 harness proposer/evolver 能写出在流程上与 Opus 同构的 skill。而要最好地利用一个 harness，模型需要正确且及时地调用 skill/工具，并且擅长长程指令遵循。

译注：原文正文写的是「from Qwen3.5-9B to Claude Opus 4.6」，图注写的是「from Qwen2-32B to Opus 4.6」，而图里标出的最小模型是 Qwen3-32B。三处不一致，此处按原文逐字译出，具体型号建议回查 Lin et al. (2026) 原论文。

更近期的一个工作 Self-Harness（Zhang et al. 2026²⁸）依靠 LLM agent 通过一个「提出-评估-接受」的循环来改进自己的 harness。

Self-Harness 的循环有三个阶段：

1. 弱点挖掘：把失败聚类成以 verifier 为依据的失败模式。
   • 用当前 harness $h_t$ 在任务上评估，收集执行轨迹用于分析。
   • 注意两次运行在错误日志表面上可能共享同一个 verifier 结果，比如超时或缺少 artifact，但因果机制完全不同。因此我们需要一份信息丰富的失败记录，包含终态的 verifier 层面成因、相关 agent 行为的因果状态、以及轨迹所暴露出的抽象 agent 机制，才能挖出根因。
2. harness 提案：基于挖出的失败模式提出有界的 harness 编辑。
   • 在 $h_t$ 下调用同一个模型作为 proposer。
   • 给模型提供一个有界的提案上下文：（1）当前 harness 的可编辑面；（2）来自评估系统的、以 verifier 为依据的失败模式；（3）应当被保留的通过行为的记录；（4）先前尝试过的编辑的摘要。
   • harness 编辑应当优先针对那些可解决的、反复出现的错误模式（例如不是任务本身难度导致的），并且能用小范围改动解决。
   • harness 编辑候选之间应当互不相同、保持多样。
3. 提案验证：验证并合并合格的编辑，生成新的 harness $h_{t+1}$。
   • 候选编辑在 held-in $D_\text{in}$（测试弱点是否被解决）和 held-out $D_\text{out}$（检查是否引入了其他未知问题）两个划分上做回归测试。
   • 只有在 held-in 和 held-out 上都没有回退的候选才被接受。
   • 被接受的候选合并进去，把 harness 更新为 $h_{t+1}$；被拒绝的候选只记录下来，不改动当前生效的 harness。

在 Terminal-Bench-2 上跑 MiniMax M2.5、Qwen3.5-35B-A3B 和 GLM-5 时，Self-Harness 被证明能学到针对不同基础模型各自弱点的、模型特定的 harness 指令，并提升 held-out 通过率。

Self-Harness 这类工作确实让我担心：如果允许一个程序编辑 OS 系统，抽象边界就被打破了。可编辑面需要被妥善设计，权限控制和安全层需要活在这个回路之外。所有围绕 reward hacking²⁹ 的挑战依然存在。

Agentic Harness Engineering（AHE；Lin et al. 2026³⁰）认为 harness 演化的瓶颈在于可观测性——也就是说，当一次 rollout 失败时，我们需要知道是哪个组件造成的，而且每一次编辑都应该有证据支撑。

这个框架用三根可观测性支柱构成一个闭环：

1. 组件可观测性：每个可编辑的 harness 组件在文件系统里都有一个表示，因此动作空间是显式且可追溯的。
   • 一个 harness 包含 7 个组件：system prompt、工具描述、工具实现、middleware、skill、subagent 配置、长期记忆。
   • 每种失败模式都被映射到某一个组件上，这样编辑可以更有针对性。
2. 经验可观测性：把大量原始轨迹分析、总结成一套分层的证据与失败模式。
   • 每个 harness 生成 $k$ 条轨迹。
   • 用一个 agent（「Agent debugger」）来分析这些轨迹（每条存成一个文件），并生成关于失败或成功根因的单任务分析报告。
   • 所有单任务报告被聚合成一份 benchmark 总览供下一步使用，需要时还能访问原始轨迹。这种分层访问结构更省 token。
3. 决策可观测性：每一次编辑都配一个对下一轮的预测，用来验证。
   • 一个 agent（「Evolve agent」）读仓库并决定编辑哪个组件，然后产出编辑内容及其背后的推理。
   • 每次编辑都是一个文件级、可被证伪的论断，能在下一轮被验证，同时受两条约束：
     • （1）编辑只能作用于 harness 工作区，runs 目录、tracer、verifier 和 LLM 配置都是只读的，这就禁掉了一批 reward hacking 手法（比如关掉 verifier、换模型、或者调高推理预算），从而让每一份被记录的收益都能归因到 harness 编辑上。
     • （2）编辑必须由证据驱动，并带一条宣言式记录：失败证据的名称、推断出的根因、针对性的修复、以及一个包含「预期修好什么」和「有回退风险的地方」的影响预测。

在 Terminal-Bench-2 上，除了 Hard 档之外，AHE 的表现好于人类设计的 harness（OpenCode、Terminus-2、Codex）以及另外几个 self-evolve 基线（ACE、TF-GRPO）。同一个冻结的 harness 不再继续演化，也能迁移到 SWE-bench-verified 上，这说明演化出来的 harness 确实把工程经验编码进了 harness 组件里，而不是在做针对特定 benchmark 的优化。

进化式搜索

进化式搜索是一种受自然选择启发的优化方法（见我以前那篇关于进化算法的文章³¹）。它演化一个解的种群，对它们做变异，只保留人群中「fitness」高的那些。当（1）搜索空间极大或形状很怪；（2）难以用梯度直接优化但容易评估解的好坏时，进化式搜索就派得上用场。harness 搜索看起来很适合这里。

进化式搜索过去在 prompt engineering 里已经被用过。Promptbreeder（Fernando et al. 2023³²）通过一套丰富的变异操作来优化任务特定的 prompt，有意思的是，那些变异 prompt（即指示 LLM 去变异任务 prompt 的指令）本身也通过演化被改进。GEPA（Agrawal et al. 2025³³）把基于反思³⁴的 prompting 和进化式搜索结合起来，用对试错轨迹的自然语言反思来提出 prompt 更新。

Novikov et al. (2025)³⁵ 提出的 AlphaEvolve 是一个 coding-agent 式的进化搜索系统，它保存一池候选程序，并 prompt 冻结的 LLM 生成用于改进的 diff。随着系统不断评估子程序并保留成功的那些，它逐渐发现更好的解。

AlphaEvolve 的设计里有几个细节很关键：

• prompt 里包含父程序、结果、指令，有时还有元信息。
• coding agent 能访问整个仓库，但需要改进的代码区域用 # EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END 显式标出。
• meta-prompt 按 LLM 的建议与指令和上下文共同演化，方式类似我们演化解程序的做法。

消融实验展示了演化流程、prompt 里的上下文、meta-prompt、全文件演化以及使用更强 LLM 各自的价值。

近期的一些变体，比如 ThetaEvolve（Wang et al. 2025³⁶）把进化式搜索与 RL 和 in-context learning 结合，DemoEvolve（Che, et al. 2026³⁷）则用人类专家演示来扩充自我 rollout 的档案库，作为 harness 层面诊断和编辑的参考经验。而 ShinkaEvolve（Lange et al. 2025³⁸）引入了三个新组件来提升 LLM 的采样效率：

• 通过设计父代采样来平衡表现排名与后代数量，让探索更省样本。
• 基于 embedding 余弦相似度做代码新颖性拒绝采样，丢掉和现有种群太像的候选。
• 在一个 meta-scratchpad 里识别成功解中的好模式，用来指导未来的变异。

与上面这些聚焦于改进解的方法不同，Darwin Gödel Machine（DGM；Zhang et al. 2025³⁹）明确瞄准的是用一个基于 LLM 的 coding agent 去演化一个可编辑的 harness 代码仓库。准确地说，这个 agent 被允许修改自己的 harness。后续工作 Hyperagents（Zhang et al. 2026⁴⁰）引入了一个 meta-agent 来控制如何修改已有的任务 agent 以创造新的。

1. 从池子里的一个 coding agent 开始。
2. 每轮迭代中，按与表现成正比、与已有子代数量成反比的概率挑一个父代，对它做修改并分叉出新的 agent。
3. 被选中的父 agent 检查自己的 benchmark 评估日志，然后对自己的 harness 代码库提出改进，生成一个新版本的 coding agent。代码编辑用两个基础工具实现：（1）bash（参数：<bash_command>）；（2）editor（参数：view/create/edit <file_path>）。
4. 评估新的 coding agent，只有表现足够高的才被加回池子。
5. 重复步骤 2-4，直到触发某个停止条件。

DGM 是固定模型下的 harness 演化。在以 Claude 3.5 Sonnet 为基础 LLM、初始 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 的实验里有几个混淆的设定选择，让结果不太好解读。比如 task-specific agent 比 Meta-Agent 和 Feedback-Agent 用的模型弱得多（gpt-oss-120b 对 Claude Sonnet 4.6），而且基线太弱，没法和相关方法干净地相互参照。我认为这个方向有意思，但证据还是暂定的。此外还有很多挑战悬而未决，比如训练稳定性和 Goodhart 效应。

Continual Harness（Karten et al. 2026⁴²）在长程游戏场景下做了实验，一边更新 harness，一边通过蒸馏一个强教师模型在低回报轨迹上的标注来共同训练策略模型。

未来的挑战

AI Scientist 这条线的工作有力地证明了，一个专家设计的 harness 能协调 auto-research 回路的相当一部分，实验形式是写研究论文。但产出论文并不等于科学发现。一个系统可以写出一份看起来站得住的稿件，同时却存在编造的引用、实现漂移、或者很弱的实验结果。

Trehan & Chopra (2026)⁴³ 测试了 LLM 能否在极少 scaffolding 和基础工具（即 read_file、write_file、llm_search、list_files）的条件下，从一个研究想法走到一篇论文。每个想法都有一个专属工作区，agent 可以在里面生成和读取文档作为上下文的一部分。他们在三个领域（world model、多智能体 RL、AI 安全与对齐）做实验，每个领域包含 45-50 篇高质量种子文档来启发新想法。只有四个想法被人类专家选中跑完整流程，而只有一个被完整执行成了论文。他们在实验里观察到六种反复出现的失败模式：

• 偏向训练数据里的默认值：用老的库、过时的命令、标准格式，或者做出并非基于实际仓库或数据集的假设。
• 执行压力下的实现漂移：当实现变得技术上很复杂时，模型可能转向一个常见的更简单方案，而不是原本提出的方法。
• 记忆与上下文退化：长程项目会丢掉关键细节，除非日志被写成持久化的 artifact。
• 过度乐观：尽管实验结果嘈杂或失败，模型仍宣称成功。Bubeck et al. (2025)⁴⁴ 观察到类似的「p-hacking 与 eureka-ing」模式，即模型会引入「数值胶带」，在信号还只是噪声时就宣布胜利。
• 领域智能不足：模型缺少默会的手艺知识，比如预判实现复杂度、判断一个实验结果是否合理、或者知道哪些基线才重要。
• 科学品味薄弱：实验也许能跑通，却回答不了对的问题。

在通往完整 RSI 的路上，研究者已经取得了真实的进展，但还有几个瓶颈。

1. 评估器又弱又模糊。 很多研究论断没有快速而精确的 verifier，很多真实世界任务也是如此。当前的自我改进回路在评估指标可测量、客观的任务上效果最好，就像 RL 起作用的方式一样⁴⁵。

研究品味、新颖性和长期科学价值要难衡量得多。比如研究品味往往混合了问题的框定方式、实验设计，以及关于「哪些令人意外的结果值得追下去、哪些失败案例值得重试」的判断。

2. 上下文与记忆的生命周期。 随着 AI agent 变得更自主、更独立，记忆会不断增长。一个有用的 harness 需要管理上下文和记忆，来弥补长上下文生成上的既有局限，同时最大化长程任务的成功率。既然人类能够终生维持记忆，我看到一个类比：context engineering 将会、也应该成为智能的核心部分，而不是停留在软件系统层。

3. 负面结果。 研究者被激励去发表成功的结果，因此文献偏向成功。在海量数据（至少目前主要还是人类创造的，哈）上训练出来的 LLM，可能不擅长判断何时该放弃一个假设、报告一个负面结果、甚至承认一次失败，因为数据里成功与失败的案例本就不平衡。一个研究 harness 应该让失败的尝试容易被保留下来，因为从失败中学习是收缩任务搜索空间的最佳方式。

4. 多样性坍缩。 进化和 RL 回路倾向于利用已知的高回报模式。我们需要机制⁴⁶来防止种群坍缩成同一个解的各种变体。这对开放式研究尤其关键，因为最好的路径在当前评估器下最初可能看起来更差。

5. Reward hacking。 自我改进回路会去优化你给它的任何信号。如果奖励来自单元测试，agent 可能过拟合到测试上；如果来自一个 judge 模型，它可能学会针对这个 judge 的 reward hacking 技巧；如果来自 benchmark 分数，它可能利用 benchmark 的人为特征。

评估器和权限控制大概应该坐在演化 harness 的那个回路之外，配上 held-out 测试、轨迹审计，以及在真正重要的决策点上的人工评审——监督能被规模化和自动化到什么程度，仍然是一个开放的研究领域。

6. 长期的成功。 一个外在的优化回路作用于单次 rollout 之外的回报，这些回报我们可以在训练沙箱里模拟。

以 coding agent 为例。coding agent 已经提升了软件工程的日常生产力，但很多优化目标仍然太短期。它常常能完成手头的任务，但如何保护一个由成百上千工程师共同维护的仓库的长期健康，就没那么明显了。标准的沙箱式 RLVR 训练很少能捕捉到可维护性、所有权边界、迁移成本、向后兼容性，或者未来的调试负担。

7. 人的角色。 人类应该向上移动到栈的更高层，而不是被从 loop 中移除，意思是人应该在正确的时机、正确的抽象层级上提供监督，我们的系统设计应该考虑何时、以何种方式建立这样的 interface。

上面列出的很多挑战都需要人类的反馈和引导。毕竟，我们是在为人类更好的未来建造这项技术，而不是反过来。

引用

请这样引用这篇文章：

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

或者使用 BibTeX：

1
2
3
4
5
6
7
8

@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/"
}

附录：一些有用的 benchmark

• PaperBench⁴⁷：从零复现 20 篇 ICML 2024 Spotlight 和 Oral 论文，包括理解论文贡献、开发代码库、并成功执行实验。
  • 每个复现任务都被分解成更小的、可单独评分的子任务。
  • 总共 8,316 条评分细则，与论文作者共同制定。
  • 当时最好的模型（Claude 3.5 Sonnet，约 21%）没有超过 ML 方向的博士生。
  • 包含 PaperBench、PaperBench Code-Dev（轻量版）和 JudgeEval。
• CORE-Bench⁴⁸：评估已发表研究的计算可复现性。
  • 基于计算机科学、社会科学、医学领域的 90 篇科学论文，共 270 个任务。
  • 任务涉及从提供的代码和数据中复现结果。
  • 包含多个难度层级，以及纯语言和视觉-语言两类任务。
  • 当时报告的最佳 agent（GPT-4o 与 GPT-4o-mini）在最难的任务上只达到 21% 准确率。
• ScienceAgentBench⁴⁹：评估 LLM agent 在数据驱动的科学发现上的能力。
  • 从四个学科（数学、化学、生物、地理）的 44 篇同行评审论文中抽取 102 个任务。
  • 覆盖这些领域的基础数据科学任务：数据处理、模型开发、数据分析、信息可视化。
• RE-Bench⁵⁰：在真实的 ML 研究工程环境中，把前沿 AI agent 与人类专家对比评估。
  • 7 个有挑战性的开放式 ML 研究工程环境。
  • 每个环境 =（打分函数，起始方案，参考方案）；每个都能在 8 张或更少的 H100 GPU 上运行。
  • 例子：优化一个 kernel、跑一个 scaling law 实验、修一个 embedding、为问答微调 GPT-2 等。
  • 包含 61 位不同人类专家的 71 次八小时尝试的数据。
  • 人类专家在 82% 的八小时尝试中取得了非零分数；24% 达到或超过了强参考方案。
  • 在 2 小时预算下最好的 AI agent 得分是人类的 4 倍，但人类在更长预算下的回报更好，在 8 小时和 32 小时设定下超过了 agent。
• MLE-bench⁵¹：在离线的 Kaggle 竞赛上评估 ML 工程 agent。
  • 包含从 Kaggle 精选的 75 个 ML 工程竞赛。
  • 测试训练模型、准备数据集、跑实验、以及向评分脚本提交预测。
  • 用 Kaggle 的公开排行榜作为人类基线。
  • 论文里最好的配置，o1-preview 配 AIDE scaffolding，在 16.9% 的竞赛中达到了至少 Kaggle 铜牌水平。
  • 包含资源伸缩和数据污染分析。
• KernelBench⁵²：评估生成的 GPU kernel 的正确性与速度。
  • 250 个 PyTorch 任务，用来评估 LLM 能否写出又快又对的 kernel。
  • 评估指标 fast_p = 生成的 kernel 中既正确又比基线更快的比例。