Agent 评测不能只看答案：从 Output Eval 到 Trajectory Eval

过去我们评测一个大模型应用，最常见的方式是看最终回答。

用户问了一个问题，模型给了一个答案。

答案对，打高分；答案错，打低分。

这种方式在普通问答场景里问题不大，但一旦进入 Agent 场景，就会开始变得不够用了。

因为 Agent 和普通 ChatBot 最大的区别不是"会不会回答"，而是它中间会做事：会规划任务、选择工具、调用接口、读取数据、处理异常、更新上下文，最后再组织一个结果返回给用户。

也就是说，Agent 的质量不只体现在最后那句话上，更体现在它"怎么走到这句话"的过程里。

这也是为什么 Agent 评测不能只停留在 Output Eval ，也就是最终输出评测，而是要进一步走向 Trajectory Eval，也就是执行轨迹评测。

简单说：

复制代码

Output Eval 关注：最后回答对不对？
Trajectory Eval 关注：它是怎么得到这个答案的？

最终答案只是结果。

执行轨迹，才是 Agent 工程化里最容易暴露问题的地方。

一、只看最终答案，为什么不够？

我们先看一个简单例子。

用户问：

帮我查一下我昨晚那笔外卖订单为什么还没退款。

Agent 最后回答：

你的订单目前还在退款处理中，预计 1-3 个工作日到账。

如果只看最终答案，好像还挺合理。

但问题是，这个答案是怎么来的？

它有没有真的查订单？

有没有确认是哪一笔订单？

有没有调用退款查询接口？

有没有看支付状态？

有没有把昨晚的订单和上周的订单搞混？

有没有在没有权限的情况下查看用户敏感信息？

有没有只是根据常见话术编了一个"1-3 个工作日"？

最终答案看起来合理，不代表执行过程一定可靠。

在 Agent 场景里，这个问题会非常常见。因为 Agent 不是简单回答一句话，它往往会接入工具、数据库、业务系统或者外部 API。

比如：

外卖助手要查订单、查退款、查骑手状态
旅游助手要查航班、查酒店、查天气、算预算
报销助手要识别发票、校验金额、匹配制度
客服助手要查用户信息、查工单、查售后政策
数据分析助手要查数据库、生成图表、总结结论

这些场景里，最后一句话说得像不像，并不能说明 Agent 真的做对了。

一个 Agent 可能最终答对了，但中间调用了不该调用的工具。

一个 Agent 可能最终答错了，但真正的问题不是模型不聪明，而是工具参数传错了、接口返回异常没处理，或者上下文里混入了旧信息。

所以，Output Eval 的最大问题是：它只能告诉你结果像不像对，但很难告诉你过程错在哪里。

只看最终答案，就像只看考试卷最后答案，不看草稿纸。

对简单题还行，但对复杂任务来说，草稿纸上往往藏着真正的问题。

二、什么是 Output Eval？

Output Eval，也就是输出评测，关注的是 Agent 最终返回给用户的内容。

常见评测方式包括：

最终答案是否正确
是否命中标准答案
表达是否完整
是否有幻觉
是否符合格式要求
是否满足用户意图

比如用户问：

北京到上海明天最早的一班高铁是几点？

Agent 最终回答：

明天最早的一班高铁是 6:20，从北京南站出发。

如果只做 Output Eval，我们只会关心这个答案是否正确。

答案对，就通过。

答案错，就失败。

这类评测很重要，不能丢。

因为用户最终看到的就是输出结果。如果最后回答错了，中间过程再漂亮也没有意义。

但 Agent 的问题在于，它不是一个单点输出系统，而是一个多步骤执行系统。它的失败往往不是发生在最后一步，而是发生在中间某个环节：

复制代码

意图识别错了
任务拆解错了
工具选错了
参数填错了
调用顺序错了
工具结果没用上
异常没有处理
高风险操作没确认
上下文注入了无关历史

这些问题，单靠 Output Eval 很难定位。

所以 Output Eval 更适合回答一个问题：

最后结果好不好？

但它很难回答另一个更关键的问题：

为什么好？为什么不好？

而 Agent 工程化真正需要的，恰恰是后一个问题。

三、什么是 Trajectory Eval？

Trajectory Eval，可以理解为执行轨迹评测。

它关注的不是 Agent 最后说了什么，而是 Agent 从接收任务到生成结果，中间到底走了哪些步骤。

一个典型 Agent 执行轨迹大概是这样的：

复制代码

用户输入
  ↓
意图识别
  ↓
任务规划
  ↓
工具选择
  ↓
参数生成
  ↓
工具调用
  ↓
结果观察
  ↓
