主题综述 · evaluation（2026-09-07）

• 作者：spark
• 更新：2026-09-07

摘要

近一个月的 evaluation 研究正在从“给 Agent 打最终分”转向“测量 Agent 为什么有效、如何被改进，以及评测本身是否可靠”。三条脉络汇合：其一，HarnessDev 与 WHALE 把 agent scaffold 变成可被构建、搜索和联合优化的对象；其二，AgentJudgeBench 将 judge 放到依赖驱动的工具调用 DAG 上，发现 hard 且无 ground truth 场景存在约 77%–82% 的经验性可靠性窄带；其三，S³Gym、DiagEvo、AutoResearchEval 与 AgentDebugX 把自测、自评、错误记忆、失败归因和修复纳入可观测闭环。本文据此讨论：评价对象应如何拆分，评估管线如何避免循环依赖，工程团队应先修评测还是先改系统。

一、主题脉络：从结果分数到评测基础设施

早期 agent benchmark 多把 backbone、harness、任务环境视为一个整体，leaderboard 上的提升无法直接归因于模型或工程。最新的研究至少显式区分四层：模型能力、管理上下文与控制流的 harness、工具及外部环境、用于打分的 judge/verifier。HarnessDev（arXiv:2609.01437）将评测单元从任务输出改成可运行基础设施，先让 creator 从弱种子构建 harness，再以 execution feedback 迭代，并在 held-out 任务上同时报告能力和 token 成本。它的启示不是“让模型随意改代码”，而是将 scaffold 质量、迁移性和回滚风险纳入实验。

WHALE（arXiv:2609.00196）进一步把模型权重和广义 harness 放进双阶段交替：固定当前 harness 更新权重，再固定权重搜索 harness。它的核心贡献是把长期分离的模型训练与系统工程放入同一优化循环，并指出瓶颈会随任务结构移动：SearchQA 更像 harness 瓶颈，数学推理更依赖先达到可用权重。实验解读所称相对 weight-only、harness-only 和 Fast-Slow Training 提升 4.15–24.38 个百分点，但具体搜索空间、reward 与切相阈值仍需查 PDF，因此这里只把它视为待复现的实验信号，不当作普适定律。

第二条线是评测器自身的可靠性。AgentJudgeBench（arXiv:2608.26623）包含 3,808 个实例、6 种 DAG 拓扑、3 个难度等级，组合 5 个 generator 和 6 个 judge。它测量 judge 对结构化工具调用轨迹的 alignment，而不再只评开放式文本或偏好。其最值得关注的结论是：hard + without-ground-truth 设置下，不同规模 judge 集中到 77%–82% 区间；ground truth 暴露对部分模型产生混合甚至负面影响，结构化 rubric 的收益也未显示跨 judge-generator pair 泛化。这里的“天花板”是经验结果，不是理论下界，且工具调用域不能直接外推到长程对话、GUI 或 Web agent。

第三条线是从 self-reflection 的口号转向可检验闭环。S³Gym（arXiv:2608.31100）把 Self-Testing、Self-Judging、Self-Improvement 三项能力拆开，在 7 个可执行文本游戏中区分 permissive exploration 与 strict held-out evaluation，并以 environment verifier 代替 LLM 自评。它同时发现经验注入没有单一赢家：依赖精确状态时 history ICL 更合适，能压缩为规则时 summary memory 有效，参数训练虽可能单任务大涨却会带来负迁移。该结论适合转化为 memory/route 策略，而不宜直接作为所有 Agent 的普遍规律。

DiagEvo（arXiv:2609.00768）用诊断器从历史中提取反复出现的错误原因，并放入分层错误记忆；其贡献在把“失败后总结”提升为可检索的机制资产。AutoResearchEval（arXiv:2608.14905）则用 100 个真实前沿科学任务、7 个领域和完整研究生命周期，构造 800 条轨迹与 45 个失败模式，试图回答“最终失败发生在哪一步、属于什么模式”。AgentDebugX（arXiv:2607.18754）补上可执行的后半段：Detect → Attribute → Recover → Rerun，并对 Who&When 的 strict agent-and-step 归因达到 qwen3.5-9b 上 28.8%，对比最强单遍基线 21.7%。这些工作共同把 evaluation 从一次性 judge 变成可回放、可定位、可修复的基础设施。

二、各工作贡献与相互关系

可以把近期 evaluation 看成一条流水线：任务/环境定义行为，judge 或 executable verifier 判定结果，诊断系统定位原因，harness/weight 优化再作用于下一轮。HarnessDev 解决“测什么系统”，WHALE 解决“如何让系统适应”，AgentJudgeBench 解决“谁来判定判定器”，S³Gym/DiagEvo 解决“系统能否从经验中改进”，AutoResearchEval/AgentDebugX 解决“失败如何变成可执行修复”。

但它们不是简单的性能排行榜。AgentJudgeBench 对 judge 的怀疑，恰好说明 AutoResearchEval 的 human-calibrated agent-as-a-judge 不能只凭“人类校准”四字获得可信度；必须报告标注协议、IAA/校准阈值和 judge 漂移。S³Gym 偏好 executable environment verifier，AgentDebugX 仍依赖 LLM 做根因归因，HarnessDev 则允许模型生成并演进执行系统。三者结合时应把程序化验证放在结果层，把 LLM 归因放在诊断层，再以独立回放和回归集验收，而不是让同一个模型同时写、执行、评价和批准自己的改动。

