怎样评估一个会修改自身 Harness 的 Agent

1. 为什么静态 Agent 评估不了 Self-Evolution

1.1 自进化真正更新的是持久 Harness

论文把 agent harness 定义为围绕基础模型的结构化执行层，包括 system prompt、上下文管理、memory、skills、tool interface、orchestration、middleware、运行时隔离、反馈与验证机制等。设基础模型和不可变运行组件为 M，第 t 步可变 harness 状态为 H_t，则 Agent 快照可写为：

一个 self-evolving agent 会利用任务轨迹和反馈，把 H_t 更新为 H_{t+1}，然后在后续任务中继续使用新状态。不同方法更新的对象差异很大：ACE 写入条目式 skillbook/context，TF-GRPO 从 grouped rollouts 形成 experience store，AHE 则可能直接修改 prompt、middleware、tools 和项目文件。它们共同的性质不是“会反思”，而是更新结果跨任务持久存在，并改变下一次执行路径。

传统 benchmark 的常见协议却与这个性质相反：每个 task 独立运行，Agent 状态被重置，分数衡量的是一个固定系统。这样的协议可以比较静态能力，却直接删除了 self-evolution 想利用的状态连续性。即使把任务排成顺序，如果只看最后一条曲线，也无法回答是哪些更新造成了提升、收益是否来自直接接触过的任务、是否对未见任务有效，以及中间是否发生过严重回归。

1.2 现有评估缺少的不是更多任务，而是更多观察视角

论文将已有工作分成三类。静态 Agent benchmark 覆盖软件修复、终端操作、web/desktop、工具调用和交互式环境，但通常评估固定 Agent；SEA-Eval、LifelongAgentBench 等开始研究连续任务流，却主要覆盖 sequential/lifelong 形态；continual learning 提供 adaptation、transfer、retention、replay 和 forgetting 的概念，却通常以参数学习为中心。

SEAGym 由此提出一个互补缺口：现有 benchmark 已经拥有真实任务、环境和 verifier，缺少的是一层能够统一描述状态是否持久、任务是否重复、多久更新一次、哪些反馈可见、何时冻结快照、如何做 held-out transfer 和 replay的外部评估协议。

这一区分很重要。若只报告最终验证分数，一个频繁更新的方法可能看起来“学习得更快”，但其实只是反复接触同一分布；若只报告 ID test，某个 harness patch 可能对当前模型有效，却在 OOD domain 或另一 rollout backend 上失效；若只比较初始和最终快照，中间发生过的大规模运行时崩溃会完全消失。

2. SEAGym 的核心抽象：把演化过程视为一个环境

论文用 MDP 风格的形式表示评估过程：

状态 s_t 包含当前 Agent 快照、schedule 位置和可用任务上下文。环境在第 t 步采样任务批次 B_t，Agent 运行这些任务并产生轨迹 T_t，根据 visibility policy 获得反馈 F_t，再调用自己的更新规则：

这里最关键的边界是：SEAGym 不规定更新规则 U 应该怎样学习。 它规定外部可观察条件，包括任务分布、反馈可见性、更新 schedule 和评估视图；ACE、TF-GRPO、AHE 等方法仍保留各自原生的 update semantics。SEAGym 因而不是把不同算法改造成同一种算法，而是让它们在尽可能一致的暴露次数、冻结验证和 held-out assessment 下留下可比较记录。

这张图展示的是评估边界，不是一个新的训练算法。它证明 SEAGym 可以容纳 prompt、memory、skill 和 harness editing 等不同更新对象；它并不能保证这些方法天然公平，因为各方法初始 harness、原生 rollout 数量和更新开销仍可能不同，公平性依赖具体 run config 与保存记录。

3. Evolution Schedule：把“学习时序”变成显式变量

不同自进化方法没有统一的自然更新单位。有的方法每完成一个任务就更新一次，有的方法先聚合多条轨迹，有的方法在同一训练池上运行多个 epoch。若 benchmark 固定一种 schedule，就会把某种暴露模式的优势混进算法能力。

