01 · OVERVIEWarXiv:2609.04280 · 2026-09-03

把 harness code 本身放进评测与优化循环

EvoHarnessBench 不是让 Agent 写 harness，而是把 tools、skills、specialist agents 分阶段扩张，测试部署退化、持久适应、forward transfer 与 forgetting。本文明确它与 harness coding 的边界，并拆解 17 条 streams、802 个任务与三条演化轴。

先分清谁在写代码、谁在执行任务

评测对象

这篇与前八篇的方向相反：外部平台在增加 tools、skills 或 specialist agents，被测系统要适应变化。code-based Meta-Harness 只是若干 adaptation baseline 之一；benchmark 本身不要求每个 Agent 都写 harness code。

核心问题

因为部署中的 harness 不会静止：工具目录、技能库和 specialist roster 会不断扩张，旧经验可能失效，选择空间也会变大。 EvoHarnessBench 同时测新能力能否学会，以及旧能力会不会因更大的 harness 或累积状态而遗忘。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?2 / 10

03 · LOOParXiv:2609.04280 · 2026-09-03

一条稳定的因果链：证据 → 修改 → 评测 → 冻结

1失败证据

从任务、轨迹或运行状态定位问题。

2修改 harness

改 prompt、tools、control flow、memory 或 verifier。

3执行评测

在固定模型与环境中运行候选。

4冻结与泛化

选择版本并在未见任务上检查。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?3 / 10

04 · NUMBERSarXiv:2609.04280 · 2026-09-03

四个数字先建立结果量级

17evolution streams

802unique tasks

520 / 42 / 62tools / skills / agents

−34.7%最严重 agent-axis BWT

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?4 / 10

05 · RELATEDarXiv:2609.04280 · 2026-09-03

相邻工作的边界决定分数能否比较

Q2. 它和“让 Agent 写 harness code”的工作到底差在哪？

它主要测“适应外部 harness 演化”，不是直接测“能否写 harness code”。 deployment 模式每阶段重新实例化，只观察更大 capability pool 的直接影响；self-evolving adaptation 才允许 memory、prompt 或 code 跨阶段保留。Meta-Harness 在这里是一个 code-based baseline，不是 benchmark 的唯一任务定义。因此把它纳入这组阅读的价值是提供下游压力测试：前八篇产出的动态 harness 若真的投入长期部署，应该同时报告这里的 retention 与 adaptation，而不能只看当前阶段分数。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?5 / 10

06 · PROTOCOLarXiv:2609.04280 · 2026-09-03

真正的协议藏在可见与隐藏信息之间

协议与信息边界

数据包含 17 条 stream、每条 3–6 stages、802 个 unique tasks；按 axis 展开后是 1,510 个 examples。能力宇宙含 520 tools、42 latent skills、62 specialist agents。每项能力按任务频率从 core 到 long tail 分批释放，任务在全部必需能力首次可用时引入，并至少需要本 stage 的一个新能力。 tools 直接继承源 benchmark 的 oracle annotations；skills 从 procedural rules 挖掘，再按 verifier keyword 关联，作者明确承认这些匹配不是必要、充分或唯一的技能解释；agents 则按 tool owner 分组，lead agent 无直接工具。 BWT = weighted(final old-task accuracy − introduction accuracy) FWT = weighted(post-adaptation new-task accuracy − pre-adaptation accuracy) 另报 final cumulative ACC、tokens、tool calls 和 latency。BWT 看遗忘，FWT 看新阶段适应，两者不能用一个总分替代。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?6 / 10

07 · RESULTSarXiv:2609.04280 · 2026-09-03

主结果之外，更重要的是版本怎样失败

结果怎么读

