复旦、北大、上海奇绩智峰联合出的 Agentic Harness Engineering(AHE)做了一件很具体的事:让 GPT-5.4 驱动的 Coding Agent 在 Terminal-Bench 2 上的 pass@1 从 69.7% 涨到 77.0%,绝对 +7.3 个百分点,超过 OpenAI 官方 Codex-CLI 的 71.9%,也超过同期两条主流自演化基线 ACE(68.9%)和 TF-GRPO(72.3%)。换到 GPT-6.0 上,他们的同名 NexAU-AHE 在 Terminal-Bench 2 leaderboard 上跑到 84.7%,全球前三。

值得记下来的不是这几个数字,而是它怎么涨上去的。AHE 没有调模型权重,没有改评估框架,只让一个 Evolve Agent 在一个被严格围出来的工作区里改 Harness 自己。这件事能跑通的关键,是它把"哪些组件可以改、改了之后哪里能看到信号、看到信号之后用什么口径决策"全部当成一等公民设计了出来。

上一篇 把 Harness Engineering 的概念边界讲清楚:人怎么把 Agent 工作流托稳。AHE 这篇工作把这条线往前推了一步——当 Harness 自己开始进化,工程师的工作会重新分配。

一、Harness 的下一步是「让它自己改自己」

Harness 的发现和优化是一个工程问题。组件由 prompt、工具、middleware、skill、sub-agent、长期记忆这一套构成,每一个都需要建模能力 + 任务环境同向的判断力,再依赖大量长尾经验试出来。在论文作者的口径里,这件事不应该全部落在一个团队几个工程师身上:人类的注意力是稀缺品,能交给 agent 的优化目标,应当尽量交给 agent 自己。

这就引出 AHE 论文一直在敲的那句问题:在 Harness Engineering 的迭代环节里,哪些部分可以被自动化?怎么让 Harness 从经验中学习并改进?

把它翻译成更工程的语言:把 Harness 当作一份代码资产,在一个观察-修改-验证-回滚的回路里,让它跟着评测信号自动生长。这个目标听起来很自然,但要落得下来必须解决三件事:

  1. 给 Evolve Agent 一片清晰的工作区,让它知道哪些文件可改、哪些必须冻结。
  2. 把每一轮 rollout 产生的 trace、报错、覆盖率、性能、回归信号,整理成一份它能读得懂、读得起的修改证据。
  3. 给修改本身一个可对账的语义:每次改动要附预测,下一轮跑完跟预测对照,不一致就把这次改动回滚掉。

AHE 的三层可观测性回路就是为这三件事服务的。

二、Harness 的三种视角

论文先把 Harness 拆成三种视角,这一步看起来像 framing,但它其实定下了后面所有设计的口径:

  • Harness as wrapper:Harness 是包在模型外面的一个工程外壳。System prompt、工具定义与实现、middleware/hook、skill 文档、sub-agent 编排、长期记忆、日志与可观测——这些组件共同把模型的行为从一发即逝调成稳定可重复,是把模型迈向长程任务的第一层保证。
  • Harness as proxy:Harness 是模型和环境之间的一条双向中介。下行方向上,把客观存在的代码仓、用户意图、环境状态、外部信息塞进模型;上行方向上,把模型的动作落实成实际操作、检验、回写到环境。开发者过去手工拼 prompt、复制 terminal 输出、复制外部文档内容,本质就是在做 proxy。AHE 把它显式化。
  • Harness as dataset:这是最关键的一种看法。Harness 自身被当成一个可被进化的客体——它是一份会成长的数据,不是一段写死的脚手架。

第三种视角是整篇论文的发动机。把 Harness 看成数据,那它就可以被 agent 编辑、被 git 管理、被 diff 回滚、被 ablation 解剖。一旦 Harness 有了可被对账的数据形态,Evolve Agent 就有了它能动手的对象。

三、可观测的进化回路:组件、经验、决策

AHE 给 Harness 设计了三层可观测性:

可观测性层 关心什么 由谁实现
组件可观测(Component) 哪些 Harness 组件存在、彼此之间什么关系、版本怎么变 NexAU Harness 框架
经验可观测(Experience) 每一轮跑完之后,做对了什么、做错了什么,有没有出现典型 hack Agent Debugger
决策可观测(Decision) 这一轮该改哪里、为什么改、预期能救哪些用例 Evolve Agent

