把大模型从演示变成能值班的系统时，Agent 审计日志与归因几乎总会先露出工程缺口。下面按可执行的顺序来拆：先讲它解决什么、卡在哪，再讲选型时看哪些数字，最后落到智能体和网关该怎么接。本文面向要上线的工程师，不写空泛趋势。
一、最小审计字段集
合规与事故调查问： 哪个用户、通过哪个 Agent、在什么策略版本下、调用了什么 tool、访问了哪条记录 ？OAuth sub alone 不够——必须含 act （Agent）与策略决策。本文定义 最小日志集 ，给出 OpenTelemetry 建模建议，并标 PII 清洗点——联动 PAM/IGA 审计 与 零信任可观测性 。
flowchart LR U["delegator_id<br/>用户"] –> A["agent_id<br/>Agent"] A –> T["tool_call"] T –> R["resource"] R –> D["decision + policy_version"] 调查查询示例（概念 SQL，非特定产品）：
二、归因链
SELECT timestamp , tool_name, resource , decision FROM agent_audit WHERE delegator_id = 'user-248289761001' AND agent_id = 'checkout-agent' AND timestamp BETWEEN '2026-06-01' AND '2026-06-02' ; 三、OpenTelemetry 建模 3.1 Span 层次 trace: agent.task.checkout ├── span: llm.completion (model=…) ├── span: agent.tool.run_sql │ ├── attribute: delegator_id │ ├── attribute: agent_id │ ├── attribute: tool.args_hash (非明文 args) │ └
MCP tools/call 应在 Host 创建 child span， server_id 作 attribute——多 Server 拓扑可过滤。
三、OpenTelemetry 建模
高合规场景：审计流 append-only（WORM / hash chain）；与 PAM 会话录像 不同——Agent 审计是 结构化事件 非 keystroke。
OPA decision log 已含 input / result ——Agent 平台应 归一化 到上述字段集，避免 OPA 与 Gateway 各记一套。
四、PII 清洗点
这一层常见的失败不是名词不会背，而是指标、资源和失效模式没有放在一张图里。先写出延迟预算、显存账和回滚条件，再决定要不要上新组件。
五、不可篡改与完整性
这一层常见的失败不是名词不会背，而是指标、资源和失效模式没有放在一张图里。先写出延迟预算、显存账和回滚条件，再决定要不要上新组件。
六、与 Policy Engine 联动
这一层常见的失败不是名词不会背，而是指标、资源和失效模式没有放在一张图里。先写出延迟预算、显存账和回滚条件，再决定要不要上新组件。
落地时建议先做的 5 件事
- 用自己的 20 条真实请求测 TTFT / TPOT / 失败原因，不要只看公开榜。
- 先写显存和 KV 缓存账，再决定卡数、量化和并发上限。
- 网关层把鉴权、配额、审计和模型路由收口，应用里不要各接各的 Key。
- 工具调用默认拒绝，按白名单放开，高风险动作必须人审。
- 模型升级准备回滚：旧权重、旧 Prompt、旧评测集要能一键切回。
和智能体产品怎么接
对龙虾PRO这类要把 OpenClaw 落到中国业务场景的平台来说，Agent 审计日志与归因决定的是延迟能不能进对话、成本能不能规模化、出了问题能不能追溯。技能市场、数字员工和网关都应该吃同一套观测与权限，而不是文章里的概念演示。
本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源
常见问题 FAQ
为什么说审计Agent行为时，光有用户的OAuth ID是不够的？
因为一个用户可以授权多个不同的Agent去执行任务。审计时不仅要知道“谁”操作，更要知道是“哪个代理”在操作。所以最小审计集必须同时包含用户ID（delegator_id）和代理ID（agent_id），并且要关联当时的策略版本和具体的工具调用，这样才能完整还原事件。
当发生安全事件时，如何根据日志追溯是哪个用户通过哪个Agent调用了敏感工具？
你可以按照文章中的归因链思路来查询。在审计日志中，通过delegator_id筛选用户，通过agent_id锁定特定代理，再结合tool_name和resource字段定位具体操作。比如用SQL概念查询，就能清晰看到是用户248289761001通过checkout-agent在特定时间段内访问了哪个资源。使用OpenTelemetry可以更结构化地实现这一点。
用OpenTelemetry为Agent建立审计日志，具体怎么设计Span的层级和属性？
你可以将一次完整的Agent任务作为一个顶层的Trace。例如，一次结账任务下，LLM生成回复、工具执行、API调用都可以作为独立的Span。关键属性如delegator_id和agent_id需要附加在相关的Span上。对于MCP协议的工具调用，应该在Host侧创建子Span，并记录server_id，这样便于分析多服务拓扑下的行为链路。
在记录Agent审计日志时，处理PII（个人身份信息）最容易在哪里出错？
常见的失败点是，系统虽然记录了结构化事件，但没有在正确的环节进行PII清洗。例如，工具调用的原始参数（args）可能包含敏感信息，但日志中记录的是参数的哈希值（args_hash），这就对了。如果直接记录明文参数，或者清洗点位置不对，就会导致合规风险。必须把PII清洗作为日志写入流程的一个标准步骤。
如何确保Agent审计日志的不可篡改性，让它成为可靠的调查依据？
对于高合规场景，审计日志流本身应该设计成只增不改（append-only）。你可以采用类似WORM（一次写入多次读取）的存储机制，或者使用哈希链（hash chain）技术，让每条日志都包含前一条的哈希值。这样，任何篡改都会被轻易发现，确保了日志在事故调查时的完整性和可信度。
我的系统已有OPA作为策略引擎，该如何整合新的Agent审计日志？
关键是要将Agent平台的日志字段“归一化”到本文建议的最小审计集上。虽然OPA自身的决策日志记录了输入和结果，但Agent审计需要更全局的视图。你应该让Agent网关或平台将delegator_id、agent_id、tool、resource、decision和policy_version等核心字段统一输出，避免与OPA日志各记一套、难以关联分析。龙虾PRO这类平台在接入时也需要遵循这个原则。