2026-07-07 ｜ 数据来源：
results/round2-fix（F6/F7 复跑 + B 同批盲评）、results/round2-mimo（Pipeline-A 等历史批次）｜ 执行模型 MiMo 2.5 Pro， 裁判 claude-opus-4-8（scores.json 带 judge_meta 可审计）
A 是传统 RAG 报告基线，三步定死、无循环无判据：
没有任何”写得够不够好”的判断环节：检索不到不补搜、写截断了不续写、 点名实体缺失无人发现。它的价值是丈量下限——同批（round2-mimo）得分 6.86，与裸 agent 差 2 分，且换弱模型时跌幅最大（−2.72）：编排越死板， 对模型能力越敏感。
B 把题目直接交给通用 agent harness（claude -p），只做两件约束：
工具白名单限定统一搜索 CLI（禁内置联网，保证与其他方案同源检索）、
限定输出文件。agent 自主决定搜什么、读什么、何时写、何时停。
它是强基线：round2-fix 同批 8.73，耗时最短（均值 257s）。
弱点在两处：depth 8.1（四维最低项，倾向罗列事实而非机制分析）与
fail-silent（断供/限速时会静默用参数化知识编造，Round 2 污染事故
与本批 q09 “exit 0 但没写报告”均为实证）。
F6 干活的主体和 B 完全相同——同一个 agent、同一套搜索工具。区别在于 F6 不改变 agent 中间怎么干活，只在开工前和交卷后各加一道工序： 开工前先把任务拆解成明确的要求清单和一份写作规范交给它；交卷后用程序 按同一份拆解逐项检查报告，不合格就带着问题清单退回去改。
第一件事：把题目拆解成结构化的要求清单（rubric.json）。 用一个便宜的快模型读题，把题目里已经写着的要求拆解成三类： 点名必须覆盖的实体（公司/国家/项目名）、数量要求（”各举两例”就是 每类至少 2 个）、必须完成的动作（对比、评估可能性等）。这一步没有 引入题目之外的任何信息——它做的事和一个研究员接到任务先拆需求 完全相同，只是拆解结果落成了机器可核对的格式。
关键设计是拆解只做一次，全程共用：agent 研究时对照它勾进度，
交卷后程序检查时也以它为依据。如果研究和检查各自独立理解题目，
就会出现 agent 觉得自己达标了、检查时却按另一套理解打回的情况。
agent 研究过程中如果发现题目隐含的新要求（比如新冒出的关键主体），
可以往清单的 discovered 数组里追加（只能加不能删改），后续检查
会把它们一并算上。
第二件事：给 agent 一份写作规范（研究协议）。 我们从高分报告 身上总结出几条具体的行为要求，直接写进 prompt：
checklist.md，研究过程中逐项勾掉；verify_cli.py 拿到报告后做两类检查，区别在于要不要 LLM 参与：
第一类：写死的代码规则，不需要 LLM。 比如：某一节结尾是不是 写到一半断了（末尾不是完整句子）、引用是不是大量重复（100 个链接 去重后只剩十几个）、有多少正文段落一个引用都没有、某一节的引用是不是 全部来自同一个网站、自媒体来源占比是否超标。这类检查零成本、结果 确定，不会有模型幻觉。
第二类：需要先”读懂”报告的检查，让 LLM 打下手、代码做裁决。 比如”要求至少分析 3 家厂商，实际分析了几家？”——让快模型从报告里 把被实质分析的厂商名单抽出来，然后由代码数数、和要求比大小。 再如”题目要求的’对比’有没有真做？”——让快模型逐条判断报告里有没有 对应的实质内容。原则是：LLM 只负责从文本里提取信息，合格与否的 判断交给代码，这样标准不会漂移。如果检查用的快模型临时不可用， 这个情况记为”检查没做成”，不会被误算成”报告有问题”。
报告交上来后按这个顺序走：
search_calls.jsonl）对账，
如果超过一成的引用在搜索记录里查无此据，说明可能在编造引用，
必须进入细查。本批实际有 3 道题因此被拦下；shipped-with-failures 标记），
供评测端和复盘时核查——宁可承认没做到，不做静默交卷。全程每一步都留档可查：机制事件（trace.jsonl）、每次搜索的原始记录 （search_calls.jsonl）、要求清单（rubric.json）、勾选记录 （checklist.md）、评分及裁判信息（scores.json）。
| 对比 | 均差 | bootstrap 95% CI | 胜/平/负 | 显著性 |
|---|---|---|---|---|
| F6 vs B | +0.300 | [+0.200, +0.388] | 9/1/0 | 显著 |
| F7 vs B | +0.173 | [-0.003, +0.349] | 7/1/2 | 不显著 |
| F6 vs F7 | +0.127 | [+0.001, +0.241] | 6/2/2 | 勉强显著 |
| Arm | overall | compr | depth | instr | read | 均耗时 |
|---|---|---|---|---|---|---|
| F6 | 9.03 | 9.07 | 8.75 | 9.38 | 8.9 | 746s |
| F7 | 8.90 | 8.9 | 8.75 | 9.25 | 8.7 | 796s |
| B（裸） | 8.73 | 8.85 | 8.1 | 9.15 | 8.8 | 257s |
| A（Pipeline，round2-mimo 批次） | 6.86 | 7.17 | 6.33 | 6.67 | 7.27 | 326s |
本批第三轮修改零触发（17 run 零修改、3 run 仅一轮），+0.30 主要来自 agent 交卷前的自查把问题就地解决，而非交卷后的退回修改；退回修改 与”带问题交卷要留记录”是尾部保险。相对结论（F6>B）因同批配对设计可靠； F6 绝对分 8.85→9.03 的变化跨裁判批次，不可归因。A 的数字来自不同批次， 只用于量级参照。
评测置信（优先，成本低）
--pairwise），30 份报告
就位未跑——低噪声模式下复核 +0.30 是否稳健；机制精度
工程与成本