• 质量分：8

spark 评 Tom · rag E1 预消化简报（2026-07-20）

被评文件：/shared/research-kb/inbox/tom/2026-07-20-rag-e1prep.md 运行时间：2026-07-20 14:30 CST 评审时长：单文件全文通读 + 3 次 web_search 关键事实核查

一、总评

Tom 这份 E1 预消化简报结构完整、组织清晰，是 7/18–7/20 这三天 inbox 增量的合格 merge。最大的优点是 epistemic hygiene —— 对 CSDN 来源的 "47% 成本开销" 明确打了"待核验"标签，并把 6 条增量按"高/中/低 + 来源可靠度"分级，没有把博客数字塞进确定性结论。结尾给出 6 条具体可执行的活文档修订动作，落到 § 节号，可被 R38/R39 直接执行。

主要扣分点在两点：

1. arXiv ID 登记有缺漏：覆盖了 BudgetMem（增量 4）和 Corpus2Skill（增量 5），但三、表格里"本次 E1 新增可引用 arXiv"只写了 1 个（2607.10463 GRASP）。实际核查后两个真实 arXiv 号分别是 arXiv:2602.06025（BudgetMem, Zhang et al. 2026-02） 和 arXiv:2604.14572（Corpus2Skill, Sun et al. 2026）。归到 paper_cards 后能在活文档里直接交叉引用。这是个可避免的事实性错误。
2. "AI Engineer Stack 2026"六层映射与原始 Letta 文章可能错位：Tom 写"Agent Surface → Agent Runtime → Tool Connectivity → Memory → Orchestration → Evaluation"，但原始 Letta 2024 + Paolo Perrone O'Reilly 2026 改版的官方层名并非此顺序（web 搜索结果中提到的版本层名含 "Agent Surface / Reasoning Engine / Orchestration / Connector / Memory / Hands" 等不同切法）。要么是读了二手摘要、要么是把 AlphaSignal 五层模型和 AI Engineer 六层混用了。R38 §1 已经建立了 AlphaSignal 五层做底，再用"AI Engineer 六层"叠加时需要逐层对应表，否则两套术语会打架。

二、事实准确性核查

三、深度评估

• 优点：每条增量都给出"与活文档 R38 现有脉络的关系 + 建议归入哪一节"，把增量条目变成活文档的 PR-payload，而不是孤立的观察。这是好的 ingest 模式。
• 不足：
• 增量 4（BudgetMem）和增量 5（Corpus2Skill）的"工程价值论证"偏浅——只点出与 Memory 12 条腿/Retrieval-free Reasoning 的并列关系，没有和 RAG 五层质量矩阵的实际评测结果对照（Corpus2Skill 论文在 WixQA 上击败 dense/RAPTOR/agentic RAG 全部 baseline，这是核心卖点；BudgetMem 论文给出 72.4% 内存节省）。
• 增量 1 的 "89%/52%" 如果属实是关键量化锚点，但 Tom 没有交代样本量、调查方法、数据出处文章段落定位——读者无法独立验证。
• 增量 6（GRASP）只复述了 TLDR，没有把 RL 训练目标 / reward shaping / 与 DeepPlanning 的对照表补上，建议补到 §2.18 时同步。

四、可读性

• 标题层级清晰，一/二/三/四/五分节逻辑清楚。
• 表格密度合适，没有堆砌。
• 末尾"⚠️ 本次最重要待核实项"是亮点——把不确定性前置，避免被下游误用为已验证结论。

五、与最新进展的差距

• 7/19 之后的 arXiv 增量（2602.06025 BudgetMem、2604.14572 Corpus2Skill）都未被 paper_cards 登记——Tom 应该在消化同时就把 arXiv ID 录入；下次 RAG radar 应回填这两条卡片。
• "RAG 替代范式"目前 Tom 列了 Retrieval-free + Corpus2Skill 两条，但还有 Toolformer / Self-RAG / FLARE 这一类"模型内化检索"路径——Tom 没覆盖；不是必须现在补，但 §1 现状全景里至少要留一行注脚说"另有模型内化检索一族，本表暂略"。
• 增量 1 的"guardrails before action" 2026 范式转换若属实是关键趋势，建议加 1 个 Anthropic / OpenAI / Google 的官方 policy 文档交叉引用（不要只用 Substack 单源）。

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

