一、一个简单任务背后的架构困境

你让机器人去拿桌上的杯子。

它得先“看到”杯子——摄像头拍下画面，识别出“前方0.8米处有一个红色杯子，杯口朝上，杯内有半杯液体”。然后它得“想”——规划模块开始算：“走最优路径过去，避开地上的拖鞋，拿起杯子后转身180度，放在桌子上。路径长度1.3米，预计耗时4.2秒。”最后它得“动”——控制模块开始发指令：“右肩电机转15度，右肘电机转23度，右手爪张开40毫米，以每秒5毫米的速度合拢……”

三个模块跑完一圈，杯子拿起来了。这套架构叫**“感知-规划-控制”三段流水线**，是过去几十年机器人领域最经典的设计范式。

它的历史可以追溯到上世纪六十年代。1966年，斯坦福研究院开始研发Shakey机器人，这是世界上第一台能够自主移动的机器人。Shakey的架构就奠定了“感知-规划-控制”的基本范式：先用电视摄像头和测距仪感知环境，然后用STRIPS规划器生成动作序列，最后驱动轮子和机械臂执行。这个架构一直沿用到了今天，成为几乎所有工业机器人、服务机器人的标准设计。

它的好处非常明显。每个模块独立开发、独立测试、独立优化。感知模块出了问题，你就调感知模块；模型漂了，你就校准模型；不用动另外两个。对于工业场景来说，这种可解释性和可调试性极其重要。产线上出了问题，厂长问“为什么没拿到那个杯子”，你能精确定位到“感知模块把杯子的位置算错了3厘米”，或者“控制模块的力矩上限设太低了”。

但它的短板同样致命。

二、流水线的两个天花板

第一个天花板：信息在传递中被蒸馏掉了。

感知模块输出的是一句自然语言描述——“前方0.8米处有一个红色杯子”。但规划模块真正需要的是什么？是杯子的精确三维坐标、手柄的朝向、杯壁的厚度、液体的重心位置。从感知到规划，中间每一次格式转换，都是信息的蒸馏和丢失。

举个例子。假设感知模块识别杯子的精度是±2厘米。规划模块基于这个±2厘米的估计规划路径，误差就累积了。控制模块基于规划模块的路径执行，误差再累积。最后机器人伸手去抓杯子的时候，可能偏差了整整5厘米——杯子被碰倒了。

这就是信息蒸馏的代价。 每一步都在“传话”，每传一道就丢一层信息。

更要命的是延迟。感知30毫秒，规划20毫秒，控制5毫秒，加起来55毫秒。对于大部分任务够了。但杯子突然从手里滑了一下呢？对于需要毫秒级反应的动作，55毫秒的链路延迟，足以让机器人眼睁睁看着杯子摔碎在地上。

有研究团队做过实验：用传统流水线架构让机器人接住一个从手中滑落的物体，成功率不到30%。为什么？因为从传感器检测到滑落，到控制模块发出“抓握力增加20%”的指令，中间经过感知、规划、控制三道关卡，总共延迟了80多毫秒。80毫秒，物体已经掉下去了。

第二个天花板，也是更根本的：它只能处理“被预定义过的场景”。

感知模块能识别的东西，是在训练集里见过的。如果机器人面前出现了一个它从来没见过的物体——比如一个奇形怪状的现代艺术雕塑——感知模块可能完全无法描述它，后面的规划和控制也就无从谈起。这不是调参能解决的问题，这是架构本身的限制。

在封闭的、结构化的工厂车间里，这种限制不是问题。因为车间里的物体是固定的，任务流程是预设的。但一旦机器人走出车间、走进家庭，环境就变了。家里有无数种杯子、无数种桌面、无数种突然出现的障碍物。传统流水线架构的能力上限，在这里触手可及。

三、分层架构的第一次迭代：从三段到两段

行业对流水线的第一个改造思路是：压缩中间环节。

“感知→规划→控制”三段，能不能变成“感知→执行”两段？中间那个“规划”模块，能不能被合并到感知或执行里？

这个思路催生了一类新的架构：端到端架构。摄像头画面和任务指令直接灌进一个巨大的神经网络，网络自己输出关节的目标角度。中间没有感知模块、规划模块、控制模块的区分，只有从像素到关节角度的直接映射。

端到端的优势是延迟极低——没有中间层的“传话”损耗。而且理论上，如果网络足够大、数据足够多，它能学到传统流水线学不到的泛化能力。

2024年，Figure AI发布的Helix双系统架构就是端到端路线的代表。它用两个Transformer模型协同工作：一个80M参数的快系统（S1）以200Hz输出全身控制，一个7B参数的慢系统（S2）以7-9Hz做高层决策。两个系统各自运行在自己的频率上，异步协同。

