Agent 误操作后的首小时处置指南

AI Agent 改错仓库、重复发邮件，甚至在人按下停止后继续执行，最先要解决的是它还能造成什么影响、外部系统到底发生了什么。原文给出的处理顺序很明确：先切断写入能力，再保存证据、核对目标系统，最后由明确的人负责恢复。

这份指南适用于能调用工具、改变外部状态的 Agent。它把首小时响应、16 个演练案例和恢复条件串了起来。对接入 AI 编程、客服或内部自动化的团队，最有用的提醒是：界面显示成功、失败或已取消，都不能直接证明业务动作的结果。

先停止影响，还要证明它确实停了

作者把事故边界划在了业务影响上。一个没有造成影响的错误回答，可以只是质量问题；一旦涉及客户、生产系统、付款、权限、数据保密或其他人依赖的流程，就需要按运营事故处理。

首小时是协调窗口，并不承诺 60 分钟内修好。先指定事故负责人和有权修改目标系统的人，再按以下顺序推进：

1. 用业务语言描述问题，例如「可能重复发送了两封续费通知」。
2. 暂停仍能造成影响的最小范围，可以是单次运行、队列、定时触发器、Agent 身份或工具权限。
3. 独立验证停止结果，检查活跃 worker、队列深度、凭证有效性和目标系统。
4. 保存执行记录，直接查询目标系统，再决定修复及恢复方案。

停止按钮的回执，只能证明系统收到了停止请求。

已经发出的请求可能仍在执行，父 Agent 停止也不代表子任务结束。作者要求枚举子运行、身份、队列、定时任务和凭证，逐一确认它们已经终止或隔离。

原文用下面的流程说明两个关键关口：停止是否有证据，业务动作是否已查清。

flowchart TD
  A[Unexpected agent side effect] --> B[Pause smallest write-capable scope]
  B --> C{Independent stop proof?}
  C -- No --> D[Revoke tool identity or isolate worker]
  D --> C
  C -- Yes --> E[Preserve execution trace]
  E --> F[Query destination system of record]
  F --> G{Effect state known?}
  G -- No --> H[Keep capability contained; escalate query]
  H --> F
  G -- Yes --> I[Choose compensating repair]
  I --> J[Owner verifies restored state]
  J --> K[Restricted monitored resumption]

要看的是 C -- No 和 G -- No 两条回路：不能证明停止，就继续隔离；查不清动作结果，就保持写入受限并升级查询，不能靠重试碰碰运气。这个图是建议流程，不代表某个产品已经提供了对应信号。

隔离范围也不能只求大。共享平台一停，可能制造第二场故障。作者主张优先隔离受影响的租户、连接器、身份或操作，同时验证其他流程仍然健康。

Agent 说做了什么，和系统发生了什么，要分开查

原文最有价值的做法，是建立两条时间线。

执行时间线记录用户请求、Agent run ID、检索内容、工具参数、子任务、重试、超时、停止请求和人工介入。影响时间线记录目标系统收到请求、授权结果、事务或记录 ID、实际状态、通知及后续补偿操作。

两条线通过稳定标识关联，例如 idempotency key、request ID、trace ID、record ID、message ID 或付款参考号。没有关联键，就标为推断。同一分钟发生，不足以证明因果。

这能解释几个常见的错觉：客户端超时，服务端可能已经提交；工具调用返回成功，目标系统可能拒绝业务变更；Agent 回复完成，下游队列可能还没处理。排查时还要区分事件实际发生时间与操作人员观察、导出记录的时间，并同时记录 UTC 和本地业务时区。

证据包也应围绕可观察事实组织。除了负责人、发现时间和当前状态，还要保存模型、system prompt、策略、tool adapter、connector 的版本，以及父子运行关系、工具输入输出、授权结果、重试策略、webhook ID 和停止证据。检索材料优先保存来源标识和哈希，避免无差别复制机密文档。

