Agent 已经执行出错了，怎么回滚、责任算谁的

Agent 执行出错后，先止损再回滚，最后谈责任。推进 Agent 回滚分三步：先停动作（按停止开关、收窄凭证、暂停触发）；再按动作类型撤回（可撤销走软删除窗口，能恢复拉回备份，撤不回发更正补偿）；最后用动作日志复原执行与授权链。责任按事前定好的角色认，事后不找人背锅。

出错后第一个小时：先停动作与收回凭证

发现 Agent 执行出错，第一个小时先切断链路，别让它自己「修」。

Railway 官方博客 2026 年 4 月 29 日写到，人弄错了会停下求助，Agent 出错往往继续做，有时为修第一个错让情况更糟。我们建议现场先按停止开关（kill switch）、暂停触发、冻结同一批次的后续动作，再收窄或吊销它用的凭证，并保留日志。

Harness 2026 年 9 月 10 日发布的《State of Agent DLC 2026》调研了 700 名大企业技术人员（2026 年 7 月，美英法德印）：76% 认为能在 15 分钟内停用或回滚出问题的 Agent；生产中有停止开关的仅 33%，自动回滚仅 39%。报告说，多数团队有某种撤回办法，但常常是手动的，比如重新部署代码，赶不上 15 分钟。我们建议上线前把停止开关做成标配。

按动作类型回滚：撤销、恢复与事后补偿

写入后果不同，回滚不能靠单一方案。我们建议上线前把动作分类：可撤销、可恢复与不可撤回。

第一类是可撤销动作，对应草稿或暂存对象，窗口期内调反向接口撤回。Railway 官方博客 2026 年 4 月 29 日写到：客户的 AI Agent 在本机找到长期有效的 Railway API 令牌，通过旧接口调用删除卷（volumeDelete），删的是生产卷。该令牌属账户级权限，范围最大。此前 API 删除卷立即执行、无法撤销，控制台有 48 小时撤销窗口。Railway 把 API 改成所有删除先软删除 48 小时，备份删除也延迟执行。

第二类是可恢复动作。数据被覆盖，但留有备份。Railway 那次事件中，旧路径级联删除让界面备份看似不可用，但异地灾备完好，数据库已恢复，数据全部找回。这类动作靠快照与灾备拉起。

第三类是不可撤回动作，如发出的邮件、付款或报价，只能走补偿更正。我们的做法是确认错误后发更正通知并转人工。

复原现场：用动作日志重放执行与授权链

复原现场要回答三件事：Agent 做了什么、按什么顺序做、谁授权调用的工具。这靠动作日志与审批日志，模型文本无法替代参数与时间线。

SecurityHQ 与 Datadog 2026 年 10 月 15 日调研了 204 位中大型组织安全负责人：76% 说已正式定义 AI 决策责任归属，但 45% 遇到过责任不清的 Agent 事件。只有 49% 能复原过去 30 天每个动作；关键事件后，17% 几分钟内复原，51% 要几小时，23% 要几天，9% 更久或说不清。

密歇根大学 2026 年秋季开的 EECS 498 课程《应用型 Agent 软件工程》（Applied Agentic Software Engineering）里，学生要给 Agent 写危险操作前人工审批、带决策日志的规则自动审批与六种停止条件。我们建议工具调用记录入参、返回值与授权凭证，重放整条链路。

责任怎么划：按事前角色分工，不找个人背锅

任务出错，责任怎么划要在上线前定清。

我们建议复盘按四类角色分清职责，不追究写提示词的个人：授权方承担授权失控责任；Agent 负责人承担规则与监控责任；凭证提供方承担凭证保管责任；平台与供应商承担底层缺陷责任。

每类出错由谁牵头也定好。比如假设场景：采购对账 Agent 重复付款，Agent 负责人先止损并冻结批次；若主管为提速跳过复核，授权方担责；若工程师把无限额凭证写进配置，凭证提供方担责。

执行前做到哪一步还要人签字，见 IT 变更评审交给 Agent 之后，影响分析做到哪一步还要人签字。扩产前区分推荐与执行风险，见 Agent 治理要赶在扩规模之前：推荐错了能不采纳，执行错了已经发生。

复盘后改什么：收窄凭证、补撤销窗口与停止条件

复盘重点是修改工程机制，避免同类失误再次发生。

第一，收窄凭证范围。令牌遵循最小权限，不给账户级权限并短期轮换。Railway 案例中正是拿到长期有效账户级令牌，调用接口删除了生产卷。

第二，高风险写操作加撤销窗口。删除或对外接口像 Railway 那样默认软删除或延迟生效，留出撤回时间。

第三，补齐停止条件。编排层预设中断规则，包含失败上限、影响面阈值与报警，触碰立刻停机。

工具权限分级开放顺序见 企业给 Agent 开工具权限，先开哪类、后开哪类。

Agent 回滚：常见问题

为什么 Agent 执行出错后，不能让它调用工具自己回滚？

Railway 的博客写到，Agent 出错后往往会继续做下去，有时为了修第一个错让情况更糟。更安全的做法是由外部系统按停止开关、收凭证，由工程链路接管并按规则执行 Agent 回滚。

企业已有常规数据库备份，为什么还要专门设计 Agent 回滚机制？

常规备份面向全量灾难恢复，耗时长且覆盖其他正常数据。我们看到的情况是，Agent 出错时要撤回的常常只是某一批动作，比如误改了一个批次的记录。专门的 Agent 回滚机制结合软删除窗口、反向撤销与补偿，定向撤回动作并恢复现场。

业务部门与技术团队协作时，如何做好 Agent 事故的责任认定？

做好 Agent 事故的责任认定，关键在按事前分工表划定职责，不追究写提示词的个人。责任认定过程中，团队按动作日志排查：主管批准过宽免审范围由授权方担责；触发阈值未生效由 Agent 负责人担责；本地凭证暴露由凭证提供方担责；平台路径缺陷由供应商修复。