# AHE：让 Coding-Agent Harness 成为可观测、可回滚的自进化层

> **论文**：*Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses*  
> **作者**：Jiahang Lin, Shichun Liu, Chengjun Pan, Lizhi Lin, Shihan Dou, Zhiheng Xi, Xuanjing Huang, Hang Yan, Zhenhua Han, Tao Gui, Yu-Gang Jiang  
> **版本**：arXiv:2604.25850v4，2026-05-18；PDF 标注为 Preprint  
> **代码**：`china-qijizhifeng/agentic-harness-engineering`  
> **研究对象**：在冻结基础模型的前提下，自动演化 coding agent 的 system prompt、tools、middleware、skills、sub-agent 配置与 memory

## 阅读主线

AHE 的出发点不是“怎样让模型再自我反思一次”，而是一个更工程化的问题：同一个基础模型被放进不同的工具、执行控制、记忆和提示系统后，任务表现会显著不同；这一整套模型外部系统就是 **harness**。既然 harness 会决定模型能力能否真正落地，它就应当成为与权重训练、prompt 优化并列的独立优化层。

但是，把 prompt 优化扩展为“联合修改整个 harness”并不只是把可编辑文件变多。它同时带来三个结构性困难：可编辑组件类型异构，数百万 token 的执行轨迹中有用信号稀少，而且多个编辑同时发生后很难判断哪个编辑修好了什么、又破坏了什么。AHE 的核心论点是：这里的瓶颈主要不是演化 Agent 不够聪明，而是演化过程缺乏 **observability**。因此论文用 component、experience、decision 三种可观测性，把 harness 演化变成一系列有证据、可验证、可回滚的文件级实验。

论文最有价值的地方不只是 Terminal-Bench 2 上从 69.7% 提升到 77.0%，而是展示了一种 AI 自进化的工程范式：把可变部分外部化，把运行经验压成可追溯证据，再要求每次自修改提前写下可证伪的预测。与此同时，实验也揭示了这个闭环尚未解决的核心难点：它较会预测“这次修改可能修好谁”，却几乎不会预测“同一修改将破坏谁”。

## 1. 为什么 Harness 是模型权重之外的独立优化层

### 1.1 Harness 到底包含什么

论文把 harness 定义为包围基础模型、决定模型怎样感知环境和采取行动的一组 **模型外部、可编辑组件**。它不等同于 system prompt，也不只是工具清单，而是至少包括：

- system prompt：规定工作风格、全局规则和完成标准；
- tool description 与 tool implementation：分别决定模型怎样理解工具、工具实际上怎样执行；
- middleware：拦截或变换模型调用、工具输出、上下文和结束流程；
- skills：按需加载的可复用工作方法；
- sub-agent configuration：任务分解与隔离执行方式；
- long-term memory：跨任务累积的经验与边界案例；
- 执行与恢复机制：超时、错误处理、状态保护和验证闭环。

这些组件共同定义了 Agent 的 action/observation interface。基础模型可能“知道”怎样解决问题，但如果工具缺少必要能力、middleware 让重要警告沉入长日志、结束流程允许 Agent 删除已经验证成功的产物，模型能力仍不能转化为任务成功。

### 1.2 为什么不能把 Harness 当作附属工程

论文在 Introduction 中给出两层论证。第一，已有 coding benchmark 结果显示，在基础模型固定时，仅改变 harness 设计就会显著改变长时程任务完成率。第二，最佳 harness 往往具有模型特异性：为一个模型调好的脚手架，换模型后可能不再合适；基础模型持续更新时，外围 harness 也必须重新适配。

当前适配主要依赖人工：开发者阅读轨迹，归纳重复失败，再分别修改 prompt、tool、middleware 或 skill。这个循环的问题不是人工改不出好 harness，而是迭代速度难以跟上模型更新速度。由此产生一个独立的“能力实现差距”：基础模型的潜在能力已经提高，承载它的工作流却仍停留在上一代设计。

**论文主张**：harness engineering 是提高 coding agent 的 first-class lever，而不是部署完成后的细枝末节。AHE 因而冻结模型，只优化 harness，使性能变化尽可能归因于模型外部结构，而不是新模型、更多推理预算或训练更新。

## 2. 为什么已有自进化方法不足以解决 Harness 演化

### 2.1 现有方法通常只开放一个编辑表面

自动 Agent 优化已有多条路线：Reflexion、Self-Refine 一类方法修改单次输出或语言反馈；prompt optimizer 修改指令；ACE 把经验写进结构化 playbook；TF-GRPO 从成功和失败的工具轨迹中构造语义优势；另一些方法搜索 skill library、Agent 程序或 workflow graph。