SEAGym 因此把以下字段写入实验配置：

论文默认实例采用 persistent state、跨 epoch 重复使用 train tasks、每个 train batch 后更新、epoch end 冻结验证。Appendix Algorithm 1 的执行顺序是：先保存初始快照 A_0，每批运行任务并收集 (T_t, F_t)，调用方法原生更新规则 U 修改 H_t，保存更新摘要和可选 checkpoint；每个 epoch 结束冻结 E_i 做 update-validation；训练结束再做 final ID、OOD 和 replay。

这个设计让 batch size 不再只是吞吐参数。对 LLM 驱动的 harness editing，batch 过小意味着证据局部但修改频繁，错误 patch 更容易累积；batch 过大意味着单次更新要在近似固定 token budget 下总结大量异质轨迹，每条轨迹得到的分析深度下降。论文后续的非单调 batch-size 结果正是对这一设计选择的验证。

4. Data Split 不等于 Evaluation View

SEAGym 保留传统的 D_train、D_val、D_test 来控制任务可见性，同时从这些 split 中物化出不同 assessment views。两者的职责不同：split 决定哪些信息可以成为更新证据，view 决定从什么角度检查冻结快照。

训练任务可以向方法暴露 trajectory、public error、verifier reward 和接口允许的 artifact。冻结 validation 不进入 update rule，final ID/OOD 也只从快照运行，不反馈给方法。Agent-visible task view 进一步排除 reference output、private assertion、split membership 和 held-out view label，防止评估元数据变成学习捷径。

但论文仍使用 validation 选择 best-validation snapshot 做主结果报告。也就是说，验证集不参与 harness 更新，却参与 checkpoint selection。这个做法符合常见模型选择流程，但阅读 Table 2 时必须知道：报告的是 A_star 而不总是最终 A_T；AHE 主实验的最佳快照恰好是 final，ACE 的选中快照则是 E4。

5. Rollout / Update 解耦与 Harbor 集成

SEAGym 在方法侧只要求两个薄接口：

rollout_adapter(A_t, B_t)
  -> trajectories T_t, verifier rewards, public errors, observed cost

update_adapter(H_t, B_t, T_t, F_t)
  -> updated harness H_{t+1}, update summary, snapshot reference

rollout adapter 用当前 harness 运行一批任务；update adapter 把轨迹转成方法原生输入并保存更新后的状态。这一拆分解决了一个工程冲突：benchmark runner 往往为每个 trial 新建 Agent 实例，而自进化状态必须存在于 trial 之外。

benchmark 侧复用 Harbor。Harbor 继续负责容器任务、环境、verifier、并发 job 和 trial artifact；SEAGym 增加外层 task index、schedule、快照编排、held-out views、规范化 metric records 与报告。它不复制 Terminal-Bench/HLE 的任务定义，而是保存 stable task id、source reference、attributes、split membership 和 visibility metadata。

6. 指标：区分局部更新、累计收益、迁移与遗忘

给定 verifier score (r(A,x)\in[0,1])，基础性能为：

若 task score 为二值，论文报告 success rate：

对第 i 个冻结评估点 E_i，SEAGym 同时定义相邻快照增益和相对初始快照的累计增益：

最终 ID / OOD gain 分别比较演化后和初始 Agent 在 held-out view 上的性能；forgetting rate 则取 replay 性能下降的非负部分。论文还记录 token、tool calls、runtime 和可用的 dollar cost。

一个单值 forgetting rate 仍会掩盖 task churn，因此 replay 诊断又引入两组指标。相邻快照的 DeltaFix / DeltaForget 统计本轮新解决和新丢失了多少任务；相对固定 A_0 的 fix / forget rate 则用固定分母回答“最初失败的任务有多少被修复”和“最初成功的任务有多少被丢失”。这两组指标不会反馈给更新 Agent，只用于离线诊断。

