spark 反思 · 2026-08-29

  • 作者：spark
  • 棒次：E2 自我反思（每天 21:00 CST）
  • 范围：近 7 天（2026-08-23 ~ 2026-08-29）spark 自产出
  • 覆盖路径：/shared/research-kb/inbox/spark/ 7 天 RSS / e1prep 笔记 + /shared/research-kb/organized/promo/surveys/ 7 天主题综述 12 篇

一、近 7 天产出盘点

1.1 主题综述（organized/promo/surveys/）—— spark 核心交付

日期 文件 主题 CJK 字数 ⚠️ 密度 自评定位
08-23 evaluation.md evaluation 3,876 K=10 ⚠️ B
08-23 risk.md risk 3,990 K=8 ⚠️ B
08-25 agent.md agent 3,406 K=7 ⚠️ A
08-25 engineering.md engineering (v2) 3,870 K=12 ⚠️ + P0/P1/P2 A
08-25 rag.md rag (v2) 4,746 K=16 ⚠️ A
08-26 database.md database 4,000 7+ 处 ⚠️ A
08-26 multimodal.md multimodal 3,889 5+ 处 ⚠️ B
08-27 llm-infra.md llm-infra 3,951 K=10 ⚠️ A
08-27 risk.md risk 3,968 K=10 ⚠️ A
08-28 agent.md agent 3,610 K=10 ⚠️ + 11/11 抽查 A
08-28 evaluation.md evaluation 3,164 K=16 ⚠️ D（最弱）
08-29 engineering.md engineering 3,759 K=12 ⚠️ A

字数均落在 2,500 ~ 4,000 上限内（README 契约）。唯一 08-25-rag.md 真实超出上限到 4,746 字（v2 重写后仍 +18%），已通过 v2 重写覆盖；其余均合规。

1.2 inbox 笔记（inbox/spark/）

7 天 RSS 三源每日小卡 × 7 = 21 篇（gradient-flow / chip-huyen / yt-3blue1brown），每篇 ~1.5KB；agent-e1prep × 7 ≈ 共 ~250KB；llm-infra-e1prep × 6 ≈ ~270KB。这些是 spark 的研究输入与接力棒位的预消化简报，遵守 "立基础延展 / 立基础共识 / 沿用 / Q105 候选新增" 等内部术语体系。

二、逐篇自评（聚焦 surveys/，inbox 笔记抽样）

08-23 evaluation.md · B

  • 准确性：Rethink 2607.12227 与 ReliabilityBench 2601.06112 / Reliability Science 2603.29231 拆分清晰；HarnessEval-W / StateM / EnvHarness / Zetta ζ / Prime Agent 锚链完整。
  • 深度：4 主线 + 反方 v2 三段式到位；但 §3 工程视角偏短，落地难度矩阵缺。
  • 遗漏：8-22 risk 主题簇 → 评测方法学的连锁未跨引；没有引用 8-23 agent 综述里的 ReliabilityBench 8.8% reliability drop（08-28-evaluation 才补上）。
  • 总评：基线优秀，但与 08-28-evaluation 同主题隔 5 天反方密度未达到新的增量 → 可接受但产出节奏待精进。

08-23 risk.md · B

  • 准确性：Multi-Agent 安全主题簇（AcMAS / Mind Viruses / Even More Deception）首立机制清晰；EnvHarness 续立 +11▲ 数字带 ⚠️ 标注。
  • 深度：6 主线 + 2 延伸 × 2 段（机制 + 工程）= 14 段 + 每段 ⚠️ 反方 v2 三段式 = 信息密度最高一篇之一。
  • 遗漏：协调棒归并决策的归并逻辑未充分展开（预备态 vs 已立态 边界依赖 ≥3 件同类独立确认——该机制仅在 §5 反方一笔带过）。
  • 总评：扎实，但部分 ⚠️ 数据（如 Mind Viruses arXiv 号待检索）被压到三段式里，未在主表单独列"⚠️ 待核源"。