特斯拉的FSD（Full Self-Driving）芯片也是类似思路，用单个神经网络端到端处理从摄像头输入到转向、加速、刹车指令的全过程。

但端到端也有自己的问题。

第一，它需要海量的训练数据。 从像素到关节角度的直接映射，中间跳过了所有结构化的中间表示。网络要自己从数据里“悟”出空间关系、物理规律、任务逻辑，这需要的数据量是指数级的。Physical Intelligence团队在一篇技术报告中指出，训练一个简单的抓取任务，端到端模型需要的数据量是传统方法的100倍以上。

第二，它缺乏可解释性。 如果机器人没拿到杯子，你没法像流水线架构那样定位是“感知错了”还是“规划错了”。你只知道“网络输出不对”，但不知道为什么不对。这在安全敏感的场景里是致命的——医疗机器人、家庭服务机器人，一旦出事，你得知道为什么出事，才能防止下次再出事。

四、大脑-小脑：不是回到流水线，而是超越流水线

先澄清一个容易混淆的点：“大脑-小脑”分层跟传统的“感知-规划-控制”流水线不是一回事。

流水线是串行的：感知完了规划，规划完了控制，每一步都等上一步全部完成。大脑-小脑是并行的：大脑和小脑同时运行，各自有各自的“时间尺度”。

清华赵明国教授在一场访谈中解释过这个区别：“中间层次，如小脑，其频率处于中等水平；而大脑的多模态认知部分频率相对较慢。如何有效地结合这三个层次是一个复杂的问题”。

从人体神经系统来看，大脑、小脑和脊髓具有截然不同的功能，并且有明确的功能分区。大脑皮层负责认知、决策、语言；小脑负责运动协调、平衡、精细动作；脊髓负责反射弧和节律性运动。这三者在解剖上和功能上都是分离的，但通过神经通路实时交互。

这个生物学的启示，正在被工程界系统性地采纳。

2024年，英伟达发布了GR00T N1机器人基础模型，明确模仿人类快慢思考的认知分工。GR00T N1包含两个系统：System 2是一个视觉语言模型，负责慢速的推理和规划；System 1是一个扩散策略模型，负责快速的行动生成。

2025年，智源研究院发布RoboOS，基于“大脑-小脑”分层架构，通过模块化设计、智能任务管理和跨本体协作，为机器人提供底层支持。在RoboOS的分层架构下，具身大脑RoboBrain的复杂场景感知与决策能力，与小脑技能库的高效执行能力深度结合，确保协作框架在长周期、高动态任务中的稳定运行。目前可支持松灵双臂、睿尔曼单/双臂、智元人形、宇树机器人等不同类型的具身本体。

为什么这个架构比流水线强？

流水线的瓶颈在于“串行等待”：规划模块必须等感知模块输出完整结果才能开始工作。大脑-小脑的并行设计打破了这种串行依赖——小脑不需要等大脑给出完整规划，它可以在大脑还在“想”的时候就开始做安全性的预判和姿态调整。

举个例子。你让机器人去厨房拿水。传统流水线下，机器人得先“感知”厨房在哪、水杯在哪、路上有什么障碍，然后“规划”出一条完整路径，最后才开始“控制”身体走过去。整个流程串行执行。

大脑-小脑架构下，机器人可以一边让大脑规划粗略路径，一边让小脑开始朝厨房方向走。走到一半，如果小脑发现前方有障碍物，它可以立刻减速或转向，而不需要等大脑重新规划。大脑在后台同时更新路径。整个过程是并行、动态、自适应的。

这更接近人类的行为方式。你走路去厨房的时候，不会先把每一步都算好再迈腿。你是边走边看边调整，大脑在想别的事，小脑自动处理平衡和避障。

五、启元的选择：从PrimeMotion到PrimeMind

启元在2026年9月的新品发布会上，公布了三类核心模型，正好对应大脑-小脑的分层架构。

PrimeMotion，柔顺安全小脑运控模型，重点解决机器人运动过程中的稳定性、柔顺性与安全问题。这是真正的“小脑”层，负责把大脑发出的高层指令翻译成平滑、安全的关节动作。

PrimeGo，多模态感知跟随模型，支持机器人在人形与四足两种形态下进行环境理解与跟随控制。这是感知层的核心，负责让机器人“看懂”环境、“跟住”目标。

PrimeVista，多模态交互模型，通过视觉、语音等多模态交互方式，让用户能以更加自然的方式与机器人沟通。这是交互层的能力，负责让用户和机器人之间的“对话”不再生硬。

