PaperSpine 上游评审协议溯源：洁净室实现、许可边界与证据化评审契约解析

PaperSpine 的独立评审能力并非凭空设计，而是基于四个 MIT 许可的开源评审项目，以"洁净室（clean-room）"方式重新实现通用评审协议，并通过固定 commit 与许可记录保证设计来源可审计。本文从 dist/openclaw/skills/paper-spine/references/upstream-review-protocols.md 出发，逐项拆解四张"吸收/边界"矩阵，并对照仓库中的受控契约、JSON Schema 与 Python 实现，说明这些上游思想如何在 PaperSpine 中落地为可验证的机器契约。读完本文，你将理解 PaperSpine 评审功能的设计来源、许可合规策略，以及"只借鉴协议、不复制实现、不让上游覆盖自身契约"的边界控制方法。

一、文档定位：一份"设计来源审计清单"

upstream-review-protocols.md 在 PaperSpine 技能体系中扮演一个特殊角色：它不定义评审怎么跑，而是回答"评审协议从哪里来、借了什么、边界划在哪里"。它在 套件地图 中被登记为：

inspected upstream commits/licenses and the clean-room protocol absorption matrix（被检视的上游 commit/许可与洁净室协议吸收矩阵）

同时被 当前方法路由索引 收录为可路由资源。这份文档在四个宿主适配器的分发目录中各有一份等价副本（dist/claude/skills/paper-spine/references/upstream-review-protocols.md、dist/codex/...、dist/hermes/skills/academic-writing/paper-spine/...、dist/openclaw/...），说明它随 Skill 一起打包分发，是各宿主安装包中固定的合规说明文件。

文档开篇即给出三条总原则：

1. 洁净室重实现：PaperSpine 对从上游学到的通用评审协议进行"与提供商无关（provider-neutral）"的重新实现；
2. 零运行时依赖：不引入任何上游项目的运行时依赖，不复制上游源码；
3. 可审计溯源：通过固定被检视 commit 与许可证，让设计出处可以被审计。

二、上游协议吸收矩阵：四张表逐项解读

原文档的核心是一张五列表：Upstream | Inspected commit | License | Protocol absorbed | Boundary retained。以下完整继承该表，并在每行后补充源码层验证：

上游项目	被检视 commit	许可证	吸收的协议	保留的边界
Agentic Paper Review	c117aba2dbb26fece9ab2de12b84c1874fa63e6f	MIT	专家/编辑分离、可选 librarian/fact-checker/critic、冲突 Judge、准则证据（criterion evidence）	人类保留接受/拒绝权限；加权分数不得覆盖 PaperSpine 的 truth gates
Open ScholarPeer	c93d344cd40017b7c406d9e410c04805e6c2c644	MIT	problem/method/time 检索轮次、historian 与 baseline-scout 通道、可审计工件	不假设提供商一定可用；PaperSpine 记录实际提供商状态，并保持封闭语料库运行处于封闭状态
DeepReviewer 2.0	1c19a232c0620b0f24e56d5965258dde00a702ae	MIT	主动式 PDF locate/annotate/search 工具循环、事件收据、用量记账	不复制固定调用次数配额；PaperSpine 采用基于风险的预算上限与证据目标
AI Paper Review	f2f72a912b3a1a23b92165382cbedf332a7b92a6	MIT	可替换人格、重复发现聚类、AI-人类 hit/miss/false-alarm 校准、跨论文推荐	词法对齐仅标记为启发式；校准不得静默改写注册表

四个仓库的检视日期统一记录为 2026-08-26。注意：外部仓库 URL 仅存在于原文档中，本文按溯源信息列出项目名与 commit 哈希，不展开外部链接。

2.1 Agentic Paper Review：人格分离与冲突裁决

吸收要点是"专家/编辑分离 + 可选辅助角色 + 冲突 Judge + 准则证据"。对应到 PaperSpine 的实现，评审人格注册表 中恰好呈现同一结构：

• editor（activation 恒为 always）：综合已落地的发现、保留分歧、决定修订顺序——对应"编辑"角色；
• methods / contribution / clarity：仅在 strict 政策下激活的独立专家；
• fact_checker（claim_trigger）：对应上游的可选 fact-checker；
• critic（cross_lane_findings）：跨手稿/文献/事实通道整合；
• judge（review_conflict）：只在独立评审或模型间出现实质性冲突时介入。

