PaperSpine 评审协议设计溯源：上游吸收矩阵、洁净室边界与可审计出处

导读

src/skill/references/upstream-review-protocols.md 是 PaperSpine5 评审管线的一份"设计出处"文档：它公开声明项目的通用评审协议来自四个 MIT 许可的上游开源项目，并逐一记录其被检视的 commit、吸收的协议内容与刻意保留的边界，形成一张可审计的吸收矩阵。本文以该文档为主体，结合仓库内控制性契约 evidence-grounded-review.md、角色注册表 reviewer-persona-registry.json、实现脚本 evidence_grounded_review.py 与下游消费方 reviewer-audit.md，讲解这张矩阵每一行的技术含义、它在当前评审协议中的实际控制位置，以及读者如何据此进行协议来源/许可审计。

这份文档在 PaperSpine 评审体系中的位置

PaperSpine5 的核心承诺是 local-first（本地优先）与 evidence-bound（证据绑定）：AI 评审输出只能作为作者侧的决策支持，任何可行动的评审意见都必须携带精确的手稿定位、评审者回执、工具回执与处置建议。在这样的体系里，评审协议的"出身"同样需要被记录——它来自哪些项目、吸收了哪些设计、在哪些地方刻意没有照搬。

upstream-review-protocols.md 回答的就是这三个问题。它声明了两条硬约束：

• 洁净室（clean-room）再实现：PaperSpine 对上游协议做的是"供应商中立、与具体实现无关"的重新实现，不引入任何运行时依赖，也不复制上游源码；
• 出处可审计（auditable）：上游被检视的 commit 与许可证被固定记录，任何人可以复核设计来源。

从仓库结构看，这份文档被两个路由/清单类文件正式登记：在 current-method-routing.json 的方法路由条目中，它被标注为"仅协议来源/许可审计时核上游固定提交与 license/源码"的参考材料；在 suite-map.md 的方法清单表中，它被描述为"inspected upstream commits/licenses and the clean-room protocol absorption matrix"。也就是说，它不是日常写作流程的启动门槛，而是一份按需查阅的出处审计文档（详见下文"仓库中的引用与当前应用"）。

完整吸收矩阵：四个上游项目与四类保留边界

原文档的核心是一张五列吸收矩阵（Upstream / Inspected commit / License / Protocol absorbed / Boundary retained）。以下完整继承该表，并对每一行做展开讲解：

Upstream	Inspected commit	License	Protocol absorbed（吸收的协议）	Boundary retained（刻意保留的边界）
Agentic Paper Review	c117aba2dbb26fece9ab2de12b84c1874fa63e6f	MIT	Specialist/editor 分离、可选的 librarian/fact-checker/critic、冲突 Judge、criterion evidence	人类保留 accept/reject 最终权；加权分数不覆盖 PaperSpine 的 truth gates
Open ScholarPeer	c93d344cd40017b7c406d9e410c04805e6c2c644	MIT	Problem/method/time 检索轮次、historian 与 baseline-scout 通道、可审计工件	不假定供应商能力；PaperSpine 记录真实 provider 状态，封闭语料运行保持封闭
DeepReviewer 2.0	1c19a232c0620b0f24e56d5965258dde00a702ae	MIT	主动式 PDF locate/annotate/search 工具循环、事件回执、用量核算	不照搬固定调用次数配额；改用基于风险的预算上限与证据目标
AI Paper Review	f2f72a912b3a1a23b92165382cbedf332a7b92a6	MIT	可替换 persona、重复聚类、AI-人类 hit/miss/false-alarm 校准、跨论文推荐	词汇对齐标注为启发式；校准不能静默改写注册表

逐行来看，这四个上游项目分别贡献了评审管线中不同层面的设计：

