「你 agent 的失败就是你的回归测试集」是很好的建议。但手工构建评测数据集不是。以下是我的做法。

如果你接触过 AI 评测，你肯定听过「必须把失败转化为回归测试集」这句话。这是很好的建议。唯一的问题是，这太费时间了。我一开始是手工做的，很快就意识到这样无法规模化。尤其是现在用 coding agent 实现功能的速度如此之快。而且，盲目让 agent 来写测试也是在自掘坟墓。我的警醒时刻是：我的 coding agent 遇到一个 503 错误，在内存中找到一个 Gemini key，烧掉了我一整晚 40 美元，而不是停下来。修复只需要 2 行代码。真正的工作是确保这个 bug 在下一次 prompt 或模型变更之后永远不会再出现。 这个策略看起来是这样的（错误分析，即 Hamel Husain / Andrew Ng 的方法）： 1. 从你的 traces 中拉取 20–30 个真实会话。 2. 为每个会话标注 pass 或 fail，并记录最先出错的地方。不要用 1–5 分："fail" 是可操作的，"3" 不是。 3. 立即修复明显的问题。 4. 将剩余的失败按类型分组，并按 频率 × 严重程度 对各组排序。 5. 为每组写一个廉价的检查项。代码优先，LLM 裁判最后。 6. 每次 prompt、工具或模型变更后，重放每一组。仍然失败说明问题没修好。之后又失败说明出现了回归。 那么你能优化什么来加快这个过程呢？在我的具体实践中，我是这样用 Kitaru 管理我的评测工具链的： - 我从 Opik 拉取我的 traces，并在其 UI 中进行标注（手动完成这一步非常重要！但你需要一个简洁的 UI，让你能零摩擦地查看数据） - 拿到数据之后，我让我的 coding agent 借助 Kitaru 的 MCP server 和 skills 走完第 3 到 5 步 - 然后重放每个失败组，确保一切运行顺畅，同时自然地扩充我的评测数据集 你大概也可以凭感觉（vibe-code）把这些步骤拼成一个内部自定义工具，但 Kitaru 真正强大的地方在于它的重放机制：它会缓存工具输出，并用这些输出来复现 bug 和你当时的上下文。这仍然很耗时，但效果还不错。 仍然很好奇，你们在运行 AI 评测和构建回归测试集时采用什么策略？