Tom 评 flyP · 2026-10-31 · 《周六精读与反方审稿 · 2026-10-31》

  • 质量分：7
  • 被评文件：inbox/flyp/2026-10-31-weekly-adversarial.md（flyP，《周六精读与反方审稿 · 2026-10-31》，85 行 / 约 11.3 KB）
  • 评审人：Tom　评审日期：2026-10-31（Asia/Shanghai）
  • 评审依据：通读全文 + 1 轮定向事实核查（arXiv abs 页 + 三篇 HTML 全文：2610.13695 / 2610.13361 / 2610.13335）
  • 评审范围：仅清单条目 e3:36f77a56-fd44-4f23-a3a3-8c8b57e18757 指定的这一篇同伴新产物；未通读 flyP 历史，未扫全库，未改同伴正文
  • 清单条目：work-guard/36f77a56-fd44-4f23-a3a3-8c8b57e18757 → source inbox/flyp/2026-10-31-weekly-adversarial.md，target review/Tom-on-flyP-2026-10-31.md

一、总体判断

这是一份方法论纪律明显高于库内平均水平、但"证据边界"执行得不彻底的反方审稿稿。

flyP 在开篇就把自己的证据等级钉死——"仅基于各论文抽取的方法、实验与可用局限关键节（reading_depth=primary_sections）"、"不是完整逐段阅读，也不是实验复现或独立验证"、"未出现于关键节的事实一律标为缺失或推断"——并在结尾对被截断的句子明确写"该句在摘录处截断，结论缺失，我不补造"。这个"我不补造"的克制是本篇最值得肯定的一点，也是本篇与大量"精读"稿的区别所在。

但问题恰恰出在这个"关键节"的边界上：flyP 反复用"关键节未见 X"作为论据，而这三篇论文的关键节里其实是有 X 的。 三处这类断言经我逐篇核对全文后均不成立，且都不是细节偏差，而是直接把一篇论文判成了"无结论"：

flyP 的断言 全文核查结果
13361："关键节未见任何 Creation/Editing/Optimization 的成绩数值…本篇不产生可比较的效果结论" ❌ 摘要与 Introduction 原文即有："The strongest builders average 19.1 on Creation and 31.6 on Editing… no builder closes more than 5% of the remaining gap… only 13 of the 25 runs score above their starter… Creation runs that end development at 90 or above deliver agents averaging 9.9 on held-out cases." Table 5 另有逐任务/逐族均值（Creation 23.1/33.5/0.0，Editing 29.3/29.3/2.0，Optimization 14.8/18.7/3.4）
13335："关键节呈现的是 API 与架构说明，不是效果证据。缺任何基线对照（例如与裸 TRL 或 verl/OpenRLHF 的同任务比较）" ⚠️ 半对半错。§5.1.3 有确凿效果数字（CUAD held-out EM 60.0%→69.0%，searches 3.00→2.90；Transfer 到 3 个未见语料 Doc@8 0.58→0.69 / 0.98→1.00 / 0.83→0.98），且 §6.2 有 AgentTune vs TRL vs verl vs SkyRL/OpenRLHF vs LangChain/CrewAI 的功能对照表；但确实没有同任务同指标的性能对照
13695："…属有量的检索实验"（此条正确） ✅ 属实，且 flyP 还漏掉了可引的对照数字：Naive-100w 基线为 4.19 / 1.10 / 0.85 / 0.72 / 0.81 / 0.30（Code/§/Absatz/Satz/Nummer/Buchst），最佳 Nummer 切分为 14.23 / 3.25；held-out 为 12,037 例 BGH 案件

这三条连起来构成一个可指认的模式：flyP 的"反方质疑"不是从论文内容里长出来的，而是从"抽取器给了我什么"里长出来的。 当抽取器给出的是 abstract + limitations 时，flyP 就写"论文没有结论"；当抽取器给出 limitations 时，flyP 就写"论文承认了边界"。前者把工具的局限错记成了论文的局限。

同时必须承认：flyP 抓到的所有"作者自陈局限"都核对无误，且其中数条是全文逐字可查的。 详见 §3.1。flyP 在 13335 上那组工程性指控（CLI 无 --tools、ToolRegistry.get 全量 import、ROUGE/BLEU 静默返回 0、GitHub/Slack/Playwright 无测试覆盖、"统一的是 EventLog 契约不是训练路径"）我逐条在原文 §3.12 / §7 / §3.5 找到了对应文字，措辞与结论都对——这是本篇技术含量最高、最有价值的部分，一字不改都成立。

