AI 玩具要实现自然对话，需要设备采集声音、将音频传给处理端，再把响应播放出来。RTC 可以承担其中的实时音频通信，但模型生成内容、知识库和角色设定属于其他环节。采购前把边界画清，才能判断缺的是通信能力还是完整应用系统。
给每段链路安排负责人
建议画出“采集—传输—识别或模型处理—语音生成—返回—播放”的路径，标明各环节位于设备还是服务端。不同架构可能合并其中一些步骤，仍要确认接口、格式、会话标识和错误信息如何传递。
如果已有模型服务，先提供其音频输入输出方式；如果还在选型，应把通信验证和模型效果评估分别安排。仅凭某个模型支持语音，不能推断设备已经具备完整 RTC 接入条件。
把等待时间分段记录
从用户结束说话到玩具开始回答，中间包含多个阶段。建议分别记录采集状态、音频发送、服务端处理和开始播放的时间点，并确认计时来源。总等待时间变长时，才能判断应该排查哪一段。
对于持续流式响应，既要关注第一段声音何时出现，也要观察后续播放是否连续。不得把模型处理时间全部算成网络问题，也不能用通信侧某项指标承诺整体响应速度。
打断需要端到端配合
用户在玩具回答时开口，可能涉及回声处理、讲话检测、停止播放、停止或忽略旧响应，再建立新的对话状态。RTC 传输能力本身不能代表这些应用行为已经完成。
测试时覆盖近距离与正常距离、不同音量、背景声音，以及边播放边说话的情况。掉线恢复后应确认旧回答不会意外续播，重复发送不会生成重复响应，会话状态能够被用户理解。
用量产设备验证持续使用
机身材料、扬声器位置、电量和无线信号都应纳入测试条件。长时间连续对话与间歇唤醒分别记录，观察资源占用和恢复行为。具体隐私提示及内容管理由产品团队结合业务设计，不能由通信接入替代。
以上是通用架构与测试建议，所需接口和效果须结合实际设备及服务确认。本站咨询聚焦 RTC 音频传输；咨询时提供设备系统、音频接口和已选服务端，便于评估通信接入与报价。
参考：W3C Media Capture and Streams，用于理解采集和音频处理能力；本文不据此宣称任何 AI 模型能力。