Agent 轨迹级评测方法：不只看结果对不对
一个 Agent 任务跑完，拿到了正确答案，是不是就代表这次执行”没问题”？很多团队的评测体系只回答了这一个问题——“最终输出对不对”，却完全没有记录 Agent 中间走了几步、有没有绕远路、有没有调用了不该调用的高风险工具。结果就是：线上跑分数据看起来很健康，但用户投诉”这个 Agent 用起来又贵又慢”，或者某次执行悄悄删了不该删的文件，团队却完全没有察觉，因为最终结果”恰好”是对的。
这就是只做”结果级评测”（outcome evaluation）的盲区。本文讲的是它的补充——轨迹级评测（trajectory evaluation）：不只看 Agent 最后说了什么，而是把整条执行路径（每一步的工具调用、参数、中间观察、决策理由）都纳入打分范围。
关于 Agent 评估的整体框架和成功率、步数等基础指标，AI Agent 评估方法 已有系统介绍，本文只深入轨迹这一个维度，不重复整体框架内容。
一、结果对但过程错的三种典型场景
在把轨迹评测的方法论展开之前，先看三个”结果正确但过程有问题”的真实场景，能帮助理解为什么这层评测不可省略：
- 绕路但凑巧对了：Agent 要查询某订单状态，正确路径是调用
get_order_status一次搞定，但它先调用了list_all_orders拉全量数据再本地过滤，多消耗了 20 倍 token，且如果订单量增长，这条路径迟早会超时失败。结果评测看到”返回了正确状态”会判定通过。 - 重复调用掩盖了失败重试：Agent 第一次调用支付接口因为参数错误失败，自己悄悄重试了一次改对参数后成功。如果没记录轨迹，你不会知道这个工具的参数说明写得不够清楚，导致模型第一次理解错误——这本该是一个需要修的 prompt/schema 问题，却被”结果正确”完全遮盖。
- 走了危险分支但被兜底救回：Agent 在多步任务中一度尝试执行了一个高权限操作（比如批量删除），但因为权限校验拦截而失败，随后走了另一条安全路径完成任务。最终结果是”任务成功、无副作用”，但如果权限校验哪天出现配置疏漏，这类”曾经尝试过高危操作”的行为模式不会被任何结果评测捕捉到，只有轨迹审查能提前发现这种倾向。
这三种场景的共同点是：结果层面的信号和过程层面的信号是两件事，后者不能靠前者推导出来。
二、轨迹的最小记录单元
要做轨迹评测，第一步是把”轨迹”定义成结构化数据而不是一堆日志文本。一个可落地的最小记录单元大致如下：
{
"step": 3,
"thought": "需要先确认用户的会员等级再计算折扣",
"action": {
"tool": "get_member_level",
"params": { "user_id": "u_10293" }
},
"observation": { "level": "gold", "since": "2025-03-01" },
"latency_ms": 340,
"token_cost": 210
}关键是 thought 字段——很多团队只记录 action 和 observation，丢掉了模型当时的推理理由。没有这一层，事后复盘”这一步为什么这么做”完全靠猜。如果底层模型支持输出推理过程（不管是显式的 chain-of-thought 还是工具调用前的简短说明），务必完整落盘，这是轨迹评测能不能定位根因的关键数据源。
三、轨迹级打分的五个维度
结果对不对只是及格线，轨迹级评测在此基础上追加了这几个维度：
| 维度 | 说明 | 典型信号 |
|---|---|---|
| 路径效率 | 实际步数 vs 理论最短步数 | 步数比、重复调用同一工具次数 |
| 工具选择合理性 | 每一步选的工具是否是当前状态下的最优解 | 是否绕过了更直接的专用工具 |
| 错误恢复能力 | 遇到工具报错或空结果后的处理 | 是否合理重试、是否放弃过早、是否死循环 |
| 风险分支触碰 | 是否尝试了高权限/破坏性操作 | 即便被拦截，触碰本身也应计入风险分 |
| 中途状态一致性 | 多步之间对同一实体的理解是否前后矛盾 | 比如第 2 步查到用户是”免费版”，第 5 步却按”付费版”逻辑处理 |
这五个维度里，路径效率和工具选择合理性可以做到相对客观的自动化打分（下一节展开），错误恢复能力和中途状态一致性通常需要 LLM-as-judge 配合人工抽检，风险分支触碰则应该做成硬性规则拦截而不是评分项——碰到就要报警，不是扣几分了事。
四、自动化打分：从”步数比”到”最优轨迹距离”
最简单也最容易落地的自动指标是步数比：
步数比 = 实际执行步数 / 该任务的参考最短步数参考最短步数怎么来？两条路：一是人工标注一批典型任务的”专家轨迹”作为基准（成本高但准确）；二是用更强的模型（比如更大参数量或推理能力更强的版本）多次采样，取步数中位数作为参考基线（成本低但可能带偏差，需要定期用人工抽检校准）。
比步数比更精细的是轨迹编辑距离：把实际轨迹和参考轨迹都表示成”工具调用序列”（忽略具体参数，只看调用了哪些工具、顺序如何），用类似字符串编辑距离的算法计算两条序列的差异度。这个指标比单纯步数比能捕捉到”步数一样但走的完全是不同路径”的情况，实现上可以直接复用经典的 Levenshtein 距离算法，把每个工具调用当作一个”字符”。
def trajectory_edit_distance(actual_tools, reference_tools):
m, n = len(actual_tools), len(reference_tools)
dp = [[0] * (n + 1) for _ in range(m + 1)]
for i in range(m + 1):
dp[i][0] = i
for j in range(n + 1):
dp[0][j] = j
for i in range(1, m + 1):
for j in range(1, n + 1):
cost = 0 if actual_tools[i - 1] == reference_tools[j - 1] else 1
dp[i][j] = min(
dp[i - 1][j] + 1, # 删除
dp[i][j - 1] + 1, # 插入
dp[i - 1][j - 1] + cost, # 替换
)
return dp[m][n]这个距离值越小，说明实际路径和专家路径越接近。需要注意的是，编辑距离对”顺序敏感”，但有些任务里两个工具调用顺序互换并不影响正确性（比如先查库存还是先查价格，结果一样），这类”可交换步骤”如果不做特殊处理，会被编辑距离误判为差异，建议在参考轨迹标注阶段就标出哪些步骤对是可交换的，计算时做归一化处理。
五、LLM-as-judge 在轨迹评测里的用法边界
错误恢复能力和状态一致性这类语义层面的判断，用规则很难覆盖所有情况，通常交给 LLM 做裁判。但轨迹评测用 LLM-as-judge 有一个和结果评测不一样的坑：轨迹通常很长，把完整的多步 thought+action+observation 序列塞进裁判模型的上下文，容易出现”裁判模型自己也顾此失彼”，对轨迹中段的问题视而不见（长上下文注意力衰减是已知现象）。
实践中更稳的做法是分段裁判 + 汇总：把轨迹按任务的自然阶段切成 3~5 段，每段单独让裁判模型评估”这一段是否合理”，最后再用一次简短的汇总裁判，输入的是各段裁判结论而不是原始轨迹全文，得出整体分数。这样每次裁判模型面对的上下文长度可控，判断质量更稳定，也更容易在某一段出问题时精确定位是哪个阶段的问题，而不是拿到一个笼统的”轨迹整体存在问题”结论。
关于 LLM-as-judge 打分的稳定性问题和评分集维护方法，LLM 评测 Golden Set 构建方法 里有更系统的讨论，本文不重复展开评分集本身的构建流程。
六、把轨迹评测接入 CI 门禁
轨迹评测最终要发挥价值，得能拦截住”这次 prompt/工具改动让 Agent 走路更绕了”这类回归，而不只是停留在离线报告里。可行的接入方式：
- 维护一批固定任务的专家轨迹基准集（不需要很大，20~30 个覆盖主要任务类型即可起步）。
- 每次 Agent 相关代码（prompt、工具定义、模型版本）改动后，跑一遍基准集，计算轨迹编辑距离和步数比的均值。
- 设定阈值——比如均值比上一个基线版本恶化超过 15%，CI 标红，需要人工确认这次改动是否值得接受这个代价（有时候为了修一个安全问题，多绕两步是合理的取舍）。
这个思路和 Prompt 改动的回归检测本质上是一类问题，只是评测对象从”单轮输出”换成了”多步轨迹”，如果团队已经有 Prompt 回归检测的基础设施，可以参考 Prompt 改动后的回归检测 里的 CI 门禁设计直接复用大部分流程骨架，只需要把评分函数换成本文介绍的轨迹距离和分段裁判。
七、什么规模的项目值得投入轨迹评测
轨迹评测的记录、存储、裁判成本都比单纯的结果评测高不少，不是所有项目都值得一开始就上。经验上，当满足以下任一条件时再引入比较合适：Agent 任务平均步数超过 5 步（步数越多，中间出问题的概率和造成的浪费都越大）；Agent 具备写操作或高权限工具调用能力（风险分支触碰这一项此时价值最大）；或者团队已经发现”结果分数正常但用户体感变差”的信号（说明结果评测的盲区已经在实际暴露问题）。如果 Agent 任务本身很短、工具都是只读查询，暂时靠结果评测加人工抽检就足够。
八、相关阅读
如果你的 Agent 需要同时调用多家模型做轨迹级 A/B 对比，用 YoTradeApi 统一接入可以省去分别对接各家 API 的评测基础设施改造成本。