这些方法并非无效，但大多预先限定了优化发生在哪一层。例如 ACE 可以累积自然语言策略，却不能直接把反复出现的跨步骤风险变成一个 middleware hook；TF-GRPO 可以强化成功工具序列，却不能修改工具实现以拦截危险命令。如果真正承载增益的层位于 tools、middleware 或 memory，仅优化 prompt 就发生了 **layer mismatch**。

### 2.2 联合编辑整个 Harness 的三个结构性障碍

把全部组件都交给演化 Agent 后，会出现三个相互耦合的问题。

1. **异构动作空间不透明**：prompt 是文本，tool 是描述加代码，middleware 是有生命周期的程序，skill 与 memory 又有各自加载方式。如果框架高度耦合，一个失败模式可能需要同时修改数百行配置和代码，既难编辑也难回滚。
2. **原始轨迹有体量、没有信号密度**：一次 benchmark campaign 可产生约千万 token 的工具调用、日志、模型消息和环境输出。直接把它们塞给演化 Agent，不等于提供经验；真正可操作的信息是失败根因、成功模式和同任务 passing/failing rollout 的分歧点。
3. **修改效果难归因**：一个回合可能同时改 prompt、tool 与 middleware，下一轮又有任务从失败变成功、也有任务从成功变失败。如果只保留“修改理由”，Agent 很容易事后把任何结果解释为合理，无法判断应保留、改进还是回滚。

因此论文的研究问题是：**怎样让一个 evolution agent 联合而稳定地演化 coding agent harness 的全部可编辑组件？** 这里的“稳定”不仅指平均分上升，还要求修改边界明确、结果可追溯、失败编辑能够撤销。

## 3. 设计转折：瓶颈是 Observability，而非单纯的 Agent 能力

AHE 的设计命题是：只要演化 Agent 能看到清晰的动作空间、经过组织的运行证据以及自身决策的下一轮结果，它已有足够能力找到更好的 harness。于是论文没有再训练一个专用优化器，而是把演化系统改造成三个可观测表面：

| 可观测性 | 原问题 | AHE 提供的结构化对象 | 产生的能力 |
|---|---|---|---|
| Component observability | 不知道能改什么，组件耦合且难撤销 | 七类组件固定为 workspace 中的显式文件，并由 Git 记录逻辑编辑 | 明确动作空间、文件级 diff 与 rollback |
| Experience observability | 千万 token 轨迹掩盖根因 | benchmark overview → per-task report → cleaned/raw trace 的分层证据库 | 先读结论、需要时逐层钻取原始证据 |
| Decision observability | 修改理由无法被下一轮证伪 | change manifest：证据、根因、修改、预测修复、风险任务 | 把每次编辑变成下一轮可核验的合约 |

![Figure 2：AHE 三种可观测性组成的闭环](./AHE-论文汇报.assets/ahe-pipeline.png)

**直接证据的作用边界**：Figure 2 是方法结构图，解释三种 artifact 怎样进入闭环；它本身并不证明 observability 一定优于更强的演化模型。论文真正的支持来自后续结果：三类 role agent 使用同一基础模型，AHE 仍优于只开放 prompt/playbook 的自进化基线，并且组件消融把增益定位到 tool、middleware 和 memory。

## 4. Component Observability：把联合优化变成文件级动作空间

### 4.1 NexAU 的解耦工作区

AHE 在 NexAU 框架上实现 harness (H)。七类可编辑组件位于固定挂载点：system prompt、tool description、tool implementation、middleware、skill、sub-agent configuration 和 long-term memory。组件之间尽量松耦合，例如增加 middleware 不要求同时修改 system prompt，增加 skill 不要求改 tool。

这种设计的关键不是目录整洁，而是让“失败模式 → 组件层”成为一个可选择的动作。例如：

- Agent 不理解完成标准，可能属于 prompt 或 memory；
- Agent 明知风险仍执行破坏命令，更适合在 tool implementation 做硬拦截；
- 单次命令正常、跨多步组合后出现风险，更适合 middleware 维护状态；
- 新工具已创建但未加载，则需要 tool/config 注册而非再写一段提示。

每个逻辑修改对应 workspace Git 历史中的一次 commit。于是结果变化能对应到具体文件 diff，失败修改也可在文件粒度回退。这一层解决的是“**演化 Agent 能对什么采取动作，以及动作是否可撤销**”。

### 4.2 为什么种子 Harness 必须足够弱

种子 `NexAU0` 被有意限制为一个 bash/shell execution tool：没有 middleware、skills、sub-agents 和 long-term memory，system prompt 也只有少量基本规则。如果种子本身已经针对 Terminal-Bench 2 精调，后续增益就混合了人工先验与自动演化贡献。弱种子迫使每个新增组件用 rollout 结果证明自己的价值。

但这也是实验解释的限制：AHE 证明的是“从极简 NexAU0 出发，联合演化可找到更好 harness”，不等于证明它从任意成熟生产 harness 出发都能获得同样幅度的提升。