边界"加权分数不得覆盖 PaperSpine 的 truth gates"在代码中体现为：评审输出本质是"带定位证据的发现（findings）"，而非一个可覆盖其他闸门的总分。见 evidence-grounded-review.md 的受控规则——"Packaging, compilation, or other technical PASS states never compensate for a grounded unresolved scientific blocker"（打包、编译或其他技术性 PASS 状态，永远不能补偿一个未解决的、有证据支撑的科学阻塞项）。

2.2 Open ScholarPeer：检索轮次与历史/基线通道

吸收要点是"problem/method/time 三类检索轮次、historian 与 baseline-scout 通道、可审计工件"。对应实现：

• 检索轮次：在 evidence-grounded-review.md 中被明确为"当允许开放文献时，使用 problem、method 与 temporal（时间）三类查询轮次"，并要求持久化 provider、query、日期时间、结果数、标识符与失败详情；
• historian 与 baseline-scout：注册表中 historian（historical_context）与 baseline_scout（baseline_trigger）两个人格，且明确"在声明为封闭语料库（closed corpus）的任务中不得加入二者"；
• 边界"不假设提供商可用"：文献工具状态被区分为 not_started、partial、retrieved/verified、no_hit、provider_failure，且"provider failure 是降级覆盖，绝不是无命中证据"。

2.3 DeepReviewer 2.0：PDF 工具循环与用量记账

吸收要点是"主动式 PDF locate/annotate/search 工具循环、事件收据、用量会计"。对应实现：

• 工具收据（tool receipts）：evidence-review.schema.json 中 toolReceipt 定义要求每条收据记录 action、status、usage（input_tokens / output_tokens / wall_seconds），覆盖 pdf_locate、pdf_annotate、paper_search、manuscript_read 等动作；
• 边界"不复制固定调用次数配额"：改为风险导向的预算上限。实现见 evidence_grounded_review.py 中 build_review_plan 的默认预算——balanced 政策为 30,000 输入 token / 10,000 输出 token / 1,200 秒 / 8 次检索 / 12 次 PDF 标注；strict 为 90,000 / 30,000 / 3,600 秒 / 20 次检索 / 30 次标注。且文档强调"预算是上限，不是配额：覆盖问题被回答就停止，不要为了凑足最小 agent 数、检索数或标注数而消耗 token"。

2.4 AI Paper Review：可替换人格与校准

吸收要点是"可替换人格、重复发现聚类、AI-人类 hit/miss/false-alarm 校准、跨论文推荐"。对应实现：

• 注册表 automatic_mutation: false 且 selection_policy: triggered-minimum-set，即人格按触发条件选择最小集合、不可被自动改写；
• 校准：calibrate 子命令计算 n_hits、n_misses、n_false_alarms、precision/recall/F1 与严重度加权召回；词法回退（lexical fallback）默认阈值 0.45，且每条词法对齐都标记 requires_human_confirmation: true——这正是边界"词法对齐仅标记为启发式"的代码级兑现；
• 跨论文推荐：aggregate 子命令要求 --min-support 2（默认 2）才生成建议，且必须经过 held-out 评估与显式采纳（对应 PaperSpine 规则演进采用 SkillOpt-Sleep 流程），输出恒定 automatic_registry_mutation: False。

三、边界保留策略：学什么、不带走什么

原文档的四条"边界保留"栏共同勾勒出 PaperSpine 的合规与质量底线，可以归纳为四类：

1. 人类权威边界：接受/拒绝权始终在人类手中。代码中 judge 人格的 job 明确写为"从收据裁决实质性评审冲突；绝不取代人类接受权威"；evidence-grounded-review.md 亦声明"AI 评审输出是作者侧的决策支持，不能冒充被指派的同行评审人、不能替代人类编辑决定、不能授权外部投稿行为"。
2. 证据状态边界：提供商故障不是"没有相关文献"的证明；no_hit 必须记录 result_count=0，provider_failure 必须记录错误详情（见 evidence_grounded_review.py 的收据校验分支）。
3. 预算语义边界：固定调用配额被替换为基于风险的预算上限，预算只控制成本与覆盖，不产生机械化的最小工作量。
4. 注册表不可变边界：校准输出建议，但绝不静默改写人格注册表；词法对齐永远需要人工确认。

