什么是 Harness 工程？从 AI Agent 到递归自我改进的完整路径

递归自我改进（recursive self-improvement，RSI）的概念可以追溯到 I. J. Good（1965）[1]。他将“超智能机器”定义为一种能够在所有智力活动上超越人类，并设计出更好的机器来改进自身的系统。Yudkowsky（2008）[2] 用“递归自我改进”描述了一种特定的反馈循环：AI 利用当前的智能，改进产生这种智能的认知机器。

在现代 AI 中，这种反馈循环可能表现为模型直接重写自身权重；更广义地说，也可能表现为模型改进训练流水线和部署系统，进而让后继模型在具有经济价值的任务上获得更好的性能。前沿实验室的 AI 研究开发速度已经显著加快（Anthropic[3]；OpenAI[4]）。

我特意提到“部署系统”，因为原始模型与真实世界上下文之间的那一层，似乎和模型自身的智能同样重要（也就是预训练之后紧接着进行的评测）。Harness 是 AI 部署的重要组成部分，Claude Code 和 Codex 等成功的编码 Agent 产品就是例子。Harness 是围绕基础模型构建的系统：它编排执行过程，决定模型如何思考和规划，调用工具并采取行动，感知和管理上下文，存储产物，以及评估结果。

本文聚焦于 Harness 工程研究，以及它如何促成 RSI。近期大量关于自动研究、自我改进 Agent 和进化式程序搜索的工作，都可以围绕这个问题来组织。模型自博弈、合成数据、测试时训练，以及持续学习这一更广泛的主题，也符合 RSI 的愿景（例如 Yuan 等人，2024[5]、Chen 等人，2024[6]、Zhao 等人，2025[7]、Choi 等人，2026[8]），但它们不是本文的重点。

与早期的 Agent 框架[9]——“Agent = LLM + memory + tools + planning + action”——相比，Harness 工程还加入了工作流设计（例如循环工程）、评估、权限控制和持久状态管理。它已经不只是提示词模板，而更接近运行时与软件系统设计：模型如何观察、行动、记忆、自检和改进。

设计应当有意保持简单、通用，以便实现泛化；同时可以借鉴已有的软件工程实践，利用预训练中获得的知识。操作系统与 Harness 之间也存在很强的类比。和操作系统类似，Harness 应封装复杂逻辑，同时保持简单的接口。配置、工具接口以及其他协议也可能逐步在行业内标准化。

模式 1：工作流自动化

定义一个让模型能够运行、测试和迭代的工作流，是实现自动化的关键设计。Karpathy 的 autoresearch 仓库[10] 是构建这类工作流的清晰例子。常见工作流遵循一个面向目标的循环：规划、执行、观察/测试、改进，再次执行，直到目标达成。这个过程也可以主动向用户请求澄清，例如确认任务规格或执行偏好。

简化的 Codex Agent 循环：Agent 调用工具，而工具响应会影响模型下一次生成。（图片来源：OpenAI Codex Agent 文章[11]）

工作流图还强调，模型应当通过 Agent 运行时分析自己的轨迹和失败案例，并据此迭代进展，而不是依赖静态提示词模板。

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

长时域 Agent 系统中反复出现的一种模式，是对丰富状态和产物进行简单控制。Harness 应把持久状态保存在文件中，让上下文承担更适合它的工作。长时域 Agent 运行过程中，实验日志、代码差异、论文摘要、错误追踪和过去的运行轨迹，往往会增长到远超模型训练所适应的上下文窗口的长度。

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

模式 3：子 Agent 与后端任务

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

关键设计选择是让并行过程显式且可检查。如果子 Agent 的输出只存在于临时聊天上下文中，它们很快就会过时并隐藏起来。如果输出被保存为文件、日志和状态记录，模型就能在中断后恢复，并根据自己的执行历史进行推理。

案例研究：编码 Agent Harness

Claude Code、Codex、OpenCode 以及 Cursor 风格 Agent 的主流编码 Agent 核心接口已经趋于稳定。它们通常采用类似下面的循环：

借助一组工具，编码 Agent 能够在给定仓库中开发和调试问题，就像人类开发者借助 IDE 工作一样。

（这不是完整列表，仅用于演示。感兴趣的话，可以阅读这篇文章[12]。）

