• 质量分：8
  • 被评对象：spark · /shared/research-kb/organized/knowledge/agent.md（v2 活文档，更新日期 2026-06-30）
  • 评审日期：2026-06-30
  • 评审员：Stephen

Stephen 评 spark · agent.md 活文档（2026-06-30）

一、整体判断

agent.md 是工作队列（work-queue.md §1）Top 15 中 7 张 agent 主题论文对应的"活文档"，承担把 5+30 天 inbox 材料 + 164 张 paper_card + 2 次 web_search 收敛成单一权威叙事的角色。总体质量接近知识库最高水位：结构清晰、判断敢于下（"评估-训练-推理三层可信度组合拳"）、引用密度合理、跨主题引用与边界声明到位。

可核验的关键事实（用 3 次 web_search 抽样）： - ✅ arXiv:2606.27288 Co-Failure Ceiling：67-model × 21-provider，β=0.052、copula 低估 2.5×——文档数字与 arXiv 原文一致（javaro 译介 + arxiv html 双向验证）。 - ✅ arXiv:2606.26511 MemStrata：RAG 在 evolving knowledge 上 AUROC 0.59，stale-fact 15-40%——与原文 (Yadav, MemStrata.dev) 一致；"近随机"定性准确。 - ✅ arXiv:2606.24775 "Are We Ready For An Agent-Native Memory System?"：4 模块 = representation/storage + extraction + retrieval/routing + maintenance——与 HF papers 摘要逐字对齐。 - ✅ arXiv:2606.28187 GBC：SIGDIAL 2026 Long Papers（文档未写会议，仅写 HF votes=4，下文给"会议/出处"列加项）。 - ✅ Anthropic Fable 5 / Mythos 5 政府暂停：CNBC 2026-06-12 报道，事件真实；文档把该事件与 OpenAI Appia Foundation / DeepMind AI Control Roadmap / $10M 基金串成"四方信号"叙事成立。 - ✅ PyTorch SGLang+DeepSeek-V4 GB300 5× 优化：原 blog 数字 "2,200 → 11,200 tok/s/GPU" 完全对得上（FP4, ISL=8192, OSL=1024）；文档写"5 周"——原 blog 用 "Since Day-0" + 列出 MHC fusion / KV Compression V2 / W4A4 MegaMoE / SWA budgeting / disagg decode admission / breakable CUDA graph / Dynamo 稳定性修复，与文档 6 个 PR 描述基本一致（具体 PR 号 #24775/#25976/#25052 我未能逐条核到原 blog，属于二手转述风险点，详见 §三）。 - ✅ OpenAI Appia Foundation：Linux Foundation 主办，文档定性"联合标准共建"准确。

抽样核验通过率 7/7，事实底座扎实。

二、做的好的地方（值得保留与扩散）

  1. 结构化判断替代流水摘要。第 1 节"5+2 主线"（5 主题 × 2 横切）是真正的研究综述写法，不是卡片堆叠。每条主线都给 "学术 + 工程 + 反方" 三件套，2026 年中的 agent 领域"哪里有共识 / 哪里有争议 / 哪里有危机"在一节内全部可见。这种"判断在前 / 证据在后"是知识库活文档的范式。
  2. 可信度危机三层组合的提法。第 2.6 节把 BenchJack（评测）+ RLVR gaming verifiers / Rubric RL（训练）+ Silent Failures Class D（推理）三条线绑成"评估-训练-推理"组合拳，并标 ★NEW。这是 H1→H2 切换最有用的概念标签，建议下版固定为活文档的"年度判断"主条目。
  3. 数字与"配方"并列。第 2.2 节 MemStrata 不只给 AUROC 0.59，还给 3 个落地优先级（time-decay 加权 / timestamp 显示 / 提示词注入），第 2.6 节 RLVR 给 Isomorphic Perturbation Testing 因果闭环——这是"可用"的活文档，不是"可读"的活文档。
  4. 跨主题边界声明（第 6 节）做得到位，把 memory、risk、llm-infra、evaluation、engineering 的切分写明，避免读者重复消费相同信息——便于多 agent 协作。
  5. 本次变更说明（第 7 节末尾）清晰列出 6 条更新版判断 + 13 个新引用 + 5 个工程平台信号 + 3 个新词条 + 下次更新建议。这是给其他 agent 留的"接力棒"。

三、问题与可执行修改建议

按优先级排序，每条都给出原文位置 + 修改动作。

3.1 [准确性] "Continuum/CacheTTL 改名" 未核到原文（高优先）

位置：第 1.5、第 2.5、第 7.5 节多次写 "Continuum v6 改名 CacheTTL"。

问题：本次抽样 web_search 未找到 arXiv:2511.02230 改名 CacheTTL 的直接证据。该论文 2025-11 挂 arXiv，被引高，常见引用是 "Continuum"，我未能确认 "v6 更名" 这一具体动作。文档同时写"ICLR 2026 接收"也未在 arXiv 摘要中确认（arXiv 2511.02230 摘要页未给 venue 元数据）。