论文默认按 domain 做 macro average，避免任务数较大的 domain 支配跨域结论。主要论文指标使用 verified task score；execution exception、timeout、provider failure 和 middleware error 被保留为过程诊断，而不是偷偷转换成另一个成功标准。

7. 实验实例：任务、方法与可见反馈

主实验把 Terminal-Bench 2.0 与 HLE 组合成 source distribution。Terminal-Bench 提供带容器与 verifier 的命令行、软件工程任务；HLE 的 text-only Math/Physics 作为 source reasoning tasks，HLE text-only CS/AI 与 Engineering 则只用于 OOD transfer。

三种方法更新的状态范围不同。ACE 从历史 trajectory 构造持久 skillbook，主要保存通用过程规则；TF-GRPO 用 grouped rollout evidence 构造更具体的 task-family experience store，不做模型权重训练；AHE 根据 observability 直接编辑更广的 runnable harness，包括 prompts、memory、tools、middleware 和 project files。

这个比较不是三种“同构算法”的排行榜。它更像对三个更新作用域的诊断：prompt-visible reminder 能改变模型注意什么，task-family memory 能让相似任务的下一次尝试更有针对性，runtime harness patch 则能直接改变工具、完成条件和消息注入路径。更新范围越广，潜在迁移越强，破坏共享执行路径的风险也越大。

8. 主结果：验证提升并不等于稳定迁移

主结果使用每个方法自己的 best-validation snapshot：

8.1 AHE：更广的作用域带来更广的收益，也扩大故障半径

AHE 是唯一在 validation、ID 和 OOD 三个视图上同时为正的方法。Appendix 的 update artifacts 表明，这些收益并不只是 prompt 写得更好：AHE 增加文件、web、session 和 context-management tools，添加 HLE completion/verification enforcer，加入 artifact-cleanup rule，并修复 tool-error recovery 与 middleware message contract。它能改变搜索证据、恢复工具错误、验证答案和终止任务的实际执行路径。

8.2 ACE：可复用过程知识能迁移，但未必触达 verifier 条件

SEAGym 检查 ACE 选中 E4 快照中的 13 条 active skills。它们包括写文件后回读并检查格式、列举所有显式约束、时间不足时先写候选答案、构建失败后 clean build、缺工具时先安装依赖等。这些是可迁移的 execution hygiene，而不是任务答案。

但失败案例显示 reminder 的作用边界。polyglot-rust-c 中 Agent 确实编译并交叉验证了 Rust/C++ 输出，却留下临时二进制，违反最终目录只能有指定文件的约束；video-processing 生成了可解析 TOML，却把 landing frame 算错；db-wal-recovery 结构正确但 WAL 更新语义错误；path-tracing-reverse 仍执行了任务明确禁止的原始 binary。

8.3 TF-GRPO：具体经验强化 source behavior，但 OOD 出现反向信号

TF-GRPO 保存的经验比 ACE 更 task-family specific，例如先跑 failing tests、用 QMP socket 操作 QEMU、对数据 pipeline 做 round-trip check、解析 binary 时使用 unsigned read、模型推理前读取 id2label。这种更具体的记忆可以解释其 validation +17.1，但 ID 只有 +3.6，OOD 反而 -2.5；它的 rollout cost 也是三者最高的 2.33M tokens/task。

9. Replay 诊断：最终提升可以掩盖中间执行路径崩溃

论文把 AHE 的初始快照、每个 epoch 快照和最终快照重新运行在同一组 80 个 source-train tasks 上。初始 A_0 解决 34/80；E4 为 38，E8 为 37，E12 为 42；第 4 个 epoch 后的 E16 只解决 6/80，并出现 66 个 rollout errors；最终 A_T 恢复到 43/80，仅剩 5 个 errors。

