OpenAI用GPT-Live-1和Codex改造LED屏，语音测试最该盯哪条链？
“晚上十点以后别再亮屏。”转写文本一字不差，Agent也回复“好的”。到了十点十五分，用户随口问了一句天气，LED屏还是被点亮了。语音识别没错、回答也没错，真正错的是动作策略。
OpenAI开发者博客在2026年9月23日分享了用GPT-Live-1、Codex和树莓派让LED显示屏具备语音交互的开发实践。它提供了一个很适合测试团队理解的问题：语音Agent不是语音转文字加一个聊天框，而是一条从声音、意图、工具到物理结果的完整链路。
只算转写准确率，会漏掉三类业务错误
第一类是意图错误。文字正确，但“不要亮”被解析成亮屏相关任务。第二类是工具参数错误，例如亮度100被当成百分比还是绝对值。第三类是状态错误，Agent不知道当前时间、静音模式或设备已经离线。
因此一条语音用例至少保存原始音频、转写、结构化意图、工具调用和最终设备状态。任何一层缺失，失败后都只能猜。
从一句口令拆出四层断言
假设用户说“把屏幕亮度调低一点，晚上十点后不要亮”。语音层允许少量文字差异；意图层必须得到亮度下降和夜间禁用两条规则；工具层检查参数范围；设备层验证时间条件真正生效。
assert intent.actions == ['decrease_brightness', 'set_quiet_hours']
assert 0 <= tool_args['brightness'] < current_brightness
assert tool_args['quiet_hours_start'] == '22:00'
assert device_state.at('22:15').screen_on is False
这比“最终回答包含好的”更接近用户真正想要的结果。
实时语音还要测试打断和抢话
用户可能说到一半修改要求：“调到30%……算了，20%。”系统必须取消旧动作，只执行最后确认的参数。还要模拟网络抖动、回声、背景电视和两个人同时说话。若意图不确定，正确行为是追问，而不是猜一个值立即操作。
涉及门锁、支付、电话和硬件控制时，应增加确认状态：识别完成不等于授权完成。Agent在确认前调用工具，哪怕结果后来被用户接受，也属于越界。
用变形测试降低音频样本维护量
同一句口令换语速、口音、背景噪声和说法，业务意图应保持不变；把“十点后”改成“九点后”，时间参数应跟着变化；加入否定词，动作方向必须反转。变形关系比为每段音频手写完整答案更容易维护。
线上Trace要能串到物理结果
日志不能停在“工具返回成功”。设备可能离线，网关可能缓存旧状态。Trace应记录命令ID、设备确认、状态回读和超时处理。同一命令重试时使用幂等ID，避免亮度连续降低两次。
普通团队可以用一个模拟设备开始，不必买硬件。实现亮度、开关和静音三个工具，准备20条语音或文本替代输入，先验证意图与动作状态机，再逐步加入真实音频。
语音Agent让测试从“听得准不准”走向“听完以后做得对不对”。传统接口、状态机、幂等和异常恢复能力没有过时，它们只是被接到了声音入口之后。
对话结束不代表动作结束
实时语音模型可能已经说完“好的”，后台工具仍在执行。用户紧接着说“取消”，系统要判断动作是否已经提交、能否撤销，还是需要补偿操作。测试Trace必须把语音轮次和工具生命周期对齐，不能只按文本消息切段。
模拟三个时间点取消：工具调用前、调用中、调用成功后。调用前应直接停止；调用中要看工具是否支持取消；成功后则执行明确的补偿流程。不同阶段都回复同一句“已取消”，会让用户误以为物理世界已经恢复。
设备回读是最后一道证据
工具返回200只说明网关收到命令，不代表LED真的熄灭。设备测试应等待状态回读，超时后告诉用户“命令已发送但未确认”，而不是宣称完成。对于门锁、空调和支付设备，这种区别更重要。
可设置命令ID，将语音意图、工具请求、设备确认和最终播报串成同一Trace。出现重复执行时，也能判断是语音模型重复规划、网关重试还是设备响应丢失。
语音质量不能只用平均值
总体转写准确率很好，老人、儿童、方言或噪声环境仍可能集中失败。评测集按人群、环境和任务风险分层，分别报告意图正确率与危险动作误触发。高风险动作宁可多追问一次，也不能用总体平均分掩盖少数群体的错误。
一套成熟的语音Agent评测，最终要同时回答：听见了什么、理解成什么、调用了什么、设备实际怎样、用户能否中途改变主意。五条证据完整，语音助手才从“会聊天”变成“敢行动”。
