AI Agent 需要可观测性：为什么下一代安全日志要记录“意图到动作”

现在很多团队在接 AI Agent 时，第一反应是加权限、加审批、加 sandbox。

这些都对，但还少了一层：可观测性。

传统系统的安全日志通常回答三个问题：

谁调用了接口？
什么时候调用的？
成功还是失败？

但 Agent 不一样。它不是简单点按钮，也不是固定执行一条 API。它会理解目标、拆计划、读上下文、选择工具、生成参数、等待确认，再执行动作。

所以下一代安全日志不能只记录“做了什么”，还要记录：它为什么认为自己应该这么做。

一句话定位

Agent 安全日志的核心，不是多打一行 log，而是把“用户意图 → Agent 计划 → 工具调用 → 权限判断 → 实际动作 → 执行结果”串成一条可追溯链路。

如果只看到最后一条：

DELETE /api/users/123 200 OK

你并不知道这是：

用户明确要求删除；
Agent 误解了“停用账号”；
页面里的恶意文本诱导它执行；
某个自动化流程越权调用；
还是审批逻辑本来就放行了错误动作。

这些场景在传统日志里可能长得一模一样。

传统日志为什么不够

传统应用里，用户点按钮，后端执行接口。安全日志记录接口、身份、IP、状态码，基本能还原责任链。

Agent 加入之后，中间多了几层：

  flowchart LR
    A[用户目标] --> B[Agent 理解]
    B --> C[任务计划]
    C --> D[工具选择]
    D --> E[参数生成]
    E --> F[权限 / 策略判断]
    F --> G[人工确认]
    G --> H[实际执行]
    H --> I[结果反馈]

真正危险的地方，往往不在最后一步。

比如 Agent 最终确实调用了一个合法 API，凭据也有效，权限也没过期。但问题可能是：

用户本意是“归档”，Agent 理解成“删除”；
检索到的网页内容里藏了诱导指令；
Agent 选择了错误工具；
工具参数来自不可信上下文；
策略引擎只看了权限，没有看任务意图；
人工确认界面只展示了动作，没有展示原因。

这时只看 API audit log，会得到一个很尴尬的结论：一切看起来都正常。

Agent 日志应该记录什么

我会把 Agent 安全日志分成六层。

层级	要记录什么	为什么
目标层	用户原始目标、压缩后的任务意图、任务来源	判断动作是否偏离用户本意
推理层	Agent 计划、关键决策点、选择某个工具的理由	还原“为什么走到这一步”
上下文层	参与决策的文件、网页、检索片段、memory 来源	判断是否被不可信上下文影响
工具层	工具名、动作类型、参数摘要、资源范围	知道 Agent 准备做什么
控制层	策略判断、权限结果、人工确认、阻断原因	证明安全控制是否生效
结果层	实际执行结果、外部系统返回、回滚信息	形成完整审计闭环

注意，这里不是让你把所有 prompt、网页、参数原文都存下来。

安全日志应该记录的是可审计证据，不是把敏感上下文复制一份。

一个更实用的日志结构

如果我要给 Agent 设计第一版日志事件，我会从这些字段开始：

{
  "event.name": "agent.tool.execution",
  "trace_id": "01HT...",
  "agent.session_id": "sess_123",
  "agent.intent_id": "intent_456",
  "agent.task_id": "task_789",
  "user.id": "u_001",
  "user.goal_summary": "停用某个测试账号，而不是删除账号数据",
  "agent.plan_step": "调用账号状态更新工具",
  "agent.decision": "选择 update_user_status，因为目标是停用账号",
  "tool.name": "user_admin",
  "tool.action": "update_status",
  "tool.args_hash": "sha256:...",
  "target.resource": "user:123",
  "risk.level": "medium",
  "policy.decision": "allow",
  "approval.required": true,
  "approval.actor": "human",
  "context.refs": [
    "issue:28",
    "file:docs/account-lifecycle.md"
  ],
  "result.status": "success"
}

这份日志有几个关键点：

trace_id 把一次 Agent 任务里的多条事件串起来；
intent_id 记录用户目标，不和单次工具调用混在一起；
tool.args_hash 避免直接存敏感参数原文；
policy.decision 说明策略层有没有介入；
approval.* 说明关键动作是否有人确认；
context.refs 只记录来源引用，不把全文塞进日志。

这样出问题时，你不是只查“谁调用了接口”，而是能问：

