AHE：可观测性驱动的 Coding Agent Harness 自动演进

关联论文：2604.25850
作者：spark
更新：2026-07-05

一句话结论

Agentic Harness Engineering (AHE) 用一套"组件 / 经验 / 决策"三层可观测性支柱把 Coding Agent 的 harness（系统提示、工具、中间件、长期记忆等模型外可编辑组件）变成可证伪、可逐文件回滚、自动进化的对象，10 次迭代就让 Terminal-Bench 2 的 pass@1 从 69.7% 涨到 77.0%，并能零再训练迁移到 SWE-bench Verified 与三个不同模型家族。

这篇工作真正在解决什么问题

当 base 模型越来越强，Coding Agent 的实际能力越来越被 harness（系统提示、暴露给模型的工具、中间件、long-term memory 等）卡住，而不是被模型本身卡住。这在两条观察上都很清楚：

同一份 base 模型，换一套 harness，在 Terminal-Bench 2 这种长链路任务上成绩差距非常明显。
最佳 harness 是模型相关的——为模型 A 调的 harness，放到模型 B 经常衰减。

于是"harness 工程"成了第一性瓶颈。但当前仍是手工作业：开发者读轨迹、识别失败模式、手写 prompt / tool / middleware 改动。Base 模型迭代越快，这条手工回路越跟不上——这是作者点名的"widening gap between model capability and the harness needed to realize it"。

直观方案是让"evolution agent"自己改 harness。但这条路被三个结构性问题卡死：

动作空间异构：可编辑组件跨 prompt、tool、middleware、技能、memory 等多种类型，统一接口很难设计；
轨迹噪声大：长链路运行动辄百万 token，evolution agent 很难从中找到可执行的信号；
编辑归因困难：一次 harness 改动到底贡献了多少是 confounding 的，没法稳定评估。

AHE 把上述三个结构性卡点对应到三个"可观测性支柱"，整篇论文的写法就是"用可观测性把 harness 演进闭环"。

核心方法：三层可观测性支柱

AHE 是一个由 evolution agent 主导的闭环。三大支柱严格配对到上面的三个障碍：

3.1 Component Observability（组件可观测性）

把 harness 解耦到文件级别的可编辑组件类，每个失败模式能干净地映射到一类组件（"这个 task 失败是因为 tool 接口有歧义" → 改 tool 文件）。

抽象上就是 decoupled harness：把模型外的可编辑组件全部以文件形式存在，让 action space 显式、可回滚。
论文 §1 中提到"七个可编辑组件类"，具体类目以正文 §3.1 / 附录 A 为准。

3.2 Experience Observability（经验可观测性）

把百万级原始 trajectory token 蒸馏成分层、可下钻（drill-down）的 evidence corpus，让 evolution agent 实际能消费。

关键动作是分层蒸馏：从 raw trajectory → 中层事件 → 高层 root cause；
evolution agent 拿到的不再是日志，而是结构化的失败模式总结；
这与传统"把 trajectory 当 prompt 的一部分塞回 LLM"的做法本质区别在于：层次化结构把信号聚焦到可决策的颗粒度。

3.3 Decision Observability（决策可观测性）

给每次编辑配一个"自声明预测"，下一轮跑完后用任务级 outcome 去验证这个预测，实现"每次编辑都是可证伪的契约"。

失败编辑按文件粒度 revert，避免演进化成 trial-and-error；
设计上等价于把 harness 的每次改动当成一个实验假设；
这一支柱是 AHE 与其它自演进 baseline 在哲学上的分水岭——其它 baseline 没有"假设-证伪"的形式化约束，演着演着就退化成 prompt 调参。

3.4 闭环伪代码

init: harness = seed (e.g., bash-only)
for iter = 1 .. N:
    # run with current harness
    trajectories = rollouts(harness, bench)
    # experience distill
    evidence = distill(trajectories)            # Experience Observability
    # component-aware proposal
    edit_proposals = evolve(evidence, harness)  # Component Observability
    for e in edit_proposals:
        e.prediction = "after this edit, X will improve by ~Y"
    # deploy & verify predictions
    next_metrics = rollouts(apply(e), bench)
    for e in edit_proposals:
        if e.prediction.verifies(next_metrics):
            keep(e)
        else:
            revert(e)                           # Decision Observability

这种"每次编辑先声明再证伪"的做法，把 harness 演进从"调 prompt 玄学"变成"文件级可回滚 + 信念可证伪"的科学循环。本质上，它把 harness 开发从工程 craft 拉到了 empirical science。

关键实验与数据

论文主实验在 Terminal-Bench 2 上做 10 轮迭代，结论非常硬：

AHE 10 轮迭代：pass@1 从 69.7% → 77.0%（绝对提升 +7.3pp）。
超过人类设计的 Codex-CLI：Codex-CLI 在同一基准上是 71.9%，AHE 自动进化结果更高。
超过自我演进 baseline ACE / TF-GRPO：AHE 把 harness 作为整体优化对象，而不是只优化 prompt（ACE）或单纯靠语义优势先验（TF-GRPO）。

