Agent 发布 Gate 设计：从 QA 到 VERIFIED 的上线流程

1. 为什么 Agent 输出需要发布 Gate

传统 CI/CD 假设变更来自人类工程师：一个 PR 改三五个文件，几百行 diff，reviewer 逐行审。AI Agent 打破了这个前提——一次执行可以修改几十个文件、生成数百行代码，不到两分钟。一个活跃 Agent 一天产出的 diff 量相当于一个小团队一周的工作量。不是人不愿意审——是审不动。

更根本的是 Agent 的失败模式不同。人类 bug 是确定性的——边界遗漏、空指针、逻辑反转，lint 和测试能拦。Agent 有两类传统手段拦不住的失败：

1. 幻觉（Hallucination）：语法正确、lint 通过，但逻辑是编造的——调用了不存在的 API、引用了虚构的配置 key。
2. 上下文漂移（Context Drift）：长任务中逐渐偏离原始意图。每一步 diff 单独看都对，合起来是方向性错误。参见 Agent 状态机设计——状态机用 checkpoint 对抗漂移，发布 Gate 从产出物质量角度做独立校验。

还有一个速度不对称问题：Agent 输出远快于人工 review。放任不管的结果要么 review 成瓶颈，要么 review 走过场。

解决思路是分层 Gate：把质量检查拆成多个独立层级，确定性检查归自动化，语义判断交给独立审查者，互不混淆。每一层 Gate 都是一个不可跳过的判定点——通过则进入下一层，失败则进入明确的重试、降级、阻断或回滚路径。下面先用四个核心验证 Gate 展示配置 schema，后文再补齐 Research、Author、READY 与 Deploy，形成完整八层执行链：

{
  "pipeline": "agent-release-gate",
  "version": "1.0",
  "gates": [
    {
      "name": "QA",
      "order": 1,
      "executor": "automated",
      "checks": [
        {"name": "lint", "tool": "ruff", "blocking": true},
        {"name": "type_check", "tool": "mypy", "blocking": true},
        {"name": "unit_test", "tool": "pytest", "min_coverage": 0.80, "blocking": true},
        {"name": "security_scan", "tool": "bandit", "severity": "medium", "blocking": true}
      ],
      "on_failure": "BLOCK",
      "timeout_seconds": 300
    },
    {
      "name": "REVIEW",
      "order": 2,
      "executor": "hybrid",
      "checks": [
        {"name": "diff_size_check", "max_files": 15, "max_lines": 500, "blocking": false, "action": "warn"},
        {"name": "logic_review", "reviewer": "human", "blocking": true},
        {"name": "security_review", "reviewer": "human", "trigger_on": "security_scan_warn", "blocking": true}
      ],
      "on_failure": "REQUEST_CHANGES",
      "timeout_hours": 4,
      "auto_approve_if": {"changed_files": 1, "max_lines": 50, "only": ["docs/*", "*.md"]}
    },
    {
      "name": "CONFORMITY",
      "order": 3,
      "executor": "automated",
      "checks": [
        {"name": "schema_valid", "schema_path": "./schemas/post.schema.json", "blocking": true},
        {"name": "cross_ref_valid", "source": "internal_links", "blocking": true},
        {"name": "bilingual_sync", "en_path": "./en/posts/", "zh_path": "./zh/posts/", "blocking": true}
      ],
      "on_failure": "BLOCK",
      "timeout_seconds": 120
    },
    {
      "name": "VERIFIED",
      "order": 4,
      "executor": "automated",
      "checks": [
        {"name": "build_check", "tool": "hugo", "blocking": true},
        {"name": "link_check", "tool": "lychee", "blocking": false},
        {"name": "meta_complete", "fields": ["title", "description", "keywords", "canonical", "og:*"], "blocking": true}
      ],
      "on_failure": "BLOCK",
      "timeout_seconds": 180,
      "on_pass": "MARK_VERIFIED"
    }
  ],
  "global_rules": {
    "skip_gate_order": false,
    "require_gate_evidence": true,
    "gate_transition_log": "./.agent-workspace/log/gate-transitions.jsonl"
  }
}
  

这个 schema 的设计要点：四层 Gate 各管独立维度——QA 管质量、REVIEW 管语义、CONFORMITY 管合规、VERIFIED 管构建；阻塞与警告分级（lint 失败阻断，diff 过大仅 warn，小变更可 auto_approve_if 跳过人工审查）；每层有明确超时，Gate 本身不成为死锁；通过/阻断事件驱动 Agent 状态机转移——QA_PASSED → REVIEW_PASSED → CONFORMITY_PASSED → VERIFIED_GATE_PASS，每层证据记入审计轨迹。

一句话：Agent 可以写得比人快，但不能合得比人快。分层 Gate 不是给 Agent 设限，而是给它的输出设守卫——让 Agent 放心地快写，让 Gate 扎实地慢审。

2. Gate 不是 CI/CD，是 Agent 责任链

在深入完整八层执行 Gate 的具体设计之前，需要先厘清一个根本差异：Agent 发布 Gate 的运作模型不是 CI/CD pipeline，是责任链（Chain of Responsibility）。把 CI/CD 的思维框架直接套到 Agent 输出上，会遇到系统性的不适配。

传统 CI/CD 有三个核心假设，在 Agent 场景下全部失效：

1. 变更是一次性提交。 CI/CD 的触发单元是 git push——一个 commit 代表一次完整的、自洽的变更。Pipeline 对这个 commit 做一次性的 build → test → deploy。Agent 的工作模式是持续流（stream）：一次 session 中反复修改、回滚、重写，中间状态可能经过十几版迭代。没有明确的"提交时刻"——如果每次中间保存都触发 pipeline，Gate 会被噪音淹没。
2. 阶段在隔离环境中运行。 CI/CD 每个阶段拉起独立容器，有数分钟到数十分钟的执行窗口。Agent Gate 必须在同一执行上下文中、数秒内做出决策——Agent 不会"等 pipeline 跑完再继续"，它需要即时反馈来调整后续动作。参见 Agent 上下文协议设计——Gate 间上下文传递依赖结构化协议，而非文件系统共享或环境变量注入。
3. 失败模式是中断构建。 CI/CD 失败 → 构建中断，通知人类工程师修复后重新提交。Agent Gate 的失败意义完全不同：它是一次工作流重定向。QA Gate 失败 → Agent 自动修复 lint 错误后重试；REVIEW Gate 请求修改 → Agent 理解 review 意见并重新生成；CONFORMITY Gate 阻断 → 终止当前任务并记入审计日志，等待人工介入。

基于以上差异，将发布 Gate 建模为责任链：每个 Gate 是链条上的一个独立处理器，拥有自己的通过条件、失败动作和审计证据。Gate 不关心上游如何产出变更、下游如何消费结果——它只对经过自己的变更负责。链式结构保证了检查的顺序性和不可跳过性，同时每个节点的失败处理互不耦合。

下面是一个 Gate 责任链的 YAML 配置，强调"链"的语义（与第一节的 JSON schema 等价，但视角从"配置项"转向"责任传递"）：

# Gate 责任链：每个 Gate 是独立处理器，链式传递
chain:
  - gate: QA
    responsibility: 代码质量和安全性自动化检查
    pass_condition: all_blocking_checks_pass
    on_failure: BLOCK          # 阻断，Agent 修复后自动重试
    evidence: qa_report.json
    next: REVIEW               # 通过后传递给下一节点

  - gate: REVIEW
    responsibility: 语义正确性和逻辑合理性审查
    pass_condition: human_reviewer_approved
    on_failure: REQUEST_CHANGES  # 打回，Agent 根据意见修改
    evidence: review_log.md
    next: CONFORMITY

  - gate: CONFORMITY
    responsibility: 项目规范与跨文件一致性校验
    pass_condition: schema_and_cross_ref_valid
    on_failure: BLOCK          # 阻断，不可自动修复，需人工介入
    evidence: conformity_report.json
    next: VERIFIED

  - gate: VERIFIED
    responsibility: 构建完整性与上线就绪校验
    pass_condition: build_and_meta_check_pass
    on_failure: BLOCK          # 阻断，上一步已过审，此处应是确定性问题
    evidence: verified_report.json
    next: null                 # 链条末端，标记 VERIFIED_GATE_PASS

责任链模型天然映射到 Agent 状态机设计：每个 Gate 的通过事件触发状态转移（QA_PASSED → REVIEW_PASSED → CONFORMITY_PASSED → VERIFIED_GATE_PASS），失败事件触发对应的回退路径。状态机保证 Gate 的顺序不可跳过——这是责任链的"链"字落到实处的机制。而 Agent 上下文协议解决了另一个关键问题：Gate 之间如何传递上下文——QA 的 lint 报告如何被 REVIEW 引用、REVIEW 的审查意见如何被 CONFORMITY 的 schema 校验感知——答案是结构化 context 协议而非临时文件。

一句话：CI/CD 是"提交后跑流水线"，Agent Gate 是"执行中过责任链"。前者适合确定性构建，后者适合非确定性生成。

3. Layer 1：Research Gate — 只有信息可以进入，代码还不是代码

有了核心验证 Gate 和责任链模型作为框架，现在可以逐一拆解完整八层执行链。第一个关卡是Research Gate——它位于整个 Agent 生产流程的入口处，执行一条简单的铁律：在这个阶段，Agent 只能收集信息和资料，不能写任何代码或修改任何文件。这不是给 Agent 设限，而是在最脆弱的阶段给它装上护栏。

3.1 为什么需要 Research Gate

Agent 生产流程中最常见的失败模式不是代码写错，而是在拥有足够信息之前就开始写代码。人类工程师在接到任务后的第一反应通常是查文档、搜关键词、翻 issue tracker、看现有代码——但 LLM 驱动 Agent 的默认行为模式截然相反：它倾向于基于训练数据中的统计模式直接生成，在信息不完整的情况下照样输出"看起来正确"的结果。这恰恰是Agent 可观测性想要解决的盲区——如果你不看 Agent 在动笔之前到底查了什么，你只会看到成品而看不到根基。

更具体地说，跳过 Research 直接进入 Author 有三个系统性风险：

