用户说：“A1042 的质量问题已经确认，帮我申请退货。”助手回答：“退款已成功，请留意到账。”从语气看，这是一条干脆的回复；打开退款账本，却没有对应记录。模型完成了写作，没有完成用户委托。
评测首先要解决的是这种错位：我们希望系统完成什么，用什么证据确认它完成了。分数只是把判断汇总成数字。成功定义错了，增加样本、换更强的裁判，都只会更稳定地测量错误的目标。
把一句用户要求拆成可核验的结果
本系列使用虚构订单 A1042。它属于租户 shop-a、用户 u-1，实付 29900 分，即 299 元。每条案例独立提供初始快照；不能拿上一篇文章里某个阶段的订单状态推断本次评测状态。售后政策 v3 规定：质量问题已核实、退款金额未超过可退余额、获得有效审批后，才可以执行退款。
“申请退货”和“立即执行退款”也不是同一个目标。如果用户只希望提交申请，成功条件应是生成有效申请并说明待审批状态，不能把擅自退款算作更好的完成。评测者先把意图和允许的动作界定清楚，再选择技术指标。
假设本次任务已包含有效审批，成功条件可以是：订单 A1042 新增一条 29900 分的退款记录，可退余额减少同样金额，没有修改其他订单，答复与最终状态一致。账本用于判断是否退款，审批记录用于判断是否有授权，回复用于判断用户是否被准确告知。三个来源各自回答不同的问题。
| 观察结果 | 可以证明 | 不能证明 |
|---|---|---|
| 回答包含“已退款” | 模型输出了这个声明 | 外部系统已执行 |
| Trace 出现 refund 工具调用 | 系统尝试过该动作 | 动作被接受且只执行一次 |
| 工具返回成功 | 工具报告成功 | 工具实现及账本没有错误 |
| 受信任账本与审批记录一致 | 业务结果和授权链符合断言 | 所有未覆盖场景都安全 |
这里的判定依据常被称为 oracle。它不一定是一句标准答案，也可以是数据库查询、状态差异、人工确认的事实集合。oracle 也会写错，所以要能回到原始证据复核。
一次失败可能来自五个不同位置
模型可能没有理解“申请”的含义；检索器可能取出过期政策；工具调用可能使用错误订单号；Runtime 可能在重试时重复执行；最后的回复也可能把“待审核”说成“完成”。只评最后一段话，会把这些问题混为“回答质量差”。
因此我们同时保留组件观察和端到端观察。组件评测固定上游输入，例如直接给生成器正确政策，检查它能否说明条件。端到端评测保留真实链路，看检索、决策、执行组合后是否完成任务。前者帮助定位，后者确认组合效果。各组件分数都高，也不意味着组合一定可靠：字段约定不一致就可能让交接失败。
单元测试可以检查金额转换函数；工具集成测试可以检查协议参数是否传入正确方法；模型决策评测才会检查它是否选择退款工具。固定调用一次函数的代码并没有测试工具选择能力。阅读任何评测报告时，都应先找被测系统究竟接收了什么输入、允许做哪些决定。
硬条件和软质量为什么要分开
有的回答比较啰嗦，但信息正确；有的回答很流畅，却退错了用户的钱。若把语气、延迟、授权和金额加权成一个平均分，后者可能依靠漂亮的文字过线。我们需要先执行必须满足的约束，再比较满足约束的结果质量。
下面的最小例子刻意只使用已经核验的业务记录，而不搜索回复里的关键词：
# 这是离线教学数据，实际系统应从受信任服务读取这些字段。
observation = {
"approved": True,
"refund_rows": [{"order_id": "A1042", "amount_minor": 29900}],
"unauthorized_reads": 0,
}
# 指定实体和金额，避免把其他订单的成功当成本次任务的成功。
expected_row = {"order_id": "A1042", "amount_minor": 29900}
checks = {
"approval_present": observation["approved"] is True,
"exact_effect": observation["refund_rows"] == [expected_row],
"permission_boundary": observation["unauthorized_reads"] == 0,
}
# all 表示每项必须满足；文风分数无法抵消其中任何一个失败。
print(all(checks.values())) # True这个例子检查最终结果，却还没证明审批发生在执行之前。时间关系要看带关联标识的事件记录，在后面的轨迹评测中补上。一个短函数的边界应明确，而不应被描述为完整安全验证。
指标是一份契约
“任务成功率 90%”至少还有四个问题：分母包括超时吗？需要人工接管算成功吗？部分完成怎么算？使用哪个版本的政策？如果这些没有固定，两次报告中的 90% 可能完全不可比较。
我们为指标记录名称、版本、输入、判断规则、分母和缺失处理。对于本系列自动完成率，Agent 超时属于未完成；评分器服务故障属于未知，需要单列覆盖率，而不是偷偷删掉。人工接管可以计入“最终解决率”，但不能同时被算成“全自动完成率”。
能力评测关注在明确资源条件下能否完成；生产可靠性还关心正常运行中有多频繁完成。放宽到一百次尝试可能改善前者，却不符合用户等待时间。报告应连同时间、工具次数、Token 和成功任务成本一起阅读。
从离线评测走向线上反馈
离线数据让我们反复比较相同任务，线上观察帮助发现数据集中没有的新问题。两者之间需要人工复核：用户点踩可能是政策本身不受欢迎，也可能真是系统答错；未经确认的反馈不能直接变成参考答案。
本系列会沿着这条链展开：先建立样本和判定依据，再解释指标与实验，然后分别评 Prompt、RAG、工具和 Agent，最后把它们放入可追溯的生产流程。我们希望回答的不只是“这个版本多少分”，还有“它为什么得这个分，失败是否会伤害业务，下一步该改哪里”。
继续阅读与配套材料
完整示例、运行方式和验证边界见评测实验指南下载。本系列的订单、政策、金额和实验数据均为教学示例。