2. 为什么 LLM Eval 不等于 Agent Eval

基础方法论 · 1～2 小时

学习目标

理解模型能力与 Agent 系统行为之间的差异
学会识别只测模型、不测 Agent 的伪 Agent Eval
理解 Environment 与 Side Effect 的重要性

前置知识

第 1 章
了解基本 Tool Calling

本章产物： 把一个现有 LLM 测试改造成真正的 Agent Eval。

2.1 模型是组件，Agent 是系统

一个 Agent 可能包含：

LLM
+ System Prompt
+ Tool Registry
+ Retrieval
+ Memory
+ Planner
+ Retry
+ Guardrail
+ Environment
+ User Interaction

换模型会影响 Agent，但 Agent 的最终表现也可能由 Tool schema、权限、数据质量、Planner 和环境稳定性决定。

因此：

模型 Benchmark 提升，不等于 Agent 产品提升。

2.2 一个典型误区

任务：取消订单。

错误评测

只让模型输出：

{"tool": "cancel_order", "order_id": "123"}

然后判断函数调用格式是否正确。

这只能证明模型在当前 Tool Schema 下生成了一个看起来合理的调用。

Agent 评测

应该让 Agent 在隔离环境中真正执行，然后检查：

order 123 exists
order belongs to user
policy allows cancellation
refund amount correct
order.status == CANCELLED
audit event exists
no unrelated order changed

这才是 end-to-end Agent Eval。

2.3 Side Effect 是 Agent Eval 的核心

Tool Agent 不是纯文本生成器。它可能：

发邮件；
修改日历；
删除文件；
提交订单；
修改 Kubernetes；
写数据库；
创建 PR。

因此必须同时设计：

Required Effects

必须发生什么。

Forbidden Effects

绝不能发生什么。

例如：

required:
  - order.status == "cancelled"

forbidden:
  - user.balance < 0
  - other_orders_changed == true

2.4 Agent 失败可能发生在不同层

最终“没有完成任务”至少可能是：

模型理解错目标；
Planner 拆解错；
Tool Selection 错；
参数抽取错；
Tool 本身失败；
Agent 没有正确处理 Tool Error；
环境状态不允许；
最终状态正确但回答错误；
回答正确但状态没改；
安全策略阻止了本该允许的操作。

如果只看最终答案，你几乎无法定位。

2.5 Progress 比 Binary Success 更有诊断价值

对于长任务，0/1 结果太稀疏。可以定义 milestone：

0.2 找到订单
0.4 检查取消资格
0.6 计算退款
0.8 执行取消
1.0 状态与用户通知都正确

Progress 不能替代最终 Success，但能帮助 Failure Attribution。

2.6 本章实验

选择一个包含工具调用的简单 Agent，做两套 Eval：

A：只评价最终回答；
B：检查工具调用和真实状态。

对比哪些 Case 在 A 中 PASS、B 中 FAIL。记录“False Success”。

2.7 验收问题

为什么函数调用 JSON 正确不代表任务成功？
Required Effect 与 Forbidden Effect 分别解决什么问题？
Progress Metric 为什么不能直接替代 Success？

本章依据

原理性结论优先来自原始论文和官方文档。论文中的实验数字只属于论文声明的模型、数据、环境和评测设置，不能直接外推为你的生产结论。