【智能体测评-06】轨迹测评：不只看做没做成，还要看怎么做的

一个成功率掩盖的问题

假设你在对比两个版本的 Coding Agent：

• 版本 A：修一个 bug，平均调用 12 次工具，读取 8 个文件，花了 3 分钟，消耗 45k token，成功率 72%。
• 版本 B：修同样的 bug，平均调用 4 次工具，读取 2 个文件，花了 40 秒，消耗 8k token，成功率 70%。

只看成功率，A 还略胜一筹。但任何一个真正用过 Agent 的人都会告诉你：B 远比 A 优秀。A 那 72% 的成功率是靠“大力出奇迹”堆出来的——读遍整个仓库、反复试错、运气好撞上正确答案；B 则是真正理解了问题，精准定位，一击命中。

如果你的测评只记录“成功/失败”这一个二元结果，你不仅无法区分 A 和 B，还可能做出错误的版本选择——甚至可能为了那 2% 的成功率提升，愿意接受 5 倍的成本恶化。

这就是我们需要**轨迹测评（Trajectory Evaluation）**的原因：把 Agent 完成任务过程中的每一步行动、每一次工具调用、每一次思考和回溯，都作为测评的输入。不只看“做没做成”，还要看“怎么做的”。

什么是轨迹

在 Agent 语境下，轨迹（trajectory）是一个 Agent 在完成任务过程中产生的完整事件序列。它通常包含：

用户输入
  → Agent 思考（thought/plan）
  → 工具调用（tool call + 参数）
  → 工具返回（observation）
  → Agent 思考（根据返回调整）
  → 工具调用
  → ...（重复 N 轮）
  → 最终输出 / 行动

每一条轨迹都是一个有时序的、结构化的事件链。它既是 Agent 行为的“黑匣子”，也是测评最丰富的数据源。

和轨迹相关但不同的概念：

• Trace（链路追踪）：更偏工程可观测性，关注 span、耗时、错误，通常来自 OpenTelemetry 等系统。轨迹是 trace 在测评语义上的超集——它不仅包含技术指标，还包含行动的逻辑和质量。
• Session（会话）：用户视角的一次交互，可能包含多个任务。轨迹通常针对单个任务。
• Transcript（对话记录）：自然语言层面的消息流。轨迹是它的结构化版本，包含工具调用、参数、返回等非对话内容。

为什么只看结果不够

在展开“怎么测轨迹”之前，先彻底说服你为什么这一步不可或缺。

1. 成功可能是“低质量成功”

Agent 完成了任务，但方式有严重隐患：

• 用 rm -rf 删了整个目录再重新创建，而不是精确修改一个文件（Coding Agent 的真实案例）
• 调用了 20 次搜索才找到信息，而正常人类只需要 2 次
• 在多轮对话中前后矛盾，但最终答案恰好碰对
• 通过硬编码/记忆题库答案“通过”了测试，但没有泛化能力

这些情况的共同点：结果正确，但过程不可迁移、不可复现、成本不可接受。 只看成功率的团队会误以为系统在变好，直到一次“低质量成功”在生产环境造成事故。

2. 失败有不同的“失败质量”

两个 Agent 都失败了，但失败的含义完全不同：

• Agent A：搜索了 3 次，发现任务需要的数据源不可访问，明确告诉用户“这个信息我无法获取”，并建议替代方案。
• Agent B：搜索了 15 次，反复点击无效链接，最后编造了一个看似合理但完全虚假的答案。

从结果看都是“失败”，但 A 是诚实的失败——它准确识别了自身能力边界，这种失败在生产中是可接受的；B 是危险的失败——它不仅没完成任务，还产生了幻觉输出，可能误导用户造成实际损失。

如果只统计失败率，A 和 B 被等量齐观。但任何一个产品经理都知道，B 造成的客诉和信任损失远大于 A。

3. 过程信号比结果信号更早、更细

结果是一个延迟信号：你需要等 Agent 跑完整条轨迹才能知道成败。而过程信号是实时的——走到第三步发现工具调用参数异常，你可以立即中止、记录、归类，不必等它浪费后续 20 步的 token。

过程信号也更细粒度。一个 10 步的任务，结果只有 1 bit（成功/失败），但过程可以产生几十个维度的信号：每步的工具选择是否合理、参数是否正确、返回是否被正确解读、回溯是否有效……这些信号加起来，对 Agent 能力的刻画精度远高于一个二元标签。

4. 过程可诊断，结果只能归因猜测

成功率从 72% 掉到 65%，你只知道“变差了”。但变差在哪里？是规划阶段拆解错了？还是某个工具的 API 变了导致调用失败？是新模型版本不擅长长链推理？还是上下文管理出了 bug？

