首页
10月22日，在上海举行的 WTCC 2026 西岸国际科技消费嘉年华上，淘宝直播进行了一场有些特别的“云逛展”。与普通探展直播不同，这一次，屏幕前的观众不只是看主播介绍产品，还能通过弹幕和投票参与决定现场机器人的行为。观众发送弹幕，让机器狗“哮天”握手、转圈；陪伴机器人 AiMe 根据弹幕中出现的高频词创作睡前故事；出行机器人昂首 EV1 按照观众指定的目标位置规划移动路线；按摩机器人 R2 的服务部位、调酒机器人的特调口味，也由直播间互动决定。这场活动展示了一种值得关注的直播玩法：观众在虚拟直播间里产生的互动行为，可以影响线下实体设备的动作和内容输出，而机器人的执行结果又通过直播画面返回给观众。
不过，弹幕投票、机器人动作指令和 VR 遥操作并不是同一种控制方式。公开报道也没有披露活动后台使用的具体通信协议、指令处理架构或 SDK。
如果开发者希望构建类似系统，需要解决哪些问题？当直播间同时涌入大量弹幕时，怎样判断应该执行哪条指令？机器人完成动作后，又怎样把结果及时反馈给观众？
这些问题涉及实时消息、视频传输、机器人本地控制，以及 AI Agent 与实体设备之间的协作。
一. 从观看直播到控制机器人，互动方式发生了什么变化？
传统直播的交互主体是人。
主播展示商品，观众发送弹幕、点赞或提问，主播根据评论作出回应。即使加入投票、抽奖和连麦，观众参与的主要还是直播内容。
但当直播间连接了一台真实机器人，用户的互动行为就可能转化为设备动作。
比如，观众选择“让机器狗转圈”，现场机器人执行动作，其他观众通过直播看到结果，再发出新的指令。
这一过程形成了从线上到线下、再返回线上的交互闭环。
1. 弹幕不再只是评论，也可以成为任务输入
以 WTCC 现场的几种玩法为例，它们实际上对应不同的交互机制。
第一种是离散动作指令。例如，让机器狗握手、转圈。这类指令可以对应预先定义好的动作接口，适合使用有限指令集进行匹配。
第二种是投票或群体决策。例如，直播观众选择调酒口味、按摩部位或故事关键词。系统需要在一定时间内汇总意见，再根据互动规则确定最终结果。
第三种是任务目标输入。例如，用户指定机器人移动到某个位置。机器人需要进一步结合自己的位置、环境信息和运动规划能力完成任务。
第四种是人工遥操作。例如，现场主持人佩戴 VR 设备操控人形机器人。这与观众投票不同，需要持续、及时的操作反馈，也对视频延迟和控制稳定性提出更高要求。
这几种交互形式都能让线上用户影响线下设备，但不能简单归纳为“所有弹幕直接控制机器人电机”。
在实际产品中，用户输入通常需要经过规则匹配、任务选择、权限检查或人工确认，才能进入设备执行环节。
2. 观众参与的是任务决策，设备负责具体执行
假设直播间有上千名观众同时发送“转圈”“坐下”“前进”等指令，机器人不可能同时执行所有动作。
如果让每条弹幕直接进入设备控制程序，就可能出现指令冲突。
例如，机器人正在转圈，另一批观众又要求它立即前进。没有任务调度机制时，设备可能频繁取消和切换动作，导致执行不稳定。
因此，面向多人参与的机器人互动直播，通常需要在观众和机器人之间增加一层业务控制系统。
系统先收集观众输入，再根据预设规则确定当前有效的任务。例如，可以采用投票最多的选项、限定时间内的首个有效指令，或者由主持人确认后执行。
机器人收到的应该是经过校验的任务，而不是没有约束的原始弹幕文本。
这一区别很重要：观众可以参与决定机器人做什么，但具体怎样做、能不能做，仍然由设备控制系统判断。
二. 一条弹幕如何变成机器人的实际动作？
目前没有公开资料证明淘宝直播此次活动使用了哪一种具体技术栈。不过，从实时互动系统的设计角度，可以将类似玩法拆解为五个环节。
用户发送弹幕，业务系统理解和筛选指令，设备接收任务并执行，再通过实时视频和状态信息向用户反馈。
1. 收集指令：处理高并发的观众输入
对于一场多人观看的直播，弹幕系统首先需要面对消息并发。
例如，主播提问：“接下来让机器狗握手，还是转圈？”
短时间内，直播间可能出现大量重复回复。
如果系统把每个“握手”都发送给机器人，既浪费消息传输资源，也可能导致设备重复执行同一个动作。
更合理的方式是由互动服务收集消息，在指定时间窗口内完成去重、聚合和计数。
对于投票类玩法，后台只需要在投票结束后生成一次有效任务，例如：
{
"taskId": "task-1022-001",
"robotId": "robot-dog-01",
"action": "turn_around",
"source": "audience_vote",
"status": "pending"
}上述 JSON 仅用于说明一种可行的业务消息结构，并非淘宝直播实际采用的数据格式。
对于普通的选择题或固定动作菜单，使用规则匹配就可能满足需求，不一定需要大语言模型。
2. 理解意图：AI Agent可以处理更开放的表达
如果观众的输入不再局限于“握手”“转圈”这样的固定命令，而是“让机器人向镜头打个招呼”“给小朋友讲个关于太空的故事”，系统就需要更灵活地理解用户意图。
这里可以引入 LLM 或 AI Agent。
例如，观众要求陪伴机器人讲睡前故事，系统可以先提取关键词，再由语言模型生成故事内容，最后通过语音合成播放出来。
如果用户提出的是设备动作请求，Agent 则可以把自然语言转化为预先定义的任务参数，交给业务服务处理。
但语言模型不应该直接生成不受限制的电机控制指令。
例如，“向前走一点”可以被解析成移动意图，但移动距离、速度上限、路径规划和障碍物检测仍需要由机器人控制系统决定。
对于涉及真实物理动作的设备，AI Agent 负责理解需求，设备系统负责校验与安全执行，两者必须明确分工。
3. 指令分发：任务必须能够被确认和追踪
有效任务产生后，需要通过消息服务传递给对应机器人。
但消息发送成功，并不等于机器人已经完成动作。
例如，业务系统发送“转圈”任务，机器人可能因为电量不足、当前动作尚未结束，或者周围环境不适合执行而拒绝。
因此，任务最好具有明确的状态，例如：等待执行、已接收、执行中、已完成、执行失败。
每项任务还应该带有唯一 ID，方便系统识别重复请求、处理超时，并把设备返回的结果关联到正确的观众互动。
这种状态管理不仅适用于机器人，也适用于直播间的互动礼物、虚拟道具、远程智能硬件和游戏任务。
4. 设备执行：物理动作必须有安全边界
实体机器人与虚拟游戏角色最大的区别，是动作会真实发生在物理世界。
如果用户要求机器人向前移动，而前方恰好有人或障碍物，系统不能因为这条指令获得了最高票数，就强制执行。
机器人需要根据传感器信息、运动范围和本地安全规则判断任务是否可执行。
对于机械臂、移动机器人或其他具有运动机构的设备，还需要防止指令过期、控制权冲突、重复动作和异常断网。
如果设备因为安全原因拒绝执行，业务系统应当将失败原因反馈给观众，而不是只显示“操作成功”。
5. 视频反馈：让观众看到自己的参与结果
机器人完成动作之后，直播画面会将现场情况重新呈现给观众。
对于弹幕互动玩法，这一步直接影响参与体验。
假设观众刚刚投票让机器人转圈，但画面过了很久才出现动作，此时直播间可能已经进入下一轮互动，用户就很难判断自己的投票是否生效。
因此，系统需要关注的不只是指令发出后的网络延迟，还包括任务排队、机器人响应、动作执行，以及结果通过视频返回用户终端的完整时间。
对于真人遥操作，反馈延迟直接影响控制精度；对于投票驱动的离散动作，适度等待通常可以接受，但系统应当明确展示“指令已选中”“正在执行”等状态。
三. 直播间有大量观众时，为什么不能只优化视频延迟？
普通直播通常重点关注播放卡顿、视频清晰度和音画同步。
当观众能够远程影响机器人动作，系统还需要处理互动消息与直播画面之间的时间关系。
1. 观众看到的画面，可能不是机器人当前状态
现场摄像头采集画面后，还要经过编码、传输、播放缓冲和终端解码。
因此，观众在直播间看到的画面，通常比真实现场晚一些。
不同的直播协议和播放策略也会产生不同的延迟。
如果观众根据几秒前的画面直接发送精细操控指令，机器人收到指令时，现场环境可能已经发生变化。
这就是为什么直播弹幕适合控制离散任务，而连续遥操作需要更及时、稳定的专用反馈链路。
例如，让机器狗表演一次握手，可以先完成投票，再执行预设动作；但如果需要操控人形机器人保持动态平衡，不能只依赖普通直播画面进行连续控制。
2. 高并发互动与机器人控制，不应使用相同的处理策略
海量观众发送的弹幕适合通过消息聚合、限流、队列和投票规则处理。
机器人接收的控制任务则要求目标明确、权限可控、状态可追踪。
因此，可以将直播间互动消息服务与机器人控制服务分开。
观众发送的内容先进入互动服务，由业务系统筛选出少量有效任务，再转发给设备。
机器人执行任务后，只需要向业务服务返回必要的状态变化，前端就可以把进度展示给所有观众。
这样能够避免把大量无效或重复弹幕直接转发给设备，也更方便实现内容审核和控制权限管理。
3. 直播内容与互动事件需要统一时间上下文
如果直播间采用低延迟播放和常规 CDN 播放相结合的方式，不同观众看到同一动作的时间可能不完全一致。
例如，投票入口已经在后台关闭，但部分观众由于播放延迟，才刚刚看到主播发起投票。
这类问题需要在业务层明确投票开始时间、结束时间和结果发布时间。
对于与具体画面强相关的互动，还可以为互动事件附加时间戳或场景标识，将用户操作与对应的直播内容关联起来。
这样既有助于避免交互错位，也能让开发者更准确地测量从观众发出指令到最终看到执行结果的完整延迟。
四. RTC、RTM与AI如何构建机器人互动直播？
从技术实现来看，类似 WTCC 的线上线下互动玩法，涉及三个不同的系统：负责直播内容的实时音视频链路、负责互动与设备状态的消息链路，以及负责机器人动作执行的本体系统。
针对这些需求，声网现有的机器人远程操控与实时互动解决方案、社交互动游戏与弹幕互动方案，以及对话式AI引擎，可以为开发者提供不同层面的参考。
需要说明的是，公开资料并未披露淘宝直播此次 WTCC 活动使用了声网服务。以下讨论的是利用声网现有产品构建类似应用的可行方式，而不是该活动的实际部署架构。
1. RTC：连接现场视频、远程操作端与直播间
在机器人互动场景中，RTC 可以用于现场设备与远程操作端之间的实时视频和音频传输。
例如，机器人摄像头持续采集现场画面，操作员通过低延迟视频观察设备动作。必要时，还可以结合双向语音与现场工作人员交流。
在声网的机器人远程操控方案中，RTC 负责实时音视频传输，并可根据网络条件调整码率、分辨率和帧率，以适应不同设备和网络环境。
不过，远程操控视频与面向大量观众的直播分发，不一定要使用完全相同的链路。
对于需要低延迟反馈的操作员，可以优先设计 RTC 实时互动连接；对于大量只观看直播的观众，则可以根据时延需求、成本和并发规模选择互动直播或 CDN 分发。
声网同时提供直播服务，可用于电商直播、赛事直播等大规模内容分发场景。
开发者需要根据是否允许观众持续参与控制、互动频率以及观众端允许的延迟，选择合适的播放与消息同步方式。
2. RTM：连接弹幕任务、机器人状态与执行反馈
在消息层面，声网 RTM 提供低延迟的消息分发及状态同步能力，可以用于直播间的互动事件、机器人任务消息和设备状态更新。
例如，业务系统完成一轮弹幕投票后，将有效任务通过消息接口发送给设备端。设备端处理后，再向业务服务返回当前任务状态。
对于多个机器人同时参与的场景，开发者可以按照设备 ID、互动房间或任务类别组织消息，避免不同设备的控制指令发生混淆。
声网 RTM 提供 Message Channel、User Channel 等不同消息模型，开发者可根据一对多广播、点对点控制或设备状态订阅需求进行选择。
但 RTM 本身不是机器人任务调度器，也不承担电机级运动控制。弹幕计票、指令解析、权限校验、任务排队、去重和执行确认，仍需要开发者在业务层实现。
对于需要严格可靠执行的操作，还应建立任务状态机，并区分消息到达、设备接受和动作完成等不同阶段。
3. 对话式AI：让机器人能够生成内容并自然回应
WTCC 现场的陪伴机器人根据观众关键词生成故事，展示了另一类互动方式：观众不一定要控制设备移动，也可以影响 AI 输出的内容。
对于这类应用，开发者可以在互动消息系统之外增加 AI Agent。
例如，业务系统统计直播间的高频关键词，再将选中的主题提交给语言模型，生成适合当前场景的故事内容，最后通过 TTS 合成为语音，让机器人播放。
如果进一步支持观众直接与机器人语音对话，则需要实时语音传输、轮次检测、打断处理和模型响应等能力。
声网对话式AI引擎支持实时语音对话、语音打断、AI 降噪以及主流 ASR、LLM、TTS 模型适配，可用于 AI 玩具、陪伴机器人和语音互动终端等场景。
对于需要执行物理动作的机器人，AI Agent 可以承担任务理解和自然语言交互，但实际动作仍应由受控的设备接口执行，避免将未经校验的模型输出直接发送给运动控制器。
4. 机器人远程操控方案：连接视频反馈与实际执行
如果直播玩法涉及机器狗移动、人形机器人遥操作，或者需要远程人员接管现场设备，就会进一步涉及低延迟视频反馈、控制指令传输与设备状态同步。
声网的平行操控方案基于 RTC SDK 和 RTM SDK 2.x，面向机器人等设备提供音视频与实时控制信令接入能力。
在实际开发中，机器人可以通过设备端 SDK 提供实时视频和必要的状态数据，远程操作端接收画面并发送经授权的控制请求。
当设备执行任务后，控制系统再反馈动作状态，让操作员确认任务是否真正完成。
对于 VR 遥操作等需要连续控制的场景，还需要结合本地机器人控制系统、专用输入设备、运动限制和安全保护机制设计完整控制链路。
因此，RTC 与 RTM 可以提供远程连接和信息传输能力，但不能替代机器人的姿态控制、路径规划和安全停机系统。
五. 直播间连接实体机器人，还需要解决哪些实际问题？
把机器人接入一场直播 Demo，与将这种玩法长期提供给大量用户，是两种不同的开发任务。
除基础连接外，系统还需要处理高并发、任务冲突、内容安全和用户体验等问题。
1. 如何避免观众指令互相冲突？
机器人一次能够执行的任务通常有限。
如果同时收到多个互不兼容的指令，系统需要决定是排队执行、合并任务，还是拒绝新的请求。
对于直播互动，可以采用时间窗口投票、冷却时间、任务优先级及主持人确认等方式管理控制权。
设备进入危险状态、出现故障或需要现场人员维护时，应能够立即停止接收新的观众控制任务。
2. 如何防止恶意弹幕触发危险操作？
面向公众开放的直播间，不可避免会出现无效、重复甚至恶意输入。
如果观众可以使用自然语言提出任意任务，系统还需要防止越权指令、诱导性文本和不符合场景规则的操作请求。
可执行动作应使用明确的白名单，所有请求经过身份、权限和参数校验后，才能提交到设备控制服务。
特别是移动机器人、机械臂及其他具备实际作用力的设备，应由本地控制系统提供必要的安全边界。
对于多人参与的直播活动，现场工作人员还应具备独立于普通观众权限的暂停与接管机制。
3. 如何衡量一次互动是否真正成功？
直播间弹幕数量增加，并不能单独说明机器人互动体验更好。
对于技术团队，更值得关注的是有效指令比例、任务接受率、实际执行成功率，以及用户发出指令后多久能够看到结果。
可以分别记录以下关键时间：
- 观众发出互动请求的时间。
- 业务系统选中有效任务的时间。
- 机器人接收并开始执行任务的时间。
- 机器人报告动作完成的时间。
- 观众端播放到对应执行结果画面的时间。
通过这些数据，可以判断问题发生在弹幕聚合、任务队列、网络传输、机器人执行，还是最终的视频播放环节。
对于投票类互动，还可以观察投票参与率、任务完成后的留存表现及用户是否继续参与下一轮互动。
七. 写在最后
淘宝直播在 WTCC 2026 的这场云逛展，让机器人不再只是展台上的演示设备。观众通过弹幕选择动作、故事和服务内容，再通过直播观察结果，线上参与与线下执行由此建立了联系。
这类互动的核心，是建立一条可管理的任务链路：收集用户意图、选取有效任务、执行设备动作，再把状态和结果反馈给用户。
对于开发者来说，RTC 可以承担实时音视频连接，RTM 可以传递互动消息和设备状态，对话式 AI 可以让机器人理解更开放的表达，机器人本地系统则负责安全地完成具体动作。
当这些环节协同工作，直播间就不再只是展示现实世界的一块屏幕，也能够成为用户参与现实场景的一种交互入口。从弹幕游戏到机器人远程操控，从 AI 陪伴到互动教育，这套技术思路能够延伸到更多应用。但真正决定体验的，仍然是系统能否及时、准确、安全地完成用户所期待的交互。
