AI Agent 时代的测试与验收，从 BDD 说起

测试 AI Agent，难在哪？传统测试有个固有的前提，同样的输入，就该有同样的输出。断言把两条写死，一条对了另一条就错。这个前提在 agent 身上没办法使用。同一个问题，模型这次和下次的回答不同，工具调用的路径不同，连要走几步都可能不同。你想断言”回复必须精确等于这句话”，没有任何意义。

所以测试 agent 要先换一种想问题的方式。从”验证实现对不对”换成”验收行为该是什么样”。这正是 BDD 的老本行。

BDD 是什么？

BDD，行为驱动开发，2006 年由 Dan North 提出。它不关心代码内部长什么样，只关心系统在用户面前表现出什么行为。测试用 Given/When/Then 三段式写成自然语言，业务、开发、质量三方一起写，写出来的既是需求也是验收标准。它最重要的一个转变，是把”测试”从验证工具升格成”规格”。测试回答代码对不对，规格回答行为该是什么。

一个 Gherkin 场景长这样：

导出少于一万行的数据
Given 用户正看着一个有 8432 行的仪表盘
When 用户点击"导出 CSV"
Then 文件在 5 秒内开始下载
And 文件里的行数等于 8432

业务人员不用懂代码就能读，能评审，甚至能自己写。

为什么 agent 时代 BDD 反而更合适？

第一，BDD 关心行为契约，实现细节它不管。agent 是概率系统，你没法规定它每一步怎么做，但你可以规定它达成什么结果。Given/When/Then 把推理空间切成几段，只约束边界不规定路线，agent 自己去找路。

第二，验收标准正在变成 agent 的 system prompt。我读到过一个说法，验收标准就是新的 system prompt。我发现 agent 经常会用不符合实际业务的方式通过测试（因为它的目标就是要通过测试），只要测试能改，它总会找到最省力的变绿方式，典型的就是悄悄把”所有符合条件的商品都打折”改成”至少一个商品打折”。Gherkin 把这个漏洞堵上了。测试写在代码之前，用业务语言，产品负责人签字，存在大家都能读的文件里。

第三，场景既是测试，也是 agent 的执行蓝图。给 agent 一段 Gherkin，等于给了它一段明确的行为规格，它照这个写实现，跑不过就返工。这就是 BDD 驱动的 agent 交付。

具体怎么测？

BDD 给了骨架，真正断言 agent 输出质量要靠三层：

第一层，确定性断言。工具调用对不对、参数格式对不对、必填字段有没有、延迟超没超。这些永远可以用代码写死，不该回退。

第二层，LLM 当裁判。相关性、语气、连贯、有没有编造，这些没法用 boolean 断言，就让一个模型按你写的评分细则去评另一个模型的输出。细则写得好，LLM 裁判和人类评审的一致性大约在八成到八成半。有人把 LLM 裁判的评分门槛直接写进 BDD 的 Then 步骤，比如”回复的正确性评分不低于 0.7”。这个做法来自一场 2026 年开发者大会的实测，用 Behave 跑 Gherkin 场景，用 DeepEval 做评分，测试报告里带上完整问答记录，每次推送进 CI 都跑一遍。

第三层，对抗输入。prompt 注入、越狱、边界措辞，这些要专门的红队测试去轰。Promptfoo 这类工具把注入和越狱检测做进了内置功能。

工具怎么选，看团队工作流：

工具一堆，真正决定评估质量的是一开始的测试集。Anthropic 的官方建议是，从真实用户失败里挑 20 到 50 条任务当起步，好过瞎造 200 条合成数据。真实失败暴露的是预期和实际之间的分布偏移，合成数据围着 happy path 转，漏掉的全是故障模式。正反例要平衡，拒绝用户不该做的事也要算一种正确行为。两条独立判分要和得上。每次运行要隔离状态。还要盯着评估饱和，通过率一旦到 100%，说明用例太简单，该换了。公开 benchmark 的保质期只有半年到一年，它一旦变成被刷的目标，就不再衡量你在乎的东西。这是 Goodhart 定律，LiveCodeBench 用不断更新的题目验证过。

先从五到十条黄金用例开始，真实会遇到的问题配上理想回答。确定性部分用代码断言，语义部分只挑一两个最重要的指标让 LLM 判。每次改动 prompt、工具或逻辑的提交，都触发一次评估。每周复盘一遍失效用例，从生产故障里补新的。工具选一个开源的先跑起来，DeepEval 配 pytest，或者 Promptfoo 配 CI，都可以。

验收标准是 agent 时代最便宜的边界线。它给”做对了什么”一个大家都能看懂、谁都不能偷改的定义。你不需要一个昂贵的框架，需要的只是把行为期望写成可执行、可读、有人签字的文件，然后让 agent 照着它干活。这件事 BDD 已经做了二十年，现在轮到它派上用场了。