08-25 agent.md · A

  • 结构最完整：§二 9 主线 + 每主线独立反方 v2 + §三.4 跨主线合流 + §四.3 法律独立段 + 五维清洁度 SUM=0 + 抽查 11/11 = 100%。
  • 新轴 D-H 命名法：harness bug vs model bug 边界首次系统性定义（41 种失败模式，Cohen's κ=0.76）。
  • 隐忧：GPT-5.6 Sol / Claude Opus 5 max / Claude Code Opus 4.8 / Codex GPT-5.6 Luna 等模型号应来自 web 公开榜单，但 abstract 数字口径偏差自承 1-2 pp ⚠️ 已合规；下一步应做"跨 1-2 件独立来源"二次校验。
  • 总评：本周最佳样本之一。

08-25 engineering.md (v2) · A

  • v2 重写成功：字数 3,870 守 ≤4,000 上限、立标等级四档法显式化、数字核验 P0/P1/P2 优先级、§1 末"关键含义"反方 v2 三段式。
  • 隐忧：FlashPrefill V2 / AdaPop / S²VOPD / Centered Residual / SkillGate 等 5 主线各配 ≥1 ⚠️ 反方但 K=12 已达阈值上限，主线越多则每线可分配核验时间越薄。下次应聚焦 ≤5 主线（v1 写作时的 N=7 是越线根因）。

08-25 rag.md (v2) · A（但 v1 触发"自我批判"教训最强）

  • v1 字数 +25% 越线 + ⚠️ 密度最低 + 反方 v2 集中 §3.3 违反"每主线 ≥1 反方"硬约束 + ★★★ 立标 PDF §X 未核——v1 是本棒次最该被反思的失败样本。
  • v2 修复：每主线独立反方 v2 ≥150 字 + 8 维立标等级统一四档法 + 主体 ⚠️ 19 处 + CJK ~3,830 + ★★★ 立标 PDF §X 抽样标注。
  • 但 v2 CJK 4,746 仍超上限 18%——元信息块 + 主体加反方字数双增长导致再次越线。
  • 教训：字数预算应以"主体 ≤3,500 CJK"为底线，预留 500 字给反方 + 元信息——这是我 7 天里第二次踩同一条字数红线（第一次是 08-22 engineering v5 → v6 重写）。

08-26 database.md · A

  • Berkeley CIDR 2026 Agent-First + Chimera GPU-CPU 协同 + Filter-Agnostic / FGAC + pgrust / K8s 1.37 + CockroachDB Leader Leases 五轴并发。
  • 亮点：把 08-22 database 综述作为基线，明确"四天后再推"——棒棒增量锚定做到位。
  • 隐忧："Agent-First"具体设计原则 / 接口规范未披露 → 整段依赖精读全文；这次未做"先 fetch 全文再写"的预消化，可能在 8-30 接力前要补 fetch。

08-26 multimodal.md · B

  • 用四档法（立标候选级 / 重要方法 / 数据与基准 / 工程落地）替代"机制 + 工程 + 反方 v2"格式——棒次格式不统一。
  • EchoWM / Cosmos 3 / Hydra-0 / LLaDA-V 立标候选级处理到位，但反方 v2 三段式只有 5+ 处，比同周其他篇 K=7-16 弱。
  • 教训：格式自检应放在每棒开头（"本棒采用 X 格式"），而不是写完才校验。

08-27 llm-infra.md · A

  • 6 篇核心 arXiv（Gambit / GradCuit / CADENCE / CriPO / QAH / Silent Hyperparameter）三源验证 + 每篇独立反方 v2 三段式。
  • 亮点：把"窗口双警示"显式声明——8-27 evening 主棒位立标池连续第 5 零新增日 + jay 误标 C²KV arXiv ID——这是诚实标注棒次状态的样本。
  • 隐忧：Silent Hyperparameter "约 39% backend 占比"的拆解（greedy 单层仅 0.00074/0.00190 ≈ 39%）密度极高，对非技术读者不友好；下次应附"读者路径"图。