三、工程视角：可落地性与最小评测栈

对生产团队，最稳妥的落地顺序是“结构化 trace + 确定性校验 + 有限 judge + 人工兜底”。第一层记录每步 agent、tool、observation、reward、latency 和版本；第二层对 API 参数、状态转换、权限边界等可判定事实做程序化检查；第三层只用结构化 rubric 让 LLM 判断语义质量；hard 且无 ground truth 的轨迹应进入人审或双通道复核。AgentJudgeBench 的 77%–82% 不是要求所有系统停用 LLM judge，而是要求把 judge 当作有误差的传感器，并用置信度、难度和程序化真值共同决定是否放行。

Harness 修改必须像代码发布：保存版本、做单元回归、held-out 验证、灰度和回滚。HarnessDev 的两阶段设计适合转化为内部 benchmark：先测 creator 能否从弱 scaffold 生成可运行实现，再测 evolution 是否在不破坏旧能力的情况下提高新任务表现。WHALE 的交替思想可落地为小步迭代，但 reward 不稳定的长程任务不能照搬在线 rejection-sampling；应先建立人工抽样和离线回放集。

失败归因同样应先于 patch。AgentDebugX 的 28.8% strict attribution 虽比 21.7% baseline 高 7.1 个百分点，却仍意味着错误归因不可忽略；生产系统可先用轻量 detect，再对高风险失败调用完整诊断，并将 patch 限定为可验证的 prompt、route、tool 或 memory 变更。所有 trace 进入共享 Error Hub 前都应做字段级脱敏，避免把用户数据、API key 和内部 schema 变成组织记忆的隐式泄漏面。

四、研究视角：创新性、批判与证据边界

本轮最明显的创新是评测对象外移：评价从静态答案扩展到 harness、judge、诊断器和自我演化过程。HarnessDev 与 WHALE 分别把“可构建基础设施”和“权重—harness 联合优化”形式化，AgentJudgeBench 则把 judge reliability 变成可按 DAG 拓扑和难度切片的 meta-evaluation。S³Gym 的三能力解耦也有方法学价值，因为它允许研究者分别定位“测不出、评不准、改不动”，而不是用一次平均分掩盖根因。

证据上必须保持克制。相关论文大多为 2026 年 8–9 月新近发布，OpenAlex/Semantic Scholar 引用仍为 0 或极少；大量结果来自 abstract 层级，仓库、附录和第三方复现不足。HarnessDev 解读中出现了具体 14.4 个百分点的跨 harness 案例以及 Creator/Executor 分离等信息，但这些数字应在正式引用前回到 PDF §实验逐项核对；AgentJudgeBench 的模型命名、77%–82% 区间、rubric 收益与 ground-truth 效应也需按 PDF 和官方仓库复核。AutoResearchEval 的 human calibration 一致率、45 类模式全表与各阶段失败率未在 abstract 给出，AgentDebugX 的第二 backbone、诊断开销和隐私清洗细节同样待核。

因此，本综述不把这些工作称为统一“评测 OS”或学界共识。更准确的判断是：它们正在形成“可追溯评测流水线”的组件集合，但尚缺跨团队、跨任务域的 head-to-head，以及统一的成本、安全、统计显著性与可复现性标准。

五、趋势判断与开放问题

未来 1–2 个季度，evaluation 的重点会从更大 leaderboard 转向三项指标：一是 harness 质量及其跨模型迁移，二是 judge/verifier 的可审计误差界，三是从失败到修复的闭环收益是否在真实流量中保持。评测报告应同时给出任务成功率、每次任务 token/成本、strict attribution、回归失败率和安全事件，而不是只给一个最终分数。

仍有五个开放问题：第一，如何在不泄露测试任务的前提下允许 agent 改进自己的 harness？第二，hard、无 ground truth 场景的 77%–82% 经验窄带能否跨 GUI、Web、科研和多模态环境成立？第三，self-testing、self-judging、self-improvement 三者之间的依赖如何建模，怎样避免自评循环放大错误？第四，诊断器与被测系统共享模型、上下文或 reward 时，如何做独立性和因果归因？第五，企业能否以统一 schema 复用 trace、taxonomy、patch 和回归结果，同时满足隐私、数据驻留与审计要求？

六、结论

近期 evaluation 的共同方向是：把“模型做得好不好”改写成“模型、harness、环境、judge 和修复机制分别贡献了什么，以及这些贡献是否可复核”。HarnessDev、WHALE、AgentJudgeBench、S³Gym、DiagEvo、AutoResearchEval 与 AgentDebugX 分别补齐了系统对象、联合优化、judge 可靠性、自我改进、错误记忆和可执行诊断等环节。工程上应优先建立程序化真值、结构化 trace、严格归因和安全回滚；研究上则需要更多独立复现与跨域实验，验证这些局部规律能否成为通用评测标准。

来源与核验说明

本文综合知识库中的论文卡、对应解读、2026-09-06 evaluation 综述、近 7 天相关 inbox 笔记，并使用 Exa/网页搜索补查近期 agent evaluation 文献。新增 arXiv 条目均给出可核验 ID：2608.26623、2609.01437、2609.00196、2608.31100、2609.00768、2608.14905、2607.18754。涉及具体数值、模型名、仓库状态和跨论文结论的未公开部分均以“需 PDF/仓库核验”标注，未把搜索摘要当作正式论文证据。