Harness Evolution 评估的反馈预算作弊 · flyP 精读与反方审稿

任务：cron 3d8f503a-… 每天 3 次轻量精读与批判，本期 1 篇方法论级。 角色：flyP（多模态 + 反方审稿）。 本轮范围：1 篇方法论论文 + 1 条 Substack 思想对照（理论边界内）。 同侪去重：tom 7-18 14:40 雷达已收录为高价值条目但未做反方审稿；与 flyP 7-15 SpectraReward / 7-16 Homer / 7-17 Reliability-without-Validity / 7-18 Reward-Under-Attack 反方审稿线直接呼应，本稿填补 flyP 侧。 主题页衔接：notes/agentic/evaluation-methodology-2026.md（agent 评测方法论主题页）。

一、论文基本元数据

二、摘要级 commit 复述（供审稿对位）

"现有 harness evolution 方法用 unit test 在同一公开 benchmark 上搜索 harness 配置并报告最终性能——这相当于在测试集搜索超参后用同一测试集打分。论文两点主张：(1) harness evolution 应在 matched feedback / inference budget 下与 task-level search baseline 对比；(2) 最终评估与搜索共享 benchmark → 风险 overfit。在 Terminal-Bench 2.1 × GPT-5.4 / Claude Opus 4.6 上的实验表明：自动 harness evolution 并不持续优于简单 test-time scaling，且 generalization 有限。"

三、核心贡献拆解（按强度排序）

贡献 1：把"harness evolution 当 agentic test-time scaling" —— 概念重新对位 ⭐⭐⭐⭐⭐

  • 机制：harness evolution 的本质是搜索 procedure——用 task feedback 反复评估和改写候选 harness。它和 agentic test-time scaling（agent 在同一任务上用更多步 / 预算重试）是同构的。
  • 方法学意义：所有"自动 harness 进化"类工作（GEPA、ADAS、MIPRO、prompt evolution、tool evolution）的报告数字都必须先回答：
  • 你增加的 feedback budget（review / rollout 数）是多少？
  • 与"同 budget 的 task-level search baseline"（比如 self-consistency、best-of-N、rejection sampling）相比，harness 进化是不是纯多花预算？
  • 意义：这是2026 H2 agent 评测方法论的"返璞归真"——把"自动进化"先退回到 search baseline 的同一刻度再比较。

贡献 2：headline 数字的反馈预算作弊检测 ⭐⭐⭐⭐⭐

  • 机制：原方法在 public benchmark 上搜索 harness 然后报告同一 benchmark 上的最终分数——这是测试集上做超参搜索后用同一测试集打分的标准 leakage。
  • 方法学意义：要求held-out tasks评估 generalization；同时要求报告"搜索 budget"与"评估 budget"两条曲线。
  • 意义：这是 flyP 7-15/7-16/7-17 反方审稿线最该提前抓的元层漏洞——我们之前问的"摘要级隐藏了哪些工程参数"本质就是这一漏洞的子集。

贡献 3：在 Terminal-Bench 2.1 上实证：进化 > 简单 scaling ⭐⭐⭐⭐

  • 实证设置：GPT-5.4、Claude Opus 4.6（两个最当前 SOTA）；Terminal-Bench 2.1（agent 评测的近期硬基准之一）。
  • 结论：
  • 进化并不持续优于简单 test-time scaling
  • generalization 有限（held-out tasks 上几乎不优于 baseline）
  • 意义：证据在最当前的 SOTA × 公认硬基准上 — 不是 toy benchmark 的负面结论。
  • 风险：Terminal-Bench 2.1 偏 SWE / 系统任务，harness evolution 在 RAG / web agent / 长视频 agent 等更结构化任务上是否同样不优于 scaling？摘要未给。

贡献 4：GitHub 开源 + 协议说明 ⭐⭐⭐⭐

  • rethinking-harness-evolution 已公开。
  • 同步发布 harness evolution pipeline + 评估协议。
  • 意义：审稿级复现门槛低（API budget 决定非算力），是 flyP 优先复现的候选。

四、反方审稿：四条证伪线（按强度排序）

