30 秒判断：Agent 是带智能的系统，产出不是确定性的。因此不能再用"跑一遍、看结果对不对"来衡量系统功能质量，必须改用统计方式——跑多次、看通过率和分布；测试工作量因此上升一个数量级，必须自动化；而自动化评测又必须先有用例集与金标准。这三步推下来，Agent 开发就变成了 "测试驱动升级版" ：不是先写代码后补测试，而是先把"测什么、什么算对"定义清楚。
适合谁读：正在做 Agent / 大模型应用、觉得"效果时好时坏但说不清哪里坏"的人；准备给 Agent 建评测体系的人；以及从传统软件测试转过来、发现老方法不灵的人。
结构速览：§1 为什么必须换方法；§2 五步流程；§3 三条配套纪律；§4 用例的两个角色；§5 常见误用；§6 一页速查。
证据标记：✅ 实测＝有可复现实验数据支撑；🤔 推断＝由实测或机制推出的判断。没标的多为框架性表述。
先交代几个名词：
- 用例：一次可复现的测试。它不只是"问什么"——输入可以是一个提问、一个任务，或一组条件（材料、配置、上下文）；一条完整的用例还要写清"这次要验什么"。
- 金标准：这条用例"什么算对"的定义，是用例里最关键的期望部分。
- 用例集：覆盖各类问题与场景的一组用例。
- 判官：拿金标准去判答案是否满足的角色或程序；可以是一段程序、一个 LLM，也可以是人。
0. 结论先行
| 问题 | 结论 |
|---|---|
| 为什么老办法不灵 | Agent 的产出不确定，单次结果可能只是运气 |
| 换成什么 | 统计方式：跑多次，看通过率与分布 |
| 代价是什么 | 测试工作量上升一个数量级——一个用例要跑 N 次，还要跨模型、跨配置、跨版本对照 |
| 所以必须做什么 | 自动化评测；而自动化必须先回答"测什么"和"什么算对"，也就是用例集与金标准 |
| 最后变成什么 | 测试驱动升级版：先把用例集与金标准立起来，再让它驱动架构决策与代码优化 |
1. 为什么 Agent 需要"测试驱动升级版"
1.1 确定性系统的测试，套不到 Agent 上
传统软件开发的测试，测的是确定行为：输入定了，输出就定了。同一个输入跑一百遍，结果一样；测试通过一次，就可以认为它对。
Agent 不一样——它是一类带智能的系统：
- 同一个问题、同一份材料，跑两遍，结果可能不一样。
- 同一个答案，"对不对"也往往不是一个布尔值。 它可能覆盖了要点但漏了扩展主题；可能内容对但引用锚不住；也可能引用了原文，却把两篇文章的关系说成同一套框架。
这两件事叠在一起，传统测试的两个前提就都没了： "重复执行结果一致" 和 "对错是二值的" 。
1.2 换成统计，测试量就上了数量级
既然单次结果不可靠，就不能用"跑一遍、看结果对不对"来衡量系统功能质量——单次通过可能只是运气，单次失败也不代表系统不行。
衡量这类系统，必须引入统计方式：跑多次、看通过率与分布，用"稳定通过"代替"碰巧通过"。
而一旦改用统计方式，测试工作量就是数量级的上升：
- 一个用例要跑 N 次；
- 还要跨模型、跨配置、跨版本做对照；
- 并且每次跑都要能复现——不然数字没法解释。
1.3 人工跑不动，自动化又必须先有金标准
靠人工跑，既贵又不稳：人会疲劳、标准会漂移，而且自己抽读还会自我说服。
一个真实的例子：我们做过一次实测，人工抽读认为答案通过，换成按事实边界逐条核的判官，判为失败。这两者的差异本身就是一条教训——人看一遍觉得"挺像"，和按判据核对一遍，是两件事。
所以测试必须自动化。
但自动化评测又不能只是一段"跑得动"的脚本——它必须先回答两个问题：
- 测什么？ → 用例集（输入是什么、这次要验什么）
- 什么算对？ → 金标准
没有它们，自动化只能告诉你"程序跑完了"，判不了"结果对不对"。
1.4 结论
把上面几步串起来：
Agent 是带智能的系统 → 产出不确定 → 必须用统计方式衡量质量 → 测试量数量级上升 → 必须自动化 → 自动化必须先有用例集与金标准 → 测试驱动升级版。
"升级版"的意思不是"多写测试"，而是顺序反过来了：不是先写代码、后补测试，而是先把用例集与金标准立起来，让架构决策和代码优化既有依据、也有验证器。
2. 五步流程
| 步骤 | 做什么 |
|---|---|
| ① 产品定义 | 回答"这是什么产品、给谁、解决什么、明确不做什么"；用户 / 产品视角第一性，工程约束刻意降权。 |
| ② 需求 / 问题空间 | 从产品定义正推"用户会问哪些类型的问题"，而不是从已有实现反推；只谈问题域，不混解决域。 |
| ③ 用例 + 金标准 | 各类问题都要有代表用例；金标准要能回答"满足什么即通过、什么情形判失败"；含概率指标与判定规则。 |
| ④ 架构决策 | 只在宏观层判断：知识承载层要背多少"全"的责任，智能执行层要背多少；不追最新范式，只对问题形态。 |
| ⑤ 实现 + 统计判质量 | 按用例集执行，用统计指标判断系统质量。这一步不是一次性的终点检查，而是一个迭代过程。 |
第 ⑤ 步展开说：每一轮失败都要走"红 → 根因定案 → 探针 → 修复 → 回归"；新暴露的问题既可能回填用例（回到 ③），也可能推翻第 ④ 步的架构判断——比如发现瓶颈不在检索，而在输出预算；或者发现"取齐"缺的是结构，而不是模型。
所以第 ④ 步不是一次定终身：架构决策必须能被第 ⑤ 步的失败模式推翻并重做。
一句提醒：顺序不能倒，但可以回环
顺序不能倒：先定义问题、再定验收、最后才定架构。反过来做，就会变成"技术上能做什么，产品就做什么"。
但顺序不能倒不等于只能走一遍——第 ⑤ 步的失败会带着证据回流到 ③ / ④，整个流程是一个可以反复回环的循环。
3. 三条配套纪律
这三条不是第 ⑤ 步之外的另一组方法，而是前面五步的护栏——每一条都能指回它保护的那一步。没有它们，流程看起来还是走完了，但结论很可能是错的。
| 纪律 | 落在哪一步 | 内容 | 为什么 |
|---|---|---|---|
| 基础件人工复核 | ③ 用例 + 金标准 | 金标准、判官提示词、系统提示词、工具行为契约——AI 可起草、可提议，但不得自审自合入。 | 基础件错了，③ 之后的所有统计都在朝错误方向优化。AI 看不见自己的盲区，自检无效；出现"补丁摞补丁"，往往是少了这步。 |
| 根因闭环 | ⑤ 实现 + 统计判质量 | 红 → 根因定案 → 先补"该不变式的代表探针"（仍红）→ 机制修复（绿）→ 全量回归。 | 探针必须钉住唯一根因类；每个根因类只留代表用例，防套件膨胀。 |
| 概率指标 + 硬线 | ③ 定义 ＋ ⑤ 执行 | 单用例跑 N 次、≥K 次满足判据才算通过；硬线（引用无伪证、来源可回锚、遗漏透明、边界合规）零违反。 | 模型每次生成都带随机性：同一个问题、同一份资料，跑两遍结果可能不一样——单次通过可能只是运气好，单次失败也不代表系统不行。所以要跑 N 次、要求 ≥K 次达标，用"稳定通过"代替"碰巧通过"。但硬线不能按比例算：引用造假、来源对不上、该声明的遗漏没说、越界——只要出现过一次就不通过，不能用平均分把它盖过去。 |
4. 用例的两个角色
用例集建起来之后，它在整个开发过程里同时扮演两个角色：
它暴露的失败模式，是架构调整与代码优化的依据——告诉你哪里不对、该往哪改。
它的通过率，是这两类改动的验证器——告诉你改完到底有没有变好。
两者是一对：失败模式负责指方向，通过率负责判结果。只有前者，你改完不知道有没有变好；只有后者，你只知道分数低，不知道低在哪。
需要补一句：架构决策的依据不止失败模式一处
失败模式只有在系统能跑之后才存在。如果把它当成唯一依据，冷启动阶段就没法做架构决策了——可第一版架构又必须先建出来才能跑。
所以更准确的说法是：
第一版架构先由产品定义、问题形态、数据形态与硬约束推出；失败模式负责修正它。
失败模式是"最直接、最能证伪"的一类证据，但不是唯一来源。
5. 常见误用
| 误用 | 问题出在哪 |
|---|---|
| 把"跑一遍通过"当通过 | 单次结果可能只是运气；没有多次统计，通过率不可信。 |
| 把硬线平均掉 | 引用造假、来源对不上、该声明的遗漏没说——这些是底线问题，不能用"总体平均分不错"盖过去。 |
| 用例集只堆数量、不凑类型 | 每类问题都要有代表用例；类型不全，失败模式就漏，架构决策的依据也跟着漏。 |
| 让 AI 自审自合金标准与判官口径 | AI 看不见自己的盲区；基础件必须有人工复核这一步。 |
| 把"测试通过"当成项目终点 | 用例集本身也会过时、会漏类型；它是活的资产，要跟着失败样本一起长。 |
6. 一页速查
为什么要升级：Agent 带智能 → 产出不确定 → 单次结果不可信 → 必须统计 → 测试量数量级上升 → 必须自动化 → 先要有用例集与金标准。
五步：产品定义 → 需求 / 问题空间 → 用例 + 金标准 → 架构决策 → 实现 + 统计判质量（可回环，能推翻第 ④ 步）。
三条纪律：基础件人工复核 / 根因闭环 / 概率指标 + 硬线。
用例的两个角色：失败模式是依据，通过率是验证器；第一版架构由产品定义、问题形态、数据形态与硬约束推出。
一句话：先定义"什么算对"，再谈"怎么建"。
