如何串联Agent调用审计链路?

Agent 的一次“帮我处理一下”背后，往往不是一条日志，而是一串跨系统动作：理解用户意图、选择工具、读取数据、发起写入，再把结果带回对话。如果这些环节各记各的，出了问题只能看到零散的成功或失败，很难回答最关键的问题：这次动作究竟是谁发起、经由谁决策、最终影响了什么。

串联审计链路，先要给一次任务建立贯穿全程的关联标识。用户请求进入会话时生成它，之后每一轮 Agent 决策、每次工具调用、每个下游系统的处理结果，都携带同一标识。这样调查时不必从海量日志里猜测关联关系，而是能顺着一条线还原：用户提出了什么需求，Agent 以什么身份执行，调用了哪项能力，资源范围是什么，策略为何放行或拒绝，最终结果如何。

不过，关联标识只是“线”，审计字段才是“证据”。一条有用的记录至少应保留发起人、会话、Agent 身份、租户或业务上下文、工具名称、目标资源类别、动作类型、策略决策和执行结果。尤其别只记录成功操作。被拦截的批量导出、越权读取或高风险写入，往往比正常调用更能暴露策略缺口和试探行为。

这里容易走向另一个极端：为了可追溯，把完整提示词、完整返回数据都塞进日志。这样确实“看得更全”，却可能把日志变成新的敏感数据副本。更稳妥的做法是记录完成调查所需的上下文，对个人信息、客户机密和密钥类材料进行脱敏或不可逆处理；确需保留细节时，也应放在受控的位置，而不是散落在普通日志中。

最后别忽略审计链本身的可信度。业务执行权限与日志查看、修改权限应分开；策略变化也应留下版本线索。真正可用的审计，不是事后拼出一个看似合理的故事，而是在任何一跳出现异常时，都能沿着同一条链确认当时发生了什么、谁该负责，以及下一次该把哪一道闸门收紧。