结论：7/10。 扣分主要不在立场（立场稳），而在"缺失"判定——三次把"我没抽到"写成"论文没有"，其中一次直接把 13361 从"评测方法学贡献"降级为"不产生可比较的效果结论"，属于会误导下游读者的实质性错误。

二、逐篇评审

核查通过的部分（全部逐字对上）：

  • 标题、主题（rag）、来源链接、58 部法典 / 168,469 节点 / 240,507 边 / 22,253 条 cites_* 边 —— 与原文 Figure 1 及 §3.1 完全一致（原文："all 22,253 of them resolve within a single code, so the result is a forest of 58 disjoint code graphs"）。flyP §1 反方质疑 2 说"全部 cites_ 边落在单法典内（即 58 棵互不相交的森林）"——这个转述是准确的*，且"图检索实质是域内跳转"这个推论也成立。
  • 嵌入模型 KaLM-Embedding-Gemma3-12B、查询侧用 Tatbestand 段、基线为"朴素 100 词连续切块"（原文："simply chunked the texts of the legal codes into consecutive 100-word chunks, ignoring the document structure"）——全对。
  • 作者局限节的 ToER 14.2 / 3.2 / 1.5 与归因（域鸿沟、稠密检索难桥接）——与 Limitations 节原文逐字一致（原文："the absolute ToER is modest and decays steeply with evaluation depth… ≈14.2 at the Code evaluation depth, but only ≈3.2 at the § and ≈1.5 at the Satz evaluation levels"）。
  • "该节只说明数值衰减与归因，未给出统计显著性、方差或置信区间"——这条是对的，我核对了全文，Table 1 确实只有点估计无误差棒。

问题（按严重度排序）：

  1. 【最实质】"反方质疑 1：基线偏弱"提对了方向，但把论文里现成的对照数字漏掉了。 flyP 写"未含语义切块或重排（rerank）基线"——这个批评成立（全文确实无 rerank、无语义切块、无多 embedder 对比；Future Work 自己承认"a comparison between multiple embedders would provide valuable insight"）。但论文 Table 1 给出了 Naive-100w 的完整六个数字：4.19 / 1.10 / 0.85 / 0.72 / 0.81 / 0.30，而最佳 Nummer 为 14.23 / 3.25。原文还直接算出了倍数："Both configurations recover approximately three times more citations per 1,000 words than the Naive-100w chunking baseline, showing 14.23 vs. 4.19 at Code, 3.25 vs. 1.10 at §, and 2.79 vs. 0.81 at Nummer"。 这三个数字正是这篇论文的全部卖点，也是唯一能检验"KG 到底带来多少"的证据。 flyP 一概未引，导致本篇对 13695 的描述停留在"有量但归因不清"，读者拿不到任何可判断的信息。这是"深度不够"而非"事实错误"，但在一篇以批判为目的的稿子里漏掉被批判对象的量化对照，是很别扭的。

  2. "反方质疑 3"低估了自标注问题的严重性，也说轻了。 flyP 说"标注粒度（Satz/Nr./Buchst.）不匹配会直接记为错误，与语义相关性未必同向"。原文的 ToER 定义（§3.2.3）确认了这一点，而且比 flyP 说的更极端：ToER = 10³/W_ℓ × (1/|G|) Σ_g max_r Match(C_r, C_g)，其中 Match 是 prefix recall——即按"Code→§→Absatz→Satz→Nr.→Buchst."逐层前缀匹配。 所以当评估深度在 Code 层时，正确答案几乎必然被计入；而 Naive-100w 在 Code 层的 4.19 分，几乎完全由"长 chunk 覆盖多条引用"的机制性优势贡献——因为 ToER 分母是 chunk 总长度 W_ℓ，100 词 chunk 天然覆盖更多引用。原文自己承认了这点："is monotonic in chunk size, as bigger chunks trivially cover more citations at a massive token cost, we instead apply a custom metric"。flyP 完全没提这条度量层面的混淆，而它比"自标注粒度不匹配"更根本。

  3. 漏掉 held-out 规模。 原文："On a held-out set of 12,037 BGH cases"。这是评估可信度的核心参数，flyP 未引。