Harness 层与核心智能？

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

1. Harness 工程会朝着元方法论的方向发展，也就是改进“如何得到更好答案”的机器，而不只是改进答案本身。Harness 系统自身会成为优化目标，启发式规则减少，通用机制增加。
2. 成熟的 Harness 反过来会支持模型自我改进循环中的自动研究；更聪明的模型则会帮助 Harness 避免过度工程化，让整个系统保持可持续。

最终，许多 Harness 改进可能会被内化到核心模型行为中，但与外部上下文和工具的接口应当保留下来。提示词工程[13] 已经呈现出较弱版本的这一模式：随着指令微调和模型推理能力提升，手工提示技巧的重要性下降了，但明确目标、约束、上下文和评估标准的需求并没有消失。

Harness 系统中被优化的对象大致经历了这样的演进：指令提示词[13] → 结构化上下文 → 工作流 → Harness 代码 → 优化器代码。随着模型变得更智能、更强大，我们会转向更复杂的目标和更通用的方法。

上下文工程

随着 Agent 任务的时域显著拉长，把所有工具响应和模型生成内容简单追加到上下文中，很快就会失控。上下文管理是一层系统，用于为 LLM 构建更结构化、更简洁的上下文，并管理持久状态。长上下文研究无疑会继续进步，但在当前阶段，长上下文智能与上下文工程有时仍然交织在一起。

Agentic Context Engineering（ACE；Zhang 等人，2025[14]）把上下文视为不断演化的作战手册，而不是一份越来越长的提示词。它包含三个组件，用来维护一份由要点构成的上下文手册；每个要点都有标识符和描述。

1. Generator（生成器）：生成任务轨迹，并参考这些要点。
2. Reflector（反思器）：从成功和失败的轨迹中提炼洞见。
3. Curator（整理器）：用增量式、条目化的内容更新结构化上下文。

Agentic Context Engineering（ACE）框架。（图片来源：Zhang 等人，2025[14]）

为了避免迭代重写时出现上下文坍缩和简洁性偏差，ACE 的一个关键设计选择是：整理器不重写一整块提示词。它输出的是一组结构化、条目化的要点，形式为（标识符、描述）；这些要点再通过确定性逻辑合并到结构化上下文日志中。上下文条目会定期被细化和去重。

ACE 能够从运行轨迹中学习洞见，推动我们走向自管理记忆；但更新规则和整体工作流仍然是手工设计的。为了进一步走向自我改进循环，Meta Context Engineering（MCE；Ye 等人，2026[15]）把机制（如何管理上下文）与产物内容（上下文里有什么）分开，在元优化层面运行技能演化，在基础层面优化上下文。

MCE 技能  定义了上下文函数 ，并把输入  映射为上下文 ，其中：

•  是静态组件（提示词、知识库、代码库）。
•  是动态算子（搜索、选择、过滤、格式化）。

双层优化的目标，是在训练数据上给定技能  时找到最佳上下文 ；外层循环则寻找能在验证集上带来最佳性能的技能：

技能数据库记录过去技能、上下文函数和评估指标的历史 。元层 Agent 会对已有技能执行面向任务  的 Agentic crossover[16]，生成新技能：。

随后，基础层上下文工程师执行技能 ，并在当前技能的引导下，从运行反馈  中学习上下文函数：。

Meta Context Engineering（MCE）框架：元层技能演化搜索上下文管理机制，基础层优化任务上下文。（图片来源：Ye 等人，2026[15]）

MCE 没有像 ACE 那样强制规定上下文的组织启发式规则。它使用自由形式的技能存储任务最重要的知识，并让技能与技能条件化的上下文一起迭代演化。从实现角度看，上下文函数  会被实例化为专用目录中的一组文件，其中同时包含静态组件（skill.md）和动态组件（上下文与数据运行轨迹）。元层和基础层优化都在 Agentic 编码环境中执行，并使用一组标准工具：

Meta-Harness（Lee 等人，2026[17]）又向下深入了一层：被优化的对象，是决定哪些信息应当被存储、检索并呈现给模型的代码。“Meta-”这个前缀表示它是一个用于优化 Harness 的 Harness。

Meta-Harness 外层优化算法。（图片来源：Lee 等人，2026[17]）

