一名监管人员给你发了一封邮件，只问了一个问题：该用户是否授权了这笔交易？六小时后，三名工程师正在聊天频道里，试图将聊天界面的对话日志、规划代理（planner agent）的推理追踪以及工具的 API 记录关联起来。聊天日志记录了轮次 ID（turn ID）和用户可见的消息，但没有工具调用的细节。规划器追踪记录了工具调用的记录，其时间戳与聊天日志相差几百毫秒。工具日志记录了 API 调用及其自身的关联 ID（correlation ID），而该 ID 在代理的记录中无处寻觅。下游服务的日志则有另一个 ID，且没有回溯链接。团队最终通过关联用户 ID 和大致的时间戳重建了答案，祈祷没有什么关键信息因错过一个轮次而产生偏差，最后向法务部门提交了一份 PDF 文件。
代理运行时日志记录了一个规划器追踪：系统提示词（system prompt）、组装好的上下文、规划器选择的工具、构建的参数以及总结的响应。它有自己的请求 ID。回到聊天界面的链接是“用户 ID + 大致相同的时间戳”，因为聊天界面没有传递关联标头（correlation header）。
工具日志记录了一个 API 调用：方法名、参数、HTTP 状态、延迟、租户 ID 以及工具自身的关联 ID。代理运行时通过一个不透传运行时请求 ID 的 SDK 调用了该工具，因此工具日志只能通过租户和时间戳与代理日志关联。
下游服务日志——即实际发送报告的邮件提供商——记录了一个消息 ID、接收者、附件哈希和发送时间。工具通过一个不转发上游 ID 的供应商 SDK 发送请求。邮件提供商在边界处标记了一个全新的消息 ID。
四个日志。四种 ID 方案。零重叠。关联它们需要（用户 ID 或 租户 ID）且（带容差的时间戳）——这种查询返回错误行的频率与不可靠的集成测试一样高，而且是悄无声息地出错。关于“该用户是否授权了这笔交易”的审计故事是由人工通过交叉引用活动窗口重建的，而且每当用户的会话包含多个工具调用时，情况就会变得更糟。
这三个事实是：用户请求了什么、代理决定为此做什么以及工具实际执行了什么。它们并不是同一个陈述。用户请求的是“发送第二季度报告给我的 CFO”。代理决定使用从上下文中推导出的特定附件、接收者和主题来调用 email.send。工具执行了一个产生消息 ID 的 HTTP POST，并由下游提供商处理，而该提供商可能遵循也可能没有遵循每一个标头。
仅捕获其中一个事实（用户的文本、规划器的意图或 API 的效果）的日志在个体上是真实的，但在回答授权问题时集体失效。监管机构关心的是关联：用户请求了 X，系统推断出 X'，现实世界接收到了 X''。X 和 X'' 之间的偏差才是合规问题的核心，而当每一层的日志只知道三者之一时，这种偏差就无法被检测到。
一个可行的代理操作审计记录应该是一个包含所有三个事实的单一文档，在操作完成的那一刻编写一次，并由用户操作边界处生成的交易 ID（transaction ID）进行索引。聊天层、代理层、工具层和下游层各自照常记录日志——但它们也会将交易 ID 输出到各自的日志中，一个专门的审计流水线通过读取交易的权威追踪来组装这“三个事实”记录，而不是在事后关联四个异构的日志流。
到了第 15 天，审计记录就不完整了：规划器的推理已被删除，但聊天消息和 API 调用仍可检索。到了第 31 天，只剩下 API 调用和消息元数据。如果一个团队认为自己可以重构一年前的操作，仅仅是因为电子邮件提供商有一年的日志，那么他们会在最糟糕的时机发现，“用户请求了什么”和“Agent 决定了什么”都在几周前就过期了。