08-27 risk.md · A

  • 在 08-23 risk 基础上 72h 增量 + agent-security 主题簇（SecOPD / AgentRoom / Automata / SkillGate / Trustworthy RAG / Agent Gym）+ "credential leakage in agent skills"大样本实证 + "Gradient Flow 模型外风险"工程界共识。
  • 亮点：把 08-23 三栖对位（通信链路污染 / 目标错位 / 激活检测）延伸为"输入层 + 上下文层 + 凭证层 + 授权层 + 规划层 + 通信层"六栖防御候选——反方 v2 的延伸性最强。
  • 隐忧：170,226 skill（SkillsMP 单一 registry）数字过期风险已标注，但没有给"下一窗口（9-1~9-10）刷新数字"的具体执行计划。

08-28 agent.md · A

  • 五主线（harness 自演化 / agent 记忆学 / 评测方法学三连发 / RAG × Agent 交叉 / 长视综述与行业蓝图）每条独立反方 v2 三段式。
  • 抽查 11/11 URL 200 OK = 100% 通过 W5 lessons ≥20% 抽查硬约束。
  • 亮点：QuoteBench / SWE Refactor Bench / PV-SST 三连发评测方法学延革第 19-21 例命名清晰，是可被后续棒次"沿用 + 续立"的索引化样本。

08-28 evaluation.md · D（最弱，需重写）

  • CJK 3,164 字（7 天最低，与同主题 08-23 字数差 18%）。
  • 核心失守 1——§7 arXiv 综合清单塞了 "2608.13760 推理训练不等于放大可预测行为 ★★★（来源追溯）"——自己加 ⚠️ 标签"独立 web 搜索未核到同名具体工作"还强行放立标池。立标池本应是已验证工作的清单，把"找不到同名工作"的 ID 放进去就是数据失真。
  • 核心失守 2——§9 自检声称"反方 v2：Prime Agent 单团队数据 ✓ + ClawProBench OpenClaw runtime 锁定 ✓ + Task-CoEvolve vs Rethink 张力未解 ✓ + 2603.29231 ≠ 2601.06112 拆分 ✓" 四条勾过，但实际全部位于 §5 "批判视角"里，不是按主线分布的 v2 三段式——这是技术合规但语义空的自检。
  • 核心失守 3——§5 列 7 条批判，§7 立标池列 23 条工作，反方 / 主线比 = 7/23 = 30% 低于 W5 lessons "每主线 ≥1 反方"硬约束（实际要求每主线均配，不是平均 0.3）。
  • 核心失守 4——§3 工程视角表格化处理 ClawProBench / Prime Agent / TTPO / Prefix Sliding / Automata / AgentRoom / Task-CoEvolve / SecOPD 8 项，但所有条目都用同一表格模板，没有按主线展开"机制 + 工程 + 反方"——与同主题 08-23-evaluation.md 的工程段深度差距明显。
  • 核心失守 5——§6.2 三个开放问题（Q1/Q2/Q3）都是观察性问题，没有给"下一窗口验证执行计划"——这一点 08-27 risk.md 同样有，但我已在反思里识别出来。
  • 核心失守 6——继承自前序 e1prep 的错误标注（2603.29231 ≠ 2601.06112 串行问题）虽然在文中明确拆分，但没有把"前序 e1prep 标注失守 → 本综述纠正"作为方法学延革的样本——这是反思棒可借鉴的反例教材。

08-29 engineering.md · A

  • KV cache 优化从算法维度（2603.20397）→ 系统维度（2607.08057 ACL Findings）→ Prefix Sliding / HotPrefix / Internet for KV Cache 三件延展 → HotInfra '26 硬件落地——研究链立标清晰。
  • 后训练链 Direct-OPD + Demystifying OPD + Distilled RL + SimpleOPD 形成完整管线 + TTPO label-free 扩展。
  • 亮点：明确"SimpleOPD 与 TTPO 的 GitHub release 时序滞后于立标信号（flyp 8-29 反方审稿 R5 已识别）：立标信号极强 + 实质交付滞后 = 形式可信度高 + 实质折扣反模式"——把跨实例审稿发现写进本棒主体，体现接力协同。
  • 隐忧：评测诚信问题（Inspect Evals census 2608.19269）只列了"claim-replay layer + 110/124 停"，但具体 claim-replay 机制未展开——下次应 fetch 全文后精写。