必要时继续调用工具
  ↓
生成最终回答

如果是更复杂的 Agent，还可能包括记忆读取、知识库检索、权限校验、人工确认、异常重试、状态更新等环节。

Trajectory Eval 就是把这些中间过程拿出来评估。

它会问一些更工程化的问题：

Agent 是否选择了正确的工具？
是否在正确时机调用工具？
工具参数是否完整、准确？
多个工具之间的调用顺序是否合理？
是否使用了工具返回的结果？
是否出现了无意义的重复调用？
是否跳过了必要的确认节点？
是否在工具失败后有合理兜底？
是否把中间证据正确转化为最终回答？

举个更好理解的例子。

用户对一个旅游 Agent 说：

帮我规划一下周末从深圳去厦门玩两天，预算控制在 1500 以内，顺便看看天气。

一个只看最终答案的评测，可能只关心它最后有没有给出行程。

但 Trajectory Eval 会继续看：

复制代码

它有没有识别出这是一个"旅行规划"任务？
有没有拆成交通、住宿、天气、景点、预算几个子任务？
有没有查询真实的车票或机票信息？
有没有查询天气？
有没有根据预算筛选住宿？
有没有把交通和酒店价格算进总预算？
有没有避免推荐明显超预算的方案？

这才是 Agent 和普通 ChatBot 的区别。

普通 ChatBot 可以直接凭经验写一份"厦门两日游攻略"。

但 Agent 如果声称自己能规划行程，就应该真的去查交通、查天气、算预算，而不是只写一段看起来很像攻略的文本。

四、Agent 的"好坏"，应该拆开看

如果把 Agent 当成一个黑盒，只看最终答案，就很容易陷入一个误区：一错就觉得是模型不行。

但很多时候，Agent 失败并不是模型本身的问题，而是系统工程问题。

比如用户问：

帮我看看这张发票能不能报销。

Agent 最终答错了。

原因可能有很多种：

第一种，发票识别错了。

比如金额、日期、发票类型识别有误，这时候应该优化 OCR 或结构化解析能力。

第二种，制度没查到。

比如公司报销规则里明确写了"超过 30 天不能报销"，但知识库没有召回对应内容，这时候问题在 RAG。

第三种，Agent 没有调用报销规则查询工具。

它只是凭常识回答"应该可以报销"，这时候问题在工具调用策略。

第四种，Agent 查到了规则，但理解错了。

这时候问题才更像是模型推理或总结能力。

第五种，Agent 直接帮用户提交报销，没有二次确认。

这就不是准确率问题了，而是安全和流程治理问题。

所以，一个成熟的 Agent 评测体系，不应该只有一个总分，而应该把 Agent 拆成多个环节来看。

五、Agent 评测可以拆成哪些维度？

1. Intent Eval：意图有没有识别对

用户说：

帮我看看这个订单怎么回事。

这句话很模糊。

用户可能是想查物流，也可能是想退款，也可能是想投诉，也可能只是想知道商家有没有接单。

如果 Agent 一上来就直接调用退款接口，就可能跑偏。

所以第一步要评估的是：Agent 有没有正确识别用户意图。

意图识别错了，后面的工具调用再准确也没有意义。

2. Planning Eval：任务有没有拆合理

复杂任务不能一步完成，需要拆成多个子任务。

比如用户说：

帮我安排一个周末广州两日游，预算 1000，想吃好一点，但不想太累。

这不是简单生成一段攻略就结束了。

一个更合理的规划过程应该包括：

复制代码

确认出发地和时间
查询交通方式
筛选住宿区域
推荐餐厅和景点
估算总预算
控制行程强度
输出最终安排

如果 Agent 直接跳到最后一步，说明规划不完整。

Planning Eval 关注的就是：Agent 有没有把复杂任务拆成合理步骤，而不是直接"拍脑袋输出"。

3. Tool Selection Eval：工具有没有选对

Agent 有多个工具时，最容易出问题的就是工具选择。

比如一个电商客服 Agent 可能有这些工具：

复制代码

查询订单工具
查询物流工具
查询退款工具
申请退款工具
查询优惠券工具
转人工客服工具

用户问：

我的快递怎么还没到？

合理的工具应该是"查询物流工具"。

如果 Agent 调用了"申请退款工具"，那就明显不对。

如果 Agent 没查物流，直接回答"可能快到了"，也不可靠。

工具选错，比最终回答措辞不好严重得多。

因为工具调用决定了 Agent 接下来拿到什么数据，也决定了它会不会误操作。

4. Argument Eval：参数有没有传对

很多 Agent 看起来"会调用工具"，但实际传参很不稳定。