P0（事实性，必须改）

1. 补充 arXiv ID：在第三节"可引用的 arXiv 号列表"中追加两行： - arXiv:2602.06025 BudgetMem: Learning Query-Aware Budget-Tier Routing for Runtime Agent Memory（rag, agent, memory） - arXiv:2604.14572 Corpus2Skill: Don't Retrieve, Navigate（rag, agent, navigation） 并在增量 4、增量 5 的"来源"行同步补 arXiv 号，不要只留 VoltAgent 聚合站。

2. AI Engineer Stack 六层映射：直接打开 https://theaiengineer.substack.com/p/the-ai-agents-stack-2026-edition 原文，核对六层官方命名；如果与 Letta 2024 原图不一致，要么改用原文命名、要么显式说明"Tom 的映射是 AlphaSignal 五层 + AI Engineer 六层的合成"。避免术语打架。

P1（深度增强）

3. 增量 4 / 增量 5 补评测数据： - BudgetMem：补 72.4% 内存节省数字 + RL router 状态/动作空间定义。 - Corpus2Skill：补 WixQA 上击败 dense/RAPTOR/agentic RAG 的具体 metric 增量（accuracy / grounding）。
4. 增量 1 的 89%/52% 数字：在引用前定位 Substack 原文段落；找不到则降级为"定性表述（observability 普及度高于 evals 普及度）"，不要硬塞百分比。
5. OWASP MCP Top 10 "首个" 改为 "较早的" 或 "beta 阶段的"，避免被同行评议指出夸大。

P2（结构/可读性）

6. 增量 6 (GRASP)：在建议归入 §2.18 时同步给出"和 DeepPlanning / Chat2Scenic 三栏对照表草案"（reward shaping、训练数据、inference 路径），降低 R38 修订者的认知负担。
7. "本次 E1 新增可引用 arXiv：1 个" 改为 "本次 E1 新增可引用 arXiv：3 个（含 2602.06025 / 2604.14572 / 2607.10463）"，与正文一致。
8. 增量 2 / 增量 3 / 增量 4 / 增量 5 都给了"来源需核验 / 较新 / 较新 / 较新"评级，但没有给出独立核验路径（如"建议核对 HF papers 2602.06025 / 2604.14572 的 abstract"）——建议在每条"较新"增量末尾加 1 行 "核验路径"。

P3（流程性，下次 E1 时改）

9. 下次 E1 应直接读 paper_cards 增量表（cron_classify_llm 的输出），从源头拿到 arXiv ID，避免再走聚合站二次转述。
10. 增量 1 这种"行业一手 Survey 类源"应单独建立一栏"权威行业 Survey 候选清单"，与"arXiv 论文清单"分开管理，因为前者生命周期长但数字易过期。

七、给 R38/R39 维护者的提醒

• 增量 1 + 增量 4 + 增量 5 合起来等于给 R38 §1 增加一条"2026 H2 新增三条 RAG 替代/分层路线" 的子小节，建议维护者考虑是否升级 R38 → R39。
• 增量 2（47% 成本）+ 增量 6（GRASP）合起来等于"RAG 质量 vs 成本"的新张力，建议在 §1 八角张力里考虑加第 17 角"质量-成本权衡"。
• 不要因为本简报而把 §2.6 "工具调用退化"当结论写入——这是监控项，应作为"待持续观察"标签。

评审结论：8/10。结构与 epistemic discipline 优秀，达到可 merge 进 R38 修订 pipeline 的水平；P0 两条（arXiv ID 补全 + 六层映射核源）改完即可上 9。