我交付的 AI 智能体通过了 23 项单元测试，但在上线不到一小时内，它就凭空捏造了一个产品功能，并报出了比实际价格低三倍的价格。当用户指出这一点时，机器人不仅没有纠正，反而变本加厉，最终导致对话中断，我也因此失去了一位客户。这次错误证明，一套确定性的单元测试无法保证智能体的可靠性。
为什么单元测试对 AI 智能体效果有限
单元测试对传统代码有效，因为相同的输入总是产生相同的输出。“2 + 2 = 4”是一个你可以通过简单的等值检查来验证的保证。然而，由 LLM 驱动的智能体其输出会随着提示词（prompt）、上下文环境以及所调用的任何外部工具的状态而变化。检查精确字符串相等的测试会漏掉幻觉、语气转变或违反护栏（guardrail）的情况。这次导致客户流失的“静默失败”表明，你必须评估整个交互过程，而不仅仅是孤立的函数。
在编写任何功能代码之前构建评估框架
我颠倒了开发顺序：先设计一个四层评估框架，然后再编写智能体。该框架单次运行可执行 131 项测试，成本约为 0.03 美元，耗时约 11 分钟。我会为每项测试分配能够处理该任务的最轻量级模型，将更大、更昂贵的模型留给真正能发挥价值的时刻。
第 1 层 – 工具功能性
第一道防线是检查智能体能否正确调用其工具。测试涵盖了成功的搜索、故意构造的错误查询以及模拟的 API 故障。由于工具的使用在很大程度上是确定性的——要么请求格式正确，要么 API 返回错误——因此简单的 Python 断言就足够了。在这里拦截错误的请求可以防止下游出现混乱。
第 2 层 – 指令遵循
接下来，框架会验证智能体是否遵守了护栏规则。使用一个较小的 LLM 作为评估器，扫描智能体的响应是否合规：保持角色设定、避免禁止的话题，并输出所需的 JSON schema。这一层可以捕捉到单元测试无法发现的语义漂移，例如滑向非预期的角色或泄露内部提示词。
第 3 层 – 目标导向行为
第三层是最关键的。它询问智能体是否真正实现了其目标。对于一个获客机器人来说，这意味着要确认它是否提出了正确的资格审查问题，并在适当的时候转接人工。我在这里使用一个面向推理的模型，因为它可以在不增加过多成本的情况下评估整体流程。如果机器人未能实现目标——即使它通过了前两层测试——也会被标记为需要重新设计。
第 4 层 – 性能
最后，框架会记录延迟和 Token 生成速度。响应缓慢会损害用户体验，尤其是在实时聊天中。通过将这些指标与功能正确性结合跟踪，我能确保智能体既准确又响应迅速。
节省成本的选择
每运行一次 0.03 美元的数字并非营销噱头；它源于将测试复杂度与模型规模进行匹配。确定性的工具检查在最便宜的运行时上运行，指令合规性使用轻量级模型，只有目标导向的评估才会调用功能更强但价格更贵的模型。这种分层方法使总支出保持在较低水平，足以在每次代码变更时运行全套测试。
权衡：速度与安全
引入评估框架增加了前期的阻力。开发周期拉长了，发布时间表也推迟了。
下一步关注点
- 模型驱动的评估器：随着 LLM 的进步，第 2 层的评估器可以变得更加细腻，在发现细微的策略违规的同时，减少误报。
总结
如果你正在构建用于生产环境的 AI 智能体，分层评估框架不是可选项，而是基础。通过将全面测试的成本前置——每次运行 0.03 美元，每套测试 11 分钟——你可以防范那些单元测试根本无法检测到的“静默失败”。