只看结果，这些问题只能靠猜。有了轨迹，你可以直接对比两个版本的行动序列：第 3 步的工具选择从“搜索”变成了“直接回答”，导致后续全部跑偏——问题定位到具体步骤。

轨迹测评的六个核心指标

我们从实践中总结了六个维度的轨迹指标。它们不是全部，但覆盖了绝大多数诊断需求。

1. 步数与效率（Step Count & Efficiency）

定义：Agent 完成任务所经历的“思考-行动”轮次。

最直觉的指标。步数越多，通常意味着：

• 规划不够精准，需要反复试探
• 信息收集效率低
• 存在不必要的迂回

但步数不是越少越好——过于“果断”的 Agent 可能在信息不足时就草率行动。关键是建立任务复杂度和合理步数的对应关系：一个简单查询用了 15 步是低效，一个复杂调研只用了 2 步可能是鲁莽。

怎么测：

• 按任务类型/难度分层，统计步数的中位数和 P90
• 设置“合理步数区间”，超出区间的标记为异常轨迹
• 对比版本时，看步数分布的变化（不只是均值）

2. 工具调用准确率（Tool Call Accuracy）

定义：在所有工具调用中，选择了正确工具、传入了正确参数、且返回结果被正确使用的比例。

这是一个复合指标，可以拆成三层：

• 工具选择准确率：该搜索的时候有没有搜索，该读文件的时候有没有读文件
• 参数构造准确率：选对了工具，参数对不对（搜索关键词是否精准、文件路径是否正确、API 参数是否完整）
• 结果利用率：工具返回了有用信息，Agent 有没有正确读取和使用（而不是忽略返回结果重复调用）

怎么测：

• 组件层（L1）可以用人工标注的“期望工具调用”作为 ground truth 来算精确率/召回率
• 任务层（L3）可以用规则校验：参数是否符合 schema、是否调用了不存在的工具、是否重复调用完全相同的参数
• 深度分析需要人工或 LLM 标注：这个调用在这个上下文中是否合理

3. 回溯与重试率（Backtrack & Retry Rate）

定义：Agent 在轨迹中“走回头路”的频率——撤销之前的行动、重新尝试已失败的步骤、或返回到之前的决策点换一种策略。

回溯本身不是坏事。一个聪明的 Agent 在发现此路不通时应该能够回退并尝试替代方案。问题在于：

• 无效回溯：反复重试同一个失败操作而不改变策略（“定义精神”的定义：重复做同样的事却期待不同结果）
• 过度回溯：频繁推翻自己之前的决策，说明规划不稳定
• 回溯质量：回溯后是否换了真正不同的策略，还是只是换了个措辞做同样的事

怎么测：

• 统计重复工具调用次数（相同工具+相同或相似参数）
• 统计“撤销”类操作的频率（如删除已写入的文件、回退已做的修改）
• 标注回溯后策略是否发生了实质性变化
• 计算“有效回溯率”：回溯后最终成功的比例

4. 无效动作率（Invalid Action Rate）

定义：Agent 产生的、对完成任务没有任何正面贡献的行动比例。

典型无效动作：

• 调用了不存在的工具（幻觉 API）
• 参数格式错误导致工具直接报错
• 读取了完全不相关的文件/页面
• 搜索了与任务无关的关键词
• 对已经确认的信息进行重复验证
• 输出了一段思考但没有采取任何行动（空转）

无效动作和回溯有重叠但不完全相同：回溯是“走了又退回来”，无效动作是“这一步本身就不该走”。

怎么测：

• 规则统计：工具调用返回 schema 校验错误的比例、404/错误响应的比例
• LLM 标注：给定任务目标和当前步骤，判断这一步是否对目标有正面贡献
• 设置阈值：无效动作率超过 20% 的轨迹标记为“混乱轨迹”

5. 成本与时延（Cost & Latency）

定义：完成任务消耗的 token 总量、API 调用费用和端到端时延。

这是最容易量化、也最容易被忽视的指标。一个成功率 90% 但平均成本 $2 的 Agent，和一个成功率 85$0.10 的 Agent，在大多数商业场景下后者更有部署价值。

需要分层统计：

• 推理 token：思考和生成输出的 token 消耗
• 工具 token：工具返回结果占用的 token（搜索结果、网页内容、文件内容等）
• 时延构成：模型推理耗时 vs 工具执行耗时 vs 网络延迟

怎么测：