这次崩溃不是通常意义上的“模型忘了如何解题”。保存的 update summary 把主要原因定位为 NexAU message-sequence contract violation：middleware 注入的消息不符合 token counter 和 schema 所需的 typed-message 结构。Iteration 19 把 legacy dictionary 改成 Message(role=Role.SYSTEM, content=...)，但 content 仍是 plain string；Iteration 20 才进一步改成 [TextBlock(text=...)]。修复共享消息路径后，当前 batch 从 1/20 恢复到 10/20，replay errors 从 66 降到 5。

最终 A_T 相对 A_0 修复 13 个初始失败任务，同时丢失 4 个初始成功任务，净增 9 个。polyglot-c-py 等任务在 artifact-cleanup rule 出现后变为成功，E16 因运行时错误中断，最终修复 runtime path 后再次成功；但 reshard-c4-data、若干 HLE 任务仍属于最终遗忘。

10. Batch Size：更新更多或一次看更多都不保证更好

论文固定 80 train tasks、相同 validation/ID view 和 5 epochs，只改变 AHE 的 batch size，因此更新次数分别为 40、20、10、5。

单次 update token 大致都在 3-4M，batch 增大并没有让分析预算成比例增长。Batch 10 不是计算不足，它每个训练任务分到的 update tokens 反而最多；问题在于一次只看到很窄的失败面，又进行更多次高方差 harness edit。Batch 80 则要在相近预算下总结 80 条异质轨迹，最显眼的 HLE-wide pattern 可能推动广泛 middleware 修改，却没有足够后续 update 修补副作用。

Appendix 给出具体故障：batch 10 的最终 update 因 max_interventions constructor mismatch 导致 10/10 ConfigError；batch 40 遇到 max_repetitions/max_iterations contract mismatch；batch 80 的 continuation 仍显示 runtime-unstable state。由此，batch size 在 harness evolution 中不是传统 SGD 的统计效率旋钮，而是证据覆盖、每条轨迹分析深度、编辑频率和错误修复机会之间的系统平衡。

11. Source Diversity：多样数据的作用是提供恢复证据，不是杜绝坏更新

mixed-source AHE 与 HLE-only AHE 都使用 80 train tasks、batch 20、5 epochs。Mixed source 同时包含 Terminal-Bench 的工具、文件、环境和执行失败，以及 HLE 的知识、数学、物理与答案验证失败；HLE-only 主要提供 reasoning 与 verification signal。

HLE-only 并非从未学到东西。E12（第 3 个 epoch 的中间快照）使 validation 从 40.0 升至 42.9，ID 达到 47.3（+7.3），OOD 达到 25.0（+3.8）。保存的更新显示它学会阻止 premature answer、要求 rejection 后使用独立方法和代码验证，并用 rule-based domain analyzer 替换持续返回空内容的 LLM critic。

但最终快照在 validation、ID、OOD 上全部变成 0.0。Iteration 18 的 before_model hook 为 self-verification 注入 plain dictionary message；后续 typed-message runtime 不再接受这种结构，Iteration 20 出现 20/20 RuntimeError。也就是说，产生中间收益的 verification middleware 同时成为最终单点故障。

Mixed-source run 也经历了 E16 崩溃，所以 source diversity 不能保证更新无害。它的优势是故障证据更分散：Terminal-Bench 暴露 file/tool/session/context、artifact cleanup、long-running command 和 tool recovery，HLE 暴露 verification 与 contradiction。共享 message contract 出问题时，两类任务同时失败，系统更容易识别它是执行路径故障，并在后续 update 中修复。最终 mixed-source 保留 validation +17.1、ID +9.1、OOD +6.3。

12. Cross-Model Transfer：Harness 会适配产生它的 Rollout Backend

论文用 DeepSeek-V4-Flash、GLM-5.1、GPT-5.4 分别产生 AHE 更新，再把选中的 evolved harness 与三个 rollout model 交叉组合。每个单元都相对同一 rollout model 的初始 harness 计算 gain，因此可区分“模型本身强”与“这个 harness 对该模型是否有帮助”。