1. Agentic Paper Review 贡献了"专职评审人与主编分离"的骨架：独立评审人负责各自的证据带，Editor 负责综合；可选增加 librarian/fact-checker/critic 通道，并在独立评审或模型之间出现实质冲突时引入 Judge。这一设计直接体现为 evidence-grounded-review.md 中的保守角色选择规则与 reviewer-persona-registry.json 中的触发式角色激活。边界在于：加权分数只是作者侧决策支持，不能越过 truth gates 代行人类接收/拒绝权。
2. Open ScholarPeer 贡献了文献检索的操作结构：problem（问题）、method（方法）、time（时间）三类查询轮次，以及 historian（历史脉络重建）与 baseline-scout（最近基线/数据集/评测缺口搜索）两条通道，同时强调可审计的检索工件（provider、query、时间、结果数、标识符等）。边界在于：不假定任何文献供应商一定可用，provider_failure 被明确定义为"降级覆盖"而非"无相关文献"；封闭语料（closed corpus）场景下不引入任何外部检索。
3. DeepReviewer 2.0 贡献了"主动工具循环"：评审过程可以主动定位 PDF 页、做注释、发起检索，每次工具调用都产生事件回执并计入用量。边界在于：不复制其固定调用次数配额，PaperSpine 改用"预算上限是天花板、不是配额"的风险导向模型（详见下文预算表）。
4. AI Paper Review 贡献了可替换 persona、重复意见聚类、AI 与人类评审的命中/漏检/误报校准，以及跨论文的建议聚合。边界在于：词汇级对齐只是保守的启发式标签，必须由人类确认，不能被描述为语义级验证；校准过程永不修改 persona 注册表。

原文档同时固定了被检视的仓库来源与检视日期（2026-08-26），并声明了最终裁定规则：PaperSpine 的控制性契约是 evidence-grounded-review.md，而不是任何上游 README 或实现细节。这意味着上表的吸收矩阵只说明"设计灵感从何而来"，当前管线实际执行的是哪套规则，以仓库内契约与实现脚本为准。

"洁净室"与"供应商中立"的工程含义

原文档把自身定位为"clean-room, provider-neutral reimplementation"。结合实现脚本可以更精确地理解这两个词：

• 洁净室意味着吸收的是"协议/流程/规则"，不是"代码"。实现层 evidence_grounded_review.py 的文件头注释明确写道：The LLM or human reviewer writes the review; this module enforces traceability. It deliberately contains no provider SDK and never treats a failed search as a negative result.（LLM 或人类评审者负责撰写评审，本模块负责强制可追溯性；它刻意不包含任何供应商 SDK，也绝不把失败的检索当作否定性结果）。"不含供应商 SDK"正是"无运行时依赖、无复制源码"在代码层的落实。
• 供应商中立体现在状态机与遥测纪律上：脚本把所有外部检索结果显式划分为 verified / retrieved / partial / no_hit / provider_failure / not_started 六种状态，其中 provider_failure 必须附带 error 细节（校验逻辑见 evidence_grounded_review.py 第 228-229 行与第 444-445 行），且 no_hit 必须记录 result_count=0。这样无论未来接哪家检索供应商，评审协议本身不需要改动。

控制性契约：evidence-grounded-review 的四链证据规则

既然上表说明"控制性契约是 evidence-grounded-review.md"，就必须展开这份契约。它的核心规则是一条"四链"约束：每一个可行动的评审发现（finding）必须同时携带以下四项：

1. 精确的手稿定位（页/行/段/图/表/公式或附录坐标）+ 一段简短手稿引用；若某条主张需要"内容缺失"作为证据，则要提供穷尽式缺席扫描回执；
2. 提出该发现的评审人/persona 以及该轮评审回执；
3. 达成该发现所用的读/搜/注释工具回执，含实测 token 与墙钟时间（当宿主暴露遥测时）；
4. 具体的建议、置信度、严重级别与处置（disposition）。

契约还规定："无定位的意见只是 advisory note，不是科学/编辑阻塞项"，且"打包、编译等技术性 PASS 状态永远不能补偿未解决的、已定位的科学阻塞项"。

从实现看，机器契约由 contracts/evidence-review.schema.json 定义，语义校验由 scripts/evidence_grounded_review.py 执行。脚本中定义了全套受控枚举，与四链规则一一对应：

