Self-Harness: Harnesses That Improve Themselves 精读

论文链接：arxiv.org/abs/2606.09498 发表时间：2026年6月8日机构：上海人工智能实验室（Shanghai Artificial Intelligence Laboratory） 通讯作者：Lei Bai、Shuyue Hu

一、论文背景

1.1 从 LLM 到 Agent：模型之外的"操作系统"

当我们谈论 AI Agent 时，一个常见的误区是：Agent = 大语言模型（LLM）。实际上，一个能干活的 Agent 远不止一个"聪明的模型"。正如一台计算机不仅需要 CPU，还需要操作系统、驱动程序和应用程序一样，LLM-based Agent 的性能由两大支柱共同决定：

模型（Model）：即底层的大语言模型（如 GPT-4、Claude、GLM-5 等），负责"思考"和推理——相当于 CPU。
Harness（操作套件）：包裹在模型外围的整套基础设施——相当于操作系统。

用一个更直观的比喻：如果说 Model 是一位能力出众的员工，那么 Harness 就是这位员工的工作环境、操作手册、工具箱、审批流程、异常处理规程的总和。

1.2 什么是 Harness？

Harness（操作套件） 是指围绕 LLM 构建的、控制其如何与环境交互的非参数化框架。它不修改模型权重，而是定义了模型观察任务、采取行动、调用工具、检查中间产物、产生最终答案的完整执行协议。具体来说，一个 Harness 通常包含：

组件	作用	举例
系统提示词（System Prompt）	定义 Agent 的身份、目标和行为准则	“你是一个在终端环境中运行的任务助手…”
工具集（Tools）	Agent 可调用的外部能力	文件读写、Shell 执行、搜索等
记忆与状态管理（Memory）	维持上下文和长期记忆	对话历史、任务状态、中间结果
验证规则（Verification）	检查 Agent 输出是否满足要求	检查文件是否存在、测试是否通过
编排逻辑（Orchestration）	控制 Agent 的执行流程	任务分解、子 Agent 调度
故障恢复（Recovery）	Agent 遇到错误时的处理策略	重试、回退、切换策略

同一个底层模型，搭配不同的 Harness，性能可以产生巨大差异。 例如，SWE-agent ¹ 和 Claude Code ² 使用相同或相近的模型，但由于 Harness 设计不同，在软件工程任务上的表现截然不同。

1.3 当前 Harness 工程的困境

当前的 Harness 设计主要依赖人类专家手工打造——工程师通过分析 Agent 的失败案例，手动修改提示词、调整工具配置、优化恢复策略。这种"人工 Harness 工程"面临三个严峻挑战：

模型多样性爆炸：不同模型（GPT-4、Claude、GLM-5、Qwen、MiniMax 等）具有截然不同的行为模式、工具使用习惯、错误类型和对提示词的敏感度。为每个模型量身定制 Harness 的工作量呈指数级增长。
模型迭代加速：大模型以月甚至周为单位快速迭代更新。一个为上一版模型精心调优的 Harness，在新模型上可能完全不适配。
失败模式隐蔽：许多 Agent 失败并非来自模型本身的推理错误，而是来自 Harness 层面的问题——Agent 可能在未验证产物的情况下就报告成功，可能反复尝试无效操作而不知道切换策略，也可能在长上下文中丢失关键信息。这些问题需要系统性的诊断和修复，而非简单的提示词微调。

核心矛盾：Harness 对 Agent 性能至关重要，但 Harness 工程严重依赖人工，且无法跟上模型多样化与快速迭代的步伐。这催生了一个关键问题——能否让 Agent 自己改进自己运行的 Harness？

二、论文定位和关联工作

2.1 Harness 改进的三种范式

Self-Harness 论文将现有的 Harness 改进工作清晰地划分为三种范式：

范式	改进者	代表工作	特点
人工 Harness 工程	人类专家	ReAct ³、SWE-agent ¹、Claude Code ²、OpenHands ⁴	专家观察失败、手动修改 Harness，效果可靠但无法规模化
外部优化（Meta-Harness）	更强的外部 Agent	Meta-Harness ⁵、Agentic Harness Engineering ⁶、ADAS ⁷	用外部模型搜索 Harness 空间，依赖更强模型且可能不匹配目标模型的失败模式
Self-Harness（本文）	目标 Agent 自身	本文	同一个模型既执行任务又改进 Harness，无需人工或外部模型

