首页10月21日，在德国柏林举行的 NVIDIA GTC 2026 主题演讲上，黄仁勋带来了四只小鸭子。它们是由法国 Pollen Robotics（Hugging Face 旗下机器人团队）开发的双足机器人 Microduck。几只机器人在舞台上展示了坐下、起身等动作。这款机器人身高只有25厘米，却能完成多种需要平衡控制的动作。
根据 NVIDIA 官方技术博客，演示使用了 RTX Spark、Hermes Agent、Nemotron 3.5 Bolt 74B 和 Isaac Lab 等工具，让 AI Agent 参与机器人的仿真训练过程。
Microduck 是 Pollen Robotics 早在8月27日就公布了这款机器人，并开放了机器人控制、仿真环境和强化学习训练等软件代码。需要说明的是，其开源范围主要是软件栈，机械和电子设计文件并未开放。
Microduck 的有趣之处还不止这些。打开它的 GitHub 开源仓库，会发现开发团队不仅在研究如何让机器人学会走路，还设计了一套基于 WebRTC 的实时通信架构，用于传输摄像头视频、接收远程控制指令，并为双向音频和远程遥操作预留接口。
让机器人学会行动，需要 Physical AI 和本地运动控制；让人能够远程查看、操作机器人，则需要实时通信。如果进一步结合对话式 AI，机器人还可以通过自然语言理解人的需求，并结合摄像头画面和设备状态作出回应。
一. Microduck是如何学会走路的？
Microduck 身高25厘米，重量不足800克，配备15个电机、摄像头、深度传感器、两组惯性测量单元（IMU）和一个能够抓取小物体的活动鸭嘴。除了行走，它还能坐下、下蹲、从常见的跌倒姿态中重新站起，甚至借助配件完成滑行动作。
这些动作并不是靠开发者逐帧编写所有关节的运动轨迹实现的。Microduck 使用强化学习（Reinforcement Learning，RL）训练运动策略，再将模型部署到机器人本体。
1. 先在虚拟世界里练习，再让真实机器人执行
让双足机器人稳定行走并不容易。机器人每迈出一步，都需要调整身体重心、关节角度和运动速度。真实电机存在响应延迟，地面摩擦力会变化，传感器也可能产生误差。
如果完全依靠实体机器人反复试错，不仅训练速度慢，还可能造成硬件磨损或损坏。因此，Microduck 采用了 Sim-to-Real（从仿真到现实） 的技术路线。
在开发团队公开的 microduck_rl 项目中，开发者使用基于 MuJoCo 的 mjlab 仿真环境和 PPO 强化学习算法训练机器人。
例如，训练机器人向前行走时，系统会设置目标速度，并根据机器人是否保持平衡、是否按照目标方向移动、动作是否过于剧烈等情况给予奖励或惩罚。
通过大量仿真试验，模型逐渐学习如何协调不同关节，在保持平衡的同时完成移动。
为了让训练结果能够用于实体设备，开发者还需要模拟电机动力学、关节间隙和外界扰动，并通过域随机化（Domain Randomization）改变训练环境中的部分物理参数，减少仿真环境与真实环境之间的差异。
训练完成后，运动策略可以导出为 ONNX 模型，再部署到 Microduck 本体运行。
根据官方硬件资料及开源代码，Microduck 使用 Rockchip RK3566 平台，运动策略以 50Hz 的频率运行，相当于大约每20毫秒执行一次控制更新。
需要区分的是，NVIDIA 在 GTC 上展示的是使用 RTX Spark、Isaac Lab 和 AI Agent 辅助机器人训练的流程，而 Microduck 常规开源训练项目提供的是基于 MuJoCo、PPO 的实现。两者都涉及机器人训练，但不应被理解为完全相同的训练流水线。
2. AI Agent参与训练，但不负责实时计算每一步动作
过去完成一轮强化学习实验，开发者往往需要自行配置仿真环境、准备训练任务、调整参数，再根据结果修改训练方案。
在 NVIDIA 的演示中，AI Agent 参与了仿真环境构建与训练相关工作，帮助开发者完成部分原本需要手动执行的步骤。
但这并不意味着舞台上的 Microduck 正在依靠大型语言模型实时计算每一步怎么走。
机器人实际运动时，仍然需要本地策略模型与控制系统持续读取传感器信息，再输出相应动作。
大型 AI Agent 可以协助训练、任务规划或生成高层指令；具体到保持平衡、关节调整和安全保护，仍由本地系统负责。
原因很简单：语言模型回答慢一点，用户还可以等待；但机器人在行走过程中，如果错过关键的姿态调整时机，就可能失去平衡。
二. 一只会走路的机器人，为什么还需要WebRTC？
Microduck 已经可以通过游戏手柄或蓝牙连接进行控制。如果开发者就在机器人旁边，这些方式已经能够满足不少操作需求。
但如果用户希望通过手机查看机器人周围的环境，或者从另一处房间控制机器人移动，就需要持续获取摄像头画面、发送控制指令，并接收设备状态反馈。
如果还要进行远程对讲，则需要在机器人和用户终端之间传输双向音频。
为此，Microduck 开发团队设计了名为 mediad 的媒体服务模块。
根据其WebRTC 技术设计文档，开发团队计划使用 WebRTC 连接承载摄像头视频、音频及不同类型的控制数据。
其中一部分已经完成硬件验证。开发者在 Radxa Zero 3W 平台上验证了局域网 WebRTC 视频传输和基础控制通道，随后还完成了摄像头视频采集与 H.264 硬件编码链路。技术文档中记录的一次摄像头采集测试帧率约为29.3fps。
不过，完整双向音频、高频遥操作通道和公网远程接入等能力，仍有处于设计或持续开发阶段的部分，不能将整套远程互动方案视为已经全部完成。
1. 实时视频不只是为了观看
在 Microduck 的设计中，摄像头画面经过 H.264 硬件编码，再通过 WebRTC 传输到浏览器。
浏览器可以利用原生 WebRTC 能力接收和播放视频，减少专用视频播放协议的适配工作。不过，整个连接仍然需要媒体发送端、信令服务以及必要的网络连接管理。
相比每隔一段时间上传一张照片，连续视频更适合让远程用户观察机器人的位置、朝向和运动情况。
例如，用户通过手机遥控机器人在房间里行走，需要不断根据画面判断它是否靠近桌腿、是否遇到障碍物。如果视频画面明显滞后，用户作出的控制决定可能已经不适合机器人的当前位置。
因此，机器人实时视频除了画质，还要考虑端到端延迟、帧率、丢包、网络抖动及连接恢复能力。
Microduck 公开文档中的早期验证主要针对局域网。若要跨公网连接，还需要进一步处理 NAT 穿透、信令服务、必要的 TURN 中继，以及用户和设备的访问权限管理。
2. 控制指令也需要区分传输方式
Microduck 的 WebRTC 设计里还有一个值得关注的细节：开发团队规划了两种不同用途的 DataChannel。
第一种是 control，采用可靠、有序传输，主要用于机器人 API 请求和需要确认执行结果的控制操作。
例如，用户要求机器人坐下，或者修改设备配置，系统需要确保请求按正确顺序处理，并返回相应结果。
第二种是 teleop，面向连续遥操作和高频状态反馈，设计为不可靠、无序传输，避免因为旧数据重传而影响最新控制指令的及时处理。
这两类指令对网络的要求不同。
假设用户正在通过虚拟摇杆控制机器人转弯。一条较早的方向指令由于网络抖动，在80毫秒后才到达。如果机器人此时已经收到更新的方向指令，再执行那条旧指令，就可能突然朝错误方向移动。
对于连续遥操作，及时处理最新的有效控制指令，往往比保证每一条旧指令都成功送达更重要。
但不可靠、无序传输并不意味着系统会自动选择最新指令。Microduck 的设计文档还提出，需要为高频控制消息增加序列号，并丢弃晚到的旧消息，防止过期指令覆盖新的控制意图。
目前，Microduck 优先实现的是基础 control 通道，teleop 高频遥操作通道仍属于后续规划。
这种设计取舍也适用于其他需要远程操作的设备，例如巡检机器人、移动摄像头和服务机器人。
3. 远程连接还必须解决访问鉴权
Microduck 的开源文档还披露了一个容易被忽略的问题：早期局域网 WebRTC 实验方案没有完整的机器人端访问鉴权机制。
按照文档描述，能够访问设备信令服务的同一网络内终端，可能建立连接、查看摄像头画面并发送控制请求。
这样的设计可以简化开发环境中的连接测试，但不能直接用于需要严格隐私和访问控制的家庭或商业场景。
WebRTC 能够通过加密机制保护传输中的媒体和数据，但传输加密并不等于业务访问授权。一条通信链路即使是加密的，系统仍需要判断连接者是否有权查看画面、操控设备。
Microduck 的远程连接设计考虑通过账户认证和桥接服务管理设备访问权限。但这些设计不能代替正式产品上线前的完整安全验证。
对于面向用户的智能机器人，开发者通常还需要实现设备绑定、用户身份验证、控制权限分配、会话管理，以及在异常连接情况下停止远程控制的机制。
三. 远程连接与机器人本地控制，为什么必须分开？
即使能够建立低延迟连接，也不意味着机器人可以完全依靠云端完成运动控制。
Microduck 的架构将运动控制与媒体传输分为不同模块。远程系统向机器人发送高层运动意图，而具体的关节调整、平衡控制和安全判断由本地控制系统处理。
例如，用户可以要求机器人“向前移动”“转向左侧”或者“坐下”。机器人如何调整电机、保持身体平衡，以及当前状态是否允许执行相应动作，仍由本地系统决定。
这样设计有一个实际好处：即使网络暂时中断，机器人也不必因为失去云端的连续动作指令而立即丧失本体控制能力。
根据 Microduck 的系统架构文档，其本地控制模块负责运动、安全约束和传感器处理，外部模块不能绕过本地安全机制直接控制电机。
需要注意，这份架构文档部分内容属于开发团队规划的目标设计，不代表所有保护机制都已经在最终量产硬件上完成验证。
不同任务，需要不同的信息更新频率
Microduck 本体运动策略以50Hz运行，并不意味着云端 AI Agent 也必须每20毫秒接收一帧图像或作出一次决策。
对于真人远程操作，连续视频能够帮助操作者及时观察环境并调整动作。
但对于不要求连续视觉反馈的 AI 任务，例如“看看桌上有没有水杯”，系统可能只需要按需获取摄像头画面，再结合设备状态进行分析。
Microduck 的 WebRTC 设计文档也讨论了类似方案：服务器端程序可以按需获取原始图像，而不一定要持续接收并解码完整的高帧率 H.264 视频流。
这样可以减少不必要的网络传输和编解码开销。
但如果任务涉及避障、视觉伺服或其他高频闭环控制，就不能简单地降低图像采样频率。相关感知与控制链路需要根据任务的响应要求单独设计。
另一个值得关注的问题是视频与传感器状态的时间同步。远程用户看到的画面、机器人上传的位置和姿态信息，可能存在不同程度的延迟。如果缺乏统一时间戳，就很难准确判断某个动作对应的是哪一时刻的视觉环境。
Microduck 的开发文档已经讨论了这一问题，但完整的跨数据流时间同步仍有待进一步完善。
对于需要精确远程操控的机器人，视频延迟、控制延迟以及状态数据的时序关系，都需要纳入系统设计。
四. 如果让Microduck听懂人说话，还需要补上哪些能力？
Microduck 当前的主要定位，是一款面向强化学习与 Physical AI 开发的双足机器人。
它具备摄像头、麦克风、扬声器及运动控制硬件，也为远程音视频交互预留了接口。不过，不能据此认为它已经实现完整的自然语言理解、实时视觉推理和语音驱动动作控制。
如果开发者希望让它进一步成为能够自然交流的机器人，还需要将语音理解、多模态感知与设备任务系统连接起来。
例如，机器人在客厅活动，用户问：“小鸭子，你看到我的水杯了吗？”
系统首先需要获取用户语音，识别问题，再结合摄像头画面判断是否存在水杯，最后通过语音给出回答。
如果用户继续说“走近一点，我看不清”，系统还需要理解新的请求，并将经过权限和安全检查的运动意图交给本地控制系统。
这涉及语音识别、视觉理解、对话管理和动作执行之间的协同。
1. 听清用户说话，还要知道什么时候该回答
机器人可能在客厅、教室或商场等环境工作。电视声、其他人的说话声，以及设备自身发出的声音，都可能进入麦克风。
如果系统无法区分用户语音与环境声音，就容易被无关声音干扰，甚至误触发任务。
与此同时，用户说话时也经常停顿。
例如，用户说：“你先到桌子旁边……算了，还是过来吧。”
如果机器人刚听到“桌子旁边”就开始执行移动任务，后面还需要取消原来的动作，并处理用户最新的指令。
因此，机器人语音交互除了 ASR 识别，还需要考虑轮次检测、用户打断、任务取消和状态管理。
声网对话式AI引擎提供实时语音交互、选择性注意力锁定、优雅打断，以及主流 ASR、LLM、TTS 模型适配能力，可以用于构建智能硬件的自然语音交互系统。
其中，选择性注意力锁定可以帮助系统在多人和噪声环境中聚焦目标说话人；轮次检测和打断处理则有助于避免机器人过早回答，或在用户已经改变需求时继续播放旧回复。
不过，语音模型识别出的动作请求仍需要经过业务层校验，不能直接绕开机器人本地的控制与安全机制。
2. 让机器人理解眼前的环境
很多机器人任务无法只靠语音完成。
例如，“看看桌上有什么”“前面是不是有人”“帮我确认门口有没有包裹”，都需要结合摄像头画面和设备状态。
声网对话式 AI 引擎支持结合图像或实时视频进行视觉理解，开发者可以基于相应能力构建语音与视觉协同的交互应用。
但视觉模型的判断并不一定始终准确。
假如模型认为前方没有障碍物，而机器人本地距离传感器检测到了物体，就应该优先遵循本体安全规则。
对于具备真实运动能力的设备，更合理的分工是：语音和视觉模型负责理解用户需求、分析环境和提供高层任务建议，本地运动控制系统负责具体动作执行与安全保护。
这样既能利用大模型的理解能力，也能避免将所有即时运动决策交给远端服务。
五. 从Microduck看，RTC与对话式AI如何接入智能硬件？
Microduck 的开源项目提供了一个具体的工程参考：机器人本地运行运动策略，通过通信接口接收外部指令，并使用 WebRTC 实现视频传输和基础控制连接。
对于面向消费者的陪伴机器人、教育机器人或家庭服务设备，开发者还需要处理公网连接、移动 App、双向语音、设备状态同步、多模态 AI 接入及访问权限等问题。
这些能力并不需要全部由机器人本地控制程序承担。
1. RTC负责把人与设备连接起来
以家庭陪伴机器人为例，用户可以通过手机查看机器人摄像头拍摄的画面，与设备进行双向语音交流，也可以远程发送移动、转向等控制请求。
这些操作涉及两类数据：摄像头和麦克风产生的实时音视频，以及用户发送的控制指令和机器人返回的状态信息。
在声网的技术体系中，RTC 实时音视频可以承担音视频传输，RTM 实时消息则可用于控制信令和设备状态同步。
声网的智慧人居解决方案覆盖家庭陪伴机器人、服务机器人等智能硬件场景，涉及实时视频查看、双向语音对讲和远程控制等应用。
对于需要更复杂远程操作的设备，声网还提供了机器人远程操控与实时互动解决方案，通过实时音视频与控制信令协同，让操作者观察设备周围环境、发送指令，并接收设备反馈。
不过，RTC 和 RTM 负责的是远程连接与信息传递。机器人如何执行动作、保持平衡，以及在网络断开时采取什么安全措施，仍需要本地控制系统负责。
这里也要区分两套技术实现：Microduck 使用的是 Pollen Robotics 自行设计的 WebRTC 与 DataChannel 架构。声网 RTC、RTM 与平行操控方案提供的是其他机器人开发者可以根据需求选择的技术路径，不能将两者视为相同的具体实现。
2. 对话式AI负责让设备理解和回应用户
如果机器人还需要聊天、识图、解释环境或者完成语音任务，就可以在实时音视频连接基础上增加对话式 AI 能力。
声网的对话式AI硬件开发套件面向 AI 陪伴、教育、家居和可穿戴设备等场景，提供实时语音交互、视觉理解与主流模型适配能力。
对于配备摄像头和运动机构的机器人，可以结合业务需求设计相应的交互流程。
例如，用户要求机器人去门口看看是否有包裹。Agent 首先理解用户请求，再由业务系统判断任务权限和设备状态，将经过校验的高层指令提交给机器人控制系统。
机器人执行观察任务后，可以将摄像头画面或识别结果返回给 Agent，再通过语音向用户说明情况。
如果移动路径受阻、任务无法执行或者网络连接中断，系统应当停止相应操作，并向用户反馈实际状态，而不是继续声称任务已经完成。
这种应用需要实时音视频、对话模型、视觉理解和机器人任务系统共同配合。接入对话式 AI 引擎能够帮助开发者处理自然交互部分，但设备动作编排、权限管理和安全控制仍需要根据具体机器人平台自行实现。
3. 真正落地时，还要考虑设备资源和运行环境
智能硬件接入 RTC 与 AI 服务后，还需要面对设备本身的资源限制。
首先是计算能力和功耗。小型机器人无法无限增加本地算力，哪些任务由端侧处理、哪些交给云端模型，需要结合芯片性能、网络条件和电池续航决定。
其次是网络稳定性。家庭 Wi-Fi、移动热点和户外网络条件差异很大。实时视频延迟可能影响远程观察，控制消息延迟则可能影响设备操作，因此需要针对目标网络进行测试。
最后是安全与隐私。机器人通常配备摄像头和麦克风，系统需要明确设备什么时候采集音视频，哪些用户可以访问，以及远程控制权限如何授予和撤销。
尤其对于具备运动能力的机器人，实时连接不能绕开设备本体的安全约束。
六. 写在最后
Microduck 的开源架构将运动控制、媒体传输、蓝牙通信和设备更新拆成不同模块。这种设计使不同服务能够相对独立地运行，也方便开发者分别测试和改进。
黄仁勋在 GTC Berlin 展示的是 AI Agent 如何参与机器人训练。Microduck 的开源文档则提供了另一部分工程细节：人如何通过实时视频观察机器人、怎样传递控制指令，以及如何将远程通信与本地运动控制分开。
这些设计对陪伴机器人、教育机器人和远程操控设备都有参考价值。
运动策略决定机器人如何保持平衡和完成动作；RTC 帮助用户与设备建立实时连接；对话式 AI 则可以进一步处理语音、视觉和自然语言任务。
但无论增加多少 AI 能力，机器人最终能否安全、稳定地运行，仍然取决于本地控制、网络通信和业务逻辑是否配合得当。
相比只看舞台上四只机器人鸭子的动作表演，Microduck 公开的训练代码、WebRTC 实现和系统设计文档，为开发者提供了更多值得研究的实际问题。
参考资料
- NVIDIA：GTC Berlin 2026 Keynote 官方回顾，Brian Caulfield，2026年10月21日。
- NVIDIA：Bringing the Spark to Europe，Gerardo Delgado，2026年10月21日。
- Pollen Robotics：Meet Microduck，2026年8月27日。
- Pollen Robotics：Microduck Press Kit，官方硬件规格及开源范围说明。
- Pollen Robotics：Microduck 开源软件项目，GitHub。
- Pollen Robotics：microduck_rl 强化学习项目，GitHub。
- Microduck：WebRTC Sessions, Signalling and Control Channel，WebRTC 技术设计与测试记录。
- Microduck：Robot Daemon — Overall Architecture，系统架构设计文档。
