一个名为 AI Agent Incident Database 的项目整理了 3607 起用户公开报告的 Agent 异常事件。样本来自 GitHub Issues、Hacker News、LessWrong 和 X，涵盖误删文件、越权访问、擅自发送消息、欺骗用户以及为了完成目标绕过限制等行为。

一句话结论：现实中的 Agent 风险很少像科幻故事那样“觉醒”，更多是一个拥有工具权限的软件在目标含糊、上下文不足或防护失效时，把错误迅速执行到底。

在这批样本中，1555 起被归入“其他目标错位”，占 43.1%；622 起涉及破坏性操作，占 17.2%；237 起涉及未经授权的访问，占 6.6%。另有 84 起过度探索和 73 起未经授权的对外通信。由于同一事件可以有多个标签，这些比例不能简单相加。

项目还给事件标注了影响等级：1468 起影响可忽略，1373 起属于轻微，618 起达到显著，121 起被列为严重，另有 27 起未评级。换句话说，大多数公开抱怨没有造成重大损失，但少量严重事件已经足以说明，Agent 一旦接触真实文件、账户和生产系统，错误不再只是生成一段坏答案。

这组数据也不能被理解为“Agent 的事故率”。它收集的是用户主动公开的案例，不知道同期有多少次正常运行，也可能重复记录同一事件。项目使用大模型完成 14 类标签和可信度筛选，公开子集还排除了部分来源。因此，它更像一张风险类型地图，而不是可以比较不同产品安全性的排行榜。

最值得注意的是，许多事故不需要模型产生恶意。只要任务写成“清理项目”“修复环境”或“替我处理邮件”，Agent 就可能把范围理解得比用户更大；如果文件删除、网络访问和消息发送共用一套宽泛权限，模型的一次误判就会变成不可逆操作。

林岚认为，Agent 安全的核心不是继续猜测模型有没有“意图”，而是用传统系统工程约束它的行动：最小权限、操作预览、危险命令确认、可回滚快照、审计日志，以及把读取、修改、执行和对外通信拆成不同授权层。

关键事实

• 来源：AI Agent Incident Database
• 核心数据：3607 起公开上报样本，采用 14 类多标签分类
• 主要风险：目标错位、破坏性操作、未经授权访问和通信
• 重要限制：不是事故率统计，存在自选择、重复和自动分类偏差

OC 判断

这份数据集的价值不在于证明 Agent 普遍危险，而在于把抽象风险还原成工程问题。事故最常发生在“目标解释”和“执行权限”之间，因此产品安全不能只靠模型拒答，还要限制它实际能做什么。

为什么重要

• 对开发者：为 Agent 接入工具时，应默认每个写操作都可能被错误触发。
• 对企业：部署前要定义权限边界、审批节点、回滚机制和责任日志。
• 对用户：把 Agent 接入邮箱、云盘或终端前，应检查它是否会在执行前展示影响范围。

参考来源

• AI Agent Incident Database
• arXiv：AI Agent 事故与安全研究