• SEVERITIES = {"CRITICAL", "MAJOR", "MINOR", "OBSERVATION"}；
• DISPOSITIONS = {"open", "resolved", "advisory", "dismissed", "needs_author"}；
• TOOL_STATUSES = {"completed", "partial", "no_hit", "provider_failure", "not_started"}；
• PRECISE_LOCATOR_RE 同时支持英文（page/p./lines/fig/table/eq/appendix/supp）与中文（页/行/段/图/表/附录）定位写法，强制"发现必须有精确坐标"；
• 工具回执校验要求 action、receipt_id 唯一、paper_search 必须带 query 与 provider，pdf_locate/pdf_annotate/manuscript_read 必须带 target_locator。

保守的角色选择：persona 注册表与触发机制

原文档吸收矩阵提到"Specialist/editor 分离"与"可替换 persona"，其在当前仓库的落地是 reviewer-persona-registry.json —— 一个 selection_policy = "triggered-minimum-set"、automatic_mutation = false 的可替换注册表，而不是每次必跑的角色清单。注册表登记的 10 个 persona 及激活条件如下：

persona_id	role	activation（激活条件）	cost_class	job（职责摘要）
editor	editor	always	medium	综合已定位发现、保留分歧、决定修订顺序，不虚构证据
methods	methods	strict	medium	审计技术正确性、可复现性、假设、统计、实验与局限
contribution	contribution	strict	medium	审计贡献边界、显著性、差异化与证据-主张强度
clarity	clarity	strict	medium	审计论证流、读者负担、图/表使用、图注与面向期刊的清晰度
literature	literature	open_literature	high	围绕 problem/method/近期时间邻域执行可审计的实时检索
historian	historian	historical_context	medium	重建研究轨迹，区分持久血统与近期潮流
baseline_scout	baseline_scout	baseline_trigger	high	对抗式搜索缺失的近期基线、数据集与评测协议
fact_checker	fact_checker	claim_trigger	medium	核验可疑的 first/best/general/causal 主张并记录证据
critic	critic	cross_lane_findings	medium	连接手稿、文献与事实三个证据带，同时保留各带边界
judge	judge	review_conflict	medium	依据回执裁决独立评审/模型间的实质冲突，绝不替代人类接收权

契约 evidence-grounded-review.md 给出了保守选择的具体策略：

• balanced：仅一位 Editor 读手稿与渲染稿，只有出现具体风险才追加专职评审人；
• strict：Methods、Contribution、Clarity 独立评审，然后 Editor 综合；
• open_literature：激活 Literature；只有出现真实的"历史/轨迹"问题才激活 Historian，只有出现"最近基线/数据集/评测缺口"问题才激活 Baseline Scout；在声明为 closed corpus 的场景下，这三者一律不得添加；
• Fact Checker 只针对可疑的 first/best/general/causal 主张激活；
• Critic 只在手稿、文献、事实三个证据带必须被连接时激活；Judge 只在独立评审或模型间出现实质冲突时激活。

这一策略在实现脚本 evidence_grounded_review.py 的 build_review_plan()（第 118-184 行）中体现为关键词触发：配置的 special_requirements 中出现 first/best/state-of-the-art/general/novel（或中文 首次/最佳/普适/新颖）即触发 claim_trigger；出现 history/trajectory/lineage/历史/脉络/演进 触发 historical_context；出现 baseline/baseline/benchmark/closest work/基线/最近工作 触发 baseline_trigger。

预算上限与遥测纪律：不照搬固定配额

吸收矩阵中"DeepReviewer 2.0 的固定调用次数配额未被复制"这一点，在 build_review_plan() 的默认预算表中有直接体现：

预算项	balanced（默认）	strict
max_input_tokens	30,000	90,000
max_output_tokens	10,000	30,000
max_wall_seconds	1,200	3,600
max_search_queries	8	20
max_pdf_annotations	12	30

