你的调用链路会记录每一个 token。它记录每一次工具调用、每一次重试、每一次检索延迟、每一个模型 id。看起来无所不包。然后,某个监管机构、某个客户、或者你自己内部的 incident 频道,抛出一个本该轻松回答的问题:模型在决策那一刻究竟看到了什么? 你这才发现,调用链路记下了"问题",却没记下模型当时正在看着回答的"答案"。
那次检索命中的 chunks 早就因为上周二的重建索引轮换出了向量存储。那次工具响应是一段流式 payload,你只保留了最终态摘要,因为完整流会让账单翻三倍。那段 system prompt 是运行时按一个 feature flag 拼装出来的,而那个 flag 此后又翻转了两次,你的 flag 服务并不按时间戳保留历史值。你对发生了什么有完整的可观测性——调用图、token 数、延迟。但你对模型当时在针对什么作答,一无所知。这道缺口,就是调用链路与决策记录之间的差别。大多数团队没意识到自己只造了两者中的一个。
周二，客户给支持团队发了一张截图。他们的账户显示六天前有一笔他们从未要求的退款。你的 CRO 转发了这张截图，并问了一个问题：“这是怎么产生的？”你知道是智能体（agent）干的——审计日志显示 actor: refund-agent-v3。但自那以后，提示词（prompt）已经修改了四次。由于财务部门为了追求 12% 的成本削减而更换了供应商，模型 ID 在上周四进行了轮换。系统提示词是根据三个检索到的文档生成的模板，而检索索引在周一重新进行了索引。对话历史被运行时（runtime）裁剪，以适应更小的上下文窗口。
你可以告诉 CRO 是智能体做的。你无法告诉他们为什么。这种差距——即知道发生了某个操作与能够重建导致该操作的输入之间的差距——是大多数智能体团队在工程团队之外的人提出真正的取证问题时发现的。
当 agent 在生产环境中第一次失控时——它删错了行，给错误的客户发了邮件，在单个任务上烧掉了 400 美元的推理费用，或者对受监管的用户说了法律风险极高的话——团队打开日志，却发现他们实际上拥有的是：一串参数被截断的 CloudWatch 工具调用名，一个只捕获了最新一轮对话的“用户提示词”字段，而且没有记录实际运行的是哪个模型版本。供应商在两周前滚动更新了别名。系统提示词存在于一个没有快照的配置服务中。由于框架默认值是 0.7 且“人尽皆知”，因此没有记录温度。触发错误操作的工具结果超过了日志行大小限制，并被截断为“...”。
你无法重现决策过程。你只能猜测。六个月后，你堆积了一堆无解的“它为什么这么做”的报告，团队开始像对待天气一样对待 agent——把它当作一种发生在你身上的事情，而不是你可以调试的东西。
飞行记录仪准则（Flight recorder discipline）是你为了防止这种情况所能交付的最廉价的东西，但如果你等到第一次事故发生才开始，它也将是你交付的最昂贵的东西。以下字段是最低要求，存储形式不容商量，采样和隐私边界必须同步设计，而不是事后修补。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