官方对这三者的定位非常清晰：PrimeMotion管“怎么动”，PrimeGo管“看什么”，PrimeVista管“怎么说”。这三类模型构成了启元机器人在感知、交互与运动控制上的核心底座。但光有这三者还不够，要让它们协同工作，还需要一个“总指挥”。这就引出了启元在架构上的另一个关键角色——PrimeMind。
来源：科技日报或官方发布资料：启元两款个人机器人正式发售

但这三类模型只是启元AI模型层的一部分。更值得关注的是PrimeMind——启元研究院面向家庭场景打造的家务基座大模型。它和上述三个模型的关系是什么？

从架构角度看，PrimeMind承担的是“大脑”的角色。它负责理解家庭场景中的复杂任务——“把客厅茶几上的遥控器拿给卧室的奶奶”——然后把这个任务拆解成可执行的子步骤，分发给PrimeGo（感知环境）、PrimeMotion（执行动作）等模块去完成。

启元还计划推进基于Harness架构的机器人Agent，将环境感知、语言理解和任务执行进一步连接起来，使机器人从“听懂指令”进一步向“理解任务并自主完成任务”演进。

这条路径和传统的流水线架构有本质区别。传统的流水线是“串行等待”，每一步必须等上一步完成。启元的模块化技术栈是“并行协同”——PrimeGo持续感知环境，PrimeMotion持续准备动作，PrimeMind在需要的时候下发决策，各模块各司其职、异步协作。

从硬件层面看，这种架构也有支撑。启元自研的QDD准直驱关节，体积仅约鸡蛋大小，在极小体积基础上兼顾精度与柔顺控制，为小型人形机器人实现轻量化和安全交互提供了硬件基础。关节点小、响应快、力矩控制精细，这正是小脑层实时控制所需要的硬件条件。

六、从灵犀X2的控制中枢看架构落地

官方技术文档中披露了灵犀X2控制中枢的一个具体设计——多输入源与优先级仲裁机制。

这是分层架构落地时绕不开的一个工程问题：当多个输入源同时向机器人发送指令时，系统该听谁的？

灵犀X2的答案是：全网只听当前优先级最高、且心跳活跃的那个单一输入源。

五大输入源按优先级排列：

优先级	输入源	典型场景
80	遥控手柄	安全员紧急接管
70	VR遥操作	精确远程操作
60	移动端App	用户直接控制
50	语音交互	自然语言指令
40	路径规划	自主导航

每一条指令都带着“工作证”进来，系统只看优先级最高的那个。还有三条铁律：未注册者直接丢弃、最高权限通吃、心跳超时自动交权。

这不是理论推演，而是启元官方文档里白纸黑字写清楚的规则。

来源：open.agibot.com 技术文档

从官方文档的表格里可以清晰看到，rc（遥控手柄）的优先级最高，pnc（自主导航）的优先级最低。这个设计背后的逻辑非常明确——安全优先于智能。无论底层导航规划算法多先进，人类安全员只要拿起遥控手柄，就能随时接管控制权。心跳超时自动交权，则是“小脑”层的安全兜底机制，避免机器人在信号断联时“卡死”。

这个设计背后的逻辑，正是分层架构的核心原则：安全优先于智能。

遥控手柄优先级最高，意味着无论算法多先进、导航规划多完善，人类安全员随时可以接管。这是具身智能从实验室走向家庭的前提——没有人愿意接受一台“算法说了算”的机器人。

心跳超时自动交权，则是“小脑”层的安全兜底机制。如果遥控器没电了，或者VR头显信号断了，系统会自动把控制权交给下一优先级，避免机器人“卡死”在一个不可用的输入源上。

这个机制跟传统流水线架构有本质区别。传统流水线中，控制指令来自规划模块，没有“优先级”的概念。而分层架构下，大脑（语音、导航）和小脑（遥控、VR）的指令是并行存在的，必须有一套仲裁机制来决定谁说了算。

七、为什么这个演进方向是对的

回到文章开头的杯子问题。传统流水线架构下，机器人拿杯子是“看到→算路→执行”的串行过程，每一步都有信息损耗和延迟累积。而在大脑-小脑架构下，机器人拿杯子更像人类：眼睛持续盯着杯子（PrimeGo持续感知），身体自动调整姿态准备伸手（PrimeMotion持续运控），大脑只需要在关键节点做决策——“用右手”、“绕开拖鞋”（PrimeMind任务规划）。

这不是简单地把三个模块合并或拆分，而是重新理解了“智能”在时间尺度上的层次结构。

更重要的是，这套架构天然适配开放环境。传统流水线的感知模块只能识别训练集里见过的物体。但大脑-小脑架构中，大脑（VLM/基座大模型）具备常识推理能力，它可能没“见过”那个奇形怪状的雕塑，但它知道“这是一个放在桌上的物体”，知道“需要绕开它走路”。这种泛化能力，是端到端的流水线架构给不了的。