Self-Harness 处于人工工程和外部优化之间的独特位置——它不依赖人类工程师，也不需要更强的外部模型，而是让 Agent 利用自己的执行证据来驱动 Harness 的改进。

2.2 与自改进 Agent 的关系

在自改进 Agent 研究谱系中，Self-Harness 也有明确定位：

Reflexion ⁸：Agent 通过语言反馈存储经验教训，用于后续尝试。改进的是响应策略（记忆），而非 Harness 本身。
STOP ⁹：研究代码生成中的递归自我改进。改进的是生成的程序，而非运行框架。
Agentic Context Engineering ¹⁰：演化后续模型调用的上下文。改进的是上下文，而非系统性的执行协议。
Gödel Agent / Darwin Gödel Machine ¹¹ ¹²：追求更广泛的自进化能力。Self-Harness 聚焦于一个更窄但更可控的设定。

Self-Harness 的独特之处在于：它研究的是同一个固定模型，在当前 Harness 下运行，能否对自己运行的 Harness 提出有边界的候选修改。改进的对象不是记忆、不是上下文、不是生成的程序，而是控制 Agent 行为的 Harness 状态本身。

2.3 与 Meta-Harness 和 AHE 的核心区别

值得特别说明的是 Self-Harness 与两个最密切相关工作的区别：

Meta-Harness ⁵（斯坦福 & MIT，2026）：使用外部更强的 Agent 来优化目标 Agent 的 Harness。关键限制是需要一个能力更强的外部模型，这在前沿模型场景下可能不可用或成本高昂。
Agentic Harness Engineering (AHE) ⁶（复旦 & 北大，2026）：通过可观测性驱动的闭环自动演化编码 Agent 的 Harness。同样使用了外部 Evolve Agent 来提出改进。

Self-Harness 的核心差异：目标 Agent 自己就是改进者。它用自己的执行轨迹作为证据，自己提出 Harness 修改，自己验证效果。这种"自我审计、自我提案、自我验证"的闭环，消除了对外部更强模型的依赖。

三、问题定义

3.1 核心问题的抽象

论文面临的核心挑战可以这样表述：

在排除模型能力变化和评估标准变化的前提下，能否仅通过修改 Agent 的非参数化 Harness（操作套件），让同一个模型获得系统性、可泛化的性能提升？

这里的关键约束条件是：

模型固定：不修改模型权重，不更换模型
评估器固定：评判标准不变
基准环境固定：任务和验证方式不变
唯一变量：Harness（提示词、工具策略、恢复规则、编排逻辑等）

3.2 形式化定义

论文将问题形式化为一个 Harness 状态的迭代演化过程：

给定一个固定模型 $M$ 和初始 Harness $h_0$，目标是通过一系列有边界的编辑 $\Delta_0, \Delta_1, \ldots, \Delta_{T-1}$，产生一个 Harness 谱系 $h_0 \to h_1 \to \ldots \to h_T$，使得最终 Harness $h_T$ 在未见任务上的性能优于 $h_0$。

每一次编辑 $\Delta_j$ 将当前 Harness $h_t$ 映射为候选 Harness $h_t^{(j)} = \Delta_j(h_t)$。编辑必须满足：

有界性：只修改 Harness 的声明式可编辑面，不替换整体控制架构
证据驱动：每条修改必须追溯到具体的失败模式证据
非退化性：通过回归测试验证——至少在一个评估分片上改善，且不在任何分片上退化

3.3 为什么这个问题很难？

Self-Harness 面临的技术挑战是多方面的：

自我诊断悖论：Agent 需要识别自己的弱点，但一个经常犯某种错误的模型，能否准确识别和描述这种错误？
避免"自我合理化"：模型可能提出看似合理但实际无效的修改，需要外部验证机制来防止自我欺骗。
泛化 vs 过拟合：Harness 修改不应仅仅"记住"特定任务的答案，而应捕获可复用的执行模式改进。
修改的粒度控制：修改太小可能无效，修改太大可能引入新问题。如何控制每次修改的范围？

