远程协作的价值取决于现场人员能否听清指令、专家能否看清操作，以及连接中断后能否继续任务。选型时，可以先挑一个真实流程，例如查看设备铭牌、确认部件位置、完成操作并复核结果，再用同一流程比较候选方案。
先定义谁在看、谁在说
一位专家指导一位佩戴者，与多人同时观看，是不同的通信需求。列明首期的参与者数量、是否需要专家交接、谁可以打开麦克风，以及现场人员如何接受或结束会话。多人观看还要确认每个人收到哪些媒体，避免把暂时用不到的能力加入首期成本。
佩戴者双手可能正在操作。发起、接听、静音和退出的动作，应在实际佩戴条件下验证。按钮或语音控制属于产品交互层，RTC 服务负责的范围需要在接入分工中写清。
用三类任务评估媒体质量
第一类是观察静态细节：让专家读取实际大小的标签，记录所需距离与光线。第二类是跟随动作：转头、走动、拿取工具，观察画面是否影响判断。第三类是连续对话：两人交替说话并适度重叠，确认没有因听不清而反复解释。
不要只保存一段效果最好的录像。建议记录成功与失败的次数、设备版本、网络条件和用户反馈。先由业务负责人确定什么程度会妨碍工作，再把可测量的指标交给研发核验。
为中断设计明确的提示
网络变差时，用户需要知道是对方静音、画面暂停还是连接已经断开。可考虑显示连接状态，必要时降低画质，恢复后提示双方确认任务位置。缓存画面不能让专家误以为现场仍在持续更新。
浏览器端可通过连接统计辅助定位问题，但统计值不能直接替代任务体验。特别要区分网络往返时间与从现场动作到远端显示的完整时延。
采购时确认功能归属
圈画标注、工单、录像、专家调度和身份权限不应默认包含在 RTC 中。逐项写清由设备团队、业务系统还是通信服务实现，以及是否另行计费。
以上是通用验收方法，具体效果需要用真实眼镜、接收端与目标网络验证。咨询 RTC 接入与报价时，附上你的协作流程和参与者关系，就能更快确定通信部分的范围。
参考：MDN getStats 文档，说明浏览器连接统计的获取方式；本文任务设计是评估建议。