机器人在桌面上能通话，不代表移动和执行任务时也能听清。扬声器、麦克风、风扇、电机和机身结构共同影响声音。评估 RTC 双向语音，应把通信链路和整机声学同时纳入测试，而不是只播放一段录音。
先弄清音频经过哪些处理
画出麦克风采集、设备音频处理、RTC 输入、网络传输、对端播放的完整路径，再反向画出接收路径。标明采样率、声道数，以及回声消除、降噪和音量控制各由谁处理。
如果硬件、操作系统和 SDK 都有声音处理功能，需要逐项确认配置。盲目叠加处理可能使问题更难定位。使用外部音频输入时，还要确认服务是否支持所需接口，以及播放参考信号如何提供给相应的回声处理模块。
分开测试回声和双讲
先让远端单独说话，检查其声音是否从机器人扬声器重新进入麦克风并被传回。再让机器人附近的人说话，检查音量和清晰度。最后让双方同时说话，观察是否有人被明显压低、截断，或必须等对方说完才能交流。
不要用“开了回声消除”作为通过条件。W3C 媒体采集规范定义了相关能力与约束，但具体设备上的效果仍需要验证。应保存测试条件和双方听感，便于研发复现。
把机器人工作状态加入矩阵
至少覆盖静止、移动、转向、风扇工作及任务负载上升等实际状态。按照产品的正常距离和朝向说话，同时记录音量设置、电源模式与外壳版本。若支持外接耳机或不同麦克风，分别验证切换后的采集与播放。
异常也要测：来电时设备正播放提示音、应用切到后台、网络恢复后重新打开音频、挂断后再次呼叫。每次结束都应确认麦克风和扬声器回到预期状态。
用责任清单推进接入
设备团队提供音频接口与声学条件；RTC 接入方确认通信能力、接口和可观察数据；产品团队确定实际对话任务和通过标准。问题先按本地采集、播放、传输三个环节归类，再安排修改。
以上是通用测试建议，不构成特定机器人的音频效果承诺。需要咨询机器人 RTC 接入与报价，可提供系统、芯片、音频链路和典型工作环境。
参考：W3C Media Capture and Streams，用于了解媒体采集能力描述，原生设备接口以实际 SDK 为准。