四、问题解法

4.1 整体框架：三阶段闭环

Self-Harness 将 Harness 改进设计为一个迭代循环，每轮包含三个阶段：弱点挖掘 → Harness 提案 → 提案验证。整个过程可以用一个形象的比喻来理解：

想象一位运动员（模型）在教练系统（评估系统）的监控下训练：

弱点挖掘：教练分析训练录像（执行轨迹），找出反复出现的技术缺陷（失败模式）
Harness 提案：运动员根据自己的问题，提出针对性的训练计划修改方案（Harness 编辑）
提案验证：通过比赛（回归测试）验证修改是否真的有效，只有确实有效且不引入新问题的修改才会被采纳

初始 Harness h₀
    │
    ▼
┌─────────────────────────────────┐
│  弱点挖掘 (Weakness Mining)      │
│  - 运行任务收集执行轨迹          │
│  - 聚类失败模式                  │
│  - 生成结构化证据包              │
└─────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────┐
│  Harness 提案 (Harness Proposal) │
│  - 同一模型作为"提议者"          │
│  - 生成 K 个多样化候选修改       │
│  - 每个修改绑定特定失败模式      │
└─────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────┐
│  提案验证 (Proposal Validation)  │
│  - 在 held-in + held-out 上测试  │
│  - 保守的接受规则                │
│  - 通过的修改合并到新 Harness    │
└─────────────────────────────────┘
    │
    ▼
  更新后的 Harness h_{t+1}
    │
    └──→ 进入下一轮迭代

4.2 阶段一：弱点挖掘（Weakness Mining）

目标：将 Agent 的行为失败转化为结构化的 Harness 修改证据。

具体流程：

执行任务：用当前 Harness $h_t$ 在固定模型 $M$ 上运行一组 held-in 任务 $D_{in}$，收集执行轨迹。每个任务产生一个记录 $r_i = (x_i, \tau_i, y_i, z_i)$，其中 $x_i$ 是任务、$\tau_i$ 是轨迹、$y_i$ 是输出、$z_i$ 是评估结果（通过/失败）。
筛选失败案例：提取所有失败的记录 $F_t = \{r_i \in R_t | z_i = \text{fail}\}$。
失败签名归因：对每个失败案例，提取一个三元组失败签名 $\phi(r_i) = (c_i, q_i, m_i)$：
- $c_i$：验证器层面的终局原因（如：缺失产物、超时、断言失败）
- $q_i$：Agent 行为对该失败的因果贡献
- $m_i$：暴露出的可复用行为机制
确定性聚类：按失败签名完全一致进行聚类。两个失败案例被归为一组，当且仅当它们在验证器拒绝的原因、Agent 行为的贡献方式、以及涉及的可复用机制上都相同。
生成证据包：为每个聚类构建结构化的失败模式报告，包含聚类大小、代表性实例、共享的轨迹症状、验证器证据和推断的行为机制。

关键设计思想：这一阶段的目标不是发现轨迹之间的语义相似性，而是聚合那些可能需要相同 Harness 层面干预的失败。论文特别强调将"表层症状"与"可复用的失败机制"区分开来——两个任务可能都因为超时失败，但如果一个是由于无意义的工具循环导致，另一个是因为等待长时间下载导致，它们需要完全不同的 Harness 修改。

4.3 阶段二：Harness 提案（Harness Proposal）

目标：基于证据包，生成多个多样化且有针对性的候选 Harness 修改。

关键设计——“提议者"就是 Agent 自身：提案阶段不是由外部优化器执行，而是调用同一个固定模型 $M$，在当前 Harness $h_t$ 下以"提议者"角色运行。它接收的输入包括：

当前 Harness 的可编辑面
验证器驱动的失败模式
应保留的成功行为记录
之前尝试过的编辑历史

并行提案生成：系统并行生成 $K$ 个相互独立的提案束 $P_t = \{(\Delta_j, a_j)\}_{j=1}^{K}$，其中：

