周六精读与反方审稿 · 2026-10-24

原文关键节证据：本文只依据下列论文的方法、实验、可用局限节关键摘录（text_evidence，verification=primary_text_excerpt）。这不是完整逐段阅读，也不是实验复现或独立验证。数值仅在摘录明确给出且条件齐全时引用。材料均为 reading_depth=primary_sections 且带 text_evidence，共 3 篇进入本轮反方审读。

既有技术 / Newsletter 线索（仅背景，非本次新发现，且仅为搜索片段级）： - Baseplate（"Heroku for LLM Apps"，Kaushik Tiwari，Attack Capital Substack）：统一多模态上下文数据库 + 无代码表格界面。片段未给出完整发布时间与原文结论，仅作线索。 - vLLM issue #60537：DeepSeek-V4.1-Flash 在 /v1/messages 下把会话中途的 system message 前置，破坏 prefix caching；片段对比为合成 token 前缀测量（6711 vs 51、6713 vs 6713），未涉及 GPU 推理，修复是加 --chat-template。

两片段均为 search_snippet_only，不能当全文核验；与三篇论文无直接证据链关系，仅作背景对照。

arxiv: 2610.13735

Orthros: Phase-Aware Heterogeneous Attention for Efficient Transformers（is_new=true，主题 llm-infra）

研究笔记视角 核心主张：把"效率"从结构分配改为阶段感知解耦，在自回归序列的 prefill / decode 两阶段用不同计算范式——全序列走滑窗注意力（SWA，窗口 128）物化层级 KV cache，仅在"负责产出生成 token"的位置额外做 full cross-attention 取全局信息。由此 prefill 近似线性复杂度，decode 保持全注意力语义。方法节明确：prefill 主要执行 SWA，仅在最后一个 prompt token 触发 full cross-attention 启动生成；decode 每步处理一对解耦 token，一个更新 KV cache，一个 cross-attention 预测下一个输出。

实验节自述五条证据线：160M→6.8B scaling 与消融、从零预训练与 Transformer 及高效注意力架构对比、Llama3.1/Qwen3 base 经持续训练转换、in-context recall（128K needle-in-a-haystack 近满分）、单/多 GPU prefill 效率。关键数值：prefill 延迟最高 21.9× 加速；消融模型统一为 10B tokens、序列长 2048、0.25M tokens 批次。局限节（5 Discussion, Limitation and Future Work）作者自陈：训练期 token 计算翻倍以换取严格训练—推理一致性；传统 scaling 分析只看 training FLOPs 与 loss 的关系，会低估"以额外训练算力换长期推理节省"的架构。

反方质疑 1. 主张：prefill 优势"translates into tangible overall speedups"。质疑：end-to-end 收益取决于 prefill/decode 比例；作者自己也点明"prefill-dominated workloads"受 compute allocation 影响，那么 decode 主导（长输出、少 prompt）的真实流量里收益可能显著缩水，而这恰是不少线上代理流量的工作点。 2. 作者陈述：decode 阶段 FLOP 翻倍被 I/O-bound 特性掩盖。对照条件：该掩盖依赖 batch 与硬件带宽，是特定部署条件下的结论。 3. 复现风险：21.9× 是"最高"值，摘录未给出对应的序列长度、硬件、batch、基线实现细节；窗口固定 128，而基线的 SWA/CA 组合、KV cache 布局与 kernel 实现都会改变端到端时间。跨论文速度比不可比。 4. 我的推断（非作者明确局限）：prefill 与 decode 用不同注意力范式，"从既有 Transformer 转换需数据高效持续训练"这条路径的收敛稳定性与退化风险（如转换后长上下文质量是否回退），摘录未给出转换前后对照数值。

证据：https://arxiv.org/html/2610.13735

arxiv: 2610.13695

Verifiable Retrieval for Legal Reasoning through Structure-driven Knowledge Graph（is_new=true，主题 rag）

研究笔记视角 核心主张：不做通用 chunking，而用结构驱动解析把法条源文档建成 KG（层级：Code→Titel→§→Absatz→Satz→Nummer→Buchstabe），让检索结果带上可核验的节点 ID，与案件引用清单做结构化比对。方法节规模自洽：58 部法典、168,469 节点、240,507 边；22,253 条 cites_* 边全落在单个法典内，故为 58 棵不相交代码森林；引用起点恒为 Satz，目标为 Satz（15,030）、Nummer（6,805）、Buchstabe（418）。嵌入模型 KaLM-Embedding-Gemma3-12B-2511。实验节将五种 KG 切分粒度（§/Absatz/Satz/Nummer/Buchstabe）与朴素 100 词连续切分基线对比，可选 1-hop 扩展。

局限节作者自陈：最好配置下绝对 ToER 仍不高，且随评估深度陡降——Code 层约 14.2，§ 层约 3.2，Satz 层约 1.5；归因于 Tatbestand（案件事实）与抽象法条规范的领域鸿沟，稠密嵌入缺显式领域自适应时难桥接。

反方质疑 1. 主张：结构驱动 KG 提升引用检索准确性。质疑：指标从 Code 层 14.2 到 Satz 层 1.5 跨两个数量级，更像"切分粒度决定任务难度"而非"KG 结构本身带来增益"。若朴素基线同层未给对照数值，结构收益与粒度收益无法分离——摘录未出现朴素基线的 ToER。 2. 对照条件：1-hop 扩展依赖 cites_* 边，该边集来自特定语料（OpenLegalData）与官方 consolidated 文本的 regex 解析。我的推断（非作者明确局限）：解析器对新法典、非典型结构或英文法域的鲁棒性未被摘录覆盖；KG 构建这一上游环节的错误会向全部下游指标传导，且通常不表现为"检索失败"，而表现为"检索到结构合法但语义错误的法条"——正好落在"可核验"承诺最脆弱处。 3. 复现风险：ToER 定义、top-k、评估集规模与显著性在摘录中缺失；依赖 12B 嵌入模型 + 图扩展，重跑成本不低。 4. 作者陈述：领域鸿沟是主因。反例（我提出）：若主因是叙事—规范语言差，查询侧领域自适应（继续预训练嵌入、对 Tatbestand 做法条术语投影）可能以远低于建 KG 的代价取得同等收益——摘录无此类消融。

