企业验证实时语音智能体，不能只安排一次演示，听它是否“像真人”。真正需要确认的是：系统能否在连续语音、打断、噪声和复杂任务中，稳定完成理解、推理、工具调用与结果交付，并在不确定时停止执行、请求确认或转人工。
先验证任务闭环
测试应从真实业务任务出发，而不是从模型名称或宣传功能出发。可以将场景拆成四类：简单问答、单次系统查询、多步骤工具调用，以及涉及权限和人工确认的复杂任务。
每类任务都要记录意图识别、关键字段提取、工具选择、任务完成、错误恢复和拒答表现。例如客服场景中，系统不仅要听清订单号、产品型号和时间信息，还要判断是否有权限查询订单或登记售后；会议场景中，则要区分正式决定与讨论意见，避免未经确认的内容直接写入业务系统。
实时语音还必须单独测试首响应延迟、完整响应延迟、打断恢复、上下文保持和网络波动下的降级能力。延迟越低并不必然代表效果越好，但复杂推理带来的等待时间必须与业务价值匹配。简单查询更看重即时响应和稳定性，跨系统任务则更看重准确率、完成率与异常恢复。
建立可比较的测试矩阵
测试数据应覆盖安静环境、背景噪声、不同口音、多人说话、连续追问和故意打断。除了正常路径，还要加入缺少信息、权限不足、工具返回错误和用户改变意图等边界情况。
评估结果不能只看模型回答是否流畅，还应计算或记录以下事实：关键字段是否听对，工具是否选对，任务是否完成，错误后能否恢复，无法确定时是否会编造答案，以及转人工时能否完整传递上下文。对于涉及支付、隐私、车辆控制、合同或客户承诺的动作，应设置二次确认和最小权限，不能因为语音自然就直接放行。
迁移必须分阶段
新模型或新接口应先进行能力核验，再做影子运行，最后进行受控灰度。影子运行期间，新系统只接收相同输入，不直接影响线上业务，用于比较延迟、错误类型、转人工比例和单位任务成本。灰度阶段则应限制业务范围、用户范围和工具权限，并保留原系统回退路径。
如果评估对象涉及 Gemini 3.8 Live 或 Gemini 3.8 Live Extended Thinking，还应先核验官方发布主体、接口形态、地区可用性、配额、计费、数据处理规则和具体能力边界。没有官方公告或开发者文档支持的参数，不应被当成已确认事实。企业最终要采购的不是“会说话的模型”，而是一套可审计、可回退、能在关键节点接受人工控制的业务系统。