智能体审计的核心，不是证明“系统调用过某个接口”，而是证明一次业务结果如何产生、由谁授权、经过哪些判断，以及出现错误后能否定位责任。只有把用户身份、智能体身份、业务上下文、工具调用、人工确认和最终写入结果串联起来，审计记录才具备责任追溯价值。
责任链必须形成闭环
一条可验证的责任链，至少应回答四个问题：谁发起了任务，智能体在什么条件下执行了什么动作，哪个业务系统实际改变了数据，出现问题后由谁确认、处置和恢复。
因此，单独保存聊天记录或接口日志都不够。审计记录应关联以下信息：
- 身份证据：发起人、组织或角色、智能体身份、智能体版本、调用渠道。
- 上下文证据：任务编号、触发时间、关联客户、订单、项目或工单，以及当时的业务状态。
- 决策证据：智能体选择了哪些工具，执行了哪些校验，使用了哪些规则，是否触发风险判断。
- 执行证据：接口名称、关键参数摘要、调用顺序、返回状态、重试情况和最终变更结果。
- 授权证据：确认人、审批节点、审批时间、确认内容，以及是否存在临时授权或范围限制。
- 补救证据：异常处理人、撤销动作、回滚结果和后续策略调整。
这些记录不能只停留在智能体平台内部，还应与业务系统的原生日志关联。因为真正改变订单、付款状态或工单状态的，通常是业务系统，而不是智能体的语言输出。责任归属必须以实际生效的系统动作和授权记录为依据。
让证据经得起复核
人工确认也必须具备证据质量。若确认界面只显示“是否继续”，用户并不知道智能体将修改哪些对象、使用哪些数据、影响多大范围，这种点击不能充分证明用户理解并承担了相应责任。有效确认应展示动作、对象、关键字段变更、异常信息、影响范围及是否可撤销，并区分“接受建议”和“批准执行”。
审计还要防止责任链被高权限账号截断。智能体不应与所有用户共用一个无法区分主体的账号；更合理的方式是采用“用户身份 + 智能体身份 + 业务上下文”的联合授权，并为工具调用设置数据范围、参数约束和前置条件。权限不足时应拒绝，无法判断时应转人工，异常调用时应暂停或终止。
最终，责任链的证明标准不是日志越多越好，而是能否完整还原一次任务：谁提出意图，智能体依据什么规则行动，谁授权了关键步骤，哪个系统写入了结果，以及错误发生后谁采取了补救。能被独立复核、相互印证并支持恢复的审计，才是真正可用于治理的审计。