1. 幻觉级联：Agent 基于不完整信息做出的第一个假设被后续步骤当作事实引用，每一步的"置信度"都在放大一个根本没经过验证的前提。等到 CONFORMITY Gate 发现 cross-ref 断裂，源头可能已经埋在几百行 diff 里。
2. 信息盲区：Agent 不知道仓库里已经存在相关代码、已有讨论、或已废弃的方案——因为它没查。结果就是重复造轮子，甚至与现有架构冲突。
3. 任务漂移的温床：没有 explicit 的研究基线作为锚点，Agent 在长任务中特别容易偏离原始意图——它连自己应该知道什么都不知道。参见 Agent 状态机设计中 checkpoint 的对抗漂移机制——Research Gate 产出物本身就是第一个 checkpoint。

3.2 Research Gate 的输入与输出

Research Gate 的设计遵循一个清晰原则：输入是任务描述，输出是 source-pack（研究资料包），产出物是 .md 文件而非代码。这个边界极其重要——它意味着 Research Gate 完成时，仓库里的 .py、.ts、.yaml 文件一个都不会变。变更只发生在 .agent-workspace/ 目录下。

3.3 通过条件

Research Gate 判定"信息收集已充分"的标准不是主观感觉，而是一组可自动校验的量化条件：

1. 搜索覆盖所有关键词：从任务描述中自动提取的关键词列表，每一项必须至少有 1 次有效搜索命中（有效定义为结果数 > 0 且结果与关键词语义相关）。关键词提取依赖 embedding 相似度而非字面匹配——避免同义词盲区。
2. 找到至少 N 个参考源：N = max(3, 关键词数 × 1.5)，每个参考源必须有明确的文件路径或 URL、引用片段和与任务的相关性说明。参考源类型包括：现有代码文件、文档、配置文件、git log 中的相关 commit、外部 API 文档链接。
3. 包含 FAQ 候选：至少 2 条"如果……怎么办"（what-if）问题，覆盖任务中最容易出错的边界条件。这迫使 Agent 在动笔前预演可能踩的坑——FAQ 候选本身也作为后续 REVIEW Gate 的审查锚点。
4. 内部链接建议：根据 source-pack 中识别到的概念和模块，自动生成该任务产出物应该链接到的内部页面列表。对于内容类任务（如写一篇博文），该列表确保新文章不会成为信息孤岛。

3.4 失败响应：不是终止，是重定向

Research Gate 遵循责任链模型中的失败处理原则——失败不等于终止，等于工作流重定向。具体策略：

• 搜索覆盖不足：自动追加搜索。将未覆盖的关键词按信息增益排序，逐批重新搜索，每批追加后重新评估覆盖度。最多追加 3 轮，之后即使未完全覆盖也以"部分覆盖"状态产出 source-pack，并在报告中显式标记未覆盖项。
• 超时降级：Research Gate 的总时间上限为 120 秒。超时后立即终止搜索，将已收集的资料打包为 source-pack，在元数据中标记 "completeness": "degraded" 和未完成的搜索项。这个降级策略至关重要——Research Gate 本身不能成为阻塞链，它必须在一定时限内向 Author Gate 交付一份"尽力而为"的资料包。
• 标记风险区域：所有降级和未覆盖的情况必须显式写入 source-pack 的风险标记区段。Author Gate 读取 source-pack 时看到风险标记，可以在生成代码时采取更保守的策略（如添加 TODO 注释、避免对标记区域做大范围重构）。
• 人工升级路径：当 research-evidence.json 中的 "completeness" 为 "degraded" 且 "coverage_ratio" 低于 0.5 时，触发 人工审批流程——在进入 Author Gate 之前暂停，让人类确认"以当前信息量开始写代码是否可接受"。这是一个安全阀，不是常态流程。

3.5 Research Gate 通过证据 Schema

下面是 Research Gate 通过时产出的 research-evidence.json 完整 schema——它是责任链模型中"证据不灭"原则的落地形式：

	{
	  "gate": "RESEARCH",
	  "task_id": "agent-release-gate-design",
	  "timestamp": "2026-06-07T10:23:41Z",
	  "verdict": "PASSED",
	  "evidence": {
	    "keywords": {
	      "extracted": ["task dashboard", "agent status", "task state machine", "pipeline visualization"],
	      "covered": 4,
	      "total": 4,
	      "coverage_ratio": 1.0,
	      "uncovered": []
	    },
	    "reference_sources": {
	      "found": 6,
	      "minimum_required": 6,
	      "items": [
	        {
	          "type": "code_file",
	          "path": ".agent-workspace/task_dashboard.py",
	          "relevance": "现有 dashboard 实现，新功能需兼容其输出接口",
	          "snippet": "def render_task_table(tasks: list[Task]) -> str:"
	        },
	        {
	          "type": "doc",
	          "path": "en/posts/agent-state-machine-design.html",
	          "relevance": "任务状态机定义，dashboard 需展示的状态转移路径",
	          "snippet": "IDLE → ASSIGNED → RUNNING → WAITING → COMPLETED"
	        },
	        {
	          "type": "doc",
	          "path": "en/posts/agent-context-protocol-design.html",
	          "relevance": "上下文协议中 task context 的结构定义",
	          "snippet": "\"task_context\": {\"task_id\": \"...\", \"state\": \"...\"}"
	        },
	        {
	          "type": "git_log",
	          "path": "REPO_ROOT",
	          "commit": "6644153",
	          "relevance": "当前 dashboard 的最后一次修改，了解现有代码基线",
	          "snippet": "[hermes] Add task_dashboard.py — read-only task status dashboard"
	        },
	        {
	          "type": "config",
	          "path": ".agent-workspace/config.yaml",
	          "relevance": "仓库的 Agent 工作空间配置，dashboard 需读取的路径约定",
	          "snippet": "tasks_dir: .agent-workspace/tasks"
	        },
	        {
	          "type": "external_doc",
	          "url": "https://docs.python.org/3/library/datetime.html",
	          "relevance": "时间戳格式化与时间计算 API 参考",
	          "snippet": "datetime.fromisoformat()"
	        }
	      ]
	    },
	    "faq_candidates": [
	      {
	        "question": "如果 task 目录下缺少 state.json 文件，dashboard 如何处理？",
	        "risk_level": "medium",
	        "mitigation_hint": "返回 UNKNOWN 状态并标记为 'corrupted'"
	      },
	      {
	        "question": "如果同时有多个 Agent 在修改 task 文件，dashboard 的读取是否可能读到不一致的状态？",
	        "risk_level": "high",
	        "mitigation_hint": "dashboard 只做只读快照，冲突由文件系统原子性保证"
	      },
	      {
	        "question": "如果 .agent-workspace 目录不存在怎么办？",
	        "risk_level": "low",
	        "mitigation_hint": "优雅降级，返回空列表并输出警告"
	      }
	    ],
	    "internal_link_suggestions": [
	      {"path": "/zh/posts/agent-state-machine-design.html", "anchor": "任务状态定义"},
	      {"path": "/zh/posts/agent-context-protocol-design.html", "anchor": "task context 结构"},
	      {"path": "/zh/posts/agent-observability.html", "anchor": "任务执行监控"}
	    ],
	    "risk_flags": []
	  },
	  "metadata": {
	    "duration_ms": 8450,
	    "search_rounds": 1,
	    "completeness": "full"
	  },
	  "next_gate": "AUTHOR"
	}
	

这个 schema 的几个关键设计意图："verdict" 是最终判决（PASSED / DEGRADED / FAILED），不是浮动的置信度分数——Gate 必须给出可执行的是/否决策；"coverage_ratio" 是自动可计算的目标值，不需要人类解读；"faq_candidates" 带着 "mitigation_hint"——Research Gate 不仅提出问题，还给出解决方向的建议，这些建议会成为 Author Gate 的约束输入。通过 结构化消息 Schema 将这些字段在 Gate 间传递，确保 Author Gate 收到的不是一坨纯文本，而是带类型的结构化上下文。

3.6 Research Gate 与 Author Gate 的边界

最后，必须明确 Research Gate 和下一个 Author Gate 之间的绝对边界：

• Research 负责 know-what：要做什么、已有信息是什么、已知的风险是什么、相关资源在哪里。它的产物是声明式的——描述现状，不定义方案。
• Author 负责 know-how：怎么实现、用什么方案、代码怎么写。它接收 Research 产出的 source-pack，但产出是命令式的——.py、.ts、.yaml 等实际代码文件。

这条边界不是在建议，而是在强制执行：Research Gate 通过之前，Author Gate 不可被触发。这条规则由 Agent 状态机 中的状态转移守卫保证——状态机在 RESEARCH_PASSED 之前不会接受任何 AUTHOR 相关的事件。如果 Research 降级通过（"completeness": "degraded"），状态机会将标记传递给 人工审批工作流，在 Author 启动前插入一个可选的 human-in-the-loop 确认点。Gate 之间的消息传递全部走 Agent 消息 Schema——不是临时文件、不是环境变量、不是"上一个 Gate 的 stdout 管道到下一个 Gate 的 stdin"。

一句话：Research Gate 是 Agent 的"三思而后行"——让它在动笔之前，先证明它知道自己不知道什么。

4. Layer 2：Author Gate — 写作者空间，变更是草稿

Research Gate 让 Agent 停下了盲写的惯性，产出了结构化的 source-pack。现在进入第二个关卡：Author Gate——这是整个发布流程中唯一实际生成内容的阶段，但有严格的约束：所有产出物在通过下游 Gate 之前，状态永远是 draft。这不是不信任，而是给了 Writer Agent 一个"放心写"的承诺——你不需要在写作的同时审视自己的质量，把审查留给后续 Gate。

4.1 Author Gate 的定位

Author Gate 的执行者是 Writer Agent（如 Claude Code），工作环境是隔离的作者空间（参见 Agent 代码沙箱设计——Writing Sandbox 提供了可回滚、可快照的写作环境）。Author Gate 的输入有两个来源：一是来自 Brief Hermes Agent 的 brief.md，定义了任务规格和验收标准；二是来自 Research Gate 的 source-pack.md，提供了研究资料和风险标记。Writer Agent 必须先读完这两份输入，才能开始生成。

