先记住这个答案
轨迹评估指对 Agent 在任务中产生的中间步骤序列进行系统化记录与质量分析，而非只看最终答案。标准轨迹应包含用户输入、每一步的模型输出（如文本、结构化对象，以及可选的显式推理步骤）、选择的工具及调用参数、工具返回结果、时间戳、资源消耗、异常标志和多轮状态快照。这些字段让开发者能复现执行过程、判断工具选择与参数是否正确、定位早期错误放大路径，并支持离线回归与在线监控。
- 轨迹评估关注中间步骤质量，而非只看结果。
- 原始输入、模型输出、工具调用和返回不可缺。
- 时间戳与状态快照支持复现和归因。
轨迹记录的核心字段与作用机制
最基本的字段是原始输入和最终输出，但真正支撑过程评估的是中间步骤。每个 Agent 循环（Loop）都应捕获：模型输入上下文（含提示词、截断策略）、生成的文本或结构化输出（如要求 JSON 时的原始内容）、工具调用的名称与参数（还原为字典形式）、工具返回的原文或结构化对象、HTTP 状态或自定义异常。缺少这些就无法回答“是哪一步造成了失败”。
时间戳和状态快照构成另一维度。时间戳包括每步开始/结束毫秒时间，用于计算工具时延和总耗时；状态快照保存当前对话历史、已收集的关键变量、重试次数，以及环境指纹（如版本号、随机种子）。它们让非确定性现象可被检查：同一输入不同轨迹时，能区分是模型采样抖动、工具响应波动还是环境差异。
电商客服 Agent 的轨迹排查实例
假设某电商客服 Agent 接到“退掉订单 12345 中的蓝色衬衫”请求。轨迹记录了用户输入、初始模型认为需要调用 get_order 和 list_items，随后调用 get_order 返回订单状态为“已发货”，list_items 返回商品颜色为“蓝”。模型又调用 request_refund 并传参 order_id=12345, item=衬衫, color=蓝，工具返回“该商品不可退款”。最终 Agent 回答“无法处理”。
评估者据此给每一步打分：工具选择正确、参数与返回一致，失败定位在工具业务规则而非模型推理。如果轨迹没存 request_refund 的返回原文，而只记录“调用成功”，则只能误判为模型没处理工具结果。这个例子说明，轨迹中应保留工具原始响应和错误码，否则归因会非常困难。
轨迹不完整与过度记录的双重边界
常见失效是省略工具返回正文，只记录“成功/失败”；当工具返回脏数据或格式异常时，模型被误导的环节就无法追溯。另一种失效是记录所有 token 级内容导致存储爆炸，却漏掉截断位置或上下文窗口溢出标志。若模型因长上下文丢失早期信息，而轨迹不记录 token 使用量，就很难解释为何行为漂移。
处理策略是分层保留：默认存储结构化字段和工具响应摘要，对完整原文按需采样或做哈希校验；同时记录每次请求的 token 计数与截断告警。这样既控制成本，又保住关键归因信息。评估时若发现轨迹缺失某类字段，则应即时标记数据质量缺陷，而非强行打分。
容易答错的地方
- 轨迹评估等同于记录工具调用日志
- 工具调用只是轨迹的一部分。若不同时记录模型决策前的完整上下文、输出文本和状态快照，就无法区分是工具返回错误还是模型误判，更无法定位推理链中的早期偏差。轨迹应是全量决策过程的时序图，而非工具账单。
- 只要最终答案正确轨迹就算合格
- 过程评估的意义在于发现隐藏风险：即使结果正确，工具参数可能含硬编码、冗余调用可能拖慢响应、多步后才纠正偏离会抬高成本。轨迹中缺少中间字段就无法捕获这些低效与脆弱点，也无法支持回归测试时的精细化归因。
面试官还会怎么问？
如何评判轨迹中某一步的合理性？
先校验工具选择与参数是否有必要、顺序是否依赖正确，再比较返回是否符合预期。没有参考答案时可利用规则：若参数与上下文冲突、调用未使用前序返回，则标记可疑。更系统的方法是用 LLM 裁判对局部步骤打分，但需避免位置偏差。
轨迹字段过多会不会拖累在线系统性能？
有影响，因此需要分层采样：在线默认只保留必填元数据，对包含敏感字段或大量 token 的内容做脱敏和摘要。评估需要完整轨迹时，可从分布式追踪中异步拉取并回放，而不是同步写全量大字段。
轨迹评估与最终结果评估是什么关系？
两者互补：结果评估回答“做成没有”，轨迹评估回答“怎么做的、错在哪”。当任务多路径合法时，结果评估更能容忍不同解法；轨迹评估擅长发现单路径中的无效调用和危险操作，但不能否定非典型但可行的路径，需结合允许集判断。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。