你的智能体审计日志记录了一切，唯独没有记录原因

合规部门给你转发了一张工单。三周前，一名客户的退款请求被你的支持代理拒绝了，他们发起了申诉，现在需要有人解释这一决定。你对此感到很淡定，因为你记录了一切。每一次提示词、每一次工具调用、每一段检索到的内容、每一个 Token 计数、每一项延迟数据——所有这些都在追踪记录（trace）中，你可以在几秒钟内调出它们。

你调出了记录。你可以看到代理收到了退款请求。你可以看到它调用了 get_order_history，接着是 check_return_window，然后是 lookup_policy。你可以看到它检索到的确切政策文本。你可以看到它发送的最后一条消息：拒绝退款。追踪记录是完整的。每一个 span 都是绿色的。但你仍然无法回答那个问题，因为追踪记录显示代理拒绝了退款，并向你展示了它查看过的所有内容，但它没有向你展示为什么这些输入叠加在一起的结果是“不”。原因存在于模型如何权衡上下文，而这种权衡从未成为一种产物（artifact）。它从未在任何地方被记录下来。

这就是追踪记录与解释（explanation）之间的差距，几乎所有声称“我们拥有完全可观测性”的团队都还没有意识到，他们只构建了前半部分。

完整的追踪记录并不等同于完整的答案

这种困惑是可以理解的，因为对于传统软件来说，追踪记录确实就是解释。如果一个确定性函数返回了错误的值，堆栈追踪加上输入就是原因——你可以阅读分支，跟随条件语句，产生输出的逻辑就写在代码里。执行路径和理由是同一个对象。

代理（Agent）悄悄地打破了这种等价关系。现在，一个代理动作涉及多次模型调用、多次工具调用、一两个检索步骤，甚至可能移交给子代理——而决定性的一步并不是其中的任何一个。它是模型接收一堆上下文并将其塌缩（collapses）为一个选择的那一刻。这种塌缩发生在一次前向传播（forward pass）中。它不会产生 span。它不会写入一行记录。你的日志捕获了决策周围的一切，却唯独没有捕获决策本身。

因此，你最终得到了一份关于错误层级的完美记录。你记录了输入和输出，因为这些东西很容易序列化。推理（Reasoning）不是你的框架递给你的一串字符串；它是权重对提示词做出反应的一种属性，除非你明确要求模型将其外显化，否则在响应流结束的那一刻，它就消失了。“我们可以看到发生了什么”是真的。“我们可以看到为什么”从未在考量范围内，而且没有人公开说明这一点。

实际的测试很简单。调出你的代理过去做出的任何决定，然后问：我能否仅凭我存储的内容，向对此不满的人辩护这个具体结果？不是“我能否看到这些步骤”——而是“我能否陈述原因”。对于大多数团队来说，诚实的答案是否定的，而他们第一次发现这一点时，往往是在监管机构、律师或愤怒的客户已经在电话那头等着的时候。

“完全可观测性”的含金量比听起来要低

可观测性（Observability）和可解释性（Explainability）常被当作同义词使用，但它们差得远呢。可观测性回答的是系统做了什么：触发了哪些工具、参数是什么、用了多少 Token、每一步花了多长时间。这是运维视角，而且确实很有价值——用于延迟回归、成本控制、捕获报错的工具。可解释性回答的是系统为什么这么做：为什么调用这个工具而不是那个、为什么在这些输入下给出这个输出、逻辑是否真的成立。

你可以同时拥有完美的可观测性和零可解释性。事实上，这正是一个通过良好插桩（instrumented）的代理的默认状态。仪表盘是满的，追踪记录是干净的，p99 数据看起来很棒，但其中没有一个字节能告诉你为什么退款被拒绝。

这个差距之所以能长期不被察觉，是因为可观测性工具被当作完整答案来推销，而对于调试来说，它也确实接近完整。当工程师调试一个表现不佳的代理运行实例时，他们在自己的脑海中重构了“为什么”——他们阅读检索到的政策，查看提示词，并推断推理过程。这之所以奏效，是因为工程师正在利用自己的判断实时提供缺失的层级。这种方式无法扩展，不可持久，也不是你能在六个月后交给非工程师的东西。“为什么”从未出现在日志中；它一直存在于调试者的脑海里。审计是这种安排分崩离析的时刻，因为审计需要原因是成为一种产物，它是可追溯且固化的，而不是由恰好在查看它的任何人进行的临时推断。

日志中的原因可能是虚构的

显而易见的修复方法是让模型展示其思考过程——记录思维链（chain-of-thought）并将其称之为解释。这比什么都没有要好，但如果你将这种追踪记录视为事实真相，那也是一个陷阱。

可解释性研究中一个令人不安的发现是，模型陈述的推理过程并不是产生答案的计算过程的可靠读取。2025 年一项关于“在野”思维链推理的研究记录了隐性事后合理化（implicit post-hoc rationalization）：分别问模型“X 是否大于 Y？”和“Y 是否大于 X？”，它有时会对两个问题都回答“是”，然后为每个矛盾的答案生成一段流畅、自信的辩解。推理并不是答案的原因。答案先出现，推理是事后拼凑以适应答案的。

同一项工作还记录了恢复错误（restoration errors）——模型犯了错，悄悄纠正了它，却从未提及纠正过程——以及不忠实的捷径（unfaithful shortcuts），即可见的逻辑显然是无效的，但无论如何还是得出了正确的答案。出错率因模型而异：在某些测试中，轻量级模型进行合理化解释的比例达到了两位数，前沿模型要少得多，但没有一个是完美的。重点并不是思维链毫无价值，而是一个未经证实的推理追踪记录只是一个看似合理的故事（plausible story），而一个看似合理的故事正是你最不希望作为事实呈交给监管机构的东西。

