paper-parallel-audit

name	paper-parallel-audit
description	在执行 ≥ 30 条目的批量核查 / 批量修改任务（引用核查、术语一致性检查、格式统一、文献元数据补齐）时， 必须采用"派多个 Agent 并行 + 每个 Agent 输出 JSON + 主进程汇总落盘 + 分批断点续跑"的标准模式， 不得在主会话里串行单线程跑全量。 Use when 任务规模 ≥ 30，涉及对独立条目的同质操作（每个条目处理逻辑相同、之间无依赖）。

paper-parallel-audit：大批量核查的并行 Agent 模式

核心理念

156 篇引用串行核查 ≈ 5 小时 + 中间挂了从头来。 3 个 Agent 并行 + 每个 50 篇 + JSON 落盘 ≈ 1 小时 + 任意一个挂了只重跑那一个。

批量任务的瓶颈不是 AI 的速度，是"挂了从头来"的恐惧。 并行 + 落盘 = 把恐惧拆成可控的小块。

---

触发条件

满足全部 → 触发：

• 任务规模 ≥ 30（条目 / 引用 / 文件 / 段落）
• 各条目之间无依赖（核查 A 的结论不影响 B 的核查）
• 操作是同质的（每条用的方法 / 标准都一样）
• 已经通过 paper-pilot-before-batch 跑过样本，逻辑确认无误

任意一条不满足 → 不并行，老老实实串行 + 落盘（仍然要落盘）。

---

标准模式（4 个组件，缺一不可）

组件 1：分片

total = 156 条
shard_size = 50（按 Agent 数倒推）
shards = [0:50, 50:100, 100:156]

组件 2：每个 Agent 独立输出 JSON

每个 Agent 处理自己的分片，输出：

{
  "shard_id": "0-50",
  "total": 50,
  "results": [
    {"item_id": 1, "status": "pass", "issue": null},
    {"item_id": 2, "status": "fail", "issue": "作者名拼写错误", "suggestion": "..."}
  ],
  "completed_at": "<ISO 8601 timestamp>"
}

组件 3：主进程汇总 + 落盘

# 等所有 Agent 返回后
python merge_shards.py shard-*.json > audit_report.json

组件 4：断点续跑

• 每个 Agent 跑完立即落盘 JSON 到磁盘
• 任何一个挂了，只重跑那个分片
• 主进程读已有 JSON，跳过已完成

---

强制流程

检测到 ≥ 30 条目的同质批量任务
        │
        ▼
确认已经跑过 paper-pilot-before-batch
        │
        ▼
分片：N 个 Agent，每个 ≤ 50 条
        │
        ▼
告诉用户：「派 N 个 Agent 并行，每个负责 [区间]，
各自落盘 JSON。预计 [时间]，挂了只重跑挂掉的分片。」
        │
        ▼
用 Task 工具派 Agent（subagent_type 选 general-purpose）
单条消息里多个 Task 调用 = 真正并行
        │
        ▼
等所有 Agent 返回 → 汇总 JSON → 给用户报告

---

派 Agent 的标准 prompt 模板

你是引用核查 Agent，负责本批 [分片区间]。

任务：核查每条引用的 [核查标准列表]。
输入：[引用列表 / 文件路径]
输出：JSON 文件，路径 `shard-<分片 ID>.json`，格式：
  {
    "shard_id": "...",
    "total": N,
    "results": [
      {"item_id": ..., "status": "pass|fail", "issue": "...", "suggestion": "..."}
    ],
    "completed_at": "..."
  }

完成后只返回一句话：「分片 X 完成，pass M 条，fail K 条，已落盘 shard-X.json」。
不要把详细结果写在回复里——一律只在 JSON 里。

---

❌ 反例（书 §10.2）

用户：「把这 156 条引用核查一遍。」

错误做法：在主会话里串行跑——

• 跑到第 80 条 rate limit 了
• claude --continue 接续，但中间结果在内存里没存
• 重跑要么从头来，要么人工记到第几条
• 用户的耐心已经磨没了

正确做法：分 3 片 → 派 3 个 Agent → 各自 JSON 落盘 → 主进程汇总 → 用户拿到完整报告。

---

"不要并行" 的情况

• 条目之间有依赖（B 用 A 的结论）→ 串行 + 落盘
• 任务规模 < 30 → 直接串行更省心
• 操作不同质（每条要不同处理）→ 一个 Agent 全包

---

Rationalization Table

念头	现实
"派 Agent 太重，自己串行更直接"	串行第 80 条挂掉时你会回来读这个表
"我能边跑边把结果记在脑子里"	你不能。这是惨案 9 的根因
"JSON 太麻烦，纯文本 markdown 就行"	汇总时要 dedupe / 排序 / filter，markdown 干不了
"派 1 个 Agent 跑 156 条也是并行"	不是，那只是把串行搬到了子进程里，还是从头来
"落盘的 JSON 占空间"	一个 shard JSON 几 KB，挂了能省小时级时间

---

Red Flags

• 你正打算 for 循环 156 次 Edit → 停
• 你想"主会话直接核查，写个 todo 记进度" → todo 不是落盘
• 你跑到第 N 条挂了，想凭记忆接着第 N+1 条 → 不行，从最近一次落盘点重启
• 多个 Task 调用分散在多条消息里 → 不是并行，重写成单消息多调用

---

配套 skill

• 触发前必须先 paper-pilot-before-batch
• 修改性操作还要 paper-protect-terminology
• 完成后用 paper-verify-before-handoff 自查报告

---

来源

《Claude Code 科研手记》§4.2「批量文献核查」、§10.2「引用核查的并行实战」