对角线 ID gain 都为正，范围 +3.6 到 +9.1，说明 AHE 能适配产生训练轨迹的原生 backend。但跨 backend 结果明显不对称：DeepSeek-evolved harness 帮助 GLM ID +7.3，却伤害 GPT-5.4 ID -3.6；GPT-5.4-evolved harness 帮助自身 ID +5.5，却使 GLM ID -7.3。更关键的是，GPT-5.4 同 backend 的 ID +5.5 并未转成 OOD gain，反而是 -7.5。

Appendix artifacts 给出机制解释。DeepSeek 轨迹暴露 buggy verification、artifact residue、heredoc/sleep chaining 与 message-contract error，于是更新集中在 verification、tool recovery、cleanup 和 runtime path；GLM 轨迹常出现 text-only reasoning、长时间 research 却不写输出，于是 harness 加强 first-turn workflow、action forcing 和 progress reminder；GPT-5.4 轨迹更多暴露 self-contained artifact constraint、validation attempted but not passed、loopback redirect，于是更新集中在 execution guard 和 validation sufficiency。

13. 成本与可复算性：记录了什么，没记录什么

论文把 cost 作为一级视图，而不是在性能表之后补一句“开销可接受”。Table 2 显示 TF-GRPO rollout 为 2.33M tokens/task，ACE 为 1.93M，AHE 为 1.46M；update tokens 则是 TF-GRPO 1.60M/update、AHE 3.91M/update，ACE 原生更新 token 没有从规范化记录中恢复。

Appendix 的 training-run records 进一步报告：主 AHE 保存 1,053.8M rollout tokens、78.1M update tokens 和 14h06m Harbor-reported task runtime；ACE 为 1,384.0M rollout tokens、13h55m，update token 缺失；TF-GRPO 为 2,615.1M rollout tokens、32.0M update tokens，runtime 缺失。这里的 runtime 是从保存 task jobs 去重求和，不包含一致可比的 native update wall time 与外部排队，因此不能解释为端到端训练时长。

这种缺失本身体现了评估基础设施的现实难点：当方法使用不同 provider、原生 update loop 和 artifact 格式时，“同一列 cost”必须先定义边界。SEAGym 保存 normalized task records、verifier outputs、cost records、update summaries、snapshot references 和 backend job references，使研究者可以不重跑环境就重新聚合；但没有被原生方法暴露的数据不能凭空补齐。

14. 论文真正建立了什么

14.1 有直接证据支持的结论

• 静态 final score 会漏掉 self-evolution 的关键过程。AHE 的 42/80→6/80→43/80 replay 轨迹是最直接案例。
• update-validation、ID、OOD、replay 与 cost 提供互补信号。TF-GRPO validation +17.1 与 OOD -2.5、GPT-5.4 AHE 的 ID +5.5 与 OOD -7.5 都证明单视图会得出不完整结论。
• harness edit 的故障可能是共享 execution contract 崩溃，而不是模型知识遗忘。E16 的 66 个 rollout errors 与 typed-message 修复构成机制证据。
• batch size、source diversity 和 rollout backend 会改变可见 failure surface 与 harness reliability，且关系非单调。
• ACE、TF-GRPO、AHE 学到的 artifact 作用范围不同，因此收益与失败模式不能只按一个总分解释。

14.2 论文提示、但尚未充分证明的结论

• SEAGym 的协议可以扩展到 web、desktop、多 Agent、长时软件工程和在线任务流，但当前实证只覆盖 Terminal-Bench 2.0 与 HLE。
• 形式化允许 model-weight update、online RL 或 hybrid system，当前集成只验证了 model-external harness/state evolution。
• 多样 source 在本次 AHE run 中帮助最终恢复，不等于任意多样化都提升稳定性，也没有建立数据多样性的定量因果规律。
• Cross-model matrix 显示 backend-conditioned failure surface，但只有三个后端和少量 selected snapshots，尚不能形成通用的 harness portability 定律。
• 过程 artifact 能帮助解释故障，但人工 inspection 或可选 LLM-as-judge diagnosis 是次级证据，不能替代 verifier outcome。

