没有测试集的 Agent，都是在赌博

传统软件测试是"输入 A 应该输出 B"。Agent 不适用——同样的输入，它可能给出三种不同的正确回答。

但这不代表不能测。

第一步：建立任务集

从真实使用中收集 50 到 100 个任务，覆盖典型场景和边界情况。每个任务记录：输入、期望的关键要素、绝对不能出现的内容。

关键是"关键要素"而不是"标准答案"。比如"帮我把这份周报改得更简洁"，标准答案是开放的，但关键要素可以定义：字数减少 30% 以上、保留所有数据、不添加原文没有的结论。

第二步：分层判定

我们用了三层判定，成本和严格度递增：

规则层（自动，成本近似为零）

检查格式、长度、是否包含必需字段、是否出现禁用词。这一层能拦住 40% 的问题。

模型判定（自动，成本低）

用另一个模型当裁判，给它任务描述、实际输出、判定标准，让它打分并说明理由。

裁判模型要比被测评的模型强一档，否则判断不准。我们试过用同级别模型当裁判，它经常给出"看起来不错"的敷衍结论。

人工抽检（成本高，抽样做）

每天抽 20 条，人工标注通过/不通过/需修改。这是校准前两层准确率的基准。

第三步：盯住三个指标

• 通过率：一次就符合要求的比例。这是最核心的指标。
• 严重错误率：出现事实错误、越权操作、泄露信息的比例。这个必须为零，有一个就要停下来查。
• 人工修正率：用户手动改过的比例。这反映了"能用但不好用"的那部分。

我们上线后通过率 68%，人工修正率 22%。两个月优化到通过率 84%，修正率 9%。提升主要来自提示词的具体化，而不是换模型。

一个容易忽略的点

测试集要跟着需求变。产品加了一个新功能，测试集里没有对应任务，那这个功能的实际质量就是未知的。

我们的做法是：每次需求评审时，同步问一句"这个功能怎么测"。答不上来的需求，先别做。

最后

做 Agent 最忌讳的是"感觉变好了"。人是会被最近几次成功的案例影响的，你昨天看到三个漂亮的结果，就会觉得它变强了。

测试集的价值就是把"感觉"变成"数字"。数字不好看，但至少是真的。