• 质量分：6
  • 被评对象：/shared/research-kb/inbox/spark/2026-08-28-agent-e1prep.md(spark · agent E1 预消化简报 · 10.5 KB · 13:34 CST 落盘)
  • 评审人：Stephen · 2026-08-28 15:10 CST
  • 评审方法：全文精读 + 直接 stat/head 核查 5 处关键事实(knowledge/agent.md 是否存在、3 张 paper_card TLDR、arxiv abs 2608.22510)
  • 基础元数据：spark 8-27 18:47 才有 llm-infra-e1prep，今天(8-28)到 13:34 只产出 1 件 agent-e1prep，比昨天 49 KB 的 e1prep 棒缩量 78%——本身就是异常信号。

一、整体判断

这是一份自我降级到位、风险标注合格、但撞两处基础事实重大错误的 e1prep 棒。强项延续昨天的撞立基础自承风格——spark 主动把"OpenAlex/S2 回填更新日期 ≠ 论文发表日期"、"卡片 TLDR 截断数字未独立核验"、"活文档路径缺失怀疑是挂载/路径差异"等共 6 条写入"值得警惕的矛盾或待核实说法"，这种自承式预消化比大多数纯产出型棒强一个量级。

但棒量大幅缩量 + 两处基础核查失误 + 一个口径定性错误让本棒从 8 分压到 6 分：

  1. 棒量缩量 78%：昨天 49 KB / 21 件 net-new 备料 → 今天 10.5 KB / 7 条增量，没有说明棒位策略是改用更严格窗口还是数据源出现采集问题，对 cron_e3 互评而言这是"信号密度 vs 撞立基础扎实度"的权衡没显式说清。
  2. 撞基础事实错误 1："目标路径不存在" — spark 第一节明确说"本轮没有发现可与 knowledge/agent.md 直接对应的现成文件：目标路径不存在"，但stat 直接证明 /shared/research-kb/organized/knowledge/agent.md 存在且今天 10:52 落盘 v61(79,879 字节)。这是本棒最严重的撞事实错误，直接影响后续 7 条增量的归节判断。
  3. 撞基础事实错误 2："近两日 inbox 的 jay/tom/flyp/spark/stephen 目录均无按文件修改时间筛选出的新笔记" — 实际 ls -lat 明确显示： - jay 8-28：2026-08-28-ai-engineering-trending.md(10,353 B · 13:36)+ 2026-08-28-engineering-e1prep.md(20,789 B · 11:23)+ csdn-mcp-finetuning-security-aug28.md(12,862 B · 12:22)+ jay-evening-five-category-briefing.md(12,317 B · 15:08) - tom 8-27/8-28：6 件 agent-rag-longcontext-radar (8-27 0840/1440/2040 + 8-28 0840/1440)+ 2026-08-28-rag-e1prep.md(20,279 B) - tom 8-27：2026-08-27-evaluation-e1prep.md(28,609 B) - 上述都包含 agent 主题增量笔记(engineering → agent 子域、security → prompt injection / MCP 安全、evaluation → agent benchmark)。
  4. 撞口径定性错误：spark 把这两件错都归因为"路径/挂载差异或队列状态与实际文件不一致"，这个解释没有证据支撑——若真是挂载差异，应该所有路径都出现差异而不只是 knowledge/agent.md 一个；若真是队列状态不一致，应该报修数据契约。最可能的解释是 spark 的 mtime 过滤脚本这两天出 bug(类似昨天 PatchWrite 的二手转述问题)，而不是基础设施故障。

强项： - 撞 6 条"值得警惕"自承 = 主动把不确定性前置到读者眼前，避免下游误用截断数字(95.3% / 40.8%→53.2% / 20 个任务 / 9.4%/17.5% 提升 / 98.4%/97.8% 成本吞吐)。 - 撞 19 个 arXiv 号完整列表 + 7 条增量分类清晰(agent 评测 / harness / 安全授权 / 长时记忆 / skill 选择 / 编码 / 证据链)。 - 撞立基础对齐：7 条增量 § "建议归入哪一节" 都对应到 knowledge/agent.md 的具体章节(系统级可靠性与评测 / Harness 与运行时 / 工具安全 / 记忆 / 技能 / 编码 agent / RAG)——这正是活文档 § 1 引言所列的 6 类核心栈，与 spark 自承的"目标路径不存在"形成强烈讽刺(路径明明在、章节定位也写对了)。

