如实汇总 Claude Code 多代理的审查结果

你输入 /prepare-pr，让 Claude Code 准备一次功能合并。它把普通审查、安全检查和补测试分别交给几个子代理，最后汇总成一份报告。

这一次，几个代理的结果各不相同：普通审查返回了三条业务隐患，其中一条要到真实集成环境里才能验证；安全审查没发现问题；测试代理在补测时因为权限不足被拦下了。主代理汇总时图省事，写下一句“审查全部通过”。

这句话至少抹平了三件事：一条隐患还没验证，一项测试根本没执行，还有一个代理失败了。拿着这份报告的人，会以为可以合并。

多个代理协作不可能永远顺利，外部服务也会超时。工作流真正的考验，是中途有环节失败时，它能不能如实交付结果。做法有三条：

• 汇总时把结果分成三类：已有证据确认的、仍待验证的假设、因缺环境或授权而没执行的；
• 合并多方发现时，按触发条件、位置和失败原因判断是否重复，标题相似不算；
• 外部状态拿不到时，标记“未知”并写清缺口，继续能独立完成的部分，最终决定交给有权决定的人。

01 一次功能合并经过哪些环节

下面按完整配置演示各组件如何衔接；实际执行时跳过不需要的代理和 MCP。Memory 与 Hook 要事先配置好，列出步骤并不会让它们自动生效：

1. Slash command 收集 git 状态、diff 和最近提交。
2. Memory 提供项目规则、测试命令和提交规范。
3. 确认当前恢复点及 Rewind 覆盖不到的改动。
4. code-reviewer 检查行为回归。
5. security-reviewer 做只读安全审查。
6. test-engineer 找测试缺口。
7. documentation-writer 判断是否需要更新文档。
8. Hooks 对写入文件做格式化和安全扫描。
9. MCP 查询当前 PR 或 Issue 状态。
10. Skill 把多方结论整理成审查报告。
11. 主代理输出最终摘要、风险、待办和验证结果。

报告要让人看清改了什么、哪些必须修、哪些可选，以及测试、文档、外部任务状态、合并风险和下一步。

02 汇总时分成三类：已确认、待验证、未执行

回到开头那三个代理的结果。主代理写“审查全部通过”，是在替用户做一个它没有依据的判断。主代理应明确区分：

• 哪些已有证据确认；
• 哪些仍是待验证的假设；
• 哪些测试因缺少环境或授权而没能执行。

把没有解决的问题摆在桌面上，让有最终决策权的工程师来定夺。一个命令的名字起得再好听，都不如一张实事求是、经得起推敲的证据清单让人踏实。

Claude Code 的最佳实践文档在区分“模型自己判断”和“工具强制执行”时，把“谁说了算”这一项也列了进去：一边是 Claude 对自己做了什么的总结，另一边是分支保护和批准合并的人。汇总报告属于前者，它的作用是把证据和缺口交代清楚，合不合并由后者决定。

03 合并重复发现，先对照触发条件

把报告方法放进一个共用的 Skill，命令和代理就能用同一套格式。审查报告 Skill 可以这样写：

---
name: review-report
description: 生成结构化代码审查报告。适用于审查 diff、PR、风险、测试缺口和合并前检查的场景。
---

# Review Report Skill

## Workflow

1. 收集变更范围。
2. 按行为风险、安全风险、测试缺口、性能风险分类。
3. 合并多个 subagent 的结论。
4. 去除重复问题。
5. 按严重程度排序。
6. 使用报告模板输出。

## Output

- Summary
- Critical findings
- High findings
- Medium findings
- Test gaps
- Recommended verification

多方结果放到一起，会遇到下一步判断：哪些发现确实重复，哪些只是标题相似？先看两种情况：

合并报告时，很容易先看标题。两条都写“鉴权风险”，读起来像重复，涉及的却可能是两类不同请求。先对照触发条件、位置和失败原因，确认是同一问题再合并。否则报告短了，风险却被删掉了一项。

04 部署检查：交付的是检查结果

用户调用：

/deploy-check production

检查按这条链路走：

取得目标环境与分支
  → Hook 核对生产操作是否允许
  → MCP 读取部署、错误率和关键指标
  → 测试代理核对真实测试，安全代理查权限与凭据变化
  → 主代理汇总；部署专员仅在已配置且需要时加入
  → 交付检查结果

沿这条链路走到末尾，交付的是环境、当前与待部署版本、测试和指标状态、风险、回滚方案及待确认操作，用户据此判断下一步。命令名里有“部署”，这次完成的仍是检查；真正发布还要进入明确授权的执行流程，最终决定和不可逆动作由用户确认。

05 没按预期走完时，知道停在哪里

当流程没有按预期走完时，应知道停在哪里、还能继续什么：

比如部署监控 MCP 超时，线上版本和错误率都没取到。报告写“未知”，附上连接失败的情况与实际时间：

已取得的本地测试、代码审查 → 保留结论，继续独立工作
缺失的线上版本与错误率   → 列出缺口，等恢复连接或人工核实后补查

部署判断需要的材料缺着，就说明还差什么，推测值补不了这个缺口。

恢复也要分层。想象第一阶段改了文件，第二阶段又跑命令更新了数据库，后续测试失败时，回退文件只恢复了前一部分，数据库还停在新状态。每个阶段做了什么、怎样验证、失败怎样恢复，都要分别记清，报告里才能写出哪些已经恢复、哪些还需要在对应系统里处理。

06 让新成员走一遍，验收整条工作流

工作流搭好后，让新成员实际走一条任务，再核对各层结果：

走完任务，再看结果能否回溯：敏感配置有没有明文进入项目，失败发生在哪一层，能否找到负责的组件？配置清单齐全，只说明东西都放进去了。新成员能用它完成一条任务，并查清中途结果，才说明各层真正接在了一起。

评价一套 AI 协作系统，要看出现意外时，安全措施和恢复路径能否实际发挥作用。入口清不清楚、权限有没有收住、失败能否恢复，都回到实际结果判断；目录和配置有多少，按实际需要来定。系统怎样从一条最小流程搭起来，见 团队 Claude Code 配置从一个命令搭起；脚本拿到单个结果时的校验方法，见 校验 Claude Code 输出的 JSON。

回到开头那次合并：一条隐患待验证、一项测试没执行、一个代理被拒，把这三行原样写进报告，合不合并交给有权决定的人。