• 每条轨迹记录 input_tokens、output_tokens、总耗时
• 按任务类型统计 P50/P95 成本和时延
• 计算“单位成功成本”：总成本 / 成功任务数（比平均成本更有决策意义）
• 画出成本-成功率散点图，找到帕累托前沿

6. 恢复行为质量（Recovery Quality）

定义：当 Agent 遇到错误、异常或意外结果时，它的应对方式是否有效。

这是六个指标中最难以自动化测量、但区分度最高的一个。真实环境中 Agent 几乎不可能一帆风顺：API 超时、页面改版、搜索结果为空、文件不存在……Agent 如何处理这些摩擦，很大程度上决定了它的鲁棒性。

恢复行为可以分成几个等级：

怎么测：

• 在测评集中主动注入故障（API 超时、返回空结果、权限拒绝），观察 Agent 的恢复等级
• 对生产环境中的错误恢复片段进行人工标注
• 统计每个 Agent 版本在 L0-L5 各等级上的分布

轨迹对比：怎么判断 A 版本比 B 版本“更聪明”

单一轨迹的指标只是素材。轨迹测评真正的价值在于对比——两个 Agent 版本、两个模型、两套 prompt，谁在过程上更优？

配对轨迹对比（Paired Trajectory Comparison）

最严格的方法：用同一批任务跑两个 Agent 版本，得到配对的轨迹对，然后逐条对比。

对比时关注：

1. 结果一致性：一个成功一个失败的 case 有多少？都成功或都失败的 case 中，过程差异是什么？
2. 分歧点分析：两条轨迹从第几步开始走不同的路？那个分叉点上 Agent 分别做了什么决策？哪个决策更合理？
3. 效率差距：在都成功的 case 上，步数/成本/时延的比值是多少？
4. 失败模式差异：A 版本的典型失败和 B 版本的典型失败有什么不同？

配对对比的好处是控制了任务难度变量——你不会因为 A 版本恰好抽到了简单任务就误判它更好。

轨迹聚类：发现典型行为模式

当你积累了成百上千条轨迹后，逐条对比不现实。这时候需要聚类：把行为模式相似的轨迹归为一类。

常见的轨迹类型：

• 直线型：从起点到终点，步骤简洁，几乎无回溯。最优轨迹。
• 探索型：前期有适度试错，找到正确方向后高效执行。正常轨迹。
• 迂回型：走了很多弯路但最终到达。步数和成本偏高。
• 螺旋型：反复在几个状态之间打转，没有实质进展。通常对应死循环或规划缺陷。
• 散漫型：方向频繁漂移，大量与任务无关的动作。注意力/目标管理问题。
• 崩溃型：几步之后遇到错误就停止，或输出完全乱套。鲁棒性问题。

聚类方法可以很简单（按步数、回溯率、无效动作率等指标做规则分桶），也可以用 embedding 对轨迹序列做向量化后聚类。关键不是算法多高级，而是聚出来的每一类都有明确的改进方向。

轨迹可视化：让人看懂发生了什么

数字和聚类之外，让人能直观看到轨迹同样重要。一个好的轨迹视图应该像 Git 的提交历史一样清晰：

• 每一步展示：思考摘要 → 工具调用 → 返回摘要
• 用颜色/标记区分正常步骤、重试、错误、回溯
• 标注出“关键决策点”（轨迹在此处分叉）和“致命错误点”
• 支持两条轨迹并排对比，高亮差异

工具方面，LangSmith、Braintrust、Langfuse 都提供了开箱即用的轨迹视图。如果自建，核心就是把事件序列渲染成可折叠的时间线。

实操：搭建轨迹测评的最小流程

讲了这么多概念，落地需要什么？

第一步：全量记录轨迹数据

你无法测评没有记录的东西。确保 Agent 的每一次运行都产生结构化的轨迹日志，至少包含：

{
  "task_id": "xxx",
  "agent_version": "v1.2.3",
  "model": "claude-sonnet-4",
  "start_time": "...",
  "steps": [
    {
      "step_number": 1,
      "timestamp": "...",
      "thought": "我需要先搜索...",
      "tool": "web_search",
      "tool_input": {"query": "..."},
      "tool_output": "...",
      "tool_status": "success",
      "latency_ms": 320,
      "tokens": {"input": 1200, "output": 80}
    }
  ],
  "final_output": "...",
  "status": "success",
  "total_tokens": 12500,
  "total_latency_ms": 18000
}

存储用 JSONL 或数据库都行，关键是全量记录、不要抽样——你永远不知道哪条轨迹未来会成为诊断问题的关键证据。

第二步：计算自动化指标

对每条轨迹自动计算：