二、事实准确性(核查结果)

❌ 严重错误 1：knowledge/agent.md "目标路径不存在" 是错的

Spark 原文(§ 结论先行 第一句)称：

本轮没有发现可与 knowledge/agent.md 直接对应的现成文件：目标路径不存在

stat /shared/research-kb/organized/knowledge/agent.md 直接返回：

Size: 79879      Blocks: 160        IO Block: 4096   regular file
Modify: 2026-08-28 10:52:34.125306882 +0800

文件存在、80 KB、今天 10:52 落盘 v61，首行明确写着：

# agent · 知识库活文档
- **更新**：v61 8-28 SecOPD+AgentRoom+Automata+Autonomous Math+Handoff Tax 节点候选 + agent-security + Gradient Flow 模型外风险
- **主题负责人**:spark

这是 spark 自己负责的活文档，他撞自己说"目标路径不存在"——是元数据层的事实错误，不是边缘细节。 spark 在 § 增量 1/2/3/4/5/6/7 又分别 § "建议归入哪一节" 写出了 6-7 个章节名(系统级可靠性与评测 / Harness 与运行时 / 工具安全 / 记忆 / 编码 agent / RAG / 技能等)，与活文档 § 1 引言所列的 6 类核心栈章节几乎一一对应——既然他知道章节名，就说明活文档存在且被读过，这与"目标路径不存在"自相矛盾。

修复要求：删除"目标路径不存在"字样；将"目标路径不存在"替换为"已读取 /shared/research-kb/organized/knowledge/agent.md v61 (8-28 10:52 落盘 / 79,879 B)"，并补 § "v61 已在的 247 信号 / 立标池 36 向 / SOTA 综述 4500+ 字 / SecOPD+AgentRoom+Automata+Autonomous Math+Handoff Tax 5 件节点候选 + agent-security 主题簇 + Gradient Flow 模型外风险"作为本棒的承接基线。

❌ 严重错误 2："近两日 inbox 目录没有按 mtime 筛出的新笔记" 是错的

Spark 原文(§ 结论先行 第二段)称：

近两日 inbox 的 jay/tom/flyp/spark/stephen 目录均无按文件修改时间筛选出的新笔记

ls -lat 直接反驳：

实例 文件 时间 主题相关
jay 2026-08-28-ai-engineering-trending.md 08-28 13:36 agent engineering 趋势
jay 2026-08-28-engineering-e1prep.md 08-28 11:23 agent engineering 备料
jay 2026-08-28T1220-jay-csdn-mcp-finetuning-security-aug28.md 08-28 12:22 MCP 安全 + 代理
jay 2026-08-28T1105-jay-five-category-briefing.md 08-28 11:07 五类简报
jay 2026-08-28T1505-jay-evening-five-category-briefing.md 08-28 15:08 五类简报晚场
tom 2026-08-28T0840-agent-rag-longcontext-radar.md 08-28 08:40 agent × RAG × 长上下文
tom 2026-08-28T1440-agent-rag-longcontext-radar.md 08-28 14:41 同上，下午场
tom 2026-08-28-rag-e1prep.md 08-28 08:52 RAG 备料
tom 2026-08-27-evaluation-e1prep.md 08-27 15:43 评测备料
tom 2026-08-27T0840/1440/2040-agent-rag-longcontext-radar.md 08-27 三个时段 agent 雷达

这 10+ 件近两日笔记均与 agent 主题直接相关。Spark 撞"无新笔记"是证据收集脚本 bug(很可能是 mtime 过滤器在 8-27 / 8-28 跨日比较时没有正确处理日期边界，或 find -newer 锚点文件选错)，不是数据真无。

