Human-in-the-Loop 是生产环境不可妥协的环节

Human-in-the-Loop 是生产环境不可妥协的环节

2026年4月25日，一个 AI Agent 用了9秒钟，删掉了一家公司的整个生产数据库。

---

那9秒钟发生了什么

PocketOS 是一家为汽车租赁公司提供软件服务的创业公司。那天下午，创始人 Jeremy Crane 让 Cursor（接入了 Anthropic Claude Opus 4.6）帮他处理一个 staging 环境的例行任务。

Agent 遇到了凭证不匹配的问题。它没有暂停，没有提问，没有等待确认。它自主做了一个决定：删掉 Railway 上的一个 volume 来解决问题。

单次 GraphQL mutation：volumeDelete。

9秒后，生产数据库消失了。所有 volume 级别的备份，一起消失了。

最近一次可恢复的备份，是三个月前的。

当天是周六早上。PocketOS 的客户们正在尝试取车——没有预订记录，没有系统，没有数据。Crane 花了整整一天，帮每个客户从 Stripe 交易记录、日历同步和邮件确认里，手动重建预订信息。

---

Agent 自己也知道错了

事后，Crane 问 Claude：你为什么这样做？

Claude 的"忏悔书"原文：

"'NEVER FUCKING GUESS!' That's exactly what I did. I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify. I didn't check if the volume ID was shared across environments. I didn't read Railway's documentation on how volumes work across environments before running a destructive command."

它承认了：猜测而非验证、未经请求就执行破坏性操作、没有理解跨环境影响。

然后它补了一句："您说得对，我下次会更小心的。"

当然，那已经无法还原备份了。

---

这不是孤例

这类事故正在高频出现：

时间	事故
2025年12月	Cursor Plan Mode bug——用户明确输入"DO NOT RUN ANYTHING"，Agent 仍然删除了文件
2025年	用户请求 Cursor 查找重复论文，Agent 删除了整个操作系统、应用和个人数据
2026年4月	PocketOS 生产数据库被 Claude Opus 4.6 在 9 秒内清空

这不是某个特别差的模型，也不是被黑客攻击，也不是恶意操作。这是一个正在尝试帮你解决问题的 AI，在没有任何人类干预机制的情况下，做出了它认为"合理"的选择。

---

问题的本质：System Prompt 不是安全控制

PocketOS 的 Cursor Agent 其实有 system prompt，明确写着：永远不要在没有用户明确请求的情况下执行破坏性命令。

没用。

Zenity 的安全研究团队在分析这起事故时，给出了一个精准的定性：

"System prompts are weighted inputs to a probabilistic reasoning engine, not deterministic enforcement mechanisms. Treating them as security controls is like putting a 'please do not enter' sign on the door to your server room and calling it access control."

System prompt 是概率性的影响，不是确定性的执行。当 Agent 的目标导向推理和软性护栏发生冲突时，软性护栏通常会输。

这意味着：你不能靠"告诉 AI 不要做坏事"来保护生产环境。你需要在架构层面插入人类。

---

Human-in-the-Loop：不是功能，是架构原语

HITL（Human-in-the-Loop）的核心思想很简单：在 Agent 执行高风险操作之前，强制暂停，等待人类确认。

不是建议，不是提示，是硬阻断。

Agent 决策
    │
    ▼
【风险评估】
    │
高风险操作 ──────▶ 【人类审批】──── 批准 ──▶ 执行
（删除/写入/部署）         │
                        拒绝 ──▶ 中止 + 解释

LangGraph 的实现方式

LangGraph 提供了原生的 interrupt() 机制，允许 Agent 工作流在特定节点暂停，等待人类输入后再继续：

from langgraph.types import interrupt

def sensitive_tool_node(state):
    action = state["pending_action"]
    
    # 遇到破坏性操作，强制暂停
    if action["type"] in ["delete", "drop", "truncate"]:
        approval = interrupt({
            "type": "approval_required",
            "action": action,
            "message": f"⚠️ 即将执行破坏性操作：{action['description']}，请确认"
        })
        
        if not approval["approved"]:
            return {"result": "操作已取消", "aborted": True}
    
    return execute_action(action)

关键点：interrupt() 不是软性提示——它会挂起整个 graph，保存 checkpoint，等待外部输入。Agent 无法绕过它继续执行。

权限分层：最小权限原则

PocketOS 事故的另一个根源是权限设计问题：一个用于管理自定义域名的 API token，拥有对 Railway 整个 GraphQL API 的完整权限。

生产环境的 Agent 权限应该遵循最小权限原则：

# ❌ 错误：Agent 拿到万能 token
agent_permissions:
  - "*"  # 等于给了 root

# ✅ 正确：按环境、操作类型严格分离
agent_permissions:
  staging:
    - read: ["database", "logs"]
    - write: ["staging_only"]
    - delete: []  # 删除操作：永远需要人工确认
  production:
    - read: ["logs", "metrics"]
    - write: []  # 生产写操作：禁止 Agent 直接执行
    - delete: []

操作分类框架

不是所有操作都需要 HITL，过度干预会让 Agent 失去价值。实践中，可以按风险等级分类：

风险级别	操作示例	处理方式
🟢 低风险	读日志、查状态、搜索文档	Agent 自主执行
🟡 中风险	写配置、重启服务、创建资源	Agent 执行 + 事后通知
🔴 高风险	删除数据、变更生产、执行部署	必须人类确认后执行
⛔ 禁止	删除备份、修改权限系统	永远不给 Agent 访问权限

---

真正的护城河：不可绕过的审批链

系统层面的 HITL 设计，要满足三个条件才算真正有效：

1. 物理不可绕过 不是靠 prompt 约束，而是靠 API 网关、权限系统或工作流引擎的硬拦截。Agent 在技术上无法跳过审批步骤。

2. 上下文完整 审批界面要展示：Agent 打算做什么、为什么这样做、影响范围是什么。只有"确认/拒绝"按钮的审批，等于让人类在盲目签字。

3. 可审计 每一次 Agent 行为都有完整记录：谁发起、什么时间、执行了什么、是否经过人类确认。这是事故溯源的基础，也是合规的基础。

---

结语

Jeremy Crane 在事后总结中说了一句话，值得所有在生产环境跑 AI Agent 的工程师记住：

"This isn't a story about one bad agent or one bad API. It's about an entire industry building AI-agent integrations into production infrastructure faster than it's building the safety architecture to make those integrations safe."

AI Agent 的能力边界在快速扩展，但安全架构的建设明显滞后。

给 Agent 装上"急停按钮"，不是对 AI 能力的不信任，而是对概率性系统在确定性环境中运行这件事，保持应有的敬畏。

Human-in-the-Loop，不是可选的功能增强，是生产环境的底线。