用 Evals 测试 AI Agent 行为正确性的实践

我用 coding agents 构建 AI 应用已经有一段时间了。

最近，我也开始尝试 evals。

这个例子中的应用大部分时候都能正常工作。问题恰恰在这里。

我为一家虚构的货运追踪公司构建了一个小型客服工单分流应用。

客户提交客服工单后，应用会判断工单涉及什么问题、紧急程度如何，以及是否需要人工回复。

真正的服务中断应该升级处理。

但这张工单不一样：

“紧急，需要立即轮换密钥”

客户只是询问，如何在安全审查前轮换自己的 API key。

应用却将其归类为安全事件，并升级给人工处理。

这是错误的。按照策略，正常的密钥轮换属于可通过自助方式解决的操作指南类请求。

没有任何程序崩溃。应用返回了有效的 JSON，所有字段也都是允许的值。

但它的行为仍然是错的。

为什么手动点几下还不够

我可以手动测试几张工单，然后说服自己这个应用运行正常。

但修改 prompt 之后，我实际上能确定什么？

服务中断的工单仍然会升级处理吗？

普通的操作指南类问题仍然会留在常规队列中吗？

换一个与 API key 有关的问题，处理结果会不会不一样？

我不想修改 prompt 之后，只能寄希望于一切顺利。

我需要一组可以反复运行的测试用例。

使用 Cursor 添加 DeepEval

我安装了 DeepEval agent skill：

npx skills add confident-ai/deepeval --skill "deepeval"

然后，我让 Cursor 为应用添加 evals：

This app sometimes treats normal support questions like emergencies and sends
them to a human.
Add DeepEval so I can test this using the tickets and policy already in the repo.
I am new to evals, so use the simplest setup DeepEval already provides, explain
what you create, and ask me anything you need.
Run the app as it is first and show me what fails. Do not fix it yet.

Cursor 已经拿到了应用、工单和策略，因此直接开始创建基线。

Goldens 就是检查清单

第一个真正有用的产物是一份 JSON 数据集。

每条 golden 都包含：

• 客户消息
• 预期分类
• 预期优先级
• 是否需要人工介入

例如：

{
  "input": "URGENT need key rotation now",
  "expected": {
    "category": "how-to",
    "priority": "P3",
    "needs_human": false
  }
}

应用并不会从这些示例中学习。

这份数据集是一张检查清单。它告诉我，在发布 prompt 更新之前，哪些行为必须继续正常工作。

正是这一点，让我真正理解了 evals 的价值。

Cursor 使用 DeepEval 的内置 metrics 检查了两个不同方面。

第一项检查会将应用的路由字段与 golden 中的预期值进行比较：

• 是否升级给人工处理

第二项检查则判断应用的决策是否遵循策略中的升级规则。

这样，我就可以分别提出两个问题：

应用是否返回了预期的决策？

按照策略来看，这个决策是否合理？

第一次运行就发现了密钥轮换用例的问题。

category: security
priority: P1
needs_human: true

预期结果是：

category: how-to
priority: P3
needs_human: false

输出格式是有效的，但行为是错误的。

策略检查还向 Cursor 提供了具体原因，解释了为什么这个决策不符合客服处理规则。

这已经比修改 prompt、再次点击同一张工单，然后祈祷自己没有破坏其他功能有用得多。

这次失败指向了分流 prompt 中一条范围过于宽泛的指令。

它把所有涉及 API key 的问题都视为安全事件。

这种处理方式过于激进。

修复方式是：只有在确实发生泄露、可疑访问或服务中断时，才升级处理。

随后，Cursor 重新运行了同一组测试用例。

密钥轮换用例通过了。

真正的服务中断用例仍然会升级处理。

后一点非常重要。只修复一个用例还不够，我还想确认自己没有破坏原本已经正常工作的用例。

这是我一直在使用的工作流：

Build the app
Create test cases
Run the app
Read the failure
Fix the prompt
Run the same cases again

如果没有 evals，我只能修改 prompt，然后祈祷自己没有制造出三个新 bug。

有了 evals，每次修改 prompt，背后都有一张检查清单提供保障。

我在这里记录了完整的工作流：

观看视频：https://x.com/juampitech/status/2084330588593385637?s=20

DeepEval 是开源的，可以在本地运行。使用这套工作流不需要 Confident AI 账户。LLM-as-a-judge metrics 需要配置模型 API key。

DeepEval Vibe Coder 快速入门：

https://deepeval.com/docs/vibe-coder-quickstart

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。