负责创建新 Harness 的提议器本身就是一个编码 Agent，最终输出是一组位于 Pareto 前沿上的 Harness 候选方案。

• 全部执行历史都可以通过文件系统访问，因此编码 Agent 使用 grep 或 cat 等命令读取历史，而不是把所有内容一次性塞进一个提示词上下文。
• 提议的 Harness 是文件系统中的一个字典，其中包含自身的源代码、分数、运行轨迹和状态更新。
• Meta-Harness 循环会反复创建新的 Harness，只保留符合条件的方案。

Meta-Harness 的性能：左图是少量迭代的文本分类，右图是 TerminalBench-2。注意，TerminalBench-2 实验中的搜索从 Terminus-KIRA 和 Terminus-2 初始化，这两个都是很强的 Harness。（图片来源：Lee 等人，2026[17]）

重要的启示很清楚：一旦 Harness 设计成为可执行的搜索空间，强大的编码 Agent 就可以利用人类工程师所使用的同一个设计空间。

工作流设计

Harness 工程中的工作流设计，可以由领域专家手工完成。以自动研究为例，人们已经提出并测试了各种框架。AI Scientist 系统（Lu 等人，2026[18]）构建了一条流水线，用于提出研究想法、编写代码、运行实验、分析结果、撰写论文和进行同行评审。Meng 等人（2026）[19] 把可验证性作为 ScientistOne 的核心设计约束：每个主张（引用、数字、方法论和结论）都必须追溯到证据来源，并接受 Chain-of-Evidence 检查。

AI Scientist 的想法生成、实验、论文写作和评审流水线。（图片来源：Lu 等人，2026[18]）

Autodata Agent（Kulikov 等人，2026[20]）被设计成一名数据科学家，用于生成训练数据和评估数据。主 Agent 管理一个提出问题的 challenger、一个能力较弱的 solver、一个能力较强的 solver，以及一个 verifier/judge，目标是合成难度“恰到好处”的数据：强 solver 能够成功，而弱 solver 会失败。

在 Autodata 中，challenger 的提示词会根据 solver 和 verifier 的反馈迭代更新。局限在于，合成任务只用于微调弱 solver，而不是强 solver；如果循环无法迭代改进强模型，那么它更像是在生成的提示词分布上进行间接蒸馏，RSI 的味道就淡了许多。

Autodata 围绕 challenger、solver 和 verifier 角色生成合成训练数据与评估数据的 Agent 工作流设计。（图片来源：Kulikov 等人，2026[20]）

工作流的设计空间极其庞大。自然地，我们可以把工作流设计视为一个搜索问题；这样一来，就应该能够通过算法寻找优秀方案，而不只是依靠手工设计。沿着这一方向，Automated Design of Agentic Systems（ADAS；Hu 等人，2025[21]）把 Agent 设计本身形式化为一个优化问题，即“元 Agent 搜索”：元 Agent 提出新的 Agent 工作流设计。

1. 用 CoT、self-refine 等简单 Agent 初始化一个 Agent 工作流档案。
2. 让元 Agent 受到档案中已有方案的启发，用代码编程实现新的 Agent。

• 元 Agent 先生成新工作流的高层描述，再用代码实现它。
• 随后，草稿程序会经过两次 self-refine：元 Agent 先要求模型提供反馈，再要求同一个模型根据反馈改进之前生成的输出（Madaan 等人，2023[22]），以检查其新颖性。

• 评估每个新候选方案，并把成功方案加入档案。
• 重复步骤 2～3，直到达到最大迭代次数。



Automated Design of Agentic Systems（ADAS）示意图。（图片来源：Hu 等人，2025[21]）

AFlow（Zhang 等人，2025[23]）把 Agent 工作流表示为一张图：节点代表调用 LLM 的动作，边则在代码中实现逻辑操作。工作流优化依赖 MCTS[24]（蒙特卡洛树搜索）：

1. 用模板把起始工作流  初始化到树中。
2. 使用分数与均匀探索的软混合，选择一个工作流节点。
3. 根据评估性能，让 LLM 生成修改后的工作流，以扩展该节点。
4. 执行并评估新工作流。
5. 如果新工作流在  轮预算内表现出改进，就把它加回树中。
6. 重复步骤 2～5，直到 top- 平均分趋于平稳或达到预算。



