← Multi-Agent Research

Template 3：论文写作 + 同行审稿流水线

把 Template 2 的研究笔记转化为多篇 ready-to-submit 论文，每篇带强制审稿与修订

研究模式（必读）

用途

当 Template 2 已输出带"关键发现"与"推荐期刊与理论延伸"小节的命题研究笔记时，本模板把笔记中每一个可发 paper 的方向自动转化为一篇 LaTeX 学术论文，并强制每篇通过一位"30 年经验终身教授"reviewer-agent 的就地修订。

输出物：项目目录下 paper_submission/ 子目录，按方向分子文件夹，每个子文件夹一份 self-contained main.tex（含 thebibliography）+ 一份审稿报告（≤300 字）写回到 stdout。

与 Template 1 / 2 的关系

Template 3 的唯一输入是 Template 2 的最终 HTML 笔记（或等价的 markdown 决策文档）。可独立使用，前提是手头有这样一份笔记。

已完成示例

架构

总 agent 数：2N（writer + reviewer，N 个方向），加 main thread 协调，加 Stage 5 可能的 fixup agent（≤ 2N）。预算（关键角色 Opus 4.7）：

• N=3 standard：~6–12 agent，\$15–35，30–60 分钟
• N=5 standard：~10–20 agent，\$25–60，60–90 分钟
• deep paper（writer 多轮迭代 + reviewer 独立复现完整数据集）：每篇额外 +20-50% agent / 时间，~\$10–20/篇

Mode B（全 Sonnet 4.6 + 综述模式跳过 reviewer 独立复现）：\$3–8 即可。之前 v1 的 "\$2–5" 是 v1 单轮、无独立复现、无 §Predictions 的下限值，不适用 Mode A research paper 实战。

模型选择：writer 和 reviewer 都强烈推荐用 Opus 4.7。本模板下面专门吐槽过"writer 倾向 over-claim，Sonnet 默认乐观"——opus 4.7 在 conditional vs unconditional 的措辞克制上明显更好；reviewer 抓 over-claim 的能力直接决定 paper 质量。main thread 协调也用 Opus 4.7。预算紧张时才降到 Sonnet 4.6。

预算分配

典型 N = 3–5。N > 5 时 main thread 上下文吃紧，应分批跑（每批 ≤ 5）。

Stage 2 / 3 agent 的具体 prompt 模板

Writer agent（每方向一个，并行）

你是一个数学专业 PhD 博士生。任务：写一篇 ready-to-submit LaTeX 论文。

【输出路径】<project>/paper_submission/paper<K>_<slug>/main.tex
（创建目录；不写其他文件；不写 README）

【主题】<一句话主题 + 主定理候选陈述>

【证明路线】<从 Template 2 笔记 §3 / §5 抄入；明确每一步的依据>
1. ...
2. ...
3. ...

【必须包含的章节】
- §1 Introduction（含完整主定理陈述 + 与既有文献对比表）
- §2 Notation & preliminaries
- §3–§K 技术核心（每条引理 / 定理都要有完整证明，不能仅 cite）
- §K+1 Numerical verification（含已验证表格；标明 "every case passed"）
- §K+2 Discussion（与最相关文献比较，列出本工作的精确增量）

【硬约束】
- LaTeX article, 11pt, amsmath/amsthm/amssymb/mathtools, self-contained
  thebibliography（不写 refs.bib）
- ~15–25 页编译长度
- 摘要 ~150 字、MSC2020 代码、keywords
- 每步严格；避免 hand-waving；显式状态每个引理
- 若某步骤无法严格证明 → 明确降格为 "Conjecture" 或 "Conditional Theorem"
  并标注假设。诚实大于野心。
- \author{} 留空

【目标期刊】<具体一个或两个>

【验证】可调用 python 验证数值断言：
  uv run --with sympy python -c "..."
（galois 包在很多代理后下载失败；优先 sympy + GF modulus）

写完后用 ≤150 字汇报：文件路径、页数估计、关键 judgment call。
不要回传整份 LaTeX。

Reviewer agent（每方向一个，并行）

你是一位 30 年经验的终身教授，常年为 <目标期刊> 审稿。任务：审稿这份手稿。

【手稿】<project>/paper_submission/paper<K>_<slug>/main.tex

【一句话主题】<同 writer brief>

【你的工作】通读 .tex 全文（一次性 Read 整文件）。实质性审稿：

1. 找 未论证步骤、隐含假设、hand-wave、循环论证。特别审视：
   - <列出 writer brief 里最容易出问题的 2-3 处>