证据：https://arxiv.org/html/2610.13695

arxiv: 2610.13361

AgentSWE: Can Coding Agents Build the Agent You Actually Want?（is_new=true，主题 agent）

研究笔记视角 核心主张：把评测从"agent 表现"转向"agent 被造出来"，覆盖开发生命周期三阶段——从自然语言需求创建完整 agent（Creation）、编辑生产级 agent 代码库（Editing）、朝可度量目标优化（Optimization）。方法节关键设计是无参考实现：任务以四元组发布——目标 g、接口契约 ℐ、约束 𝒞、资源 ℛ；只给少量公开开发用例 D，真正的用例空间 𝒳_q 保持"未写出来"。交付物是 agent a=(h,m)，h 为编排骨架，m 经固定网关接入骨干模型；因 m 会采样，同一交付在不同执行上可能时好时坏，所以接受判定要实际执行并按行为评分。

实验节定位与既有工作的差异：WorFBench 评工作流结构，AI4AI-Bench 评训练算法重设计，SE-Bench 评知识内化，OPT-BENCH 评反馈驱动精化，AIE-Bench 在受控变异边界下改进被钉住的目标骨架；AgentSWE 增量在于完整三阶段生命周期 + 冻结提交 + held-out 用例上评行为。

局限节（Appendix J）作者自陈：主要比较与 harness 研究对每个 builder×task 组合只构建一次；Native Optimization 目标在同一 agent 重复评估间有波动；development-case、prompt-prior、eight-task 研究用 3 次独立 builder 运行并描述性报告差异；Creation/Editing 的 Result 分数由模型裁判给出，裁判与至少一个 builder 共享模型家族（Creation 用 GPT-5.6 Sol，Editing 用 DeepSeek-V4.1-Flash 并列 DeepSeek-V4-Pro/Flash）；每家族固定一个运行时模型与一个裁判，故绝对水平只在家族内可比，跨家族不可比；部分研究同时用 DeepSeek-V4.1-Flash 充当 builder、运行时模型与裁判。

反方质疑 1. 主张：benchmark 测的是"coding agent 能否交付用户真正要的 agent"。质疑：用行为评分替代参考实现对照，思路稳健；但最终分数仍交给模型裁判，而裁判与 builder 共享模型家族，共享家族偏好可能系统性偏向"该家族风格的实现"。作者承认裁判继承自身错误，但未提供裁判—人工标注相关系数或交叉裁判一致性数字，摘录中缺失。 2. 对照条件：摘录中未给出 Creation/Editing/Optimization 的具体数值结果，可引用的只有设置层面事实（3 次独立运行、描述性差异、单次构建）。故本轮不判断结论强弱，也不据此排名。 3. 复现风险：builder 采样 + 单次构建 + 家族内固定裁判叠加，单点结果方差可能很大；作者对 Optimization 波动已明说，但 Creation/Editing 的方差结构未明说（摘录仅有"每对只构建一次"，反说明主结果方差未被充分处理）。 4. 我的推断（非作者明确局限）：held-out 用例"𝒳_q 未写出来"是设计亮点，但测试集本身由 benchmark 作者构造，"用户真正要的 agent"实被代理为"benchmark 作者认为该要的 agent"——fidelity 上限由 commission 书写质量决定，而摘录未提供 commission 质量与保真度的相关性证据。

证据：https://arxiv.org/html/2610.13361

共同对照

三篇共享一条结构性主张：不要用单一、静态的架构/流程假设覆盖所有工作负载——Orthros 按 prefill/decode 阶段解耦注意力，法律 KG 论文把切分从"固定 100 词"换成"文档结构层级"，AgentSWE 把评测从"固定实现的表现"换成"构造行为的保真度"。三者都拒绝"通用平均值"目标，转而以任务结构（阶段、层级、生命周期）为切分依据。

但证据条件并不相同，不可互相换算：

Orthros 给的是效率轴量化对比（最高 21.9× prefill 加速、FLOP 翻倍代价），但收益有部署前提（prefill 占比、I/O-bound 掩盖），跨论文速度比不可比。
2610.13695 给的是检索质量轴绝对数值，作者明说偏低且随深度陡降（14.2 / 3.2 / 1.5），故它证明的是"粒度选择很关键"，尚未证明"结构 KG 优于朴素切分"——后者缺朴素基线对照数。
2610.13361 给的是评测方法论轴，本轮摘录不含最终结果数值，可信度当前取决于作者自陈的裁判共享家族、单次构建、家族内可比等限制。

三者都不提供跨论文可比的统一指标，故本轮不做排序，也不把任一篇数值当作另一篇基线。

评审覆盖状态：本轮 3 篇均已逐条评审（各有 text_evidence 与方法/实验/局限节摘录）。清单全局统计 unreviewed = 1598（即"仍有1598份未逐条评审"），quarantined_materials = 1598（失败隔离）——库内仍有大量未完成或未通过隔离闸门的材料，不代表它们无价值，也不代表已被评审；本文件不覆盖这些材料。

本文件为独立有界产出，非全库副本；所有结论仅基于上述关键节摘录。