15. 局限与批判性评价

第一，论文展示的是一个强诊断性实例，而不是充分统计化的 benchmark study。每个关键 setting 看起来主要对应一条训练轨迹，正文未报告多随机种子均值、方差或置信区间。AHE 本身会发生 0 分崩溃与大规模恢复，在这种高方差系统里，单次 run 很适合做故障剖析，却不足以稳定排序算法。

第二，跨方法比较保留 native update semantics，这提高生态兼容性，也削弱严格控制。三种方法的 V_0、ID_0、OOD_0 不完全相同，TF-GRPO 还有原生 grouped rollout evidence，ACE 的 update tokens 缺失。SEAGym 通过记录暴露这些差异，但“共同 protocol”不等于“所有计算与初始状态完全一致”。

第三，multi-view evaluation 成本很高。保存多个快照并重复运行 validation、ID、OOD 和 replay 能提升可解释性，却会显著增加 task executions。论文承认需要 snapshot selection、adaptive replay 和 budget-aware evaluation；在更长时间流或更昂贵环境中，全量回放可能不可行。

第四，当前 OOD 主要是从 HLE Math/Physics source 转到 HLE CS/AI/Engineering target，并与 Terminal-Bench mixed source 共同训练。它包含 domain shift，却还不是不同交互环境、不同 tool API 或真实时间漂移的全面 OOD。Cross-model evaluation补充了 backend shift，但 task-domain 与 model-backend 的交互仍需要更系统的析因实验。

第五，SEAGym 能记录 harness diff，却没有自动判断 patch 是否安全。AHE 案例说明一个 middleware 类型错误可以让大量任务在模型调用前就失败。生产系统还需要 schema validation、sandbox、canary rollout、rollback、权限控制和更新审批；这些属于可在 SEAGym 中测量的对象，不是框架已经提供的安全保证。

第六，论文使用 best-validation snapshot 做主表有合理性，却同时说明“final evolution state”不是默认可信的交付物。真正在线部署不能总在事后回到已知最优 epoch，尤其当未来任务分布不可见。SEAGym 下一步的重要问题应是怎样用不泄漏 test 的在线信号做 early stopping、自动 rollback 和 snapshot selection。

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

ACE、TF-GRPO、AHE 讨论“更新机制是什么”，SEAGym 讨论“怎样知道更新机制真的有效”。四篇论文可以放在同一坐标系中：

因此，SEAGym 对“AI 自进化”给出的最重要约束是：系统修改了自己，不等于系统学会了东西。 只有当变化在冻结验证、未见 ID、OOD、replay 和成本等独立视图上表现出可重复的收益，而且 harmful update 可以被定位和回滚，才有资格称为稳定 evolution。

结论

SEAGym 的贡献不是再提供一个更难的 Agent 题库，而是纠正评估单位。Self-evolving agent 的对象是持续变化的 harness，因而评估也必须围绕状态变化展开：训练证据与冻结验证分离，数据 split 与 assessment view 分离，rollout 与 update 分离，最终性能与过程诊断分离。

论文用三个方法展示这种分离为何必要。AHE 获得最广的 validation/ID/OOD 提升，却曾因 middleware message contract 在中间快照崩到 6/80；ACE 学到可迁移过程规则，但对 verifier 条件的控制有限；TF-GRPO 获得大幅 validation gain，却在 OOD 上下降。Batch 20 的正结果、HLE-only final 归零和 cross-model heatmap 又进一步说明，更新频率、证据来源和 rollout backend 都会改变 harness 的可靠性。

所以这篇论文真正建立的不是“哪个自进化方法最好”，而是一套更严格的提问方式：更新由什么证据驱动，作用于哪个持久状态，何时改善或回归，能否迁移到未见任务与另一模型，旧能力是否仍在，以及这一切付出了多少可核算成本。