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

> **论文**：*SEAGym: An Evaluation Environment for Self-Evolving LLM Agents*  
> **作者**：Congjie Zheng, Chuanyi Xue, Bin Liang, Jun Yang, Changshui Zhang  
> **单位**：清华大学自动化系、北京信息科学与技术国家研究中心  
> **版本**：arXiv:2606.17546v1，2026-06-16；PDF 中未看到正式会议或期刊录用信息  
> **论文类型**：评估环境与实证诊断，不是新的自进化算法

## 阅读主线

SEAGym 研究的不是“怎样让 Agent 自进化”，而是一个更基础的问题：**当 Agent 会在任务之间持续修改 prompt、memory、skill、tool、middleware 或运行配置时，怎样证明这些修改真的形成了可复用能力，而不是记住近期任务、破坏旧能力、增加成本，或者只在某个模型后端上碰巧有效？**

论文的论证从一个评估错位开始。传统 Agent benchmark 通常把每个任务视为彼此独立的 episode，运行前恢复固定状态，最后报告一个静态 Agent 的平均分；但 self-evolving agent 的核心恰恰是跨 episode 保留并修改持久状态。顺序式或 lifelong benchmark 虽然保留了时间轴，却经常只给出一条总分曲线，仍难以区分训练任务拟合、冻结验证提升、ID/OOD 迁移、旧任务遗忘、运行时故障和更新成本。

SEAGym 的回答是：不要把 self-evolution 压成一个最终分数，而要把它建模为**带持久状态、显式更新时序和冻结快照的评估过程**。环境负责规定任务来源、可见反馈、schedule 和 assessment views；被测方法保留自己的 rollout policy 与 update rule。每次更新后保存快照，再分别检查 update-validation、ID transfer、OOD transfer、replay 和 cost。这样，评估对象从“最终 Agent”扩展为“Agent 的整个演化轨迹”。

一句话概括：**SEAGym 把静态 benchmark 改造成一个能够观察 Agent harness 如何变化、何时变好、在哪里退化以及付出多少成本的动态评估环境。**

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

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

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

\[
A_t = (M, H_t)
\]

一个 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 上失效；若只比较初始和最终快照，中间发生过的大规模运行时崩溃会完全消失。

**论文主张**：self-evolution 的评估单位不应只是 task score，而应包括产生每次更新的证据、更新时序、冻结快照、迁移与保留视图、成本和可诊断 artifact。

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

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

\[
\mathcal{M} = (\mathcal{S}, \mathcal{A}, \mathcal{P}, \mathcal{R}, \rho)
\]

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

\[
H_{t+1}=U(H_t, B_t, T_t, F_t)
\]

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

![Figure 1：SEAGym 的 train、validate、test 与多视图评估流程](./SEAGym-论文汇报.assets/fig1-seagym-overview.png)

*图源：论文 Figure 1，第 4 页。Train 阶段让方法根据任务轨迹和可见反馈修改自身；Validate 阶段冻结多个快照并测量更新轨迹；Test 阶段比较初始与演化后快照在 ID、transfer/OOD 和 replay 上的差异。图中同时把 verified metrics 与基于保存 artifact 的过程诊断分开。*

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

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

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

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

| Schedule 字段 | 它控制什么 | 不显式记录会产生的混淆 |
|---|---|---|
| state persistence | episode 之间是否保留 harness | 无法区分静态 Agent 与真正跨任务学习 |
| task reuse | 任务流只遍历一次还是跨 epoch 重复 | 重复暴露可能被误写成更强更新规则 |
| train size | 每个 epoch 从 source pool 选多少任务 | 方法间看到的经验总量不可比较 |
| batch size | 累积多少 task trajectories 后更新 | 更新频率与单次证据密度被混在一起 |
| number of epochs | 训练池被遍历多少轮 | 无法观察中间快照、恢复或后期过拟合 |
| updates per batch | 每批执行多少次原生更新 | 更新计算量可能隐藏在相同 task 数之后 |
| assessment timing | 在哪些边界冻结并评估 | 只看最终状态会漏掉 useful intermediate snapshot |

论文默认实例采用 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 决定从什么角度检查冻结快照。