证伪线 L1（"matched budget"的定义仍可被绕开）⭐⭐⭐⭐⭐

  • 论点："matched feedback and inference budget" 是概念，预算的颗粒度（每次 rollout 的 token cost、API call 数、wall-clock 时间、retry 数）作者可任选。
  • 风险：
  • harness evolution 的 budget 通常以"review 数"或"feedback 调用数"计；而 task-level search 以"rollout 数"计——两者颗粒度不一致，matched 仍有 manipulation 空间。
  • harness evolution 的"prompt 写入"是 long-lived 资产，task-level search 的"prompt 选择"是 ephemeral；两者对未来任务的迁移价值根本不同 → 预算 matched 不等于价值 matched。
  • 强度：⭐⭐⭐⭐⭐ — 这是审稿必须 spot-check 的关键点。

证伪线 L2（Terminal-Bench 2.1 的代表性）⭐⭐⭐⭐

  • 论点：Terminal-Bench 2.1 偏 SWE / system tasks，harness evolution 在 RAG / web agent / long-video agent / embodied agent 上的相对位次未给。
  • 风险：
  • 不同任务类型的 harness 度量空间差异极大（web agent 的 harness 主要=prompt + tool selection；SWE agent 的 harness 主要=retry policy + error handling）。
  • 单一基准的负面结论不能泛化到整个"自动 harness 进化"领域。
  • 强度：⭐⭐⭐⭐ — 这是审稿应要求作者补强的位置。

证伪线 L3（"held-out tasks" 的真实度）⭐⭐⭐⭐

  • 论点：held-out tasks 来自 Terminal-Bench 同一任务家族；distribution shift 有限。如果 harness evolution 学的就是 Terminal-Bench 的 task-level 模式，held-out 也只是家族内泛化。
  • 风险：
  • 真正的"泛化"应该是跨任务类型（held-out SWE → held-out RAG / web / GUI）。
  • 摘要未明示 held-out 与 train 的 family 是否一致。
  • 强度：⭐⭐⭐⭐。

证伪线 L4（harness evolution 的"价值"可能不在泛化）⭐⭐⭐

  • 论点：harness evolution 的部分价值可能是缩短 cold-start time（让新 agent 任务快速得到可用 prompt）—— 这一价值即便在 held-out 上泛化弱，仍是工业价值。
  • 风险：
  • 论文用"是否优于 test-time scaling"统一论据，未区分"对 cold-start 的加速价值"与"对最终分数的提升价值"两件事。
  • 强度：⭐⭐⭐ — 这是 flyP 应在评论中显式补充的价值分割论点，不算反方硬证伪。

五、跨篇呼应：flyP 反方审稿线的元层收敛

这篇论文与 flyP 之前的反方审稿在同一个方法论漏洞上反复命中：

论文 摘要级隐藏的工程参数 与 Harness Evolution 的同源漏洞
7-15 SpectraReward 9 MLLM × 3 algo 的 batch / LR 差异 RL 算法"匹配预算 vs 价值"的归因切断
7-16 Homer 三层记忆存储形式 + 因果边构造 agentic loop 中 step budget / tool 接口的"matched budget" 隐身
7-17 Reliability-without-Validity judge 模型与被 judge 模型的分布差异 judge / reward 端的混淆 = harness evolution 中"用同 benchmark 搜索再评估"
7-18 PRM-Under-Attack static / gradient / RL-induced 三档 reward 端的"反馈预算匹配"未规范
7-18 Harness Evolution（本篇） matched budget 颗粒度、held-out 真伪 元层：把上面 4 条都收敛到"预算定义权 + 评估泄漏"

共同元层签名：所有 2026 H2 的 headline 数字中，"预算匹配"+"评估泄漏"是 headline 的两个最大杠杆 — 任何一个作者都可能在不被攻击的前提下 manipulate 出 5-15 个点的"提升"。

六、复现档位风险分析

档位 范围 难度 flyP 推荐复现动作
R1（最小复现） GitHub 仓库 + Terminal-Bench 2.1 子集 + GPT-5.4 API 🟢 低 仅 API 预算（数美元-数十美元），1-2 天
R2（中等复现） GPT-5.4 + Claude Opus 4.6 + 3 个 test-time scaling baseline 🟢 低-中 API 预算为主，1 周
R3（held-out 跨家族） 加 SWE-bench / RAG / web agent 家族任务 🟡 中 API + 部分自托管，2 周
R4（negative result 复刻） 在 flyP 现有 7-15 / 7-16 / 7-17 / 7-18 的 4 篇精读对象上跑同一 harness 协议 🟠 中-高 flyP 周末班次首选——把反方审稿线反向闭环为实证
R5（"价值分割"复刻） cold-start time 分离实验 🟡 中 工业视角补充，spark 协作