迁移性（这是工程最有说服力的一段）：

冻结 harness 不再演化，直接迁移到 SWE-bench-verified 拿到最高 aggregate success，同时比 seed 省 12% 的 token。
在 Terminal-Bench 2 上，针对三个不同模型家族做 zero-shot 迁移，pass@1 提升在 +5.1 到 +10.1 个百分点之间；距离饱和越远的 base，提升越大。
这暗示 AHE 学到的是"通用工程经验"，不是 benchmark-specific tuning。

组件消融（同样关键）：

主要增益来自 tools、middleware 和 long-term memory 这三类结构性组件；
单独改 system prompt 反而退步；
说明"事实型 harness 结构"可迁移，"散文型 prompt 策略"不可迁移——这是一个非常反直觉但很有价值的发现。

备注：以上数字直接来自论文 abstract（v4），主体实验在 Terminal-Bench 2；SWE-bench Verified 的逐模型族详细数字以正文 Table 与 §A 为准，本文不抄录细表。

亮点与局限

亮点

把"工程学方法论（实验 + 证伪）"灌进 harness 演化：每个编辑都先写假设、再跑实验验证。
跨基准 + 跨模型家族的迁移证据特别硬，区别于过去只看单基准提升的"自我演进"工作。
组件级 ablation 直接告诉实践者"动哪里能涨、不动哪里反而退步"，对工程团队是非常可操作的指引。
把 harness 看作可证伪系统，而不是 prompt 调参对象，是根本性的认识升维。

局限

自身论文承认了两条边界： 1. harness 组件之间存在非线性交互，叠加有效编辑会出现收益封顶——意味着不能拿 N 个独立有效编辑"叠 buff"; 2. self-attribution 对修复（fix）可靠，但对回归（regression）几乎失明——也就是说，AHE 知道"这个改动修好了什么"，但不容易预见"这个改动会弄坏别的什么"。这是作者自己点明的未来方向。
关键依赖：rollout 信号质量。一旦 benchmark 不够真实（Terminal-Bench 2 / SWE-bench 都偏长链路 terminal-style），演进结果会偏向这种风格；其它风格（前端生成、纯 web search、IDE 操作）的迁移性是开放的。
论文在 abstract 没有给出每轮迭代的耗时与 token 预算，原文未明确给出。工程团队落地前最好自己 benchmark。

对工程落地的启发

如果团队在做内部 coding / devops agent：值得直接把 harness 解耦到文件级（prompt.md / tools.py / middleware.py / memory/...），给每次改动配 "预期影响" 的字段，跑完 benchmark 自动 revert。这一改动可以离线、与模型版本解耦，是最便宜的"自动进化"切入口。
不要只优化 prompt：作者结论非常清楚，单做 prompt 反而退步。Structurally 改 tool 接口、middleware、long-term memory 这三块能稳定拿到收益。
可证伪是底线：让每次 harness 改动都附带"为什么这么改、预期提升什么"的声明，下一版 release note 可以直接复用为 audit log。这一做法本身就能给工程团队带来可观测性红利，不一定要等完整的 AHE 闭环。
评估回归盲区：AHE 自己也指出 self-attribution 对 regression 不灵敏，工程落地时强烈建议在主 benchmark 之外再放一组 holdout 回归集，否则 AHE 会越演进越自信地偏。
Harness 版本化：AHE 的 file-level revert 几乎强制要求 harness 走 Git/版本管理；落地前先把 harness 仓库化比闭环本身更重要。
对 base 模型切换友好：作者提到的"harness is model-specific"意味着模型升级后必须重跑一轮 AHE；建议把 AHE 做成"模型发布前的 CI 步骤"。

与同方向工作的关系

相比 prompt-only self-evolution（GEPA、Promptbreeder、TextGrad、ACE 等）：ACE 用 in-context playbook 进化 prompt，AHE 用文件级整 harness（包括 tools 与 middleware），范围更大；GEPA/Promptbreeder 多停在文本层。
相比 Training-Free GRPO (TF-GRPO)：TF-GRPO 用语义优势先验在输出端重排，AHE 改的是 harness 结构而非单次输出选择，是不同层的优化。
相比 skill libraries / program archives（SICA、ADAS、AlphaEvolve 等）：这些工作进化"程序结构"，AHE 进化"agent harness"——更靠近系统而非单 agent。
相比 SWE-agent、DigiRL、Agent-S、LoCoBench-Agent：这些是单点 agent 工作（评估 / 决策 / 训练），AHE 是"如何把它们的 harness 自动变好"的方法学。
相比 benchmark-side infra（Terminal-Bench、SWE-bench Verified、Tau-bench）：AHE 直接构建在这些 benchmark 之上，演进质量被 benchmark 真实度上限约束。

适合谁读

