一、结果对、过程错：三种最常见的翻车

大多数团队的评测只回答一个问题：最终输出对不对。但 AI 助手（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 字段。很多团队只记动作和返回，把模型当时的推理理由丢掉了，事后复盘「这一步为什么这么做」就完全靠猜。只要底层模型能输出推理过程——不管是显式的思维链，还是调用工具前的一句简短说明——都务必完整保存下来，这是能不能定位到根因的唯一数据源。

三、在「对不对」之外，再加五个维度

这五项里，路径效率和工具选择合理性可以做到相对客观的自动打分；错误恢复能力、中途状态一致性通常得靠大模型当裁判加人工抽检；而风险分支触碰不该做成「扣几分」的评分项——它应该是硬性报警，碰到就拦。

四、自动打分怎么落地：从「步数比」到「轨迹距离」

最容易上手的自动指标是步数比：实际执行步数 ÷ 该任务的参考最短步数。参考值有两条路——一是人工标注一批典型任务的「专家轨迹」（贵但准），二是用更强的模型多次采样、取步数中位数当基线（便宜但可能带偏差，需要定期人工校准）。

更精细的是「轨迹编辑距离」：把实际轨迹和参考轨迹都写成「工具调用序列」，忽略具体参数，只看调了哪些工具、顺序如何，再用类似字符串编辑距离的算法算差异。它能抓住「步数一样、走的却是完全另一条路」的情况。

一个坑要提前避开：编辑距离对顺序敏感，但有些任务里两个调用互换并不影响正确性（先查库存还是先查价格，结果一样）。这类可交换步骤如果不在标注阶段标出来，会被误判成差异，计算时需要做归一化。

五、让大模型当裁判：别把整条轨迹一次性塞进去

语义层面的判断（恢复能力、状态一致性）规则覆盖不全，一般交给大模型裁判。但这里有个和单轮评测不同的坑：轨迹通常很长。整条「思考+动作+返回」序列塞进裁判的上下文，容易顾此失彼，对中段的问题视而不见——长上下文注意力衰减是已知现象。

更稳的做法是「分段裁判 + 汇总」：把轨迹按任务的自然阶段切成 3~5 段，每段单独判断「这一段是否合理」，最后再用一次简短的汇总裁判，输入的是各段结论而不是全文。这样每次面对的上下文长度可控，判断更稳，也能精确定位是哪个阶段出的问题，而不是拿到一句笼统的「整体有问题」。

六、什么规模值得投入，怎么接进发布流程

轨迹评测的记录、存储、裁判成本都比结果评测高不少，不建议一上来就全量铺。满足下面任一条时再引入比较划算：

• 任务平均步数超过 5 步（步数越多，中间出问题的概率和浪费越大）；
• Agent 具备写操作或高权限工具调用能力（此时「风险分支触碰」价值最大）；
• 团队已经出现「结果分数正常、用户体感变差」的信号。

接入发布流程的做法也不复杂：维护一批固定任务的专家轨迹基准集（不用很大，20~30 个覆盖主要任务类型即可起步）；每次改动 prompt、工具定义或模型版本后跑一遍，算出轨迹编辑距离和步数比的均值；设阈值，比如均值比上一版恶化超过 15% 就让流水线标红，人工确认这次改动是否值得付出这个代价——有时候为了修一个安全问题，多绕两步是合理取舍。

如果任务本身很短、工具全是只读查询，暂时靠结果评测加人工抽检就够了，不必上这套重装备。