AFlow 在工作流候选树上的优化过程。（图片来源：Zhang 等人，2025[23]）

AFlow 在问答、代码和数学任务上的实验显示，相比手工设计的工作流和 ADAS，它取得了不错的改进。



AFlow 与手工方法和 ADAS 的实验比较。（图片来源：Zhang 等人，2025[23]）

自我改进的 Harness

上下文工程或工作流设计，都只是 Harness 的一部分。我们需要搜索整个设计空间，把上下文管理逻辑、工作流、权限以及其他 Harness 组件放在一起优化。Meta-Harness、ADAS 和 AFlow 等工作说明，代码是定义程序和系统的通用语言。简单说，Harness 是一段代码，用来编排提示词、工具调用、子 Agent、控制流、记忆和工作流逻辑。如果 LLM 能够优化执行 Agent 的代码，它就能接触到比手写提示词大得多的设计空间。

Self-Taught Optimizer（STOP；Zelikman 等人，2023[25]）是递归脚手架改进的早期例子之一。在  时，种子改进器  接收初始解 、效用函数  和黑盒语言模型 ，返回改进后的解 ，即 。STOP 的目标并不是直接改进 ，而是改进改进器  本身。

首先，定义给定改进器函数  在下游任务集合  上的平均效用，也就是元效用：

由于改进改进器函数本身也是一个优化问题，我们可以根据  的元效用表现，通过自我改进更新递归得到 ：



Self-Taught Optimizer（STOP）算法。（图片来源：Zelikman 等人，2023[25]）

在 Zelikman 等人（2023）的实验中，改进后的改进器发现了多种策略，例如遗传算法、分解并改进各个部分、多臂提示词赌博机、模拟退火、改变温度，以及 beam/tree search。这与把 Harness 工作流表示为可优化对象的方式类似。



STOP 发现的自我改进策略示例。（图片来源：Zelikman 等人，2023[25]）

一个值得警惕的结果是：STOP 在 GPT-4 上跨迭代提升了下游任务的平均性能，但在 GPT-3.5 和 Mixtral 等较弱模型上性能下降。仅有递归结构还不够，基础模型必须具备足够的能力，才能改进这个机制。这意味着 Harness 改进能够让模型获得更好的部署效果，但智能本身仍然是核心。

较新的 Self-Harness 工作（Zhang 等人，2026[26]）依赖 LLM Agent 通过“提出—评估—接受”循环改进自身 Harness。



Self-Harness 使用“弱点挖掘、受限 Harness 提案、验证”循环来更新 Harness。（图片来源：Zhang 等人，2026[26]）

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

1. 弱点挖掘：把失败聚类为以 verifier 为依据的失败模式。
• 使用当前 Harness  在任务上进行评估，并收集执行轨迹供分析。
• 注意，两次运行在错误日志中表面上可能拥有相同的 verifier 结果，例如超时或缺少产物，但背后的因果机制不同。因此，需要记录丰富的失败信息：包括 verifier 层面的终止原因、相关 Agent 行为的因果状态，以及轨迹暴露出的抽象 Agent 机制，从而找到根因。
• Harness 提案：根据挖掘出的失败模式，提出受限的 Harness 编辑方案。
• 在  下调用同一个模型，让它充当提议器。
• 为模型提供受限的提案上下文，包括：（1）当前 Harness 可编辑的表面；（2）评估系统中由 verifier 归因的失败模式；（3）应当保留的通过行为记录；（4）此前尝试过的编辑摘要。
• Harness 编辑应优先处理反复出现、可被解决的错误模式（例如不是任务特定难度导致的问题），并用范围狭窄的改动解决它们。
• 编辑候选方案应当彼此有区别，并保持多样性。
• 提案验证：验证并合并合格编辑，创建新的 Harness 。
• 在 held-in 数据  上运行回归测试，检查弱点是否解决；在 held-out 数据  上运行回归测试，检查是否引入其他未知问题。
• 只有在 held-in 和 held-out 数据上都没有回归时，候选方案才会被接受。
• 接受的候选方案会被合并，用来更新 Harness 为 ；被拒绝的候选方案会被记录，但不会改变当前生效的 Harness。

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

