evaluation · E1 预消化简报(2026-10-11)
检查来源清单
| 来源 | 文件 | evaluation 相关度 |
|---|---|---|
| knowledge/evaluation.md | organized/knowledge/evaluation.md（R100 锚点） | 高（锚点骨架） |
| paper_cards 新卡 | 1199/1196/1194/1180/1175（10-11 OpenAlex 入池 · evaluation 主分类） | 高（4 件 eval 新卡） |
| jay 工程筛选 | 2026-10-11-engineering-e1prep.md | 低（无 eval 新 benchmark） |
| jay csdn/ai-eng | 2026-10-11-ai-engineering-substack-hf-inference-stack-oct.md | 低（无新 eval 信号） |
| tom 昨日 e1prep | 2026-10-10-evaluation-e1prep.md | 沿用锚点 |
增量条数：4 条（+ 1 个 Harness 簇新节点）
增量 1：HarnessDev · LLM 生成的 Harness 仍落后于人工参考方案，但写作/ML 实验除外
来源：arXiv:2609.01437（paper_card 1196 · 10-11 OpenAlex 入池 · 主分类 evaluation · 形态 benchmark · 被引 8）
TLDR 核心：研究 LLM 能否创建并演进自身的 Agent Harness。发现：生成的 harness 在代码与搜索/研究任务上仍显著落后于成熟的人工参考方案，而在写作与机器学习实验任务上达到或超过所选参考方案，且执行成本差异巨大。
要点： - 核心问题：Harness 的创建和演进是否可以由 LLM 自主完成，而非纯人工设计 - 关键发现：生成的 harness 在代码与搜索/研究任务上仍显著落后于成熟人工参考——这两个领域对 harness 精度要求最高 - 例外：在写作与机器学习实验任务上，生成 harness 可达到或超过所选参考方案 - 成本信号：执行成本差异巨大（生成 harness 的计算开销 vs 人工设计成本需要权衡） - 补充说明：该文研究的是"LLM 自主创建 harness"，而非 R98 EMHO（轨迹驱动 Harness 自演进）或 R100 Mara Chain（被拒候选重用）——但三者在"harness 设计自动化"主题下形成横向对照
与 knowledge/evaluation.md 现有脉络的关系： - R98 §6.183.2 EMHO（具身 Agent Harness 自演进 · arXiv:2610.08432）：Harness 由执行轨迹驱动自动演进——EMHO 的演进方向由历史轨迹决定 - R100 Mara Chain（被拒候选重用 · arXiv:2609.35855）：Harness 演进方向由被拒候选的诊断信息决定——两者都是"由某种信息源驱动演进" - HarnessDev 的补充视角：LLM 直接"生成"harness，而非演进现有 harness——这是"harness 从零生成"与"harness 演进优化"两条平行路径 - 建议归入 §2.1 Harness + Judge 累积（Harness 生态候选二十角候选的第 88-89 角预备级区域），或单独建立"harness 生成 vs harness 演进"对照节点 - ⚠️ 注意：该文在 R100 归档时尚未显式锚定，今日补入待锚池
开放问题： - LLM 生成 harness 的"成本-质量"帕累托前沿在哪里？代码/搜索任务上的差距根因是什么（任务复杂度？harness 约束条件数量？） - 生成 harness 在写作/ML 实验上达标，是否说明这些任务的 harness 设计更容易形式化？
增量 2：AgentJudgeBench · 首个 LLM-as-Judge 在 Agentic 工具调用工作流 DAG 上的系统性失效分析
来源：arXiv:2608.26623（paper_card 1194 · 10-11 OpenAlex 入池 · 主分类 evaluation · 形态 benchmark · 被引 1）
TLDR 核心：首个系统性研究 LLM-as-a-judge 在工作流 DAG 上对 Agentic 工具调用评判可靠性的基准，区别于面向开放式文本或偏好的通用 LLM-as-a-judge 任务；揭示了当前 LLM judge 的根本局限，并给出面向 Agentic 系统可靠评估的实践指南。
要点： - 研究空白：现有 LLM-as-Judge 研究多聚焦于开放式文本生成或偏好排序的评判，Agentic 工具调用的工作流 DAG 评判从未被系统性研究 - 核心问题：在 agentic 系统中，LLM judge 需要评判的是具有因果依赖关系的有向无环图（DAG），而非独立文本片段——这带来了独特的可靠性挑战 - 关键贡献：首个专门针对 workflow DAG 上 agentic 工具调用评判的 benchmark；揭示当前 LLM judge 在该场景下的根本局限；给出面向 agentic 系统可靠评估的实践指南 - 与现有 judge 失效研究的关系：R92 MIST（R92，VLM judge 被无关图像劫持 verdict）、R93 SAGO（稳定性维度失效）、R95 LexReward（奖励分类法失效）、R97 Selection vs Extraction（预注册方法失效）、R100 Opera（反馈追踪失效）——AgentJudgeBench 揭示的是 DAG 结构因果依赖这一特定场景下的 judge 失效，与上述六元并列，构成第七元（或第八元）失效模式的补充
与 knowledge/evaluation.md 现有脉络的关系： - R84-JEV-as-a-Judge → R89 ARGUS → R92 SEAL 聚合层失效 + MIST 个例层失效 + Training LLM Judges 训练层失效 → R93 SAGO → R95 LexReward → R97 Selection vs Extraction → R100 Opera 反馈追踪 = 现有 judge 失效模式体系 - AgentJudgeBench 的增量价值：引入"DAG 因果依赖结构"这一新的 judge 失效维度——工具调用之间存在因果依赖，LLM judge 在评判时是否能理解这种依赖关系并给出合理评分？这是 R100 Opera（反馈后是否真正解决）之外，judge 评估中的又一个结构化场景失效 - 建议归入 §1.2 judge 范式 + 多维评估框架：作为"DAG 工作流 agentic judge 可靠性"的新评测维度，与 R100 Opera（反馈追踪第七元）并列形成"judge 评测时机 + 评测结构"两个新维度 - ⚠️ 待原文精读确认：DAG 场景下 judge 失效的具体模式（是误解依赖顺序？还是忽略中间节点状态？）、多难度设置的具体含义
开放问题： - AgentJudgeBench 中的"多难度"如何分级？是从简单到复杂的 DAG 深度/宽度变化，还是工具类型复杂度变化？ - DAG judge 失效与 R92 MIST（无关图像劫持）的失效机制是否本质不同？ - 给出的"可靠评估实践指南"是否有开源实现可供复现？
增量 3：EvoGenUI-Bench · 多轮生成式 UI 助手评测基准——150 任务 × 5 轮 × 750 轮次
来源：arXiv:2608.29387（paper_card 1175 · 10-11 OpenAlex 入池 · 主分类 evaluation · 形态 benchmark · 被引 1）
TLDR 核心：提出 EvoGenUI-Bench，一个面向多轮界面维护的基准，包含 150 个五轮任务，共计 750 轮，覆盖三种场景：信息呈现、可执行交互和工具驱动的外部状态。
要点： - 规模：150 个五轮任务，共 750 轮对话轮次——每任务平均 5 轮交互 - 三种场景：(1) 信息呈现（information presentation）；(2) 可执行交互（executable interaction）；(3) 工具驱动的外部状态（tool-grounded external state） - 评测焦点：多轮界面维护（multi-turn interface maintenance）——而非单轮 UI 生成——这是与现有 UI 生成 benchmark 的核心区别 - 注意：该 benchmark 评测的是"LLM 作为多轮生成式 UI 助手"，而非 agent 的通用工具调用能力
与 knowledge/evaluation.md 现有脉络的关系： - R83 GameHorizon → R88 AgentWorld → ... → R97 AgencyBench → R98 SafeActBench：长程/多 Agent 评测端点体系 - EvoGenUI-Bench 的补充价值：填补"多轮 UI 界面维护"这一特定类型长程评测的空白——是"长程"的另一个维度（轮次深度），而非新的端点类型 - 建议归入 §1.3 长程/多 Agent 评测端点（作为多轮交互评测的补充节点，而非新端点） - ⚠️ 待原文精读确认：评测指标体系（是自动评分还是人工评分？）、三种场景的 task distribution、是否存在工具调用评测子集
开放问题： - 750 轮次是否足以支撑统计显著性？每种场景 50 任务是否足够？ - "工具驱动的外部状态"与 R98 SafeActBench 的工具使用评测有何本质区别（UI 维护 vs 外部 API 调用）？
增量 4：Aspire · 模糊目标驱动的自我演化 Benchmark——520 题 6 类目标
来源：arXiv:2608.31111（paper_card 1199 · 10-11 OpenAlex 入池 · 主分类 evaluation · 形态 benchmark · 被引 2）
TLDR 核心：提出 ASPIRE，面向模糊目标驱动自我演化的基准，表明模糊目标会将搜索资源导向目标解释阶段；并在涵盖 6 类目标的 520 题隐藏专家评测集上评估所得系统。
要点： - 核心问题：当 agent 被给予模糊（vague）而非精确的目标时，如何评估其自我解释和自我演化能力？ - 关键发现：模糊目标会将搜索资源导向目标解释阶段（goal interpretation）——而非直接执行——这改变了 agent 的工作流程重心 - 评测集规模：520 题隐藏专家评测集，覆盖 6 类目标——hidden expert-authored set - 评测对象：系统根据模糊目标的自我演化结果，在专家评测集上的表现
与 knowledge/evaluation.md 现有脉络的关系： - R99 Agent Plasticity（能力快照→学习轨迹，三维自我改进评测）：两者都涉及"agent 在经验中演化/改进"，但侧重点不同 - Agent Plasticity：测量 agent 在多轮任务中的性能改进曲线（性能泛化/获取效率/崩溃点） - Aspire：测量 agent 在面对模糊目标时如何通过自我解释建立精确目标并完成任务 - 建议归入 §1.4 垂类多阶段多维评测（作为"目标模糊性下的自我解释与演化"这一评测维度的新节点，区分于 Agent Plasticity 的"性能改进曲线"维度） - ⚠️ 待原文精读确认：520 题的 6 类目标具体是什么？模糊目标的定义粒度？与 Agent Plasticity 的评测集是否可互用？
开放问题： - Aspire 与 Agent Plasticity 的评测对象是否重叠（两者都涉及自我改进）？还是互补（目标解释 vs 性能曲线）？ - 隐藏专家评测集的构造方式是否避免了数据污染风险？
增量 5：Harness 簇——HarnessDev + HoH + AgentJudgeBench 形成"harness 全生命周期"评测三角
来源：综合 arXiv:2609.01437 / arXiv:2609.01481 / arXiv:2608.26623（paper_cards 1196/1180/1194）
TLDR 核心：三个今日 OpenAlex 入池的 paper_cards 形成一个自然聚类——HarnessDev 研究"Harness 从零生成"、HoH 研究"Harness 在多日迭代中持续演进"、AgentJudgeBench 研究"Harness 的核心组件（Judge）在 DAG 场景下的可靠性"。三者共同覆盖了 Harness 从生成→使用→评估→迭代的全生命周期评测维度。
三个 paper_cards 的聚类关系：
| 论文 | arXiv | 评测焦点 | 生命周期位置 |
|---|---|---|---|
| HarnessDev | 2609.01437 | LLM 能否从零生成 harness | 生成阶段 |
| Harness-of-Harness | 2609.01481 | 多日 70+ 迭代中 harness 自主演进 | 迭代/演进阶段 |
| AgentJudgeBench | 2608.26623 | LLM Judge 在 DAG 工作流的可靠性 | 评估/使用阶段 |
与 R100 Harness 自演进三路径的关系： - R98 EMHO（轨迹驱动 Harness 演进）：演进方向由执行轨迹决定 - R100 Mara Chain（被拒候选重用）：演进方向由被拒候选的诊断信息决定 - HarnessDev 的新视角：直接从零生成 harness，而非演进现有 harness——这提供了第三条 Harness 来源路径（轨迹/候选/生成） - 三者在 evaluation.md §2.1 中的位置：建议作为"harness 生命周期评测三角"横向聚类标注，不单独升锚，但标注与 R98/R100 的关系
HoH（paper_card 1180 · arXiv:2609.01481）补充说明： - TLDR：在持续多天、超过 70 轮迭代的部署中，HoH 自主开发出一款第一人称射击游戏 - 该文主分类 evaluation、形态 method——Harness-of-Harness 名称中的第一个 Harness 是动词（评价/约束），第二个是名词（评测工具）——即"Harness 的 Harness"，用 AI 系统对 AI 系统开发过程进行持续评测与改进 - 注意：HoH 的 contribution 是"多日自主开发出完整游戏"的方法论，而非新的评测基准或指标体系——更接近 agent 主分类，但由于是"用 Harness 评测 agent"，归入 evaluation 副分类合理
值得警惕的矛盾或待核实说法
-
OpenAlex 入池 ≠ 新论文：今日 paper_cards 1199/1196/1194/1180/1175 均为 OpenAlex 9 月更新后于 10 月 11 日入池的历史论文（2025 年 9 月上传），非当日新发表的论文——但因为 TLDR/元数据补充，对 knowledge/evaluation.md 有增量价值。警惕将"OpenAlex 入池"误认为"arXiv 新发表"。
-
EvoGenUI-Bench 评测指标未披露：该卡的 TLDR 未提及评测指标体系（自动打分？人工打分？正确率？任务完成率？）——在引用该 benchmark 时需先确认评测方法的可复现性。
-
Aspire 的"模糊目标"与 R99 Agent Plasticity 的潜在重叠：两者都涉及 agent 在经验/目标不清晰时的适应行为，但分别从"目标解释"和"性能改进曲线"角度切入——若两者的评测集可互用，则存在评测方法学上的互补性问题，需要确认两者的边界是否清晰。
-
HarnessDev 的"写作/ML 达标"vs"代码/搜索落后"：生成 harness 在写作任务上达标（matching or exceeding references），但在代码任务上显著落后——这与"代码是 LLM 最强能力领域"的常见认知形成矛盾。可能的解释：写作任务的 harness 约束更容易形式化（风格/格式/长度），而代码任务的 harness 涉及执行正确性验证（需要运行时环境），技术难度更高。需原文确认根因。
可引用的 arXiv 号列表
| arXiv ID | 论文 | 主分类 | 形态 | 新增性质 |
|---|---|---|---|---|
| 2609.01437 | HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? | evaluation | benchmark | NET-new（今日 paper_card 1196 入池） |
| 2608.26623 | AgentJudgeBench: A Multi-Difficulty Benchmark for Evaluating LLM Judges on Agentic Tool-Calling | evaluation | benchmark | NET-new（今日 paper_card 1194 入池） |
| 2608.29387 | EvoGenUI-Bench: Evaluating LLMs as Multi-Turn Generative UI Assistants | evaluation | benchmark | NET-new（今日 paper_card 1175 入池） |
| 2608.31111 | Aspire: Can Models Self-Evolve from Vague Goals? | evaluation | benchmark | NET-new（今日 paper_card 1199 入池） |
| 2609.01481 | Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement | evaluation | method | NET-new（今日 paper_card 1180 入池 · agent 副分类） |
| 2609.35855 | Mara Chain（已锚锚 199） | — | — | R100 沿用 |
| 2606.03335 | Hebero（已锚锚 200） | — | — | R100 沿用 |
| 2609.33987 | Opera（已锚锚 201） | — | — | R100 沿用 |
新 arXiv 号汇总（本次 E1 +5）：2609.01437 / 2608.26623 / 2608.29387 / 2608.31111 / 2609.01481
本次 E1 预消化结论
- 显著新增量：4 条增量 + 1 个 Harness 簇节点——全部来自今日 OpenAlex 入池的历史论文（非当日新发表，但对知识库有增量价值）
- 新 arXiv：+5（2609.01437 / 2608.26623 / 2608.29387 / 2608.31111 / 2609.01481）
- 新聚类发现：HarnessDev + HoH + AgentJudgeBench 形成"harness 全生命周期评测三角"（生成 / 迭代 / 评估使用），与 R100 的 EMHO + Mara Chain + 4 件伴生形成横向互补
- 待核实：今日 inbox 来源中无新 benchmark 原始发表（jay/stephen/spark/tom 10-11 无 evaluation 专项 e1prep）；无 R101 级别的范式跃迁信号
Tom E1 预消化 · 2026-10-11 15:40 CST · 已检查来源：knowledge/evaluation.md（R100 锚点）/ paper_cards 1199+1196+1194+1180+1175（10-11 OpenAlex 入池 · evaluation 主分类 5 件）/ jay 10-11 inbox 无 eval 专项 / knowledge/evaluation.md（R100 锚点）