你的 Agent 没有保管的证据柜

你的 trace 记录了每一个 token。它记录每一次工具调用、每一次重试、每一次检索延迟、每一个 model id。它看起来已经无所不包。然后一位监管者、一位客户,或你自己的事故频道,问出那个本该容易回答的问题:模型在做决策的那一刻,究竟看到了什么? 这时你才发现:你的 trace 记录的是问题,而不是模型作答时正在看的那些答案。

被检索到的 chunk 已经从向量库中轮换出去了,因为语料库在上周二被重新索引过。工具响应是一个流式 payload,你只保存了最终状态的摘要,因为完整保存流会让你的账单翻三倍。系统提示是在运行时根据一个 feature flag 拼装出来的,而那个 flag 此后又被翻转过两次,你的 flag 服务并不按时间戳保留历史值。你对 发生过什么 有完整的可观测性——调用图、token 计数、延迟。你对模型当时 拿什么作答 几乎一无所知。这个鸿沟就是 trace 和决策记录之间的差别,而大多数团队还没注意到自己只搭建了其中之一。

Trace 告诉你形状,决策记录告诉你实质

Trace 是面向运维的。它是为 SRE 的问题而设计的——请求去了哪里、花了多久、哪次调用失败了。它的 schema 也是为此优化的:span、parent id、duration、错误码,每个 span 上稀疏地挂几个属性。每一家现有的可观测性厂商都通过给这套 schema 加上 token 计数、model id 以及 prompt 和 completion 字符串,来扩展支持 LLM。这种扩展是必要的,但它和决策记录不是同一种工件。

决策记录是面向取证的。它是为另一种问题而构建的——这个 agent 在行动的那一刻,承认并依赖了哪个版本的世界状态。这个状态包括:被检索到的文档在被检索时的那个版本(而不是指向一个可变语料库的指针)、agent 收到时的工具输出(而不是日后重新拉取、可能已经改变的版本)、运行时拼装出来的系统提示(而不是模板加上一个 flag id)、模型版本(包括任何来自供应商一侧的静默升级),以及决定 agent 行为的每一个 guardrail 和 feature flag 的配置状态。Trace 告诉你这次运行的形状。决策记录告诉你 agent 当时要应对的实质。

这两种工件有重叠,这正是让这个缺口难以被发现的原因。你的 trace 里已经包含了 prompt 和 completion。它看起来就像决策记录。

它不是。trace 里的 prompt 是在 flag 翻转之后渲染出来并捕获的字符串。completion 是最终答案,trace 告诉你模型返回了这个 completion——但它没法告诉你:为那条 prompt 中的上下文块提供来源的那次检索,所依赖的 chunk 已经被重新嵌入,现在排到了第 7 名而不是第 1 名。trace 记录了表面,底下的实质已经移动过了。

你为了省钱丢弃的那个快照

每一个搭过非平凡 LLM 可观测性的团队都开过这样一场会议,以这句话收尾:我们不存完整的检索 payload,只存 chunk id 和分数。这个理由表面上很站得住——向量检索一次能返回几十 KB,一次 agent 循环可能发起几十次检索,一个每月处理百万级决策的系统面对的就是 TB 级别、长尾访问的证据。只存 chunk id,查询时再从向量库里反查内容,成本可以降到五十分之一。于是这就是被上线的方案。

那个为了省钱被丢弃的快照,恰恰是能让你重建 agent 行动时认知状态的那个快照。半年之后,向量库已经被重新索引了两次。trace 里的 chunk id 指向的是不再存在的内容——更糟的是,指向了仍然存在但已经被重新嵌入、重新切分,文本略有不同的内容。

你可以拿当前的向量库重跑一次检索,得到 一个 结果,但那个结果不是 agent 当时看到的。你已经失去了回答原始问题的能力——不是因为你缺乏可观测性,而是因为你的可观测性是一套指针系统,而它指向的东西移动了。

同样的模式在到处复现。把工具响应只存成最终状态摘要,会丢掉 agent 当时所反应的那些流式中间状态。用 id 引用 feature flag 而不是按值快照,等 flag 服务回收旧配置时就会丢掉历史状态。用 template id 加变量来引用系统提示,等模板被原地编辑、旧版本被覆盖时就会丢掉它原本的含义。每种情况下,团队都有一个站得住脚的成本理由。每种情况下,团队都在不太自觉的情况下,让决策变得不可复现。

缩小缺口的几种模式

补救的思路在概念上简单,在架构上烦人。原则是:决策记录必须自包含——可以脱离任何决策时存在的可变系统,独立恢复。能做到这一点的几种模式:

