跳转到主要内容

Agent 的审计追踪是预写日志问题,而非仪表盘问题

只有当每一次工具调用、凭证使用和状态转换在执行之前就被追加记录,Agent 的可问责性才可被证明,这也使日志成为运行时依赖。

服务器机架的近景,显示堆叠的存储单元、指示灯和线缆,位于昏暗的数据中心通道中。

Agent 可观测性中的问责缺口

大多数 Agent 平台把审计当作下游事务处理。追踪数据在事后才被发出,送入时序存储,再渲染成仪表盘。这对性能监控足够,对问责毫无用处。仪表盘会采样、聚合和下采样。它能回答诸如这一小时有多少次工具调用失败之类的问题,却无法回答这起事故之前确切的决策有序序列是什么,每一项决策又由谁授权。

最近的两起事件说明了这种失效模式。澳大利亚 Medicare 事件以及据报道与 Gemini 相关的入侵事件,都是事后从零散的遥测数据中重建出来的——散落的应用日志、服务商侧记录和推理追踪,只能靠手工拼接。这两起事件中,系统本身都没有持有关于 Agent 意图及其被授权做什么的完整、有序、防篡改的记录。这种重建是取证考古,其结论的可靠性完全取决于它无法填补的那些空白。

更深层的问题是结构性的。一份能被它所描述的那个进程修改的审计记录,不是证据。如果 Agent 运行时持有自己日志的写句柄,那么该运行时的任何失陷——提示注入、依赖混淆、恶意工具——都能压制、重排或改写那些会定它罪的条目。从问责角度看,以这种方式构建的可观测性流水线属于自报数据。它们对调试有用,在争议中一文不值。

Agent 运行的预写语义

在存储引擎中,预写日志对这个问题有确定的答案:意图在效果被应用之前就被持久记录。同样的纪律适用于 Agent,它把日志从一种输出变成一种前置条件。

一次合规的 Agent 运行会在任何副作用触发之前,按顺序追加:

  1. 预期动作——工具名称、规范化后的参数、目标资源。
  2. 授权策略决策——匹配了哪条规则、哪个主体发起了这次运行、适用了哪些约束。
  3. 解析后的凭证——工具将以哪个身份行事,以及该身份的范围。

只有在追加被确认之后,工具调用才会执行。因此日志是一种运行时依赖:如果日志写入器不可用,动作就不会继续。这是诚实的权衡。采用预写审计的团队接受日志中断即能力中断。另一种选择——永不阻塞的尽力而为日志——恰恰是催生上述那些事后重建的体制。

Close-up of a modern building facade with red steel beams in geometric patterns against a blue sky

日志同时也成为恢复点。在崩溃、被杀或超时后,重放所记录的轨迹决定一个动作是被重试、回滚还是隔离。由于意图在执行前已被记录,恢复过程能够区分从未开始与已开始且结果未知,而这正是幂等性和补偿逻辑所关心的区别。没有它,重试会重复副作用,回滚则会漏掉它们。

最后,写入器必须与 Agent 进程分离。一种常见模式是日志服务以独立身份运行,通过经过认证的通道接受追加,并持有唯一的写凭证。Agent 进程持有一个仅追加的能力,作用域限定于它自己的运行标识符;它无法删除、修改或跨运行读取。失陷的 Agent 于是可以拒绝行动,但无法抹去它已经声明过的东西。

记录必须包含什么

单条追加条目的最小 schema:

{
  "seq": 41822,
  "run_id": "run_7f3a...",
  "parent_step": 41819,
  "ts_monotonic": 918273645,
  "kind": "tool.intent",
  "tool": "http.fetch",
  "args_hash": "sha256:9c1f...",
  "policy_rule": "net.egress.allowlist.v4",
  "credential": "svc-fetch-readonly@proj-9",
  "context_refs": ["doc_31a", "doc_88b"]
}

有几个字段承载着不成轻重的分量。

