这是「GSD 全景代码解析」专题的第 25 篇。在前面的文章中，我们从命令系统到工作流编排，从 execute-phase 的 Wave 调度到 verify-phase 的质量门禁，逐步构建了 GSD 运转机制的全景图。但有一个问题始终悬而未决：执行质量检查的主体是谁？ 工作流只是编排器，真正执行验证逻辑、逐行审查代码的，是 GSD 中两个至关重要的专用 Agent——
gsd-verifier和gsd-code-reviewer。如果说工作流是 GSD 的神经系统，那么 Agent 就是它的感官与四肢。本章将聚焦 Agent 系统，逐一拆解 GSD 33 个专业 Agent 的设计哲学、角色定义和协作协议。本文先从质量保障体系中两个最核心的 Agent 开始——负责阶段验证的 Verifier，和负责代码审查的 Code-Reviewer。
Verifier 与 Code-Reviewer
在 GSD 的多 Agent 编排体系中，质量保障不是某个工作流的"附加功能"，而是由专门设计的 Agent 专职负责的系统性工程。gsd-verifier 和 gsd-code-reviewer 分别镇守两条质量防线：前者验证"阶段目标是否达成"，后者审查"代码实现是否合格"。两者相互独立又紧密协作，共同构成了 GSD 质量保障体系的核心执行层。
本文将深入解析这两个 Agent 的定义文件——agents/gsd-verifier.md（约 30KB）和 agents/gsd-code-reviewer.md（约 15KB），揭开它们的工作方式、审查标准和协作机制。
一、gsd-verifier：阶段目标的守门人
1.1 Agent 定位与核心职责
gsd-verifier 是 GSD 中专门负责阶段级验证的 Agent。与工作流层的 verify-phase 不同，verifier 不是编排器，而是执行者——它接收工作流传递的上下文，独立执行验证逻辑，生成结构化的验证报告。
它的核心职责可以概括为三个问题：
- Goal 达成了吗？ —— 阶段定义的成功标准（must-haves）是否全部满足
- 交付物完整吗？ —— 代码、测试、文档是否按 PLAN.md 的约定全部产出
- 质量达标吗？ —— 测试通过率、覆盖率、Schema 一致性等量化指标是否达到 gates.md 的阈值
flowchart TD
subgraph Input["输入上下文"]
I1[PLAN.md — 计划定义]
I2[SUMMARY.md — 执行结果]
I3[REQUIREMENTS.md — 需求基线]
I4[gates.md — 质量标准]
end
subgraph Verifier["gsd-verifier 执行"]
V1[解析 must-haves]
V2[检查交付物完整性]
V3[运行量化指标]
V4[综合判定]
end
subgraph Output["输出产物"]
O1[VERIFICATION.md]
end
I1 --> V1
I2 --> V2
I3 --> V1
I4 --> V3
V1 --> V4
V2 --> V4
V3 --> V4
V4 --> O11.2 角色定义与工作方式
gsd-verifier.md（30KB）的文件结构遵循 GSD 统一的 Agent 定义格式：
---
name: gsd-verifier
description: 验证阶段目标达成度的专用 Agent
model: ${config.model}
permissions:
- read:workspace
- read:planning
- read:tests
- exec:test-suite
tools:
- gsd-sdk query
- bash (read-only)
---角色提示（System Prompt）的核心指令：
你是一个严格的阶段验证器。你的任务不是找出代码中的 Bug（那是 Code-Reviewer 的工作），而是判断整个阶段的目标是否已经达成。你必须：
- 只依据 PLAN.md 中定义的 must-haves 进行验证，不引入额外的标准
- 对每条 must-have 给出明确的 PASS / FAIL / NEEDS_HUMAN 判定
- 如果存在 gaps，提供 gap-closure 路径而非直接修复
- 保持客观，不因代码写得"漂亮"就放松对功能完整性的要求
这段角色定义体现了一个关键设计：Verifier 的判定标准是"功能性"而非"审美性"。它不关心代码风格，只关心"承诺的功能是否实现"。
1.3 验证流程与检查点
Verifier 的验证流程包含 7 个顺序检查点：
flowchart TD
A[接收验证请求] --> B[加载 PLAN.md]
B --> C[提取 must-haves 列表]
C --> D[加载 SUMMARY.md 和交付物]
D --> E{每条 must-have
都有对应交付物?}
E -->|否| F[标记缺失项]
E -->|是| G[加载 gates.md 阈值]
G --> H[运行测试套件]
H --> I{测试通过率 ≥ 阈值?}
I -->|否| J[标记测试失败]
I -->|是| K[检查 Schema 一致性]
K --> L{Schema drift?}
L -->|是| M[标记 drift]
L -->|否| N[检查文档完整性]
N --> O[生成 VERIFICATION.md]
F --> O
J --> O
M --> O各检查点的详细说明：
| 检查点 | 输入 | 判定逻辑 | 失败处理 |
|---|---|---|---|
| Must-Have 覆盖 | PLAN.md | 每条 must-have 都有对应交付物 | 标记 gaps，不进入后续检查 |
| 交付物存在性 | SUMMARY.md + git status | 所有声明修改的文件真实存在 | 标记"幽灵交付物" |
| 测试通过率 | gates.md 阈值 + 测试报告 | 通过率 ≥ 阈值 | 列出失败测试，分析根因 |
| Schema 一致性 | Schema 文件 + DB 状态 | 无未推送的 schema 变更 | 标记 schema drift |
| 代码库漂移 | 执行前后的 codebase 结构 | 无意外文件变更 | 标记 codebase drift |
| 文档同步性 | API 变更 + 文档文件 | 接口变更已同步到文档 | 标记文档缺口 |
| 回归检测 | 前期阶段测试套件 | 前期功能未被破坏 | 标记 regression |
1.4 验收标准的制定与执行
Verifier 不自行制定验收标准，而是严格执行 PLAN.md 和 gates.md 中预定义的标准。这种"标准前置"的设计确保了验证的客观性和一致性：
sequenceDiagram
participant Planner as gsd-planner
participant Plan as PLAN.md
participant Executor as gsd-executor
participant Verifier as gsd-verifier
participant Gates as gates.md
Planner->>Plan: 写入 must-haves + 验收标准
Planner->>Gates: 写入阶段质量阈值
Executor->>Plan: 按 must-haves 执行
Executor->>Verifier: 交付 SUMMARY.md
Verifier->>Plan: 读取 must-haves
Verifier->>Gates: 读取阈值
Verifier->>Verifier: 执行验证逻辑
Verifier->>Plan: 写入 VERIFICATION.md关键设计原则：标准在规划时确定，验证时只读
这种设计避免了"标准漂移"——如果 Verifier 在验证时自行解释什么是"足够好"，不同运行之间就会产生不一致的判定。GSD 通过将标准固定在 PLAN.md 和 gates.md 中，实现了：
- 可预测性：同样的输入总是产生同样的判定
- 可追溯性：验收标准可以追溯到规划阶段的讨论
- 可审计性：人类可以审查 PLAN.md 中的标准是否合理
1.5 与 verification-patterns.md 的关系
gsd-verifier 和 verification-patterns.md 的关系常被混淆。实际上它们的职责有明确分工：
| 维度 | gsd-verifier Agent | verification-patterns.md |
|---|---|---|
| 定位 | 执行验证逻辑的 Agent | 定义通用验证模式的参考文档 |
| 内容 | 角色定义、工作方式、输出格式 | 跨项目的通用检查清单 |
| 使用方式 | 被工作流 spawn | 被 Agent 通过 @reference 引用 |
| 定制化 | 每个项目统一 | 可按项目裁剪 |
| 典型内容 | "验证 must-haves 的步骤" | "测试覆盖率计算公式"、"Schema drift 检测方法" |
verification-patterns.md 是一个知识库，而 gsd-verifier 是一个执行器。Verifier 在执行验证时，会按需引用 verification-patterns 中的具体方法（如"如何检测 N+1 查询"、"如何验证 API 兼容性"），但验证的判定权和输出格式由 Verifier 自身定义。
二、gsd-code-reviewer：代码质量的显微镜
2.1 Agent 定位与核心职责
如果说 gsd-verifier 是站在 10,000 米高空俯瞰"阶段目标是否达成"，那么 gsd-code-reviewer 就是拿着显微镜逐行检查"代码实现是否合格"。它的核心职责是：
- 发现缺陷：Bug、安全漏洞、性能隐患、边界情况遗漏
- ** enforce 规范**：编码风格、命名约定、项目架构约束
- 评估可维护性：圈复杂度、重复代码、注释质量
- 验证测试充分性：测试覆盖率、边界测试、Mock 使用
flowchart TD
subgraph Input["输入上下文"]
I1[git diff — 变更范围]
I2[CLAUDE.md — 架构规范]
I3[PROJECT.md — 项目约定]
I4[verification-patterns.md — 审查清单]
end
subgraph Reviewer["gsd-code-reviewer 执行"]
R1[生成 diff 摘要]
R2[按文件分组审查]
R3[逐行分析]
R4[标注问题等级]
R5[汇总建议]
end
subgraph Output["输出产物"]
O1[REVIEW.md]
end
I1 --> R1
I2 --> R2
I3 --> R2
I4 --> R3
R1 --> R2
R2 --> R3
R3 --> R4
R4 --> R5
R5 --> O12.2 代码审查标准
gsd-code-reviewer.md（15KB）定义了详细的审查标准，这些标准来自 verification-patterns.md 的 40+ 条检查项，按类别组织如下：
| 类别 | 检查项示例 | 问题等级 |
|---|---|---|
| 安全性 | 无明文存储密码、输入校验、XSS 防护、CORS 配置 | Critical |
| 可靠性 | 错误处理、超时设置、重试策略、幂等性 | Major |
| 性能 | N+1 查询检测、大文件读取、内存泄漏、事件监听器清理 | Major |
| 可维护性 | 圈复杂度控制、函数长度、命名规范、注释完整性 | Minor |
| 测试 | 分支覆盖、边界测试、Mock 使用、测试隔离性 | Major |
| 架构 | 层间依赖方向、接口稳定性、重复代码检测 | Minor |
Critical 问题的判定标准（部分示例）：
## Critical（阻塞性）判定规则
以下情况必须标记为 Critical：
1. **安全漏洞**
- 密码、Token、密钥以明文形式存储或传输
- 用户输入未经校验直接拼接 SQL / HTML
- 敏感接口缺少鉴权
2. **数据完整性风险**
- 并发场景下缺少事务保护
- 关键操作无幂等性保证
- 缺少数据备份/恢复机制
3. **系统稳定性**
- 无限递归或死循环风险
- 资源泄漏（文件句柄、连接池未释放）
- 未捕获的异常可能导致进程崩溃2.3 审查深度控制：quick / standard / deep
gsd-code-reviewer 支持三种审查深度，通过 --depth 参数或工作流配置控制。这是 GSD Agent 设计的典型模式——同一 Agent，不同深度，不同上下文预算：
| 深度 | 描述 | 耗时 | 上下文预算 | 适用场景 |
|---|---|---|---|---|
quick | 仅模式匹配 + 安全扫描 | ~2 分钟 | ~50K tokens | 预提交检查、快速扫描 |
standard | 逐文件分析 + 语言特定检查 | ~5-15 分钟 | ~150K tokens | 常规阶段审查（默认） |
deep | 跨文件分析 + 导入图和调用链 | ~15-30 分钟 | ~300K tokens | 关键模块、安全审查 |
flowchart TD
subgraph Quick["quick 模式"]
Q1[安全模式匹配] --> Q2[已知漏洞扫描]
Q2 --> Q3[生成快速报告]
end
subgraph Standard["standard 模式"]
S1[quick 全部检查] --> S2[逐文件 AST 分析]
S2 --> S3[编码规范检查]
S3 --> S4[测试覆盖率评估]
S4 --> S5[生成详细报告]
end
subgraph Deep["deep 模式"]
D1[standard 全部检查] --> D2[跨文件调用链分析]
D2 --> D3[架构约束验证]
D3 --> D4[性能热点检测]
D4 --> D5[生成深度报告]
end
Quick --> Standard --> Deep三种模式的上下文差异：
- quick：只加载变更文件的 diff + 安全规则库
- standard：加载变更文件 + 相关接口定义 + 编码规范 + 测试报告
- deep：加载完整项目结构 + 依赖图 + 性能基线 + 架构文档
这种分层设计使得审查资源可以被合理分配——80% 的场景用 standard 即可，只有关键模块才需要 deep 级别的投入。
2.4 与 gates.md 的集成
gsd-code-reviewer 的审查判定不是二元的"通过/失败"，而是与 gates.md 中的质量门控阈值联动：
# gates.md 中与代码审查相关的配置
code_review:
depth: standard # 默认审查深度
critical_threshold: 0 # Critical 问题必须为零
major_threshold: 3 # Major 问题最多 3 个
coverage_threshold: 80 # 测试覆盖率最低 80%
cyclomatic_complexity_max: 15 # 圈复杂度上限
duplicate_lines_threshold: 5% # 重复代码比例上限Code-Reviewer 在执行审查时，会将发现的问题与这些阈值对比，生成结构化的判定结果：
## 审查判定
| 检查项 | 发现数 | 阈值 | 状态 |
|--------|--------|------|------|
| Critical 问题 | 0 | 0 | ✅ 通过 |
| Major 问题 | 2 | 3 | ✅ 通过 |
| 测试覆盖率 | 82% | 80% | ✅ 通过 |
| 圈复杂度 | 18（auth.js:45） | 15 | ❌ 超标 |
## 综合判定：CONDITIONAL_PASS
> 圈复杂度超标，建议重构 auth.js 中的 `validateToken` 函数。
> 其他指标全部达标，不影响合并。2.5 输出格式：REVIEW.md 的结构化设计
gsd-code-reviewer 的输出严格遵循 REVIEW.md 模板，这是 Agent 可组合性的关键——工作流可以可靠地解析 Reviewer 的输出，驱动后续流程：
# Code Review Report
## 变更概要
- 审查范围：12 个文件，+482/-127 行
- 审查时间：2026-04-24
- Reviewer：gsd-code-reviewer
- 深度：standard
## 问题列表
### 🔴 Critical（阻塞性）
- **[auth.js:45]** 密码以明文形式存储到 localStorage，存在严重安全风险
- 建议：使用 Web Crypto API 加密存储
- 关联规则：SEC-001（verification-patterns.md）
### 🟠 Major（重要）
- **[utils.ts:23]** 递归函数缺少终止条件检测
- 建议：添加深度限制或改为迭代实现
### 🟡 Minor（建议性）
- **[styles.css:34]** 魔法数字应提取为常量
## 质量指标
| 指标 | 值 | 阈值 | 状态 |
|------|-----|------|------|
| 测试覆盖率 | 82% | 80% | ✅ |
| 平均圈复杂度 | 8 | 15 | ✅ |
## 通过标准检查
- [x] 所有 Critical 问题已修复或已接受风险
- [x] 所有 Major 问题已修复或有合理解释
- [x] Minor 问题不影响合并
## 签名
- Reviewer Agent: gsd-code-reviewer
- 审查标准版本: verification-patterns.md @ v2.3关键设计点：
- 规则溯源：每个问题都标注关联的 verification-patterns 规则编号，便于追溯标准来源
- 可操作建议：不只是指出问题，还要给出修复建议
- 可解析结构：工作流可以通过正则或结构化解析提取问题列表和判定结果
- 版本追踪：记录审查标准的版本，确保审查结果可复现
三、Verifier 与 Code-Reviewer 的协作关系
3.1 职责分离：功能验证 vs 代码审查
Verifier 和 Code-Reviewer 虽然都涉及"质量"，但它们的关注点截然不同：
| 维度 | gsd-verifier | gsd-code-reviewer |
|---|---|---|
| 关注点 | "功能是否正确交付" | "代码是否高质量实现" |
| 输入 | PLAN.md + SUMMARY.md | git diff + 架构规范 |
| 输出 | VERIFICATION.md | REVIEW.md |
| 判定标准 | must-haves + gates.md 阈值 | verification-patterns 检查清单 |
| 失败处理 | 生成 gap-closure 路径 | 生成修复任务 |
| 上下文预算 | ~200K tokens | ~150K tokens（standard） |
flowchart LR
subgraph Executor["gsd-executor"]
E1[编写代码]
E2[编写测试]
E3[生成 SUMMARY.md]
end
subgraph Quality["质量检查层"]
direction TB
V["gsd-verifier
功能验证
'目标达成了吗?'"]
R["gsd-code-reviewer
代码审查
'实现得好吗?'"]
end
subgraph Result["结果"]
V_OK["VERIFICATION.md
PASSED"]
R_OK["REVIEW.md
APPROVED"]
end
Executor --> V
Executor --> R
V --> V_OK
R --> R_OK
V_OK --> Merge["允许合并"]
R_OK --> Merge3.2 串行 vs 并行执行策略
在 GSD 的工作流编排中，Verifier 和 Code-Reviewer 的执行顺序取决于具体场景：
场景 A：execute-phase 后的默认流程（串行）
execute-phase 完成
→ code-review（先审查代码质量）
→ code-review-fix（修复问题）
→ verify-phase（再验证功能目标）
→ 生成 VERIFICATION.md这种顺序的逻辑是：先确保代码质量过关，再验证功能是否完整。如果代码本身有问题（如安全漏洞），即使功能实现了也不应该通过验证。
场景 B：audit-milestone 中的并行执行
Milestone 完成
→ [并行] gsd-verifier 验证所有 Phase
→ [并行] gsd-code-reviewer 审查全部变更
→ 汇总 AUDIT.md在里程碑审计时，由于变更量大、时间预算充足，两个 Agent 可以并行执行，最后由 orchestrator 汇总结果。
flowchart TD
subgraph Milestone["audit-milestone 工作流"]
A[Milestone 标记完成] --> B{审查策略}
B -->|常规| C[串行: review → verify]
B -->|大版本| D[并行: review + verify]
end
subgraph Serial["串行模式"]
S1[code-review] --> S2[code-review-fix]
S2 --> S3[verify-phase]
end
subgraph Parallel["并行模式"]
P1[gsd-code-reviewer] --> P3[汇总结果]
P2[gsd-verifier] --> P3
end
C --> Serial
D --> Parallel3.3 结果冲突的处理
当 Verifier 和 Code-Reviewer 的结果出现冲突时（例如 Verifier 判定 PASSED 但 Code-Reviewer 发现了 Critical 问题），GSD 的处理策略是：
Code-Reviewer 的判定优先于 Verifier 的功能判定。
原因很明确：一个存在安全漏洞的功能"实现"，不能被视为"达成目标"。GSD 的质量哲学是**"质量是前提，功能是结果"**。
flowchart TD
V{Verifier: PASSED?}
R{Code-Reviewer:
Critical 问题?}
V -->|是| R
V -->|否| F1[进入修复流程]
R -->|否| F2[全部通过，允许合并]
R -->|是| F3[阻塞合并，优先修复 Critical]
F3 --> F4[code-review-fix]
F4 --> V四、与 verify-phase 工作流的衔接
4.1 Verifier 在 verify-phase 中的位置
verify-phase 工作流（ Orchestrator ）与 gsd-verifier Agent（执行者）的关系，是 GSD "Thin Orchestrator" 设计原则的典型体现：
sequenceDiagram
participant User as 用户
participant Cmd as /gsd:verify-phase
participant WF as verify-phase.md
工作流
participant SDK as gsd-sdk
participant V as gsd-verifier
Agent
participant FS as 文件系统
User->>Cmd: 触发验证
Cmd->>WF: 调用工作流
WF->>SDK: query init.verify-phase
SDK-->>WF: 返回上下文 payload
WF->>WF: 组装验证参数
WF->>V: spawn Agent + 传递上下文
V->>FS: 读取 PLAN.md / SUMMARY.md / gates.md
V->>V: 执行 7 步验证流程
V->>FS: 写入 VERIFICATION.md
V-->>WF: 返回验证结果信号
WF->>FS: 更新 STATE.md
WF->>User: 输出验证摘要在这个流程中：
- 工作流负责：参数解析、上下文组装、Agent spawn、结果收集、状态更新
- Verifier负责：实际的验证逻辑执行、判定、报告生成
两者通过文件系统（VERIFICATION.md）和信号（return code / done signal）进行通信，而非通过对话上下文传递结果。
4.2 验证结果的三种状态与后续路由
Verifier 生成的 VERIFICATION.md 有三种状态，驱动 verify-phase 工作流的后续路由：
| 状态 | 含义 | 后续动作 |
|---|---|---|
passed | 所有 must-haves 验证通过 | 更新 ROADMAP，标记阶段完成 |
human_needed | 自动化检查通过，需人工确认 | 创建 HUMAN-UAT.md，暂停等待用户 |
gaps_found | 发现缺口 | 提供 /gsd:plan-phase {X} --gaps 路径 |
flowchart TD
A[verify-phase 工作流] --> B[spawn gsd-verifier]
B --> C[读取 VERIFICATION.md]
C --> D{status?}
D -->|passed| E[更新 STATE.md
标记 COMPLETED]
D -->|human_needed| F[创建 HUMAN-UAT.md
暂停等待用户]
D -->|gaps_found| G[提取 gap 列表]
G --> H{auto_fix?}
H -->|是| I[调用 plan-phase --gaps]
H -->|否| J[生成修复任务清单
等待用户决策]4.3 与 execute-phase 的自动推进链
当 workflow.auto_advance 启用时，execute-phase 在 Wave 执行完成后会自动触发 verify-phase，形成"执行-验证-推进"的闭环：
flowchart LR
subgraph Execute["execute-phase"]
E1[Wave 执行] --> E2[代码审查门控]
E2 --> E3[回归测试门控]
E3 --> E4[Schema 漂移门控]
end
subgraph Verify["verify-phase"]
V1[spawn gsd-verifier] --> V2{passed?}
V2 -->|是| V3[标记完成]
V2 -->|否| V4[进入修复循环]
end
subgraph Advance["auto-advance"]
A1[调用 transition] --> A2[启动下一阶段]
end
Execute --> Verify
V3 --> Advance
V4 --> Execute关键设计：Verifier 是自动推进链的"把关者"。如果验证不通过，链条自动断裂，不会盲目推进到下一阶段。这防止了"带病前行"——一个未达标的功能不会被带入下一阶段累积技术债务。
4.4 上下文隔离与 Fresh Context 原则
Verifier 在与 verify-phase 工作流衔接时，严格遵循 GSD 的 Fresh Context Per Agent 原则：
flowchart TD
subgraph Orchestrator["verify-phase 工作流
（主会话）"]
O1[上下文窗口
~30% 占用]
end
subgraph VerifierAgent["gsd-verifier Agent
（独立会话）"]
V1[全新上下文窗口
~200K tokens]
V2[加载 PLAN.md]
V3[加载 SUMMARY.md]
V4[加载 gates.md]
V5[执行验证]
V6[写入 VERIFICATION.md]
end
O1 -->|spawn + payload| V1
V1 --> V2
V2 --> V3
V3 --> V4
V4 --> V5
V5 --> V6
V6 -->|done signal| O1Verifier 不会继承 execute-phase 中 Executor 的上下文。它看到的是：
- 干净的 PLAN.md（目标是什么）
- 干净的 SUMMARY.md（实际做了什么）
- 干净的 gates.md（标准是什么）
这种隔离确保了 Verifier 的判定不受执行过程中"中间推理"的污染——它只依据最终结果和标准进行判定，避免了"因为知道你是怎么想的，所以理解你的偏差"的宽容错误。
五、两个 Agent 的设计哲学对比
5.1 规模差异背后的设计意图
| Agent | 文件大小 | 设计意图 |
|---|---|---|
gsd-verifier.md | ~30KB | 验证逻辑复杂，需要覆盖 7 个检查点、3 种判定状态、多种失败处理策略 |
gsd-code-reviewer.md | ~15KB | 审查逻辑相对聚焦，核心是对照检查清单逐行分析，深度控制通过参数实现 |
Verifier 更大的体积并非因为它"更重要"，而是因为它的判定逻辑更复杂：
- 需要处理 must-have 的多种匹配模式（精确匹配 / 模糊匹配 / 人工确认）
- 需要与 gates.md 的动态阈值联动
- 需要生成 gap-closure 路径（这比简单的"通过/失败"复杂得多）
- 需要处理三种判定状态（passed / human_needed / gaps_found）的差异化输出
Code-Reviewer 的审查逻辑虽然也需要细致，但基本是"对照清单检查 → 标注问题等级 → 汇总报告"的线性流程，通过 verification-patterns.md 外部化了大部分规则内容。
5.2 可组合性设计
两个 Agent 都遵循 GSD 的可组合性原则：独立运行、标准输入输出、可被任意工作流调用。
flowchart TD
subgraph Callers["可能的调用方"]
C1[verify-phase]
C2[audit-milestone]
C3[audit-fix]
C4[/gsd:verify]
end
subgraph Verifier["gsd-verifier"]
V1[标准输入: PLAN + SUMMARY + gates]
V2[标准输出: VERIFICATION.md]
end
subgraph Callers2["可能的调用方"]
D1[code-review]
D2[code-review-fix]
D3[execute-phase 门控]
D4[/gsd:code-review]
end
subgraph Reviewer["gsd-code-reviewer"]
R1[标准输入: diff + 规范 + 深度参数]
R2[标准输出: REVIEW.md]
end
C1 --> Verifier
C2 --> Verifier
C3 --> Verifier
C4 --> Verifier
D1 --> Reviewer
D2 --> Reviewer
D3 --> Reviewer
D4 --> Reviewer这种设计使得：
- 新增工作流时可以直接复用现有 Agent，无需重写验证逻辑
- Agent 的升级（如改进验证算法）会自动惠及所有调用方
- 可以针对特定场景 spawn 多个 Verifier 并行验证不同维度
六、小结
本文深入解析了 GSD 质量保障体系中两个核心 Agent 的设计与实现：
| Agent | 核心职责 | 关键设计 |
|---|---|---|
| gsd-verifier | 验证阶段目标达成度 | 7 步检查流程、3 状态判定、标准前置、gaps 路径生成 |
| gsd-code-reviewer | 逐行审查代码质量 | 3 级审查深度、40+ 检查项、与 gates.md 阈值联动、结构化 REVIEW.md |
两者的协作关系：Verifier 回答"目标达成了吗"，Code-Reviewer 回答"实现得好吗"。前者关注功能性，后者关注实现质量。当两者冲突时，Code-Reviewer 的 Critical 问题优先——因为质量是前提，功能是结果。
与工作流的衔接：两个 Agent 都不是独立运行的，它们被 verify-phase、code-review、audit-milestone 等工作流 spawn，遵循 Thin Orchestrator 原则——工作流负责编排，Agent 负责执行。通过文件系统（VERIFICATION.md / REVIEW.md）和信号进行通信，确保上下文隔离和判定客观性。
GSD 的质量保障体系设计体现了一个核心理念：
质量不是检查出来的，而是内建在 Agent 的 DNA 中的。
Verifier 和 Code-Reviewer 不是可选的"附加组件"，而是 GSD 执行管道的必经关卡。它们的专业化分工、标准化输出和可组合设计，使得质量保障可以从"靠运气"变为"可工程化"。
下一篇预告：第 26 篇《文档与研究 Agent》
在解析了质量保障体系的核心 Agent 之后，我们将继续探索 GSD Agent 系统的另外两个重要维度——
gsd-doc-writer和gsd-ai-researcher。文档 Agent 如何确保代码变更与文档同步？研究 Agent 如何在规划阶段提供深度技术调研？它们如何与 Planner、Executor 形成完整的知识生产闭环？敬请期待！