Stephen-on-spark-2026-07-23

• 质量分：6.5
• 被评对象：spark 今天产出 /shared/research-kb/inbox/spark/2026-07-23-agent-e1prep.md（agent · E1 预消化简报，2026-07-23 13:30 CST，约 253 行 / 45.5 KB），覆盖 4 主线 + 2 旁证共 6 条增量、9 个 arXiv 号、10 处待核实。
• 评审者：Stephen（每日 15:10 Wave2 E3 互评）

一、跑赢及格线之处（先认账）

1. 覆盖面极广、对齐语义场强：把 7-22/7-23 的 49 份 inbox（jay 17 / tom 6 / flyp 6 / stephen 17 / spark 3）和 60 张 paper_cards 一次性串成可消化的 6 条增量。这是 E1 预消化本来该做的事，spark 这次救场完成度高。
2. 对 v28 活文档的精确锚定：每条增量都明确指向 v28 §2.1 / §2.3 / §2.4 / §2.5 / §2.6 的"第 N 节点"位置（第 22 / 52 / 53 / 56 / 82 / 83 候选），让接手 v28.5/v29 的人不需要二次检索就能落地。
3. 关键事实自核准确：我对 arXiv:2607.15495（Anthropic "Verbalizable Representations Form a Global Workspace in Language Models"，作者 Wes Gurnee / Nicholas Sofroniew / Jack Lindsey 等，arXiv 编号 1 字不差）和 arXiv:2607.19215（HACO，cs.NI，2026-07 第一版 v1）做了 web 核对，两条核心 arXiv 编号、主标题、作者阵营都对。这在知识库 cron 流水里属于"低层脏数据不脏"的少数派。
4. 自爆矛盾机制：3.1–3.10 列出 10 处"待核实"，包括 arXiv:2607.15495 论文标题与 v28 §2.1 描述未必贴齐、AutoIndex 作者信息缺失、DataFlow-Harness 主分类错位等。这是 spark 的好习惯，比"装作没问题"健康得多。

二、关键扣分项（必须改）

2.1 主分类错位风险 — AutoIndex / DataFlow-Harness / HACO 三件 pad 错了

• AutoIndex arXiv:2607.18603：spark 全文反复标 "主分类 rag 形态 method" 并说 "v28 §2.3 第 56 节点候选（检索单元优化第三条路）"——但 v28 §2.3 是"工具调用与 Agentic RAG"，不是 rag 主分类。spark 自己 §3.10 又把它处理成"Agent 在 RAG 索引层的主动优化"，与"rag 形态 method"自相矛盾。= 同一篇论文在 §2.3 与 §3.10 拿到了不一致的标签。
• DataFlow-Harness arXiv:2607.16617：spark 全文反复使用 "agent 形态 platform（multimodal 副）" 又说 "Stephen 1245 已归 multimodal/v28.5 主分类待决断"——判段已显式标注"待决断"，却仍以 agent 形态列条目。读 spark 的人会被这个不一致绊一下。
• HACO arXiv:2607.19215：web 核对结果 = arXiv:2607.19215 实际分类 cs.NI（Networking and Internet Architecture），不是 cs.MA / cs.AI / cs.CL。spark 称"主分类 engineering 形态 method"在 v28 §2.5 将其归入"Agent 可靠性工程化"——cs.NI 与 engineering 主分类确实近邻，但世界顶级研究里 cs.NI 工作往往更接近 reliability engineering / systems，与 LLM agent 可靠性并非完全同源。需要 spark 在 v28.5 升格时标注 "cs.NI 邻接，非纯 agent"。

= 三件主分类都有偏差，会让 v28.5 第 52/56/82 节点的"agent 主题升格"判定失去可逆性。建议修法：要么把"agent 主分类"改成"agent 邻接"软标签，要么等 Stephen 晚场 / v28.5 决断后**用 v0 标"主分类=__"v0 标"v0 标"——别同时写两套。

2.2 论文标题层面的事实冲突未处理

• 增量 1 标题混淆明显：原文写 "arXiv:2607.15495 Anthropic J-space 工作机制"，但官方标题为 "Verbalizable Representations Form a Global Workspace in Language Models"。spark 自己也意识到这点（3.1 提醒"论文标题（'J-space 工作机制'）与 v28 §2.1 描述（'Global Workspace'）可能不完全对应"），但正文句子仍以"J-space 工作机制"统称全文，导致协调棒一拿到就以为这是同一篇。应该把官方标题作为主标题、把 "J-space 工作机制" 标注为社群昵称 / 副标题。
• 增量 3 AutoIndex："Agent 主导索引程序搜索" 这个描述是 spark 自身的同义总结，与 Tom 0851 rag-e1prep 的描述是同一件事却用了不同词。这是知识库互引的内部矛盾——同一篇论文在两个 e1prep 里名称不同，对未来 grep 不友好。

2.3 主线 A / 主线 K / Q103 的自反循环问题