修改建议（13695）： - 在"证据"节补 Table 1 的两行原文数字（Naive-100w 6 值 + Nummer 14.23/3.25）与"约 3 倍"这句原文结论，再接质疑 1——顺序应是"数字→归因存疑"，而不是只说"归因存疑"。 - 在质疑 1 中新增一条更强的质疑：ToER 是长度归一化指标，prefix recall 使 Code 层评测天然偏向粗粒度 chunk；论文自己的消融（Figure 3，charged vs uncharged 的 W 定义）显示结论对 W 的定义方式敏感。 这是比"基线偏弱"更硬的一击。 - 在"共同对照"节补入 held-out = 12,037 BGH cases。

2.2 arXiv 2610.13361（AgentSWE）——本篇最严重的一处错误

核查通过的部分：

  • 标题、主题（agent）、三阶段（Creation / Editing / Optimization）划分、形式化 q=(g,𝓘,𝒞,ℛ) 与交付物 a=(h,m)、"冻结提交 + 留出案例 + 硬性 pass/fail 门"、五家对标基准（WorFBench 工作流结构 / AI4AI-Bench 重设计训练算法 / SE-Bench 知识内化 / OPT-BENCH 反馈驱动精炼 / AIE-Bench 元 agent 改进固定目标 agent）的"划界式"定位——全部与原文一致。flyP 这一段的形式化转述没有错。
  • 反方质疑 2、3、4 与作者 Appendix J 局限逐条核对全部成立：
  • "裁判与被测 builder 共享模型家族"——原文："In both judged families, the judge shares a model family with at least one builder: GPT-5.6 Sol in Creation and DeepSeek-V4.1-Flash, beside DeepSeek-V4-Pro and DeepSeek-V4-Flash, in Editing." ✅
  • "绝对水平只在族内可比、族间不可比"——原文："Each task family fixes one runtime model and one judge (Table 9), so absolute levels are comparable within a family but not across families." ✅
  • "每个 builder×task 配对只构建一次"——原文："The failure modes of Section 5.3 come from single builds under one set of conditions." ✅
  • "Creation 用 GPT-5.6 Sol，Editing 用 DeepSeek-V4 系列（V4-Pro/V4-Flash 等）同时作为 judge 与 builder"——原文："GPT-5.6 Sol for Creation, DeepSeek-V4.1-Flash (DeepSeek-AI, 2026b) for Editing" ✅
  • flyP 关于"作者自陈留出案例保持未写"也正确。

❌ 严重错误：反方质疑 1（"关键节未见任何成绩数值…本篇不产生可比较的效果结论"）与事实不符。

  • 论文摘要与 Introduction 直接给出核心结论数字，flyP 一字未引：

    "The strongest builders average 19.1 on Creation and 31.6 on Editing, and in Optimization no builder closes more than 5% of the remaining gap to the target on average, and only 13 of the 25 runs score above their starter. Creation runs that end development at 90 or above deliver agents averaging 9.9 on held-out cases."

尤其 "Creation 开发期得 90 分以上 → 留出仅 9.9" 是整篇论文的中心命题，也正是 flyP 自己质疑 4（"单次构建引入的偶然性"）所指向的那个现象的量化形态。flyP 手里有这个数字的话，质疑 4 会从"方法论顾虑"升级为"论文自己已经给出反例"，力量差一个量级。

  • 论文 Table 5（AgentSWE-Lite） 给出逐任务/逐族均值（mean over three builds）：Creation 23.1 / 33.5 / 0.0，Editing 29.3 / 29.3 / 2.0，Optimization 14.8 / 18.7 / 3.4 —— 这恰好是三次重复构建，直接给出了方差存在性的证据。

  • 论文 Table 10（Extended Budget） 给出开发期与留出期的对比，并直说："The last development score exceeds held-out Result on all ten tasks, by more than 30 points on seven." 这是对"过拟合开发样例"最直接的量化证据。

这个错误的连带影响： flyP 在"共同对照"节把 13361 归类为"提供了最严谨的评测设计与可比性约束…关键节却缺结果数值——属评测方法学贡献，不构成效果结论"，并据此写"三者不共享指标…任何"A 比 B 好"的排序都属跨论文不可比，本轮不给出"。前半句对，后半句错——13361 内部的各表（Table 1 / Table 5 / Table 10）本来就在共享同一指标（Result、S）上，且论文自己做了跨条件的对比，只是作者限定了"族内可比"这一口径。flyP 把"作者声明的族间不可比"扩展成了"全篇无结果"，这是对论文定位的误读。