参数哈希,而非参数本身。 哈希让机密不进入日志,同时仍把条目绑定到确切的输入。当参数必须可恢复以用于重放时,将它们存到一个单独的加密存储中,以同一哈希为键,并配有自己的访问策略。

父步骤。 AgenClose-up of stacked rusty industrial pipes showing corrosion and texture成一条无差别的流。

Circuit board macro

检索上下文的来源。 每一个进入上下文窗口的文档、片段或工具结果,都应以标识符和内容哈希引用。这才能让一份被投毒的文档向前追溯到消费过它的每一次运行,向后追溯到放行它的摄取路径。没有来源的检索会把一起注入事件变成一场无边界调查。

确定性时钟与单调序列号。 每个 worker 的墙上时钟时间戳在分布式编排器之间不可排序;时钟偏移和并发 worker 会重排那些因果上本就有序的事件。由编排器分配单一单调序列,把墙上时钟时间作为供人阅读的次要字段,就能给出一个在重放中依然成立的全序。

运营后果

写放大与保留期成为预算项。 每一次工具调用现在至少花费一次持久追加,往往更多(意图、策略决策、凭证解析、结果)。在高频 Agent 上,这是存储和 I/O 预算中相当可观的一部分,而且它与推理成本并列,而不是落在可观测性额度之内。保留策略成为一项设计决策:完整轨迹保留多久、什么被归约为哈希、什么被导出到冷存储。归约绝不能破坏链条——哈希只有在原像能按一份使其保持可信的策略被取回时才有用。

从第一天起就做 schema 版本化。 事故复盘发生在代码变更数月之后。如果日志 schema 没有版本,调查所涉时期的条目可能无法被当前工具读取,调查就会卡在格式迁移上。显式地对条目 schema 做版本化,为曾经发出过的每个版本保留读取器,并把 schema 变更当作破坏性变更,以对待 API 的同等严谨对待它。

事件响应从考古转向重放。 当轨迹完整且有序时,发生了什么这个问题可以通过把所记录的运行对照所记录的决策进行重放来回答。有意思的工作转向策略为何允许它以及应当改变什么。这是真正的进步,同时也抬高了门槛:一个能精确重放其 Agent 的组织,再也不能把事故归咎于可见性不完整。

立场

Agent 的审计追踪是预写日志问题。日志必须在执行之前被追加,由一个 Agent 无法影响的进程写入,由编排器排序,并为尚不存在的读取器做版本化。仪表盘对运营仍然有用;它们不是证据。内化这一区别的团队将能够证明他们的 Agent 做了什么。没有内化的团队则将继续从任何幸存的遥测数据中重建它。

封面照片:panumas nikhomkhai / Pexels。

分享XLinkedIn永久链接5 分钟阅读

相关阅读

这能回答的问题

Why can't existing observability dashboards serve as an audit trail?

Dashboards sample, aggregate and downsample telemetry, so they cannot reconstruct the exact ordered sequence of decisions that preceded an incident. They are also typically written by the same process they describe, which means a compromised agent can suppress or rewrite its own entries. Audit requires an append-only record written before execution by a separate process.

What does write-ahead logging change about agent runtime behaviour?

The log becomes a runtime dependency. The intended action, the authorising policy decision and the resolved credential are appended durably before any side effect fires. If the log writer is unavailable, the action does not proceed. On crash or kill, replay of the recorded trajectory decides whether the action is retried, rolled back or quarantined.

What is the minimum content of an agent audit entry?

Tool name, argument hash, the policy rule that matched, the credential identity the tool will act as, and the parent step that requested the action. Retrieved context should be referenced by identifier and content hash so a poisoned document can be traced to every run that consumed it. Ordering should come from orchestrator-assigned monotonic sequence numbers rather than per-worker wall-clock timestamps.

What are the main costs of adopting write-ahead auditing for agents?

Write amplification and retention become first-class budget lines alongside inference, and a log outage becomes a capability outage because actions are blocked until the append is acknowledged. Log schemas also need explicit versioning from the start, since incident review often happens months after the code changed.