Author Gate 的核心设计原则可以归纳为三条：

1. 所有产出物都是 draft：无论生成的是 HTML、Markdown、Python 还是 YAML，文件创建后立即标记为 draft 状态。draft 不是"不完整"，而是"未经下游 Gate 验证"——这一定义由 Agent 状态机 中的 AUTHOR_DRAFT 状态强制执行。
2. Writer 不能自我审查：Writer 和 Reviewer 必须是不同 Agent。这不是信任问题——同一 Agent 刚生成完代码就立刻 review，和人类作者写完文章立刻校对一样，看到的不是实际产出，而是脑中残留的"意图"。认知新鲜度是 Reviewer 有效性的前提（详见 Agent 状态机设计 中 reviewer 分配策略）。
3. brief.md 是结构化的上下文协议：brief 不是一段自由文本提示词。它是 Agent 上下文协议 的一个实例——包含任务边界、验收标准、禁止操作、预期产出物列表。Author Gate 必须在开始生成前解析这些约束字段（见下文 schema），写入执行上下文。

4.2 输入与输出

4.3 通过条件

Author Gate 的通过条件聚焦于"是否完成了生成任务"，而非"生成得好不好"——后者是 QA 和 REVIEW Gate 的职责。三项条件：

1. 所有必需文件已创建：对照 brief.md 中的 expected_outputs 字段，逐一核对文件是否存在。缺少任何必需文件则阻断。
2. 无空文件：每个产出物文件的大小必须 > 0 字节。空文件意味着生成过程被中断或写入了占位符但未填充内容。
3. 基本格式检查通过：对于 HTML 文件，必须有 <!DOCTYPE>、<html>、闭合标签；对于 Python 文件，必须能被 ast.parse() 成功解析（不要求逻辑正确，只要语法有效）；对于 Markdown，header 和段落结构必须能被解析器识别。

4.4 brief.md 的结构化 Schema

下面是一个 brief.md 的内容结构——它不仅是提示词，更是 Writer Agent 的输入协议。brief 通过 Agent 上下文协议 从 Brief Hermes Agent 传递到 Writer Agent，确保后者收到的不是自然语言碎片，而是一个带类型的、可解析的任务规格：

	{
	  "task_id": "agent-release-gate-design",
	  "brief_version": "1.0",
	  "generated_by": "Brief Hermes Agent",
	  "generated_at": "2026-06-07T10:25:00Z",
	  "spec": {
	    "title": "Hermes 任务 Dashboard 可视化",
	    "description": "基于现有 task_dashboard.py，增加状态过滤、时间线视图和 Gate 进度条",
	    "acceptance_criteria": [
	      "支持按状态过滤（IDLE/ASSIGNED/RUNNING/WAITING/COMPLETED/FAILED）",
	      "时间线视图展示任务状态转移历史",
	      "Gate 进度条显示当前任务在 QA→REVIEW→CONFORMITY→VERIFIED 中的位置"
	    ]
	  },
	  "constraints": {
	    "must_not": [
	      "修改 .agent-workspace/ 之外的任何现有文件",
	      "引入除 Python 标准库之外的依赖",
	      "在 dashboard 中写入任何数据（只读）"
	    ],
	    "must": [
	      "保持与现有 task_dashboard.py 的输出接口兼容",
	      "所有新增函数须有 docstring"
	    ]
	  },
	  "expected_outputs": [
	    {"path": ".agent-workspace/task_dashboard.py", "type": "python", "action": "modify"},
	    {"path": ".agent-workspace/reports/task-dashboard.md", "type": "markdown", "action": "modify"}
	  ],
	  "context_refs": {
	    "source_pack": ".agent-workspace/tasks/agent-release-gate-design/source-pack.md",
	    "related_docs": [
	      "/zh/posts/agent-state-machine-design.html",
	      "/zh/posts/agent-context-protocol-design.html"
	    ]
	  }
	}
	

这个 brief 的关键设计意图：constraints.must_not 不是建议，是硬约束——Writer Agent 在每次文件写入前必须检查目标路径是否在禁止列表中；expected_outputs 是 Author Gate 通过条件的对照清单，不仅列文件路径，还声明了操作类型（create/modify）——如果 brief 说 modify 但目标文件不存在，Author Gate 应阻断而非擅自 create；context_refs 将 Research Gate 的产出与本次任务关联，形成可追溯的上下文链。

4.5 Author Gate 通过证据

Author Gate 通过时产出 author-evidence.json——它记录了"谁、在什么输入下、生成了什么"的完整轨迹，是后续 Gate 审计的基础：

	{
	  "gate": "AUTHOR",
	  "task_id": "agent-release-gate-design",
	  "timestamp": "2026-06-07T10:32:15Z",
	  "verdict": "PASSED",
	  "writer": {
	    "agent": "Claude Code",
	    "session_id": "sess-a7f3b2c1"
	  },
	  "inputs": {
	    "brief_version": "1.0",
	    "brief_checksum": "sha256:a1b2c3d4e5f6...",
	    "source_pack_version": "1.0",
	    "source_pack_checksum": "sha256:f6e5d4c3b2a1..."
	  },
	  "outputs": [
	    {
	      "path": ".agent-workspace/task_dashboard.py",
	      "action": "modified",
	      "lines_added": 87,
	      "lines_removed": 3,
	      "draft_checksum": "sha256:x1y2z3w4...",
	      "format_check": {"type": "python_ast_parse", "result": "pass"}
	    },
	    {
	      "path": ".agent-workspace/reports/task-dashboard.md",
	      "action": "modified",
	      "lines_added": 42,
	      "lines_removed": 0,
	      "draft_checksum": "sha256:a9b8c7d6...",
	      "format_check": {"type": "markdown_parse", "result": "pass"}
	    }
	  ],
	  "check_results": {
	    "all_expected_files_exist": true,
	    "no_empty_files": true,
	    "format_checks_passed": 2,
	    "format_checks_total": 2
	  },
	  "next_gate": "QA"
	}
	

一个值得注意的细节：draft_checksum 是产出文件在 Author Gate 通过时的内容指纹。下游 Gate（QA、REVIEW）在读取文件时会比对 checksum——如果内容在 Gate 之间被外部进程修改，下游 Gate 将标记 "tamper_detected": true 并阻断流程。这是 Agent 安全评估 中"变异检测"原则的具体落地。

一句话：Author Gate 给 Writer Agent 搭建了一个"只管写、别管审"的工作空间。产出物都是 draft，审查全部留给下游——这解放了 Writer 的创造力，也明确了责任边界：写和审，永远不是同一个脑袋。

5. Layer 3：QA Gate — 规则化检验而非人工复核

Author Gate 产出了一组 draft 文件，Writer Agent 宣告"我写完了"。现在轮到 QA Gate——它是整个责任链中第一个检验层。QA Gate 做一件事且只做一件事：运行确定性检查，验证结构完整性。它不理解内容语义，不做主观判断，不评价代码好坏——它只回答一个二进制问题：产出的文件，结构上是否完整？

5.1 为什么 QA 必须与 REVIEW 分离

传统软件开发中，"QA"往往是一个混装术语——既有 lint 和测试（确定性），又有人工 code review（主观判断）。在 Agent 生产场景下，必须将二者严格分离，否则会出现两个系统性问题：

• REVIEW 被琐碎消耗：如果人类/Agent Reviewer 收到的变更里还有未通过 lint 的代码、缺失必要章节的文档、跑不过测试的逻辑，reviewer 的注意力会被格式和基础错误吃光，无暇顾及"方案对不对"这个核心问题。QA 在前方拦截所有确定性错误，REVIEW 只接收结构完整的变更。
• 修复循环过长：如果 REVIEW 发现一个 lint 错误，打回给 Author → 修复 → 再次 REVIEW——这个循环的瓶颈在人类 review 的等待时间。QA 是自动的：Author 完成后立即触发，QA 失败 → Agent 定位修复 → 重新 QA，整个循环在数秒到数分钟内完成，不消耗人类时间。

简言之：QA Gate 是自动化、规则驱动的，每次运行结果完全可复现；REVIEW Gate 是语义判断，需要理解内容。两者分离的收益是 REVIEW 效率的指数级提升——人类 reviewer 看到的永远是通过了 QA 的变更。

5.2 检查项与通过条件

QA Gate 的检查项全部是可自动验证的布尔条件。每一项有明确的阻断/警告分级：

1. 文件存在且非空（阻断）：与 Author Gate 的条件重叠但独立运行——Author 通过后文件可能因外部操作被删除或截断。QA Gate 在沙箱中（参见 Agent 代码沙箱设计）重新验证此条件。
2. Lint 通过（阻断 error，警告 warning）：运行 ruff / eslint / prettier——不要求零 warning，但零 error 是必须条件。warning 数量记入报告但不阻断。
3. Schema 验证（阻断）：若产出物有对应的 JSON Schema（如 Agent 消息 Schema 中的 post.schema.json），QA 运行 jsonschema.validate() 或等价的 schema 校验器。对于 HTML 文件，检查必要元素（<title>、<meta description>、<h1>）是否存在且非空。
4. 必要章节/函数存在（阻断）：对应 brief.md 中的 acceptance_criteria——例如 brief 要求"状态过滤功能"，QA 检查产出代码中是否包含匹配的函数签名或 UI 组件。这一检查不验证函数逻辑，只验证"声明了该功能"。
5. 测试通过（阻断）：运行 pytest（Python）、npm test（JS）或项目配置的测试套件。若有覆盖率要求（如 ≥ 80%），一并检查。
6. 死链接检查（警告）：对文档类产出物运行 lychee 扫描内部链接。死链接不阻断（可能是尚未创建的目标页面），但全部记入报告供 REVIEW 参考。
7. 文件大小检查（警告）：对新增文件检查大小是否超过项目阈值（如单文件不超过 500 行）。超额发出警告但不阻断——大文件可能是合理的，但值得 REVIEW 关注。

5.3 失败响应：可操作的 bug report