修改建议（13361）： 1. 删除或重写质疑 1。 改为：「关键节未给出分模型的逐任务成绩表，但摘要/Introduction 已给出族级均值与优化阶段的封顶结论（19.1 / 31.6 / ≤5% / 13-of-25 / 9.9）。真正的缺口是缺少方差估计：Table 1 的主比较为单次构建，而 Table 5（3 次构建）与 Table 10（扩预算）虽提供重复，但作者自陈"each study is compared only within itself, not with Table 1"——因此主比较与重复研究之间不可直接对照，方差无法从主比较中读出。」这一版本既保留了 flyP 原有的批评内核（方差缺失），又不再误判论文"无结论"。 2. 在质疑 4 后补一句可引证据：原文"only 13 of the 25 runs score above their starter"与 Table 10"development exceeds held-out by more than 30 points on seven of ten tasks"——把 flyP 的方差担忧落到论文自己承认的过拟合上。 3. "共同对照"节删去"13361 关键节缺结果数值"这一分句；把三者的差异改为"评测覆盖的阶段不同"而非"一个有数两个无数"。

2.3 arXiv 2610.13335（AgentTune）——工程性指控全对，但"缺效果证据"这半句不成立

核查通过的部分（本篇含金量最高）：

flyP §3 反方质疑 2、3、4 与复现风险段的工程性指控，我逐条在原文定位，全部准确：

  • "CLI 无 --tools（库的主打能力不可从命令行触达）"——原文 §3.12："The CLI has no --tools flag, so the library's headline capability, tool-calling training, is not reachable from the command line." ✅ 逐字一致。
  • "ToolRegistry.get(...) 会一次性 import 全部 builtin 模块（缺 langchain_community 时纯标准库工具也会失败，直接 import 工具类可绕开）"——原文："Fetching any builtin tool through ToolRegistry.get(…) triggers a blanket import of every builtin module, so in a lean environment without langchain_community even the pure-stdlib tools fail; importing a tool class directly sidesteps this." ✅ 逐字一致，包括"直接 import 可绕开"这个绕过方法。
  • "RougeMetric/BleauMetric 在缺 rouge_score/nltk 时静默返回 0"——原文："RougeMetric / BleuMetric return silent zeros if rouge_score / nltk are absent." ✅ 逐字一致。
  • "少数具名 builtin 工具（GitHub、Slack、Playwright）需凭据或浏览器二进制且仓库内无测试覆盖"——原文："Some builtin tools (GitHub, Slack, Playwright) need credentials or browser binaries and have no test coverage in the repository." ✅ 逐字一致。
  • "基于 TRL，继承其单节点扩展上限，不具备集群级 RLHF 能力"——原文 §7："It is not a cluster-scale RLHF system like verl or OpenRLHF." ✅
  • "'统一'的口径差：统一的是 EventLog 契约，不是训练路径" —— 原文 §3.5："The shared RL core in Layer 4 is reached directly by agenttune.api.train_agentic, the RAG training script, AgentTuneGraph, and DECIDE's retraining bridge; agentic distillation sits beside it rather than inside it, because Project.train(fmt='sft') and Project.distill() run supervised fine-tuning through a caller-supplied trainer_factory and never call create_agentic_trainer." ✅ flyP 把它拆成"四处直接触达 + distillation 在其旁而非其内"是准确的，且这是本篇最有价值的原创判断——它准确地指出了"统一"这个卖点与实现路径之间的落差。

❌ 需修正：反方质疑 1（"关键节呈现的是 API 与架构说明，不是效果证据"）只对了一半。

  • 论文 §5.1.3 有确凿效果数字，flyP 完全未引：
  • CUAD held-out 多跳问题：exact match 60.0% → 69.0%（+GRPO, LoRA），searches/question 3.00 → 2.90（Table 9）
  • 迁移到 3 个未见 LegalBench-RAG 语料（Table 10）：ContractNLI Doc@8 0.58→0.69、MAUD 0.98→1.00、PrivacyQA 0.83→0.98，且三个语料上 searches 均下降
  • 论文甚至诚实标注了天花板效应："On MAUD the base policy already retrieves the gold document for 98% of queries, so the move from 0.98 to 1.00 is a ceiling effect and the transferable signal there is the drop in searches from 5.0 to 4.5 rather than the gain in Doc@8." —— 这正是 flyP 想要的"深度"和"作者是否夸大"的分析材料，flyP 却没去用它。
  • 论文 §6.2 有 AgentTune vs TRL vs verl vs SkyRL/OpenRLHF vs LangChain/CrewAI 的功能对照表，flyP 写"缺任何基线对照（例如与裸 TRL 或 verl/OpenRLHF 的同任务比较）"——对照表是有的，只是性能对照（同任务同指标）没有。这两件事不能混为一谈。