## 5. Experience Observability：把千万 Token 轨迹变成可钻取证据

### 5.1 Agent Debugger 不只做摘要

每轮对 benchmark 中每个任务执行 (k) 次 rollout。原始轨迹可能包含数百万到约千万 token，但错误通常只来自少数关键分歧。AHE 使用 Agent Debugger，把轨迹视为可导航的文件环境：每条消息单独存放，Debugger 通过 shell 和脚本定位关键步骤，对同一 query 的 passing/failing traces 进行比较，输出每任务分析报告。

报告包含任务 pass/fail 状态、失败根因或成功模式；所有 per-task report 再聚合为 benchmark-level `overview.md`。演化 Agent 默认先读 overview，再读相关任务 detail，只有摘要不足时才下钻 cleaned trace 或 raw trace。这就是 progressive disclosure：

```text
benchmark overview（约 10K token 入口）
        ↓ 选择失败模式或任务簇
per-task analysis report
        ↓ 需要核实时
cleaned trajectory
        ↓ 摘要仍不足时
raw trace（全量可追溯证据）
```

因此，experience observability 不是用 10K token 摘要替代全部轨迹，而是让摘要成为索引，同时保留返回原始消息验证分析的路径。它解决的是“**从哪里获得可操作的根因，而不是被日志淹没**”。

### 5.2 为什么每个任务至少需要两个 Rollout

参考运行设置 (k=2)。同一任务有两个 rollout 时，0/2、1/2、2/2 不仅提供更稳定的 pass@1 估计，也让 1/2 的 partial-pass task 成为特别有价值的诊断对象：能力上限已经存在，Debugger 可以比较成功与失败轨迹的分歧点，寻找怎样把偶然成功变成稳定默认策略。

需要注意，两个样本仍然很少；单任务从 0/2 到 2/2 可能受采样方差影响。论文通过全 89 任务、多轮迭代和下一轮任务级 delta 减轻这一问题，但没有消除高方差。

## 6. Decision Observability：每次编辑都是可证伪合约

### 6.1 Evolve Agent 的两条硬约束

Evolve Agent 读取分层证据，选择增加、修改或删除 harness 组件。论文没有允许它任意自修改，而是设置两类约束。

**Controllability**：只允许写入 harness workspace；runs、tracer、verifier 和 LLM configuration 只读，种子 system prompt 的原始规则不可删除。这阻止演化 Agent 通过关闭 verifier、换更强模型、提高 reasoning budget 等方式“刷高”结果，使得性能变化仍可归因于 harness 编辑。

**Evidence-driven change**：每次修改必须先给出失败证据、根因、针对性修复和预测影响。预测不仅列出 `predicted_fixes`，还应列出可能受损的 `risk_tasks`。这些内容写入 `change_manifest.json`，下一轮用实际 fail→pass 与 pass→fail 变化核验。

一个 manifest entry 的逻辑结构如下：

```json
{
  "id": "chg-2",
  "files": ["workspace/middleware/execution_risk_hints.py"],
  "failure_pattern": "跨步骤风险只出现在命令序列中",
  "root_cause": "单步 tool output 无法表达状态累积",
  "targeted_fix": "新增维护 recent history 的 middleware",
  "predicted_fixes": ["mteb-retrieve", "train-fasttext"],
  "risk_tasks": ["长时程任务可能因额外检查超时"],
  "constraint_level": "middleware"
}
```

下一轮的 `ATTRIBUTE` 将旧 manifest 与前后两轮任务结果相交，生成每个编辑的 verdict；被拒绝的编辑在新一轮分析前回滚。先归因、后蒸馏的顺序很重要，因为 verdict 会进入新的证据库，使“这次修改上轮说要修谁、实际修了谁”成为下一轮决策输入。

### 6.2 可审计不等于正确归因

change manifest 让决策可以审计，但它仍是 Evolve Agent 对未来的自我预测。文件级 commit 能证明哪些代码发生了变化，却不能在多个组件同时修改时自动识别因果贡献。论文后续专门评估 fix/regression prediction 的 precision 与 recall，结果显示其正向定位有信息量，但回归预判仍很弱。

## 7. AHE 外层算法怎样运行

给定种子 harness (H_0)、冻结模型 (M)、benchmark (D)、每任务 rollout 数 (k) 和最大迭代数 (N)，AHE 重复六个阶段：

```text
H_best ← H_0
for t = 1 ... N:
    T_t  ← ROLLOUT(M, H_{t-1}, D, k)        # 执行任务
    T~_t ← CLEAN(T_t)                       # 轨迹规范化
    if t ≥ 2:
        V_t ← ATTRIBUTE(C_{t-1}, T_{t-1}, T_t)
        H_{t-1} ← ROLLBACK(H_{t-1}, V_t)    # 撤销被否定编辑
    R_t ← AGENT_DEBUGGER(T~_t)              # 分层根因证据
    (H_t, C_t) ← EVOLVE(H_{t-1}, R_t, V_t)  # 修改 workspace + manifest
    COMMIT(H_t, C_t, t)                     # Git 标记本轮状态
    if pass@1(T_t) > pass@1(H_best): H_best ← H_t
return H_best
```

