这周 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 评估与安全验证视角）
以上来源用于观察事件经过与行业倡议，事故具体数字（如操作次数、时间线）以官方后续报告为准，本文不将其作为独立核验过的事实背书。