关键语义：预算是一个天花板（ceiling），不是配额（quota）。契约要求"覆盖问题得到回答就停止"，不为了凑足评审人/检索/注释的数量而消耗 token；每个工具回执记录实测用量而非估算值，宿主不暴露遥测时写 telemetry_status=unavailable，绝不把未知量编码成实测的 0。校验逻辑（第 238-247 行）强制 telemetry_status 只能是 measured 或 unavailable，并在 unavailable 时累计 telemetry_unavailable_count 并给出警告"zero values are not measured cost"。评审计划生成命令为：

python scripts/evidence_grounded_review.py plan paper_rewriting_output \
  --manuscript paper_rewriting_output/final_paper/main.tex

该命令会把计划写入 paper_rewriting_output/review_prompts/review_plan.json，其中包含手稿路径与 SHA-256 哈希绑定、选中的 persona 列表、条件 persona 列表、预算上限与停止规则。

证据通道与搜索状态语义

契约要求把评审证据严格分成三条通道，避免跨带污染：

• paper-original evidence：手稿实际写了什么/展示了什么；
• project evidence：论文自有的数据、代码、台账支持；
• external literature：为新颖性、基线、历史或事实定位而检索的外部论文。

文献检索必须使用显式状态：not_started、partial、retrieved/verified、no_hit、provider_failure。三条语义红线值得强调（均与上游矩阵的边界列一致）：

1. provider_failure 是降级覆盖：它只说明检索没做成，绝不等于"不存在相关工作"；
2. 零结果查询只是一张检索回执，不是"无先前工作"的证明；
3. 没有检索到外部证据时，novelty/positioning/baseline/historical 类发现不能定级为 CRITICAL/MAJOR。

开放文献允许时，按 problem/method/time 三轮查询推进，并持久化 provider、query、时间、结果数、标识符与失败细节。

合成与聚类：共识提升优先级，但高严重级发现不可被埋没

契约对"重复发现聚类"设定了两条保护性规则：聚类只为了阅读效率，必须保留每个源发现 ID 与评审回执；任何唯一的、已定位的高严重级发现，即使大多数评审人都没提，也不得删除。共识可以提高优先级，而分歧必须对 Editor 或条件触发的 Judge 可见。合成状态上：只要还有任何 CRITICAL/MAJOR 发现处于 open 或 needs_author，PASS 就是无效的；BLOCKED 必须点名阻塞它的发现 ID。评审合成前的校验命令为：

python scripts/evidence_grounded_review.py validate \
  paper_rewriting_output/evidence_review.json \
  --manuscript paper_rewriting_output/final_paper/main.tex \
  --markdown --write

人类评审校准：命中/漏检/误报，且不篡改注册表

吸收矩阵中"AI Paper Review 的 hit/miss/false-alarm 校准"在契约中对应 calibrate 子命令：

python scripts/evidence_grounded_review.py calibrate ai_review.json human_review.json \
  --output calibration_delta.json

实现要点（脚本第 535 行 calibrate_reviews，默认阈值 0.45）：优先采用显式的人类→AI 发现链接；确定性的词汇级回退匹配是保守的，所有推断对齐都标记为"需要人类确认"，不得被描述为已验证的语义匹配。校准报告覆盖覆盖率、漏检、误报、按严重级加权的召回、persona 噪声、选择失败与提示失败，并且永不修改 persona 注册表。跨论文的重复建议用 aggregate --min-support 2 聚合，之后要求留出集评估与显式采纳（对 PaperSpine 自身规则使用 SkillOpt-Sleep 流程）。

下游消费：reviewer-audit.md 的三视图

吸收矩阵的最终服务对象是评审管线的"评审人视角审计"产物 reviewer-audit.md：它要求以决定论文命运的人——评审人与责任编辑——的眼睛重读同一份手稿，在投稿前把评审人将要提出的具体反对意见逐条列出，并为每条附上预防性修复。该审计由三个视图组成，均可共享既有评审笔记：