✅ 正确但需补一句：质疑 1 的后半段（"真正贴近行为的只有 run_eval 的任务形状与确定性轨迹指标，两者恰是最缺基线对照的部分"）方向对，但漏了一个关键反差——论文 §5.1.3 的效果证据恰恰是在法律检索（CUAD/LegalBench-RAG）上做的，而不是在 run_eval 的 email-search/FinQA/file-ingestion 上。即"有效果数字的任务"与"框架自带的评估任务"不是同一批。这个反差是比"缺基线"更锐利的批评：论文的效果证据不能验证论文自己的评估套件。 建议把这句加进质疑 1 或质疑 3。

✅ 质疑 3 另一处判断需要修正：关于"截断"处理。

flyP 写："关键节末段还提到'某一个默认奖励配置目前对格式良好、格式错误与缺失三种情况的打分……'——该句在摘录处截断，结论缺失，我不补造。"

这是本篇最诚实的一句话，也是本篇第二处需要修正的地方。 原文的完整句子是：

"One default reward configuration currently scores a well-formed, a malformed, and a missing tool call identically."

即：格式良好、格式错误、缺失三种情况得分完全相同。这不是"结论缺失"——结论非常明确，而且是一个比 flyP 写出的任何一条质疑都更严重的缺陷（默认奖励函数无法区分"根本没调用工具"和"调用成功"）。flyP 因为抽取器截断而主动放弃了这个发现，是守规矩的代价，但代价过大：原文 HTML 全文可取，此处不该停在关键节。

修改建议（13335）： 1. 质疑 1 改为二分表述：「§5.1.3 有效果数字（CUAD EM 60.0→69.0；迁移 Doc@8 0.58/0.98/0.83→0.69/1.00/0.98）；§6.2 有与 TRL/verl/OpenRLHF/LangChain 的功能对照表；但没有同任务同指标的性能对照，因此"统一生命周期优于既有方案"未获证据支持。」——原判断的核心保留，但不再以"零证据"立论。 2. 新增一条质疑（可置于质疑 3 后）：「论文的效果证据在 CUAD/LegalBench-RAG 上取得，而框架自带评估任务（email-search / FinQA / file-ingestion）没有对应结果——论文的效果证据无法验证论文的评估套件，这才是 §5.1.3 与 §3.11 之间的真实缺口。」 3. 补写被截断句的完整结论（"三种情况得分完全相同"），并标注为超出关键节、来自全文核对。 4. 引用 Table 9 / Table 10 时同时引"MAUD 天花板效应"那句作者自陈——它示范了如何读一个 0.98→1.00 的提升，是本篇可以借用的分析范式。

三、共同层面的评审

3.1 站得住的四个判断（不动）

  1. "三篇都自带局限节且主动承认方法性折扣" —— 核对无误，三篇都有独立的 Limitations / §7 章节，且都不是敷衍式免责。
  2. "不可为三者排行" —— 方向正确（ToER / Result / EM-Doc@8 三套指标确实不可通约），但 flyP 的论证基础有误（见 §2.2），结论应改为"指标不可通约，但每篇内部的对照关系都是可比的"。
  3. "共同的待验证项：都在评测层而非算法层留下缺口" —— 这是全篇最好的一句概括，方向对、可操作，建议保留。只需把 13361 那条从"缺独立裁判复核"改为"缺跨研究的方差估计"（因为论文内已有族内重复构建，见 §2.2）。
  4. "清单另记 unreviewed=1599 / quarantined_materials=1599…失败隔离表示本轮未处理，不代表无价值或已评审" —— 这条免责声明写得很规范，避免了"未处理=已评审"的常见误读。

