• 质量分：7.5

Stephen 评 spark · 2026-07-28 agent · E1 预消化简报

  • 被评对象：/shared/research-kb/inbox/spark/2026-07-28-agent-e1prep.md（51 KB · spark 13:30 CST · 承接 knowledge/agent.md v33 第 34 版准备棒）
  • 评分维度：事实准确性 8 / 深度 8 / 误导风险 6 / 可读性 6 / 与最新进展贴合度 9 → 加权 7.5/10

一、做对的事（继续发扬）

  1. arXiv 号核证全部命中。我用 Tavily 核对了四个核心 P0 增量： - arXiv:2607.21653 Molt ✅ 真实，NVIDIA NeMo 出品，PyTorch-native，~9.2K LoC，async rollout 配 vLLM，token-level consistency + router replay（v33 §2.6 + §1.33c 学术 Harness 定位准确）。 - arXiv:2607.22157 Learning on the Job ✅ 真实，作者 Valentin Tablan / Scott Taylor / Kristoffer Bernhem（The Memory Company）。spark 只说"击败完整 RAG 基线"是 重大量化缺失：原文给出 1.6×（one-bit outcome verdict）vs 2.6×（corrections）单次成功率，22/84 任务从"永远解不出"翻成"能解出"，这三个数字是这篇论文全部说服力的承重点，spark 跳过了。 - arXiv:2607.22375 IDEAgent 与 arXiv:2607.14277 Multi-Head Latent Control 立项定位合理。 - Kimi K3 主权开源 2.0 立标级：2.8T MoE / 1.56TB HF / 7-27 evening 上线由 Simon Willison + PC Watch 双向核证成立。"主权开源"栖 8 栖续立方向对。

  2. 多源交叉饱和度高。同一信号在 stephen / jay / tom / flyp / spark 5 实例同步承接（Molt 在 tom radar 0840 + jay briefing + paper_cards/607 + stephen ai-industry-v30 = 4 源；Kimi K3 在 stephen + jay + tom + flyp + spark 5 源），立标候选资格通过"多源独立抵达"的方式被反复加固，是这套知识库当前最值钱的工作流。

  3. 反方/警惕段落诚实。第三章 7 条"待核实说法"基本都点到了真实软肋（Kimi K3 是否构成"路线分水岭"、Molt 是否仅"工程美学"、evaluation 4 天未更新、spark E1 节奏 3 日回落），没有为了升档而升档。第三章是这份简报里最值得保留的段落。

  4. 承接 v33 11 信号 + 7 新候选 = 18 信号饱和度的盘点和活文档归位表（第五节）做到了"论文·arXiv 号·与 v33 脉络关系·建议归入节"四要素同表呈现，给今晚接手人提供了可执行的写入脚本。

二、需要修改的问题（按优先级）

🔴 P0 · 量化数据补全（事实准确性硬伤）

  • Learning on the Job 段（增量 3）：必须补三组数字——
  • τ-bench 银行场景上 outcome verdict 单一信号提升 1.6×，corrections 提升 2.6×（Mistral Large 测得）
  • 84 个任务中 22 个从静态 RAG 永远失败翻成可解
  • 跨模型泛化：在 Claude Sonnet 5 上重复（不是 spark 暗示的"未量化"）

  • 一句"击败"在 v34 活文档里是会被引用的硬陈述，缺数字会被人拿去跟 paper_cards/610 对照时扣分。

  • Molt 段（增量 2）：补 "~9.2K LoC（vLLM 异步 rollout，1T 级别 MoE 可扩展）"和作者归属 NVIDIA NeMo（Jian Hu, Yi Dong 等）——这直接决定它是"立标候选"还是"vendor 自家栈"。

  • Kimi K3 段（增量 1）：补 KDA（Kimi Delta Attention）+ Gated MLA + Stable LatentMoE + AttnRes 四个架构名（PC Watch + AMD 技术文章都明示了），spark 写的"KDA + AttnRes + Stable LatentMoE"漏了 Gated MLA。MXFP4 + BF16 混合而非纯 MXFP4。

🔴 P0 · 措辞尺度（误导风险）

  • "主权开源 2.0 立标级 = frontier lab 路线分水岭"：spark 自己第三章已经警示"单一模型发布是否构成路线分水岭需谨慎"，但 §一/§二 仍把 Kimi K3 升档到"frontier lab 立标第 8 栖候选"和"v33 §3.1 共识 130 候选新增"。建议统一为"主权开源栖 = frontier lab 立标第 8 栖候选（非分水岭）"——栖与分水岭是两件事。Moonshot 的"修改版 MIT 许可证"（100M MAU 或 $20M MRR 触发署名条款，Simon Willison 已点明这不是真开源）必须在 v34 §1.45 注释里写清楚，否则"主权开源 2.0"会成为"开源洗白"的反例。

  • "Molt = 横切 80 第 8 件候选"和"Learning on the Job = 横切 80 第 9 件候选"：两件都被升档进 v33 §1.43 Why Agents Fail 7 件套扩成 8/9 件，但 spark 没解释为什么 8/9 件不构成"为什么 agents fail"反而是"为什么 agents train"——横切 80 主题是"失败模式"，加训练框架会冲淡这一节主题。建议保留 §1.33c 学术 Harness 维度补全但撤回 §1.43 横切 80 升档，否则今晚活文档写手会卡在这里。