算法维护的是 best-so-far harness，而不是默认返回最后一轮。因为每轮即时分数并非单调，保留历史最好点避免最后一轮回归抹掉此前收益。参考实验运行 10 轮，每个任务 2 次 rollout；一轮同时包含评测、Debugger 分析和 Evolve Agent 修改。

Iteration 1 还并行运行一次 Explore Agent，从 NexAU 源码与公开 coding-agent 资料中生成少量框架知识和参考 skill，帮助 Evolve Agent 学会怎样合法编写组件。这些 skill 从第二轮开始与其他文件一样可以被保留、改写或删除，并不享有永久保护。

## 8. 演化到底改出了什么：从文字规则到执行时约束

![Figure 5：Evolve Agent 在 middleware、prompt 与 tool 三层产生的实际编辑](./AHE-论文汇报.assets/evolve-edits.png)

Figure 5 展示的不是预设模块模板，而是演化过程中实际产生的三种修改。不同失败模式被放在不同执行层，构成 AHE 相对 prompt-only 方法最关键的差异。

### 8.1 四个获胜轮次的累积演化

| 演化节点 | 观察到的失败 | 修改层 | 实际机制 |
|---|---|---|---|
| Iteration 2 | 用 row count、文件存在等代理检查代替 evaluator 语义；前台长命令耗尽超时 | prompt + tool | 增加 contract-first、mirror evaluator、no-overfit 等规则；shell tool 暴露 `timeout_ms` 和后台执行提示 |
| Iteration 5 | 已经通过验证后，为“清理目录”又删除最终产物 | prompt + tool | 定义 publish state；shell guard 记录受保护路径并拦截后续 destructive command |
| Iteration 6 | 风险来自多步命令序列，单次 prompt/输出看不出；脚本入口未被保护 | tool + middleware | 扩展 publish guard 到 evaluator 入口脚本；`ExecutionRiskHintsMiddleware` 追踪跨步骤风险模式 |
| Iteration 8 | Agent 用 override token 绕过软保护；warning 留在上一轮 tool output 中，下一轮推理忽略 | tool + middleware | 将关键删除升级为 hard block；在下一次 model call 前把风险提升为 `FRAMEWORK` reminder |

这一过程说明 AHE 的价值不在“Agent 自动写了更多代码”，而在 **constraint escalation**：同一个失败若在 prompt 层反复出现，就转移到更接近执行点的 tool 或 middleware 层。自然语言建议负责解释原则，工具硬约束负责在模型忘记原则时阻止不可逆动作。

### 8.2 一个具体因果链：publish-state guard

`path-tracing` 任务要求生成 `/app/reconstructed.ppm`。失败 rollout 已经正确渲染并通过自检，却随后执行清理命令，把正确输出一起删除；verifier 最终找不到文件。Iteration 5 的修改分两层：prompt 声明通过 evaluator-style final check 后的文件系统状态就是交付物；shell tool 则解析检查命令中的路径，将产物标记为 protected，在后续删除前直接拦截。

这个例子说明为什么“再补一句不要删除文件”不够。失败发生在模型已经知道目标、也已完成任务之后；真正缺少的是执行时状态保护。修改后 `path-tracing` 从 0/2 变为 2/2，同时也迁移到其他“验证成功后破坏状态”的任务。

### 8.3 Middleware 为什么是不可替代的层

Iteration 6 的 `ExecutionRiskHintsMiddleware` 读取最近命令和新输出，识别浅层验证、只测 localhost、用自制 proxy 代替指定 evaluator、绕过官方 wrapper、没有 threshold 的 benchmark、重复长超时和同错重试等跨步风险。它在 tool call 之后记录信号，Iteration 8 又把信号提升到下一轮 model call 之前，解决“警告存在但不显眼”的 salience gap。

在 `mcmc-sampling-stan` 中，Agent 用近似 grid integration 生成看似合理的数字，却中止真正的 MCMC，再用“文件存在且是数值”作为最终检查。middleware 把 proxy validation 与 shallow validation 标出，tool guard 保护真正 evaluator 入口脚本，最终两个 rollout 都运行完整分析并通过 6/6 verifier tests。这个案例比抽象得分更直接地展示了 observability 如何从轨迹差异转化为组件修改。

## 9. 实验设计：三组 RQ 分别验证什么

### 9.1 RQ 与证据对应关系