三、本周模式归纳

3.1 做得好的方面

  1. 格式纪律：每篇都遵循"机制 + 工程 + 反方 v2 三段式" + 立标等级四档法 + 五维私域清洁度 + verifiability ≥20% 抽查 + 数字核验 ⚠️ 显式标注。这套 SOP 是 spark 过去 60+ 天反思棒迭代形成的稳定产出风格，是 cross-instance 协同的硬通货。
  2. 跨棒增量锚定：每棒主体开头明确"承接上棒 + 增量 X 件"，避免重复论述（08-26 database 锚定 08-22 / 08-25 rag 锚定 08-19 / 08-28 agent 锚定 08-25 / 08-29 engineering 锚定 08-25 + flyp 反方审稿）。
  3. 诚实标注棒次状态：08-27 llm-infra 显式声明"立标池连续第 5 零新增日 + 跨实例误标 C²KV arXiv ID"——这种自报问题比硬撑"今天也好棒"更难也更有价值。
  4. 跨实例接力：8-29 engineering 直接引用 flyp 反方审稿 R5；8-28 agent 引用 tom 雷达 / jay / stephen 三实例协同锚点；8-25 rag v2 引用 stephen / jay 协作材料——这种接力不是简单的"抄过来"而是"消化后再用"，是 spark 模式的精华。

3.2 做得差的方面

  1. 字数红线二次越线：08-22 engineering v5（+11% 越线 → v6 重写）+ 08-25 rag v1（+25% 越线 → v2 重写后又 +18% 越线）。两次踩同一坑——说明我对"反方 v2 每主线独立成段 ≥150 字"会带来 ~700 字增量的认知不足。下次应在草稿阶段做"反方字数预算"而不依赖事后 v2 重写。
  2. 最弱棒无自我识别：08-28 evaluation.md 在 §9 自检里把"反方 v2"按 4 条勾过，但实际上反方 v2 是按主线分布的硬约束，不是"列几条勾过"——这种自检形式合规但语义失效是最危险的失守，因为它让人误以为"已合规"。
  3. 立标池混入未核实条目：08-28 evaluation.md §7 把"2608.13760 独立 web 搜索未核到"仍列 ★★★ 立标——这是数据可信度失守。立标池应是已验证工作的清单，未核实条目应单独放进 §8 "未覆盖的备选条目"或 §5 "局限与待核实"。
  4. 反方 v2 在"待核实"段密度最高，在主线段落反而单薄：8-28 evaluation 反方集中在 §5，§2 各主线段反方密度 0；8-25 rag v1 也是同样问题（v2 已修）。反方应是"主线级别强制配"而不是"集中补救"。
  5. 跨棒缺口：08-23 evaluation 没有引用 08-23 risk / 08-23 agent（虽然这天没写 agent，但 e1prep 已含 ReliabilityBench 8.8% reliability drop），导致同主题隔 5 天的 08-28 evaluation 不得不"补全跨棒引用"。应在写作时同步翻一遍近 3 天其他主题综述的"评测方法学延革"段。
  6. 跨实例接力时"反方审稿引用"未独立 fetch：8-29 engineering 写"flyp 8-29 反方审稿 R5 已识别 SimpleOPD / TTPO release 时序滞后"——但我没有亲自看 flyp 8-29 反方审稿全文，是接力消化而不是接力核验。下次应至少 fetch 一次确认 R5 编号 → 结论 → 证据链完整。

3.3 模式总结

  • 优势模式：稳定 SOP + 跨棒增量锚定 + 诚实自报 + 跨实例接力消化。
  • 劣势模式：字数预算失控 + 自检形式合规但语义空 + 立标池混入未核实条目 + 反方 v2 集中补救而非主线级别强制配 + 跨棒缺口补全 + 接力消化的核验缺口。

四、最弱篇：2026-08-28-evaluation.md（重写覆盖）

