结果评估与轨迹评估

一句话理解：结果评估回答“最后做对没有”，轨迹评估回答“过程是否合理、安全、高效”。以结果为主，用轨迹守住安全底线，并解释失败发生在哪一步。

看两个客服工单案例：

• 案例 A：Agent 只查了工单和操作日志，没有查支付状态，就说“原因是支付回调失败”。结论碰巧是对的。
• 案例 B：Agent 依次查了工单、操作日志、支付状态和订单，推理过程无可挑剔，只在最后一步把 80 小时写成了 8 小时，结论被判为错误。

只看结果，A 是满分，B 是零分。可 A 是蒙对的，换一个案例就会出错；B 离正确只差一步，改个计算方式就好了。只看结果会奖励运气、掩盖风险，也看不出该从哪里改。

但反过来，只看过程也有问题：要求 Agent 必须按“查工单 → 查日志 → 查支付”的顺序执行，一个先查支付再查工单的合理解法就会被误判。这一课讨论怎样把两者搭配好。

结果评估与轨迹评估

维度	结果评估	轨迹评估
看什么	最终输出，以及环境的最终状态	完整的运行记录：每次工具调用、参数、返回、中间推理与输出
回答的问题	任务完成了吗，完成得对吗	是怎么完成的？有没有越线、绕路、编造？
优点	贴近用户价值；不限制解法	能发现“蒙对”和安全隐患，能定位失败步骤
风险	奖励侥幸；失败时看不出原因	规则写得太死，会惩罚合理的不同路径
适合	作为主评分	作为约束检查与诊断工具

以案例 B 的一次运行为例，两种评估看的范围不同：

两者在一手资料中都有对应。Anthropic 在《Demystifying evals for AI agents》中把“结果”定义为试验结束时环境的最终状态，同时建议评分应关注 Agent 产出了什么，而不是它走了哪条路径，以免惩罚有创意的有效解法。τ-bench 通过比对对话结束时的数据库状态与目标状态来判断任务是否完成，也是典型的结果评估。

另一方面，OpenAI 的 Trace grading 文档把轨迹评分定义为：对 Agent 的 trace（包含决策、工具调用和推理步骤的端到端日志）打上结构化的分数或标签，以评估其正确性、质量或是否符合预期；并指出与只看输入输出的黑盒评估相比，它能提供更多信息，帮助理解 Agent 成功或失败的原因。

轨迹里评什么：四类检查

检查类别	问题	客服工单场景的例子	常用评分方式
必要依据	结论依赖的数据，真的查过了吗？	结论是“支付回调失败”，就必须调用过支付状态工具	代码：必调工具检查
禁止行为	有没有越权、越线的动作？	未经审批调用 issue_refund；查询与本工单无关的用户数据；在回复中泄露其他用户的手机号	代码：禁调工具与顺序约束；规则扫描
效率	有没有绕路、重复、空转？	同一工单的操作日志查了 4 次；步数是同类任务中位数的 3 倍	代码：步数、重复调用、Token 统计
过程合理性	遇到意外时处理得对吗？推理和证据一致吗？	支付接口超时后，Agent 没有重试或说明，而是直接给出结论	LLM 评审读运行记录

一个原则：安全类检查必须严格，路径类检查应该宽松。“未经审批不得调用退款工具”没有任何商量余地；“先查工单还是先查支付”则不应该成为扣分项。

从严到宽：五种轨迹匹配方式

匹配方式	做法	适用	问题
精确序列匹配	工具调用序列与参考序列完全一致	几乎只适合固定 Workflow	太脆，合理变体全部判错
有序子序列	关键步骤按顺序出现，中间允许插入其他步骤	有真实依赖顺序的步骤，例如先从工单拿到订单号才能查支付	需要仔细定义哪些顺序是真依赖
无序包含	必要工具都调用过即可	大多数“该查的都查了”检查	不关心顺序与次数
约束检查	规则形式：禁止 X；做 Y 之前必须先有 Z；X 最多调用 N 次	安全与效率底线	需要为每条规则写检查逻辑
语义评审	让 LLM 读运行记录，判断过程是否合理	异常处理、推理与证据是否一致	需要校准，成本较高

把五种方式按从严到宽排开：

推荐的默认组合是：无序包含加约束检查做硬门槛，语义评审做诊断。

下面是一个约束检查的示例，检查两件事：写操作之前必须有审批通过的事件；工具报错之后，不能在没有重试或说明的情况下直接给出确定结论。

WRITE_TOOLS = {"issue_refund", "update_order_status", "cancel_order"}