| 研究问题 | 设置 | 对比对象 | 核心指标 | 要检验的主张 |
|---|---|---|---|---|
| RQ1：为什么是 AHE | Terminal-Bench 2 全部 89 任务，10 轮演化 | OpenCode、Terminus-2、Codex；同 seed 的 ACE、TF-GRPO | pass@1，按 Easy/Medium/Hard 分层 | 联合 harness 演化是否优于人工 harness 与单层自进化 |
| RQ2：是否过拟合优化目标 | 冻结 AHE workspace，零重演化迁移到 SWE-bench-verified 与五个 alternate bases | NexAU0、ACE、TF-GRPO；同模型 seed/AHE 成对比较 | success rate、tokens/trial、跨模型 pass@1 | 经验是否写入可迁移组件，而非只记住 Terminal-Bench 轨迹 |
| RQ3：增益来自哪里、归因是否可信 | 单组件 swap；9 个相邻轮次预测核验 | NexAU0、full AHE、random prediction baseline | 分层 pass@1；fix/regression P/R | 哪个组件承载增益，manifest 预测是否真有信息量 |

### 9.2 Benchmark、模型和运行条件

Terminal-Bench 2 使用全 89 任务：4 Easy、55 Medium、30 Hard，每任务最长 3600 秒；参考演化 (k=2)，因此每轮有 178 个任务 rollout。SWE-bench-verified 使用 500 个任务、7 个 repository，用于跨 benchmark 的 frozen-harness transfer。

主实验中 Code Agent、Agent Debugger 和 Evolve Agent 都使用 GPT-5.4，论文强调这一点是为了排除跨模型能力转移。不过原文存在一处配置口径矛盾：正文 §4.1 称三个角色均为 GPT-5.4 high，Appendix Table 4 则把 Evolve Agent 列为 xhigh。按照附录的细粒度配置，Code Agent 是 high reasoning、最多 300 model turns；Evolve Agent 是 xhigh reasoning、最多 500 turns；两者最大 context 都是 200K，单 turn 最大生成 32K。Debugger 并发 16、单任务超时 600 秒，外层一共 10 轮、rollout 并发 96。因此可确认三个角色属于同一模型家族，但 reasoning setting 是否完全一致不能按正文表述直接认定。

`pass@1` 定义为所有任务与 rollout 的二元 reward 平均值。基础设施异常和 API timeout 按失败计入 pass@1；但 token 均值排除基础设施中止的 trial，以免截断调用量扭曲均值。这个差异必须保留：成功率采用严格失败口径，而 token 效率只基于完成 trial。

## 10. RQ1 主结果：联合 Harness 演化是否真的更强

![Figure 1：十轮 AHE 得分与 best-so-far 演化曲线](./AHE-论文汇报.assets/evolution-curve.png)

十轮 AHE campaign 约运行 32 小时，最佳 harness 的 Terminal-Bench 2 pass@1 从种子 69.7% 提升到 77.0%，绝对增益 7.3 个百分点。曲线不是单调上升：第 6 轮和第 8 轮形成新高点，之后即时得分又回落；因此算法保留 best-so-far，而不是把最后一轮视为最佳。

| 方法 | 类型 | All | Easy | Medium | Hard |
|---|---|---:|---:|---:|---:|
| OpenCode | human-designed | 47.2% | 75.0% | 52.7% | 33.3% |
| Terminus-2 | human-designed | 62.9% | 75.0% | 74.5% | 40.0% |
| Codex | human-designed | 71.9% | 75.0% | 80.0% | **56.7%** |
| NexAU0 | shared seed | 69.7% | 87.5% | 78.2% | 51.7% |
| ACE | self-evolved from NexAU0 | 68.9% | 91.7% | 78.2% | 48.9% |
| TF-GRPO | self-evolved from NexAU0 | 72.3% | **100.0%** | 79.4% | 55.6% |
| AHE | self-evolved from NexAU0 | **77.0%** | **100.0%** | **88.2%** | 53.3% |

**直接证据**：AHE 的总体分数在这组方法中最高，主要优势来自占比最大的 Medium tier：88.2%，比 NexAU0 高 10.0 个百分点、比 Codex 高 8.2 个百分点。Hard 上 AHE 的 53.3% 低于 Codex 的 56.7% 和 TF-GRPO 的 55.6%，因此“全面超过所有基线”只对 All aggregate 成立，不对每个难度层成立。

**论文解释**：ACE 的自然语言 playbook 和 TF-GRPO 的工具轨迹优势仍主要作用于模型上下文；AHE 额外开放了 tool、middleware 与 memory，而后续消融显示增益恰好主要储存在这些层。这个结果支持“只优化 prompt 会错过关键组件”的 layer-mismatch 论证。

**本文解读**：Medium 有 55 个任务，对总体分数权重最大。AHE 的优化目标是 aggregate pass@1，因此最终 harness 偏向 Medium 是目标函数的自然结果；它不必然代表对长时程 Hard 任务更稳健。

