基于门控的阶段流转：AI 工作流的安全过渡模式

基于门控的阶段流转：AI 工作流的安全过渡模式

学习目标

读完本章后，你将能够：

• 设计阶段门控（Stage Gate）机制，防止 AI Agent 在条件不成熟时进入下一阶段
• 实现完成门、用户授权跳过门和共识证据门三种门控类型
• 构建带审查循环的流水线架构，支持自动回退与重试
• 理解 Autopilot 模式下的严格循环流水线设计

前置知识

• 基于规则引擎的 AI 工作流编排

---

核心概念

1. 为什么需要阶段门控

在多阶段 AI Agent 工作流中，阶段门控（Stage Gate）是一种防止 Agent 在条件不成熟时进入下一阶段的防御性设计模式。

典型的场景：

• 在需求尚未澄清时，Agent 不应该直接进入编码阶段
• 在方案未获批准时，Agent 不应该开始大规模文件修改
• 在代码审查未通过时，不应该进入最终验收

没有门控的风险：

风险	后果	门控防御
需求理解偏差	编码方向错误，大量返工	完成门：确认所有澄清问题已回答
方案未经评审	架构缺陷导致系统性问题	共识证据门：需要 Architect + Critic 一致通过
跳过测试直接部署	生产环境故障	质量门控：验证测试覆盖率 + 审查通过

2. 完成门（Completion Gate）

完成门是最基础的门控类型，检查前一阶段是否满足完成的必要条件。

伪代码：
function evaluateCompletionGate(phase, state):
  switch phase:
    case "deep-interview":
      return {
        passed: state.questions.length > 0
          && state.questions.every(q => q.answered),
        reason: state.questions.length === 0
          ? "No questions were asked during interview"
          : "Unanswered questions remain"
      }

完成门的要素：

要素	说明
必要条件	必须满足的客观条件（如”所有问题已回答”）
完成证据	记录完成状态的工件（如已回答的问题列表）
失败原因	门控未通过时的具体原因

3. 用户授权跳过门（User Authorization Skip Gate）

允许用户在特定条件下授权跳过某个阶段，但必须有显式的授权记录。

伪代码：
function evaluateSkipGate(phase, userActions):
  authRecord = findUserAuthorization(userActions, phase)
  if authRecord && authRecord.explicit:
    return { passed: true, reason: "User authorized skip" }
  return { passed: false, reason: "No user authorization found" }

授权记录的结构：

字段	说明
phase	被跳过的阶段
explicit	是否为显式授权（非默认同意）
rationale	用户授权的简要理由
timestamp	授权时间

为什么需要显式授权：防止 Agent 将用户的模糊表达（如”ok”、“sure”）误判为阶段跳过授权。显式授权要求用户明确表示”跳过这个阶段”或”直接进入下一阶段”。

4. 共识证据门（Consensus Evidence Gate）

共识证据门要求多个独立 Agent 对同一产出物达成一致意见，才能进入下一阶段。

共识门的判定逻辑：

架构师	批评者	共识结果
通过	通过	✅ 通过（双方认可）
通过	不通过	❌ 不通过（存在分歧，需修改）
不通过	通过	❌ 不通过（存在分歧，需修改）
不通过	不通过	❌ 不通过（双方一致否定）

顺序要求：架构师先审查，批评者后审查。批评者可以看到架构师的审查结果，但必须独立判断。这防止了”先入为主”的偏差——批评者的角色是发现架构师可能遗漏的问题。

5. 质量门控（Quality Gate）

质量门控是最终完成前的综合检查，通常包含多个独立验证维度。

伪代码：
function evaluateQualityGate(evidence):
  checks = []
  checks.push(evaluateAISlopCleaner(evidence))     // AI 代码清理
  checks.push(evaluateVerification(evidence))      // 验证测试
  checks.push(evaluateCodeReview(evidence))        // 代码审查

  return checks.every(c => c.passed)
    ? { passed: true }
    : { passed: false, failures: checks.filter(c => !c.passed) }

质量门控的典型维度：

维度	检查内容	通过标准
AI Slop Cleaner	清除冗余的 AI 生成代码	status = “passed”
验证测试	构建、lint、单元测试	所有命令通过
代码审查	独立审查员和架构师双签	审查通过 + 架构师 CLEAR

6. 审查循环（Review Loop）

当质量门控未通过时，流水线自动回退到规划阶段进行修复。

循环保护：

保护机制	说明
最大循环次数	防止无限循环（如上限 10 次）
审查发现携带	回退时将问题列表传递给规划阶段
循环计数记录	审计日志记录每次回退的原因和时间

7. Autopilot 严格循环流水线

Autopilot 模式将多个阶段组成自动执行的严格循环：

$deep-interview → $ralplan → $ultragoal → $code-review → $ultraqa

如果任一阶段产出非清洁，自动回退到 $ralplan 并携带审查发现。

严格循环的特征：

特征	说明
全自动	无需人工介入，每个阶段自动衔接
门控保障	每个阶段间都有门控检查
循环上限	防止无限循环的最大重试次数
状态持久化	每次阶段转换都写入持久化状态

陷阱与对策

陷阱	后果	对策
门控条件过于严格	流水线频繁阻塞	提供用户授权跳过门作为逃生舱
门控条件过于宽松	不合格产出物进入下一阶段	定期审计门控通过率，调整阈值
共识门顺序不当	后审查者被先审查者影响	确保批评者在架构师之后但独立判断
循环无上限	无限循环消耗资源	设置最大循环次数并记录超限原因
门控状态丢失	会话重启后无法恢复门控状态	将门控状态写入持久化文件

参考来源

• OpenAI Codex CLI — Goal workflows 模块
• Workflow Patterns — https://www.workflowpatterns.com
• Stage-Gate Process — Cooper, R. G. (2008), “Perspective: The Stage-Gate Idea-to-Launch Process”