比如查询订单工具需要这些参数：

复制代码

{
  "orderId": "123456",
  "userId": "U1001"
}

如果 Agent 把订单号传错，或者用了上一轮对话里的旧订单号，那么工具调用虽然成功了，但查出来的是错误数据。

再比如用户说：

查一下我上周五的订单。

Agent 需要把"上周五"解析成具体日期。

如果日期解析错了，结果也会错。

常见参数问题包括：

复制代码

ID 抽错
时间范围错
枚举值错
必填字段漏传
把自然语言原文直接塞进结构化参数
多轮对话里用了旧参数

所以参数正确率应该单独评估，而不是混在最终答案里。

5. Order Eval：调用顺序是否合理

有些工具调用是有依赖关系的。

比如用户问：

帮我改签明天去上海的票。

合理流程应该是：

复制代码

先查询用户订单
再确认可改签规则
再查询可改签车次
再让用户确认
最后执行改签

如果 Agent 一上来就执行改签，那肯定不行。

因为它还没确认是哪张票，也没确认用户想改到哪一班，更没让用户确认最终费用。

调用顺序错了，可能不只是回答错误，而是直接造成误操作。

所以 Trajectory Eval 里一定要看工具调用顺序。

6. Safety Eval：有没有守住安全边界

只读工具和写操作工具必须分开评估。

查询订单错了，是准确性问题。

自动退款错了，就是事故。

所以对于退款、改签、提交报销、发送通知、修改资料这类高风险工具，必须评估：

复制代码

是否经过权限校验
是否经过用户确认
是否有幂等控制
是否有操作审计
是否能回滚或补偿
是否存在越权调用

比如用户说：

帮我看看这张票能不能改签。

Agent 可以查询改签规则，可以推荐改签方案。

但它不能在用户没有明确确认的情况下直接执行改签。

这类评测不能只算准确率，而要当成治理指标。

六、一个更真实的 Agent 评测例子

假设我们有一个电商客服 Agent，用户输入：

我昨晚买的蓝牙耳机还没发货，帮我看看能不能催一下。

如果只做 Output Eval，标准答案可能是：

你的订单目前还未发货，我已经帮你查看，建议等待商家处理或联系人工客服。

这个答案看起来还行。

但如果做 Trajectory Eval，我们会关注它的完整过程：

复制代码

Step 1：识别任务类型 = 订单发货咨询
Step 2：确认用户所说的"昨晚买的蓝牙耳机"是哪一笔订单
Step 3：调用订单查询工具，查看订单状态
Step 4：调用物流或发货状态工具，确认是否出库
Step 5：判断是否满足催发货条件
Step 6：如果支持催发货，询问用户是否需要提交催发货请求
Step 7：在用户确认后，再调用催发货工具
Step 8：生成最终回复

然后逐项评分：

评测项	关注点	示例
意图识别	是否识别为发货咨询	不能识别成退款申请
工具选择	是否调用订单和发货状态工具	不能只靠模型猜
参数正确性	订单号、商品名称、用户 ID 是否正确	不能查到另一笔订单
调用顺序	是否先查订单再判断能否催发货	不能直接提交催发货
证据使用	是否基于订单状态回复	不能编造发货状态
安全边界	是否在用户确认后才提交催发货	不能擅自操作
最终输出	回复是否清晰、可执行	不能只说"请耐心等待"

这样评测之后，我们就能知道 Agent 到底好在哪里、差在哪里。

如果最终答案错了，但轨迹显示工具调用都对，只是最后总结偏了，那优化方向是生成 Prompt 或模型能力。

如果最终答案错了，轨迹显示根本没查订单工具，那优化方向就是工具选择策略。

如果工具选对了但参数错了，那应该优化 Schema、参数抽取和多轮状态管理。

如果 Agent 没有经过用户确认就提交催发货，那问题就不是回答质量，而是安全流程设计。

这就是 Trajectory Eval 的价值：它不只是打分，而是帮助定位问题。

七、Trajectory Eval 不是替代 Output Eval，而是补上盲区

这里有一点要特别说明：不是说 Output Eval 没用了。

Agent 评测不是二选一，而是分层组合。

比较合理的方式是：

复制代码

最终结果评测：回答是否正确、完整、符合用户目标
过程轨迹评测：工具、参数、顺序、证据、效率、安全是否合理
组件专项评测：RAG、Memory、Tool、Planner 单独测试
线上反馈评测：真实用户是否采纳、是否追问、是否人工纠错

Output Eval 更接近用户视角。

Trajectory Eval 更接近工程视角。

组件评测更接近开发视角。

线上评测更接近业务视角。