• 每次决策的不可变上下文 bundle。 对每一个值得保留的 agent 决策,写出一个 bundle,内含:拼装完成的完整系统提示、检索到的完整内容(不是指针)、agent 观察到的完整工具响应、包含供应商版本的 model id,以及 agent 读取过的每一个 flag 的配置快照。把 bundle 写进冷存储,按内容哈希寻址,然后从 trace 里引用它。trace 保持便宜,bundle 才是证据。
• 检索结果按内容哈希、内容寻址查找。 检索到一个 chunk 时,对 chunk 内容计算哈希并把哈希写进 trace,然后确保 chunk 被保存在以该哈希为 key 的内容寻址存储里。重新索引向量库不会让这个 chunk 失效——它只是为同一段内容生成一个新的向量,而旧内容依然可寻址。这就是 LLVM 的内容寻址存储所依赖的技巧,也是所有能挺过重构的构建缓存所依赖的技巧:按内容定义身份,而不是按位置。
• 快照而不是引用配置状态。 Feature flag、prompt 模板、模型版本、工具 schema,都应该在决策时以值的形式被写进 trace,而不是以 id 引用。"按时间 T 查 flag X" 的那种便利,恰恰是 flag 服务下线某个配置时会断掉的便利。把值内联保存只花一些字节;只保存引用,花掉的是回答关于过去问题的能力。
• 按证据等级分层保留,而不是按时间。 运维 trace 在三十天后可以便宜地丢弃,因为它回答的是 SRE 的问题,而 SRE 的问题半衰期就是三十天。决策记录在三十天后不能便宜地丢弃,因为审计员、监管者或原告律师上门的时间和你的保留策略毫无关系。正确的分区维度不是新旧,而是关键程度:常规决策可以过期,事故级决策无限期保留,而区分二者的策略要活在系统里,而不是在某个人的记忆里。

烦人的地方在于,这些都不是一行 config 就能搞定的事。每一家现有的可观测性厂商都是围绕 trace 模型构建 schema,而决策记录模型是一套不同的 schema,有不同的写入模式,有不同的保留成本结构。已经搭出这一层的团队都是自己搭的,通常是经历过一次事故、发现自己回答不了那个最关键的问题之后。

你和审计员的那场对话

让这件事从架构观点变成运营必需的场景,是某个团队外的人请你重建一个决策的时刻。可能是监管者,在 2026 年 8 月生效的欧盟 AI 法案中对高风险系统审计追溯条款的执行下——这些条款要求的是持续的、结构化的合规证据,而不是政策文档。可能是某个起诉方,声称你的 agent 拒绝了他的服务,或者批准了一笔欺诈交易。也可能是你自己的事故复盘,在追问 agent 为何在某个周二给某个用户发出了某个错误答案。

每种情况下,对话的形状是一样的。你被要求重建 agent 当时拿到的是什么。你打开你那个很出色的可观测性工具,信心十足地拿出 trace——span、模型调用、工具调用、延迟。

审计员看了一眼,接着问:agent 检索到了什么?检索到的内容是什么? 你指向 chunk id。审计员要看 chunk。你解释说向量库已经被重新索引过了。审计员在本子上写下了点什么。这场对话此刻已经揭示:你的系统在运维意义上是可观测的,在证据意义上是不可追责的,而这两种属性不是同一回事。

能体面挺过这场对话的团队,不是日志记得更激进的那些。是那些在这场对话发生之前就已经决定:决策记录是和 trace 不同的工件,并且搭建了能同时产出两者的基础设施的团队。挺得不体面的团队,会先满怀信心地把 trace 摆出来,然后实时看着审计员一点点向下调整对他们的评分。

必须存在的取证学科

更大的论点是:决策时的证据保全是一门学科,和运维日志是不同的学科,它需要有人配岗、有预算、有人主责。它不是你可观测性栈的一个特性——你的可观测性栈是为另一个问题搭的。它不是你数据仓库的一个特性——仓库存的是事实,不是这些事实所依据的那层底料。它也不是你 prompt 管理工具的一个特性——那个工具版本化了模板,但它没有快照运行时拼装的结果,而运行时拼装的结果才是模型真正看到的东西。

它自成一层,有自己的 schema、自己的保留策略、自己的成本模型、自己的 SLO。这层的 SLO 不是可用性,而是可重建性——给定一个 decision id 和一个关于 agent 在那一刻认知状态的问题,你能不能给出一个充分的答案?能给出答案的团队,可以用 2026 年的证据回答 2027 年的问题。不能给出答案的团队,会发现"我们有完整的可观测性"这句话是关于现在时的陈述,而他们被问的那个问题是过去时的,而过去时正是他们的架构没有保住的时态。