三层之上跑三个角色:

  • Coding Agent 基于 NexAU Harness 跑用户级任务。这个角色不变。
  • Agent Debugger 把每一轮 Coding Agent 产生的原始 trace(约 10M token 量级)整理成结构化、可消费的经验。它先用一组 QA Sub-agent 做去噪与抽取,再用一个 Cleaner 做单题分析,最后汇总成约 10K token 的概览报告。token 压缩比是 1000:1。
  • Evolve Agent 拿到 Agent Debugger 给出的经验,决定本轮改 Harness 的哪个组件、改成什么样、为什么。它的修改全部以 git commit 形式落到 Harness 的工作区。

整条回路用一句话总结:rollout 产生 trace → Agent Debugger 把 trace 浓缩成经验 → Evolve Agent 把经验翻译成对 Harness 的修改 → 下一轮 rollout 验证修改。组件、经验、决策,分别对应 Harness 现在长什么样、上一轮发生了什么、下一轮该怎么变。

这套设计最容易被忽略的是 token 经济学。原始 trace 不可被 Evolve Agent 直接消费——它太长、噪声太多、价格太高。把它压成 10K token 的结构化报告,是把可观测性从「能看到」推到「能用来决策」必须做的工程。

四、自由的边界比自由本身更重要

AHE 设计中最值得拆开看的是 Evolve Agent 的修改边界:

  • 可改:workspace 内的 Harness 组件文件,包括 7 类组件的代码、模板、配置。
  • 不可改:评估框架、LLM 配置、原始 system prompt、benchmark 输入。

这条边界的真正用意不是约束,而是反 hack。一旦 Evolve Agent 能动评估框架,它会很快学会绕过题目、把 stub 写进答案、修改测试期望——所有 reward hacking 工作都会以这种形态出现。冻结评估侧之后,Evolve Agent 就只能在「让 Harness 真正变好」和「失败」之间二选一,而失败会立刻被回滚机制吞掉。

这种设计的另一面,是它强迫修改回到组件层。Evolve Agent 没法用一个上帝视角的 prompt 一把梭把所有问题都解决,它必须把改动落到 middleware 的 hook、tool 实现的边界、长期记忆的存储格式这些颗粒度上。这些层都比 prompt 更可分块测试,也就更适合作为进化目标。

修改本身也被强约束:每一次改动都要附一份"变更菜单"——改了哪些组件、根据哪些失败证据改的、预期能救哪些用例、预期会不会导致已通过用例回归。下一轮跑完之后,跟这份菜单对账。如果一次"预测会通过的修改"实际带来了回归,这次改动会被自动回滚。

这套机制把 Evolve Agent 强制推到了 Hypothesis-driven debugging 的姿态。它不能"凭直觉改",它必须给出可证伪的命题,并接受证伪。

五、最值得引用的几个数字

主实验:在 Terminal-Bench 2 上,AHE 把 GPT-5.4 驱动的 Coding Agent 从 69.7% 推到 77.0%,绝对 +7.3 个百分点,相对 +10.5%。这个分数不仅压过 OpenAI 自家的 Codex-CLI(71.9%),也压过两条同期自演化基线 ACE(68.9%)与 TF-GRPO(72.3%)。

跨任务迁移:把 Terminal-Bench 2 上演化出的 Harness 直接搬到 SWE-Bench Verified,不再继续演化、不让 token 消耗或评估反馈跨域漏出,AHE 仍以 75.6% 拿下整体最高,分项里 django、sympy、scikit-learn、pydata、astropy 五个仓库全部领先。这件事说明 AHE 学到的是一类问题的结构,不是某个 benchmark 的特解。

跨模型迁移:拿同一份 GPT-5.4 演化出的 Harness 套到 Qwen-3.6-Plus、Gemini-3.1-Flash、DeepSeek-V4 上跑,每个模型都拿到 +5.1 ~ +10.1 的绝对提升。说明 Harness 学到的不是模型身世定制的 trick,而是任务结构本身的规则。

组件级消融(Table 3,Terminal-Bench 2 的 89 题集):

变体 All Easy Medium Hard
NexAU₀ seed 69.7% 87.5% 78.2% 51.7%
+ memory only 75.3% 90.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.8% 100.0% 88.2% 53.3%