这类 Self-Harness 工作也让我担心：如果允许程序编辑操作系统，抽象边界就会被打破。可编辑表面需要经过恰当设计，权限控制和安全层应当位于这个循环之外。关于奖励投机[27] 的所有挑战仍然存在。

进化式搜索

进化式搜索是一种受自然选择启发的优化方法（可以参考我之前关于进化算法的文章[28]）。它通过变异解来演化一个解群体，只保留群体中“适应度”较高的解。当（1）搜索空间很大或形状奇特；（2）很难直接通过梯度优化，但容易评估解时，进化式搜索尤其有用。Harness 搜索似乎正适合这种方法。

过去的研究已经把进化式搜索用于提示词工程。Promptbreeder（Fernando 等人，2023[29]）通过丰富的变异操作优化任务特定提示词；有意思的是，用来让 LLM 变异任务提示词的“变异提示词”本身也会通过进化得到改进。GEPA（Agrawal 等人，2025[30]）把基于反思[31] 的提示词方法与进化式搜索结合起来，针对试错轨迹进行自然语言反思，从而提出提示词更新。

Novikov 等人（2025）[32] 将 AlphaEvolve 引入为一种编码 Agent 进化式搜索系统：它保存一个候选程序池，并提示冻结的 LLM 生成用于改进的差异。当系统反复评估子程序、保留成功方案时，就会逐渐发现更好的解。



AlphaEvolve 的工作方式。（图片来源：Novikov 等人，2025[32]）

AlphaEvolve 的设计中有几个细节值得注意：

• 提示词包含父程序、结果、指令，有时还包含元信息。
• 编码 Agent 可以访问完整仓库，但需要改进的代码区域会用 # EVOLVE-BLOCK-START 和 # EVOLVE-BLOCK-END 明确标记。
• 元提示词会与指令和上下文共同演化，这一点与 LLM 建议我们演化解程序的方式类似。

消融实验展示了进化过程、提示词中的上下文、元提示词、整文件进化以及使用更强 LLM 的价值。



消融实验展示了 AlphaEvolve 中多种设计的价值。（图片来源：Novikov 等人，2025[32]）

最近的变体包括 ThetaEvolve（Wang 等人，2025[33]），它把进化式搜索与 RL 和上下文学习结合起来；另一方面，ShinkaEvolve（Lange 等人，2025[34]）引入了三个新组件，用于提高 LLM 采样效率：

• 通过设计父代采样，在性能排名和子代数量之间取得平衡，从而实现更高样本效率的探索。
• 代码新颖性拒绝采样：根据基于嵌入的余弦相似度，丢弃与现有群体过于相似的候选方案。
• 在元草稿中识别成功解中的优秀模式，为之后的变异提供指导。

与上述聚焦于解改进的方法不同，Darwin Gödel Machine（DGM；Zhang 等人，2025[35]）明确把目标放在一个可编辑 Harness 代码仓库的演化上，并由基于 LLM 的编码 Agent 执行。更准确地说，这个 Agent 被允许修改自己的 Harness。后续的 Hyperagents 工作（Zhang 等人，2026[36]）引入了一个元 Agent，用来控制如何修改已有任务 Agent，从而创建新的 Agent。

1. 从池中一个编码 Agent 开始。
2. 每次迭代选择一个父 Agent；选择概率与它的性能成正比，与它拥有的子代数量成反比。然后修改该父 Agent，并从它分支出新的 Agent。
3. 被选中的父 Agent 检查自己的基准评估日志，提出对自身 Harness 代码库的改进，生成一个新版编码 Agent。代码编辑通过两个基础工具实现：（1）bash（参数为 ）；（2）editor（参数为 view/create/edit）。
4. 评估新的编码 Agent，只有性能足够高的 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。

当候选解能够自动评估、候选适应度也容易量化时，这类方法表现良好，例如矩阵乘法、GPU kernel 优化、算法竞赛和数据中心调度。遇到评估缓慢、含义模糊或主要依赖启发式判断的领域时，它就会遇到困难。进化过程的计算效率和有效性也值得关注。

与模型权重联合优化

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

SIA（Hebbar 等人，2026[37]）是一个早期尝试，它把 Harness 改进和模型参数更新放进同一个优化循环中，设计包含三个组件：