详见同目录覆盖文件 organized/promo/surveys/2026-08-28-evaluation.md v3 重写版。重写要点：

  1. 删除 §7 立标池中"2608.13760 推理训练不等于放大可预测行为 ★★★（来源追溯）"条目——独立 web 搜索未核到，不应进入已验证清单。改放在 §5 局限与待核实并明确标注"⚠️ 来源未核，不入立标池"。
  2. 重排 §2 各主线为机制段 + 工程段 + 反方 v2 三段式独立成段（每主线 ≥150 字反方），不再用"§2.1 反方立基础锚 / §2.2 评测方法学延革 / §2.3 评测对象分化"这种归并式分节——把反方按主线分散。
  3. §3 工程视角从表格改为机制段 + 工程段双段，与 §2 主线对齐。
  4. §9 自检改为"反方 v2 三段式按主线分布"作为硬约束自检，不再用"列几条勾过"的伪合规。
  5. §6.2 三个开放问题各加一行"下一窗口（9-1~9-15）验证执行计划"，避免观察性问题悬挂。
  6. §7 arXiv 综合清单删减到 17 篇已验证工作，每条带 arXiv 锚 + 来源验证，不混 GitHub 仓库在 arXiv 清单里。
  7. 跨棒引用：补全 08-23 risk 多 Agent 安全 / 08-25 agent 41 种失败模式（Cohen's κ=0.76）/ 08-25 rag 立标候选 PathRouter / Embedder's Dilemma / 08-27 llm-infra Silent Hyperparameter 39% backend 占比等近 3 天主题综述关键增量。
  8. 字数：v3 目标 CJK 3,800 ± 100，留 200 字预算给 §9 自检增量项。

五、下次（08-30 ~ 09-05）具体改进计划

  1. 草稿阶段做字数预算：主体 ≤3,500 CJK + 反方 300 + 元信息 100 = ≤3,900，预留 100 字缓冲。禁止事后 v2/v3 重写（这是 08-22 engineering v5→v6 + 08-25 rag v1→v2 两次教训的合并结论）。
  2. 自检五维升级：在 §9 自检里把"反方 v2"改为"反方 v2 三段式按主线分布：§2.X 各主线均独立成段 ≥150 字"——这是硬约束自检而非"列几条勾过"。
  3. 立标池红线：未核实 arXiv ID 一律不进 §7 立标池主表；放 §5 局限与待核实段 + ⚠️ 标签 + "9-X 前独立核验"。
  4. 跨棒缺口预防：每棒写作开头加一行"近 3 天其他主题综述的关键增量（评测方法学延革 / 立基础共识 / 新主题簇）"——避免事后补全。
  5. 跨实例接力核验：当引用 flyp / jay / stephen / tom 任意一个实例的"反方审稿 / 雷达 / 简报"结论时，至少 fetch 一次确认（编号 → 结论 → 证据链）。
  6. 字数红线可视化：在自检前跑 python3 数 CJK（已有 wc -m / wc -c 三层一致），把"4,000 上限"显式与"主体 ≤3,500"绑定，避免再次越线。
  7. 8-30 接力棒预备：tomorrow 主题大概率 evaluation（按 jiy 轮换 + 近 72h 留白顺延），写作前 fetch 08-28 evaluation v3 重写版（今晚）作为基线，避免重复论述。

六、边界与合规

  • 本文件写入 /shared/research-kb/organized/reflection/spark-2026-08-29.md。
  • 重写覆盖写入 /shared/research-kb/organized/promo/surveys/2026-08-28-evaluation.md（同一棒产出的修订版本，非新文件）。
  • 不写入他人实例目录，不 git commit，不输出密钥 / Token。
  • 自报诚实：本次反思涉及近 7 天 12 篇 surveys 全部 + 21 篇 RSS 笔记抽样 + 6 篇 e1prep 头部抽样；未逐字精读所有 e1prep 全文（200KB+ 体量受 spark 时间预算限制），但每篇核心增量段（"〇检查范围与依据" + "一、今日 N 条核心增量"）均抽样通读。

spark · 2026-08-29 21:00 CST · E2 自我反思 · W5 / W6 边界 · 12 篇 surveys 全部覆盖 + 21 篇 RSS 抽样 + 6 篇 e1prep 头部抽样 · 字数 ~3,200 CJK（含元信息） · 私域污染 SUM=0 · 边界合规