AI Agent 审计日志：如何串联对话、检索与工具调用
一次回答正常，不代表后台动作可追溯。围绕关联标识、执行身份、权限判定和结果状态，梳理智能体审计日志的记录边界与验收方法。
面对一次“处理完成”的回答，排查人员可能仍有疑问：智能体检索了哪个版本的资料，权限检查是否通过，工具是否真正执行，业务系统最后返回了什么？如果这些记录散落在不同组件中，仅靠聊天截图和相近的时间，很难还原同一笔操作。
AI Agent 审计日志需要连接可核查的事件，而不只是保存更多对话。本站安全与合规说明将日志字段与保存期限列为按审计制度配置的内容。以下是通用设计与验收建议，不预设某个日志平台，也不代表本站采用了文中的固定字段或已经完成对应测试。
先分清对话内容与执行事实
对话记录回答“用户提出了什么、界面展示了什么”；调用链帮助定位“请求经过哪些组件、哪里耗时”；审计记录则要帮助复核“谁以什么身份，对什么对象进行了什么操作，依据和结果是什么”。它们可以共用基础设施，但记录范围、访问权限和保留规则不必相同。
模型生成的说明不能替代服务端的权限判定，也不能替代业务系统的执行回执。人工确认通过、请求已发送、接口返回成功与业务状态已更新，属于不同阶段，不能都压缩成一个“成功”。通常也不需要收集模型隐藏的推理过程来证明业务动作，应该依赖可观察的请求、判定与结果。
因此，先约定哪些事件必须记录，包括被拒绝的请求、取消的操作和待确认的结果，而不是只保留最终成功的调用。记录范围应从实际场景出发，不把所有调试输出都当成审计证据。
用关联标识串起一次任务
一段对话可能发起多个任务，一个任务又可能包含多次检索和工具调用。只记录一个对话编号，往往无法区分具体动作；为每个事件随机生成编号，却不记录彼此关系，同样难以追溯。可以按现有系统的标识能力区分以下层次：
- 会话与任务：会话引用关联多轮交流，任务标识关联一次明确的处理过程。这里的会话引用是业务标识，不是登录 Cookie 或认证令牌。
- 业务动作与调用尝试：同一动作的重试保留稳定的业务关联标识，同时区分每次尝试，避免把两次网络请求误认成两笔业务。
- 事件与前后关系：给事件保留可去重的标识，并记录它对应的任务、动作或前序事件。异步队列和回调也需要传递或映射这些关系。
如果已有链路追踪，可利用现有标识，不必再造一套平台。OpenTelemetry 的日志数据模型提供可选的 TraceId 和 SpanId 字段，用于关联请求及处理片段；提供 SpanId 时应同时提供 TraceId。业务任务编号与链路编号如何映射，仍需要应用自己约定。
关联标识不是授权凭证，收到外部传入的追踪头，不代表已确认调用者身份。W3C Trace Context 规范也明确，traceparent 和 tracestate 不应携带可识别个人或其他敏感信息。不要为了检索方便，把姓名、证件号或业务正文拼进这些字段。
最小字段要回答哪些问题
AI Agent 工具调用日志应该记录哪些字段？可以先围绕下面五类问题制定字段表，再按实际场景取舍。字段名不是通用产品接口，也不要求每种事件填满所有内容；不适用与未知应有明确含义。
- 谁发起、谁执行：区分发起用户、委托关系和实际使用的服务身份，保存受控引用，不保存其认证材料。后台服务账号不等于业务发起人。
- 做什么、作用于哪里：记录动作类型、工具版本、目标系统及受控对象引用。参数只保留约定允许的字段、摘要或引用，并标明是否经过裁剪。
- 依据什么判定：记录允许或拒绝、可解释的原因分类、适用策略版本；需要人工确认的动作，关联确认记录与确认时的操作范围。
- 使用了哪些资料：对需要来源追溯的检索，记录文档引用、文档版本或索引版本，以及对应的权限范围判定。不要用完整检索片段替代版本信息。
- 结果如何确认：区分未执行、已发起、被拒绝、已确认成功、已确认失败和结果待确认，关联可核查的业务回执或状态查询记录。
例如，在一个假设的工单更新任务中，“用户确认了修改”只能证明确认环节；“工具请求超时”只能说明本次调用没有及时得到响应。要判断工单是否已更新，还要看业务系统回执或后续查询。审计记录应能关联这些证据，而不是让模型替缺失的结果作结论。
时间、结果和版本需要一起看
跨组件排查时，日志出现的先后顺序未必就是事件发生的先后顺序。OpenTelemetry 日志数据模型区分源端记录的事件时间 Timestamp 与采集系统观察到事件的时间 ObservedTimestamp。批量发送、延迟到达和时钟差异，都需要在解释时间线时考虑。
实际验收中，应明确时间格式、时区、时钟来源和允许的偏差，结合关联标识与前后关系还原过程，不仅凭“相差几秒”把两条记录拼在一起。时间来源不可靠或发生采集延迟时，保留这一限制，不制造看似精确的顺序。
结果也要保留变化过程。待确认的动作后来查明成功，可以新增一个关联的确认事件，而不是覆盖最初的超时记录。记录适用的工具、流程、策略和资料版本，才能判断事后查看的配置是否就是当时使用的配置；这里记录的是版本引用，不是把所有配置内容复制进日志。
至于如何避免超时后的重复写入，可另见ERP 写接口的重试与幂等处理。日志能帮助复核过程，但不能代替业务系统本身的幂等控制。
日志不应成为第二份敏感数据库
“审计日志是否需要保存完整提示词和工具返回”不宜用一律全存来回答。提示词、检索片段、参数和异常信息都可能包含个人信息、内部资料或认证材料。优先采用字段允许清单与内容引用，让排查者知道发生了什么，而不是默认复制全部原文。
OWASP Logging Cheat Sheet提醒开发者避免直接记录访问令牌、密码、连接串和其他秘密，并对日志输入做校验与适当编码，防止换行或分隔符形成伪造记录。脱敏应覆盖嵌套字段、异常信息和第三方返回，而不只检查一个固定名称的字段。
例如，可记录“工单状态字段变更请求”和受控工单引用，而不是把整份工单、请求头和响应体放进统一检索索引。确有必要留存原始材料时，应另行确认用途、授权、访问范围和保存期限，并通过受限引用关联；不能因为叫“日志”就降低数据保护要求。
记录关联标识也不等于实现匿名化：如果它能被映射回业务人员或对象，仍需要适当的访问控制。日志查询与导出不能成为绕过业务权限的入口，读日志的人不应因此自动获得全部文档正文。
把缺失、拒绝和导出纳入验收
不要只用一条正常请求检查日志页面。调用链采样可能让部分请求不被保留；OpenTelemetry 的采样文档指出，仅靠头部采样不能保证保留所有包含错误的链路。因此，若某类审计事件要求完整留存，就不能默认沿用普通性能追踪的采样规则。这是采集策略的区分，不意味着必须另建一套系统。
可以在授权的测试环境中，围绕同一组任务增加以下检查：
- 正常与拒绝：分别执行允许和拒绝的动作，确认能定位发起身份、目标、判定依据和结果，且拒绝记录不会被成功事件掩盖。
- 异步与重试：让事件延迟到达或经队列处理，确认关联关系仍然完整，重复投递可以识别，不会把一次任务统计成多次业务完成。
- 未知与后续确认：制造受控超时，再查询业务状态，检查前后记录是否并存且可关联，未确认前不被标成执行成功。
- 采集故障：模拟日志接收端不可达或存储受限，检查告警、缓冲边界和恢复后的缺失情况。高风险动作在审计不可用时应暂停还是受控降级，需要提前约定，不能临时静默忽略。
- 敏感字段与异常文本：使用明确标注的虚构测试值，检查提示词、工具参数、异常和导出文件是否遵守同一脱敏范围，特殊换行不能伪造新的事件。
- 读取与保留：用不同权限账号检查查询和导出范围，并检查保留、删除及配置变更是否符合已约定的策略。不能仅凭“可导出”就声称具备防篡改能力。
最终交付的不是一张日志列表截图，而是字段说明、关联关系、采集与保留配置、测试样例、实际结果和未覆盖边界。可以结合POC 验收口径逐项记录；涉及检索对象的可见性，还应与知识权限变更与历史入口的规则保持一致。能解释缺失与未知，比堆满记录后笼统承诺“全程可追溯”更有意义。
参考资料
资料查阅于 2026 年 9 月 11 日。以下官方资料用于说明日志字段、追踪与采样的边界；文中的字段分组和测试场景是通用建议，不构成产品测试、客户案例或合规结论。