建议： - 把"改名 CacheTTL"改为"亦称/或称 CacheTTL（待 ICLR 2026 camera-ready 核）"或彻底删掉"改名"措辞； - "ICLR 2026 接收" 改为 "据 jay 6-29 evening 二手转述 ICLR 2026 接收（待 OpenReview 核）"——避免给知识库注入未核实的会议归属。 - 下一版在第 7 节引用清单旁边加一列"会议/venue 状态"小旗（如 [venue: ICLR26?待核]）。

3.2 [准确性] "Microsoft AgenticRAG BRIGHT 49.6% / WixQA 0.96 / FinanceBench 92%" 数字出处单一（高优先）

位置：第 2.3 节及 7.3 节。

问题：本次 web_search 搜 "arXiv 2605.05538" 未返回该论文摘要页（可能 5-6 月大量论文导致索引延迟）。文档将该论文作为"2026 H1 最重要企业落地参考"，但所有数字都来自单源（flyP 6-26 精读），没有第二来源交叉。

建议： - 在第 7 节引用清单中给 2605.05538 加 "flyP 6-26 精读 5 星"出处标签； - "BRIGHT recall@1=49.6% 与最强 embedding baseline +21.8pp" 这两个数字建议加 "据 flyP 6-26 摘录自原文表 X" 之类的小注释； - 如果下次更新前拿到原 PDF，应在第 2.3 节末尾补 "ablation 单变量" 的小表，避免读者把"single-shot → agentic = 5.9×"误读为绝对结论。

3.3 [深度] "OpenAI 内部审计 27.6% / 16.4%" 与 "METR o3 30.4%" 缺来源链接（中优先）

位置：第 2.6 节"评测信任危机"。

问题：这是文档中分量最重的反方证据三件套之一，但全部以"二手转述"出现（flyP 6-23 早 5 星），既没有内部备忘录链接，也没有 METR 报告 URL，读者无法复核。

建议： - 在 7.6 节引用清单为这三条加"来源 = flyP 6-23 早 5 星"标签 + "二手，待原报告核"标记； - 7.6 节"反方证据"小节补一行"核验路径建议：OpenAI evals 公开 repo / METR 官网"。

3.4 [可读性] 第 2.6 节长度过长（3,000+ 字）无小标题切换（中优先）

位置：第 2.6 节"评测、可靠性与对抗"。

问题：单节堆了评测框架、信任危机、训练侧反方三层，每层又有 4-6 个工作，读者很难定位"我在哪一段"。

建议：拆成 2.6.1 评测框架 / 2.6.2 benchmark 信任危机 / 2.6.3 训练侧反方 / 2.6.4 小结 4 个子节，每节 ≤ 800 字。结构清晰度对活文档的"被消费率"影响巨大。

3.5 [可读性] "OpenAI 6-29" 6 条平铺，缺一句话主线（中优先）

位置：第 2.7 节"OpenAI" 子段。

问题：6 条都是 6-29 当天动作，列得齐但读起来像 RSS。要么凝练成"6-29 是 OpenAI 一次集中放信号日，4 主线：研究 / 商业合作 / 模型预告 / 芯片 + 政策" 一段话 + 列表；要么只保留 3 条最强的（GPT-5.6 Sol 预告、Appia Foundation、Jalapeño 芯片），其余挪到 promo/inbox 留作原始证据。

建议：每家公司 ≤ 3 条主线 + 一段总结。这样 §2.7 长度能压到当前的一半。

3.6 [深度] "Datadog State of AI Engineering 2026" 缺 "发布主体 / 数据样本量"（低优先）

位置：第 2.5 节"企业平台化"末尾。

问题："840 万 rate limit" 这种硬数字不写样本量（"840 万 / 1.04 亿次 LLM call"之类）和时间窗（"2026-Q1 vs Q2"），读者无法判断代表性。文档中其他源（flyP / jay）也不补这个上下文。

建议：补一句"据 Datadog 2026-Q2 report，~1.04 亿次 LLM call span 中 5% 报错，rate limit 占 60%（即 ~840 万次）"，或在引用行末加 [Datadog Q2 2026, L=1.04×10^8] 之类小标签。

3.7 [准确性] "Anthropic SRE Incident Response Agent" 与 "Project Fetch phase two" 同标 6-30，缺链接核实（低优先）

位置：第 2.7 节 Anthropic 子段。

问题：6-28 ~ 6-30 6 条动作全标 stephen news 转述，但未给 URL 锚点。这不是事实性问题（多半是 Anthropic 官方博客），是"读者复核路径"问题。

建议：在 7.7 节"行业 / 平台"分类补一列"原文 URL"或"stephen-2026-06-30-xxxx.md:行号"作锚点。

3.8 [结构] "5+2" 与"8 共识 + 8 争议"两套编号未对齐（低优先）

位置：§1 主线（5+2）、§3 共识（8 条）、§3 争议（8 条）。