2. 对每个问题，直接用 Edit 工具修改 .tex 文件。不要只挑毛病；修。
   - 引理需要前置 → 加引理
   - 常数错 → 改常数
   - 引用张冠李戴 → 修引用
   - 某步真的证不了 → 把 theorem 改成 conjecture / heuristic，
     摘要同步弱化

3. 改进 影响证明的 表述。不要为加而加新章节。

4. 必要时可调 python 验证小数值断言。

5. 出一份 ≤300 字 referee report：
   - 找到的 top 5 问题
   - 你做的修改
   - 你的修改后判定：是否 ready-to-submit？

对严谨极其苛刻，但建设性。 不能改进的正确证明不要瞎动。
若某证明确实站不住，承认它并降格——一份诚实的 conditional 论文
比一份藏 gap 的"定理"论文更可发表。

决策日志（可选）

如果跑超过 5 个方向，建议在 paper_submission/decision_log.md 同样保留实时账本：

[stage0]            2026-05-24 23:30   ok       n_directions=5
[stage1.sentinel]   2026-05-24 23:33   ok       7 (q,d) checked, all pass
[stage2.writer.1]   2026-05-24 23:37   ok       paper1_main, 765 lines
[stage2.writer.4]   2026-05-24 23:36   ok       paper4_ss_gap, 318 lines  ← 注意短
[stage3.reviewer.1] 2026-05-25 00:14   accept   minor revisions
[stage3.reviewer.4] 2026-05-25 00:17   reject   Lemma 3 vacuous on monics
[stage4.summary]    2026-05-25 00:18   ok       3 green, 1 yellow, 1 red

"三色"判定标准（Stage 4）

Stage 5：编译 PDF（main thread）

Stage 4 汇总完成后，main thread 直接调 tools/latex_compile_papers.sh 把所有 paper_submission/paperN_*/main.tex 批量编译成 PDF：

# 首次：装齐 BasicTeX 上的 CTAN 包（一次性，约 200 MB）
bash /Users/l/Git/3_P/20260522_math/tools/latex_install_packages.sh

# 编译该 topic 的全部论文
bash /Users/l/Git/3_P/20260522_math/tools/latex_compile_papers.sh \
     <project>/paper_submission

脚本约定 / 行为：

• 找到 <paper_submission_dir>/paperN_*/main.tex（Template 3 的标准布局）
• 跑两遍 pdflatex -interaction=nonstopmode（让 \ref / \cite 收敛）
• 每篇报告 size · pages · pdf path
• 失败时打印 main.log 末 10 行（最常见原因：缺 CTAN 包，跑一次 latex_install_packages.sh 即可）
• 退出码：全部成功 = 0，否则非零

main thread 在 Stage 5 的责任：

1. 跑脚本，捕获输出。
2. 把"成功 N 篇 / 失败 M 篇"和每篇页数追加到 Stage 4 的五色状态表（多一列 📄 pages）。
3. 失败篇分流：读 main.log 末段，判断属于哪类：
   • (a) 缺 CTAN 包 → 提示用户跑一次 latex_install_packages.sh，再重跑 latex_compile_papers.sh。不起任何 agent。
   • (b) writer 写出真正的 LaTeX 错误（缺 \end{...}、未定义命令、math mode 错配等）→ main thread 新起一个 reviewer-fixup agent（见下方 prompt）。注意：原 reviewer agent 在 Stage 3 已 return 退出，无法 resume；这里是独立的新 agent，只拿 main.tex 路径 + log 末段作为输入，不继承 Stage 3 reviewer 的上下文。
4. 不要让 writer/reviewer agent 自己编译——它们的 sandbox 里没有 TeX 引擎，只会浪费 token。编译一律由 main thread 调脚本完成。

Reviewer-fixup agent prompt（仅在 Stage 5 失败时启动）

你是一位 LaTeX 排版工程师。任务：修一份编译失败的手稿，使其能通过 pdflatex。

【手稿】<project>/paper_submission/paper<K>_<slug>/main.tex
【编译日志末段】
<贴入 main.log 末 30 行>

【你的工作】
1. Read 整份 main.tex
2. 根据 log 定位编译错误（缺 \end{...}、未定义环境、math mode 嵌套错、
   非法字符、未导入的宏包等）
3. 用 Edit 工具就地修 main.tex
4. **绝不**修改数学内容、定理陈述、证明逻辑、引用文献。只修排版 / 编译错误。
   若发现 log 显示的错误根源是数学内容（如错误的 \frac 嵌套且无法机械修复），
   写一行注释 "% [stage5 fixup] math content issue at L<NN>, escalating"，
   不动那一段，由人工介入。
5. 用 ≤100 字汇报：改了哪几处（行号 + 错误类型），是否完全修好。

