AI Agent治理从口号到落地：可审计的执行日志应记录哪些关键字段

部署AI Agent的企业越来越多，但一旦Agent执行了错误操作——比如误删数据、越权调用API、做出了不符合预期的决策——真正能追溯原因的却少之又少。很多团队发现，Agent跑了，日志也记了，但事故发生时根本找不到“谁下的指令、用了什么权限、调用了哪个模型版本、中间有没有人确认过”。这种现状的根源，在于大部分企业的Agent日志还停留在“记录接口调用”的层面，离可审计差了很远。

可审计的日志不是为了排查Bug，而是为了事后还原完整的执行链路，明确责任归属，满足合规要求。无论是欧盟AI法案即将生效的强制日志要求，还是SOC 2、ISO 42001等标准对审计线索的规定，都指向同一个核心：日志必须能支撑“谁、在什么时间、基于什么上下文、采取了什么动作、结果如何、是否被授权”的完整追溯。下面这张图展示了可审计日志在Agent执行流程中的关键作用。

身份与溯源：知道“谁”发起了动作

可审计日志的第一个硬性字段是调用方标识。这个标识不限于用户ID，还应该包括Agent自身的ID、会话ID，以及触发该次执行的上游调用链。当需要定位“是哪个Agent在什么上下文中调用了数据库”时，仅靠一个用户ID远远不够。IETF的Agent Audit Trail草案中，把Agent身份标记为强制字段，并且要求每个事件都能关联到唯一的执行会话。实际落地时，建议至少包含：

• Agent ID：标识执行该动作的具体Agent实例。




• Session ID：标识一次完整的任务会话，便于将多个动作串联成一条链路。




• 调用方来源：发起该动作的实体（用户、其他Agent、定时任务或外部系统），并记录其身份认证方式。

这些字段构成了事后追查的第一层过滤网：先找到“谁在什么时候启动了任务”，再往下看具体做了什么。

动作与上下文：还原“做了什么”以及“为什么这么做”

有了身份，下一个问题是Agent到底执行了什么操作。常见的日志只记“调用了某某API”，但审计需要更细粒度的元数据。关键字段应包括：

• 动作类型：读、写、删除、授权、执行等，用标准化的分类描述，便于后续按动作类型批量检索。




• 目标资源：实际访问或修改的对象，例如数据库表名、文件路径、API端点、用户账户等。需要记录资源的唯一标识和类型。




• 输入参数与指令：Agent执行时收到的原始输入或指令内容（脱敏后），以及当时传递给工具或外部系统的参数。这一步是还原“为什么走到这一步”的核心证据。




• 时间戳：精确到毫秒，包含时区信息，且所有日志应使用统一时间源，防止时间错位导致链路混乱。

除了这些，还应该记录Agent执行时的上下文状态，例如当前任务的目标、已完成的步骤、触发该动作的推理路径（如果Agent框架暴露了内部决策链，应记录关键节点）。没有上下文，只看孤立动作很难判断是Agent自主决策还是被恶意指令诱导。

权限与数据范围：验证“能否这么做”

审计日志不能只记录“做了”，还必须记录“在什么权限范围内做的”。否则出了事故，无法判断是权限配置不当还是Agent行为越权。建议强制记录：

• 授权边界：Agent执行该动作时实际持有的权限集合，例如可读写的数据库表、可调用的API列表、可访问的用户数据范围。最好记录权限的版本号或定义标识。




• 数据访问范围：实际读取或修改的数据集范围，比如“查询了用户表ID=1~1000的记录”或“仅修改了字段status”。如果Agent有独立的隔离环境，还需记录环境标识。




• 权限来源：该权限是显式授予、继承自角色，还是通过临时提权获得的。这有助于定责时判断是Agent越权还是权限管理本身有漏洞。

当Agent需要访问敏感数据或执行高危操作时，日志还应记录是否经过了人工确认节点：是谁、在什么时间、通过什么方式确认了该操作。没有人工确认记录的越权操作，本身就是合规漏洞。

结果与可信度：判断“执行得怎么样”

动作结束后，日志必须记录最终结果，否则无法判断Agent是否成功完成了任务，还是中途出错或失败。关键字段包括：

• 执行结果：成功、失败、部分成功、未执行（如超时或被拒绝）。失败时需记录错误码和错误描述。




• 输出数据与副作用：Agent执行后返回的结果，以及对系统状态产生的实际影响。例如，写操作后受影响的行数、文件变更哈希、API调用的响应状态码。




• 信任级别：IETF草案中提出了信任级别报告，用于记录Agent在决策时对自身推理的置信度、外部输入的可信度，以及是否使用了低质量的模型输出。这对定责很重要——低信任度下的盲目操作，责任更可能落在系统设计而非Agent本身。




• 模型版本与推理参数：如果Agent调用了大模型，应记录使用的模型标识、版本号、推理参数（如温度、最大Token数），以及是否使用了缓存或外部知识库。不同版本、不同参数下的行为差异巨大，没有版本信息无法复现问题。

非篡改与完整性：让日志本身成为证据

最后，所有上述字段必须存储在不可篡改的日志中。IETF草案建议使用SHA-256哈希链，将每条日志通过前一条记录的哈希链接起来，形成防篡改的审计线索。企业级部署还应考虑：

• 日志存储独立：日志应写入与Agent运行环境隔离的存储，例如专用的审计日志库或安全事件管理平台（SIEM）。




• 访问控制：日志的写入权限严格限制，读取权限也需审计。谁在什么时间查看了日志，本身也要被记录。




• 保留策略：根据法规要求设置日志保留期，例如欧盟AI法案要求高风险AI系统至少保留日志整个生命周期。

对照检查清单

读完这篇文章，你可以对照自己的Agent日志体系，逐一检查以下问题：

• 每条日志是否包含Agent ID、Session ID和调用方来源？




• 是否记录了动作类型、目标资源和输入参数？




• 是否记录了Agent执行时的授权边界和数据访问范围？




• 高危操作是否有人工确认记录？




• 日志是否包含执行结果、错误信息和模型版本？




• 日志存储是否不可篡改、与运行环境隔离？




• 日志的访问权限是否受控，并有审计？

如果有一项不符合，说明你的Agent审计体系还有缺口。在AI监管日渐收紧的今天，补上这些字段不是锦上添花，而是事故问责和合规检查的底线。