AI Agent 出问题以后，团队最怕看到一堆日志，却回答不了几个简单问题：是谁发起的任务，Agent 代表谁调用了工具，权限从哪里来，输出有没有外发，最后是谁确认放行的。日志很多，不等于审计可用。
审计查询字段的目标，是让复盘人员能按真实问题快速检索，而不是把原始日志从头读到尾。它应该和 权限审计、凭证轮换、证据归档 放在同一套运行体系里。
任务 ID 是第一根线
每一次 Agent 运行都应该有稳定的任务 ID。它要贯穿用户输入、计划拆解、工具调用、人工确认、输出结果和后续回放。没有任务 ID，复盘时只能靠时间和关键词猜测，非常容易漏掉相关动作。
任务 ID 还要能关联批次、队列和版本。比如某次知识库改版后出现异常，团队要能查出同一版本下受影响的任务，而不是只看单条失败记录。
身份和权限要分开记录
审计里至少要区分三层身份：发起用户、Agent 身份、被代表的业务身份。很多事故不是工具坏了，而是 Agent 拿错了身份，或者用共享账号完成了本该由个人确认的动作。
权限来源也要单独记录。它来自角色授权、临时令牌、人工放行，还是某个旧配置。这里能和 AI Agent 凭证轮换 形成闭环，方便发现长期密钥和越权调用。
工具调用要能看见前后文
只记录工具名称和成功失败不够。复盘时还需要看到输入摘要、关键参数、返回状态、错误码、重试次数和输出去向。敏感内容可以脱敏，但不能把上下文删到无法判断。
如果工具调用涉及客户可见动作，还要记录确认人、确认时间和确认理由。这一点可以参考 客户可见动作确认 的分层方式。
查询维度要贴近复盘问题
审计字段不是越多越好，而是要能回答高频复盘问题：某个用户触发了哪些高风险工具，某个 Agent 今天外发了哪些内容，某个知识库版本影响了哪些回答，某个凭证被哪些任务使用过。
这些问题如果只能靠工程师临时写脚本，审计就还没有真正产品化。至少要给运营、安全和业务负责人留出可查询的字段入口。
总结
AI Agent 审计查询字段的关键，是让任务、身份、权限、工具、确认人和证据链能被快速串起来。复盘时能查清事实，团队才有机会把一次异常变成下一轮改进。