这一点很重要，因为失效模式是隐蔽且不对称的。虚构的理由看起来并不像虚构的。它看起来像一个清晰、结构良好的解释——通常比真实的解释写得还要好。如果你的审计流程是“检索记录的推理并大声朗读出来”，那么你构建的就是一个能对“为什么”产生自信回答的系统，却无法保证答案是真实的。而在法律诉讼中，一个错误但流畅的原因比没有原因更糟糕。

在决策时捕捉理由，而非事后重构

如果理由不在追踪记录（Trace）中，且模型的事后叙述并不可信，那么关键在于将理由捕获作为决策时刻的一个刻意、结构化的步骤——而不是事后去补救。

以下是三种模式，强度依次递增：

• 让模型在执行行动前先承诺一个理由。 强制要求结构化输出，让智能体陈述决策内容、背后的主要因素以及所应用的策略或规则——并要求在行动执行之前完成，而不是事后。行动前生成的理由至少在因果关系上是有据可依的；而行动后生成的理由则很容易演变为一种“事后合理化”。这并不能保证理由完全忠实于原始逻辑，但它将理由的地位从“叙事”转变为“承诺”。
• 将决策时的输入快照作为一等记录。 决策记录并非原始追踪。它是一个小型的、结构化的产物：当时生效的是哪个策略版本、检索到了哪些事实、智能体报告的置信度是多少、衡量了哪些因素及其权重、考虑并拒绝了哪些替代方案。追踪记录会显示智能体调用了 lookup_policy；而决策记录则会说明：这一条款、这一版本，以这种方式应用，并排除了这些可能性。 当下个季度策略变更时，该记录仍能展示决策当天的真实情况。
• 将理由视为数据，而非散文。 将理由存储为结构化字段——因素、权重、策略 ID、置信度、结果——使其可被查询。这样你就可以跨决策进行提问：有多少次拒绝是由“账户历史不足”导致的？在提示词更改后，该比例是否大幅上升？理由的聚类是否表现出某种偏见？大规模场景下，纯文本推理是无法审计的；结构化理由则是调试工具与治理工具之间的本质区别。

成本是现实存在的：额外的推理步骤带来的延迟、Token 消耗、模式（Schema）设计以及存储。但请注意另一种成本。事后重构理由意味着工程师要在数月后，在压力之下，从可能已不再反映决策当时系统状态的输入中重新推导——提示词更新了、策略变动了、模型版本迭代了。这种重构本身就是一次新的推理，而新的推理并不是审计轨迹。它只是一个带有时间戳的猜测。

为监管者设计，而非为调试者设计

最深刻的错误是为错误的读者设计审计轨迹。为工程师构建的日志优化的是“我能找到 Bug”。为问责制构建的日志必须优化为“能说服心存疑虑的外部方，证明决策是合法的”——这是两种完全不同的规格。

外部压力已不再是假设。欧盟《人工智能法案》（EU AI Act）第 12 条规定，高风险系统必须具备自动事件日志记录功能，附件 III 规定的义务将于 2026 年 8 月起强制执行，最低日志保存期限以月计，罚金高达数千万欧元。在美国消费信贷领域，CFPB（消费者金融保护局）已经明确表态：债权人不能以模型过于复杂无法解释为由，为模糊的拒绝理由开脱。如果模型无法给出具体、准确的理由，那么该模型就不能用于该项决策。“它是一个黑盒”不是法律辩护，而是一种认罪。

因此，应从审计需求出发进行逆向设计，而不是顺着框架的默认设置。以下是区分“可辩护轨迹”与“调试便利工具”的几个特性：

• 归属 (Attribution)。 每条决策记录都关联到特定的主体、模型版本、提示词版本和策略版本。“智能体做出了决定”是不可追溯的；“该配置在这一天做出了决定”才是可追溯的。
• 不可篡改性 (Immutability)。 记录在决策时刻被冻结，并具有防篡改特征。一个你以后可以悄悄修改的理由称不上证据。
• 无需运行系统即可重构 (Reconstruction without the live system)。 你应该能够仅凭存储的记录来回答“为什么”，而无需重新运行智能体——因为等到有人询问时，智能体可能已经迭代了三个版本，它现在的回答已不再是当时的回答。
• 忠实度警告 (Faithfulness caveats)。 如果理由是模型的自我报告，请将其标注出来。不要让事后合理化的说明被提升为“官方理由”，仅仅因为它恰好是日志中唯一的文本。

这些都不是什么玄奥的工程技术。这主要是一种决策：像对待“结果层”一样严肃地对待“原因层”，在 Token 和模式设计上投入精力——并且现在就做决定，趁现在的成本只是一个 Sprint 的开发量，而不是以后面临作证时的巨大代价。

在你需要答案之前要问的问题

去调取智能体上个月做出的一个真实决策——一次拒绝、一次升级、一次推辞，任何可能让利益相关者不悦的行为。尝试仅使用你存储的内容，写出一段监管机构能够接受的理由。如果你能做到，你的审计轨迹就是真实的。如果你发现自己不得不打开提示词并进行推论，那么你拥有的只是一个挂着“审计轨迹”名牌的可观测性系统。

解决方法并不是增加更多日志。你现在的日志记录几乎肯定已经过多了。解决方法是意识到“为什么”是与“做什么”不同的独立产物，必须在决策时刻有意识地捕获；意识到模型对自己推理过程的叙述只是草案而非定论；并且意识到你所服务的读者不是带着调试器的友好工程师，而是数月后不在现场的怀疑论外部人士。构建一个能在这场对话中幸存下来的轨迹，调试用例自然会随之解决。如果只构建调试用例，你会在最糟糕的时刻发现差距：问题已经抛出，而理由早已消散。