• 总步数、工具调用次数
• 各工具调用次数分布
• 错误/重试/回溯次数（用规则匹配）
• 总 token、总时延
• 是否调用了不存在的工具
• 是否有重复的相同调用

这些指标 100% 可自动化，不需要 LLM 或人工。它们构成了轨迹测评的“基本面”。

第三步：对关键轨迹做深度标注

自动化指标只能告诉你“发生了什么”，不能告诉你“这一步是否合理”。对以下轨迹需要做深度标注：

• 版本对比中结果不一致的配对轨迹
• 自动化指标异常的轨迹（步数远超 P90、无效动作率过高）
• 生产环境中引发用户投诉的轨迹
• 随机抽样的 5-10% 轨迹（用于校准自动化指标的可信度）

标注可以用 LLM-as-Judge（参考第 5 篇的校准方法），但关键 case 必须有人工审核。

第四步：建立轨迹基准线（Baseline）

第一次跑的时候，不要急于设阈值。先积累 100-200 条轨迹，计算各指标的分布，建立基准线：

• 步数中位数和 P90
• 工具调用准确率的基准值
• 平均成本和时延
• 各类轨迹模式的占比

有了基准线，后续每次版本更新都能回答：新版本的步数分布是改善了还是恶化了？无效动作率是升了还是降了？成本变化了多少？

第五步：把轨迹指标接入版本决策

最后也是最重要的一步：让轨迹数据真正影响发布决策。建议的门禁标准：

• 成功率不低于基准线（L3 硬指标）
• P90 步数不超过基准线的 120%（防止效率退化）
• 无效动作率不超过基准线的 110%
• 单位成功成本不超过基准线的 115%
• 高严重度失败模式（幻觉工具、危险副作用）零新增

这些阈值不是固定的，需要根据业务调整。但有阈值和没有阈值的区别是：前者让你在发版前就能发现“成功率涨了但过程变差了”的退化，后者只能等线上出问题。

轨迹测评的边界和陷阱

最后说几个容易踩的坑。

陷阱一：步数崇拜

“步数越少越好”是最常见的误读。步数是效率指标，不是质量指标。一个经过深思熟虑、充分验证后才行动的 Agent，步数可能比一个草率决策的 Agent 多，但质量更高。

正确做法：把步数和成功率、错误率联合看。步数少 + 成功率高 = 高效；步数少 + 成功率低 = 鲁莽；步数多 + 成功率高 = 稳健但有优化空间；步数多 + 成功率低 = 混乱。

陷阱二：把轨迹指标当成优化目标

Goodhart’s Law again：当指标变成目标，它就不再是好指标。如果你把“减少步数”作为优化目标，Agent 可能学会在信息不足时过早下结论来“节省步数”。

轨迹指标是诊断信号，不是优化目标。真正的目标是任务完成质量和用户满意度，轨迹指标帮你理解和改进过程，但不应被直接优化。

陷阱三：忽视轨迹的隐私和安全

轨迹记录了 Agent 的完整行动过程，可能包含敏感信息：用户数据、API 密钥、内部文件内容、商业逻辑。存储和共享轨迹时需要：

• 脱敏处理（PII、密钥、token）
• 访问控制（谁可以查看轨迹）
• 保留期限（不是所有轨迹都需要永久保存）
• 用户告知（在隐私政策中说明 Agent 行动会被记录用于改进）

陷阱四：只在测评环境做轨迹分析

测评环境的轨迹是干净的、可控的、任务明确的。生产环境的轨迹充满了噪音：用户可能中途改变主意、网络可能抖动、工具可能间歇性故障。

只在测评环境分析轨迹，你会错过最重要的失败模式。理想状态是建立从生产到测评的回流通道：生产环境中典型的失败轨迹被脱敏后加入测评集，在下一个版本中被针对性测试。

小结

轨迹测评的核心信念是：Agent 的能力不仅体现在它“做了什么”，更体现在它“怎么做的”。 一个聪明的 Agent 和一个笨拙的 Agent 可能在成功率上相差不大，但在行动效率、工具使用精准度、错误恢复能力上差距巨大——这些差距只有通过分析过程才能发现。

这六个指标覆盖了 L2 轨迹测评层的核心。它们和 L1 组件测评、L3 任务测评、L4 生产观测共同构成了完整的测评体系。

下一篇【智能体测评-07】自建测评集方法论：别再拿 20 条 case 自欺欺人了，我们讲一个所有其他测评层都依赖的基础设施——怎么构建一套真正有信号量的测评集。因为不管你的评分方法多科学、轨迹分析多精细，如果测评任务本身设计得不好，所有结论都是空中楼阁。