10.4 日志审计

概念

审计是「过程层」的地基。企业管理后台提供操作日志审计，让企业内的每一次配置变更、能力调用都可回溯——这是「同一批成员、同一套权限、同一份积分度量、同一条审计链」里的关键一环（第 5 章）。

出事之后能不能还原链路，全靠日志。一个好的 Agent 日志，标准是能还原一次完整请求的因果链。用户问了什么 → Agent 思考了什么 → 调了什么工具 → 工具返回什么 → 最终回答了什么。

FDE 交付时要确认的三条审计能力：

• 配置可追溯 ：谁在什么时候改了哪个 Skill / 专家 / 策略。

• 调用可追溯 ：连接器调用了哪个外部系统、返回了什么（接口实证要能复查调用记录，第 8 章三态溯源）。

• 决策可追溯 ：涉及人工终审的动作，留下「谁在什么时候确认了什么」。

用法

日志设计的关键在「三段式」——把一次请求切成三段，每段单独记录：

必须给每条日志打上同一个 request_id，让一次请求的所有事件可以串起来。这是事后排查的命脉。

示例

一次请求的日志链路（简化示意）：

// 日志条目 1：用户输入

{

  "request_id": "req-abc123",

  "stage": "prompt",

  "user_input": "帮我查一下 A 公司的合同金额",

  "user_id": "u-zhang",

  "timestamp": "2025-01-15T10:23:01Z"

}

// 日志条目 2：工具调用

{

  "request_id": "req-abc123",

  "stage": "tool_call",

  "tool_name": "query_contract",

  "tool_input": {"company": "A 公司"},

  "tool_output": {"amount": "120000", "currency": "CNY"},

  "duration_ms": 230

}

// 日志条目 3：最终输出

{

  "request_id": "req-abc123",

  "stage": "response",

  "response": "A 公司合同金额为 12 万元人民币。",

  "prompt_tokens": 420,

  "completion_tokens": 28,

  "model": "<model_name>"

}

• 上述日志字段为示意结构，实际字段名需参考所使用平台的官方文档确认。

通过 request_id 串联，可以完整还原这一次请求的全部动作——这是合规审计的最低要求。

注意事项

• 日志本身也可能泄露敏感数据 。如果 tool_output 里含手机号，日志里也存了一份明文——合规审计反而成了泄露源头。必须对日志里的敏感字段做脱敏（mask），或单独存到加密的「敏感日志库」，跟普通日志隔离。

提示

护栏动作：上线前做一次「审计演练」——假设三个月后出了一起争议（一笔错误结算、一份对外发错的文件），你能不能从日志里还原出完整链路？答不上来，审计就是缺的。