给AI Agent补一套可追责日志：6类事件、3个存储原则和1次越权演练

普通接口报错，查请求日志、数据库记录和调用链，通常能拼出发生了什么。

AI Agent出问题时，事情没这么简单。它可能先读邮件，再根据邮件内容调用脚本，随后换一组凭据访问代码仓库。最后页面只留下一句“任务已完成”，中间到底经过哪些判断，没人说得清。

所以Agent上线前，除了权限控制，还需要一套独立的运行证据。它不是给模型看的思维链，而是给研发、安全和业务人员用的事故日志。

SAFE草案提供了一个现实参照

Open Secure AI Alliance公开的SAFE草案，试图建立AI智能体事故共享机制。它目前是行业草案，不是已经生效的法律，但提出的事件范围很实用：未经授权访问第三方系统、突破身份或沙箱边界、接触第三方机密信息，以及差一点造成损失的未遂事件，都应该留下记录。

草案背后有120多家机构参与讨论，这说明Agent事故已经不再只是实验室里的假设。

对工程团队来说，最值得借鉴的不是报告格式，而是两个要求：事故必须尽快通知受影响方，证据必须在任务运行时形成。

日志先解决“串不起来”的问题

Agent的一次任务会跨越模型服务、工具网关、身份系统、数据库和外部平台。如果每个系统只保存自己的请求ID，事故发生后很难把它们放进同一条时间线。

最少要有三个贯穿全程的标识：

• run_id：一次Agent运行；
• event_id：运行中的单个事件；
• trace_id：跨系统调用链。

不要只记录“工具调用成功”。真正有用的事件至少要回答：谁发起、Agent以什么身份执行、目标资源是什么、参数来自哪里、系统产生了什么副作用。

六类事件足够搭起第一版黑匣子

第一类是 trigger，记录任务入口、发起人、组织、会话和原始目标。

第二类是 context，记录Agent读取了哪些文档、网页、邮件或代码，内容来自可信系统还是外部输入。这里不一定保存全文，可以保存来源、版本和内容指纹。

第三类是 permission，记录运行开始时可用的工具、凭据、网络范围和资源边界。否则事后只能看到Agent做了什么，却不知道它当时被允许做什么。

第四类是 tool_call，保存工具名称、关键参数摘要、执行身份、返回状态和耗时。

第五类是 side_effect，记录真正发生的变化，例如数据库写入、文件修改、消息发送、权限调整和代码提交。

第六类是 recovery，记录告警、暂停、人工接管、凭据吊销和数据恢复。

一条最小事件可以这样设计：

{
  "run_id": "run_7f31",
  "event_id": "evt_0042",
  "trace_id": "trace_91ad",
  "event_type": "tool_call",
  "occurred_at": "2026-08-12T09:18:42+08:00",
  "actor": {
    "agent_id": "release_assistant",
    "initiator_id": "user_1024",
    "credential_id": "svc_git_writer"
  },
  "target": {
    "system": "git",
    "resource": "repo/payment-service",
    "environment": "production"
  },
  "action": {
    "tool": "create_branch",
    "arguments_hash": "sha256:...",
    "result": "success"
  },
  "approval_ref": "approval_8821",
  "policy_version": "agent-policy-2026.08.1"
}

字段不必一次设计到完美。先保证跨系统能够关联，再逐步补充风险标签和业务信息。

三个存储原则比字段数量更重要

第一，证据写入模型无法删除和修改的存储。Agent可以生成摘要，但不能成为自己唯一的记录员。

第二，保存原文要克制。提示词、邮件和文档可能包含密钥、个人信息与商业资料，日志系统不能因为追求完整而变成新的泄漏源。能用摘要、哈希和对象版本定位的内容，不要无条件保存全文。

第三，高风险动作必须留下审批快照。只记一个 approved=true 没什么用，还要保存审批人当时看见的目标、参数和风险提示。

SAFE草案也特别强调证据保存和后续调查材料。

72小时要求倒逼日志在运行时生成

草案提出了分阶段通知时限，包括尽快通知直接受影响的组织、72小时内通知存在可信暴露风险的客户，以及后续事实报告和修复状态。

这类时限意味着团队不能等事故发生后，再去群里问“谁还记得当时Agent做了什么”。证据如果没有在运行过程中产生，后面补出来的只会是人的回忆和模型的总结。

上线前做一次越权演练

最简单的验收方法，是故意设计一个会触发边界的任务。

例如让测试Agent尝试读取无权访问的目录，再申请一次高风险工具调用。运行结束后冻结日志，让研发、安全和业务人员分别复盘，然后比较三方能否回答同样的问题：

1. 谁启动了任务；
2. Agent读到了什么；
3. 哪条内容改变了后续计划；
4. 它实际调用了哪些工具；
5. 哪一步被拒绝或批准；
6. 系统产生了哪些真实变化。

如果三方只能依靠聊天记录猜测，黑匣子就还没有建成。

Agent的护栏负责减少事故，审计日志负责解释事故。两者不是替代关系。系统越有自主执行能力，越需要把模型外部的证据做扎实。

等到它真的闯祸以后再补日志，通常已经晚了。

参考资料

• SAFE原始草案
  https://github.com/OpenSecureAIAlliance/RFCs/blob/main/rfc-safe-proposal.md
• Axios相关报道
  https://www.axios.com/2026/08/11/open-source-security-ai-agent-reporting