Human-in--Loop 怎能妥协于生产环境？

那9秒钟发生了什么

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

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

单次 GraphQL mutation：volumeDelete。

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

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

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

Agent 自己也知道错了

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

Claude 的"忏悔书"原文：

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

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

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

这不是孤例

这类事故正在高频出现：

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

问题的本质这方面，System Prompt 不是安全控制

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

没用。怎么说呢，

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

from langgraph.types import interruptdef sensitivetoolnode: action = state # 遇到破坏性操作，强制暂停 if action in : approval = interrupt if not approval: return {"result": "操作已取消","aborted": True} return executeaction

至于权限分层。最小权限原则

# ❌ 错误：Agent 拿到万能 tokenagentpermissions: - "*" # 等于给了 root# ✅ 正确：按环境、操作类型严格分离agentpermissions: staging: - read: - write: - delete: # 删除操作：永远需要人工确认 production: - read: - write: # 生产写操作：禁止 Agent 直接执行 - delete: 

操作分类框架

从真正的护城河来看，不可绕过的审批链