此外，review-policy.md 补充了运行层面的边界：balanced 与 strict 两种政策只改变过程深度，不改变 truth 标准；评审政策不授予交互权限（回答贡献、动机、图表、目标、投稿等问题仍需用户授权或显式委托）。

四、受控契约：上游实现不能覆盖 PaperSpine 自己的规则

原文档最后一行是全文最重要的结论：

The controlling PaperSpine contract is evidence-grounded-review.md, not any upstream README or implementation detail.（PaperSpine 的受控契约是 evidence-grounded-review.md，而不是任何上游 README 或实现细节。）

这条规则在仓库中有三重落点：

第一层：协议文档。 evidence-grounded-review.md 定义"每条可操作评审发现必须携带四类链接"：精确手稿定位符（页/行/段/图/表/公式/附录坐标 + 简短引文，或对缺失内容的穷尽式缺席扫描收据）、提出该发现的评审人/人格及其评审轮次收据、用于得出该发现的读写/检索/标注工具收据（含实测 token 与墙钟时间）、以及具体的建议、置信度、严重度与处置状态。未定位的观点只能算咨询性备注，不能成为科学/编辑阻塞项。

第二层：机器契约。 evidence-review.schema.json（schema_version 1.0）用 JSON Schema 固定了这份契约的机器可校验形态，顶层必填字段包括 policy（balanced/strict）、literature_scope（closed_corpus/open_literature）、manuscript（path + 小写 SHA-256）、reviewers、findings、tool_receipts、synthesis。其中：

• finding 必填 finding_id、reviewer_id、criterion、severity（CRITICAL/MAJOR/MINOR/OBSERVATION）、recommendation、confidence（0–1）、disposition（open/resolved/advisory/dismissed/needs_author）、paper_evidence、tool_receipt_ids；
• paperEvidence.kind 限定为 quote/figure/table/equation/absence_scan；
• synthesis.status 只能是 PASS 或 BLOCKED，BLOCKED 必须点名 blocker_finding_ids。

第三层：语义执行。 evidence_grounded_review.py 的模块说明直接呼应洁净室立场："LLM 或人类评审者负责写评审，本模块只负责强制可追溯性。它刻意不包含任何提供商 SDK，并且绝不把失败的搜索当作负面结果。"这一句可以看作原文档"零运行时依赖 + 提供商中立"的代码级签名。

五、把矩阵落成命令：plan / validate / calibrate / aggregate

对应用户可实操的入口，evidence_grounded_review.py 提供四个子命令，覆盖"评审规划 → 契约校验 → 人机校准 → 跨论文聚合"的完整闭环：

5.1 生成评审计划与成本上限

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

该命令读取 paper_rewriting_output/paper_spine_config.json 中的 review_policy 与 literature_scope（缺省按 reference_mode=specified_paths 推断为 closed_corpus，否则为 open_literature），按"触发式最小集合"原则选出人格，并把预算上限写入 review_prompts/review_plan.json。触发词从 special_requirements 中识别：

• 声明类触发（claim）：first、best、state-of-the-art、general、novel、首次、最佳、普适、新颖 → 激活 fact_checker；
• 历史类触发（history）：history、historical、trajectory、lineage、脉络、历史、演进 → 激活 historian；
• 基线类触发（baseline）：baseline、benchmark、dataset gap、closest work、基线、数据集、最近工作 → 激活 baseline_scout。

测试 test_evidence_grounded_review.py 的 test_strict_plan_selects_open_literature_lanes_and_cost_ceiling 验证：strict + open_literature + 三类触发词时，选中集合包含 editor、methods、contribution、clarity、literature、historian、baseline_scout、fact_checker，而 judge 不在其中（冲突才触发），且 review_budget.max_search_queries 可被配置覆盖为 7。

5.2 校验证据化评审契约

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

校验器内置精确定位符正则 PRECISE_LOCATOR_RE（支持英文 page N、p. N、lines N、figure N、table N、eq. N、appendix X、supp. X 以及中文 页 N、行 N、段 N、图 N、表 N、附录 X）。关键的语义强制包括：