1. Reviewer Value Map（评审人价值图）——每个评审准则能买到什么、当前手稿在该准则上哪里薄弱。模板覆盖 Novelty、Significance、Technical soundness、Evidence sufficiency、Clarity、Venue fit 六个轴向，每行要求"评审人/编辑想要什么、我们已有的手稿证据、当前弱点、一个修订动作"，例如 Novelty 行给出的动作是"在引言与摘要中加一句可被评审人引用的 Unlike [closest work], we …"。
2. Reviewer Objection Register（评审人反对意见登记表）——评审人可能做出的具体攻击，用他们的语气写出，每条配预防性修复与可关闭的状态。严重级别采用与 structured_review 相同的刻度（CRITICAL / MAJOR / MINOR，代码中定义于 structured_review.py 的 ReviewFinding.severity 与 evidence_grounded_review.py 的 SEVERITIES）。每条登记行必须追溯到发现 ID、精确定位、评审人/persona 与回执（模板示例即 CON-001 … contribution / receipt-contribution 的形式，与测试契约中 receipt-{role} 的命名一致）。
3. Editorial Fit Map（编辑适配图）——面向编辑的视图：目标期刊契合度、desk-reject 风险、编辑为何值得把这篇送外审，把拒稿风险显式化。

角色映射保持直接：Methods & Reproducibility 评审人对技术健全性、证据充分性、可复现性、缺失的消融/基线提出异议；Contribution 评审人对新颖性、显著性、与先前工作的差异化、引用可信度提出异议；Clarity 评审人对结构、含糊主张、图/表可读性与期刊惯例违背提出异议。输出位置为 paper_rewriting_output/reviewer_audit.md。值得注意的边界：文献供应商故障不能变成新颖性反对意见，只能保留为降级覆盖的咨询性证据；零反对意见的审计在记录了"查了什么、为何无行动项"时是有效的，绝不为了填满行数而虚构反对意见。

仓库中的引用与当前应用：何时查阅本文档

本溯源文档的"当前应用"在 current-method-routing.json 中有明确登记（对应条目原文大意）：

正常 review 可用相应方法；仅协议来源/许可审计时核上游固定提交与 license/源码。当前来源未验证如实标未知，不添加运行依赖。原封装对应范围：commit/license/clean-room 为需独立证据的历史主张，不作科研完成前提。

这给出两个明确的适用前提：

• 日常评审流程：不把本表当作启动门槛——上游 commit、license、clean-room 属性属于"需要独立证据的历史主张"，不影响当前论文写作的科研完成度；
• 协议来源/许可审计：当需要审计评审协议的出处与许可证合规时，本表是唯一权威入口，按其固定的 commit 与 MIT license 记录核验上游，且仓库当前实现不引入任何上游运行时依赖。

源码与测试中的印证

上述全部语义并非仅存在于 Markdown 契约，而是被实现与测试锁定：

• evidence_grounded_review.py：全部状态枚举、预算默认值、触发词、回执校验与校准逻辑所在；模块注释明确"contains no provider SDK and never treats a failed search as a negative result"；
• contracts/evidence-review.schema.json：机器可校验的 evidence review 契约；
• reviewer-persona-registry.json：触发式最小角色集注册表；
• tests/test_evidence_grounded_review.py：构造严格的、哈希绑定且有成本核算的契约样本（methods/contribution/clarity 三份回执 + MET-001 发现），验证 validate_contract、build_review_plan、write_review_plan、calibrate_reviews、aggregate_calibrations 的行为，例如 test_valid_strict_contract_is_hash_bound_and_costed 检验手稿 SHA-256 绑定与用量记录；
• structured_review.py：ReviewFinding.severity（CRITICAL | MAJOR | MINOR | OBSERVATION）与 ReviewerPersona 等评审数据结构的实现，供 reviewer-audit 的严重级别刻度引用。

结语

upstream-review-protocols.md 篇幅不长，却是一份精确的"设计出处契约"：它把四个 MIT 上游项目的被检视 commit、吸收协议与保留边界固定成表，并把最终裁定权交给仓库内的 evidence-grounded-review.md。对于想审计 PaperSpine 评审协议来源、许可证合规性或"哪些设计被刻意没有照搬"的开发者，这张吸收矩阵加上角色注册表、预算表与状态语义，构成了一套完整、可核验的出处与边界证据链；对于日常使用者，记住一句即可——协议可以吸收，边界必须保留，控制性契约始终在仓库内部。