这个动作对应的原始意图是什么？
Agent 是在哪一步选择了这个工具？
参数来自哪里？
策略为什么放行？
有没有人工确认？
执行结果是否和计划一致？

最关键的是“动作前日志”

很多系统只在动作完成后记日志。

对 Agent 来说，这不够。

Agent 至少需要两类事件：

1. 动作前事件

记录 Agent 准备做什么：

当前意图；
计划步骤；
工具选择理由；
参数摘要；
风险等级；
权限判断；
是否需要人工确认。

如果这里就发现风险，可以在执行前阻断。

2. 动作后事件

记录实际发生了什么：

调用了哪个外部系统；
返回结果是什么；
是否失败或重试；
是否触发补偿动作；
是否改变了数据状态。

动作前日志解决“为什么要做”，动作后日志解决“最后做了什么”。

缺少前者，很多 Agent 事故只能看到结果，无法还原意图偏移。

不要把日志变成新的泄漏面

Agent 日志越细，越容易踩到另一个坑：把敏感信息全存进日志。

我会明确禁止记录这些内容：

API key、token、cookie、SSH 私钥；
完整 prompt 和完整工具参数；
用户输入里的隐私字段；
网页正文里的敏感业务数据；
未脱敏的订单、账号、学生、客户信息；
大段 memory 原文。

更合适的方式是：

原文只在短期安全存储里保留，设置过期时间；
长期日志只存摘要、hash、资源 ID、来源引用；
高风险字段单独打标签，查询也需要权限；
日志系统本身也要有审计记录；
训练、分析、报表默认不使用原始敏感日志。

可观测性不是“什么都保存”，而是“关键证据能被安全地还原”。

从工程上怎么落地

第一版不用做得很复杂。我会按这个顺序做：

1. 先打通 trace

一次用户请求、一次 Agent run、一次工具调用，都要能串起来。

至少需要：

trace_id
agent.session_id
agent.intent_id
tool.call_id

OpenTelemetry 的日志模型里已经有 TraceId、SpanId、Attributes、EventName 这类字段，适合承载这种结构化事件。不要把 Agent 行为只写成一段不可解析的字符串。

2. 在工具网关统一打点

不要让每个工具自己随便写日志。

更稳的做法是让所有工具调用都经过一个 tool gateway：

Agent → Tool Gateway → Policy Check → Human Approval → Tool Execution

这样你可以在同一个地方记录：

工具调用前的 intent / plan / args；
策略判断；
审批状态；
执行结果；
失败和重试。

安全控制和日志打点在同一个边界上，排障会简单很多。

3. 给高风险动作做单独事件

不是所有动作都需要同样粒度。

这些动作应该单独提升日志等级：

删除数据；
导出大量数据；
修改权限；
修改账单或支付；
调用生产环境；
访问敏感系统；
自动提交代码或发布。

高风险动作至少要记录：意图、策略、确认人、执行前参数摘要、执行后结果。

4. 做几个真正有用的告警

不要一开始就做一堆 dashboard。

先做这些告警更实用：

高风险工具调用没有人工确认；
Agent 计划是只读任务，但实际发生写操作；
同一个 intent 下出现异常多的工具重试；
工具参数来自不可信上下文；
策略引擎不可用时仍然放行动作；
单个 Agent 在短时间内访问大量资源；
动作结果和计划步骤不一致。

这些告警都不是传统 API 日志能轻易发现的。

一个判断标准

设计 Agent 安全日志时，可以用这个问题检查：

如果明天有一个 Agent 误删数据，我能不能在 30 分钟内回答：用户原本想做什么、Agent 怎么理解、为什么选择这个工具、谁批准、实际影响是什么？

如果不能，说明现在的日志还不够。

结论

Agent 的风险不只来自“有没有权限”，还来自“拿着合法权限做了错误的事”。

所以安全日志也要升级。

下一代 Agent 安全日志应该记录：

用户意图；
Agent 计划；
上下文来源；
工具选择；
策略判断；
人工确认；
实际动作；
执行结果。

这不是为了事后甩锅，而是为了让 Agent 系统变得可解释、可审计、可阻断、可恢复。

真正可用的 AI Agent，不只是能完成任务，也应该能说明自己为什么这么做，以及每一步留下足够清楚的证据。

参考

OWASP：https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
OpenTelemetry Events：https://opentelemetry.io/docs/specs/semconv/general/events/
OpenTelemetry Logs Data Model：https://opentelemetry.io/docs/specs/otel/logs/data-model/
NIST AI RMF：https://www.nist.gov/itl/ai-risk-management-framework