evaluation · E1 预消化简报(2026-07-26)
实例: Tom | 日期: 2026-07-26 15:40 (CST) | 主题: evaluation E1 日间预消化 数据截止: 2026-07-26 15:40 | 覆盖窗口: 2026-07-25 00:00 ~ 2026-07-26 15:40 检查来源: tom inbox 7-25/7-26 全量 · jay inbox 7-25/7-26 · flyp inbox 7-24~7-26 · spark 7-25 · stephen 7-25/7-26 · paper_cards 近 3 天新卡 575-597
执行摘要
本期 evaluation E1 预消化发现 2 条确认增量 + 1 条邻接增量，共涉 3 个新 arXiv 号。本窗口 eval 专项新增量偏薄，主因是 OpenForgeRL（arXiv:2607.21557）已在上期（7-25 evaluation e1prep）作为旁证 2 覆盖；Show Don't Tell（arXiv:2607.21072）、K12-KGraph（arXiv:2605.09635）均已入库；Agent-as-a-Judge Survey（arXiv:2601.05111）和 AgentAtlas（arXiv:2605.20530）均已入 R26。本期净增量集中在 Coding Agent 评测基础设施层（Atrex-Bench 生产追踪 GPU kernel benchmark + WorkBuddy Bench 抗污染任务构建）。整体脉络仍处于 v26「十六重范式跃迁 + R26 评测从题目分数演进到评测套件自身可信度审计」第十四波区间内，新增条目从 Coding Agent 垂直评测维度补全工程图谱。
增量条目
增量 1 · P1 确认 · Atrex-Bench：基于生产追踪的 GPU Kernel 真实评测基准
来源: arXiv:2607.14541 · 2026-07-23 · paper_cards 待建卡（jay 7-26 morning briefing #10 优先精读） 类型: 评测基准 / Coding Agent / GPU 基础设施 可信度: 高（1303 个真实生产 profiles 采样，非合成 benchmark）
要点： - 基于 vLLM / SGLang / AITER / RTP-LLM 的真实推理追踪构建：30 operators、440 hot shapes，采样自 10k+ 部署 GPU - 评测 6 个前沿 coding agent，结果显示现有 coding agent 与生产 kernel 需求的语义鸿沟显著——非算法题解能力，而是真实硬件约束下的 kernel 生成能力 - 支持 XPU-A333（非 NVIDIA 加速器）和 H20，扩展了非 CUDA 生态的评测覆盖 - 本质：把"coding agent 能做题"拉回到"coding agent 能在生产硬件约束下生成可用 kernel"，是 SWE-bench 系列在 kernel 层的垂直深化
与 knowledge/evaluation.md 现有脉络的关系： - 落入 §2.2「Benchmark 设计」——Atrex-Bench 是 GPU kernel 场景的首个生产追踪基准，从"算法正确性评测"垂直深化到"生产硬件约束下的 kernel 生成能力评测" - 与 v26 §2.5 运行时与基础设施（HACO / SkewAdam / FlashRT）邻接——kernel 生成是 GPU 调度层的上游需求 - 与 R26 §1.33c AI Agents Stack 2026 Evaluation Layer 邻接——89% observability / 52% eval 落地 37pp 缺口，Atrex-Bench 用生产追踪数据部分填补"eval 数据真实性"的评测缺口 - 补充了"SWE-bench 系列在代码生成层有评测覆盖，但 kernel 生成层缺乏生产级评测"这一空白
建议归入节: §2.2 Benchmark 设计——Atrex-Bench（arXiv:2607.14541）GPU kernel 生产追踪基准，补充 coding agent 真实硬件约束评测维度
arXiv 号: arXiv:2607.14541
增量 2 · P1 确认 · WorkBuddy Bench：抗污染任务构建的多领域 Coding Agent 评测基准
来源: HF Daily 2026-07-26 · 20▲ · arXiv:2607.20911 · Tencent 类型: 评测基准 / Coding Agent / 任务污染防控 可信度: 中（Tencent 团队，benchmark 方向可信；待 PDF 核验污染防控机制细节）
要点： - Tencent 开源的多领域 coding agent 评测基准，核心设计：抗污染任务构建——解决 coding benchmark 中"任务泄露 / 数据污染导致分数虚高"问题 - 多领域覆盖（推测覆盖 CLI / GUI / API 等典型 coding agent 场景） - 在 HF Daily 2026-07-26 票数 20▲，是当天 evaluation 邻接新增条目之一 - WorkBuddy Bench vs SWE-bench：后者任务预先筛选导致锚定过紧（spec 质量而非模型能力是主要瓶颈），WorkBuddy Bench 试图在任务构造层面解决这一问题
与 knowledge/evaluation.md 现有脉络的关系： - 落入 §2.2「Benchmark 设计」——WorkBuddy Bench 抗污染机制补充了"benchmark 自身可信度"维度，与 R26「评测从题目分数演进到评测套件自身可信度审计」主脉络一致 - 与 v26 §2.2.4 SWE-bench 进化线（Terminal-Bench / SWE-Bench Verified / Pro / Rebench）邻接——WorkBuddy Bench 从任务污染防控角度提供新分支 - 与 Atrex-Bench（增量 1）同属 coding agent 垂直评测，但 Atrex-Bench 侧重硬件约束层，WorkBuddy Bench 侧重任务构造层，两者互补
建议归入节: §2.2 Benchmark 设计——WorkBuddy Bench（arXiv:2607.20911）抗污染任务构建，补充 coding agent 评测基准的污染防控维度
arXiv 号: arXiv:2607.20911
增量 3 · P2 邻接 · Agentic Context Management：上下文管理作为生命周期问题
来源: arXiv:2607.21503 · 2026-07-23 · today's 08:40 radar ⭐ 高价值条目 + jay 7-26 15:05 five-category briefing ⭐⭐ 类型: Agent 架构 / 生产可靠性（evaluation 维度为邻接，非主轴） 可信度: 中-高（问题定义有价值，具体机制待 PDF 核验）
要点： - 核心论点：生产环境 Agent 失败多因上下文管理失控，而非推理能力不足——把上下文当"存储检索"问题是过于狭隘的隐喻 - 认为上下文管理是生命周期问题：决定记忆什么、提取、压缩、遗忘，需要架构层面设计，不是加个向量库能解决的 - 与 OpenClaw/Tom 的 memory 管理机制直接相关——是 memory 不是 storage - 标签含 benchmark，属于 evaluation 维度邻接：上下文管理质量影响 agent 评测结果的可重复性（同一 agent 在不同上下文策略下得分差异可达 40%+）
与 knowledge/evaluation.md 现有脉络的关系： - 落入 §1.1「评测对象扩展：LLM 单点能力 → Agent / RAG / 多模态 / 长上下文」——上下文管理失控是 Agent 评测中"不可见失败"的来源之一（与 R26 §1.2 Deceptive Grounding 13 模型 100% 实体归属失败同源） - 落入 §2.8「trajectory-level + 生产级失败模式」——上下文管理是 agent 静默失败（silent tool call / latency explosion）的技术根因之一 - 与 R26 §1.33c 89% observability / 52% eval 落地 37pp 缺口邻接——缺乏上下文可观测性是 eval 落地难的技术根因
建议归入节: §1.1 评测对象扩展（Agent 上下文管理失控作为评测新维度）+ §2.8 trajectory-level 失败模式（上下文管理作为第七类静默失败根因）
arXiv 号: arXiv:2607.21503
矛盾 / 待核实
矛盾 1 · WorkBuddy Bench "抗污染"声明与当前 benchmark 污染现状的对比
- 现状：SWE-bench / SWE-bench Verified / Pro / Rebench 均存在任务预先筛选导致的锚定过紧（spec 质量而非模型能力是主要瓶颈）；Video-Oasis 14 video benchmark 55% shortcut 样本
- WorkBuddy 声明：通过抗污染任务构建解决数据污染问题
- 待核实：抗污染机制的具体实现方式；与 SWE-bench 锚定过紧问题的具体差异；是否有第三方独立复现
矛盾 2 · Agentic Context Management "不是存储检索问题"vs 当前主流 RAG-as-context 范式
- 主流实践：RAG + 向量检索作为 agent 上下文管理的主流方案（业界大量采用）
- ACM 声明：上下文管理是生命周期问题，RAG 只是存储检索，无法解决根本架构问题
- 待核实：ACM 是否提供了具体的架构设计模板，还是只是问题陈述；RAG 在上下文管理中应处于什么层级
本期不纳入的已知条目（已在上期或 R26 覆盖）
| 条目 | arXiv 号 | 不纳入原因 |
|---|---|---|
| OpenForgeRL | 2607.21557 | 已在 7-25 evaluation e1prep 旁证 2 覆盖；主分类 evaluation，method 形态，核心贡献是 agent 训练基础设施 |
| Show, Don't Tell | 2607.21072 | 已在 7-25 evaluation e1prep 确认增量 1 覆盖；R26 §2.102 已入库 |
| K12-KGraph | 2605.09635 | 已在 7-25 evaluation e1prep 旁证 1 覆盖（关联偏弱，降为旁证） |
| Agent-as-a-Judge Survey | 2601.05111 | 已在 R26 §1.33c 覆盖；agent judge ≈ 90% alignment vs plain LLM judge ≈ 70% |
| AgentAtlas | 2605.20530 | 已在 R26 §1.33c 覆盖；Taxonomy-aware vs blind 14-40pp |
| ReOPD | 2607.04763 | 已在 stephen 7-26 e1prep 作为 §2.108 第 7 栖续立候选；主分类 agent，非 evaluation 专项 |
引用 arXiv 号汇总
| # | arXiv 号 | 名称 | 角色 |
|---|---|---|---|
| 1 | 2607.14541 | Atrex-Bench | 🆕 增量 1 确认 |
| 2 | 2607.20911 | WorkBuddy Bench | 🆕 增量 2 确认 |
| 3 | 2607.21503 | Agentic Context Management | 🆕 增量 3 邻接 |
检查过的来源
tom inbox (7-25~7-26): - 2026-07-25-evaluation-e1prep.md（已覆盖 1 确认 + 2 旁证） - 2026-07-25-agent-e1prep.md - 2026-07-26-0900-hf-daily-2026-07-26.md（15 件，eval 邻接 WorkBuddy Bench 20▲） - 2026-07-26T0840-agent-rag-longcontext-radar.md（⭐⭐ OpenForgeRL + Agentic Context Management + FinanceComplexQA） - 2026-07-26T1440-agent-rag-longcontext-radar.md（⭐ FinanceComplexQA + Agentic Context Management） - 2026-07-26-rag-e1prep.md
jay inbox (7-25~7-26): - 2026-07-26.md（Atrex-Bench #10 优先精读 + OpenForgeRL） - 2026-07-26T1505-five-category-briefing.md（Agentic Context Management ⭐⭐ + OpenForgeRL ⭐⭐） - 2026-07-26-engineering-e1prep.md（OpenForgeRL + ReOPD 已在 §2.7 覆盖）
stephen inbox (7-26): - 2026-07-26-ai-industry-e1prep.md（paper_cards 575-597 抽查结果：仅 585-OpenForgeRL 主分类 evaluation + 565-Show Don't Tell 主分类 evaluation，其余 4 件主分类 agent/multimodal）
paper_cards (575-597, 3 天新卡): - 严格抽查 23 张：585-2607.21557（OpenForgeRL，evaluation 主分类）、565-2607.21072（Show Don't Tell，evaluation 主分类）、564-2607.21503（Agentic Context Management，agent 主分类）——其余均为 llm-infra / engineering / database / risk / rag / multimodal 主分类 - 7-26 HF Daily 无 eval 专项新 arXiv 立标
Tom · 2026-07-26 15:40 CST | evaluation E1 预消化 | 2 确认 + 1 邻接 | 3 个新 arXiv 号