作者不建议用隐藏推理代替执行轨迹。记录尽量只追加，纠错时新增事件指向旧记录；密钥只存 vault 引用，不把 token、完整 prompt 或个人数据扔进公共事故频道。

16 个案例反复追问：能不能安全重试和恢复

这 16 个案例是作者在 2026 年 11 月 8 日手工编写的假设场景，没有来自客户事故、生产遥测或用户研究的数据，也没有测量事故率、响应时间或处理效果。

它们覆盖重复邮件、受保护分支误改、错误工单、付款超时、旧指令删除、子任务继续执行、内部内容公开、提交后服务器报错、过时策略检索、人工修改与重试冲突、错误授权、取消无效、人工接管后发消息、运行中配置变化、大范围停机和修复无法验证。

这些场景可以归到三个工程问题里。

第一，超时和报错都不等于回滚。付款超时后，应通过 idempotency key、支付处理方参考号、商户账户和足够宽的时间窗口查询。服务器报错后，也要按 request ID 查目标事件和资源版本。只有确认未提交，并且调用满足幂等条件，才有讨论重试的基础。

第二，修复必须保留合法的后续变更。Agent 改错分支后直接 reset，可能抹掉开发者随后提交的修复；恢复被删除的数据，也可能覆盖删除之后的合法更新。作者更倾向于经过审核的纠正提交或补偿操作，并要求先比较提交图、记录版本及恢复点。

第三，人工接管必须影响已经排队的工作。UI 的归属标志变了，旧消息可能仍在发送途中；人更新了记录，旧重试也可能覆盖新值。因此需要检查消息队列、webhook 顺序、乐观锁令牌，并验证陈旧写入会被拒绝或送审。

恢复条件同样具体：明确负责人、已验证的检查点、受限权限、首笔操作监控和可用的停止路径。若无法查询权威记录，就继续限制能力并升级给目标系统负责人；确实要带着不确定性恢复，必须有人明确承担决策。

我的判断

这份指南最成立的地方，是把 Agent 事故接回了分布式系统的处理方式。幂等、版本校验、审计记录、补偿操作和权限隔离，都有直接的工程落点。相比事故后先调整 prompt，这些控制更能约束外部影响，但原文没有提供两种做法的对照数据。

它也有明确前提：团队能够查询目标系统、撤销凭证、识别子任务，并找到有权决定恢复的人。有些托管产品只暴露聊天记录和一个停止按钮，这时指南首先暴露的是控制能力缺口，不能靠补一张检查表解决。

演练部分属于经验性建议。作者提到的「停止后仍继续运行数小时」只是单个用户的论坛陈述，不能据此推断某类产品的事故频率。文中引用的 2026 年事故报告研究也是提案，并非通用标准。

提供的原文在 Python 3 脚本 triage_agent_incident.py 的 PROOF_FIELDS 定义处截断，无法获得完整可运行代码。可见部分包含 SAFE_EFFECTS = {"confirmed_none", "reconciled"}，意图是检查事故记录是否缺证据；它不会调用 API、撤销权限、判断法律义务或自动批准恢复。

文中提及的 72 小时通报也有适用条件，不能把所有 Agent 故障都判为须通报的个人数据泄露。分类应交给隐私或法务负责人，同时继续隔离影响。

能拿来做什么

• 给 AI 编程 Agent 配置受限仓库和分支权限，恢复时先通过一个人工审核的 pull request 验证，避免让它直接合并或绕过分支保护。
• 在 Node 工具适配层记录请求标识、目标记录 ID、版本及幂等键，遇到超时先查询实际状态，并为记录更新增加版本前置条件。
• 把前端的「取消」「人工接管」与后台 worker、队列和连接器状态关联起来；只有独立检查完成后，才把业务状态标为已停止。
• 用这 16 个场景做桌面演练，检查负责人、独立停止路径、目标状态查询和恢复权限是否齐全，把缺口写成有负责人和截止日期的任务。