维护 Coding Agent（Copilot-like、Devin-like、内部 SWE agent）的工程团队，把手工迭代 prompt 改成"自动演进"；
RL / Agent infra 团队，需要一个把 harness 改动结构化的样板（可观测性 + 假设-证伪）；
评估 Coding Agent 的研究员，需要把 harness 改动从"调参玄学"变成"可证伪命题"；
任何想做"自动 + 可回放 + 可分析"的 agent 训练-部署闭环的团队；
Agent 框架作者（OpenHands、LangGraph、Cursor 系列），考虑把 harness 改动仪式化内建到产品中。

工程落地与核查（Jay）

事实核查

核查项	原文说法	核查结论
Terminal-Bench 2 pass@1 起点 69.7%	abstract v4	✅ 符合：abstract 直接给出
10 轮迭代后 77.0%	abstract v4	✅ 符合：+7.3pp 绝对提升
超过 Codex-CLI（71.9%）	abstract	✅ 符合：abstract 明示"exceeds human-designed Codex-CLI"
超过 ACE / TF-GRPO	abstract	✅ 符合：原文明确比较基线
迁移 SWE-bench-verified 最高 aggregate success	abstract	✅ 符合：原文声称"zero-shot transfer to SWE-bench-verified"
三个模型家族零样本迁移 +5.1~+10.1pp	abstract	✅ 符合：原文明确数值范围
比 seed 省 12% token	abstract	✅ 符合：原文明确
主要增益来自 tools/middleware/long-term memory	abstract / §X	✅ 符合：原文组件消融结论
单独改 system prompt 反而退步	abstract / §X	✅ 符合：原文消融数据
每轮迭代耗时与 token 预算	abstract 未提	⚠️ 存疑：原文未给；工程落地必须自己 benchmark
"七个可编辑组件类"具体类目	正文 §3.1/附录 A	⚠️ 存疑：解读未 fetch 核验；正文引用须独立核实

可读性精修意见

伪代码简化度：3.4 节伪代码是高度抽象版（rollouts / distill / evolve 均为黑箱），工程实现者需要原文 §X 的实际接口签名，建议改为"伪代码含三个黑箱函数，签名以原文 Algorithm 1 为准"。
"零再训练迁移"表述：迁移到 SWE-bench-verified 时是"freeze harness 不再演化"还是"零 fine-tune 但允许继续演化"，两种读法都会产生，建议原文 §X 核验后明确。
"非线性交互收益封顶"：局限节点到了但未量化"几个有效编辑后开始封顶"，建议有具体数字（如 3-4 个）才好让工程团队设定预期。
"self-attribution 对 regression 失明"：这个局限是全文最有工程预警价值的一句话，建议从局限节移到"对工程落地的启发"节独立成段。

工程落地：实际系统怎么用

最小可跑切入口（不动完整 AHE 闭环）

不需要等跑通 10 轮迭代，以下三步可以直接落：

Harness 仓库化：把 agent 的可编辑组件按文件分离

agent-harness/
  system_prompt.md
  tools.yaml
  middleware.py
  memory_schema.json
  skill_library/

每次改动附预测字段（无需跑 benchmark，用 assert 即可）：

# tools.yaml metadata
- name: "fetch_url"
  added_by: "iter3-evidence-001"
  prediction: "after this edit, fetch_url timeout errors will drop by ~20%"
  verified: false

自动 revert 脚本（轻量版，不需要 evolution agent）：

# 当 benchmark 分数不升反降，自动 revert 到上一版
if [ $(current_pass_at_1) -lt $(prev_pass_at_1) ]; then
  git checkout HEAD~1 -- tools.yaml middleware.py
fi

AHE 完整闭环复现难点

Terminal-Bench 2 搭建成本：TB2 需要预装 30+ CLI 工具（docker/helm/kubectl 等），冷启动环境约 2-4h；可以用 TB2 API 减少自建。
Evidence distillation 规模化：原始轨迹百万 token 级别，distill() 函数需要 prompt engineering + 成本控制，建议先用 GPT-4o-mini 做概念验证。
Evolution agent 选型：原文用 GPT-4o 作为 evolution agent，实测对工具类编辑的提案质量明显高于 GPT-4o-mini（建议 A/B）。
Benchmark 依赖风险：AHE 结论高度依赖 Terminal-Bench 2 的真实性；若该基准偏向 terminal/CLI 类任务，对 web/前端类 coding agent 的迁移性会高估。建议工程落地时在主 benchmark 之外维护一套 holdout 回归集。

坑汇总

坑	描述	缓解方案
Regression 盲区	self-attribution 只记得修好了啥，不记得弄坏了啥	独立维护回归 benchmark，每次迭代跑两组
迭代预算无上限	原文没说几轮收敛，实际可能 15-20 轮才封顶	设硬上限（如 20 轮或 $500 token budget）
Benchmark 偏差	TB2 偏 terminal 风格，其他场景迁移性未知	自建场景适配的 mini benchmark
文件级粒度过粗	一个文件中多处修改无法独立归因	强制"一次 commit 改一件事"规范