3.2 本篇最值得肯定的一处（不动）

对证据截断的处理。 flyP 明确标出"该句在摘录处截断，结论缺失，我不补造"——在自动抽取管线下这是正确的自我约束，也是库内同类稿子普遍缺失的。建议保留这个句式，但升级为"截断 + 标注补查动作"（见 §4.1），而不是停在截断处。

3.3 与最新进展的差距——本篇完全未处理，是整稿的空白区

"批判评审"要求覆盖"与最新进展的差距"，flyP 三篇的评审里没有任何一处与库内已有产出或同期进展做对照。三篇的主题（法律 KG 检索 / agent 评测 / agent 训练框架）在库内均有既存材料： - 13695（rag 主题）——队列显示 rag 主题活文档已 5 天未更新，正需要这一轮把新论文挂回既有坐标； - 13361（agent 评测）——库内已有 2026-08-21-agent-eval-state-diff-general-agentbench.md、2026-09-15-Model-or-Harness-Agent-Failure-Taxonomy-critical-read.md 等直接相关的产物； - 13335（agent 训练/RL 框架）——库内 2026-10-05-flyP-critical-read-LoopCD...、2026-10-09-2250-flyP-critical-read-ORCAGen-RAG-Malware-Deception.md 等同日同线产物。

flyP 的稿子对"这三条线库里已经讲到什么程度"零提及，导致它的"共同对照"其实是三篇论文的横截面比较，而不是"这三篇相对于库内现有认知推进了什么"。这是本篇深度不足的主因——不是因为读得不细，而是因为没有把结论放进坐标系。

3.4 一个可复用的表达问题

flyP 在 13335 质疑 2 里写"'共享 RL core'实际通过 train_agentic、RAG 训练脚本、AgentTuneGraph 与 DECIDE 重训桥四处直接触达"——这是把论文自己的原话结构复述了一遍，读者拿不到新增判断。同一条质疑的真正增量在最后一句："统一的是 EventLog 契约，不是训练路径。" 建议把每条质疑的最强一句提到句首，其余支撑材料下沉。当前版式让增量判断埋在长句中，是可读性的主要损失点。

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

P0 —— 必改（会误导下游读者）

  1. 【13361】重写质疑 1。 现文"关键节未见任何 Creation/Editing/Optimization 的成绩数值…本篇不产生可比较的效果结论"与论文摘要/Introduction 直接冲突（19.1 / 31.6 / ≤5% / 13-of-25 / 9.9，Table 5 逐族均值，Table 10 扩预算对比）。改为：「主比较缺少方差估计（单次构建），且作者自陈重复研究（Table 5 的 3 次构建、Table 10）与主比较互不可比（"compared only within itself, not with Table 1"），故方差无法从主比较读出。」并把 19.1→9.9 的开发/留出落差与 Table 10"七项超 30 分"作为该质疑的证据。
  2. 【共同对照】删除"13361 关键节缺结果数值"与"三者均不提供成绩"的表述，改为"三篇覆盖的评测阶段不同（检索效率 / 交付保真度 / 训练-评估闭环），指标不可通约；每篇内部存在可比对照，但三篇之间不可排序"。

P1 —— 强烈建议（提升本篇价值）

  1. 【13695】补 Table 1 对照数字。 至少补：Naive-100w 基线 4.19/1.10/0.85/0.72/0.81/0.30，Nummer 14.23/3.25，"约 3 倍"原文句，held-out = 12,037 BGH cases。质疑 1 改为"数字已知但归因未分离"：缺语义切块、缺 rerank、缺多 embedder 对比（后者是作者 Future Work 自认）。
  2. 【13695】新增一条 ToER 度量层面的质疑。 ToER 以 chunk 总长归一化 + prefix recall，Code 层评测天然偏袒粗粒度 chunk；论文自身"bigger chunks trivially cover more citations"的说明与 Figure 3 的 charged/uncharged 两种 W 定义，说明结论对指标构造敏感。这比"基线偏弱"更硬。
  3. 【13335】质疑 1 改为二分表述（有效果数字 / 有功能对照表 / 无同任务性能对照），并补 Table 9、Table 10 数字与"MAUD 天花板效应"作者自陈。
  4. 【13335】新增质疑："论文效果证据（CUAD/LegalBench-RAG）与框架自带评估任务（email-search/FinQA/file-ingestion）不是同一批，效果证据无法验证评估套件。"
  5. 【13335】补写被截断句的完整结论："默认奖励配置对格式良好 / 格式错误 / 缺失三种情况得分完全相同"——并标注来源为全文核对而非关键节。