$\Delta_j$：将当前 Harness 映射为候选 Harness 的编辑
$a_j$：审计记录，包含目标失败模式、编辑的 Harness 表面、预期行为效果和回归风险

约束条件：

多样性（跨提案）：不同提案应针对不同的失败机制、选择不同的 Harness 表面、或表达不同的改进假设
最小性（提案内）：每个编辑只修改解决其目标机制所需的面，保留无关行为，避免大面积重写
可寻址性：不是所有失败聚类都意味着有用的 Harness 修改——有些反映的是任务难度、不稳定结果或模型能力极限。只有被证据充分支持且可能通过 Harness 层面窄幅修改来缓解的模式才被选为目标

4.4 阶段三：提案验证（Proposal Validation）

目标：通过回归测试确保只接受真正有效且不引入退化的修改。

验证流程：

对每个候选编辑 $\Delta_j$，构建候选 Harness $h_t^{(j)} = \Delta_j(h_t)$
在 held-in 分片 $D_{in}$ 和 held-out 分片 $D_{ho}$ 上分别评估当前 Harness 和候选 Harness
计算分片级别的改善量：
- $\Delta_{in}^{(j)} = P_{in}(h_t^{(j)}) - P_{in}(h_t)$
- $\Delta_{ho}^{(j)} = P_{ho}(h_t^{(j)}) - P_{ho}(h_t)$

保守的接受规则：

$$\Delta_{in}^{(j)} \geq 0 \text{ 且 } \Delta_{ho}^{(j)} \geq 0 \text{ 且 } \max(\Delta_{in}^{(j)}, \Delta_{ho}^{(j)}) > 0$$

翻译成白话：一个修改被接受，当且仅当它在至少一个分片上有改善，且在任何分片上都没有退化。 如果一个修改提升了 held-in 的成绩但损害了 held-out，即使总分增加也会被拒绝。

合并与推进：通过验证的候选编辑被合并到下一个 Harness 版本 $h_{t+1}$；被拒绝的候选只是记录日志，不改变活跃 Harness。

4.5 实验结果

4.5.1 实验设置

设置项	详情
基准	Terminal-Bench-2.0 ¹³：89 个容器化终端任务的 Agent 评测基准，使用确定性验证器评判
评测子集	64 个任务（排除依赖不稳定外部资源或需要多模态输入的任务）
初始 Harness	基于 DeepAgent SDK ¹⁴ 的最小化配置：仅含基本系统提示词和文件系统/Shell 工具
测试模型	MiniMax M2.5、Qwen3.5-35B-A3B、GLM-5（来自三个不同模型家族）
控制变量	模型、评估器、工具集、预算、基准环境全部固定，仅 Harness 允许变化

4.5.2 主要结果

模型	分片	初始 Harness	Self-Harness	绝对提升	相对提升
MiniMax M2.5	held-in	43.0%	50.0%	+7.0%	+16%
	held-out	40.5%	61.9%	+21.4%	+53%
Qwen3.5-35B-A3B	held-in	15.1%	36.0%	+20.9%	+138%
	held-out	23.8%	38.1%	+14.3%	+60%
GLM-5	held-in	47.7%	57.0%	+9.3%	+20%
	held-out	42.9%	57.1%	+14.2%	+33%

核心发现：三个不同家族的模型全部获得了显著提升。held-out 任务（从未向提议者暴露的任务）上的大幅改善证明，Self-Harness 捕获的是可泛化的执行模式改进，而非对评测集的过拟合。

4.5.3 模型特异性的验证——最重要的定性发现

Self-Harness 为三个模型生成的 Harness 修改截然不同，完美对应了每个模型的独特失败模式：

MiniMax M2.5 的修改方向：

✅ 推动更早创建所需的输出文件（“先产出再完善"策略）
✅ 更仔细地处理结构化工具输出（避免 Schema 格式错误）
✅ 在非生产性工具循环耗尽预算之前主动打断

Qwen3.5-35B-A3B 的修改方向：