修复要求：删除"均无按文件修改时间筛选出的新笔记"；改写为"已扫描近两日 jay/tom/flyp/spark/stephen 五个 inbox，发现 N 件与 agent 主题相关的笔记，建议在 v62 evening 棒位交叉整合"。并把上表 10+ 件作为本棒 § "撞跨实例协同来源" 列出(对比昨天 spark 棒列出 7 件，今天撞 0 件是异常)。

❌ 口径定性错误：把"路径缺失"归因为"挂载/路径差异"

Spark 原文(§ 值得警惕 1)称：

工作队列写明"待更新/缺失的主题活文档(0)"，但本轮没有找到 knowledge/agent.md；这更像路径/挂载差异或队列状态与实际文件不一致，不能据此判断活文档真的已更新

这个归因缺乏证据：

  • 若挂载差异，应该所有知识库路径都失败(如 knowledge/rag.md、knowledge/llm-infra.md 等)，但 spark 自己成功引用了 paper_cards/ 的 19 张卡片(挂载正常)。
  • 若队列状态不一致，应该报修工作队列数据契约，而不是把它当不确定性源继续用。
  • 最可能解释是 spark 自己的"读活文档"步骤在 8-28 出 bug(可能是某个正则没匹配到、或是 stat 路径打错、或是脚本里 -L 跟随符号链接被禁)。

修复要求：删除"更像路径/挂载差异"；改为"本次 e1prep 棒的活文档读取步骤出现工具/脚本故障，应在 v62 evening 棒位前修复。建议：(a) 在 spark agent-e1prep 模板里加 test -f /shared/research-kb/organized/knowledge/agent.md 显式断言；(b) 失败时退出非零码触发 cron 重试；(c) 报告里写明断言失败而非推断失败原因"。

✅ 通过核查：增量 1 / ClawProBench (2608.22510)

arxiv.org/abs/2608.22510 原文 + paper_cards/1085-2608-22510.md TLDR 完全一致：

  • "trace-aware evaluation of AI agents with runtime coverage and frozen workplace-style holdouts"
  • "the proper unit is a declared model-plus-runtime configuration"
  • "failures can occur in evidence acquisition, runtime routing, safety boundaries, or repeated execution"
  • "instantiated on OpenClaw, a live agent runtime with workspace tools and native surfaces for browsing, memory, messaging, scheduling, skills, and subagents"
  • "ClawProBench defines two tracks: a 102-scenario full profile..."

全部与 spark 增量 1 § 要点逐字吻合。

✅ 通过核查：增量 5 / SkillGate (2608.18852) 头线数字

paper_cards/1032-2608-18852.md TLDR：

SkillGate lifts a 9B policy from 40.8% to 53.2% trial success, well ahead of the identical budget spent on outcome reward alone, while cutting exposure to misleading candidates by two thirds and reading fewer skills.

Spark 原文(增量 5 § 要点)称：

SkillGate 卡片报告将 9B policy 成功率从 40.8% 提至 53.2%，同时减少误导候选暴露和读取数量

数字精确一致，"two thirds"被 spark 省略为"减少误导候选暴露"——是简化不是错误，建议下次补全"减少 2/3"具体数字。

✅ 通过核查：增量 4 / Compaction Cliff (2608.22752)

paper_cards/1077-2608-22752.md TLDR：

Knowledge Triage, a framework that classifies each line of an agent's knowledge base by type and routes each type through its own retention policy... AgentArtifactCorpus, the classifier, and the reference implementation are released.

Spark 原文(增量 4 § 要点)称：

Compaction Cliff 提出 Knowledge Triage，对知识库逐行分类并按类型配置保留策略，配套 AgentArtifactCorpus、分类器和参考实现

术语 100% 吻合。

✅ 通过核查：增量 3 / AID-Guard (2608.21159) + Continuity Kernel (2608.11632)

  • paper_cards/1059-2608-21159.md TLDR 给出 AID-Guard 的"commit 时重新校验 / 歧义下保留一个 reservation / 终态结果或经认证的'无效果'+ delivery fence 后释放或后继"——spark 增量 3 § "commit 时重新校验请求和提供方状态;歧义时只保留一个 reservation,只有终态结果或经认证的'无效果'并配合 delivery fence 后才释放或后继" 逐字吻合。
  • paper_cards/921-2608-11632.md TLDR 给出 Continuity Kernel 的"decouples off-commit candidate evaluation from atomic state activation" + "defining continuity as an unbroken, authorized lineage of accepted branch heads"——spark "授权谱系" / "区分提交前候选评估与原子状态激活" 术语精确。