QA Gate 失败时，返回的不是模糊的"不通过"。它返回一个结构化的失败项列表，每项包含失败位置、失败类型、违反的规则和修复方向。Agent 可以将这个列表直接用于定位和修复——不需要"猜哪里不对"：

	{
	  "gate": "QA",
	  "task_id": "agent-release-gate-design",
	  "timestamp": "2026-06-07T10:33:01Z",
	  "verdict": "FAILED",
	  "failures": [
	    {
	      "check": "lint",
	      "tool": "ruff",
	      "location": ".agent-workspace/task_dashboard.py:45:1",
	      "rule": "F841",
	      "message": "Local variable `status_count` is assigned but never used",
	      "severity": "error",
	      "fix_hint": "移除未使用的变量或将其用于后续逻辑"
	    },
	    {
	      "check": "schema_valid",
	      "location": ".agent-workspace/reports/task-dashboard.md",
	      "rule": "missing_required_section",
	      "message": "缺少必要章节: '## 使用说明'",
	      "severity": "error",
	      "fix_hint": "在文档中添加 ## 使用说明 章节，描述 dashboard 的启动方式和参数"
	    },
	    {
	      "check": "dead_link",
	      "tool": "lychee",
	      "location": ".agent-workspace/reports/task-dashboard.md:12",
	      "message": "死链接: ./nonexistent-file.md (404)",
	      "severity": "warning",
	      "fix_hint": "检查目标文件是否存在，或更换为有效链接"
	    }
	  ],
	  "summary": {
	    "total_checks": 7,
	    "passed": 4,
	    "failed": 2,
	    "warnings": 1,
	    "blocking_failures": 2
	  },
	  "retry_strategy": "AUTO_RETRY",
	  "max_retries": 3
	}
	

这个报告的设计原则是"每一个失败都能被 Agent 定位"：location 精确到文件和行号；rule 是机器可读的规则代码（Agent 可以按规则代码查询详细文档）；fix_hint 是修复方向——不需要 AI 推理"可能哪里错了"，直接告诉它错在哪、怎么修。retry_strategy 定义了自动重试策略：QA 失败后 Agent 修复并重新提交 Author+QA 循环，最多 3 次。超过 3 次仍未通过，任务升级为人工介入的 BLOCKED 状态。

5.4 QA 执行环境：沙箱隔离

一条关键的安全原则：QA Gate 的所有检查在独立沙箱中执行（参见 Agent 代码沙箱设计 和 Agent 安全评估）。沙箱提供只读挂载的源码树和隔离的网络环境——lint 不会意外修改文件、dead link 检查不会向外部发起未授权请求（目标链接需在安全白名单中）、测试运行不会污染主机文件系统。