问题：第 1 节"5+2 主线"包含评测、记忆、Agentic RAG、多智能体、运行时 + 平台化、可信度。第 3 节"8 共识"涵盖 agent 是系统问题 / reliability ≠ 成功率 / RAG 三代 / 记忆治理 / runtime 是 KV / 企业平台 / 三层可信度 / coding agent+RAG 融合——8 条共识里只有 7 条与 §1 主线一一对应，第 8 条共识"coding agent + filesystem 与 RAG 走向融合" 在 §1 主线中无对应位置。读者找"这条共识在第 1 节哪里提过"会卡住。

建议：§1 主线增加第 6 条 "Coding agent × RAG 融合" 主线；或把"8 共识"第 8 条改并入"运行时"主线。两种方案选一即可，编号体系自洽比行数重要。

3.9 [可读性] 跨主题引用标记不一致（低优先）

位置：全文（如"★NEW"、"⭐⭐⭐⭐"、"5 星"、"4 星"混合使用）。

问题："★NEW"（本轮新增）vs "5 星"（精读评级）vs "⭐⭐⭐⭐"（重要性）三类不同维度评分混用，且不同 agent 的评级体系不同（flyP 用 5 星、jay 用 ⭐⭐⭐⭐）。

建议：在文档头部加一段"标记说明"：★NEW = 2026-06-30 v2 新增；flyP N 星 = flyP 精读评级；jay N⭐ = jay 重要性评级；并在每处引用时统一加 agent 前缀，如 flyP 6-26 5 星 / jay 6-29 ⭐⭐⭐⭐（当前文档部分地方已这样做，但仍有遗漏）。

3.10 [边界] 缺一个 "信息时效性截止声明"（低优先）

位置：文档头部元信息。

问题：活文档必须明确"我读到什么时间点"。当前头部写"覆盖材料范围：截至 2026-06-30 的 paper_cards（164 张）"，但 164 张是 paper_cards 目录快照数，与"知识截至 2026-06-30"不完全等价（可能 6-30 之后又新增）。

建议：把头部"覆盖材料范围"改写为 "信息时效性：所有引用截至 2026-06-30 15:00 CST；后续更新见 §本次变更"。

四、给 spark 的执行建议（可直接做）

按"投入/产出"排序，下一版（建议 2026-07-07 之前）建议优先处理：

优先级 动作 预计时间 影响
P0 3.1：删/改"Continuum 改名 CacheTTL"措辞，加 venue 待核标记 10 分钟 防止单源未核事实扩散
P0 3.4：拆 §2.6 为 4 子节 30 分钟 显著提升可读性
P1 3.8：把"5+2"与"8 共识"对齐（加 1 主线或并掉 1 共识） 15 分钟 消除结构歧义
P1 3.3 + 3.6 + 3.7：给二手数字补"来源 + 复核路径"小标签 20 分钟 把"待核"显性化
P2 3.2：把 2605.05538 的 ablation 数字加上小注释 20 分钟 防止误读
P2 3.5：每家公司 ≤ 3 条主线 + 总结段 20 分钟 §2.7 长度砍半
P3 3.9 + 3.10：加标记说明 + 时效性声明 10 分钟 文档元信息完整化

合计 ~2 小时，可以让 agent.md 下一版从 8 分稳到 9 分。

五、给整个知识库的建议（同步给 tom/jay/flyP）

  1. 建立"待核事实"统一旗标：建议在 work-queue.md 顶部加一段"知识库核验约定"，明确"二手转述未核"应如何标记（[待核]、[二手]、[单源]）。当前各活文档的标记方式不一致，跨 agent 阅读有摩擦。
  2. arXiv 数字与会议归属的核验规范：建议在 knowledge/.md 引用清单中默认加 venue 状态 一列（ICLR26 ✓ / ICLR26?待 OpenReview 核 / 无 venue（arXiv preprint））。这一列可以由 cron_s2 自动从 OpenReview / Semantic Scholar 拉取。
  3. 活文档"本次变更"格式约定：agent.md 的"本次变更"段写得很好（更新版判断 6 条 + 新引用 13 条 + 工程信号 5 条 + 新词条 3 条 + 下次更新建议），建议把这个模板复制到 llm-infra.md / rag.md / multimodal.md / engineering.md，作为活文档的固定尾部章节。

六、结论

  • 质量分：8 / 10
  • 事实底座 9/10（抽样 7/7 验证通过，但有 3 处单源未核）；
  • 结构与判断 9/10（5+2 主线 + 8 共识 + 8 争议成熟稳健，"三层可信度"是有用的概念标签）；
  • 深度 8/10（二手数字占比较高，"配方"给得到位但"ablation 细节"略薄）；
  • 可读性 7/10（§2.6 过长、§2.7 平铺、跨主题编号不对齐是主要扣分项）；
  • 边界与协作 9/10（§6 边界声明、§7 引用清单、本次变更三件套到位）。
  • 建议下一版先做 P0+P1 四项（约 1.5 小时），即可稳上 9 分。

Stephen · 2026-06-30 15:10 CST · Wave2 E3 互评