论文概览
一句话定位、核心贡献、高层架构
AHE 将编码 Agent 的 Harness 优化从手工调试变成了可观测的自动化闭环——让 LLM 自己修改自己的工具链、中间件和记忆，每次修改附上预测，下轮验证，最终超越人工设计的 Harness。
这篇论文直击当前编码 Agent 的一个核心痛点：Harness（外围工程系统）——包括 System Prompt、Tools、Middleware、Long-term Memory 等——对 Agent 性能影响巨大，但 Harness 的设计和优化至今仍是纯手工活。论文提出的 Agentic Harness Engineering (AHE) 是一个完全自动化的闭环系统，通过三个可观测性支柱让 Harness 能够基于经验证据自主进化。
核心贡献速览
| 贡献 | 说明 | 证据等级 |
|---|---|---|
| 三支柱可观测性框架 | Component / Experience / Decision Observability，让 Harness 进化可追溯、可验证 | 直接证据 |
| 10轮迭代超越人工设计 | Terminal-Bench 2 上 pass@1 从 69.7% → 77.0%，超过 Codex-CLI (71.9%)、ACE、TF-GRPO | 直接证据 |
| 跨模型跨任务泛化 | 冻结的 Harness 直接迁移到 SWE-bench-verified 和 3 个不同模型家族，均带来正向收益 | 直接证据 |
| 组件级消融定位增益来源 | Tools、Middleware、Long-term Memory 是主要增益点，System Prompt 单独反而拖累 -2.3pp | 直接证据 |
| 可迁移的工程经验 | 进化出的组件编码了通用工程经验，而非 benchmark 特定调优 | 基于证据的推断 |
研究脉络与问题定位
这篇论文在回答什么问题？前人做了什么，留下了什么缺口？
Harness 工程至今是手工工艺——人类开发者观察失败轨迹、识别重复模式、手动修改 Prompt/Tools/Middleware。为什么自动化它如此困难？
论文识别了自动化 Harness 工程的三个根本挑战：
- 异构动作空间：Harness 组件（Prompt、Tools、Middleware、Memory）类型各异（文本、代码、配置），编辑方式不统一，无法用单一优化算法覆盖
- 轨迹噪声淹没信号：一次 rollout 产生数十万 token 的 Agent 对话日志，真正的失败模式（如"用代理检查代替真正的验证器检查"）淹没在细节中
- 因果归因困难：一次 Harness 修改可能影响多个任务，有的变好、有的变差，没有系统的方法追踪"哪个改动导致了什么效果"
与相关工作对比
| 方法线 | 代表工作 | 可编辑范围 | 与 AHE 的差异 |
|---|---|---|---|
| Prompt 优化 | DSPy, OPRO, GEPA | 仅 Prompt | AHE 发现 Prompt 单独编辑反而降效 -2.3pp |
| Trajectory 反馈 | ACE, TF-GRPO | 自然语言规则 / 工具选择序列 | 不修改底层脚手架，错过 Tools/Middleware 层增益 |
| 程序结构进化 | Skill Libraries, Graph Workflows | 代码或流程图 | AHE 的观察空间包含文本 + 代码 + 配置，更贴近真实工程 |
| ⭐ AHE | 本文 | Prompt + Tools + Middleware + Memory | 统一可观测性框架，每次编辑附带可验证预测 |
核心方法：三支柱可观测性架构
AHE 通过三个精心设计的可观测性层解决上述三大挑战
Component Observability
每个 Harness 组件（Prompt、Tool、Middleware、Memory）都有独立的文件级表示。动作空间明确、可回滚。失败模式可以精确映射到单个组件类。
Experience Observability
将百万级原始轨迹 token 蒸馏为分层的、可下钻的证据语料库。Agent Debugger 将每条轨迹的消息组织为独立文件，通过 shell 和脚本工具导航分析，产出逐任务分析报告。
Decision Observability
每次编辑附带自行声明的预测（预计修复哪些任务、可能回归哪些任务），下一轮验证后确认或回滚。每个编辑成为"可证伪的契约"，而非盲目的试错。
工作流程详解
- Code Agent（编码 Agent）：使用当前 Harness 配置在 benchmark 上运行任务，产生 k 条轨迹
- Agent Debugger（调试 Agent）：以文件系统形式组织轨迹，逐任务分析失败原因和成功模式，产出分层证据语料库
- Evolve Agent（进化 Agent）：读取证据语料库，决定修改哪些组件，实施修改，记录每次修改的预测和理由，输出 Change Manifest
- 验证阶段：下轮 rollouts 执行后，将实际结果与 Change Manifest 的预测对比，决定保留或回滚每个编辑
想象一个软件开发团队：Code Agent 是程序员写代码，Agent Debugger 是 QA 分析 bug 根因，Evolve Agent 是 tech lead 根据分析报告改代码规范。每一轮改进都写上"我预计这样改能修好哪些 bug，但可能会引入这些新 bug"，下轮测试来验证。这就是 AHE。
核心设计约束
- 可控制性：Evolve Agent 只能修改
workspace/目录下的 Harness 文件，基础设施只读 - 可归因性：每次编辑必须在 Change Manifest 中记录"预计修复的任务"和"可能回归的任务"
- 可回滚性：下轮验证后，未兑现的编辑被自动撤销
实验设计与核心发现
三个研究问题，覆盖性能、泛化性、可解释性
📊 RQ1：主结果——自动进化能否超越人工设计？
在 Terminal-Bench 2（89个任务）上，以只暴露 bash 工具的 NexAU 0 为种子，10 轮 AHE 迭代后：
| 方法 | 类型 | All (89) | Easy (4) | Medium (55) | Hard (30) |
|---|---|---|---|---|---|
| opencode | 人工 Harness | 47.2% | 75.0% | 52.7% | 33.3% |
| terminus-2 | 人工 Harness | 62.9% | 75.0% | 74.5% | 40.0% |
| Codex-CLI | 人工 Harness | 71.9% | 75.0% | 80.0% | 56.7% |
| NexAU 0（种子） | 基线 | 69.7% | 87.5% | 78.2% | 51.7% |
| ACE | 自进化（Prompt 级） | 68.9% | 91.7% | 78.2% | 48.9% |
| TF-GRPO | 自进化（Trajectory 级） | 72.3% | 100.0% | 79.4% | 55.6% |
| AHE（本文） | 自进化（全 Harness） | 77.0% | 100.0% | 88.2% | 53.3% |
加粗 = 列最优。AHE 从单纯 bash 工具的种子（NexAU 0）出发，10 轮迭代（约32小时）达到整体最优。
ACE 和 TF-GRPO 起始于相同的 NexAU 0 种子，但只编辑 Prompt 或轨迹反馈层面，不修改底层脚手架。消融实验证实：AHE 的增益主要来自 Tools (+3.3pp)、Middleware (+2.2pp)、Long-term Memory (+5.6pp)，而 System Prompt 单独改进反而 拖累 -2.3pp。这解释了为什么 ACE/TF-GRPO 无法匹敌 AHE——它们从未触及实际的增益所在层。
🌐 RQ2：泛化性——是通用经验还是 benchmark 调优？
跨 Benchmark 迁移 (SWE-bench-verified)： AHE 的 Harness 直接冻结使用（不做进一步进化）：
| Metric | NexAU 0 | ACE | TF-GRPO | AHE |
|---|---|---|---|---|
| Success Rate ↑ | — | 27.3% | 29.7% | 35.2% |
| Tokens k ↓ | 203 | 183 | 207 | 179 |
AHE 在 SWE-bench-verified 上实现了最高的成功率（35.2%），同时 token 消耗最少（179k），比种子节省 12% 的 token。
跨模型家族迁移： 在 5 个不同基础模型上重评估，全部为正向增益：
🧠 deepseek-v4-flash
51.7% → 61.8% (+10.1pp)
跨家族增益最大
🧠 qwen-3.6-plus
56.2% → 62.5% (+6.3pp)
跨家族增益显著
🧠 gemini-3.1-flash-lite
36.5% → 41.6% (+5.1pp)
最弱模型也受益
🧠 GPT-5.4 medium
← +2.3pp
同家族增益最小
跨家族增益 > 同家族增益。直觉解释：远离饱和点的模型更依赖 AHE 固定的协调模式（Tools/Middleware/Memory 层），而更强的基座模型可以从自身 Prompt 中重新推导出这些协调，边际收益低。这强烈暗示 AHE 编码的是通用的工程经验，而非 GPT-5.4 特定的 benchmark 调优。
🔬 RQ3：消融与归因——增益从何而来？
| 变体 | All | Easy | Medium | Hard |
|---|---|---|---|---|
| NexAU 0（种子） | 69.7% | 87.5% | 78.2% | 51.7% |
| + 仅 Long-term Memory | 75.3% | 50.0% | 83.6% | 63.3% |
| + 仅 Tools | 73.0% | 75.0% | 87.3% | 46.7% |
| + 仅 Middleware | 71.9% | 100.0% | 81.8% | 50.0% |
| + 仅 System Prompt | 67.4% | 75.0% | 78.2% | 46.7% |
| AHE 完整 | 77.0% | 100.0% | 88.2% | 53.3% |
- 修复预测：Precision 33.7%, Recall 51.4%——约是随机基线的 5x，说明 Evolve Agent 的修复定位是真正基于证据的
- 回归预测：Precision 11.8%, Recall 11.1%——仅约随机基线的 2x，Agent 无法可靠预测自己的修改会破坏什么
- 这个"回归盲点"正是产生非单调进化曲线的根源：一轮改进可能意外破坏其他任务，下一轮再修复
局限性与批判性分析
诚实面对论文的假设、边界和未回答的问题
⚠️ Benchmark 专注性风险
评估集中于 Terminal-Bench 2 一个 benchmark。尽管做了跨 benchmark 迁移测试，但 terminal 类任务空间与真实软件工程环境仍有差距。论文承认"gain on this benchmark does not by itself establish broad generalization"。
⚠️ 过拟合表面增大
AHE 扩展了可编辑组件范围（Prompt + Tools + Middleware + Memory），灵活性增大，但同时也为 benchmark 特定调优创造了更多"旋钮"。论文通过迁移实验来缓解此风险，但边界效应需进一步研究。
⚠️ 治理与安全机制不成熟
当前系统在安全性上有基本的组件级保护（只写 workspace，不碰基础设施），但缺少更细粒度的权限模型、编辑审计链或对抗性保护。如果 Harness 编辑能力被恶意利用，后果严重。
⚠️ Hard 任务未见最优
在 Hard 任务上 AHE 的 53.3% 低于人工设计的 Codex-CLI（56.7%）。部分原因是 Evolve Agent 优化了以 55 个 Medium 任务为主的 aggregate，牺牲了 Hard 任务的特定收益。
⚠️ 组件交互非加性
三个正向组件的单独增益之和（+11.1pp）超过完整 AHE（+7.3pp），说明组件之间存在重叠和竞争。在 Hard 任务上，仅 Memory 变体（63.3%）甚至超过完整 AHE（53.3%）。
⚠️ 计算成本未充分报告
论文报告 10 轮约 32 小时，但未分解 GPU 小时数、总 token 消耗、以及 Agent Debugger + Evolve Agent 本身的开销。对于实际部署，强化学习式的 token 成本可能更低。
- 不同领域（如数据分析、Web 自动化、多模态）上的 Harness 进化效果
- 更小/更弱的基础模型（低于 36.5% pass@1）是否能从 AHE 中获益
- 超过 10 轮迭代的渐进效果是否会持续改善或饱和
- Evolve Agent 本身的"元-元"进化——谁来优化优化器？
- 在持续变化的任务分布上（而非固定 benchmark 集）的长期适应性
启发与更广泛意义
这篇论文对 coding agent 研究意味着什么？
Harness 是可学习的适应面
核心方法论贡献：即使基础模型固定，Harness 的外部组件可以作为一个独立的、可学习的适应面。这意味着可以在不微调模型的情况下提升 Agent 能力。
工程经验可以外部化
AHE 表明 coding agent 的工程经验可以沉淀为 Tools、Middleware、Memory 等显式工件，而非隐式编码在模型权重中。跨模型迁移实验充分支持了这一主张。
自进化 loop 的设计基准
AHE 的三支柱框架为未来的自进化系统提供了设计基准。特别是"每次编辑附上可证伪预测"的设计模式，有望成为自治系统的标准组件。
值得关注的方向
- 交互感知进化：当前 Evolve Agent 分别优化各组件，忽略交互效应。未来的进化算法需要感知组件间的重叠和协同。
- 回归预测改进：修复预测好（5x 随机），回归预测差（2x 随机）。这是最清晰的改进方向——如果能可靠预测副作用，进化曲线将从震荡上升变为单调上升。
- 跨领域迁移：AHE 的 Harness 在 terminal 类 SWE 任务上训练，如果能迁移到数据分析、Web 自动化等完全不同的领域，将极大扩展影响力。
- 元进化：Evolve Agent 本身能否也被优化？Evolve Agent 的 Prompt 和策略当前是固定的——如果让它也学会如何更好地进化，会发生什么？
延伸阅读
前置必读、同期对比与工程实现参考
前置必读
- Terminal-Bench 2 (Liu et al., 2025) — 本文使用的评估 benchmark，多步骤终端工作流基准
- NexAU (Lin et al., 2026) — AHE 底层的 Agent 框架，提供 Harness 的解耦组件结构
- Agent Debugger (Liu et al., 2026) — 分层轨迹证据挖掘框架，AHE 的 Experience Observability 基础
同期对比
- ACE (Agrawal et al., 2025) — 反思式 Prompt 进化，仅操作自然语言规则层面
- TF-GRPO (Cai et al., 2025) — 无需训练的轨迹反馈 GRPO 变体，强化工具选择序列
- GEPA (Agrawal et al., 2025) — Pareto 前沿轨迹驱动的反射式 Prompt 更新
工程实现参考
- 官方代码: github.com/china-qijizhifeng/agentic-harness-engineering
- Codex-CLI (OpenAI, 2025) — 本文最强人工对比基线
- Claude Code (Anthropic, 2025) — 另一个主流编码 Agent 的 Harness 实践
- OpenCode (Anomaly, 2025) — 开源编码 Agent，本文另一个对比基线