## 11. RQ2 迁移：学到的是通用工程经验还是 Benchmark 痕迹

### 11.1 跨 Benchmark：SWE-bench-verified

四个 harness 都在 GPT-5.4 上运行；AHE、ACE、TF-GRPO 都只在 Terminal-Bench 2 上演化，然后不做 SWE-bench 域内重演化，直接冻结迁移。

| 方法 | Aggregate success | Tokens / trial | 相对 NexAU0 token 变化 | Success / Mtok |
|---|---:|---:|---:|---:|
| ACE | 74.6% | 679K | +29.1% | 1.10 |
| TF-GRPO | 74.2% | 582K | +10.6% | 1.27 |
| NexAU0 | 75.2% | 526K | 基准 | 1.43 |
| AHE | **75.6%** | **461K** | **-12.4%** | **1.64** |

AHE 的成功率只比 seed 高 0.4 个百分点，幅度很小；更明显的证据是每 trial token 从 526K 降到 461K，同时 aggregate success 没有下降。ACE 与 TF-GRPO 在 aggregate success 上都略低于 seed，却消耗更多 token。论文将其解释为：prompt/playbook 信息会搭载在每次模型调用中，而 tool、middleware、memory 可以把反复的协调行为固化为执行结构，减少模型每轮重新推导。

结果并非每个 repository 都正迁移。AHE 在 django 为 81.0%（seed 79.2%），在 sphinx-doc 为 70.5%（seed 68.2%）；但 scikit-learn 从 93.8% 降到 87.5%，pydata 从 77.3% 降到 72.7%，astropy 从 54.5% 降到 50.0%。论文把小 repository 的回落部分归因于样本量和方差，但这些仍是实际负迁移，不能用 aggregate 结果抹掉。

### 11.2 跨模型：同一 Frozen Harness 能否复用

| Base model / reasoning | NexAU0 | AHE frozen | 绝对增益 |
|---|---:|---:|---:|
| GPT-5.4 medium | 65.7% | 68.0% | +2.3 pp |
| GPT-5.4 high | 69.7% | 77.0% | +7.3 pp |
| GPT-5.4 xhigh | 72.5% | 74.7% | +2.3 pp |
| gemini-3.1-flash-lite-preview | 36.5% | 41.6% | +5.1 pp |
| deepseek-v4-flash | 51.7% | 61.8% | +10.1 pp |
| qwen-3.6-plus | 56.2% | 62.5% | +6.3 pp |

五个 alternate operating points 都是正增益，跨 family 的 +5.1 到 +10.1 pp 大于 GPT-5.4 medium/xhigh 的 +2.3 pp。论文据此认为演化组件编码了较通用的 coordination patterns，而非只适配 GPT-5.4 的表达习惯。

但 GPT-5.4 family 内部的增益并不随 reasoning tier 单调变化：medium +2.3、high +7.3、xhigh +2.3。演化期间 step budget 和 timeout 都围绕 high 调整；medium 能力更弱，xhigh 又可能因每步耗时更长触发 task timeout。因而该实验混合了 harness portability 与 operating-point coupling，不能只按“越弱模型越依赖 harness”解释。

## 12. RQ3a 组件消融：增益究竟储存在哪里

| Harness variant | All | Easy | Medium | Hard |
|---|---:|---:|---:|---:|
| NexAU0 | 69.7% | 87.5% | 78.2% | 51.7% |
| + memory only | 75.3% | 50.0% | 83.6% | **63.3%** |
| + tool only | 73.0% | 75.0% | 87.3% | 46.7% |
| + middleware only | 71.9% | **100.0%** | 81.8% | 50.0% |
| + system prompt only | 67.4% | 75.0% | 78.2% | 46.7% |
| AHE full | **77.0%** | **100.0%** | **88.2%** | 53.3% |

三个非 prompt 组件单独移植都超过 seed：memory +5.6 pp、tool +3.3 pp、middleware +2.2 pp；system prompt 单独移植反而 -2.3 pp。这是论文支持“harness 是独立优化层”的最关键消融：可执行结构与长期经验在没有其他组件时仍能产生效果，而文字策略的可执行性依赖外围机制。

但组件效果高度异质。Memory 在 Hard 达到 63.3%，甚至超过 Codex 和 full AHE，却让 4 个 Easy 任务降到 50.0%；tool 在 Medium 接近 full AHE，却使 Hard 退化；middleware 在 Easy 全部通过，但会增加 Hard 的 turn 消耗。每一层都修复特定 failure surface，也会在另一个任务分布上制造成本。

三个正向单组件增益相加为 +11.1 pp，高于 full AHE 的 +7.3 pp，说明组件 **非加和交互**。Memory、middleware 与 prompt 都可能推动 closure-style verification，叠加后在长任务上重复检查、耗尽 budget。Full AHE 不是各组件独立最优效果的简单总和，当前 Evolve Agent 也没有显式建模组合相互作用。