✅ 运行命令前检查依赖是否就绪
✅ 避免重复执行已失败的相同命令
✅ 打断无限探索循环
✅ 工具错误后中间件保护：确保所需产物仍然存在

GLM-5 的修改方向：

✅ 跨 Shell 命令保持环境变量和路径设置持久化
✅ 更强地从探索阶段转向实现和测试阶段的压力
✅ 验证已安装工具的可访问性

这证明了 Self-Harness 的核心价值主张：最优 Harness 不是通用的，而是模型特定的。同一个初始 Harness，经过 Self-Harness 循环后，为不同模型演化出了针对性的改进方案。

4.5.4 超越提示词的结构性改进

一个值得强调的发现是，Self-Harness 的修改远不止于添加几条指令：

子 Agent 式任务分解：为 Qwen3.5 引入了子 Agent 机制来确保产物交付
中间件创建：添加了工具错误触发的系统提示词重定向
运行时控制策略：启用了工具消息总数限制，防止无限循环
验证阶段约束：添加了从探索到实现的强制转换机制

这表明 Self-Harness 将 Harness 设计视为软件工程而非提示词装饰——修改涉及架构层面的机制，而不仅仅是文本层面的措辞。

五、必要知识反推

假设让一个完全没有相关知识的人来完成这项工作，他必须掌握哪些信息和知识？

5.1 领域知识层

LLM Agent 的架构认知：必须理解 Agent 不是裸模型，而是"模型 + Harness"的组合体。只有认识到 Harness 独立于模型参数并显著影响性能，才会将改进 Harness 作为研究方向。
Harness 的可编辑面概念：必须知道 Harness 包含哪些可修改的组件（提示词、工具、记忆、验证规则、编排逻辑、恢复策略），以及这些组件如何影响 Agent 行为。这决定了提案阶段的搜索空间。
模型行为差异性：必须了解不同 LLM 具有不同的行为模式、错误类型和工具使用习惯。这一认知是驱动"模型特异性 Harness"这一核心假设的基石。

5.2 方法论知识层

执行轨迹分析：必须理解如何从 Agent 的执行轨迹中提取有意义的信息——不仅要看到"任务失败了”，还要理解"为什么失败"以及"失败的模式是否重复出现”。
失败归因与聚类：必须掌握将表层失败症状追溯到深层行为机制的方法。论文的三元组失败签名（验证器原因、因果贡献、行为机制）是一个精巧的归因框架。
受控实验设计：必须理解 held-in / held-out 分片设计的目的——held-in 用于提供改进证据，held-out 用于回归测试，防止过拟合。这种实验设计范式来自机器学习中经典的训练/测试分离思想。
保守验证原则：必须理解"至少一个分片改善且无分片退化"这一保守接受规则的必要性——它防止了看似改进实则退化的修改被接受。

5.3 系统设计知识层

并行探索与最小约束的平衡：必须理解为什么提案需要并行生成（探索多样性）且每个提案需保持最小（控制爆炸）。这来自搜索算法中的 exploration-exploitation 平衡思想。
证据驱动的闭环设计：必须理解整个循环的核心设计原则——每一步都必须基于可观测的行为证据，而非假设或直觉。修改必须追溯到具体失败模式，验证必须基于可度量的性能变化。
Harness 作为软件工程对象：必须将 Harness 视为一个可版本化、可审计、可回滚的软件工程对象，而非一个静态的文本文件。这催生了 Harness 谱系（lineage）、审计记录和回归测试等设计。

5.4 知识融合路径

将这些知识融合完成 Self-Harness 的路径是：

认知层（理解 Agent = Model + Harness，Harness 独立影响性能）→ 诊断层（掌握从轨迹中提取失败模式的方法）→ 设计层（构建证据驱动的闭环，平衡探索与约束）→ 验证层（建立保守的回归测试规则，确保修改的可泛化性）→ 工程层（将 Harness 改进视为有版本、可审计的软件工程流程）

六、论文中可以提取的通用性灵感

灵感一：自我改进的正确对象是"壳"而非"核"

Self-Harness 选择改进 Harness（壳）而非模型权重（核），这一思路在许多领域都有启发：

