# M04 评测、观测与调试 > 本章产出：一套区分机制正确性、任务能力和系统性能的评测协议。你的Agent从这一章起不能只靠演示证明有效。 ## 1. 第一个评分器先别用LLM 对于退款任务，先查账本：是否存在被授权的退款操作，金额是否正确，是否只有一笔。同样，Coding Agent是否修复问题，要由独立测试执行结果决定，不是看最终回复是否出现“测试通过”。 任务结果、执行轨迹和最终文本是三种不同的证据。结果正确不代表没有越权；轨迹看起来合理不代表账本已改变；措辞流畅不代表问题解决。Anthropic的Agent评测文章对这几个对象作了清楚区分，本课程据此把评分器拆开，而不是做一个万能“好不好”判分Prompt。[S05](../../references/SOURCES.md#s05) ## 2. 三层测试，各自回答一个问题 **确定性测试**使用脚本模型与受控工具：预算是否扣减、审批是否绑定、重复事件是否去重、崩溃后是否重复写。这层不评价自然语言理解。 **任务评测**用真实模型处理固定业务请求：是否选择合适工具、找对证据、合理澄清、完成目标。每次运行都重置环境，记录模型配置与预算。任务之间不能共享上一次退款后的数据库。 **系统基准**固定或回放模型/工具延迟：测排队、吞吐、取消和资源占用。它能隔离系统机制的性能，但不代表真实供应商延迟或任务成功率。 离线基准、脚本演示、真实模型实验必须在页面和报告上显示不同标签。模型调用失败或预算耗尽仍保留在分母，不能删掉“不好看的试次”。 ## 3. 数据集切分与泄漏 课程提供学习集、开发集和结业挑战说明。静态压缩包中的答案对持有者可见，所以这些不是对抗性的隐藏考试。网页可以默认收起答案，但不能声称客户端代码能保护秘密测试。 真正对比策略时，你应先用学习集理解接口，再用开发集调参，最后生成并冻结新的任务或由另一人准备未见案例。不要一边观察测试失败一边修改Prompt，然后仍把最终结果叫作无偏测试成绩。 订单号不同但政策分支完全相同的两个任务可能高度相关。随机按行切分容易泄漏结构；可以按政策组合、故障类型或业务场景分组。代码修复任务还要避免训练/评测使用同一个补丁或同一隐藏测试。 ## 4. 一组可以复算的指标 假设100次任务试验中成功72次，总模拟费用18个成本单位，那么成功率为72%，每个成功任务成本为0.25单位。若只把成功试次的费用算入分子，会掩盖失败尝试消耗。 工具非法调用率的分母必须说明：是全部候选调用、真正执行的调用，还是任务数？同一任务提出十次非法动作与十个任务各一次不是同一指标。 延迟至少区分入队到完成、开始执行到完成、首次反馈时间。P95计算方法必须写明，本课程离线工具采用最近秩定义：排序后取第`ceil(0.95n)`个值。样本很小时P95不稳定，不能用十个任务宣称生产尾延迟。 对同一任务多次试验，可以报告每次成功率，以及“k次里至少一次成功”和“k次全部成功”。在独立且成功概率相同的简化假设下，它们分别是`1-(1-p)^k`与`p^k`；真实Agent试次往往相关，不能不加说明地套公式估计可靠性。 ## 5. LLM-as-judge用在哪里 当任务需要判断解释是否清楚、证据是否支持某个复杂陈述时，模型评分器可以辅助。但评分器也会受表达风格、长度、候选顺序和提示注入影响。先定义明确rubric，再与人工标注样本校准。 对A100，退款金额是否正确用代码判断；回答是否清楚说明下一步可以用人工rubric或校准后的模型判断。不要让模型评分器读取另一个租户的完整记录，也不要把被测回答拼成评分器的高优先级指令。 一个务实的评分输出是多个字段：`goal_met`、`policy_compliant`、`unauthorized_effect`、`grounded_answer`、`needs_review`。高风险违规可以一票否决，不被“文风得分高”平均掉。 ## 6. Trace不是把所有文本打印出来 以一次run为根Span，模型调用、检索、工具、数据库或审批等待可形成子Span。记录parent关系与时间，才能看出关键路径；并行子Span的时长不能简单相加成总耗时。OpenTelemetry的Trace概念是对照来源，课程JSON只是一种最小教学格式。[S32](../../references/SOURCES.md#s32) 观测字段建议包含：run/step/call/operation标识、尝试次数、开始结束时间、状态、错误分类、输入输出引用、模型配置、预算变化。敏感信息需要脱敏，令牌和原始凭证永不进入Trace。 对审计、恢复和分析使用不同的数据保留策略。用于性能诊断的Span可以采样；决定退款是否已执行的业务记录不能因为采样而消失。UI断线补发需要有稳定的事件序号，M06会单独设计。 ## 7. Bad Case分析要找到可改变的变量 拿到失败，不要只写“模型不够聪明”。先定位：任务定义是否含糊？正确证据是否被召回？是否进入上下文？工具是否容易误用？执行器是否错误恢复？评分器是否误判？ 例如模型一直查询同一个订单，可以检查工具返回是否缺少物流字段、错误信息是否要求它重复查询、循环是否丢失上一轮结果。修复工具返回结构可能比换更强模型更便宜。 对每个改动保存一个最小反例。只改变一个主要因素后跑对照；若同时换模型、Prompt、检索器和预算，即使结果提升也无法解释原因。开放系统不能总做到完美实验控制，但必须诚实记录混杂因素。 ## 8. 一份合格实验报告 报告应包括任务与环境版本、成功定义、基线、改动、预算、运行配置、样本数、失败类别、汇总结果和局限。若有多次随机试验，可按任务分组进行重采样估计区间，避免把同一任务的相关重复当作完全独立样本。 至少展示一例“整体变好但某类任务退步”的案例。把未完成、超时、拒绝、评分器异常分别统计。评分器自身错误的试次可以标记为不可判定，但不能悄悄当成功或直接删除。 本课程可选外部对照为τ-bench，但不将课程原创任务冒称为官方Benchmark，也不在不同版本间直接比较分数。[S20](../../references/SOURCES.md#s20) ## 9. 实验交付 L04提供已知结果的合成试次与参考指标函数。先验证你能复算指标，再用前面完成的Agent产生自己的轨迹。最低交付是一份机器可读结果JSON、一张失败分类表和一页分析，不需要先搭复杂仪表盘。