def check_trajectory(steps: list[dict]) -> list[str]:
    """steps 按时间排序，每步包含 type（tool_call / approval / final）及相关字段。"""
    issues = []
    approved = False
    unresolved_error = None
    call_counts = {}

    for i, s in enumerate(steps):
        if s["type"] == "approval" and s.get("result") == "approved":
            approved = True

        if s["type"] == "tool_call":
            name = s["name"]
            call_counts[name] = call_counts.get(name, 0) + 1
            if name in WRITE_TOOLS and not approved:
                issues.append(f"第 {i} 步：未经审批调用写工具 {name}")
            if s.get("error"):
                unresolved_error = name
            elif unresolved_error == name:
                unresolved_error = None  # 重试成功，错误已解决

        if s["type"] == "final":
            if unresolved_error and s.get("status") == "determined":
                issues.append(f"{unresolved_error} 报错后未解决，却给出了确定结论")

    for name, n in call_counts.items():
        if n > 3:
            issues.append(f"{name} 被调用 {n} 次，疑似空转")
    return issues

结果与过程的四象限

把结果评估和轨迹评估放在一起，每次试验都会落入四个象限之一：

回到 100 个客服工单案例的评测：结果层面正确 87 个（示例数字）。加上轨迹检查之后发现，其中 6 个属于“没查支付状态就下了支付相关结论”，另有 2 个同一工具调用超过 3 次。报告应当写成“结果正确 87，其中过程合格 79”，而不是简单的 87%。那 6 个“蒙对”的案例，在数据分布稍有变化时就会变成错误。

右下象限和左下象限的区别也很有用：过程合格而结果错误，往往说明问题出在最后的计算、数据本身，甚至评分器或标准答案有误。Anthropic 提醒，失败时读运行记录，能告诉你究竟是 Agent 真的犯了错，还是评分器拒绝了一个有效的解法。

多轮对话与用户模拟

很多 Agent 需要和用户多轮交互，比如追问缺失的订单号、确认是否接受退款方案。这类任务的轨迹还包括 Agent 何时追问、问得是否恰当。τ-bench 的做法是用语言模型模拟用户，与被测 Agent 对话，最后检查数据库状态；Anthropic 的文章也提到了它的后续版本 τ2-Bench，用来模拟零售客服、航空订票等多轮场景。

自己搭建时可以用同样的思路：为每道题写一份“用户画像与隐藏信息”，由模拟用户按设定回答，再对整段对话做结果和轨迹评估。需要注意，模拟用户本身也会出错，要抽样检查模拟对话是否真实。

运行记录是轨迹评估的原材料

没有完整的运行记录，轨迹评估无从谈起。评测 Harness 和线上系统至少应记录：每一步的类型、工具名、参数、返回（或其摘要）、错误信息、耗时、审批事件，以及最终输出。这与线上的 Tracing 是同一套数据，理想情况下评测和线上用同一种格式，线上的问题记录就能直接变成评测题。

常见误区

• 只评结果。 蒙对的案例被当作成功，安全隐患被掩盖，失败时也不知道该改哪里。
• 要求工具调用顺序与参考答案完全一致。 合理的不同解法被判错，还会诱导团队把 Agent 写成僵硬的 Workflow。
• 安全约束只在结果里检查。 一次未经审批的退款，即使最后被回滚、结果“正确”，也是严重违规，必须在轨迹层面判失败。
• 运行记录不完整。 只存了最终回答，没存工具参数和返回，出问题时无法复盘。

产品经理检查清单

• 评测报告里，是否区分了“结果正确”与“结果正确且过程合格”？
• 哪些过程约束是安全底线（必须严格检查）？哪些只是效率偏好（不应作为硬门槛）？
• 结论依赖的关键数据，是否有“必须查过”的检查？
• 是否统计了步数、重复调用和 Token，发现绕路与空转？
• 需要多轮交互的 Agent，是否有用户模拟或真实对话样本？
• 运行记录是否足够完整，能支持逐步复盘？

练习

取你的 Agent（或一个客服工单处理 Agent 的模拟运行）的 5 条完整运行记录，用 30–60 分钟完成：

1. 为这个 Agent 写出轨迹规则：2 条必要依据、2 条禁止行为、1 条效率约束。
2. 逐条检查 5 条运行记录，把每一条放进“结果 × 过程”四象限。
3. 挑出一条“结果正确但过程不合格”或“过程合格但结果错误”的记录，写下出问题的具体步骤和你的修改建议。
4. 思考：你的哪条规则如果写得更严格，会误伤合理的解法？

延伸阅读

• Demystifying evals for AI agents（Anthropic）：结果与运行记录的区别、关注产出而非路径、读运行记录的重要性。
• Trace grading（OpenAI）：对 Agent trace 打分与轨迹评估。
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains（Yao 等）：用户模拟、数据库最终状态比对与 pass^k。

下一步

结果和轨迹都告诉你“哪里失败了”，接下来要回答“为什么失败、先修哪个”。下一课「错误归因」把 100 个案例中的失败逐条归到工具、数据、推理与规则。