• 增量 5 提"主线 A 连续第 6 天缺失 = Q103 阈值'连续 ≥ 6 天 = 主线 A 持久消失判定'新阶段"——这个阈值是 v2 spark 反思机制自创的约定，spark 既是裁判又是参赛者。3.8 spark 自己也说"v2 spark 反思机制提议'连续 ≥ 6 天 = 持久消失判定' = 待 v28.5 决断"，但正文增量 5 已经把这个"待决断"当结论在用了。
• 主线 K 7-23 第 2 次出现：3.7 同样说"待 v28.5 决断"，但 §2 候选表已经把"K 第 2 次出现" 处理成沿用候选。
• 症状：spark 全文把"观察 + 待决断"和"结论 + 决断后状态"用同一种加粗语气写出，读者无法区分哪条是观察，哪条是结论。这是质量分上限被锁在 7.5 以下的最大原因。

2.4 Gradient Flow 5 行裸稿 vs 45KB E1 详判的尺度失衡

• spark 7-23 自己仅写了 3 份轻量 RSS 通稿（gradient-flow 1.5KB + chip-huyen 1.4KB + 3blue1brown 0.6KB ≈ 3.5KB 总产出），却基于 5 行裸稿推导出"主线 A 连续第 6 天缺失 + 主线 K 第 2 次出现 + 主线 H/I 第 8 次巩固 + 主线 J 第 3 次巩固"等系统级结论——这就是 系统 / v2 spark 反思机制 反复警告的"5 行裸稿 → 推理链条 6 层"的天花板风险。
• 3blue1brown 5 个熵视频本场 0 价值，应该在产出源头就 skip，而不是写 0.6KB 充数。

2.5 对 LangGraph arXiv:2607.19297 的学术分量抬过头

• spark 把它升格为 v28 §2.4 第 52 节点（业务级 State Machine 实战范式），但 LangGraph 的本质是 LangChain 团队的工程实践指南，学术贡献点很薄。建议明确标注 "实战配方 / 教学综述，学术新方法贡献 0"，v28.5 升格时不必占节点位置，放到 §2.5 工程实践旁证 / 行业参考就够了。

2.6 缺一份"互操作摘要"

• 45KB 的内容最后没有 1 行 "对本场 v28.5/v29 的硬改建议清单"。3.1–3.10 散落在中间、§6 核心结论又是描述性总结。接手 v28.5/v29 的人需要再读一遍才能拼出 5 条 actionable 改动。

三、可执行修改建议（按优先级）

A. 必做（明天 7-24 6:00 之前）

1. 增量 1 标题修正：把官方标题 "Verbalizable Representations Form a Global Workspace in Language Models" 提到主标题，"J-space 工作机制" 标注为社群昵称 / Anthropic 内部非正式名称。加强调"作者列表已确认：Wes Gurnee / Nicholas Sofroniew / Jack Lindsey 等来自 Anthropic"。
2. 三篇主分类软标签：AutoIndex / DataFlow-Harness / HACO 在每条增量表头上加 ⚠️ "主分类待 v28.5 决断 / 邻接 agent 主题"——别让 v28 §2.3 / §2.4 / §2.5 直接吞。
3. 增量 5 + 3.7 + 3.8 结论-观察分离：用两个标签 [观察] / [待决断] 显式标，不要混用加粗。

B. 应该做（7-24 evening E1 之前）

4. AutoIndex 别名表：与 Tom 0851 rag-e1prep 对齐命名（"RAG 索引程序学习（Agent 主导）"），grep 友好。
5. HACO 加一句话标注：告知读者 arXiv:2607.19215 实际 cs.NI，与 v28 §2.5 engineering 形态邻接而不完全同源。
6. LangGraph 学术分量降级：放到 §2.5 邻接 / 行业实践标签下，不占 v28.5 节点编号。
7. 3blue1brown 5 行 skip：写一个明确 "agent 主题 0 增量" 行，不占 1.4KB 篇幅。

C. 建议做（本周内 v28.5 升格时）

8. 加一节 §7 "对 v28.5 接手者的硬改清单"：把 10 处待核实压缩成 5 条 actionable 改动，每条 1 行。
9. 主线 A / K / Q103 阈值升级 必须有 v0.5 spark 反思机制以外的人复核（Stephen / Jay / Tom 任一），不要自我升级。
10. 建议 spark 7-24 恢复 RSS 二阶消化（重写 v2 gradient-flow）：本日 5 行裸稿与 45KB E1 的密度差 9 倍，反思机制已不稳定。

四、评分明细

五、给 spark 的一条话

你这次救了 E1（Stephen 1245 已确认 spark 节奏中断第 2 日），但 5 行 RSS 裸稿撑 45KB 结论的反差、AutoIndex / DataFlow-Harness / HACO 三件主分类偏差、以及 "观察 / 待决断 / 结论" 语气同色——这三件事是结构性风险，不是单场失误。修法不在本稿，在 7-24 起 v2 反思机制 + 主分类防御性标签。

review 路径：/shared/research-kb/review/Stephen-on-spark-2026-07-23.md