OpenAI把AI决策藏了3年，工程师发现后集体破防

去年秋天，某支付公司的AI Agent在生产环境把一笔200万刀转账划给了错误账户。复盘时发现，系统日志只写了"REJECT"——但没人知道它为什么拒绝，又为什么最终执行了。人类操作员连夜翻聊天记录，靠猜把锅补上了。

这不是bug，是设计缺陷。大多数Agent崩溃不是因为违反规则，而是因为规则不够用时，它选择硬撑。

原文作者抛出一个反直觉结论：想让Agent真正可运营，第一个该设计的不是"拒绝"，而是"降级（DEGRADE）"。

01｜二极管陷阱：为什么REJECT不够

当前主流Agent系统只有两种结局：成功，或拒绝。听起来干净，实则偷懒。

真实业务里，大量决策处于灰色地带：审批链缺了一环、证据链接404、依赖服务超时、状态未确认。这时候如果只能REJECT，操作员被迫用"解释权"兜底——"我觉得能跑""上次这样没问题"。

tacit knowledge（隐性知识）就这样野蛮生长。三个月后，团队里只有老张知道哪些REJECT可以手动放行。审计时，"无法复现当时为何通过"成为标准答案。

更隐蔽的风险来自LLM的"叙事冲动"。当多个字段缺失时，模型倾向于补全一个自洽的故事——"这看起来像是审批通过了"。这种"帮忙"心态，正是执行假依据的温床。

REJECT把责任甩给人类，但没有留下甩锅的证据链。

02｜DEGRADE的本质：可控的暂停，不是失败

作者定义的DEGRADE（DEFER）是一种机械分支："当前无法安全决策 → 停止，并记录停止的原因。"

关键区别：它不是"什么都不做"，而是标准下一步。停止本身是可运行的工作流节点，有入口、有出口、有计时器。

具体实现上，DEGRADE返回的不是问题，而是结构化请求：

• 缺失字段的机械路径（如approvals.sre_approved）
• 所需证据的精确ID
• 当前已验证状态的快照

LLM可以起草给人看的消息，但"必须请求什么"由验证器决定。人机分工明确：模型提案，系统执行，审计留痕。

作者举了一个变更管理示例。当change_request缺少created_at时间戳时，系统不猜测、不拒绝，直接进入DEGRADE状态，标记为MISSING_EVIDENCE，并启动SLO计时器。

03｜让DEGRADE可运营：三类元数据

作者提出DEGRADE必须携带三类信息，否则只是高级REJECT：

Category（类别）：与负责团队、运维手册、SLO一一映射。如MISSING_APPROVAL对应SRE团队，STATE_UNKNOWN对应数据平台值班。

Granularity（粒度）：返回机器可读的缺失清单，而非散文描述。比如返回approvals.sre_approved: null，而不是"缺少SRE审批"。

SLO元数据：DEGRADE是"带时间的状态"，需要：

• degrade_at：进入时间
• sla_target：预期解决时间
• auto_escalate_at：自动升级阈值

这套设计让DEGRADE成为可观测、可改进的基础设施。作者直言："DEGRADE会膨胀，这没问题。有问题的是'我们不知道这是什么类型的DEGRADE'、'不知道卡了多久'、'无法优化它'。"

04｜可重入验证：从暂停到恢复

最终让DEGRADE区别于"抛异常"的设计，是可重入验证机制。

当缺失的依据被补齐，同一案例可以重新流经相同的验证器，产出新的裁决。这不是"重试"，而是"续审"——所有历史状态保留，决策逻辑一致。

作者特别提到生产配置变更的场景：改动很小，爆炸半径很大，最适合DEGRADE优先设计。比如feature flag rollout（功能标志灰度发布）缺少rollback_plan_id（回滚计划ID）时，系统不猜测风险，直接降级等待人工确认。

这种设计把"我不知道"从系统漏洞变成了运营资产。

回到开头那笔200万刀的转账。如果系统当时返回的是DEGRADE状态，附带缺失字段、责任人、计时器——夜班工程师至少知道该叫醒谁，而不是在Slack里@所有人问"有人懂这个吗"。