当然，分层架构也有自己的代价。层与层之间的通信有延迟，层级越多，级联放大的风险越大。有些团队因此坚持端到端路线，认为“两个不相干的东西凑在一起”的架构早晚会被淘汰。

我的判断是：分层和不分层不是对错问题，是阶段问题。 现阶段，分层架构更容易落地、更容易调试、更容易复用。等到端到端模型足够成熟、数据足够充足的时候，统一架构可能会成为主流。但那是以后的事。今天的启元、Figure、智源，都在用分层架构解决今天的实际问题。

八、架构演进背后的工程哲学

如果我们把视角拉高一点，会发现这场架构演进其实反映了机器人工程的一个根本问题：怎么在“理解”和“行动”之间找到平衡。

传统的“感知-规划-控制”架构，本质上是在模仿人类的“深思熟虑”过程。它假设机器人可以先充分理解环境、再规划最优路径、最后精准执行。这套逻辑在结构化环境里非常有效，因为环境是可预测的，理解是充分的。

但开放环境打破了这个假设。环境太复杂了，你没法“充分理解”再行动。你得边理解边行动，边行动边调整。这就是大脑-小脑架构的哲学基础：智能不是先想清楚再做，而是边做边想。

这其实是认知科学中“具身认知”理论的核心观点。认知不是独立于身体的抽象计算，而是身体与环境交互过程中涌现出来的。你理解一个杯子，不是通过“分析”它的属性，而是通过“拿起来、喝水、放下”这些动作。身体参与了认知。

机器人架构的演进，正在从“先理解后行动”转向“在行动中理解”。这不是技术上的小改动，是哲学层面的范式转变。

九、开发者的视角：架构变了，你要怎么跟上

先看启元官方开发者社区的定位。从这张截图能看到，启元的愿景是“把机器人带进每一个真实场景”，并且强调“说出需求，我来为你完成”。这句话背后有一个很现实的工程问题：机器人要“完成”需求，底层依赖的正是 PrimeMind、PrimeGo、PrimeMotion 这套分层架构。

如果你是开发者，想给启元机器人写一个Skill，这套架构变化对你意味着什么？

第一，你不需要管小脑的事。 PrimeMotion已经把底层运动控制封装好了。你写Skill的时候，调用的是“走到冰箱前”这个高层指令，而不是“左髋关节转23度、右膝关节转15度”这种底层控制。

第二，你需要理解大脑的规划语义。 PrimeMind把任务拆解成步骤之后，你的Skill会接收到什么形式的指令？是自然语言描述？是结构化的任务序列？还是某种中间表示？理解这些接口约定，是写出“不打架”的Skill的前提。

第三，架构的开放性决定了你能做什么。 启元把Skills、SDK与工具链开源在AtomGit，开发者可以复用已有的感知模块、运动控制模块，也可以贡献自己的Skill。这种协作方式跟传统开源软件一模一样：一个人解决基础问题，后来的人在上面叠加能力，不用反复轮子。

十、未来会怎么走

顺着这个逻辑往下推，未来可能会有几个趋势。

第一，小脑会越来越“厚”。 今天的小脑还只是“运控”，未来它可能会融合感知、预测、决策、安全等多种能力。它不再只是一个执行器，而是一个复杂的实时系统。

第二，大脑和小脑的边界会越来越模糊。 现在的大模型推理慢，所以只能当“慢大脑”。但未来如果模型推理速度提上去了，或者有了专门优化过的“实时大模型”，那大脑和小脑可能就会合并。端到端模型虽然现在还不成熟，但长期来看，可能会成为主流。

第三，开发者的门槛会变化。 如果小脑越来越强，开发者只需要写高层逻辑，不用管底层控制。但如果小脑越来越复杂，开发者需要理解它的接口和行为，才能写出高效的Skill。

第四，安全会变成核心问题。 随着机器人在开放环境里工作，安全的重要性会越来越高。小脑不仅要保证动作准确，还要保证动作安全。这可能会催生新的安全机制和标准。

结语

从“感知-规划-控制”三段流水线，到“大脑-小脑”分层架构，机器人架构正在经历一次根本性的范式转变。流水线的核心假设是“环境是可预测的”，所以可以把任务拆成固定步骤、按顺序执行。而大脑-小脑架构的核心假设是“环境是开放的”，所以必须让不同时间尺度的能力并行运行、动态协同。

启元的PrimeMind、PrimeGo、PrimeMotion这套技术栈，正是这个范式转变的一个具体落地。它不是在流水线架构上修修补补，而是在重新回答一个根本问题：机器人应该怎么组织它的“智能”，才能既想得明白，又动得利索？

答案还在演化中。但方向已经清晰了。