• Meta-Agent：提出初始 Harness。
• Task-Specific Agent：执行任务。
• Feedback-Agent：根据最近的运行轨迹，决定更新 Harness 还是模型权重。



SIA 中的 Feedback-Agent 决定下一种迭代类型。（图片来源：Hebbar 等人，2026[37]）

SIA 实验中存在一些混杂因素，使结果难以解释。例如，任务特定 Agent 远弱于 Meta-Agent 和 Feedback-Agent 使用的模型（gpt-oss-120b 对比 Claude Sonnet 4.6），基线也太弱，无法与相关方法进行干净的交叉对照。我认为这个方向很有意思，但证据仍属初步。训练稳定性和 Goodhart 效应等许多挑战仍然悬而未决。

未来挑战

AI Scientist 系列工作有力地证明了：专家设计的 Harness 可以协调自动研究循环中的很大一部分，并以撰写研究论文的形式完成实验。但论文生产并不等同于科学发现。系统可以写出一篇看似可信的论文，同时仍然存在虚构引用、实现漂移或实验结果薄弱等问题。

Trehan 和 Chopra（2026）[38] 测试了 LLM 能否在极少脚手架和基础工具（即 read_file、write_file、llm_search、list_files）的支持下，从研究想法走到论文。每个想法都有独立工作区，Agent 可以把文档生成并读取为上下文的一部分。他们在三个领域进行了实验：世界模型、多 Agent RL、AI 安全与对齐；每个领域都有 45～50 份高质量种子文档，用来启发新想法。只有四个想法被人类专家选中，进入完整流水线；最终只有一个想法完整执行为论文。他们在实验中观察到六种反复出现的失败模式：

• 偏向训练数据默认值：使用旧库、过时命令、标准格式，或基于训练数据却没有根据实际仓库或数据集验证的假设。
• 执行压力下的实现漂移：实现变得复杂时，模型可能转向更常见、更简单的方案，而不是原先提出的方法。
• 记忆与上下文退化：长时域项目如果不把日志写成持久产物，就会丢失关键细节。
• 过度乐观：即使实验嘈杂或失败，模型仍然宣布成功。这与 Bubeck 等人（2025）[39] 观察到的“p-hacking 和 eureka-ing”模式类似：模型引入“数字胶带”，在信号仍是噪声时宣布胜利。
• 领域智能不足：模型缺少隐性的工艺知识，例如预测实现复杂度、判断实验结果是否可信，或知道哪些基线真正重要。
• 科学品味薄弱：实验可能可以运行，却没有回答正确的问题。

研究人员已经在走向完整 RSI 的道路上取得了真实进展，但仍有几个瓶颈。

1. 弱且模糊的评估器。 许多研究主张没有快速、精确的 verifier，许多现实任务也是如此。当前的自我改进循环，最适合评估指标可测量且客观的任务，这一点类似 RL 的工作方式[40]。

研究品味、新颖性和长期科学价值更难测量。例如，研究品味往往混合了问题构建、实验设计，以及判断哪些意外结果值得追踪、哪些失败案例值得重试。

2. 上下文与记忆的生命周期。 随着 AI Agent 变得更加自主和独立，记忆会不断增长。一个有用的 Harness 需要管理上下文和记忆，补足长上下文生成的现有限制，同时最大化长时域任务的成功率。既然人类能够在一生中维持记忆，我认为这里存在一个类比：上下文工程将来会、也应该成为智能的核心组成部分，而不只是停留在软件系统层。

3. 负面结果。 研究人员受到发表成功结果的激励，因此文献会偏向成功。LLM 目前主要在由人类创建的大量数据上训练（至少现在如此，哈哈），可能不擅长判断何时应当放弃假设、报告负面结果，甚至承认失败，因为训练数据中成功与失败案例并不平衡。研究 Harness 应当让失败尝试易于保存，因为从失败中学习是缩小任务搜索空间的最佳方式。

4. 多样性坍缩。 进化和 RL 循环倾向于利用已知的高奖励模式。我们需要机制[41] 防止群体坍缩为同一个解的不同变体。这对开放式研究尤其重要，因为最好的路径在当前评估器看来，起初可能反而更差。