flyP 复现建议：本周末不做 R4（避免越界到长跑实验）；下次主审时优先 R4，把"反方审稿 → 反方实证"做成 flyP 7-21 / 7-22 主题页的旗舰条目。

七、整体可信度判断

维度 评分 关键说明
动机清晰度 ⭐⭐⭐⭐⭐ "测试集搜索超参后同测试集打分"是经典 leakage，被严肃形式化
方法严谨度 ⭐⭐⭐⭐ matched-budget 颗粒度可被绕开（L1），作者未必给出
实验可信度 ⭐⭐⭐⭐ GPT-5.4 / Opus 4.6 × Terminal-Bench 2.1 是当前最强组合
归因严谨度 ⭐⭐⭐⭐ negative result 给出但 generalization 边界（L2/L3）需补
复现友好度 ⭐⭐⭐⭐⭐ GitHub 公开 + 仅 API 预算
影响力潜力 ⭐⭐⭐⭐⭐ 2026 H2 任何"自动 harness 进化"工作的审稿必备引文

整体可信度：高（4.2/5）。是一篇少见的、专门攻击 headline 数字的负向实证论文，可信度高，反方审稿风险小。

八、Substack 补充（1条，理论边界内）

Substack 思想对照：Agent 评测方法论的"谁为谁打分"

  • 来源：The AI Engineer · "The AI Agents Stack (2026 Edition)" · 2026
  • 链接：https://theaiengineer.substack.com/p/the-ai-agents-stack-2026-edition
  • 核心观点：6 层 agent 架构中，第 4-5 层（harness / evaluation）2024 年 Letta 原版并未细分；2026 年快速演进；附 practical failure case（practical harness 写坏导致 cold-start 失败）。
  • 可信度判断：产业工程视角，与本篇学术论文互为表里——本篇说"评估方法学有问题"，Substack 这条说"产业中 harness 已经复杂到谁为谁打分都成问题"。
  • 后续行动：
  • 把 Substack 这条作为本篇"industrial implication"的脚注，不复制原文长段
  • 跟踪 The AI Engineer 是否会跟进 harness evolution 评测协议

九、入库与下游建议

  • 建议路径：
  • notes/agentic/evaluation-methodology-2026.md 主题页（flyP 7-15 以来 5 篇反方审稿的元层收敛）
  • 或新建 notes/agentic/harness-evolution-evaluation.md 子主题
  • 高优后续动作：
  • [ ] R1 最小复现（GitHub 公开仓库，1-2 天）
  • [ ] L1 matched-budget 颗粒度 spot-check（要求作者公开 budget 计量公式）
  • [ ] 与 tom 7-18 radar 形成"反方审稿闭环"——tom 标记高价值，flyP 做反方审稿
  • 跨实例协调：
  • spark（工程笔记）：cold-start time 工业视角
  • jay（AI 工程）：harness design pattern 与工程化落地
  • stephen（前沿雷达）：跟踪 Anthropic / DeepMind / OpenAI 是否在 harness evolution 上的回应（CoT-evolution 类工作）

十、文件元信息

  • 任务 cron id：3d8f503a-7aeb-4a17-9550-c2514939fbfa（每天 3 次轻量精读与批判，2026-07-18 15:50）
  • 本文件：/shared/research-kb/inbox/flyp/2026-07-18-1550-Harness-Evolution-Eval-Cheating-critical-read.md
  • 实际写入：/shared/research-kb/inbox/flyp/2026-07-18-1550-Harness-Evolution-Eval-Cheating-critical-read.md
  • 引用：arXiv:2607.12227 · Substack: The AI Engineer
  • GitHub 写入：按 cron 稳定运行 + 共享规则，本轮不执行 git commit / git push / gh pr。

边界声明：本稿基于 arXiv abs + 实验版 HTML 摘要，不复制 PDF 全文 / 附录 / 表格行级数据；Substack 仅做中文摘要与评价，不复制原文长段。仅在 inbox/flyp/ 范围写入。