在 Claude Code 生态中，PR 审查工具已有不少选择 —— 内置的 /review、CodeRabbit、Greptile 等。但这些方案大多是单一模型或单一视角的审查逻辑，缺乏对审查意见的聚合、去重与冲突仲裁能力。adamsreview 是一个开源的多智能体协作审查管道，通过六命令生命周期与持久化 JSON 状态，将多 Lens 并行检测、双阶段验证门与自动修复环整合为一套可工程落地的流水线。本文从多 Agent 协作工程的视角，拆解其角色分配、上下文聚合与审查意见仲裁的完整链路。
并行 Lens 子代理架构：六视角并行检测
adamsreview 的核心设计哲学是 “单一模型难以覆盖所有审查维度”。:review 命令的 Phase 1 启动最多七个并行子代理 Lens，每个 Lens 对代码的某个特定维度进行专项检测。这些 Lens 包括正确性（correctness）、安全性（security）、用户体验（UX）、策略合规（policy）、架构设计（architecture）等，组合起来构成对 PR 的多棱镜审视。
这六个 Lens 实际上是六个独立的 Sonnet 子代理实例，在同一 Phase 内并发启动。每个 Lens 接收同一份上下文信息 —— 包括 PR 差异、$claude_md_paths 指向的仓库级指南，以及通过 $prior_fix_suspects 注入的历史修复经验。Lens 的输出被统一格式化为结构化候选发现（candidate findings），进入后续去重阶段。
当使用 --ensemble 标志时，系统还会在 Phase 1.5 额外启动 Codex CLI 作为第七个 Lens，并通过 PR 评论抓取（gh api + bot 过滤器）从外部来源注入额外发现。这使得总检测源达到七个，但所有来源最终汇聚到同一个 Sonnet 归一化管道中处理。
Lens 并行的关键工程挑战在于上下文一致性。由于所有 Lens 读取的是同一时间点的代码快照，必须确保它们不会因为代码在检测期间被其他操作修改而产生不一致的判断。adamsreview 在 Phase 0 的 preflight 阶段通过 reviewed_sha 和 comparison_ref 锁定代码基准，任何 Lens 的输出都与这个锚点绑定。
跨 Agent 上下文聚合：Phase 2–3 的发现合并与评分
六个 Lens 的输出并行完成后，不能直接呈现给用户 —— 必须经过聚合、评分与筛选，才能形成可操作的审查意见。adamsreview 将这个过程拆解为 Phase 2（去重）和 Phase 3（廉价评分与门控）两个阶段。
Phase 2 的去重逻辑由一个 Sonnet 调用完成。这个去重代理接收所有 Lens 的候选发现，通过语义相似度判断哪些发现实质上是同一问题的不同表述。等效的发现被合并，它们的 source_families 字段取并集，保留所有触发来源的追溯信息。去重是单向的 —— 如果某个外部来源（如 :add 命令注入的云端 /ultrareview 结果）发现了一个已存在的内部发现中没有的问题，它会被保留并进入后续验证。
Phase 3 的评分阶段采用分块批处理策略。超过 25 个候选发现会被分割为多个 chunk，每个 chunk 由一个 Sonnet 代理应用错误升级 rubric（err-up rubric）进行快速评分。这里有一个关键的设计选择：Phase 3 的评分是 “廉价” 的，意味着它不是深度验证，而是用低成本的模型调用快速过滤明显低质量的候选发现。评分低于 45 分且来自单一来源家族的发现在此阶段被直接降级为 below_gate 状态，不再进入 Phase 4 的深度验证。但如果同一发现被两个或以上的 Lens 独立报告，系统会将其自动晋级到 Phase 4—— 这是跨 Agent 共识机制的核心体现。
评分阶段还输出 demote_rate 和 score_phase3_histogram 到 phases.jsonl 日志文件中，为后续的参数校准提供数据基础。值得注意的是，Phase 3 的评分门限 45 与后续 Phase 4 的深度验证门限（45/60/75）是独立设置的，前者是入口筛选，后者是最终确认。
双轨验证门：Deep Lane 与 Light Lane 的角色划分
通过 Phase 3 筛选的发现进入 Phase 4 验证阶段。adamsreview 在此引入了 Deep Lane 和 Light Lane 的双轨架构，这是其多 Agent 协作设计的精髓所在。
Deep Lane 针对 correctness 和 security 类型的发现，使用 Opus 模型进行逐发现深度验证。每个候选发现由一个独立的 Opus 代理处理，执行范围追踪（blast-radius tracing）与全面的修复方案建议。Deep Lane 的发现还会经过 Phase 5 的跨切面审查（cross-cutting review），由另一个 Opus 代理分析这些发现之间是否存在关联的副作用或级联风险。由于 Opus 的调用成本远高于 Sonnet，Deep Lane 严格限定于高影响类型的问题。
Light Lane 针对 UX、policy 和 architecture 类型的发现，使用 Sonnet 模型进行分块批处理验证。每个 chunk 最多 25 个发现，由一个 Sonnet 代理完成确认。Light Lane 的验证器通常输出 manual 或 report_only 类型的可执行性评估，但在某些非常机械化的规则下也可能输出 auto_fixable。
双轨分离的工程价值在于成本 - 覆盖率权衡。正确性和安全性问题需要深度分析，每个发现单独调用 Opus 是必要的；而 UX 和架构问题虽然也需要验证，但批处理可以显著降低 token 消耗。Phase 4 的验证结果决定最终 disposition—— 评分 75 以上且 auto_fixable 的 Deep Lane 发现标记为 confirmed_mechanical，是后续 :fix 命令的默认处理对象。
审查意见冲突仲裁：Disposition 状态机与分数门限
多 Agent 协作系统的核心挑战之一是如何处理不同 Agent 给出的相互矛盾的建议。adamsreview 通过一套基于分数和状态机的冲突仲裁机制来解决这个问题。
Disposition 枚举是该仲裁机制的决策键。当一个发现经过 Phase 4 验证后，其最终 disposition 由 score_phase4 分数和验证器设置的可执行性共同决定。分数低于 45 的发现标记为 disproven；45 到 59 分之间标记为 uncertain—— 这两类都不进入自动修复流程。分数达到 60 以上时，disposition 取决于可执行性：auto_fixable 映射到 confirmed_mechanical（Deep Lane 下自动修复候选），manual 映射到 confirmed_manual（仅报告），report_only 映射到 confirmed_report。
confirmed_mechanical 是自动修复的核心来源。Phase 8 的 fix gate 规定，只有 disposition 为 confirmed_mechanical 且 current_state 为 open 的发现才会被自动修复。Lane 过滤器默认将 Light Lane 的 confirmed_mechanical 排除在自动修复之外，除非通过 :promote 或 :walkthrough 命令获得了人类的显式确认（human_confirmation != null）。
这套仲裁机制的另一个重要设计是 Phase 9 的回归检测。在 :fix 命令的执行阶段，每个修复组完成后会由 Opus 进行后置审查（post-fix review）。如果审查发现该修复引入了新的相邻问题（回归），整个修复组会被自动 revert，相关的 find 标记为 regression disposition 并保持 open 状态供重试。这意味着即使是多 Agent 协作产生的修复建议，也必须通过实际代码变更的验证，而非仅停留在文本层面的建议。
持久化状态与六命令生命周期的工程参数
adamsreview 的另一个核心工程决策是将审查状态持久化到磁盘。每个 review 的完整状态 —— 包括 artifact、trace、phase logs 和 token logs—— 存储在 ~/.adams-reviews/<repo-slug>/<branch>/<review_id>/ 目录下。选择这个路径而非 ~/.claude/reviews/ 是因为 Claude Code 对 ~/.claude/ 下的写入有敏感文件权限提示，而这个提示即使在 bypassPermissions 模式下也会触发，会严重影响批量审查的体验。
artifact 结构通过 bin/schema-v1.json 定义，包含 findings[] 数组中每个发现的完整生命周期追踪 —— 从 Phase 1 的初始发现，到 Phase 4 的验证分数，再到 Phase 8 的修复尝试和 Phase 9 的验证结果。状态字段 current_state（open | attempted | resolved）和 disposition 枚举共同约束合法的状态转换，任何非法转换都会导致 artifact-patch.py 拒绝写入并输出确定性恢复消息。
六个命令构成了一个可选的完整生命周期：:review 发起审查，:add 注入外部发现，:walkthrough 对不确定发现进行人机交互确认，:fix 执行自动修复，:promote 提供单发现旁路，:codex-review 提供 Codex 驱动的对等审查。这些命令共享同一个 artifact 存储位置，可以跨会话、跨天甚至跨周操作同一次审查的结果。
工程落地的关键参数与阈值
对于计划在团队中部署 adamsreview 的工程师，以下参数值得重点关注。
关于 token 成本控制，默认的 non-ensemble 模式下 Phase 1 启动六个并行 Sonnet Lens，Phase 4 对 Deep Lane 逐发现调用 Opus。在一个包含 50 个文件的 PR 中，如果 Phase 3 筛选后保留 15 个 Deep Lane 发现和 20 个 Light Lane 发现，粗略估计 Phase 4 的 Opus 调用约为 15 次、Phase 4b 的 Sonnet chunk 约为 1 次（20 个发现一个 chunk）。配合 --ensemble 会额外增加 Codex CLI 的成本，适合在关键 PR 需要最高覆盖率的场景。
关于 :fix 的 threshold 参数，默认值 60 意味着只有 Phase 4 评分达到 60 及以上的 confirmed_mechanical 发现才会被自动修复。可以降低阈值到 45 来纳入更多不确定但可能值得修复的问题，但会增加 false positive 的风险。Phase 7.5 阶段会弹出一个确认界面，显示所有 Light Lane 和 manual/report 类别的发现，允许在正式 dispatch 前一键批量接受。
关于 :walkthrough 的人机交互流，它使用 Claude Code 的 AskUserQuestion UI 逐个遍历高阈值但未自动修复的发现。对于每个发现，用户可以选择 promote（提升为可自动修复）、skip（仅记录为手动处理项）或 edit fix-hint（提供人工修正建议）。决策日志最终发布到 PR 评论中，形成完整的审查追溯链。
小结
adamsreview 的工程价值在于它将多智能体协作从 “多个模型独立审查然后简单合并” 的初级阶段，推进到 “并行检测、上下文聚合、分数仲裁、双轨验证、回归 revert” 的完整工程链路。通过 Deep Lane 与 Light Lane 的分离设计，它在审查深度与成本控制之间取得了平衡；通过 disposition 状态机与分数门限，它实现了跨 Agent 审查意见的自动化仲裁；通过 Phase 9 的 post-fix review 与 revert 机制，它将修复建议从 “文本承诺” 提升到 “工程验证”。
资料来源：adamsreview GitHub 仓库（https://github.com/adamjgmiller/adamsreview）。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。