轨迹。
智能体真正的产出不是它交回来的那个答案——而是它走到那里的整条路；而那条路是唯一一处能让「答对了」和「蒙对了」看上去不一样的地方。多数团队从没见过它，因为他们的工具记录的是模型调用而不是运行，而一次运行根本没有属于自己的那一行。把单位修对，你在评测、调试与成本上的一半麻烦，就会显出它们本来是同一个麻烦。
轨迹就是那次运行，按序排好——而那次运行才是你交付出去的东西。
在一个聊天系统里，工作的单位是一对：提示词进去，补全出来，而你可以单独评判这一对。在智能体循环里，这一对只是四十步中的一步，评判它几乎什么都告诉不了你。与「智能体做了那件事」相对应的单位是轨迹：从接到目标到终止之间一切的有序序列。
具体说，一条轨迹装着：
- 它出发时的目标——任务字符串、系统提示词、被交到手上的工具集、被交到手上的各项预算。
- 每一个动作与观察，按顺序——每次工具调用及其实参、每条结果、每个错误、每次重试。
- 模型自己的中间产出——在厂商会返回的情况下，那些步骤之间的推理；以及它一路上对用户说过的话。
- 终止状态——不只是最后那条消息，还有它为什么停：目标达成、预算耗尽、出错、被人打断。这是四种不同的结局，而散文会把它们揉成一种。
最后那条消息，是由你正要评判其工作的那同一个系统，为这条轨迹写的一份摘要。那是个找证据的坏地方，而几乎所有人都先往那儿看。
有两个近邻词不是同义词。trace（追踪）是执行的遥测记录——span、时序、父子链接——而它通常是你存放轨迹的方式。轨迹则是那个语义对象：目标、动作、观察、结局。你可以有一流的 trace，却依然答不上「第 4471 次运行到底做了什么」——而那个症状说明，这套 trace 是为基础设施设计的，不是为智能体设计的。
轨迹是「对」与「对得有道理」分开的地方。
两个智能体对同一个问题给出了一模一样的答案。一个检索了当前的政策文件、引用了相关条款、核对了生效日期。另一个从训练里想起某件听着像那么回事的东西，一次工具都没调，碰巧是对的。只给输出打分，这是同一次运行。它们不是同一个系统，而差别会在下周政策变更时冒出来。
这就是轨迹评测存在的实际理由，而它两个方向都切得动：
- 输出对，过程坏。上面那次蒙对。还有：从一条错误消息里拿到答案的智能体；因为一次重试掩盖了 bug 而成功的智能体；以及子智能体在搜索工具正在失败时报回「什么都没找到」的那个。这些全都能通过输出检查，而且全都不可复现。
- 输出错，过程稳。每一步都是对的一步，而第三个工具返回了陈旧数据。按输出去判，这看着像模型失灵，于是会有人跑去改提示词。轨迹说这是一个数据新鲜度的 bug，而该修的地方在完全另一处。
- 两样都不占，还很贵。智能体在第九步就拿到了正确答案，然后又走了三十步，因为没有任何东西叫它停下——这是终止问题：在输出里看不见，在路径上一目了然。
要注意它不意味着什么。拿一条理想路径去给每一步打分，通常是个错误：智能体确实会经由人类不会挑的路线抵达好结果，而一份惩罚这种做法的评分表，量的是顺从度。关于一条轨迹，有用的问题要窄得多——它有没有为自己提出的说法找到依据，有没有待在预算之内，有没有因为对的理由而停下，有没有做了一个它本不需要做的不可逆动作。
如果你的技术栈里没有任何东西带着一个 run ID，你就没有轨迹。
这一节枯燥，却决定一切。多数可观测性是从 LLM API 时代来的，那里天然的一行就是一次模型调用，而大量智能体工具继承了那个形状。结果是一个装满「步」的存储，却没有一个靠得住的概念说明它们属于哪一次运行——而一条你重建不出来的轨迹，就是一条你没有的轨迹。
线头断掉的那几处很具体，而且全都常见：
- 重试与续跑。一次在第十二步崩掉、随后续跑的运行，会落成两条记录。除非那个 ID 挺过了重启，否则你的延迟分布里如今有两次短运行，而本来只有一次长运行——并且看起来没问题的那些，正是失败的那些。
- 委派。子智能体是一段独立的模型对话，默认就会是一条独立的 trace。没有显式的父链接，孩子内部的一次失败就是一次不相干的运行，而你手上不是一份可读的记录，是一个功劳分配问题。
- 换模型与降级。飞行途中切到第二家厂商的那次运行是一条轨迹，而多数技术栈会把它记成两条。
- 一切不是模型调用的东西。缓存命中、护栏拒绝、策略校验、卡在人工那里的审批。这些是轨迹里的事件，而且恰恰是你的事故复盘最想要的那些——正因为没有任何一次模型调用与它们对应。
解法是一个早早做出的决定：目标到达时铸一个 run ID，把它挂到每一个 span、每一次工具调用、每一行日志、每一条花费记录和每一个子运行上，并让它成为你智能体数据的主键。于是每任务成本、完成耗时、失败分类学与「给我看看发生了什么」，就全都变成对同一个对象的查询，而不是四次重建。这正是智能体可观测性区别于服务可观测性的那部分含义。
轨迹既是资产也是负债，而两边都比你以为的大。
既然决定留下它们，就看清你如今握着什么。
它们是让其余一切成为可能的那项资产。存下来的轨迹可以重放：你可以拿一段新提示词，对着同一批录下来的观察去跑，把路径做差分，看清变了什么，而不必再为那个环境付一次钱。它也是原料——用于一份从生产而不是从想象里搭出来的评测集，用于一套反映真实用户行为的回归套件，以及那份告诉你四个问题里哪个才真正昂贵的失败分类学。答得上「这件事多久出一次错、以什么方式出错」的团队，手里有轨迹数据；答不上的，没有。
它们同时也是你的系统产出的、最大且最敏感的那个对象。一条轨迹装着智能体见过的一切，而按构造那就是它被允许见到的一切：它读过的客户记录、工具响应里的那份凭据、它检索到的那份文档。它比聊天日志大上几个数量级，它在诉讼中可被调取，而且它一条现有的留存规则都继承不到——因为没人为它写过。成本也是真的：把每次运行都全保真地 trace 下来，是一张在价值到来之前就先到的账单。
- 在写入时脱敏，且只在一个地方做。轨迹存储是你的数据在世上最集中的那份副本；见智能体追踪中的 PII 脱敏。
- 成功的采样，失败的全留。对出错、上报或做过不可逆动作的运行全量留存；其余采样。没有人会去重读一次成功的运行。
- 留存规则要刻意定，而不是默认成什么样。长到够你复盘一次事故、搭出一份评测集；短到你不必守着一年份自己说不清理由的客户数据。
这周就做一件事：挑一次在生产里出了问题的运行，试着只用你目前存下来的东西把它从头到尾重建出来——目标、每一次工具调用与结果、它为什么停。给自己计时。如果超过几分钟，或者你发现自己在靠时间戳拼三个系统，那缺的那块就是一个 run ID；而补上它，比你原本在考虑的任何一项修法都要小。
相关：结果评测 vs 轨迹评测讲如何在不惩罚创造性的前提下给它打分，轨迹与过程评测讲具体方法，以及追踪采样与留存讲留着它们要花多少钱。