6. Task Outcome 与 Success Criteria

核心工程 · 2～3 小时

学习目标

把自然语言需求变成可判定成功条件
设计 Required/Forbidden Effects
理解 Binary Success、Partial Progress 与 Composite Score

前置知识

第 4～5 章

本章产物： 完成一份 20 Case 的 Success Criteria 表。

6.1 Success Criteria 是 Eval 的核心契约

一个 EvalCase 最重要的不是 Prompt，而是：

如果 Agent 成功了，世界应该变成什么样？

模板：

goal: "取消订单 123"

required_effects:
  - order.status == CANCELLED
  - refund.amount == expected

forbidden_effects:
  - other_orders_changed == true
  - refund.amount > paid_amount

user_communication:
  - mention cancellation success
  - mention refund timing

6.2 Binary Success 什么时候最好

当任务有明确可验证终态时，Binary Success 很有价值：

测试是否通过；
数据库是否符合目标；
文件是否产生；
页面是否完成操作。

它简单、可解释、适合 Release Gate。

6.3 Partial Progress

长任务可以记录 Progress，但一定要避免“靠完成容易步骤刷高分”。

建议 milestone 必须和真实业务进展对应，而且最终成功仍单独报告。

6.4 Composite Score 的风险

假设：

State 0.5
Answer 1.0
Safety 1.0

平均 0.83 看起来不错，但如果 State 是核心业务结果，这个任务其实应该 FAIL。

所以优先使用：

hard gates + secondary metrics

而不是无脑加权平均。

6.5 Critical Cases

有些 Case 数量少，但风险高：

大额资金；
删除生产资源；
医疗/法律高风险决策；
管理员权限；
PII。

这些 Case 应建立独立 Gate：

critical_success == 100%
critical_safety_violation == 0

6.6 Negative Case

不仅测“应该做什么”，也测“应该拒绝什么”。

例如：

用户没有权限 → 不执行
缺少确认 → 请求确认
关键参数不明确 → 澄清

一个只会“积极执行”的 Agent 并不是高质量 Agent。

6.7 验收问题

为什么 Composite Score 可能掩盖致命失败？
Required Effect 与 User Communication 为什么要分开？
Critical Case 应该怎样进入 Release Gate？

本章依据

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