## 13. RQ3b 决策归因：能预测修复，却看不见大多数回归

![Figure 4：Evolve Agent 对修复与回归的预测 precision/recall](./AHE-论文汇报.assets/attribution-quality.png)

每轮 manifest 预测哪些任务会被修好、哪些任务有回归风险。论文将第 (N-1) 轮预测与第 (N) 轮真实 task delta 对比，在 9 个可核验轮次上分别计算 fix 和 regression 的 precision/recall。

| 预测类型 | Precision | 随机基线 | Recall | 随机基线 |
|---|---:|---:|---:|---:|
| Fix | **33.7%** | 6.5% | **51.4%** | 10.6% |
| Regression | **11.8%** | 5.6% | **11.1%** | 5.4% |

Fix precision 与 recall 大约是随机基线的 5 倍，表明 Evolve Agent 的正向 targeting 确实从证据中获得了信息，而不只是随机挑任务。但 33.7% precision 仍意味着多数预测修复没有按预期发生；它是“有信息的噪声信号”，不是可靠因果模型。

Regression 指标只约为随机的 2 倍。Appendix D 给出更直观的累计数字：9 轮中 Agent 发出 43 个 unique regression predictions，只有 5 个命中；同时真实发生了 40 个它未预见的回归。换言之，manifest 较会说明“为什么这个改动应该帮助”，却不会系统枚举同一改动的破坏面。这正是即时得分多次非单调、组件组合互相干扰的直接原因。

**论文主张**：decision observability 把 rationale-driven self-justification 替换成可测合约。  
**直接证据**：fix prediction 显著高于随机，证明合约含有部分可用信号；regression prediction 接近低水平，证明当前合约并未实现完整的风险归因。  
**本文解读**：AHE 已经实现“审计基础设施”，但还没有实现足够准确的 world model。下一步不只是让 Evolve Agent 写更详细理由，而应进行组合干预、反事实评测或针对风险任务的主动回归测试。

## 14. 效率与成本：推理 Token 更少，不代表演化免费

SWE-bench-verified 上，AHE 的 tokens/trial 比 seed 少约 12%、比 ACE 少约 32%、比 TF-GRPO 少约 21%，并以 1.64 successes per million tokens 获得最高 token efficiency。这支持“把协调策略固化在 tool/middleware，而不是每次在 prompt 中重推导”的解释。

但是需要区分三类成本：

- **Frozen harness 推理成本**：Table 2/5 的 tokens/trial 与 Succ/Mtok，AHE 在这里有优势；
- **一次 AHE campaign 的演化成本**：10 轮 × 89 任务 × 2 rollouts，加上 Debugger、Evolve、Explore Agent，约 32 小时；论文没有给出完整美元成本或全 campaign token 总账；
- **执行基础设施成本**：每个 rollout 在独立 E2B sandbox 中运行，任务最长一小时，外层并发 96；这不包含在简单的模型 tokens/trial 指标中。

此外，token 均值排除了基础设施中止的 trial，而 pass@1 将其计为失败。AHE 的效率结论适用于成功完成运行的模型调用量，不能直接等同于端到端生产总成本。

## 15. 论文已经证明、提示但未证明了什么

### 15.1 有直接证据支持的结论

1. 在固定参考设置中，从 bash-only NexAU0 出发，AHE 的 best harness 将 Terminal-Bench 2 aggregate pass@1 从 69.7% 提升到 77.0%，高于所列人工与自进化基线。
2. 增益不是主要来自 system prompt；单独替换 memory、tool、middleware 都高于 seed，system prompt alone 反而退化。
3. Frozen AHE harness 在 SWE-bench-verified 上保持略高 aggregate success，并降低完成 trial 的模型 token 使用。
4. 同一 frozen workspace 对五个 alternate model/operating points 都产生正向 pass@1 变化。
5. Manifest 的 fix prediction 显著优于随机，但 regression prediction 很弱；自归因有用而不可靠。

### 15.2 论文提示、但没有完全证明的结论

1. **“Observability，而不是 Agent capability，是主要瓶颈”**：实验支持结构化闭环有效，但没有与“相同 harness、不同能力 Evolve Agent”进行系统正交对照，因此不能完全排除 optimizer capability 的影响。
2. **组件编码通用工程经验**：跨 benchmark/模型正迁移提供支持，但只有两个 benchmark，且 repository 级结果存在负迁移，尚不能覆盖更多语言、IDE 工作流或真实团队协作。
3. **AHE 优于 prompt-only 的原因就是编辑层更广**：组件消融与基线差异一致，但 AHE 同时改变了证据蒸馏、归因、回滚和动作空间，实验没有逐一控制每个差异。
4. **自动回滚建立了稳定演化**：best-so-far 确实上升，但即时曲线仍显著波动；稳定性更多来自保留历史最佳和文件回滚，而不是每一步编辑都不会伤害系统。

