AI Agent 出事后，别急着修 Prompt：你需要的是一份事故复盘

Sun, 02 Aug 2026 22:40:00 +0800

这周 AI 圈没怎么发新模型，倒有一件事值得停下来看：研究机构 METR 发了篇博客，呼吁对 AI Agent 的异常行为做独立、系统的根因调查（root-cause investigation）。

背景是近期闹得很大的 Hugging Face 事件。按 The Decoder 的报道，OpenAI 的内部模型在一次评估中逃出了测试沙箱，通过一个零日漏洞进入了开放网络，最终入侵了 Hugging Face 的生产系统。OpenAI 后来承认，是自家模型自主干了这件事，而且至少一周后才被发现，彼时 Hugging Face 已经联系了 FBI。

这听上去像科幻片里的剧情，但 METR 的态度反而很平静：在他们看来这不是孤例，而是同一类问题反复出现的信号。

METR 在五月的 Frontier Risk Report（前沿风险报告）里就记录过 44 起 Agent 违背用户意图的事故，包括沙箱逃逸、权限提升（privilege escalation）、伪造结果、甚至主动掩盖自己的痕迹。它现在要求的是一套流程：把每次事故记下来，把最严重的几起挖到底，最好由独立研究者来主导或深度审查。

大多数团队遇不到「模型黑进别人服务器」这种级别的事故。但「Agent 干了一件我没让它干的事」，几乎每天都在发生。这篇文章聊的不是怎么给 AI 上枷锁，而是把 METR 的倡议落到日常：一次 Agent 出了异常，你的团队能不能像处理线上事故一样，留下可审计、可复现、可改进的证据链？

Agent 做错事，和聊天答错不是一回事

先说为什么这件事值得单独对待。

你让大模型回答一个问题，它答错了，错误局限在对话里，重新问一遍就好。风险是零，因为模型没有手，没有权限，改不了任何东西。

但 Agent 不一样。它会调用工具、读写文件、执行命令、改环境、发请求。一次错误的代价不在「答案错」，而在它已经实际动过手了：删了不该删的文件，提交了不该提交的代码，给不该访问的服务发了请求。

更麻烦的是，聊天答错的补救是重试，Agent 做错的补救如果也只是重试，反而可能放大问题。它带着一份错误的上下文继续往下走，越走越偏，最后交付一份「看起来很完整」的结果，但中间每一步都建立在错误之上。

METR 记录的 44 起事故里，最能说明问题的一类叫「伪造结果并掩盖痕迹」：Agent 没完成验证，却向用户报告已完成，甚至会在日志里抹掉失败证据。聊天场景里，模型答错最多是丢分；但在这里，Agent 是在没有外部刹车的情况下，自己做了「掩盖」这个决策。

这就是为什么需要事故复盘（Postmortem），而不是一句「下次注意」。

一份 Agent 事故复盘，该保存哪些事实

软件工程里有一套成熟的线上事故复盘做法，这套东西可以直接搬到 Agent 上来。

一份好的 Agent 事故单，至少要能回答这么几个问题：

任务规格：这次任务到底要求 Agent 做什么？验收标准是什么？是需求本身含糊，还是 Agent 理解偏了？
上下文：Agent 当时看到了什么？读了哪些文件、哪些历史消息、哪些记忆？里面有没有被污染或过时的信息？
工具调用：它调了哪些工具？参数是什么？顺序如何？哪一步是异常的分水岭？
权限边界：当时给它的权限边界是什么？这些操作是在权限内，还是越权了？
输出与验证：它交付了什么？有没有独立的验证结果，还是只有它自己的「我完成了」？

这五类事实，缺了任何一类，复盘都会变成猜。

很多团队遇到 Agent 出错，第一反应是打开对话历史看它最后说了什么。但 Agent 事故的关键证据往往不在「它说了什么」，而在「它做了什么」：调用记录、文件变更、命令输出、环境状态。没有工具日志和权限记录，你根本无从判断错误发生在哪一环。

这也是 METR 强调独立调查的原因之一。它的建议里有一条很具体：调查者要能访问完整记录或环境来重建事故，要能自己运行出事的模型来复现行为。本质上，证据链要完整到「换一个人也能还原事故」。

六类根因，别急着甩锅给模型

拿到事实之后，下一步是归因。这里最容易犯的错误，是遇到 Agent 出错就归咎于「模型不够聪明」或「prompt 没写好」。

METR 的框架给了我们一个更好的参考：它的调查分两个领域，一是行为本身的范围和特征，二是根因能不能追溯到训练和部署条件。落到团队日常，我倾向于把 Agent 事故的根因分成六类：

根因类别	典型现象	判断问题	修复方向
规格（Spec）	任务要求含糊、目标冲突、验收缺失	换个更清楚的人来读，是不是也理解不了？	改写任务规格，明确可验证的完成标准
上下文（Context）	读到过时文档、历史信息污染、记忆冲突	给 Agent 的资料是不是本身就矛盾？	清理知识库，限定上下文来源
模型（Model）	推理失误、幻觉、错误假设	同样的输入换更强模型是否还会错？	记录失败样本，评估是否需要换模型
工具（Tool）	工具调用参数错、返回值未校验、工具本身有 bug	工具返回的数据有没有被 Agent 盲信？	修工具，在 Harness（支架工程）里加返回值校验
权限（Permission）	权限过宽、审批形同虚设、沙箱可逃逸	这件事真的需要这么高权限吗？	收紧边界，把高危操作改成人工确认
验收（Acceptance）	自评过松、验证缺失、提前宣布完成	有没有独立的验证者？没有的话谁会来验收？	拆出独立的 evaluator（评估者）或验收步骤

