重塑AI安全评估：Agent Incident Registry如何构建新的失效记录范式
从“碎片化报告”到“结构化登记”：AIR的诞生背景与必要性
随着大型语言模型能力的突破，AI代理不再局限于简单的文本生成，而是开始通过工具调用和委托权限，介入到更复杂的自动化任务中。然而，随之而来的安全风险也日益凸显。过去，学术界和产业界对AI代理失效的记录多为零散的案例分析、博客式的事后复盘，或是闭门的内部安全评估报告。这种碎片化的信息生态，使得研究人员难以对比不同平台、不同代理在面对相似威胁时的表现差异，也难以建立跨项目的、可复现的安全基准。
正是基于这一痛点，Agent Incident Registry（AIR）应运而生。该项目并非简单的事故日志堆砌，而是试图构建一个具备源链接能力、标签体系完备的公开 registry。文章明确指出，AIR目前收录了从 \Yfirst{} 到 \Ylast{} 之间的 \N{} 代理相关事件记录。每一条记录都配有稳定标识符和支持证据，旨在解决“如何比较公开失败与代理安全评估”这一核心方法论难题。这种从“事后复盘”向“前瞻登记”的转变，标志着AI安全治理理念的一次重要迭代。
数据画像： realized harm 与 collection composition 的辩证关系
对 AIR 数据集进行深度剖析后，研究发现其内部结构呈现出显著的分布特征。在 \Nprimary{} 个生成式系统记录中，有 \Rprimary{} 个案例涉及 realized harm（实际危害），这一比例为 \Pprimary%。值得注意的是，这些实际危害的结果高度集中在“in-the-wild”（实际部署环境）和 safety-failure（安全失败）类记录中。反观 responsible disclosures（负责任的披露）和 research demonstrations（研究演示），则占据了绝大多数情况。
这种分布并非偶然，也并非意味着整个行业的安全形势良好。文章对此进行了深刻的观点表达：这些 realized outcomes（实际结果）的聚集，更多地反映了该数据集的收集构成，而非当前部署场景的真实风险概率。换言之，AIR 的现有结构在很大程度上记录了研究者和披露者的活跃度与倾向，而非代理系统在野外持续、无差别地产生危害的频率。这种“收集偏差”提醒我们，在解读任何安全数据时，都必须先审视其来源与筛选机制。
审计视角的差异：InjecAgent 案例与无对抗者失效
为了验证 AIR 的实用性，研究团队进行了一次 deployment-analogue audit（类部署审计）。在此过程中，InjectAgent 的 \NInjecAgentCases{} 案例占据了 AIR 十二个表面中的三个，且全部由攻击者触发。这一观察结果极具启示性：它表明，在缺乏明确对抗性测试的常规登记中，这三个案例的出现或许并非代表系统普遍存在的安全漏洞，而更可能是特定攻击向量下的响应。
更为关键的是，AIR 中目前并不存在 no-adversary safety failures（无对抗者安全失败）的记录。这一反差凸显了当前 AI 安全评估体系的一个重要盲区：大量的安全焦虑往往源于对抗性场景，而非日常运行中的非故障行为。对于希望评估其系统在“无恶意干扰”下的鲁棒性的开发者而言，AIR 提供了一个可以对标的基准，有助于区分“由于攻击导致的失效”与“自然状态下的失效”。
工具属性：检索与审计，而非单纯的失效率估算
归纳 AIR 的核心定位后，文章认为该注册库的主要价值在于“源 grounded case retrieval”（源 grounded 案例检索）和“evaluation-scope auditing”（评估范围审计）。它构建了一个可以追溯、可核实的失效知识库，允许研究人员针对特定机制或特定类型的危害进行深入挖掘。
然而，文章也明确指出了 AIR 的边界。它并非旨在提供一个简便的“失效率计数器”。试图用 AIR 的记录数量来直接估算 AI 代理在实际部署中的危害概率，在方法论上是站不住脚的。正如前文所述，该数据集的结构本身就带有显著的筛选偏差。对于产品经理、安全工程师而言，AIR 更像是一份详尽的“病例手册”，帮助他们理解不同类型的失效是如何被记录、披露和分类的，从而在设计缓解措施时能有的放矢。
前瞻展望：结构化登记对行业标准的推动
展望未来，Agent Incident Registry 的意义在于它为 AI 代理安全治理搭建了第一块基石。随着越来越多的项目加入、更多样化的失效机制被纳入，AIR 有潜力演变为一个行业共识的基准库。未来的研究方向或许可以关注如何减少收集过程中的偏差，如何更精准地区分“攻击触发的失效”与“自然状态下的失效”，以及如何将这些结构化数据转化为具体的安全增强指标。
对于正在部署 AI 代理的企业和开发者而言，忽视此类结构化的失效档案将是一个战略盲点。AIR 的出现提醒我们：在 AI 的快速迭代中，记录“它是怎么失败的”可能比单纯计算“失败了多少次”更为关键。构建可追溯、可比较的失效生态，是从实验室走向可靠自动化的必由之路。