三条 axis 的困难不同：tools 是检索噪声，skills 是会不会真的调用，agents 是 recall 与 coordination。 tools 的累计目录有时提分，却显著加成本；EOG 上 MemToolAgent 38.6%、ReasoningBank 36.9%、Meta-Harness 35.2%，deployment 为 30.2%。ALE 多数方法接近或低于 baseline。 skills 扩张本身影响小；GEPA 在 EOG 从 18.9% 到 24.1%，但 GPT-5 默认系统几乎不调用 offered skills。agents 上 Meta-Harness 在 EOG 从 8.8% 到 18.5%，ALE 多数方法不改善。selection precision 已约 90%，瓶颈主要是 required-agent recall 和选中后的 coordination。为什么 retention 与 adaptation 必须分开？跨 axis 最坏 forgetting 分别是 tools −5.3%、skills −4.0%、agents −34.7%；最佳相对 adaptation gain 又分别达到 +27.8%、+27.5%、+110.2%。一个方法完全可能更少忘旧题，却在新阶段出现负 FWT。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?7 / 10

08 · EVIDENCEarXiv:2609.04280 · 2026-09-03

哪些结论成立，哪些还没有被证明

证据支持

三条 axis 的困难不同：tools 是检索噪声，skills 是会不会真的调用，agents 是 recall 与 coordination。 tools 的累计目录有时提分，却显著加成本；EOG 上 MemToolAgent 38.6%、ReasoningBank 36.9%、Meta-Harness 35.2%，deployment 为 30.2%。ALE 多数方法接近或低于 baseline。 skills 扩张本身影响小；GEPA 在 EOG 从 18.9% 到 24.1%，但 GPT-5 默认系统几乎不调用 offered skills。agents 上 Meta-Harness 在 EOG 从 8.8% 到 18.5%，ALE 多数方法不改善。selection precision 已约 90%，瓶颈主要是 required-agent recall 和选中后的 coordination。为什么 retention 与 adaptation 必须分开？跨 axis 最坏 forgetting 分别是 tools −5.3%、skills −4.0%、agents −34.7%；最佳相对 adaptatio

不能外推

把它用作“演化后 harness 的持续部署回归集”，而不是拿它替代 harness-coding benchmark。创建或修复系统后，应让新工具、skill、agent 分阶段进入，分别测 fresh deployment 与 persistent adaptation；同时记录 catalog size、routing recall、token/call cost 与 old/new cohort matrix。项目页可访问，但截至 2026-10-08 未链接独立公开 code/checker repository。skills 的 rule-based annotation 也只是一种 proxy；若把低 skill overlap 直接解释成模型缺能力，会混入 annotation incompleteness。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?8 / 10

09 · NEXTarXiv:2609.04280 · 2026-09-03

下一轮实验应该补什么

Q5. harness coding 研究者应该怎样使用这个 benchmark？

把它用作“演化后 harness 的持续部署回归集”，而不是拿它替代 harness-coding benchmark。创建或修复系统后，应让新工具、skill、agent 分阶段进入，分别测 fresh deployment 与 persistent adaptation；同时记录 catalog size、routing recall、token/call cost 与 old/new cohort matrix。项目页可访问，但截至 2026-10-08 未链接独立公开 code/checker repository。skills 的 rule-based annotation 也只是一种 proxy；若把低 skill overlap 直接解释成模型缺能力，会混入 annotation incompleteness。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?9 / 10

10 · VERDICTarXiv:2609.04280 · 2026-09-03

带着边界读结论，才不会把局部改进说成自我进化

最终判断

EvoHarnessBench 对“写 harness code”的相关性是间接但重要的。它提醒我们，一个今天高分的 harness，在工具或 agent 池扩大后可能迅速退化；而持续写 prompt/code 的 adaptation 也可能保住旧能力却伤害新任务。独特贡献把 tools、skills、agents 三种扩张拆开，并同时报告 BWT/FWT。边界 benchmark 本身不要求 Agent 编写 harness。构造风险 skill association 是规则匹配，不是完整因果标注。推荐对象已经读完前几篇、想补长期部署视角的读者。

阅读位置

这篇在整个系列中的兴趣度为 7.8/10。先看任务边界，再看真实修改与隐藏评测，最后回到限制。

EvoHarnessBench: Can Your Agents Keep Pace with an Evolving Harness?10 / 10