阶段：G6-工程化与交付 ｜ 预计耗时：90 分钟 ｜ 前置：G6-01 Streaming 与 Middleware 新依赖：
pip install promptfoo（评测工具，Node 生态用 npx 跑；或先用自写脚本起步） 代码：要你自己敲成langgraph-learn/examples/g6_eval.py+evalset.yaml（30 题评测集） 90% 的学习者止步于"能跑"，你的护城河就是这一篇的数字
学习目标
- 建一个 30 题评测集（含标准答案/评分规则），跑出你 agent 的准确率数字
- 理解"评测集即验收标准"：改 prompt/换模型后重跑同集，有数字对比才敢交付
- 会做交付三件套：README + 演示流程 + 数字
核心知识
1. 为什么要评测集（三个残酷事实）
- "感觉变好了"不是证据——LLM 输出有随机性，10 次体验说明不了什么
- 没有基线就没有回归：你改 prompt 修好 3 题，很可能同时改坏 5 题而不自知
- 客户验收要数字："准确率 83%，10 道错误案例已列" 比 "效果很好" 多值 10 倍报价
2. 评测集怎么建（30 题的配比）
| 类型 | 数量 | 考什么 |
|---|---|---|
| 知识库能答 | 12 | 检索+回答正确性（有标准答案） |
| 库里没有须拒答 | 6 | 拒答能力（幻觉防线） |
| 需工具/计算 | 6 | 工具选择与执行 |
| 需审批/边界 | 6 | 该 interrupt 的有没有 interrupt |
评分规则先简单：答案关键点命中打 1，否则 0（关键词判定脚本即可）；promptfoo 支持用 LLM 当裁判（精确但费钱，先不用）。
3. 回归纪律
- 评测集冻结：改实验不改题（除非需求变）
- 每次"有意图的改动"后重跑，记录版本号 → 数字表（G5-03 的 ADR 习惯在这里延续）
- 错题分析 > 总分：每道错题写一行"为什么错"，修 3 个共性原因 > 盯着总分调 prompt
实验任务
任务 1：建 30 题评测集（40 分钟）
以你 G4-02 的知识库为题源，按上面配比出题。格式（YAML，题目/期望行为/判定关键词三列）。出题本身就是学习：出 30 题后你对"什么算对"的理解会上一个台阶。
任务 2：写评测脚本并跑分（30 分钟）
g6_eval.py：读题 → invoke agent → 按规则打分 → 输出准确率 + 错题清单。跑出第一个数字（无论多低，这就是基线）。
任务 3：一次改进闭环（20 分钟）
从错题里挑最共性的一个原因（如拒答判据太松）→ 改一处 → 重跑 → 数字变化记录（升级/降级都记）。感受"数字驱动的迭代"和"凭感觉改"的差别。
验收标准
G6 毕业检查点：四模式会选、Middleware 会写、有基线数字。
衔接下一阶段
工程能力齐了 → G7-01 实战项目三选一：把全部能力投进一个真实交付物。