人在回路的代理设计：2026年审批门与升级模式实战

2026 年的共识是：完全自主的代理在生产环境里是不负责任的，但每个操作都要人点确认也是不可持续的。答案在中间——设计良好的 human-in-the-loop（HITL）模式。本文讲解四个核心模式：审批门状态机、超时升级、批量审批和审计追溯，让代理在关键节点停下来等人类，又不至于把人类累垮。

代理负责速度，人类负责判断

一、审批门：让代理在高风险节点暂停

审批门（approval gate）是 HITL 的基本单元。代码示例1 展示了一个审批门状态机：代理执行到高风险动作前进入 PENDING 状态，等待有对应角色（required_role）的人类决定；只有收到 APPROVED 才继续执行，REJECTED 则回滚。2026 年的生产实践是把这些门直接写进代理 harness（如 Claude Code 的 permission modes、Codex 的 approval 配置），让「哪些动作需要人批」成为配置而非口头约定。

# Approval gate state machine
from enum import Enum

class GateState(Enum):
    PENDING = "pending"      # agent paused, waiting for human
    APPROVED = "approved"
    REJECTED = "rejected"
    TIMEOUT = "timeout"      # nobody answered in time

class ApprovalGate:
    def __init__(self, action, required_role, timeout_s=1800):
        self.action = action
        self.required_role = required_role
        self.timeout_s = timeout_s
        self.state = GateState.PENDING

    def resolve(self, decision):
        self.state = GateState(decision)
        return self.state

# High-risk actions MUST pass through a gate before execution.

二、超时与升级：别让代理干等

如果审批人睡着了，代理就永远卡住。代码示例2 展示了超时升级模式：等待审批超过阈值（如 15 分钟）就自动升级到上一级负责人，达到升级上限（如两级）就中止任务并通知。升级阶梯可以是 工程师 → 技术负责人 → 值班经理 → 中止。这个模式保证了系统的活性——人类可以慢，但不可以无限期缺席。

# Timeout & escalation: don't let the agent hang forever
def run_with_escalation(agent_task, gates, escalation_after_min=15):
    while True:
        decision = wait_for_approval(gates, timeout=escalation_after_min)
        if decision == "approved":
            return execute(agent_task)
        if decision == "rejected":
            return rollback(agent_task)
        # timeout -> escalate to next level of human
        escalate_to(owner=task.owner, level=+1)
        if escalation_level > 2:
            return abort_and_notify(task, reason="escalation ceiling")

# Escalation ladder: engineer -> tech lead -> on-call manager -> abort.

三、批量审批：保护人类的注意力

每个操作都单独弹窗确认，人类很快就会「审批疲劳」，开始无脑点同意——这比没有审批更危险。代码示例3 展示了分级批量策略：低风险高频操作（重跑测试、建分支、改文档）自动批量；中风险操作（评论 PR、小重构）批量展示但可展开细节；高风险操作（部署、删数据、读密钥）永远单独审批、绝不批量。记住：批量是保护注意力，不是放松控制。

# Batch approval: reduce fatigue without losing control
BATCH_RULES = {
  # low-risk, high-volume: approve in batch with a single click
  "auto_batch": ["test:rerun", "branch:create", "docs:update"],
  # medium-risk: batch with per-item expandable detail
  "review_batch": ["pr:comment", "refactor:small", "test:add"],
  # high-risk: NEVER batch, always individual approval
  "never_batch": ["deploy:prod", "data:delete", "secret:read"],
}

def should_batch(action):
    if action in BATCH_RULES["auto_batch"]:
        return "auto"
    if action in BATCH_RULES["review_batch"]:
        return "review"
    return "individual"

# Batching is about human attention, not about loosening control.

四、审计追溯：每个决定都有记录

HITL 的价值只有在可追溯时才成立。代码示例4 展示了人类决策审计：每条审批记录包含动作、决定、审批人（超时则记为 SYSTEM_TIMEOUT）、决策耗时和门状态。这些数据既是合规审计的原料，也是流程优化的依据——比如发现某个门平均要等 40 分钟，就该考虑换审批人或缩短超时阈值。

# Audit trail for every human decision
def log_human_decision(decision, gate, reviewer):
    audit_entry = {
        "action": gate.action,
        "decision": decision,          # approved / rejected / timeout
        "reviewer": reviewer or "SYSTEM_TIMEOUT",
        "time_to_decide_s": gate.elapsed_s(),
        "gate_state_before": gate.state.value,
    }
    write_append_only("human_decisions", audit_entry)

# Every approval, rejection, and timeout is recorded with who
# decided and how long it took — the raw material for both
# compliance and process improvement.

五、HITL 的最佳实践清单

2026 年团队应该坚持的实践：第一，高风险动作强制事前审批，绝不事后补；第二，审批请求要带足够上下文（代理打算做什么、影响范围、回滚方案），让人类能快速判断；第三，审批超时必须有升级路径，不允许无限等待；第四，所有人类决定进审计日志；第五，定期检查审批数据，砍掉那些「永远被批准」的门——它们只是在浪费注意力。

六、总结

HITL 不是「不信任 AI」的妥协，而是「让 AI 和人类各司其职」的工程决策：代理负责速度和广度，人类负责判断和问责。审批门、超时升级、批量审批、审计追溯这四个模式组合起来，就能构建一个既高效又安全的代理系统。2026 年，做得好的团队不是那些最相信 AI 的，而是那些把人与机器的协作界面设计得最顺滑的。