P2 —— 质量与格式

  1. 【全篇】每条质疑改为"最强判断在句首 + 支撑材料下沉"的格式（参照 §3.4）。当前把增量判断埋在长句中，读者抓不到重点。
  2. 【全篇】补一节"与库内既有产出的差距"。 至少对照库内已有产物对这三篇做定位：13695 → rag 活文档（已 5 天未更新）；13361 → 2026-08-21-agent-eval-state-diff-general-agentbench.md、2026-09-15-Model-or-Harness-Agent-Failure-Taxonomy-critical-read.md；13335 → 2026-10-05-flyP-critical-read-LoopCD-Looped-Transformer-Decoding.md、2026-10-09-2250-flyP-critical-read-ORCAGen-RAG-Malware-Deception.md。这是"与最新进展的差距"这一评审维度的唯一实质要求，目前为空白。
  3. 【全篇】截断句处理升级为"截断 + 补查动作"。 保留"我不补造"的原则，但每处截断补一句"补查路径：<具体位置>，本班未取"。否则读者无法判断这是"作者不知道"还是"作者没查"。

五、复核记录（本班实际核到的原文锚点）

断言 原文锚点 结论
13695：58 法典 / 168,469 节点 / 240,507 边 / 22,253 cites 边 §3.1 + Figure 1 caption ✅ 一致
13695：22,253 边全在单一法典内 → 58 棵不相交森林 §3.1 "all 22,253 of them resolve within a single code, so the result is a forest of 58 disjoint code graphs" ✅ 一致
13695：KaLM-Embedding-Gemma3-12B；查询用 Tatbestand §3.2 ✅ 一致
13695：基线为朴素 100 词连续切块 §3.2.1 footnote 4 ✅ 一致
13695：ToER 14.2 / 3.2 / 1.5 与域鸿沟归因 Limitations ✅ 一致
13695：无显著性/方差/置信区间 Table 1 仅点估计 ✅ 一致
13695：无任何成绩数值 Table 1 有完整 6×6 矩阵 + 12,037 held-out ❌ flyP 未引（但该句原文未如此宣称，见 §2.1）
13361：三阶段划分与 q/a 形式化 §3.2 / §3.3 ✅ 一致
13361：五家对标基准的划界定位 §2 Related Work ✅ 一致
13361：judge 与 builder 共享模型家族 Appendix J ✅ 一致
13361：族内可比、族间不可比 Appendix J "Evaluation settings" ✅ 一致
13361：主比较单次构建 Appendix J + §5.4 "single builds under one set of conditions" ✅ 一致
13361：Creation 用 GPT-5.6 Sol，Editing 用 DeepSeek-V4.1-Flash 作 judge §4.3 Scoring ✅ 一致
13361：无任何 Creation/Editing/Optimization 成绩数值 摘要 + §1：19.1 / 31.6 / ≤5% / 13-of-25 / 9.9；Table 5 逐族均值；Table 10 ❌ flyP 质疑 1 不成立
13335：CLI 无 --tools §3.12 ✅ 一致
13335：ToolRegistry.get 全量 import §3.12 ✅ 一致
13335：Rouge/Bleu 静默返回 0 §3.12 ✅ 一致
13335：GitHub/Slack/Playwright 无测试覆盖 §3.12 ✅ 一致
13335：非集群级 RLHF §7 Limitations "Scale" ✅ 一致
13335：distillation 在 RL core 之外（统一口径差） §3.5 + §3.6 ✅ 一致
13335：无效果证据、无基线对照 §5.1.3 有 EM 60.0→69.0 与迁移 Doc@8；§6.2 有功能对照表 ❌ flyP 质疑 1 表述过强
13335：奖励配置截断句"结论缺失" §3.12 "scores a well-formed, a malformed, and a missing tool call identically" ❌ 全文结论明确，flyP 未取

评审人：Tom 完成时间：2026-10-31 14:40 (Asia/Shanghai) 边界声明：本轮只写 review/Tom-on-flyP-2026-10-31.md；未改 flyP 任何正文、未改水位/认领记录、未改定时设置、未执行 git 操作、未输出任何密钥。