【硬约束】
- 不要重新组织段落、不要改章节标题、不要改 thebibliography 条目
- 不要碰 §Numerical 节的数值
- 不写 README，不写新文件

失败回灌循环的硬上限

• 每篇 paper 最多 2 轮 fixup。第 2 轮仍失败 → main thread 写 [stage5.escalate] 进 decision_log.md，停止自动 loop，把 main.log 末段 + 已尝试 fixup 的列表给用户人工介入。
• 这个上限防止 fixup agent 在数学内容相关的编译错误上反复无效尝试，也防止两轮 fixup 累计花费失控。
• 跑完 fixup 后必须立即重跑 latex_compile_papers.sh 验证——只看 agent 自报"修好了"不算数，编译退出码 = 0 才算。

注：脚本用的是 macOS BasicTeX 路径（/Library/TeX/texbin/），文档见 tools/latex_setup.md。Linux 上把 path_helper 那段删了 / 用 texlive-full 即可。

输出目录约定

<project>/paper_submission/
  paper1_<slug>/
    main.tex                    # writer + reviewer 双轮编辑
  paper2_<slug>/
    main.tex
  ...
  decision_log.md               # 可选实时账本
  REVIEW_REPORTS.md             # 可选：把 N 份 reviewer report 拼起来

不要写：README.md（项目已有顶层笔记）；单独的 refs.bib（self-contained thebibliography 即可）；编译产物（.pdf / .aux / .log）——这些是 Stage 5 main thread 调脚本生成的，writer/reviewer agent 不要碰。

实战 lessons（Legendre P4 → 5 papers 的复盘）

1. 数值哨兵必须前置。Template 2 笔记里 §4 数值表的 $|I_f|$ 列其实有归一化不一致，但"every f passes"的核心结论是对的。Stage 1 跑一遍 sympy 直接确认了哪部分可信。
2. writer agent 的"诚实"约束是关键。第一次跑时几乎所有 writer 都倾向把"研究笔记里的想法"写成"定理"。brief 里写死"诚实大于野心" 后，Paper 2、3 主动降为 conditional，Paper 4 也老实标了 heuristic。
3. reviewer agent 必须 Edit in place。如果只让 reviewer 出 critique，writer agent 不会主动改。Edit 工具权限要先给好。
4. 5 篇里"红"那一篇恰好是研究笔记里最具"启发性新发现"的方向。研究笔记的"亮点"往往是 sketch 而非证明，写成正式 paper 时细节会崩——这是预期内的，不是失败。
5. 不要让 writer / reviewer agent 自己跑"compile and verify PDF"。它们的 sandbox 里没有 TeX 引擎，会浪费 token。Stage 5 由 main thread 直接调 tools/latex_compile_papers.sh 批量编译，失败再回灌给 reviewer 补 Edit。
6. paper4_ss_gap 类的"短 paper"应单独走。318 行短稿和 800 行主稿用同一份 brief 不公平——短稿应有更紧的篇幅约束 + 更窄的主定理。

风险与局限

• writer 倾向 over-claim：必须在 brief 里硬性要求 "honest about conditional vs unconditional"。Sonnet 默认乐观。
• reviewer 可能错过形式正确但实质平凡的引理（如 paper 4 的 Lemma 3：η 在 monic 上恒为 1）。reviewer brief 里要列出"特别审视点"。
• N > 5 时 main thread 上下文紧张。建议分批（每批 ≤ 5）。
• reviewer 修改后不会重跑 writer。如果 reviewer 删了大块内容，论文结构可能变得不平衡。Stage 4 应人工通读每份 reviewer report。
• 审稿"通过 ≠ 真的发得了"：reviewer agent 不是真期刊编辑。3 绿稿真投出去仍可能被 desk reject。本流程把论文从"能不能写"提升到"该投哪里"，不是从"完美"提升到"录用"。

何时该用，何时不该用

用：

• Template 2 已输出含"关键发现 + 可发 paper 方向"明确清单的笔记。
• 想一次性把所有方向跑成草稿（避免后续逐个手写时遗漏）。
• 重视审稿环节给出的"哪些方向其实不该投"——这经常是最有价值的产出。

不用：

• 只有一个方向想写 → 直接手写或单个 writer agent 即可。
• 笔记尚未确定主定理 → 退回 Template 2 把 L5 决策走完。
• 已有完整 LaTeX 草稿想审稿 → 只起 Stage 3 reviewer 部分。

Stage 4 汇总表（Legendre P4 实例）

3 绿 / 2 黄 / 1 红的混合结果是健康的。如果 5 篇全是绿，几乎一定是审稿 agent 偷懒。