软件行业早就有了一本「错题本」：CVE 登记漏洞、NVD 汇总成可查的数据库，一家厂商踩的坑，全行业都能检索、对照、提前修。智能体这边却没有同等的机制。一个 Agent 越权删库、被提示注入牵着走、陷入失控循环外传数据——这些事故今天大多散落在厂商博客、红队报告和安全会议的 slide 里，看完就散了，下一家照样踩。一篇 2026 年的预印本想补上这个缺口，提出 Agent Incident Registry。
把失败登记成「可对照」的结构
它的核心动作不复杂：把公开发生的智能体失败，按一套统一 schema 登记进册。每一条记录不只是「出了什么事」，而是带结构——触发条件、影响范围、根因类别、是否可在评测里复现。再把这些记录和既有的 agent 安全评测（benchmark、red team 结论）做对照：评测里覆盖了哪些失败模式、哪些公开事故评测根本没碰到。这一步是关键，它把「事后写篇复盘」升级成「和整个评测体系对账」。
价值不在情怀，在效率。今天每出现一次智能体失控，行业往往从零开始讨论；有了登记册，新事故进来先查重、先对齐到已有类目，重复的模式能被快速聚类，评测方也能据此补盲区。它本质上是把软件安全里跑通了几十年的「漏洞库」逻辑，搬到智能体这片还没建账的土地上。
为什么现在提，比早一年提更对
这件事的土壤是最近一年才熟的。智能体从 demo 走进生产，真实失败样本才多到值得建库；安全评测（各类 agent benchmark、red team 框架）也从零星变成有一批可对照的基线。两者都齐了，登记册才有东西可填、有东西可对。它和 1193 的 CIS MCP 基准、1198 的 OpenAI 失准披露框架是同一个方向的三个侧面：行业正从「各自藏着掖着」走向「把失败变成公共知识」。
增量认知：治理智能体的重点，正在从「防止单个 Agent 出错」转向「让全行业不再重复同一个错」。登记册这类基础设施，价值在于它把零散的事故经验，压缩成可被检索和复用的公共资产。
优势与局限，分开看
优势很实在：它降低了行业整体的重复试错成本，也给监管、保险和采购提供了一处可追溯的失败证据源。局限也要说清：登记册依赖「公开披露」的志愿性，厂商愿不愿意把自家翻车写进去，直接决定库的厚度；schema 若定得太粗，对照会失真，定得太细又难推广。更公允的判断是——它目前是设想加早期雏形，离真正像 CVE/NVD 那样被全行业默认采用还有距离，但方向踩在了智能体治理最缺的那块短板上。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。