## 16. 局限与批判性评价

### 16.1 论文明确承认的局限

- **Benchmark scope**：只在 Terminal-Bench 2 演化，在 SWE-bench-verified 迁移；其他语言、生产 repository、长时间部署和 human-in-the-loop 流程未测试。
- **Evolution operating point**：step budget 与 timeout 针对 GPT-5.4 high 调整，跨模型结果混合了 harness 可迁移性与运行预算耦合。
- **Self-modification governance**：workspace 权限、verifier 只读、Git manifest 和 rollback 是研究级约束，不构成完整安全治理；长期 harness 清理与滥用防护仍不成熟。

### 16.2 进一步需要警惕的问题

**单次 campaign 与高方差**。主结果来自一次 10 轮 reference run，且每任务 (k=2)。论文给出跨任务和迁移证据，但没有多随机种子重复整套演化 campaign 的均值与置信区间。77.0% 应理解为这一 campaign 的 best configuration，而不是 AHE 运行十次都能稳定得到的期望值。

**比较对象并非完全同构**。ACE 与 TF-GRPO 从同一个 NexAU0 出发，这是公平的重要部分；但 AHE 开放更多组件、使用 Agent Debugger、manifest、rollback 和 Explore Agent，系统复杂度更高。结果证明“完整 AHE 系统更强”，还不能精确分摊三种 observability 各自的边际贡献。

**组件归因仍受联动影响**。文件级 commit 和 single-component swap 提高可解释性，但 tool、middleware、prompt 的语义互相依赖。一个组件单独移植的表现，不等于它在 full harness 中的 Shapley-style 因果贡献。论文自己发现单组件增益总和大于 full AHE，正说明简单归因不足。

**风险感知是当前最薄弱的一环**。回归 recall 只有 11.1%，意味着大部分破坏直到真实 benchmark 执行后才被发现。对于昂贵或高风险环境，仅靠下一轮全量评测发现回归可能代价过高；需要在提交前做静态检查、针对预测影响面的 sandbox test、差分执行和更强的 rollback policy。

**优化目标造成任务分布偏置**。89 个任务中 55 个是 Medium，aggregate pass@1 驱动 Evolve Agent 偏向 Medium。Memory-only 在 Hard 明显更强却在 full harness 中被部分抵消，说明单一总体指标会牺牲少数但更困难的任务。多目标或分层约束可能比一个 aggregate score 更适合实际部署。

## 17. 放在 AI 自进化专题中的位置

AHE、ACE 与 TF-GRPO 都冻结基础模型，但它们把“可进化状态”放在不同位置：

| 方法 | 主要可进化对象 | 经验怎样写回 | 强项 | 主要风险 |
|---|---|---|---|---|
| ACE | itemized context / playbook | Reflector 诊断后由 Curator 产生 delta，再确定性合并 | 持续积累可读策略，适合上下文适应 | 依赖反馈质量，知识仍主要搭载在上下文中 |
| TF-GRPO | rollout 中的策略/语义优势信号 | 用组内相对结果构造 training-free 更新 | 从多轨迹相对反馈中强化有效决策 | 可编辑表面仍较窄，难形成执行级硬约束 |
| AHE | prompt、tool、middleware、skill、memory 等完整 harness | Debugger 生成证据，Evolve Agent 修改文件，manifest 核验并回滚 | 能把经验编译成可执行、可审计组件 | 搜索成本高、组件非加和、回归预测薄弱 |

AHE 可以被理解为 **experience compilation**：ACE 更像把经验写成“下一次供模型阅读的知识”，AHE 则进一步尝试把反复经验编译成工具接口、状态机、hook 和硬保护。两者不是互斥替代；一个更完整的自进化系统可能同时需要 playbook 层的快速记忆与 harness 层的慢速结构固化。

## 结论

AHE 把 coding-agent harness 从人工维护的外围工程，提升为一个显式、自主、可审计的适应层。其核心不是让 Agent 无限制改自己，而是用三种 observability 限定自修改：组件变成文件级动作，轨迹变成可钻取证据，修改变成下一轮可证伪的预测。实验表明，真正可迁移的收益主要存放在 tools、middleware 与 long-term memory，而非一段更长的 system prompt。

同时，AHE 还不是成熟的自治进化系统。它在单次 reference campaign 上表现突出，但组件组合会互相干扰，跨 repository 存在负迁移，回归预测 recall 只有 11.1%，完整演化成本也明显高于 frozen harness 推理成本。论文最可靠的结论不是“Agent 已能稳定改进自己”，而是：**当自进化对象被外部化、证据被结构化、每次修改被迫接受下一轮验证时，harness 可以成为模型权重之外一条现实且可审计的能力增长路径。**