| 角色 | Pool / view | 要回答的问题 |
|---|---|---|
| 更新证据 | `B_t ⊂ D_train` | 哪些轨迹和公开反馈驱动下一次 harness update？ |
| 过程评估 | `V_update-val ⊂ D_val` | 不把验证任务作为更新证据时，中间快照是否改善？ |
| ID transfer | `V_ID ⊂ D_test` | 更新能否迁移到 source distribution 中未见任务？ |
| OOD transfer | `V_OOD ⊂ D_test` | 更新能否迁移到目标域或分布偏移任务？ |
| replay / retention | `V_replay` | 旧任务是否保留、遗忘、回归或恢复？ |

训练任务可以向方法暴露 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 在方法侧只要求两个薄接口：

```text
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。

**本文解读**：SEAGym 的主要工程贡献不是发明新的 task runner，而是把“静态 task backend”与“跨 task 的 persistent learner”之间缺失的状态层补上。这个外层协议使原有 benchmark 可以被重新利用，但也意味着扩展到新领域依赖其能否提供稳定 task id、可重复环境和可靠 verifier。

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

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

\[
Perf(A,D)=\frac{1}{|D|}\sum_{x\in D}r(A,x)
\]

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

\[
SR(A,D)=\frac{1}{|D|}\sum_{x\in D}\mathbb{I}[r(A,x)=1]
\]

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

\[
UVG_i^{prev}=Perf(E_i,V)-Perf(E_{i-1},V)
\]

\[
UVG_i^{base}=Perf(E_i,V)-Perf(E_0,V)
\]

最终 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。

| 设置 | 数量与配置 |
|---|---|
| source train | 80 tasks |
| frozen update-validation | 35 tasks |
| held-out ID test | 55 tasks |
| held-out OOD test | 80 HLE CS/AI + Engineering tasks |
| 默认 schedule | 5 epochs，batch size 20，每个 train batch 1 次 SEAGym update |
| runtime | task timeout 1800 秒，并发 16，除非 run-specific config 覆盖 |
| 主模型后端 | DeepSeek-V4-Flash |
| 被测方法 | ACE、TF-GRPO、AHE |

三种方法更新的状态范围不同。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. 主结果：验证提升并不等于稳定迁移

![Figure 2：AHE、ACE、TF-GRPO 的训练与冻结验证曲线](./SEAGym-论文汇报.assets/fig2-baseline-curves.png)

*图源：论文 Figure 2，第 6 页。曲线显示 AHE 验证性能在第 4 个 epoch 附近严重下降后恢复；ACE 变化较小；TF-GRPO 的训练和验证也不是单调增长。单看最终点无法解释这些轨迹。*

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

| 方法 | Val `V0 -> V*` | UVG | ID `ID0 -> ID*` | IDG | OOD `OOD0 -> OOD*` | OODG | rollout tok./task | update tok./update |
|---|---:|---:|---:|---:|---:|---:|---:|---:|
| AHE | 40.0 → 57.1 | +17.1 | 40.0 → 49.1 | +9.1 | 22.5 → 28.8 | +6.3 | 1.46M | 3.91M |
| ACE | 37.1 → 40.0 | +2.9 | 30.9 → 34.5 | +3.6 | 22.5 → 25.0 | +2.5 | 1.93M | 未记录 |
| TF-GRPO | 31.4 → 48.6 | +17.1 | 30.9 → 34.5 | +3.6 | 26.3 → 23.8 | -2.5 | 2.33M | 1.60M |

### 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。它能改变搜索证据、恢复工具错误、验证答案和终止任务的实际执行路径。

**直接证据**：AHE 的 UVG、IDG、OODG 分别为 +17.1、+9.1、+6.3，覆盖三个视图。

**限制**：这些数字来自一个主训练轨迹，且 AHE 初始分数与另两种方法不同；它们支持“该实例下更广 harness edit 获得更广迁移”，不能单独证明 AHE 普遍优于 ACE/TF-GRPO，也不能证明每个 patch 都是正贡献。

### 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。

**直接证据**：ACE 在 SEAGym 上只获得 +2.9 validation、+3.6 ID、+2.5 OOD。它说明 skillbook 学到的过程规则有小幅跨任务价值，也说明 prompt-visible skill 不会自动成为 verifier-equivalent runtime guard。

### 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。

**论文主张**：grouped rollout evidence 能快速强化 source distribution 上的行为，但更新活动和 validation gain 本身不能证明 transfer。

**本文解读**：SEAGym 在这里提供的价值不是宣告 TF-GRPO 失败，而是把“source curve 很漂亮”和“shifted target 上更好”拆成两个独立命题。OOD -2.5 是不能被平均 headline 隐藏的反证。

## 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。

![Figure 4：AHE train replay 的成功率、相邻任务 churn 与相对 A0 的修复/遗忘率](./SEAGym-论文汇报.assets/fig4-replay-diagnostics.png)

*图源：论文 Figure 4，第 8 页。左图显示 epoch 4 的断崖与 epoch 5 恢复；中图说明恢复时大量任务被重新修复；右图表明中间快照相对 A0 的 forget rate 一度接近 90%。*

这次崩溃不是通常意义上的“模型忘了如何解题”。保存的 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 任务仍属于最终遗忘。

**直接证据**：initial-vs-final 表只能看到 34→43，完全看不到 42→6→43 的过程，也无法区分 task reasoning 退化和共享 middleware 崩溃。

**论文主张**：self-evolution 的 forgetting 不只发生在知识层，还可能表现为 execution contract 被一次 harness patch 破坏。冻结 snapshot、replay 和 error taxonomy 必须共同存在，才可能定位这种故障。

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

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

| Batch | 更新次数 | Validation 初始→最终 | ID 初始→最终 | update tok./update | update tok./train task | 诊断 |
|---:|---:|---:|---:|---:|---:|---|
| 10 | 40 | 37.1→22.9 (-14.3) | 38.2→23.6 (-14.5) | 3.13M | 0.31M | 证据窄、修改频繁，configuration/runtime drift 累积 |
| 20 | 20 | 40.0→57.1 (+17.1) | 40.0→49.1 (+9.1) | 3.91M | 0.20M | 证据多样性、逐轨迹深度和修复机会最平衡 |
| 40 | 10 | 37.1→40.0 (+2.9) | 41.8→43.6 (+1.8) | 3.36M | 0.08M | 能看到 shared failure，但异质任务分析变薄 |
| 80 | 5 | 42.9→25.7 (-17.1) | 41.8→25.5 (-16.4) | 3.57M | 0.04M | 证据过载，显著全局模式压过长尾错误，修复机会少 |

单次 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。

**本文解读**：论文并没有证明“数据越杂越好”。它更具体地说明，训练源决定哪个 harness 子系统收到最多错误证据，也决定更新会集中到哪里；多样源在本实验中的价值主要是扩大可观察 failure surface，并为坏 patch 提供后续恢复线索。

## 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 对该模型是否有帮助”。

![Figure 5：AHE evolved harness 在不同 rollout model 上的 ID 与 OOD gain](./SEAGym-论文汇报.assets/fig5-cross-model-transfer.png)

*图源：论文 Figure 5，第 8 页；完整数值见 Appendix Table 28。行表示产生 harness update 的模型，列表示评估时的 rollout model。对角线 ID 全为正，但 OOD 对角线并不稳定。*

| Evolved with \ Evaluated with | DeepSeek ID / OOD | GLM ID / OOD | GPT-5.4 ID / OOD |
|---|---:|---:|---:|
| DeepSeek | +9.1 / +6.3 | +7.3 / +0.0 | -3.6 / -8.8 |
| GLM | +7.3 / -5.0 | +3.6 / +3.8 | +0.0 / -5.0 |
| GPT-5.4 | -1.8 / +3.8 | -7.3 / -1.3 | +5.5 / -7.5 |

对角线 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。

**直接证据**：harness transfer 在 failure surface 相似时较强，在模型行为或目标域改变后可能中性或负向。

**限制**：GLM training run 的 final validation 从 31.4 跌到 0.0，Table 28 使用的是 epoch 1 best snapshot；GPT-5.4 使用 epoch 3 selected snapshot。若只看 cross-model heatmap而忽略训练轨迹，会高估最终演化状态的可靠性。

## 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 暴露的主要风险 |
|---|---|---|---|---|
| ACE | itemized context / skillbook | trajectory、feedback、reflection | 可审计、增量保存可复用过程知识 | reminder 可能停在 verifier 条件之前，SEAGym 增益温和 |
| TF-GRPO | grouped experience/context | 多 rollout 相对证据 | 形成更具体 task-family 策略 | source validation 强但 OOD 下降，rollout cost 高 |
| AHE | prompt、tool、middleware、files 等 harness | observability 与失败轨迹 | 能修改实际执行路径，迁移范围更广 | 一次 patch 可破坏共享 runtime contract，跨模型不稳定 |
| SEAGym | 不更新 Agent，组织评估过程 | verifier、snapshot、held-out views、replay、cost | 把提升、迁移、遗忘、成本与故障分开 | 评估昂贵，当前实例任务/模型/随机种子覆盖有限 |

因此，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 的可靠性。

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