5. 奖励投机[27]。 自我改进循环会优化它收到的任何信号。如果奖励来自单元测试，Agent 可能过拟合测试；如果奖励来自评判模型，它可能学会针对这个评判模型的奖励投机技巧；如果奖励来自基准分数，它可能利用基准中的漏洞。

评估器和权限控制可能应当位于 Harness 演化循环之外，并结合留出测试、轨迹审计以及关键决策点上的人工审核。人工监督到底能在多大程度上规模化并自动化，仍是开放的研究问题。

6. 长期成功。 外部优化循环依赖单次运行之外的奖励，而我们可以在训练沙箱中模拟这些奖励。

以编码 Agent 为例，编码 Agent 已经提高了软件工程的日常生产力，但许多优化目标仍然过于短期。它往往能完成眼前的任务，却不容易理解应当如何保护一个由数百或数千名工程师共同维护的仓库的长期健康。基于沙箱的 RLVR 风格训练，通常很难捕捉可维护性、所有权边界、迁移成本、向后兼容性或未来调试负担。

7. 人类的角色。 人类应当上移到更高的抽象层，而不是从循环中消失。人类应在恰当的时间、恰当的抽象层级提供监督；系统设计也应考虑何时、以何种方式设置这些接触点。

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

引用

本文引用格式：

Weng, Lilian. “Harness Engineering for Self-Improvement”. Lil’Log (Jul 2026).[50]

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[42]**：从零开始复现 20 篇 ICML 2024 Spotlight 和 Oral 论文，包括理解论文贡献、开发代码库，以及成功执行实验。
• 每个复现任务都会被拆分成更小、可以分别评分的任务。
• 总计 8,316 条评分标准，由论文作者共同参与制定。
• 当时最好的模型（Claude 3.5 Sonnet，约 21%）并没有超过机器学习博士。
• 包含 PaperBench、PaperBench Code-Dev（较轻量版本）和 JudgeEval。
• **CORE-Bench[43]**：评估已发表研究的计算可复现性。
• 基于计算机科学、社会科学和医学领域 90 篇论文构建 270 个任务。
• 任务要求根据提供的代码和数据复现结果。
• 包含多个难度级别，同时覆盖纯语言任务和视觉语言任务。
• 论文中报告的最佳 Agent（GPT-4o 和 GPT-4o-mini）在最难任务上的准确率也只有 21%。
• **ScienceAgentBench[44]**：评估面向数据驱动科学发现的 LLM Agent。
• 从数学、化学、生物学和地理学四个学科的 44 篇同行评审出版物中提取 102 个任务。
• 覆盖这些领域中的基础数据科学任务：数据处理、模型开发、数据分析和信息可视化。
• **RE-Bench[45]**：在真实的 ML 研究工程环境中，以人类专家为对照评估前沿 AI Agent。
• 包含 7 个具有挑战性的开放式 ML 研究工程环境。
• 每个环境由（评分函数、起始解、参考解）构成；每个环境都可以用不超过 8 张 H100 GPU 运行。
• 例子包括优化 kernel、运行 scaling law 实验、修复 embedding、微调 GPT-2 完成问答等。
• 包含 61 名不同人类专家进行的 71 次八小时尝试的数据。
• 人类专家在 82% 的八小时尝试中取得了非零分数；24% 的尝试达到或超过了强参考解。
• 在两小时预算下，最佳 AI Agent 的得分是人类的 4 倍；但人类在更长预算下的收益更好，并在八小时和 32 小时设置下超过了 Agent。
• **MLE-bench[46]**：在离线 Kaggle 竞赛上评估 ML 工程 Agent。
• 包含从 Kaggle 精选的 75 个 ML 工程竞赛。
• 测试训练模型、准备数据集、运行实验，以及向评分脚本提交预测结果。
• 使用 Kaggle 公共排行榜作为人类基线。
• 论文中的最佳设置是带 AIDE 脚手架的 o1-preview，在至少 16.9% 的竞赛中达到了 Kaggle 铜牌级别。
• 包含资源扩展和数据污染分析。
• **KernelBench[47]**：评估生成 GPU kernel 的正确性和速度。
• 使用 250 个 PyTorch 任务，评估 LLM 是否能写出快速且正确的 kernel。
• 评估指标 fast_p 表示生成的、既正确又比基线更快的 kernel 所占比例。