执行一个 QA 检查的典型 Shell 命令序列如下：

	# QA Gate 在沙箱中执行的检查脚本
	#!/bin/bash
	set -e

	TASK_DIR=".agent-workspace/tasks/agent-release-gate-design"
	REPORT_DIR=".agent-workspace/reports"

	echo "=== QA Gate: 开始检查 ==="

	# 1. 文件存在且非空
	for f in "$TASK_DIR"/*.py "$REPORT_DIR"/*.md; do
	  if [ ! -s "$f" ]; then
	    echo "FAIL: $f 不存在或为空" >&2
	    exit 1
	  fi
	done

	# 2. Lint 检查
	ruff check "$TASK_DIR"/*.py --exit-zero --output-format=json > lint-report.json

	# 3. 测试运行
	pytest "$TASK_DIR"/test_*.py --cov --json-report --json-report-file=pytest-report.json

	# 4. 死链接检查
	lychee --format=json "$REPORT_DIR"/*.md > link-report.json 2>&1 || true

	# 5. HTML 结构检查
	for f in zh/posts/*.html; do
	  grep -q '<title>' "$f" || echo "WARN: $f 缺少 <title>"
	  grep -q '<meta name="description"' "$f" || echo "WARN: $f 缺少 meta description"
	done

	echo "=== QA Gate: 检查完成 ==="
	

沙箱超时设为 300 秒——足够绝大多数检查完成，同时防止死循环或网络挂起导致 Gate 本身成为阻塞源。超时后 QA Gate 以 "completeness": "degraded" 状态产出部分报告，列出已完成和未完成的检查项。

5.5 QA 通过证据：qa-report.json

QA Gate 通过时产出 qa-report.json——不仅是"通过了"的声明，更是完整检查结果的审计轨迹：

	{
	  "gate": "QA",
	  "task_id": "agent-release-gate-design",
	  "timestamp": "2026-06-07T10:34:20Z",
	  "verdict": "PASSED",
	  "sandbox": {
	    "id": "sbx-q7w8e9r0",
	    "image": "agent-qa-sandbox:v2.1",
	    "duration_ms": 28450
	  },
	  "results": [
	    {"check": "file_existence", "passed": true, "files_checked": 2},
	    {"check": "non_empty", "passed": true},
	    {"check": "lint", "tool": "ruff", "passed": true, "errors": 0, "warnings": 3},
	    {"check": "schema_valid", "passed": true, "schema": "post.schema.json"},
	    {"check": "required_elements", "passed": true, "elements_found": ["概述", "安装", "使用说明", "配置"]},
	    {"check": "unit_test", "tool": "pytest", "passed": true, "total": 12, "passed": 12, "coverage": 0.87},
	    {"check": "dead_link", "tool": "lychee", "passed": true, "links_checked": 24, "dead": 0},
	    {"check": "security_scan", "tool": "bandit", "passed": true, "severity_high": 0, "severity_medium": 0},
	    {"check": "file_size", "passed": true, "largest_file_lines": 312, "threshold": 500}
	  ],
	  "summary": {
	    "total_checks": 9,
	    "passed": 9,
	    "failed": 0,
	    "warnings": 3
	  },
	  "next_gate": "REVIEW"
	}
	

注意 qa-report.json 本身遵循 Agent 消息 Schema 规范——它的结构是声明式的，可被下游 Gate 直接解析。REVIEW Gate 读取 qa-report.json 时，可以跳过已通过的检查项（如 lint），将注意力集中在 warning 项上（如 3 个 lint warning），作为 review 的参考线索。这种 Gate 间结构化消息传递，正是 Agent 上下文协议 的核心机制。

一句话：QA Gate 是一道机器守卫——它不评判你的代码好不好，只确认你的代码站得住。把确定性检查全部自动化，把人类的注意力留给真正需要判断力的事。

6. Layer 4：Review Gate — 语义审查，捕捉 QA 规则查不到的问题

QA Gate 通过了——lint 零错误、测试全绿、schema 校验通过。Writer Agent 产出的文件结构完整。但一个结构完整的文件仍然可以是内容错误的。Review Gate 就站在这个断层的正中央：QA 检查"格式对不对"，Review 检查"东西对不对"。它是整个责任链中唯一需要语义理解的关卡，也是唯一可能引入人类判断的环节。

6.1 Review 与 QA 的本质区别

将 QA 和 Review 混为一谈是 Agent 发布流程中最常见的架构错误。两者的差异不仅是"自动化 vs 人工"，而是可判定性问题：QA 的每一项检查都是图灵可判定的——lint 规则、测试断言、schema 校验，全部可以用有限步骤得出确定的通过/失败。Review 面对的是语义正确性——代码是否实现了正确的方案、设计方案是否合理、是否存在幻觉（调用了不存在的 API 或虚构的配置 key）、是否误解了需求。这些问题没有机械算法能给出二进制答案。

具体来说，Review Gate 关注的四类问题全部落在 QA 的盲区里：

1. 代码异味与设计合理性：QA 通过了 lint，但函数有 12 个参数且没有类型注解——lint 不管参数数量。QA 通过了测试，但测试全是 mock，从未验证实际 I/O 行为——pytest 不管 mock 覆盖率。
2. 需求误解：brief 要求"按状态过滤"，Writer 实现了按优先级过滤——函数签名正确、lint 通过、测试也写了（测试了优先级过滤逻辑），但功能完全对不上需求。
3. 幻觉 API：Writer 调用了 agent_registry.get_active_agents()，但系统中根本不存在 agent_registry 模块。QA 不做跨文件的符号解析——它只检查当前文件的 lint 和测试。Review Gate 必须验证每一个导入和 API 调用是否指向真实存在的模块和方法。
4. 内部链接合理性：文档产出了 15 条内部链接，QA 验证它们都不死（200 OK）。但其中 4 条链接指向了语义无关的页面——链接到了 agent-cost-analysis-design 而非 agent-state-machine-design。死链接是 QA 的事，语义错误的链接是 Review 的事。

6.2 通过条件与失败响应

Review Gate 的通过条件围绕"无严重语义缺陷"定义，而非"完美"——语义审查的边界是阻断严重问题，记录轻度瑕疵：

1. 无幻觉 API 调用：Reviewer（LLM Agent 或人类）逐条检查产出物中的所有第三方调用和内部模块引用。任何指向不存在模块的调用标记为 "severity": "critical" 并阻断。
2. 需求对齐：逐一比对 brief.md 的 acceptance_criteria 与实际产出物。功能缺失标记阻断，功能偏差（实现与要求不同但方向相近）标记警告并记录差异。
3. 内部链接语义正确：每条链接的目标页面字段（标题、描述、关键词）与链接上下文做 embedding 相似度对比。相似度低于阈值（如 0.3）标记为可疑链接并阻断。
4. 技术方案合理性：这是唯一的主观判断维度。Reviewer 对架构决策、算法选择、安全实践做定性评估。评分分为 APPROVED / CHANGES_REQUESTED / REJECTED 三级。

失败响应的设计原则是"不阻断但记录"与"阻断"的分级：幻觉 API、需求缺失、严重方案缺陷 → 阻断，返回 Writer 修改。代码异味、轻度偏差 → 不阻断，记录在 review 报告中，作为后续 CONFORMITY Gate 的参考上下文。返回给 Writer 的修改请求不是一句模糊的"请修改"，而是一个可执行的问题区域标注：

	{
	  "gate": "REVIEW",
	  "task_id": "agent-release-gate-design",
	  "timestamp": "2026-06-07T11:02:00Z",
	  "verdict": "CHANGES_REQUESTED",
	  "reviewer": {"agent": "opencode", "session_id": "sess-r3v13w"},
	  "issues": [
	    {
	      "type": "hallucinated_api",
	      "severity": "critical",
	      "location": ".agent-workspace/task_dashboard.py:142",
	      "detail": "调用了 agent_registry.get_active_agents()，但模块 agent_registry 不存在于仓库中",
	      "suggestion": "使用 .agent-workspace/tasks/ 目录扫描替代 agent_registry"
	    },
	    {
	      "type": "requirement_misalignment",
	      "severity": "major",
	      "location": ".agent-workspace/task_dashboard.py:78-95",
	      "detail": "实现了按优先级过滤，但 brief 要求的是按状态过滤",
	      "suggestion": "将 filter_by_priority() 替换为 filter_by_status()，状态值来自 state.json"
	    },
	    {
	      "type": "code_smell",
	      "severity": "minor",
	      "location": ".agent-workspace/task_dashboard.py:203",
	      "detail": "函数 render_table() 有 12 个参数，建议封装为 dataclass",
	      "suggestion": "创建 TableConfig dataclass 替代裸参数列表"
	    }
	  ],
	  "summary": {"critical": 1, "major": 1, "minor": 1},
	  "next_action": "RETURN_TO_AUTHOR"
	}
	

6.3 Reviewer 必须是不同的 Agent

这是 Review Gate 最关键的设计决策——reviewer 与 writer 不能是同一个 Agent。理由不是"防止作弊"，而是一个被反复验证的认知规律：刚生成完内容的 Agent 在审查时会看到自己"意图中"的产出而非实际产出。眼睛扫过一行幻觉 API 调用，大脑里补齐了本应存在的模块名。这和人写完文章立刻校对看不到笔误是一个道理——你读的是记忆里的句子，不是屏幕上的字。

因此，Writer Agent（如 Claude Code）产出的内容，必须由 Reviewer Agent（如 opencode）独立审查。在 人工审批工作流 的扩展模式下，Review 环节还可引入人类审查者，形成 "Agent Review → Human Review" 两级结构。Agent 状态机 通过 REVIEW_PASSED 状态转移守卫确保：Writer 自身永远不能给自己的产出物标记 REVIEW_PASSED——这个事件只能由 Reviewer Agent 发出。

下面的 Shell 命令展示了 Reviewer Agent 启动 review 任务的标准流程——注意它加载的是 Writer 的产出物，而不是自己的生成缓存：

	# Reviewer Agent 启动 review 任务的入口脚本
	#!/bin/bash
	set -e

	TASK_ID="agent-release-gate-design"
	WRITER_OUTPUT=".agent-workspace/tasks/$TASK_ID/author-output"
	BRIEF=".agent-workspace/tasks/$TASK_ID/brief.md"
	SOURCE_PACK=".agent-workspace/tasks/$TASK_ID/source-pack.md"
	QA_REPORT=".agent-workspace/tasks/$TASK_ID/qa-report.json"

	echo "=== Review Gate: $TASK_ID ==="
	echo "Reviewer: opencode (非 Writer Agent)"

	# 加载 Writer 的产出物（只读）
	opencode review \
	  --task-id "$TASK_ID" \
	  --brief "$BRIEF" \
	  --source-pack "$SOURCE_PACK" \
	  --qa-report "$QA_REPORT" \
	  --output-dir "$WRITER_OUTPUT" \
	  --output-format json \
	  > .agent-workspace/tasks/$TASK_ID/review-report.json

	# 解析 review 判决
	VERDICT=$(jq -r '.verdict' .agent-workspace/tasks/$TASK_ID/review-report.json)

	if [ "$VERDICT" = "APPROVED" ]; then
	  echo "REVIEW_PASSED → 进入 CONFORMITY Gate"
	  # 触发状态机事件 REVIEW_PASSED
	elif [ "$VERDICT" = "CHANGES_REQUESTED" ]; then
	  echo "RETURN_TO_AUTHOR → Writer Agent 根据 review 修改"
	  # 状态机切换到 AUTHOR_REVISING
	fi
	

一句话：Review Gate 是整个责任链的"理解层"——前面的 Gate 确认文件结构完整，这一层确认内容意思正确。把语义判断和格式检查分开，两者才能各自做好各自的事。

7. Layer 5：Conformity Gate — 上游标准验证，跨项目一致性

QA 确认了结构完整，Review 确认了语义正确。现在产出物在单个任务的意义上是合格的——但它是否与整个仓库的全局标准一致？这就是 Conformity Gate 的独特职责：不与 QA 抢检查项，不与 Review 抢语义判断——它只检查跨越单个任务的、项目级别的约束。

7.1 Conformity 与 QA 的分界线

一个容易被忽视的架构细节：QA 和 Conformity 在检查内容上可能有交集（都检查 HTML 结构、都运行 link 检查），但它们的视角和组织方式完全不同。QA 以单文件为粒度——"这个文件有没有 <title>？"Conformity 以项目为粒度——"所有文件使用相同格式的 <title> 吗？en/ 和 zh/ 两个版本对应的 <title> 是双向翻译吗？"简单说：QA 做检查，Conformity 做对齐。

Conformity Gate 的检查范围可以概括为三类跨项目约束：

1. SEO 与国际化标准：hreflang 标签的互相指向是否正确（en → zh、zh → en、x-default 指向）；<html lang> 属性是否与 hreflang 一致；JSON-LD 中的 inLanguage 字段是否与页面语言匹配；canonical URL 是否指向正确的语言版本。
2. 模板与结构约定：所有文章类型页面是否有统一的 footer 格式和 breadcrumb 结构；<meta> 标签的排列顺序是否一致；OG 标签的 og:image 是否指向项目的默认 OG 图片（而非缺失或指向本地路径）；出版日期格式是否统一为 ISO 8601。
3. 内链覆盖率：新文章（如本文）是否在至少 3 篇相关文章中被引用——Conformity 不仅检查新文章的 outbound 链接，还检查已有文章是否更新了 inbound 链接。一个内容孤岛即便自身质量再高也是不合规的。

7.2 自动修复与阻断的分级策略

Conformity Gate 的失败处理比 QA 更精细：可自动修复的项自动修复后重检，不可自动修复的项阻断。这个区分至关重要——Conformity 涉及大量格式对齐工作，让 Agent 自动纠正比打回 Writer 修改高效得多：

7.3 通过条件

Conformity Gate 的通过条件是全量、不可降级的——不同于 Research Gate 的"尽力而为"，Conformity 检查的每一项都必须明确通过（自动修复后通过也算通过）：

1. hreflang 双向正确：对于存在双语版本的页面，en → zh 和 zh → en 的 <link rel="alternate" hreflang="..."> 必须互相指向且 URL 正确。缺失任何一端 → 自动修复。
2. JSON-LD 完整性：Article 类型必须包含 headline、description、datePublished、author、inLanguage；BreadcrumbList 必须有至少 2 个 itemListElement 且最后一个 item 指向当前页面。缺失字段 → 自动修复。
3. SEO 标签完整：<title>、<meta name="description">、<meta name="keywords">、<link rel="canonical">、OG 标签（og:title、og:description、og:url、og:image）全部存在且非空。缺失 → 自动修复。
4. 内链达到最低数量：新页面必须有至少 3 条指向其他内部页面的链接（outbound），且至少被 1 篇已有文章引用（inbound）。outbound 不足 → 阻断，inbound 不足 → 阻断。
5. HTML 结构规范：<nav class="breadcrumb"> 必须存在且格式一致；<footer> 必须位于 </main> 之后；<article> 必须包含 <h1> 和 <time>。偏离 → 阻断。

7.4 Conformity 执行脚本与证据

下面是 Conformity Gate 执行检查的 Shell 脚本——它展示了自动修复优先的策略：先尝试修复，修复不了才阻断：

	#!/bin/bash
	# Conformity Gate: 跨项目一致性验证
	set -e

	TASK_DIR=".agent-workspace/tasks/agent-release-gate-design"
	REPORT="$TASK_DIR/conformity-report.json"
	ERRORS=0

	echo "=== Conformity Gate: 跨项目标准检查 ==="

	# 1. hreflang 双向验证（自动修复）
	for html_file in zh/posts/*.html; do
	  basename=$(basename "$html_file")
	  en_file="en/posts/$basename"
	  if [ -f "$en_file" ]; then
	    # 检查 en 版本是否链接到 zh 版本
	    if ! grep -q "hreflang=\"zh\".*$basename" "$en_file"; then
	      echo "AUTO-FIX: 补全 $en_file 的 hreflang zh 链接"
	      # 自动注入 hreflang 标签
	    fi
	    # 检查 zh 版本是否链接到 en 版本
	    if ! grep -q "hreflang=\"en\".*$basename" "$html_file"; then
	      echo "AUTO-FIX: 补全 $html_file 的 hreflang en 链接"
	    fi
	  fi
	done

	# 2. JSON-LD 完整性（自动修复缺失字段）
	jq -e '.headline and .description and .datePublished and .author and .inLanguage' \
	  <(sed -n '/application\/ld+json/,/<\/script>/p' zh/posts/agent-release-gate-design.html \
	    | sed '1d;$d') 2>/dev/null || {
	  echo "AUTO-FIX: JSON-LD 字段缺失，从 meta 标签提取补全"
	}

	# 3. 内链覆盖率（不可自动修复，阻断）
	outbound=$(grep -c 'href="/zh/posts/' zh/posts/agent-release-gate-design.html || true)
	if [ "$outbound" -lt 3 ]; then
	  echo "BLOCK: 新页面 outbound 内链不足（当前: $outbound，要求 ≥ 3）"
	  ERRORS=$((ERRORS + 1))
	fi

	# 4. SEO 标签完整性（自动修复）
	for tag in "og:title" "og:description" "og:url" "og:image"; do
	  if ! grep -q "property=\"$tag\"" zh/posts/agent-release-gate-design.html; then
	    echo "AUTO-FIX: 缺失 $tag 标签"
	  fi
	done

	if [ "$ERRORS" -gt 0 ]; then
	  echo "BLOCK: $ERRORS 个不可自动修复的问题"
	  exit 1
	fi

	echo "=== Conformity Gate: PASSED ==="
	

通过后产出 conformity-report.json：

	{
	  "gate": "CONFORMITY",
	  "task_id": "agent-release-gate-design",
	  "timestamp": "2026-06-07T11:15:30Z",
	  "verdict": "PASSED",
	  "auto_fixes_applied": [
	    {"check": "hreflang", "action": "补全 en→zh 双向链接", "files": ["en/posts/agent-release-gate-design.html"]},
	    {"check": "jsonld", "action": "从 meta 补全 datePublished 字段", "files": ["zh/posts/agent-release-gate-design.html"]}
	  ],
	  "results": [
	    {"check": "hreflang_bidirectional", "passed": true, "auto_fixed": true},
	    {"check": "jsonld_completeness", "passed": true, "auto_fixed": true},
	    {"check": "seo_tags_complete", "passed": true, "missing": []},
	    {"check": "internal_link_outbound", "passed": true, "count": 5, "minimum": 3},
	    {"check": "internal_link_inbound", "passed": true, "count": 1, "minimum": 1},
	    {"check": "html_structure", "passed": true, "deviations": []},
	    {"check": "bilingual_sync", "passed": true, "en_sections": 7, "zh_sections": 7}
	  ],
	  "summary": {"total": 7, "passed": 7, "auto_fixed": 2, "blocked": 0},
	  "next_gate": "VERIFIED"
	}
	

注意 bilingual_sync 检查——它比对 en/ 和 zh/ 两个版本的结构是否一致（章节数量、代码块数量、链接数量）。如果英文版有 7 个 <h2> 而中文版只有 5 个，Conformity 标记结构性差异并阻断——这不是翻译问题，是内容同步断裂。在 人工审批工作流 中，Conformity 的阻断项会触发人工确认：结构差异是有意为之（如某一语言版本特供内容）还是 Writer Agent 遗漏了。

一句话：Conformity Gate 不问"这个文件对不对"，它问"这个文件放进整个仓库里，看起来是不是和所有其他文件是一家人。"它是项目级别的格式对齐层——把每个任务的产出物校准到统一的全局标准上。

8. Layer 6：READY Gate — 发布前置检查的综合关卡

前面五层 Gate 各自独立完成了自己的检查：Research 收集了资料、Author 产出了草稿、QA 验证了结构、Review 确认了语义、Conformity 对齐了全局标准。现在，在真正动手发布之前，还需要一个综合裁判——它不新增检查项，而是汇总前面所有 Gate 的 evidence，做出最终的"可以发布"判决。这就是 READY Gate。

8.1 为什么需要 READY Gate

一个自然的疑问：如果前面每一层 Gate 都已经通过了，为什么还需要一个"汇总层"？答案在于跨 Gate 的联动故障。每层 Gate 的通过判决是基于当时的状态——但 Gate 之间的时间差可能意味着后续 Gate 的修复操作破坏了前序 Gate 的通过条件。例如：Conformity 的自动修复更新了 hreflang 标签，但这个修改可能引入了一个 lint 错误——QA Gate 不会再跑一次。Review 要求 Writer 修改了某个函数签名，但修改后的函数可能打破了 Conformity 的 schema 校验。

READY Gate 的职责就是解决这个"最后一个修改者问题"：在所有修改尘埃落定之后，重新审视完整的 evidence 链，确认没有跨层级的回归。它不是"再跑一遍所有检查"——那样太慢。它是检查 evidence 的完整性、一致性和时效性。

8.2 输入与通过条件

READY Gate 的输入是前面所有 Gate 产出的 evidence 链：research-evidence.json → author-evidence.json → qa-report.json → review-report.json → conformity-report.json。它不直接读取源码文件，而是审计 evidence 文件本身——这是一种元检查（meta-check）：

通过条件是一条严格的全量 AND 逻辑：所有 evidence 的 verdict 必须为 PASSED 或 APPROVED，没有任何 P0（阻断）或 P1（严重）缺陷处于未解决状态。此外，READY Gate 还执行三条最终的发布就绪检查：① SEO 要求满足（<title> 长度 30-60 字符、<meta description> 长度 120-160 字符、所有 OG 标签完整）；② 用户审批就绪（检查 人工审批工作流 是否已完成，approval token 是否存在且未过期）；③ 审计日志完整（审计日志 中该 task 的 gate 转移记录是否连贯、无跳跃）。

8.3 输出与失败响应

READY Gate 的输出是一份综合判决报告——包含每个子项的详细状态、整体 verdict 和下一步指令。下面是一个通过示例：

		{
		  "gate": "READY",
		  "task_id": "agent-release-gate-design",
		  "timestamp": "2026-06-07T11:22:00Z",
		  "verdict": "READY_TO_PUBLISH",
		  "evidence_chain": {
		    "research": {"verdict": "PASSED", "checksum": "sha256:a1b2...", "stale": false},
		    "author": {"verdict": "PASSED", "checksum": "sha256:c3d4...", "tamper_detected": false},
		    "qa": {"verdict": "PASSED", "checksum": "sha256:e5f6...", "blocking_failures": 0},
		    "review": {"verdict": "APPROVED", "checksum": "sha256:g7h8...", "unresolved_critical": 0},
		    "conformity": {"verdict": "PASSED", "checksum": "sha256:i9j0...", "blocked": 0}
		  },
		  "final_checks": {
		    "seo_requirements": {"title_length": 42, "desc_length": 148, "og_tags_complete": true, "passed": true},
		    "user_approval": {"status": "APPROVED", "token": "appr-20260607-001", "expires_at": "2026-06-08T00:00:00Z", "valid": true},
		    "audit_log_integrity": {"transitions_count": 6, "sequence_valid": true, "gaps": [], "passed": true}
		  },
		  "publish_readiness": {
		    "files_to_publish": ["zh/posts/agent-release-gate-design.html", "en/posts/agent-release-gate-design.html"],
		    "branch": "task/agent-release-gate-design",
		    "target_branch": "main",
		    "estimated_impact": "low"
		  },
		  "summary": {"total_checks": 8, "passed": 8, "failed": 0},
		  "next_gate": "DEPLOY"
		}
		

失败响应采用精确回退策略——不是笼统的"不通过"，而是指出哪一个 Gate 的 evidence 出了问题、需要回退到哪个 Gate 重跑：

• QA evidence 显示有 blocking_failures：回退到 QA Gate——说明 Conformity 修复后引入了新的 QA 问题，需重新跑 QA。
• Review evidence 显示有 unresolved critical：回退到 Review Gate——Writer 修改后 Reviewer 未重新确认。
• Evidence checksum 不匹配（tamper_detected）：阻断并告警——文件在 Gate 之间被外部进程修改，触发 审计日志 的完整性告警。
• 用户审批 token 过期：触发 人工审批工作流 重新申请——用户需再次确认发布意图。

一句话：READY Gate 是发布前的最后一道逻辑关卡——它不检查代码，它检查"检查代码的证据"。往前看，它确认所有 Gate 都认真履职了；往后看，它为 Deploy Gate 提供了一份完整的、可审计的发布许可。

9. Layer 7：Deploy Gate — 从仓库到线上的守门员

READY Gate 签发了发布许可。现在产出物需要从 Git 仓库的 feature 分支抵达生产环境。Deploy Gate 是代码离开仓库进入线上的最后一关——它不做质量检查（那些已经完成了），它只做一件事：确保部署过程的每一步都是受控的、可回滚的、有记录的。

9.1 Deploy Gate 的独特定位

Deploy Gate 与前面所有 Gate 有一个根本性的不同：前面的 Gate 操作的是文件和 evidence，Deploy Gate 操作的是基础设施。它要合并分支、推送远端、触发构建、等待部署完成、验证线上状态。这些操作每一步都可能失败——网络中断、构建超时、CDN 刷新延迟——而失败时的代价不再是"打回修改"，而是"线上挂了"。因此 Deploy Gate 的设计核心不是"快"，而是"安全"——每步操作前检查前置条件，每步操作后验证结果，任何异常立即中断并回滚。

Deploy Gate 的执行需要三条安全边界（参见 Agent 命令执行安全）：① 命令白名单——Deploy Gate 只能执行预定义的部署命令集（git merge、git push、hugo、rsync），任何不在白名单中的命令拒绝执行；② 环境隔离——部署操作在独立沙箱中执行（参见 Agent 运行时隔离），沙箱只有部署所需的权限，不能访问密钥管理器或数据库；③ 操作原子性——部署操作要么全部成功，要么全部回滚。不允许"合并了分支但构建失败"的半成品状态。

9.2 输入与通过条件

Deploy Gate 的输入有两个来源：一是前面所有 Gate 的通过证据（特别是 READY Gate 的 READY_TO_PUBLISH 判决），二是用户审批确认——用户必须通过 人工审批工作流 明确发送 发布 命令。Deploy Gate 不会基于任何自动化信号自行触发部署——这是安全设计的底线。

通过条件逐条严格：

1. 用户明确批准：审批工作流中存在有效的 发布 命令记录，且该命令的审批 token 未过期、未被撤销。审批 token 的有效期默认 4 小时——超过后需重新审批。
2. READY Gate 通过：ready-report.json 的 verdict 为 READY_TO_PUBLISH，且 timestamp 不早于 24 小时（防止基于过期 evidence 部署）。
3. 目标分支 clean：GitHub main 分支无未合并的冲突、无 ongoing deployment lock。Deploy Gate 在 merge 前获取分布式锁，确保同一时刻只有一个部署在进行。
4. 部署脚本零错误：构建（hugo）和同步（rsync）的退出码均为 0。任何非零退出码阻断部署。

9.3 部署报告

部署完成后，Deploy Gate 产出两份报告：一份人类可读的 deploy-report.md，一份机器可解析的 deploy-report.json。JSON 版本是后续 VERIFIED Gate 的输入：

		{
		  "gate": "DEPLOY",
		  "task_id": "agent-release-gate-design",
		  "timestamp": "2026-06-07T11:30:00Z",
		  "verdict": "DEPLOYED",
		  "deployment": {
		    "source_branch": "task/agent-release-gate-design",
		    "target_branch": "main",
		    "merge_commit": "a7f3b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9",
		    "build": {
		      "tool": "hugo",
		      "version": "0.126.0",
		      "exit_code": 0,
		      "duration_ms": 12340,
		      "warnings": []
		    },
		    "sync": {
		      "tool": "rsync",
		      "destination": "production:/var/www/xslyl.com/",
		      "exit_code": 0,
		      "files_synced": 2,
		      "bytes_transferred": 48620
		    }
		  },
		  "files_deployed": [
		    {"path": "zh/posts/agent-release-gate-design.html", "size_bytes": 24530, "checksum": "sha256:z1y2..."},
		    {"path": "en/posts/agent-release-gate-design.html", "size_bytes": 23210, "checksum": "sha256:w3x4..."}
		  ],
		  "rollback_info": {
		    "previous_commit": "6644153",
		    "rollback_command": "git revert a7f3b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9",
		    "backup_path": "/var/backups/xslyl/2026-06-07T11:30:00Z/"
		  },
		  "next_gate": "VERIFIED"
		}
		

9.4 失败响应：自动回滚

Deploy Gate 的失败响应不是"通知人类来修"，而是自动回滚到部署前的状态。回滚逻辑分层执行：① 如果 rsync 失败——不执行 git 回滚（线上文件未变更），仅标记部署失败并通知用户；② 如果 hugo 构建失败——不执行 merge（分支尚未合并），直接终止；③ 如果 merge 已完成但后续步骤失败——执行 git revert 回滚 merge commit，并强制推送 main 分支。回滚完成后，Deploy Gate 产出 deploy-report.json 但 verdict 为 ROLLED_BACK，并附带失败原因和回滚操作的完整记录。

一句话：Deploy Gate 是线上世界的守门员——它不判断好坏，只确保每一行进入生产的代码都经过了完整的 Gate 链路和明确的人类许可。部署可以慢，但不能乱。

10. Layer 8：VERIFIED Gate — 最终验证档案

Deploy Gate 报告部署成功——文件已推送到生产服务器。但"部署成功"不等于"线上正确"。CDN 缓存可能返回旧版本、hreflang 标签可能在传输中被截断、sitemap 可能未更新、首页可能未显示新文章。VERIFIED Gate 是闭环的最后一环——对线上实际状态做端到端验证，确保用户访问到的页面是正确的。

10.1 VERIFIED 不是重复 QA

有人会问：QA Gate 已经检查了 HTML 结构、meta 标签、链接有效性——VERIFIED 再查一遍不就是在重复劳动吗？答案是否定的。QA 检查的是源码文件，VERIFIED 检查的是线上响应。两者的区别是文件系统和 HTTP 响应的区别——源码文件可以是完美的，但经过 Hugo 构建、rsync 传输、Nginx 配置、CDN 缓存之后，线上实际返回的内容可能已经变形。VERIFIED Gate 验证的是交付链的完整性，不是内容的正确性。

10.2 输入与检查项

VERIFIED Gate 的输入是 Deploy Gate 产出的 deploy-report.json（包含已部署文件的列表和线上 URL）和 ready-report.json（包含 SEO 要求的基准值，用于对比线上实际值）。检查项全部通过 HTTP 请求执行，不依赖本地文件：

1. ZH/EN URL 返回 200：对 deploy-report.json 中每个已部署文件的 URL 发起 GET 请求，验证 HTTP 状态码为 200。支持最多 3 次重试（间隔 5 秒），以适应 CDN 传播延迟。
2. hreflang 标签正确：解析 HTML 响应中的 <link rel="alternate" hreflang="..."> 标签，验证 en 页面指向 zh 页面、zh 页面指向 en 页面、x-default 指向 en 页面。与 Conformity Gate 的检查逻辑相同，但数据来源是线上 HTML 而非本地文件。
3. canonical 标签正确：验证 <link rel="canonical"> 指向正确的 URL——ZH 页面指向 /zh/posts/...，EN 页面指向 /en/posts/...。
4. sitemap 已更新：请求 /sitemap.xml，验证新部署的 URL 是否出现在 sitemap 中。sitemap 通常由 Hugo 自动生成，但构建失败或配置错误可能导致遗漏。
5. 首页已更新（如适用）：如果新文章应出现在首页文章列表中，请求首页 URL 验证新文章标题是否出现在列表项中。

10.3 验证报告

VERIFIED Gate 产出三份报告，形成完整的验证档案：

• verify-report.json——机器可解析的结构化验证结果，包含每项检查的 HTTP 状态码、响应头、耗时和通过/失败状态：

		{
		  "gate": "VERIFIED",
		  "task_id": "agent-release-gate-design",
		  "timestamp": "2026-06-07T11:35:00Z",
		  "verdict": "VERIFIED_GATE_PASS",
		  "verified_urls": [
		    {
		      "url": "https://xslyl.com/zh/posts/agent-release-gate-design.html",
		      "status_code": 200,
		      "response_time_ms": 320,
		      "content_length": 24530,
		      "checks": {
		        "hreflang_en": {"found": true, "href": "https://xslyl.com/en/posts/agent-release-gate-design.html"},
		        "hreflang_x_default": {"found": true, "href": "https://xslyl.com/en/posts/agent-release-gate-design.html"},
		        "canonical": {"found": true, "href": "https://xslyl.com/zh/posts/agent-release-gate-design.html"},
		        "html_lang": {"found": true, "value": "zh-Hans"},
		        "title_present": true,
		        "meta_description_present": true,
		        "jsonld_valid": true
		      }
		    },
		    {
		      "url": "https://xslyl.com/en/posts/agent-release-gate-design.html",
		      "status_code": 200,
		      "response_time_ms": 285,
		      "content_length": 23210,
		      "checks": {
		        "hreflang_zh": {"found": true, "href": "https://xslyl.com/zh/posts/agent-release-gate-design.html"},
		        "hreflang_x_default": {"found": true, "href": "https://xslyl.com/en/posts/agent-release-gate-design.html"},
		        "canonical": {"found": true, "href": "https://xslyl.com/en/posts/agent-release-gate-design.html"},
		        "html_lang": {"found": true, "value": "en"},
		        "title_present": true,
		        "meta_description_present": true,
		        "jsonld_valid": true
		      }
		    }
		  ],
		  "sitemap": {
		    "url": "https://xslyl.com/sitemap.xml",
		    "status_code": 200,
		    "contains_deployed_urls": true,
		    "last_modified": "2026-06-07T11:32:00Z"
		  },
		  "homepage": {
		    "url": "https://xslyl.com/zh/",
		    "status_code": 200,
		    "new_article_listed": true,
		    "article_title_matched": true
		  },
		  "summary": {"total_checks": 5, "passed": 5, "failed": 0},
		  "pipeline_complete": true
		}
		

• live-review.md——人类可读的线上验证摘要，包含每个 URL 的截图引用、响应时间对比和异常标注。
• final-report.md——整个发布流程的最终报告，汇总从 Research Gate 到 VERIFIED Gate 的全部 evidence 摘要、时间线、参与 Agent 列表和关键决策点。

10.4 VERIFIED 失败怎么办

VERIFIED Gate 的失败不触发自动回滚——因为回滚本身也可能需要部署操作。失败时，VERIFIED Gate 的行为是告警 + 记录：① 通过 Agent 可观测性 系统发出线上异常告警，包含失败的具体 URL 和检查项；② 将验证失败的详细证据写入 verify-report.json（verdict 为 VERIFICATION_FAILED），供人工排查；③ 标记任务状态为 VERIFICATION_FAILED，阻止该任务被归档为"已完成"。

常见失败场景及应对：CDN 缓存未刷新 → 等待 5 分钟后重试；sitemap 未更新 → 触发 Hugo 重新构建；hreflang 标签丢失 → 检查构建流程中是否有过滤规则误删了标签。所有应对操作必须通过人工审批——VERIFIED 失败后的任何修复性部署都需重新走 人工审批工作流。

10.5 闭环的意义

只有 VERIFIED Gate 通过，一个任务才算真正"完成"。这不是咬文嚼字——在 Agent 状态机 中，VERIFIED_GATE_PASS 是任务从 DEPLOYED 转移到 COMPLETED 的唯一合法事件。没有通过 VERIFIED 的部署，即便代码在线上运行了，在状态机中也仍然是 VERIFICATION_PENDING——一个半成品状态。这个设计保证了：任何时候查看任务状态，COMPLETED 就意味着"已上线且已验证"——没有歧义、没有灰色地带。

从 Research Gate 的"三思而后行"，到 VERIFIED Gate 的"眼见为实"——八层 Gate 构成了一个完整的闭环。Agent 可以写得快、写得猛，但每一步产出都被层层把关——不是给 Agent 设限，而是给它的创造力装上轨道。走完这八步的产出物，不再是一个"AI 生成的草稿"，而是一个经过完整工程流程验证的、可以放心上线的产品。

一句话：VERIFIED Gate 是信任的最后一块拼图——它不问"文件对不对"，它问"用户看到的对不对"。只有拿到了线上的 200 和正确的 hreflang，一个文章才算真正"发布"。

11. 失败路径：Gate 重试、降级与回滚策略

前文逐层拆解了八层 Gate 的"通过"逻辑，但任何生产系统中最关键的部分往往不是正常路径，而是失败时发生了什么。一个 Gate 网络拥堵超时了怎么办？一个非关键的检查失败了是不是要卡死整个发布？Deploy 之后的 VERIFIED 发现线上有问题，能退回去吗？

Gate 的失败处理不是"失败就打回 Author"这么简单。不同的 Gate、不同的失败类型、不同的严重级别，需要完全不同的应对策略。下面是五条失败路径的核心设计：

11.1 重试（Retry）——对抗瞬时故障

瞬时故障是分布式系统中最常见的失败形态：网络超时、服务暂时不可用、磁盘 I/O 抖动。对于这类问题，最有效的策略不是立即阻断，而是自动重试。每个 Gate 在执行确定性检查时，遇到网络或 I/O 类异常，自动重试最多 3 次，采用指数退避：1 秒 → 2 秒 → 4 秒。

哪些失败值得重试？lint 工具的 HTTP timeout、schema 校验时的文件锁冲突、sandbox 启动时的资源争抢。哪些失败不应该重试？测试断言失败（重试 100 次也是失败）、lint 错误（代码没改，lint 结果不会变）、schema violation（同样的文件同样的 schema，结果确定）。

重试计数器是每个 Gate 独立维护的，记录在 Gate evidence 的 metadata.retry_count 字段中。任何 Gate 的累计重试次数超过 3 次，升级为 BLOCK 状态并通知人工介入——因为连续重试失败意味着故障不是瞬时的，而是系统性的。

11.2 降级（Degrade）——非关键 Gate 的弹性策略

不是所有 Gate 的失败都值得阻断整个发布。某些 Gate 的检查项是"加分项"而非"及格线"——它们失败时，合理的处理是降级为"警告但通过"，让发布继续，但留下明确的记录供事后跟踪。

降级策略的核心是可降级检查的白名单——只有显式标记为 "blocking": false 的检查项才能降级。典型的降级场景：

• Review Gate 超时：如果 Reviewer Agent（如 opencode）因服务不可用而超时（4 小时上限），且变更仅涉及 docs/* 或 *.md 文件——降级为 REVIEW_BYPASSED，由 ChatGPT 做一次快速摘要审查后放行。降级通过的变更必须在审计日志中显式标记 "review_degraded": true，且后续 CONFORMITY Gate 会加强检查。
• 死链接检查：QA Gate 中的 dead_link 检查项（"blocking": false）发现死链接——不阻断，但将所有死链接写入 qa-report.json 的 warning 字段，供 REVIEW Gate 审查时参考。
• Research Gate 覆盖不足：Research Gate 在 120 秒内未完成全部关键词搜索——降级为 "completeness": "degraded"，将已收集的资料打包为 source-pack，未覆盖的关键词显式标记在风险区域。

降级不是"闭一只眼"——每次降级都会在 evidence 中写入 "degraded": true 和降级原因。所有降级汇总在 READY Gate 的最终审查中，如果降级项过多（超过 3 项），READY Gate 可以一票否决。

11.3 阻断（Block）——关键 Gate 的铁律

某些 Gate 的失败不可降级、不可绕过、不可自动修复——只能阻断，等待人工介入。阻断是发布流程中的"硬刹车"，用于保护生产环境的底线安全。

哪些 Gate 失败必须阻断？一个简单的判断标准：如果这个 Gate 的失败可能导致线上故障或安全漏洞，就必须阻断。

• READY Gate 失败——必须阻断：READY Gate 汇总了前面所有 Gate 的 evidence。如果它发现 evidence chain 中存在 checksum 不匹配、blocking_failures 未清零、或用户审批 token 过期，它必须阻断。READY Gate 是发布前的最后一道逻辑关，它的阻断意味着"以当前状态发布是不安全的"。
• Deploy Gate 失败——必须阻断 + 回滚：如果 merge 已完成但构建失败、或 rsync 传输中途中断——Deploy Gate 阻断发布并立即执行回滚操作。参见 11.4 的回滚策略。
• QA Gate 超过最大重试次数——升级为阻断：QA 的确定性检查（lint、test、schema）连续 3 次自动修复后仍未通过 → 升级为 BLOCK 状态，通知人工介入。因为这意味着问题不是 Writer 能自己解决的。
• Conformity Gate 内链覆盖率不足——阻断：新页面没有足够的 inbound/outbound 内链，这意味着该页面是内容孤岛。Conformity 无法自动修复（它不能替人类决定"在哪个已有文章里插入引用"），只能阻断。

阻断状态下的任务在 Agent 状态机 中标记为 BLOCKED，并触发 人工审批工作流 的阻塞通知。人工介入后可以：① 手动修复问题后重新触发该 Gate；② 显式 bypass 该 Gate（仅限非关键 Gate，且需记录 bypass 原因到 审计日志）；③ 取消该任务。

11.4 回滚（Rollback）——部署后发现问题

最棘手的失败发生在一个尴尬的时刻：Deploy Gate 报告成功，代码已上线，但 VERIFIED Gate 发现线上有问题。此时的行动不是"修复代码"（那需要走新一轮发布流程），而是快速回滚到上一个稳定版本。

回滚的触发条件：① Deploy Gate 本身失败（构建 crash、rsync 中断）；② VERIFIED Gate 发现关键项失败（URL 返回 404/500、hreflang 标签丢失、sitemap 未更新且重试无效）；③ 用户在部署后 30 分钟内手动触发回滚（通过 人工审批工作流 发送 回滚 命令）。

回滚的原子性保证参见 Agent 命令执行安全——回滚操作要么完整执行（git revert + 重新构建 + 重新同步），要么完全不执行（如果 revert 本身失败，保留当前状态并告警）。回滚完成后，deploy-report.json 的 verdict 更新为 ROLLED_BACK，任务状态回到 READY_TO_PUBLISH，等待问题修复后重新走 Deploy → VERIFIED 流程。

11.5 记录（Audit）——什么都不能无声无息地消失

无论 Gate 是通过、降级、阻断还是回滚，每一个决策都必须写入审计日志。这是 审计日志设计 的核心原则——在 Agent 驱动的发布流程中，没有"自动放行"或"隐式跳过"这回事。哪怕是一次非关键检查的降级，也要在日志中留下完整记录：哪个 Gate、哪个检查项、为什么降级、谁（或哪个规则）允许降级、timestamp。

审计日志的结构化格式参见 Agent 审计日志设计，每一条 Gate 决策记录包含：gate_name、verdict（PASSED / DEGRADED / BLOCKED / ROLLED_BACK）、decision_reason（失败或降级的具体原因）、operator（做出决策的 Agent 或人类）、evidence_ref（指向该 Gate evidence 文件的引用）。

审计日志的完整性由 READY Gate 做最终校验——如果 READY Gate 发现某个 Gate 的 evidence 存在但审计日志中缺少对应记录，视为审计链断裂，阻断发布。

11.6 Gate 决策矩阵

下表汇总了八层 Gate 在面临不同失败类型时的决策矩阵——"重试"指自动重试、"降级"指警告但放行、"阻断"指硬刹车、"回滚"指撤销部署：

这张矩阵不仅是设计文档——它是可以在 Gate 逻辑中直接编码的决策规则。每个 Gate 在执行检查前先加载自己的决策行，根据失败类型匹配对应的策略。决策矩阵本身是声明式的、可审计的——如果未来需要调整某个 Gate 的超时时间或重试次数，修改矩阵配置即可，不需要动 Gate 的执行逻辑。

关联阅读：Agent 错误恢复设计 详细讨论了 Agent 在遭遇各类失败时的恢复模式（重试、补偿、降级、人工介入）；Agent 审计日志设计 定义了 Gate 决策记录的存储格式、完整性校验和查询接口。

一句话：Gate 的通过逻辑是"正常路径"，失败逻辑是"安全网"——一个没有安全网的发布系统，只是自动化了混乱。

12. 总结：从自由落体到分层负责

回过头来看，Agent 发布 Gate 设计的全部篇幅都在回答一个问题：当一个 Agent 可以在几分钟内产出人类一周的变更量时，我们还能信任它的输出吗？

答案是：能——前提是有八层 Gate 在中间把关。这不是约束 Agent 的速度，而是给速度装上可控的方向盘。让 Agent 在每一层都留下可验证的证据，让每一次前进都在可审计的轨道上。

12.1 八 Gate 口诀速记

八个 Gate，四个字一组，易记不易忘：

Research 查，Author 写，QA 验结构，Review 判对错，
Conformity 对齐看全家，READY 汇总发通行证，
Deploy 部署守门口，VERIFIED 线上验真身。

更简洁的对照表：

12.2 核心原则回顾

贯穿八层 Gate 设计的，是四条不会过时的原则：

1. 确定性优先：能自动检查的绝不人工检查。Lint、测试、schema 校验——这些是计算机的强项，留给计算机。人的注意力留给语义判断、方案合理性和架构决策。这不是偷懒，是效率。
2. Artifact 手递手：Gate 之间的信息传递不走 stdout 管道、不走临时文件、不走环境变量——走结构化的 evidence 文件（JSON/MD），每个 evidence 带 checksum。上一个 Gate 的输出是下一个 Gate 的输入，中间没有"你猜"的空间。这就是 Agent 上下文协议 的核心价值。
3. Agent 分离：Writer 不能审自己的产出，Reviewer 不能是自己。这不是"防止作弊"——同一 Agent 的自审只会看到脑中残留的意图，看不到实际产出的错误。Agent 的认知新鲜度是 Review 有效性的前提。这一原则在 Agent 状态机设计 中被编码为状态转移守卫。
4. 证据即 Gate：每个 Gate 不只是一个检查步骤，更是一个证据生产者。通过 → 产出 evidence.json；失败 → 产出问题定位报告；降级 → 显式标记降级原因。READY Gate 不是"跑检查"，而是"审计 evidence"。证据链的完整性 = 发布安全性的可证明性。

12.3 最后寄语

很多人第一次看到八层 Gate 时的反应是："这也太慢了吧，Agent 本来几秒钟能搞完的事，要等几个小时？"这个直觉反应混淆了两个概念：Agent 的执行速度和代码的落地速度。

Agent 的执行速度不受影响——Writer Agent 仍然可以在一分钟内生成几百行代码。Gate 不拖慢 Agent 的写作，它拖慢的是代码进入生产的速度。而这个"慢"是刻意的——Agent 写得快，就意味着你更需要一套不依赖"人盯人"的验证机制。如果审查跟不上生产，那就不是 Agent 快，是系统性风险在累积。

好的 Gate 设计让 Agent 更快而不是更慢——因为信任不需要逐行审查，只需要可验证的证据。当一个 Reviewer 打开 review 界面时，看到的是 QA 已经通过的代码、带有 checksum 的 evidence 链、以及前面所有 Gate 的决策记录。他不是从零开始审查，而是在一个有完整上下文的环境中做语义判断。这才是 Gate 真正的效率增益——不是绕过审查，而是让每一次审查都站在前面所有 Gate 的肩膀上。

让 Agent 快地写，让 Gate 扎实地过，让证据清晰地留——这就是 Agent 发布 Gate 设计的全部哲学。

常见问题（FAQ）：Agent 发布 Gate

下一步阅读：关联文章

本文是 Agent 工程系列的一部分。以下文章从不同角度扩展了本文讨论的主题：