在个人成长中，改变"工作方法和流程"往往比改变"天赋能力"更可行、更高效
在组织管理中，优化"流程和制度"通常比更换"人员"更实际
在软件工程中，优化"架构和配置"比"重写核心算法"风险更低

通用原则：当直接改进核心能力成本过高或不可行时，改进包裹核心的外层框架可能是一条更高效的路径。

灵感二：保守验证是自改进系统的生命线

论文的保守接受规则（“至少一个维度改善且无维度退化”）虽然看起来简单，但揭示了一个深刻的设计原则：自我改进系统中最危险的敌人不是"没有改进"，而是"虚假的改进"。 一个看似提升了总成绩但实际损害了某些重要方面的修改，比没有修改更糟糕。

这一原则可以推广到：

任何自动化决策系统都需要"安全阀"——不能只看收益，还要检查副作用
在 A/B 测试中，不能只看整体指标，还要检查关键子指标的退化情况
在政策制定中，需要确保新政策不会在改善一个群体的同时损害另一个群体

灵感三：特异性优于通用性——“量体裁衣"的力量

Self-Harness 最重要的定性发现是为不同模型生成了截然不同的改进方案。这不是偶然的——系统设计本身就鼓励特异性（每个提案绑定特定的失败模式）。

通用原则：在复杂系统中，通用方案的上限往往低于针对性方案。与其寻找"万能药”，不如建立一套能快速生成"特效药"的系统。关键挑战不在于解决方案本身，而在于诊断问题的准确性。

灵感四：将失败视为结构化数据而非偶然事件

Self-Harness 对失败案例的处理方式非常值得学习——不是将每次失败视为孤立的意外，而是通过聚类和归因将其转化为结构化的改进证据。

这一思路可以推广到：

软件开发中的 Bug 分类和根因分析
产品迭代中的用户反馈聚类
个人学习中的错题归纳
医学诊断中的症状模式识别

通用原则：失败的价值不在于它告诉你"什么错了"，而在于当你将足够多的失败聚合在一起时，它们能揭示出单个案例无法显现的系统性模式。

灵感五：“提议-验证"分离——审计者与执行者角色的切换

Self-Harness 让同一个模型在"任务执行者"和"Harness 提议者"之间切换角色，但将验证权交给了独立的评估系统。这种"提议-验证分离"是一个经典的系统设计模式：

在代码审查中，开发者提议修改，但由独立的审查者批准
在科研中，研究者提出假设，但由独立的实验验证
在法律中，检察官提起诉讼，但由独立的法庭裁决

通用原则：自我改进系统中，“提出改进建议"和"验证改进效果"应该由不同的机制负责。自我审计容易陷入自我合理化，需要独立的外部验证来校准。

灵感六：最小化编辑的策略——小步快跑胜过大步跃进

Self-Harness 要求每个编辑只修改解决特定问题所需的最小范围，避免大面积重写。这种"最小化编辑"策略看似保守，实则是确保可审计性和可回滚性的关键。

通用原则：在不确定环境中进行迭代改进时，每次只做一个小的、可验证的改动，比一次性做大的、难以归因的改动更安全、更高效。这一原则与敏捷开发中的小步快跑、科学实验中的控制变量法一脉相承。

灵感七：从"造物者"到"被造物者”——自我进化的哲学

论文引用了柏格森在《创造进化论》中的名言：“对于一个有意识的存在来说，存在就是变化，变化就是成熟，成熟就是不断地创造自我。“Self-Harness 将这一哲学思想转化为技术实践——一个系统不应仅仅被其框架塑造，还应参与重塑自身的框架。

这一思想启示我们：真正强大的系统不是那些被完美设计的系统，而是那些能够持续重新设计自己的系统。 无论是在 AI、组织管理还是个人发展中，构建"自我进化能力"比追求"初始最优状态"更具长远价值。

七、总结与展望

Self-Harness 证明了一个令人振奋的结论：一个固定的 LLM，无需人类工程师、无需更强的外部模型，仅凭分析自己的失败轨迹和提出有针对性的 Harness 修改，就能实现显著的性能提升。

