验证与质量保证：别让「看起来对」蒙混过关

这门课讲怎么验收 Agent 的产出。前面几门课你已经能让 Agent 跑起来、跑得久：本系列第 7 门课的 harness 循环、第 8 门课的上下文管理、第 9 门课的检查点与恢复。但「能跑完」和「跑对了」是两回事——Agent 是非确定性的，同一个任务两次跑出两条不同的路径，传统测试「给定输入 X 必走路径 Y 得到输出 Z」的假设直接失效。本课教你在这个前提下把验收做扎实：先分清「看起来做完了」和「真的做完了」，再决定验什么（终态优先，过程兜底）、用什么验（能跑出 pass/fail 的确定性验证器排第一，自由文本再上 LLM 裁判）、拿多少条用例验（从 20 条真实任务起步，不用等攒够几百条），最后动手给你自己的 Agent 搭一条评测跑道：一条任务一个循环、跑完出报告，改一版提示词就能看到分数变没变。适合已完成本系列前 9 门课的读者。本课不教通用软件测试方法论（单元测试怎么写不在这里），不教具体评测框架或平台的 API，也不涉及模型训练侧的基准测试（benchmark）建设；CI 里怎么编排评测只作工程常识提及，不展开。

课程大纲

学习目标

完成本课程后，你将能够：

说清 Agent 的非确定性怎么让传统测试的路径假设失效，以及为什么没有可跑的检查时「看起来做完了」会成为唯一信号
为一个 Agent 任务定出可测量的成功标准，并决定验终态还是在关键节点设状态检查点，而不是逐步核对轨迹
按「最快、最可靠、最可扩展」的顺序为任务挑验证器：精确匹配、脚本比对、测试套件这类确定性检查优先，并识别「验证器过严把对的判错」这类陷阱
给自由文本产出设计 LLM 裁判：写多维量表、限定输出格式、先推理后给分，并说清为什么干活的模型不该自己当裁判、被要求找茬的裁判为什么总能找出点什么
从约 20 条真实任务起步搭评测集：贴合真实分布、补边缘用例、数量优先于单条质量、留出集防过拟合，并解释为什么效应量大的早期几条用例就够看出差异
给自己的 Agent 搭一条可以反复跑的评测跑道：一条任务一个 harness 循环、确定性验证器加 LLM 裁判分层判分、记录通过率之外的时长与调用指标，亲手用它测出一次提示词修改的真实影响

前置要求

完成本系列前 9 门课，或具备等同基础
能手写以 stop_reason 驱动的 harness 循环，理解 tool_use/tool_result 配对（本系列第 7 门课）
了解检查点与效果台账的落盘机制（本系列第 9 门课；本课的评测跑道会复用 harness 循环骨架）
能读写基础的 JavaScript / Node.js 代码（第 6 课需要跟着写）

预计学习时间

约 3-4 小时，包括每课的动手练习