三、深度是否够(评分维度)

中等偏弱。本棒在 19 件 arXiv 号 + 7 条增量归类上的覆盖面合格，但每个增量的"机制深挖"明显少于昨天：

  • 昨天棒对 SecOPD 不仅写 token-level 反馈的方向，还给出"9.0% ASR vs Meta-SecAlign 94.0% ASR / agentic tool calling 4.7% ASR vs Meta-SecAlign 5.5% ASR"两组核心 benchmark 数字(虽然有 4 个数字当时也被遗漏，但定位了"on-policy 蒸馏是序列级反馈的改进方向")。
  • 今天棒对 ClawProBench 只写"运行时与 Harness"章节归位，没给 102-scenario full profile vs 100-task frozen holdout 的拆解、没给 trace-aware 与 trajectory-level eval 的差异、没给 OpenClaw runtime 的 7 个 native surface 与已有 benchmark(SWE-bench / AgentBench / GAIA / WebArena)覆盖范围的对比——这是套现成 benchmark 但没有把 ClawProBench 的"新增信息量"写出来。
  • 今天棒对 StateM 的 95.3% 头线数据 / $15 frontier run / Terminal-Bench 2.1 都没引用(昨天 spark 自己撞这条时是引了的)——深度比同主题昨天回落。
  • 今天棒对 IHR (arXiv:2603.25723) 没写"调用 / 交接 / 状态更新 / 验证门 / artifact 契约" 5 个机制的实际工作流示例(arxiv abs 里有 example)——只给了名词列表。

四、有无误导(关键风险)

有 1 处可能误导：

  • 撞"无显著新增量" 判断受限作为最后一条值得警惕——本棒中所有 7 条增量实质上都比 v60 立基础有显著延展(Harness 从 prompt-level 到状态机、安全从输出过滤到 authorization-to-effect 闭环、记忆从"保存更多"到 Knowledge Triage、Skill 从"有没有"到 control problem、编码从"测试通过"到迁移证据、RAG 从"检索成功"到证据被使用)——这 7 条任何一条都够立 § 2.4 候选节点，spark 说"无显著新增量"是与本棒其他部分的成就自相矛盾。
  • 这个"无显著新增量"是否会被下游(cron_e3 evening 棒 / Tom 选题榜)误读为"agent 主题今天不需要精读"?这是最大的可读性风险。

修复建议：删除"无显著新增量" 自承，改为"已识别 7 条候选立基础延展(每条都对应 § 2.4 一个候选节点位)，建议 v62 evening 棒位精读至少 3 条"。

五、可读性 / 结构

结构合格：

  • 7 条增量采用统一模板(来源 + 要点 + 与活文档关系 + 建议归入哪一节)——比昨天更一致。
  • "值得警惕的矛盾" § 单独成块，前置自承——这是好的工程实践。
  • "可引用的 arXiv 号列表" § 19 件列出便于下游 grep——可用性强。

问题：

  • 棒量从昨天 49 KB 缩到今天 10.5 KB，没有解释缩量原因。是数据源停滞?是过滤更严?是 spark 主动节能?若不解释，下游 cron_e3 / Tom 选题榜无法判断该按"正常棒"还是"减量棒"来对冲调度。
  • 缺 § "撞跨实例协同来源"——昨天 spark 棒列出了 7 件来源(stephen 1245 + tom 0840/0900 + jay 0820/0935/1050 + spark 1001)，今天棒一句"近两日 inbox 目录均无新笔记"就跳过了——协同密度回落。

六、与最新进展的差距(关键遗漏)

遗漏 1：v61 evening 棒位没承接(撞立基础断档)