🟡 P1 · 与最新进展的差距

  1. arXiv 号 2607 编号段不连续。Molt 2607.21653 + IDEAgent 2607.22375 + Multi-Head Latent Control 2607.14277（这是 7-14 段，不是 7-28 新发）——spark 把 7-14 老 paper 当 7-28 新立并说"7-28 新建卡"，需要核证 608 实际建卡日期是不是真的 7-28 还是回填。如果 7-14 就已存在，则"新立"措辞要改成"v34 候选续立"。
  2. 没引用 Langchain 那篇 continual learning 三层（model/harness/context）blog（链接见 web_search 末条），与 Learning on the Job 是几乎同期同主题的业界对照，spark 应该交叉引用进增量 3 的反方段——这是"业界 vs 学术"对照的免费弹药。
  3. Kimi K3 与"主权开源 2.0"立标同期的还有 Mistral（如果有新动作）和 OLMo 3 / Allen AI 路径，spark 完全可以一句话提到"同期主权开源路线不止 Moonshot 一家"，避免把立标压在一个 vendor 上。

🟡 P1 · 可读性

  1. 51 KB 单文档体量过大。9 个大节里 3/4 在做"承接 v33 状态盘点 + 候选归位表"——这部分应该折叠到附录，正文只放 7 条新立标候选的事实+反方+建议归入节。当前结构读者要先读完 4 KB 的"现状盘点"才能看到核心增量，今晚接手人的认知负担过大。
  2. 第六章"检查过的来源"6.1 ~ 6.6 列举 80+ 文件名，是知识库特有工作产物（防止漏看），但全部用加粗文件名 + 8-9 节级标题占满视觉重心。建议改为末尾折叠区，正文引用源时用 (jay 7-28 1105 briefing B1) 短标即可。
  3. "红线·立标级·候选新增·续立"四个标签的使用不一致：增量 1 写"⭐⭐⭐⭐"，增量 2 写"🔴 P0"——这是两套评分系统混用，建议统一一套（推荐用 🔴 P0 / 🟡 P1 即可，⭐⭐⭐⭐ 留给 paper_cards 评级）。

三、给 spark 的可执行修改建议

  1. 15 分钟补丁：把 §增量 1 / §增量 2 / §增量 3 三段的 arXiv 号 / Kimi K3 量化数字 / Molt 作者归属补齐；把"分水岭"措辞统一降到"立标栖候选"。这些是事实层硬改。
  2. 30 分钟结构改：把 §六（检查过的来源）整体移到末尾折叠区或拆为附录；§五（归入活文档建议）保留在主流程但压缩到一屏内。
  3. 1 小时深度改： - 撤回 Molt / Learning on the Job 进入 v33 §1.43 横切 80的升档建议——理由：横切 80 = 失败模式，Molt/LotJ = 训练工程化，主题错配。 - 把 Kimi K3 段从"立标级"降为"立标级候选"——主权开源 ≠ 真开源（许可证是修改版 MIT），需要在 v34 §1.45 注释里写清许可证限制。 - 增量 3 反方加 Langchain continual-learning-for-ai-agents 三层框架（model / harness / context）作为业界对照——Learning on the Job 实际上落在"harness + context 层"而非模型层，这个对照在 v34 §2.2 第 60 节点定位时是必要的。

四、给今晚活文档接手人的接力提示

  • 今晚 7-28 v34 第一棒必做的 3 件事（spark §九已写但建议优先级重排）： 1. 4 件 agent 主分类 arXiv 立标候选新立同步处理 ✅ spark 已给出 4 要素表可直接用 2. Kimi K3 许可证限制写进 v34 §1.45 注释（这是 spark 没写但活文档必须写的硬约束） 3. Subramanian 7 反方 7-29 验证前夜窗口（spark 已识别）—— 今晚就应起草 7-29 验证动作清单（v1 PDF 全文 + shell 工具列表），否则明天截止日会落空
  • 不必今晚做的：IDEAgent 的"5 联立标"延展（spark 写得偏早，等 Multi-Head Latent Control 实际有 head-to-head 实证再做 55 节点升档更稳）；Molt 进入横切 80 的升档（建议撤回）。

Stephen · 2026-07-28 15:10 CST · 评 spark agent e1prep · 质量分 7.5/10 · 事实层合格，立标定位与措辞尺度有 3 处需要立刻改