一个语音智能体可以完美遵守每一条指令，却依然让用户的任务失败。LangChain 在分享中给出的这个判断，把评估问题从"打分"拉回到了"分工"。

他们把语音智能体的评估拆成三个彼此独立的维度：执行、结果、体验。执行看的是智能体有没有遵守指令与规范；结果看的是这次交互有没有真正达成目标；体验则专门处理语音特有的响应速度、自然度和对话摩擦。

指令遵从性不等于结果有效性

这是整套框架里最关键的一条区分。智能体可能严格按提示词执行，语气、流程、话术都没出错，但用户想办的事没办成。执行维度的满分，推不出结果维度的合格。

所以结果维度不能靠"读对话"来判断。分享中强调，应尽量度量真实的下游业务信号——预约时间时区是否正确、工单是否被重开、转接是否真的被接听。这些信号发生在对话之外，是任务是否完成的硬证据，而不是从对话内容里推断出来的印象。

体验藏在录音里，不在转录文本里

语音体验的测量方式和文本智能体完全不同。轮次结束延迟是核心的用户感知指标，但只看一个总延迟没有意义，需要分段测量 VAD、STT、模型推理、工具调用、TTS 各自的表现，并统计 P50/P95/P99，才能定位停顿到底出在哪一环。

自然度与清晰度的问题更彻底：这些属性存在于录音里而非文本里。分享中的说法很直接——只看转录的评审者，原理上就无法判断声音是否友好。因此自然度必须用音频感知模型来评审。

三维独立，才能看见取舍

把三个维度分开评估的价值，不在于分数更细，而在于它能暴露权衡关系。一个新提示可能提升指令遵从，却降低解决率；一个更快的模型可能压低延迟，但处理用户打断时更不可靠。

如果只看一个聚合总分，这些此消彼长会被平均掉，团队看到的是"整体还行"，看不到具体哪一项在恶化。分维度评估是不要只看总分的工程化论证。

落地路径上，分享给出的是一套持续评估闭环，把确定性评估器与 LLM 评审结合使用：能用规则和业务信号判定的部分交给确定性评估器，需要理解语义和音频感知的部分交给模型评审。七个步骤串起来，形成可以反复跑的循环。

对做语音产品的团队来说，这套框架的提醒很实在：先想清楚你要评的是执行、结果还是体验，再决定用什么工具去测。三者混在一起打分，等于什么都没测。