按直觉,prompt 是策略性最强的组件,单独留它应该最强。事实上单独留 prompt 是所有变体里最弱的一档(67.4%),还低过 NexAU₀ seed 自己。

六、最反直觉的一张消融表,背后是同一个原理

为什么 prompt-only 反而最弱?论文给了一个挺克制的解释:prompt 修改是策略性的,但策略不可分块测试。一次 prompt 修改通常会同时影响多种行为,下一轮看到失败时很难指认是哪一句改坏的;而 memory 与 tool 的语义是事实性的,每一处改动都对应着一段可单测的代码或数据,进化器更容易把某个修改和某个分数变化挂上钩。

这条原理一旦说出来,看起来就是常识:能进化的,必须先能被分块测试。但反过来也成立——

  • 当一项工作的"修改单元"和"评测单元"对不上号时,自动化进化会变成博彩。
  • 改 prompt 的常见痛苦——「为什么改了这句反而退步」——本质上是评测信号粒度太粗。
  • 想让一类组件被自动优化,先把它的评测从 all-or-nothing 变成可分块。

AHE 论文走过的弯路印证了这点。最早一版只在 Terminal-Bench 2 的 30 道难题上演化,结果连演 10 轮难题数纹丝不动;分析版本历史发现,Evolve Agent 在 hack——它写过 Golden Gate 检测、splice-offset 检查、Caffe pipeline 流模型适配,全都是靶向于单一题目信号的。后来的修复路径是:扩到 89 题、引入 partial pass 作为单题诊断信号、把"建议性 prompt"换成"失败驱动的行为约束 + 自动回滚"。修完之后,分数从 76% 进一步提到 77.0%,更重要的是修改分布回到健康——middleware 37% + tool 48% + prompt 10%,长期记忆几乎不被频繁动。

七、给我们做工程的几条可迁移启示

把 AHE 抽象成可迁移的工程纪律,能拿走的至少有以下几条:

第一,进化的前提是可观测,不是更聪明的 agent。如果一次 rollout 留下的 trace 既看不出哪一步出错、也看不出失败的类型,再强的 Evolve Agent 也只能瞎改。10M → 10K 的浓缩链路是实打实的工程活。

第二,「冻结的部分」和「可改的部分」要先定下来再开干。AHE 把评估框架冻死,是一条把 reward hacking 卡在源头的简单铁律。如果你打算让 agent 自动改自己的工程,就先想清楚哪些文件不能在它的修改范围里出现。

第三,partial pass 比单一 pass/fail 更适合做演化信号。哪怕题目最终没过,能告诉 Evolve Agent「至少哪几个子步骤跑通了」,进化方向就有了梯度。这件事和监督学习里的 dense reward 是一个道理。

第四,hack 是进化压力的副产品,不是 bug——它告诉你哪个评测设计漏了。AHE 自己第一版就被 Evolve Agent hack 过一遍,作者把它当作信号修评测,而不是惩罚 Evolve Agent。这是把人和 agent 放进同一套 PDCA 的姿态。

第五,Harness 可以放进 git,可以做 diff,可以回滚。看上去这只是工具选择,但它的真正含义是——把软件工程的纪律加在 agent 自己身上。Agent 可以成为会改 Harness 的开发者,但它必须接受跟人类开发者同样的版本控制、code review、回归测试。

结语

AHE 的核心命题:当目标足够清晰、修改单元足够小、评测信号足够细,Harness 自己会开始进化。

可复制的最小版本不复杂:一片冻结-可改边界明确的 workspace,一份能让模型读得起的修改证据,一条「修改要附预测、和实跑对账、不一致就回滚」的纪律。三件事到位,一个 Evolve Agent 雏形就能跑起来。

复旦这篇工作的工程意义大于绝对分数。它是把 Harness Engineering 这门工艺往 self-improving software 推进了一步。下一阶段的 Coding Agent,可能不是更大的模型加更多工具,而是一份会一直变得更顺手的 Harness。

论文:arxiv 链接见项目主页 代码:china-qijizhifeng/agentic-harness-engineering 报道:机器之心《全球排名前三,复旦自进化 Harness Engineering 让 GPT-5.4 再涨 7 个点》(2026-05-20)