• 无定位不得通过：定位符缺失或不够精确直接报错（测试 test_unlocated_comment_cannot_pass）；
• provider 故障不能支撑阻塞：open_literature 下，novelty/positioning/baseline/historical_context/citation_coverage 类别的 CRITICAL/MAJOR 发现若无已检索外部证据，判定为"不能硬阻塞"（测试 test_provider_failure_cannot_support_major_novelty_blocker）；
• no_hit 必须零结果：状态为 no_hit 但 result_count != 0 时校验失败（测试 test_no_hit_requires_zero_results_and_is_not_provider_failure）；
• 不可用量化零：宿主无用量遥测时写 telemetry_status: unavailable 并计入告警，绝不把未知量编码为实测 0（测试 test_unavailable_telemetry_is_disclosed_not_counted_as_measured）；
• PASS 与未决阻塞冲突即失败：存在 open/needs_author 状态的 CRITICAL/MAJOR 时 PASS 无效；BLOCKED 必须列出阻塞发现 ID。

校验通过后 --markdown --write 会输出 evidence_review_check.md，列出 grounded 发现数、外部证据数、工具收据数、实测 token 与墙钟时间、遥测不可用收据数。该文件与 evidence_review.json 一起构成 strict 模式下审计阶段的可追溯证据链（见 audit.md 的命令清单）。

5.3 人机评审校准

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

校准优先采用显式的人工到 AI 发现链接（matching_ai_ids）；无显式链接时退回到保守的词法对齐（默认阈值 0.45，可用 --threshold 覆盖），且每一条词法对齐都标记 requires_human_confirmation: true，不得描述为"已验证的语义匹配"。输出指标包括覆盖率、miss、false-alarm、严重度加权召回、人格噪声、选择失败与提示失败归因，并生成 strengthen_persona_prompt 或 selection_policy_adjustment 两类建议。测试 test_human_calibration_reports_hits_misses_false_alarms_without_mutation 验证 1 hit / 1 miss / 1 false alarm 的统计与 automatic_registry_mutation: False。

5.4 跨论文聚合与显式采纳

python src/scripts/evidence_grounded_review.py aggregate delta_a.json delta_b.json delta_c.json \
  --min-support 2 --output aggregate.json

聚合仅把支撑论文数达到 min-support（默认 2）的建议提升为推荐，且始终保留"需要 held-out 评估与显式采纳"的注记——这正是对上游"跨论文推荐"思想的边界化落地：推荐可以累积，但规则变更必须由人显式采纳，绝不自动发生。

六、如何核对这份溯源（给审计者与使用者的路径）

如果你想亲自验证本文所述内容，可以按以下顺序在仓库中走查：

1. 阅读受控契约：evidence-grounded-review.md —— 四条发现链接、三种证据通道（paper-original / project / external literature）、五类文献状态、聚合与人工权威；
2. 对照机器契约：evidence-review.schema.json —— 每个字段的枚举与必填约束；
3. 核对语义执行：evidence_grounded_review.py —— build_review_plan（L118-184）、validate_contract（L337-479）、calibrate_reviews（L535-648）、aggregate_calibrations（L651-682）；
4. 查看测试证据：test_evidence_grounded_review.py —— 八条用例覆盖上文提到的全部关键不变量；
5. 查看人格注册表：reviewer-persona-registry.json —— automatic_mutation: false 与 10 个人格的触发条件；
6. 回到源头：upstream-review-protocols.md（即本文主题文档，在 dist/openclaw/ 等分发目录有等价副本）—— 四个被检视项目、四个 commit 哈希、统一检视日期 2026-08-26 与许可证记录。

七、结语：审计友好是一种设计属性

upstream-review-protocols.md 之所以存在，是为了让"借鉴"本身可被审计：固定到 commit 的检视记录、明确的 MIT 许可、逐条的吸收/边界矩阵，以及"受控契约优先于上游实现"的总原则。落到运行时，这套溯源被翻译成了代码中的硬约束——人格按触发选择、检索失败不被误用为证据、词法对齐必须人工确认、校准永不静默改写注册表、PASS 永远无法掩盖未决的科学阻塞。对于在合规敏感环境中部署评审 Agent 的团队，这套"洁净室 + 可审计吸收矩阵"的做法本身，就是一份值得复用的工程模板。