这几层合起来，才是一个真正可用的 Agent 评测体系。

只看最终输出，很容易把 Agent 当成一个聊天机器人。

但看执行轨迹，才会发现它其实是一个由模型、工具、数据、状态、权限和流程共同组成的系统。

八、Trajectory Eval 常见的几个坑

1. 不要把轨迹评测做成"死记路线"

有些团队做 Trajectory Eval 时，会要求 Agent 的每一步都和标准流程完全一致。

这在简单流程里可以，但在复杂场景里容易误伤。

因为 Agent 的合理路径可能不止一条。

比如旅游规划任务，可以先查天气再查酒店，也可以先定预算再筛选交通。只要关键依赖没有错，最终结果可靠，就不一定非要完全一样。

所以轨迹评测应该关注关键约束，而不是机械规定每一步。

2. 不要只让 LLM Judge 打一个总分

LLM Judge 很方便，但如果只输出一个 8 分、9 分，价值不大。

更好的方式是让它分维度评价：

复制代码

工具选择：是否正确
参数传递：是否准确
执行顺序：是否合理
证据使用：是否充分
最终回答：是否符合任务目标
安全边界：是否遵守

这样才方便开发人员定位问题。

评测的目的不是拿一个漂亮分数，而是知道下一步该优化哪里。

3. 不要忽略失败样本

评测体系最有价值的不是证明 Agent 有多强，而是发现它在哪些情况下不稳定。

失败样本应该沉淀下来，进入回归测试集。

以后改 Prompt、换模型、调整 Tool Schema、修改 RAG 策略，都要重新跑这些用例。

这就是 Agent 的回归测试。

没有回归测试，Agent 迭代很容易出现一种情况：新版本解决了一个问题，又悄悄弄坏了另一个能力。

4. 不要只评测 Demo 场景

Demo 场景通常是最友好的：问题清晰、数据完整、工具正常、用户配合。

但真实生产环境不是这样。

真实用户会省略信息，会表达不清，会中途改需求，会问权限外的问题，业务系统也可能超时、返回空数据、返回异常数据。

比如用户可能会这样问：

复制代码

"帮我查一下那个订单。"
"刚刚那张票还能改吗？"
"这个能报销吗？"
"你直接帮我退了吧。"
"算了，换成明天下午的。"

这些话都很真实，也都很容易让 Agent 出错。

所以 Agent 评测一定要覆盖脏数据、异常流、多轮追问和权限边界。

Agent 能跑通 Demo，不代表能上线。

九、我理解的 Agent 评测核心：不是打分，而是治理

很多人一听评测，就想到排行榜、分数、准确率。

但在企业 Agent 里，评测真正的价值不是给 Agent 打一个漂亮分数，而是让它变得可控。

可控意味着：

复制代码

你知道它为什么这么回答
你知道它调用了哪些工具
你知道它用了哪些数据
你知道它有没有越权
你知道它失败在哪一步
你知道下次改哪里能变好
你知道升级模型后有没有退化

这才是 Agent 从 Demo 走向生产的关键。

普通 ChatBot 可以靠"感觉还不错"上线试试。

但企业 Agent 不行。

因为 Agent 一旦接入业务系统，就不再只是生成文本，而是在参与真实流程。

它可能查订单、改签车票、提交申请、发送通知、生成报告、影响人工决策。

所以 Agent 的评测也不能只停留在"回答像不像"。

它必须进入过程，进入工具，进入参数，进入权限，进入证据链。

十、总结

Agent 评测不能只看最终答案。

Output Eval 解决的是：

最后回答对不对？

Trajectory Eval 解决的是：

它是怎么得到这个答案的？这个过程可靠吗？

对于真正要落地的企业 Agent 来说，后者越来越重要。

因为 Agent 的风险往往不在最后一句话，而在中间那几步：工具有没有选错，参数有没有传错，数据有没有查错，权限有没有跳过，证据有没有用上。

一个成熟的 Agent 评测体系，应该同时包含：

复制代码

Output Eval：评估最终回答
Trajectory Eval：评估执行过程
Component Eval：评估 RAG、Tool、Memory、Planner
Regression Eval：评估版本迭代是否退化
Online Eval：评估真实生产表现

如果说 Prompt 决定了 Agent "想怎么做"，Tool 决定了 Agent "能做什么"，那么 Eval 决定了 Agent "做得靠不靠谱"。

Agent 真正从 Demo 走向生产，不是多接几个工具，也不是多写几个提示词，而是要让整个执行过程可观测、可评测、可回放、可治理。

最终答案只是结果。

执行轨迹，才是 Agent 工程化里最值得盯住的地方。