执行、结果与体验三维框架

语音智能体的评估难点在于，一次通话可能同时呈现多种矛盾信号：智能体出现长时间停顿，听起来很别扭，但最终解决了用户问题；或者严格按照指令执行了每一步，却因缺乏必要上下文而让用户失望。这两种情况都说明系统存在改进空间，但改进方向截然不同。LangChain 因此建议将评估拆分为执行、结果与体验三个相互关联但不可互换的维度，避免用单一指标掩盖真实问题。

执行维度关注智能体是否忠实遵循了设计规范。对于可明确定义的行为要求，代码评估器是最高效的选择。以预约调度智能体为例，可以用确定性规则检查：check_availability 是否在 book_appointment 之前被调用，工具是否收到了完整的日期、时间与时区参数，必要的隐私披露语句是否出现在通话记录中。这类检查无需额外模型调用，速度快、成本低，适合在 LangSmith 中对追踪数据进行批量验证。

对于依赖语义理解的执行要求，则需要引入 LLM 裁判。例如判断智能体是否准确回答了来电者的问题、是否使用了专业且符合场景的语言、是否在遇到模糊请求时提出了合适的澄清问题。LLM 裁判的关键在于评估标准必须足够具体：宽泛的问题如「这个回复好吗」会产生噪声结果，而明确的评分规则——如「若智能体在调用预订工具前确认了日期、时间和时区则通过，否则失败」——则能产生可重复的评估结论。

结果维度与执行维度的核心区别在于：智能体可以完美遵循所有指令，却仍然让用户失败。一个典型案例是调度智能体完成了所有规定步骤，但因流程中未要求确认时区，导致预约被记录为错误时间。这类失败在原始通话记录中并不明显，往往需要通过后续用户反馈才能发现。LLM 裁判可以评估来电者的核心诉求是否真正得到解决，以及智能体在无法完成任务时是否采取了恰当的兜底行动。

最可靠的结果评估方式是直接衡量下游业务数据，而非仅从对话内容推断成功与否。调度智能体应对照实际预约记录进行评估，客服智能体应参考工单是否被重新打开，转接智能体应验证来电者是否到达了正确目的地。在 LangSmith 中，可以将预约成功率、问题解决率、升级率、转接成功率等业务指标与原始追踪记录关联，从而直观判断提示词或流程的调整是否同步改善了真实业务结果，而不仅仅是让对话看起来更顺畅。

三个评估维度共同构成了一套完整的语音智能体质量保障体系。执行评估帮助团队发现流程合规问题，结果评估揭示系统设计层面的盲区，体验评估则捕捉那些不影响任务完成但会损害用户感受的细节。将代码评估器的确定性、LLM 裁判的语义理解能力与业务数据的客观反馈结合使用，团队才能在迭代过程中准确判断每一次改动的真实效果，避免在局部优化中忽视整体表现的退步。

要点

• 语音智能体评估应覆盖执行合规、目标达成与通话体验三个维度，三者相互关联但不可互换，单一指标无法全面反映智能体质量。
• 可明确定义的行为要求适合用代码评估器进行确定性检查，语义层面的判断则需要配合明确评分规则的 LLM 裁判，两者结合才能覆盖不同类型的执行问题。
• 智能体严格遵循指令并不等同于达成业务目标，结果评估需要将下游业务数据（如预约记录、工单状态）与原始追踪记录关联，才能验证改动的真实价值。
• LangSmith 支持对完整通话交互进行追踪，并可将多种评估信号与业务指标统一关联，为团队提供跨时间维度的对比分析能力。