为什么轨迹评价必须先回答三个问题？
- 起点: 持续进化的起点是评估，系统若不知道任务是否完成、也不知道哪一步造成成败，语言模型生成的反思只能是猜测;
- 三个问题: 事情是否办成了，是否以允许的方式办成，是否让用户舒服;
- 结构: 对应结果验证器、过程验证器、质量验证器三层;
- 优先次序: 结果层来自环境真实状态，最应优先建立;
结果验证器回答什么？
- 职责: 判断事情是否真的办成;
- 证据: 测试结果、数据库状态、工具返回;
- 例子: Coding Agent 运行测试、类型检查与性能基准；退款 Agent 查询订单状态和实际退款金额;
- 可靠性来源: 信号来自环境中的真实状态，通常比模型对自己行为的描述可靠;
过程验证器回答什么？
- 职责: 判断是否以允许的方式办成;
- 反例一: 删除失败的测试用例也能让测试通过;
- 反例二: 口头承诺“我们会在 7 天内退款，请耐心等候”也可能得到暂时的满意反馈;
- 检查对象: 业务规则、权限与动作序列;
- 可分界的条件: 政策库、权限表与动作轨迹均可精确表达，因此这一层同样能由代码判定;
质量验证器回答什么？
- 职责: 判断是否让用户舒服;
- 典型维度: 客服是否耐心、是否提供合规范围内的变通方案；研究报告是否抓住关键证据；生成文本是否自然简洁;
- 地位: 这些维度不影响事情办成与否，但对用户体验有影响;
- 手段: LLM-as-a-Judge 加预先定义的 Rubric，要求逐项给分并引用轨迹证据;
三层如何映射到具体评价维度？
| 维度 | 验证问题 | 主要证据 | 所属层 |
|---|
| 任务结果 | 用户的核心诉求是否得到解决 | 最终环境状态、工具结果 | 结果层 |
| 规则遵从 | 是否违反政策、权限或必要流程 | 政策库、动作轨迹 | 过程层 |
| 隐私边界 | 是否泄露不应提供的信息 | 回复文本、数据访问记录 | 过程层 |
| 事实可靠性 | 陈述是否有知识或工具结果支持 | 引用来源、工具返回 | 横跨两层 |
| 承诺—行动一致性 | 声称完成的操作是否真实发生 | 回复与工具日志对照 | 过程层 |
| 表达质量 | 是否自然、简洁，避免重复与模板化 | 对话全文、语言 Rubric | 质量层 |
| 合规变通 | 原方案不可行时是否找到允许的替代路径 | 用户目标、政策与后续动作 | 质量层 |
- 维度示例: 客服 Agent 的三层可展开为这七个可逐项评分的维度;
为什么“事实可靠性”横跨两层？
- 可核验部分: 能与工具返回逐一比对的事实由代码核验;
- 不可核验部分: 其余陈述交由 Rubric 判断;
- 设计含义: 同一维度可以按证据可及性拆分给不同验证器，不必强行归入单层;