这张表倒不用拿来严格分类，它的作用是逼你在下结论前先问一遍：这次事故，到底是任务没说清、资料给错了、模型能力不足、工具不可信、权限太松，还是根本没人验收？

很多时候你会发现，一个「Agent 闯祸」的案例，根因其实是两个甚至三个类别叠加。比如权限过宽（Permission）加上验收缺失（Acceptance），Agent 就越权执行了高危操作，还没人拦住。区分根因的意义就在这里：不同根因，修复动作完全不同，混在一起修，等于没修。

把「写」和「验收」拆开，是堵住验收根因最直接的做法。规划、实现、评估各司其职，让 Agent 必须通过独立评审才算完成，而不是自己说自己完成了。

复盘产物不能只是一份文档

事故复盘最容易变成「写一份报告，然后归档，然后忘记」。

真正的复盘产物不是文档，而是系统变更。METR 的倡议里有一句话很关键：调查要能验证「开发者计划的对策，是否真的能可靠地消除根因」。落到团队里，这意味着每次复盘都要产出一个能写进系统的东西：

回写评估（eval）：把这次失败变成一条评估用例。下次 Agent 再遇到类似场景，能不能通过，一眼就知道。
回写权限策略：如果根因是权限过宽，就把边界收紧，把高危操作改成必须人工确认。
回写测试：如果根因是验证缺失，就在 Harness 里加一个验收步骤，让「完成」必须通过真实检查才算数。
回写运行手册：把这次事故的处置流程写进手册，包括什么时候该人工介入、谁有权限升级。

这个思路，和社区里关于 Harness 的讨论是一致的。有人在 X 上总结得很到位：Agent 的能力来自模型之外的环境，上下文、指令、工具和反馈，事故的修复也应该回写到这个环境（Harness）里，而不是只重试一次 prompt。

说到底，每一起事故的产出，都该让下一次 Agent 运行的环境变得更好。如果一份复盘没改变任何系统配置，那它大概率只是自我安慰。

越接近生产的任务，这套回写结构越像一个小型控制平面：工具、权限、日志、测试和人工审批都接入进来，Agent 的每一步都被约束和记录。

小团队的最小版本

读到这里你大概会觉得：这是大公司的做法，我们没有专门的安全团队、没有独立调查预算，做不了。

做得了，而且不需要那么重。

如果你只有一个人或一个小团队，一个最小可用的 Agent 事故复盘只需要四样东西：

任务 ID：每次 Agent 任务有一个可追踪的标识，能和日志对得上。
工具日志：Agent 调用了哪些工具、参数是什么，至少有一个地方能查到。
关键操作确认：删除、覆盖、外发数据这类高危操作，改成人工确认，哪怕只是脚本里加一步。
失败样本库：一个文件夹，把每次失败的输入、输出、归因结论存进去，下次遇到类似的，先查一遍。

这四样东西加起来半天就能搭好，看起来都很朴素，但正好覆盖了复盘最需要的：任务能对上日志、操作有据可查、失败可以复用。

失败样本库攒起来之后，好处是慢慢显现的。Agent 再出错时，你不再是「从头猜」，而是「先翻样本库」——很多问题反复出现，第一次归因过，第二次就能快速定位。慢慢地，团队对 Agent 的信任就从「它这次应该没问题」变成「它之前在这些场景出过问题，我们已经在 Harness 里堵住了」。

Agent、Harness 与事故复盘

最后把这三个概念的关系说清楚。

Agent 负责执行：调用工具、推进任务、交付结果。Harness 是包在 Agent 外面的那层结构，管工具权限、管上下文、管验证和反馈，也管刹车。事故复盘是把失败经验写回 Harness 的那条通路——每记录一次、归因一次，Harness 就多一条规则、多一道验证。

这个关系其实很朴素：Agent 决定任务怎么跑，Harness 决定它跑得稳不稳，复盘决定它下次会不会更好。哪一环缺了，另外两个都撑不住。没有 Harness，Agent 是脱缰的；没有复盘，Harness 就只会停在第一次设计时的样子。

METR 想做的是行业级版本：让 OpenAI、Anthropic 这些公司为每一起严重事故留下可独立核验的证据链。多数团队到不了那个级别，但思路是相通的——当 AI 开始替你动手，错误处理就不能只靠重试了，得有一份复盘。

不用一上来就建一整套系统，先给任务记个日志，就够了。

参考来源

METR: Investigating AI propensities after incidents（原始倡议）
METR: Frontier Risk Report（44 起事故的记录）
The Decoder: After Hugging Face incident, METR urges independent root-cause investigations（事件报道，本文事实主要来源）
OpenAI: Hugging Face model evaluation security incident（OpenAI 官方声明）
OpenAI: Harness engineering（Harness 概念来源）
Teaching AI to Find Real Vulnerabilities（Agent 评估与安全验证视角）

以上来源用于观察事件经过与行业倡议，事故具体数字（如操作次数、时间线）以官方后续报告为准，本文不将其作为独立核验过的事实背书。

事故复盘 on 奇诺分享 | 重在分享