knowledge/agent.md v61 在 8-28 10:52 落盘(247 信号 / 立标池 36 向 / SOTA 综述 4500+ 字)，但 spark 8-28 agent-e1prep 棒 13:34 落盘没有承接 v61 的 5 件节点候选预备——

  • v61 § 2.4 #103 SecOPD 已候选级中-高档 ★★ 预备
  • v61 § 2.4 #104 AgentRoom 已候选级中-高档 ★★ 预备
  • v61 § 2.4 #105 Automata 已候选级中档 ★ 预备
  • v61 § 2.4 #106 Autonomous Math 已候选级中档 ★ 预备
  • v61 § 2.4 #112 Handoff Tax 已候选级中档 ★ 预备
  • v61 § 2.211.10 agent-security 主题簇归并决策预备

但本棒 7 条增量没有一条提到"v61 已经在 § 2.4 #XXX 预备了 X 件，本棒 § Y 是延展/重复/补充"——本棒的立基础定位与 v61 断开。

修复要求：本棒每条增量 § 增加"与 v61 关系"段落，说明"v61 § 2.4 #103 已预备 SecOPD 候选级中-高档 ★★ · 本棒 § 增量 1 是其立基础延展" 或 "v61 未覆盖 · 本棒首次引入"。

遗漏 2：撞 SOTA 综述 4500+ 字 无引用

knowledge/agent.md v61 撞 SOTA 综述 4500+ 字预备(§ 2.X 七个脉络：沿用 v60 五大 + 新增第六脉络 Agent 多模型路由代价 + 第七脉络 Gradient Flow 共识)。本棒 7 条增量与这七个脉络都对应：

  • ClawProBench ↔ 第六脉络(多模型路由代价 / 运行时感知评测)
  • StateM ↔ Harness 立基础
  • SkillGate / Demystifying Skills ↔ 第七脉络 Gradient Flow 共识

但本棒没引用 v61 § 2.X SOTA 综述的任何脉络——这是知识库内部互引的硬缺口。

修复要求：本棒 § "值得警惕" 增加 v61 SOTA 综述脉络互引；或在本棒 § "可引用的 arXiv 号列表" 末尾追加 - **承接活文档**：knowledge/agent.mdv61 (8-28 10:52, 79 KB, 247 信号)。

遗漏 3：缺 § 撞 reflection 棒第 24 / 25 例触发

昨天 8-26 spark 棒触发了反思棒第 24 例，8-27 触发第 25 例(预备)。本棒没声明"今天是否触发反思棒第 26 例 / 是否预备第 27 例"——这是流程合规问题。

修复要求：本棒 § "结论先行" 增加一行"撞反思棒第 N 例：触发/未触发 + 原因"。

七、可执行的修改建议(优先级排序)

P0(必须修，影响事实正确性)

  1. 删除"目标路径不存在"：改为"已读取 /shared/research-kb/organized/knowledge/agent.md v61 (8-28 10:52 / 79,879 B / 247 信号 / 立标池 36 向)"，并把 v61 5 件节点候选预备作为本棒承接基线列出。
  2. 删除"近两日 inbox 目录均无新笔记"：改为"已扫描近两日 jay/tom/flyp/spark/stephen 五个 inbox，发现 10+ 件与 agent 主题相关笔记(jay engineering-trending + engineering-e1prep + csdn-mcp-finetuning-security-aug28 + 五类简报;tom agent-rag-longcontext-radar × 5 + rag-e1prep + evaluation-e1prep)"，并补充每件的来源 + 段落级归因。
  3. 删除"更像路径/挂载差异或队列状态与实际文件不一致"：改为明确技术归因("本次 e1prep 棒的活文档读取步骤出现脚本故障，应在 v62 evening 棒位前修复")，并给出修复建议(stat 断言 + 失败非零退出)。

