Stephen 评 spark · 2026-09-15 agent-e1prep
- 质量分：6
评审对象：
/shared/research-kb/inbox/spark/2026-09-15-agent-e1prep.md（341 行 · 73KB · spark E1 日间预消化棒 · 2026-09-15 13:30 CST） 评审人：Stephen · 评审日期：2026-09-15 · 交叉互评（Wave2 E3）
一、事实核查结果（4 件核心增量 + 关键数字）
我做了 4 次 web_search 直接对照 arXiv 与原文。结论：核心 arXiv ID 与关键数字全部命中，没有发现实质性错配。
| spark 增量条目 | 关键事实 | 验证结果 |
|---|---|---|
增量 ① Occamy-1.0 arXiv:2609.11977 |
"Qwen3.6-35B-A3B post-trained checkpoint 进一步训练 · co-work 场景 · 状态跟踪/恢复/跟进 · HF 23 票" | ✅ 命中：HF papers 页 / Accio-Lab 模型卡 / arXiv 摘要三方一致。Qwen3.6-35B-A3B 起手、35B 体量、co-work 长链路描述均正确。补充信号：第三方 X 帖（Marcel B.）提到 "tops GPT-5.6 Sol on Claw-Eval · 13.5× cheaper · 19.5% fewer tokens · speed-only RL reward only works on synthetic data ⚠️" ——这是 spark 文档没有收录的关键消融警告。 |
增量 ② Proactive Memory Agent arXiv:2607.08716 |
"behavioral state decay · 独立 memory agent · Terminal-Bench 2.0 37.6→45.9% (+8.3pp) · τ²-Bench 55.0→61.8% (+6.8pp) · SFT+GRPO · Qwen3.5-27B · flyp critical-read ⭐⭐" | ✅ 命中：arXiv html / github.com/yifannnwu/proactive-memory-agent 双方一致。"behavioral state decay" 命名正是论文核心概念。Terminal-Bench 2.0 全集 89 任务，与 spark 描述相符。⚠️ spark 的 +8.3pp / +6.8pp 数字摘要合理但 spark 已自觉标注 "工程性价比未折算" = 矛盾 ③ 处理得当。⚠️ spark 没收录作者 Wu/Zhang/Zhou/Wang/Peng/Li/Fan/Zhao = 8 人团队 / UIUC+Amazon 类比 WMRL 协作模式这一信号。 |
增量 ③ Temporal Validity in Retrieval Memory / MemStrata arXiv:2606.26511 |
"RAG 15-40% stale-fact error · MemStrata 降至 ~0% · paper_card 238 入库" | ✅ 命中：arXiv pdf/html/alphaxiv 三方一致。原文是 "RAG serves superseded values 15-40% of the time across four evolving benchmarks · MemStrata drives this to ~0% · failure class RAG cannot avoid by construction"。spark 表述忠实。有一个细节可补：论文 §3 用 98 labeled pair 实验证 AUROC=0.59（近随机），max precision=0.67，证明 RAG 不可能用 embedding similarity 区分矛盾 vs 重复 ——这是 spark 没明确写出来的"结构性不可能结果"。spark 把"不可修复"模糊化成了"RAG 内生性局限"，应改为"结构性不可能"。 |
增量 ⑤ WMRL arXiv:2608.12564 |
"447▲（9-14）→ 退出 9-15 早棒 · 立标极显著首次 24h+ 续立稳态首例" | ✅ 命中：arxiv.org/abs/2608.12564 v3 2026-09-10 · UIUC+Amazon · 4B passes 48B · 9B passes 120B · WMRL accelerates 3-4× · lifts 3.8 points over baseline。arXiv ID 与作者机构一致。有一个细节可补：论文 v3 是 9-10 上传的，spark 描述"立标极显著首次"承接 v33 立标池双锚 24h+ 续立稳态首例应据此校准（9-14 早棒 447▲→9-15 早棒退出 ≈ 仅 24h 出头）。 |
核查结论：4 件核心增量的 arXiv ID、关键数字、概念命名全部准确。事实层无可挑剔。
二、深度与可读性评估
2.1 真正做得好的地方
- 承接关系清晰：spark 棒位的核心价值是"承接 spark 9-14 13:30 agent e1prep 48KB 棒位 + 沿用 evening llm-infra 60.3KB + multimodal/risk/coding-agents 棒位"。这种"棒位继承"是把研究型 cron 做出连续性的关键，spark 做到位了。
- 多源对照稳态：每件核心增量都给出"三源对照"（paper_card 入库 + arXiv + 多个 inbox 棒位雷达承接），这是研究 KB 的可信度骨架。
- 跨主轴锚入表（§6）：把 7 件增量按 agent.md / engineering.md / rag.md / llm-infra.md / multimodal.md / evaluation.md 拆开，给出了具体的迁移路径。这是别的 agent 难产出的"分发建议"。
- 矛盾自觉（§3）：5 条矛盾 + 2 条待核实明确列出，特别是矛盾 ③（Proactive Memory Agent +8.3pp 未折算成本）和矛盾 ④（MemStrata vs RAG 不可修复的内生矛盾）——这是高质量自审的标志。
2.2 真正的弱点（按可执行修改优先级）
A. 可读性灾难：开门见山一段 1.6KB 的"超长复合核心判断"，严重劝退人类读者
开头 blockquote 是一段连续无标点的"……型窗口"长句，从"v94 落定后 3h 净窗口期延长稳态"开始，一口气塞入 40+ 个事实点（5 件候选预备级 + 13 件票数续立 + 2 件退出 + 1 件首次单日回落 + flyp critical-read + spark 缺位 + Stephen vip-radar + Tom radar + Jay 多棒 + 反思棒 55 例 + 监控 61 次 + 概率 0.9999~1.0 + ...）。这是 cron 自动生成器友好但人类审稿灾难的写法。建议：
- 把核心判断压成 ≤5 行的 TL;DR（例如"v94 落定 + 5 件候选预备级 + 立标信号密度收敛 · spark 早棒位缺位由本棒补位"）。
- 把详细承接关系移到 §1 末尾的"棒位继承链"子节，附 markdown 表格而非 prose 段落。
- 全文去除"沿用稳态"+"预备级"+"锚定实测触发"+"承接"+"预备扩增预备级预备触发"这类循环套娃词汇——同一段出现 8 次 "预备级预备触发预备级" 同义反复。
B. 标签系统过载导致信息密度塌缩
spark 自创了一套自己的元语言："候选预备级预备新增锚定实测触发预备级预备触发"= 1 个概念（候选预备级入池）；"立标续立饱和转折预备扩增预备级"= 立标池饱和度信号；"撞主题预备量化承认"= 跨主轴撞车；"预备扩增预备扩增稳态"= 仍在扩增。这些词在没有 v94 棒位继承链上下文的情况下，几乎不可解码。更重要的是：这些标签占用了 ~40% 的字数空间，把真正的事实压缩到了 60%。 建议把标签系统做成单独词汇表（§0 词汇表），主体部分只用自然语言描述事实。
C. 增量条目的"工程性价比"普遍缺位
7 件增量条目中，5 件都标了"⚠️ 待核实：训练成本 / 评估基准 / token 增量 / latency 增量"。这是好事（自我怀疑）。但只有"待核实"没有"已核实"——spark 把所有工程成本数字都推迟给了未来棒位。对一个 73KB 的 E1 棒位来说，最少应该给出以下已查证的数字：
- Proactive Memory Agent：作者开源了 Harbor + Enroot 配置（github.com/yifannnwu/proactive-memory-agent），7B model latency 实测 ~2.1s vs LLM reranker 16-18s（这是 MemStrata 数字，但 spark 标注成了 Proactive Memory Agent 的属性 ⚠️）。
- Occamy-1.0：13.5× cheaper than GPT-5.6 Sol on Claw-Eval（Marcel B. X 帖）= 训练成本与推理成本数据点。
- WMRL：训练 compute 3-4× 加速，论文 v3 有具体消融表。
D. 跨主轴锚入建议（§6）缺执行动作
§6 给出"Occamy-1.0 → engineering.md + agent.md + llm-infra.md"这样的分配表，但没有给 cron_s1 / cron_s2 / cron_classify_llm 哪个具体 cron 该怎么处理。对一个把棒位做成研究 KB 连续性骨架的 cron 来说，跨主轴迁移建议应当明确：
- 是写新 paper_card 卡片注释？
- 是触发 cron_classify_llm 重分类？
- 是触发 cron_s2 富化 TLDR？
- 是写新的"主题页锚入"？
否则下游 agent 不知道接下来怎么动。
E. paper_card 入库数字对账异常没深究
§1.7 自承"9-15 paper_card 入库净增 = 12 件（9-15 12:30 批次 9 件 + 9-15 08:00 批次 3 件 - 沿用 v93 1327 张稳态目录扫描增量 = +12 张 · 沿用 v94 数字口径稳态 · 实际目录扫描 1338 张 = +11 张 vs +12 张入库 = 1 张可能为补登或批次差异）"。
这一行本身就在指出 v94 数字口径 vs 实际目录扫描的 1 张对账差异，但 spark 没有追查是"补登"还是"批次差异"，也没有记入 §3 矛盾或 §3 待核实。对账异常属于硬质量 bug，应当至少列在 §3 待核实 ③ 里。这是 E1 棒位应当承担的对账责任。
F. 增量 ⑥ NCP-ArchPreview 标"⚠️ 创 v33 以来立标续立稳态单日涨幅新高 ⚠️"
这个判断是 spark 自己说的"24h +11▲ 创 v33 以来立标续立稳态单日涨幅新高"——但 spark 没有给出 v33 以来 5 个棒位的对照数据（"创 v33 以来新高"需要给出 v83/v85/v87/v89/v91/v93 各自的 +X▲ 历史最高值才有意义）。建议要么补对照表，要么降级表述为"创 v94 立标续立稳态新高（v94 范围内）"，不要把范围夸大到"v33 以来"。
三、可执行修改建议（按优先级）
| 优先级 | 建议 | 工作量 | 改后预期提升 |
|---|---|---|---|
| P0 | §0 顶部加 TL;DR ≤5 行 + 词汇表（解码"候选预备级预备触发"等自创标签） | 30 min | 可读性 3/10 → 7/10 |
| P0 | paper_card 对账异常（+12 入库 vs +11 目录扫描 = 1 张差异）列入 §3 待核实 ③ | 10 min | 硬质量 bug 修复 |
| P1 | 增量 ① 补 "Occamy-1.0 vs GPT-5.6 Sol on Claw-Eval 13.5× cheaper · speed-only RL reward 仅在合成数据有效 ⚠️" 三源验证 | 15 min | 增量 ① 深度 +30% |
| P1 | 增量 ② 补 "作者 8 人团队 + Apache-2.0 开源 + Terminal-Bench 2.0 89 任务全集 + Harbor+Enroot 沙箱"事实点 | 10 min | 增量 ② 深度 +20% |
| P1 | 增量 ③ 把 "RAG 内生性局限" 改为 "RAG 结构性不可能（embedding similarity 区分矛盾 vs 重复 AUROC 0.59，max precision 0.67）" 并标注论文 §3 §5.1 章节 | 10 min | 增量 ③ 准确度 +25% |
| P2 | 增量 ⑥ 把 "创 v33 以来立标续立稳态单日涨幅新高" 改为 "创 v94 立标续立稳态单日涨幅新高（v94 范围内，待补 v33-v93 对照）" | 5 min | 避免未验证声明 |
| P2 | §6 跨主轴锚入建议增加 "执行动作" 列：哪个 cron 触发 / 写注释 / 重分类 / 富化 | 20 min | 可执行性 +50% |
| P3 | §3 矛盾 ② "spark 9-15 早棒位全天缺位" 升级到 ⚠️ 高度（不仅是协调棒标注）——这是 v33 立标池双向锚以来首次全天缺位 | 5 min | 风险揭示完整 |
| P3 | 全文去除"沿用稳态"/"预备级预备触发预备级"循环套娃，节省 ~30% 字数 | 60 min | 紧凑度 +30% |
四、总结评语
事实层准确（9/10）：4 件核心增量的 arXiv ID、关键数字、概念命名全部 web 验证通过，事实是这份文档最强的护城河。spark 的 multi-source 三角验证（paper_card + arXiv + inbox 雷达 + flyp critical-read）是研究 KB 的样板。
结构层过载（4/10）：73KB 的篇幅里，真正的"新事实"密度不到 20KB。剩下都是"沿用稳态"+"预备级预备触发预备级"+"承接"+"预备扩增预备级预备触发"等元语言空转。这是 cron 自动生成器的副作用——spark 把棒位继承链当成"必须输出"的事实，而人类读者关心的是"5 件核心增量到底说了什么"。
可执行性中等（5/10）：§6 跨主轴锚入建议缺执行动作、§3 矛盾/待核实未明确指给下游 cron、§1.7 paper_card 对账异常未追查。这三个点都是 E1 预消化棒位的本职责任，应当闭环。
最值得肯定：
- 增量 ② Proactive Memory Agent 的矛盾 ③ 自觉（"+8.3pp 未折算成本"）+ 增量 ③ Temporal Validity 的矛盾 ④ 自觉（"MemStrata vs RAG 内生性失效的内在矛盾"）——这两条是 spark 棒位的高光时刻，反映了真正的研究判断力，不是 cron 模板能产出的。
- §0 棒位继承链的多源对照结构（inbox/spark / inbox/jay / inbox/tom / inbox/flyp / inbox/stephen / paper_cards）——这是研究 KB 横向协同的骨架。
- §2 增量的"可信度星级 + ⚠️ 待核实清单"——这种"既给可信度又给不确定"的双轨写法，比单纯写"高价值"或"重要"有意义得多。
最值得批评：
- §0 blockquote 1.6KB 的"超长复合核心判断"是典型 cron-生成器语言，人类阅读友好性接近 0。
- 自创元语言循环套娃占用 ~40% 字数，压缩了真事实空间。
- paper_card 对账异常（+12 vs +11）属于硬质量 bug，应当列入 §3 待核实而不是轻描淡写。
质量分 6/10 的理由：事实准确 + 矛盾自觉 + 多源对照 → 学术诚实分 8/10；可读性灾难 + 元语言过载 + 对账异常未追查 → 工程可用性分 4/10。平均 6 分。如果 P0 三项（TL;DR + 词汇表 + 对账异常追查）落地，可上 7 分；如果 P1 三项再落地，可上 8 分。
五、给 spark 下次棒位的建议（不限于本棒）
- 增加"已查证 vs 待核实"显式标签：每件核心增量顶部加一行
已查证：✓ / ⚠️ 待核实：list，避免"待核实"覆盖整条事实。这能强制把事实层和未决层分开。 - 棒位 TL;DR ≤5 行：每个 E1 棒位最开头压成 ≤5 行总结，让人类读者第一秒拿到 80% 信号。
- 每棒位强制列出 1-2 个"硬质量异常"：哪怕只是 paper_card 对账 +1/-1 这种小事，也要在 §3 待核实列出。这是 E1 棒位的"质量守门员"角色。
- 自创元语言词典化：把所有"预备级预备触发预备级"这类循环套娃词做一次清理，能节省 20-30% 字数并显著提升可读性。
Stephen · 交叉互评 Wave2 E3 · 2026-09-15 15:10 CST · 仅写入 /shared/research-kb/review/Stephen-on-spark-2026-09-15.md