第 12 章：测试、评估与质量保障
智能体评估需兼顾非确定性与指标化设计，测试流程应覆盖功能、回归与质量评估。
智能体测试的挑战：非确定性与黑盒特性
智能体应用的核心在于允许大语言模型（LLM, Large Language Model）自主决定解决问题的下一步骤。这种灵活性虽然强大，但 LLM 的黑盒（black-box）本质使其难以预测对智能体任何一部分的调整将如何影响整体行为。
智能体应用本质上具有非确定性，因为它们链接了多个组件，并依赖于 LLM 的推理，这使得彻底的测试成为构建生产级智能体的关键。尽管构建智能体原型很容易，但构建足够可靠以投入生产的智能体仍然非常困难。
为了构建生产就绪的智能体，需要采取彻底的测试方法。
测试类型：单元测试与集成测试
测试智能体主要有两种方法，下面的表格对比了各自特点与适用场景：
| 测试类型 | 描述 | 最佳用途 |
|---|---|---|
| 单元测试 | 在隔离状态下测试智能体的小型、确定性部分，使用内存中的假对象（fakes）来断言确切行为。 | 快速、确定性地测试不需要 API 调用的逻辑。 |
| 集成测试 | 使用真实网络调用来测试智能体，以确认组件协同工作、凭证和模式对齐，以及延迟可接受。 | 验证只有在使用真实 LLM 时才会出现的行为，例如智能体决定调用哪个工具、如何格式化响应。 |
由于智能体将多个组件链接在一起，并且必须处理 LLM 的非确定性，因此它们往往更侧重于集成测试。
在单元测试中，需模拟那些耗时或成本高昂的外部依赖项：
- 模型 Mocking（模拟聊天模型）：对于不需要 API 调用的逻辑，可以使用内存中的存根（stub）来模拟响应。LangChain 提供了
FakeChatModel，它可以接受响应迭代器（AIMessages 或字符串），并在每次调用时返回一个响应，支持常规和流式传输用法。 - 内存 Checkpointer：测试期间可用 InMemorySaver Checkpointer 实现持久性，模拟多轮交互，测试依赖于状态的行为。
使用 AgentEvals 进行智能体评估
AgentEvals 是专门设计用于测试带有真实模型的智能体轨迹的包，允许轻松评估智能体执行的确切序列（包括消息和工具调用）。
有两种主要评估方法：
- 轨迹匹配（Trajectory Match）：适用于明确知道预期行为的工作流。
- LLM 裁判（LLM Judge）：适用于评估整体质量和合理性，无需严格的工具调用或排序要求。
下表对比了轨迹匹配评估器的四种模式及典型用例：
| 模式 | 描述 | 用例 |
|---|---|---|
| strict | 消息和工具调用必须顺序完全匹配。 | 强制执行特定操作序列，如授权前策略查询。 |
| unordered | 允许相同工具调用以任意顺序进行。 | 验证信息是否被检索，顺序不重要。 |
| subset | 智能体调用的工具不超过参考轨迹中的工具（不允许额外工具）。 | 确保智能体不会超出预期范围。 |
| superset | 智能体至少调用了参考轨迹中的工具（允许额外工具）。 | 验证至少采取了所需最低限度行动。 |
轨迹匹配评估器确定性、快速且具有成本效益，无需额外 LLM 调用。
LLM-as-Judge 评估器则通过 LLM 评估智能体执行路径，无需参考轨迹但可选提供，适合评估效率和适当性，但非确定性更高。
可观测性与 LangSmith 集成
为了跟踪实验和智能体在生产中的行为，可观测性至关重要。LangChain 智能体通过 LangSmith 提供内置可观测性，LangSmith 是用于追踪、调试、评估和监控 LLM 应用的平台。
- 轨迹追踪：捕获智能体每一步，包括所有工具调用、模型交互和决策点。
- 启用追踪：所有 LangChain 智能体自动支持 LangSmith 追踪，只需设置必要环境变量即可启用。
- 评估日志：可将评估器结果记录到 LangSmith，便于跟踪实验。
持续集成与成本优化建议：在 CI/CD 管道中频繁运行集成测试可能慢且成本高。建议使用库记录 HTTP 请求和响应，然后在后续运行中重放，模拟真实 LLM 交互，无需实际网络调用。
总结
智能体测试与评估需兼顾非确定性与指标化设计，合理选择测试类型与评估方法，配合可观测性平台，才能保障智能体的质量与稳定性。