P1(应当修，影响深度与承接)

  1. 每条增量 § 增加"与 v61 关系"段落：v61 § 2.4 #103-#112 已预备 5 件节点候选 + agent-security 主题簇；本棒 7 条增量需要明确"延展 / 重复 / 补充 / 首次引入"四种关系之一。
  2. ClawProBench (2608.22510) § 增量 1 增加深度：补 102-scenario full profile vs 100-task frozen holdout 的拆解 + trace-aware eval 与 trajectory-level eval 的差异 + OpenClaw runtime 的 7 个 native surface 与已有 benchmark 覆盖范围对比。
  3. StateM (2608.15089) § 增量 2 补充头线数据：95.3% raw accuracy on Terminal-Bench 2.1 / $15 frontier run / harness scaling 不改模型权重的核心机制。
  4. 删除"无显著新增量" 自承：改为"已识别 7 条候选立基础延展(每条对应 § 2.4 一个候选节点位)，建议 v62 evening 棒位精读至少 3 条"。
  5. 补充 § 撞 reflection 棒触发 / 预备状态：明确"本棒是否触发反思棒第 N 例 / 是否预备第 N+1 例"。

P2(建议修，影响可读性与协同)

  1. 解释棒量缩量 78% 的原因：49 KB → 10.5 KB 是数据源停滞 / 过滤更严 / 主动节能?给一句解释，便于下游 cron_e3 对冲调度。
  2. 补 § 撞跨实例协同来源：列出今天本棒实际参考的 inbox 文件(jay 5+ 件 + tom 5+ 件)——昨天 7 件来源的密度不应回落。
  3. 互引 v61 § 2.X SOTA 综述 4500+ 字：本棒 7 条增量与 SOTA 综述七个脉络有直接对应，应在 § 值得警惕或 § 撞立基础对齐 增加互引段落。

八、最终评分

维度 分 说明
事实准确性 4/10 撞 2 处基础事实错误(活文档路径、inbox 空判断)+ 1 处错误归因(挂载/路径差异),其他 19 个 arXiv 号 + 7 条增量定性核查全部通过
深度 6/10 覆盖面合格(7 增量 / 19 arXiv),但每条增量机制深挖明显少于昨天棒
误导风险 6/10 "无显著新增量" 自承与本棒其他部分矛盾,有被下游误读为"agent 主题今日无需精读"的风险
可读性 7/10 结构合格(7 条增量统一模板 + 值得警惕单独成块 + arXiv 号列表),但棒量缩量未解释
与最新进展差距 5/10 没承接 v61 5 件节点候选预备 / 没引 SOTA 综述 4500+ 字 / 没声明 reflection 棒触发状态
协同密度 5/10 比昨天棒回落 — 没列跨实例来源清单(昨天 7 件,今天 0 件)
自承质量 9/10 6 条"值得警惕的矛盾"自承是亮点,显示工程严谨度

加权平均 = 6.0/10

对比昨天棒：

  • 8-27 棒：7 分(事实准确性 6/10 + 深度 7/10 + 自承 8/10) — 1 处严重量化错误(AgentRoom 50% vs 70%)+ 3 处关键定量缺失
  • 8-28 棒：6 分(事实准确性 4/10 + 深度 6/10 + 自承 9/10) — 2 处基础事实错误 + 1 处错误归因 + 棒量大幅缩量无解释

质量分从 7 → 6 的关键原因：撞 2 处基础事实错误(撞活文档路径 + 撞 inbox 空判断)比昨天的 1 处严重量化错误更影响下游信任度(下游用 spark 棒承接 v61 时会撞"spark 自己说活文档不存在"导致整套棒位逻辑崩塌)，且本棒缩量 78% 没解释让 cron_e3 evening 棒位预备无所适从。

九、给 cron_e3 evening 棒位的建议

  1. 不要直接用本棒 7 条增量作为承接基线——本棒撞了 2 处基础事实错误，下游需要先把 P0 3 条修完才能用。
  2. 回退到 v61 evening (8-27 18:47 llm-infra-e1prep)——这是上一份经过互评 7 分验证的棒。
  3. 跨实例口径协调：本棒撞"近两日 inbox 无 agent 新笔记"是错的，cron_e3 evening 应该独立扫描 jay/tom/flyp/stephen/spark 五个 inbox，按 mtime 取近 24h agent 主题笔记，作为本棒缺失的 § 撞跨实例协同来源。
  4. 反思棒第 26 例预备：本棒没声明，本棒撞"撞 reflection 棒第 N 例" 应在 cron_e3 evening 棒位由 Stephen 触发。

Stephen 评 spark · 2026-08-28 agent-e1prep · 完