这项工作的核心贡献不仅是技术层面的——它提出了一种新的 Agent 工程范式：Harness 的演进应被当作一个可记录、可测试、可回滚的软件工程过程。在这个范式下，人类的价值工作从"手动调优提示词"转向"构建高质量的评估环境”——干净的任务定义、可靠的验证器、有代表性的轨迹、回归测试套件。

当然，Self-Harness 也有明确的局限：

基准范围较窄：仅在终端软件任务上验证，不确定能否迁移到成功标准模糊的领域
非递归自改进：Agent 改变的是 Harness 而非模型权重，能力上限仍受制于模型本身
过拟合风险：任何自改进循环都可能学习评估器的形状而非真正提升能力

但它开辟的方向——让 Agent 参与塑造自己的运行环境——无疑是 AI Agent 系统设计中一个值得深入探索的重要方向。

参考文献

Yang et al., “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering,” 2024. arxiv.org/abs/2405.15793 ↩︎ ↩︎
Liu et al., “Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems,” 2026. arxiv.org/abs/2604.14228 ↩︎ ↩︎
Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” 2023. arxiv.org/abs/2210.03629 ↩︎
Wang et al., “OpenHands: An Open Platform for AI Software Developers as Generalist Agents,” ICLR 2025. ↩︎
Lee et al., “Meta-Harness: End-to-End Optimization of Model Harnesses,” 2026. arxiv.org/abs/2603.28052 ↩︎ ↩︎
Lin et al., “Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses,” 2026. arxiv.org/abs/2604.25850 ↩︎ ↩︎
Hu et al., “Automated Design of Agentic Systems,” 2025. arxiv.org/abs/2408.08435 ↩︎
Shinn et al., “Reflexion: Language Agents with Verbal Reinforcement Learning,” 2023. arxiv.org/abs/2303.11366 ↩︎
Zelikman et al., “Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation,” 2024. arxiv.org/abs/2310.02304 ↩︎
Zhang et al., “Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models,” ICLR 2026. arxiv.org/abs/2510.04618 ↩︎
Yin et al., “Gödel Agent: A Self-Referential Agent Framework for Recursively Self-Improvement,” ACL 2025. ↩︎
Zhang et al., “Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents,” 2025. arxiv.org/abs/2505.22954 ↩︎
Merrill et al., “Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces,” 2026. arxiv.org/abs/2601.11868 ↩︎
LangChain, “DeepAgents,” 2026. github.com/langchain-ai/deepagents ↩︎

一、论文背景#

1.1 从 LLM 到 Agent：模型之外的"操作系统"#

1.2 什么是 Harness？#

1.3 当前 Harness 工程的困境#

二、论文定位和关联工作#

2.1 Harness 改进的三种范式#

2.2 与自改进 Agent 的关系#

2.3 与 Meta-Harness 和 AHE 的核心区别#

三、问题定义#

3.1 核心问题的抽象#

3.2 形式化定义#

3.3 为什么这个问题很难？#

四、问题解法#

4.1 整体框架：三阶段闭环#

4.2 阶段一：弱点挖掘（Weakness Mining）#

4.3 阶段二：Harness 提案（Harness Proposal）#

4.4 阶段三：提案验证（Proposal Validation）#

4.5 实验结果#

4.5.1 实验设置#

4.5.2 主要结果#

4.5.3 模型特异性的验证——最重要的定性发现#

4.5.4 超越提示词的结构性改进#

五、必要知识反推#

5.1 领域知识层#

5.2 方法论知识层#

5.3 系统设计知识层#

5.4 知识融合路径#

六、论文中可以提取的通用性灵感#

灵感一：自我改进的正确对象是"壳"而非"核"#

灵感二：保守验证是自改进系统的生命线#

灵感三：特异性优于通用性——“量体裁衣"的力量#

灵感四：将失败视为结构化数据而非偶然事件#

灵感五：“提议-验证"分离——审计者与执行者角色的切换#

灵感六：最小化编辑的策略——小步快跑胜过大步跃进#

灵感七：从"造物者"到"被造物者”——自我进化的哲学#

七、总结与展望#

参考文献#