提到人形机器人这两年圈内人讨论最多的词就是“大脑、小脑”。你去任何一场机器人展会都会听到厂商在讲“我们的大脑多聪明、小脑多稳”可真要追问一句“大脑和小脑到底怎么分工边界在哪”很多人其实讲不清楚。这篇文章我就从一个完整系统的角度把大脑、小脑的划分逻辑、硬件选型、软件栈、协同方式全部拆开聊一遍同时也整理一些我在实际项目里踩过的坑。想深入了解人形机器人技术底层的工程师、产品经理、投资人或者刚开始接触这个领域的同学都可以通过这篇文章建立一套比较完整的认知框架。1. 先搞明白大脑和小脑在这套系统里到底指什么1.1 从人体解剖学借来的比喻机器人体系里怎么落地人形机器人的“大脑”和“小脑”是从人体解剖学借来的说法。人在做动作的时候大脑负责思考“我要干什么”小脑负责协调肌肉让动作稳定、平滑、不摔倒。机器人把这套分工映射到计算系统上就变成了两条非常清晰的技术路线一条偏人工智能、偏感知决策另一条偏控制理论、偏实时计算。很多行外人对这个划分有误解觉得“大脑就是系统里那台最强的电脑小脑就是次要的处理器”。实际上大脑和小脑在本体上的算力差距可能很大但重要程度是一样的。大脑错了机器人可能不知道怎么干活小脑不稳机器人根本干不成活。我在实际项目里见过太多方案只把精力砸在大脑模型上小脑随便跑个 PID 就上真机结果走出去三步就倒回头又怪关节电机不行——那其实冤枉了硬件。1.2 大脑管的事感知、理解、规划、决策大脑这层通俗讲就是“知道自己要做什么想清楚先干什么后干什么”。它的核心能力包括几个方面一是环境感知机器人要用相机、激光雷达、深度传感器去建立对周边世界的理解识别出桌子、椅子、苹果、人这些物体的位置和姿态二是语义理解当人跟它说“把桌上的苹果拿给我”它不能只听到一串语音而是要理解“苹果”“桌”“拿给我”这几个语义概念之间的关联三是任务规划理解完语义之后它得把“拿苹果”拆成一串子任务“走到桌前、伸出手、抓住苹果、收手、放到人手上”这串子任务的顺序和优先级就需要大脑来决策。在大模型时代大脑的能力基本都靠神经网络。语言理解用大语言模型视觉感知用视觉语言模型甚至现在热门的 VLAVision-Language-Action模型直接把“眼睛看到的画面 人给的指令”映射成“要执行的动作”。这一层的特点是计算密集、模型巨大、思考偏“慢”运行频率可能只有十几赫兹到几十赫兹数据吞吐量却非常大。它解决的是一个“做对的事情”的问题。1.3 小脑管的事稳定、平衡、协调、实时响应小脑这层通俗讲就是“怎么把大脑的意图变成身体上每一块肌肉的动作”对机器人来说就是怎么把高层指令变成每个关节0.001秒级别的力、位置、速度指令。它要处理几件核心的事第一个是平衡机器人在行走、转弯、被推一下的时候要持续判断当前身体姿态通过调整脚底落点、髋关节力矩让重心始终落在可控范围内第二个是运动协调走路的时候左腿迈出去右腿要同步配合手臂摆动还要跟步频匹配不能各动各的第三个是力与位置的混合控制比如抓鸡蛋位置不能用死劲力要刚刚好这套控制思路跟传统工业机械臂一脉相承但到了双足或者四足机器人身上难度要翻好几倍。小脑的核心特征是“实时”。控制周期通常都在1毫秒左右甚至更短也就是1000Hz级别的刷新率有的高性能力控整机会跑到几kHz。这一层的特点跟大脑刚好相反计算逻辑相对固定模型参数没有那么大但必须确定性极高绝不能因为内存回收或者系统调度慢了半拍导致某个关节指令晚到了2毫秒那样整台机器可能就会一哆嗦甚至倒地。1.4 大脑和小脑的分界线到底画在哪里一句话概括分界线不在硬件上而在控制频率和决策层级上。大脑负责低频、高维、语义化的决策给出来的东西是“任务意图”比如“走到坐标(2.3, 1.8)的位置”小脑负责高频、低维、物理化的执行接收到的输入必须是“关节角度、关节力矩、躯干姿态”这类可以直接被执行器和电机响应的量。这里有一个在工程中特别重要的概念叫“控制层级”。从上到下可以拆成语义层大脑运动规划层中间层伺服控制层小脑。有些方案会在大脑和小脑中间再放一个运动规划器把大脑输出的“意图”转成一条条可执行的运动轨迹再交给小脑去闭环执行。所以严格来说真正卡在大脑和小脑之间的是一整套“指令接口”和“运动原语”的设计。这个接口的好坏直接决定了整个系统能不能有效率地联动。2. 硬件平台的分工逻辑选型背后不只看算力2.1 大脑硬件为什么大家都在堆 GPU 和 NPU大脑这层的硬件选型这几年其实变化很大。早期人形机器人还会用普通的工控机加 CPU 跑算法到了大模型时代基本都切换到高算力嵌入式平台或者车载级计算平台了。目前市面上比较多见的方案包括 NVIDIA 的 Jetson AGX Orin、Thor以及一些国产的昇腾、地平线系列芯片。这些平台有几个共同特征带强大的 GPU 或 NPU 模块用来跑神经网络推理内存带宽高因为视觉模型的输入动辄就是几百MB甚至上GB的图像点云数据有相对丰富的 IO 接口可以接相机、麦克风、激光雷达。需要注意的是大脑平台的“算力强劲”往往是相对的——你就算堆到几百TOPS算力真跑一个多模态大模型推理延迟也照样要几百毫秒。所以实际工程里大脑平台还会做很多优化比如模型量化、算子融合、只跑精简版模型等等。还有一个被很多人忽略的点功耗和散热。像Jetson AGX Orin这种平台跑满负载的时候整板功耗可以冲到60瓦甚至更高在机器人身上这个功率可不是随便就能白拿的。电池容量就那么大大脑多耗1瓦续航就少几分钟。所以大脑硬件的选型本质上是在算力、功耗、散热、部署空间四者之间做权衡。2.2 小脑硬件为什么偏要用 MCU 和 FPGA 这些“老家伙”小脑这层硬件跟大脑完全是另一套思路。它不追求“算得过来”追求的是“算得准、算得稳、算得及时”。所以很多整机方案里小脑用的是实时微控制器MCU、数字信号处理器DSP、FPGA甚至在某些超高频的力控关节上直接用带专用数学加速器的伺服控制芯片。常见的品牌包括ST、瑞萨、TI、Microchip以及赛灵思现在并入AMD的FPGA产品线。为什么不用一颗大算力SoC把小脑也干了核心原因是实时性和确定性。Linux这种通用操作系统进程会被调度器来回切换一个高优先级任务被顶掉几百微秒是常有的事一旦控制周期出现抖动机器人关节的力矩曲线会立刻变形轻则抖动发热重则失稳摔倒。小脑控制器一般跑的是RTOS实时操作系统比如FreeRTOS、RT-Thread、VxWorks甚至直接上裸机裸奔程序逻辑跑在一个固定节拍里不到时间不执行到了时间必须执行这种确定性是OS级别就保障的。小脑硬件还有一个很关键的指标通信时延。大脑到小脑之间要传数据从总线到中断响应每跳延迟都要控制到微秒级。这也是为什么工业界偏爱EtherCAT总线的原因。EtherCAT在100Mbps网速下就能把同步周期压到1毫秒以内抖动在微秒级而且它支持分布式时钟同步可以让全机身几十个关节在同一时刻去采样和输出。相比之下如果走普通TCP/IP以太网延迟和抖动完全不可控小脑根本没法干活。2.3 整机架构里的大脑、小脑、执行器三层模型从整机看现在主流人形机器人的计算架构基本是三层的。第一层是大脑计算单元跑Linux系统负责感知、语义、任务规划挂在机器人的头部或者腰部第二层是运动控制器通常就在机器人背部或者胸口位置跑RTOS负责人体的平衡、步态、全身运动控制第三层就是遍布全身的关节执行器包括电机驱动器、编码器、力矩传感器驱动器自身有的还带一层很小的控制MCU负责电流环和速度环的快速控制。这三层之间的通信链路也很有讲究。大脑和小脑之间通常走高速以太网或者PCIe因为要传图像、点云这类大块数据小脑和各个执行器之间走EtherCAT或者CAN/CANopen因为要保证确定性的低延迟同步。关节驱动器的电流环刷新频率通常是最高的可能到十几kHz甚至几十kHz速度环和位置环稍微低一些再往上是全身运动控制层的1kHz规划。刚开始接触这个领域的人很容易把注意力都放在“总算力”上觉得算力越强机器人就越聪明。实际上一套完整的人形机器人系统决定它能不能走稳、能不能干了活的往往是“计算架构能不能在确定性的时间内把数据送到该去的地方”。你在大脑里放一个最强GPU但是小脑到关节的链路延迟不稳机器人照样站不住。3. 软件和算法栈大脑的“慢思考”与小脑的“快反应”3.1 大脑侧的算法栈从感知到任务规划怎么做大脑侧的软件栈往前推几年还是很传统的模块化Pipeline感知出一个模块、定位一个模块、导航一个模块、行为决策一个模块模块之间靠消息通信对接起来。这两年大模型来了以后整个大脑的架构被重构了一遍很多团队开始走“多模态大模型 视觉语言模型 任务规划器”的路线。拿“把桌上的苹果拿给我”这个任务举例。大脑的流程大致是先用语音识别把人的话转成文本再通过大语言模型分析出意图是“拿取动作”、目标是“苹果”、约束是“给我这个人”同时视觉感知模块实时检测桌面上的物体把苹果的坐标框出来下一步一个任务规划模块会把“拿苹果”拆成“移动到桌前、伸出右臂、调整手部姿态、闭合手指抓取、收回手臂、递出”这样一串子任务。拆完之后大脑才把第一个子任务“移动到桌前”转成一条指令发给运动规划层。这里面有一个工程上容易被忽视的点人形机器人的大脑还必须包含一个“可执行性校验”的环节。模型不是万能的它可能规划出一个桌面上没有苹果的动作也可能在“弯腰捡东西”这个动作时没考虑机器人的关节限位导致规划出来的目标位置根本够不到。成熟的系统会在大脑输出指令之前加一个参数校验器至少判断目标坐标是否在可达空间内、当前关节状态是否允许执行这个动作。3.2 小脑侧的算法栈平衡、步态、全身控制小脑侧的算法是控制理论和机器人学的硬核领域。先说平衡经典做法是基于简化模型的比如线性倒立摆模型LIPM把机器人看成一根倒立摆腿部电机提供的力就是维持不倒的支撑力通过调整脚尖触地点和支撑力作用点把重心控制在支撑多边形内部。在此基础上很多团队会接一个模型预测控制MPC在预测时域内规划重心的运动轨迹然后再用全身动力学控制WBC把重心的运动需求分配到全身各个关节的力矩上。这里面有一个很关键的计算问题全身控制WBC本质上是一个带约束的优化问题要在每个控制周期内求解也就是要在1毫秒内解完而且解出来的关节力矩必须落在物理可行范围内不能超过电机峰值力矩也不能违反脚底摩擦力锥的约束。这个问题放在通用CPU上裸煮经常是来不及的所以许多团队会在小脑控制器上做大量数学优化比如用QP求解器专门跑稀疏矩阵或者把一些固定结构的计算直接用FPGA硬核加速。再说步态规划。双足行走的步态规划说复杂很复杂要考虑步长、步频、抬脚高度、落脚点方向几乎每个参数都会影响稳定性说简单也简单本质上就是“在保证重心投影不超出支撑多边形的前提下用一组周期性的状态轨迹让两条腿交替支撑身体前进”。但真到了不平整地面、楼梯、斜坡这些场景光靠周期性步态就不够用了得加地形感知和落脚点重规划这也是为什么现在大家越来越强调“大脑小脑要联动”的原因。3.3 大脑输出给小脑的到底是什么格式这是我最常被问到的问题也是很多项目团队内部扯皮最多的地方。大脑到底以一串什么格式的内容告诉小脑干活目前行业里大概有三类方案。第一类是运动原语。大脑输出“走方向转角、目标距离、期望速度”这样的高度抽象指令由小脑去生成相应的步态轨迹。这类方案的好处是大脑很省心小脑自主能力要求高适合在比较复杂的非结构化环境中用。第二类是轨迹点序列。大脑直接给出一条末端或者关节级别的轨迹序列小脑负责把这条轨迹跟踪得稳稳的。这类方案的好处是大脑对动作的精细度控制强但一旦环境变化轨迹跟不上小脑就会死磕到摔倒。第三类是端到端动作也是目前VLA模型最喜欢用的方式。大脑模型直接输出下一时刻关节目标角度或者手臂末端位姿频率可能只有20到50Hz小脑接收以后再做一个高速插值和平滑然后去闭环执行。需要特别强调的是大脑输出的频率和小脑执行频率是天然不匹配的。大脑可能每秒只发10条指令小脑每秒要执行1000次控制这之间的差值必须靠一个插值器或者轨迹缓存模块来填平。这个模块如果设计不好就会出现机器人动作一顿一顿、甚至急启急停的现象。我见过一个团队在做端到端控制时大脑输出的关节角度变化非常剧烈插值器没有做速度限幅导致电机的电流冲击直接把关节减速器磨坏了。3.4 大模型时代的新变化VLA与小脑怎么配合VLAVision-Language-Action模型是这两年最热的方向很多人觉得有了VLA小脑就可以下岗了。说实话这种观点在圈内人看来是站不住的。VLA确实让机器人看到了“端到端学习”的希望你给它看大量人类演示数据它就能学会看画面输出动作。但VLA输出的动作目前离可以直接驱动关节伺服还有很大的差距。首先VLA的推理频率太慢了受限于大模型的计算量一两百毫秒出一帧动作已经算快了但小脑需要的控制刷新率是几毫秒一次。所以VLA的输出不可能直接作为关节伺服指令中间必须有小脑去做高频平滑和稳定控制。其次VLA对物理世界的理解是统计性的它不知道机器人当前电池电压多少、电机温度多高、脚底打滑程度如何这些物理量恰恰是小脑里状态估计和控制律最擅长的领域。最后VLA没有紧急兜底能力你不可能让一个大模型1毫秒内去响应“即将摔倒”这种紧急事件。所以我在项目里的经验是VLA这类大模型是大脑侧的技术升级它替代的是传统感知加规划那一套复杂Pipeline但小脑的实时控制层不仅不会消失反而变得更加重要。没有小脑的稳固支撑VLA学得再好真机也跑不起来。反过来小脑再稳如果没有大脑的智能调度机器人的行为就会显得呆板、没法处理复杂任务。两者是配合关系不是替代关系。4. 行业现状与工程落地要权衡的事4.1 国内外的技术路线差异到底在哪如果把全球主流的做人形机器人的团队摆在一起看会发现两条比较明显的发展路线。一条是“模型驱动派”代表是Figure、1X、智元、宇树等他们的特点是强调数据、强调端到端学习、强调大模型在整机中的核心作用另一条是“控制驱动派”代表是早期波士顿动力在液压驱动时代靠极其硬核的动力学建模、模型预测控制和全身力控做出惊艳的动作能力。但这两年两条路线明显在快速融合。波士顿动力转为电驱之后同样也在引入更多的学习和感知组件Figure这种主打AI模型的团队也在持续补强底层控制不然真机跑不起来。国内几个头部团队包括宇树、智元、星动纪元基本都形成了“大脑团队做数据训练小脑团队做运动控制”的分工格局。从工程实践看融合的原因也很现实单靠模型驱动机器人的稳定性和安全性很难保证单靠传统控制任务泛化能力太差换个环境就干不了活。对创业团队来说明智的做法是先用小脑把机器人的运动能力做扎实让机器人至少在实验室里能走能跑再去叠加大脑的能力这样每一步的成果都是可见的、可验证的。4.2 软硬解耦是不是真的可行近几年“软硬解耦”被提得很多很多公司都在对外强调自己的平台支持“大脑可插拔”“小脑可替换”。这个概念本身没错但我必须给同行们提个醒软硬解耦是有边界的不是简单的“接口定义好就万事大吉”。大脑和小脑之间确实应该有一个稳定的接口协议这样大脑团队升级模型不用动小脑代码小脑团队优化控制律也不用惊吓大脑。但是人形机器人是强耦合系统大脑输出的运动原语要想被小脑完美执行大脑侧必须理解小脑的能力边界。你大脑让机器人跨过一个1.2米的障碍物小脑就算控制律再强硬件条件也做不到。所以接口协议里必须包含“能力描述”和“可执行性反馈”简单说就是小脑要告诉大脑“我能干什么、不能干什么、刚才那个指令我认为完不成”。我在和几个整机团队交流时大家都有一个共识软硬解耦做得最好的团队往往不是把接口做成最简单的空壳协议而是在接口里嵌入了对机器人运动能力、关节限位、碰撞检测、状态机的描述。这样的接口才有真正的解耦价值。4.3 云端大脑与端侧小脑的分工和“算力焦虑”的解法另一个行业里讨论很多的话题是把大脑放在云上跑。具体做法是机器人本体上只保留小脑和最低限度的应急感知模块负责实时的运动控制和保命而重计算的大模型跑到云端通过5G或者WiFi把推理结果下发到机器人上。这个方案最大的好处是不用背着几十瓦的GPU到处跑本体续航和发热都能缓解。但问题也很明显通信的延迟和稳定性不能保证。哪怕5G网络平均延迟只有20毫秒偶尔一个断流或者抖动就可能导致机器人接收不到下一步指令在原地发呆甚至失去跟环境交互的能力。所以目前比较稳妥的做法是“混合架构”机器人本体上有一个中等算力的端侧大脑处理基础感知和低时延决策任务重量级语义理解和大规模的场景推理才走云端。云端掉线了端侧大脑还能保证机器人安全地站在那里或者执行“回到上一步安全状态”的降级动作。这个思路说白了就是大脑要分层小脑一定在端侧绝对不能把保命的实时控制放到云上去。4.4 功耗、散热、续航这些“不性感”的指标往往决定成败人形整机项目的行业共识是技术能不能落地往往不是看模型多惊艳而是看整机的功耗和热设计扛不扛得住。一台人形机器人关节多、传感器多、计算单元多光是站起来保持平衡功耗可能就要上百瓦一旦走路、干活峰值功耗更是惊人。大脑硬件是整个系统的功耗大户。跑一个大模型的Jetson级别平台功耗轻松上50瓦外接高分辨率相机、点云处理又是一笔开销。小脑部分虽然单板功耗相对低但是全机身二三十个关节的驱动器每个瞬时峰值可能都要几十安培的电流加起来对电池和散热系统是极大的考验。更麻烦的是热设计。机器人的结构紧凑没有地方装太大的散热片风扇又会引入噪声和可靠性问题。我看到不少原型机实验室跑半小时就发热降频大脑算力直接打七折小脑也因为热保护把关节力矩限制住。这种问题在Demo里不会暴露一旦连续工作就开始显现。所以做整机的团队基本都会在功耗预算上精打细算能跑轻量模型的绝不上重模型能省一瓦是一瓦。5. 实操中常见的坑以及我自己的几条体会5.1 实时性被严重低估控制周期抖动是第一个坑我见过不止一个团队在小脑控制上跑Linux加ROS一开始直走没问题就去跑更复杂的动作结果机器人莫名其妙抖动排查下来发现是Linux调度带来了几十毫秒级的偶发延迟。小脑控制必须跑在RTOS或者裸机上这件事没有任何妥协空间。哪怕你用了实时抢占补丁也不能保证绝对确定性真要在关键时刻实时响应就得从OS层去保障。5.2 大脑输出“看似合理”但“根本不可执行”的指令大模型生成的任务规划经常在语义上很顺畅但落到实际就出问题。它可能让你走到一堵墙前面再“伸手拿苹果”但苹果明明在你身后也可能让机器人把手臂伸到关节限位之外的位置。解决这个问题的办法是在大脑指令下发之前加一层可执行性校验套用一些基础的运动学和碰撞检测算法先把这个动作在虚拟空间里模拟一遍确认安全了再发给小脑。这一步看着笨实际非常能省事。5.3 数据记录和回放的坑时戳不同步导致实验室复现失败在调试大脑和小脑协同的时候经常需要做数据回放。大脑记录的是感知数据和控制指令小脑记录的是关节角度、力矩、状态估计结果两边频率不一样如果时戳不统一回放出来完全是错乱的。最好的方式是在系统设计初期就统一用PTP或者GPS时戳同步所有传感器数据和控制指令全都打上硬件时戳这样出了问题才能定位到底是大脑的问题还是小脑的问题。5.4 仿真到真机的鸿沟换了个环境机器人就“不会走路了”仿真里调好的人形机器人搬到真机上往往有一段痛苦的迁移过程。原因很多仿真里的地面摩擦系数是理想值真机的地板打滑关节电机的响应带宽在仿真里没考虑真机就有滞后感知模型的噪声在仿真里没模拟真机相机成像有模糊、有遮挡。做迁移的时候我建议先把小脑的控制律做得很保守确认能站能走再慢慢放开复杂度千万别一上来就指望仿真里百分之百成功的动作直接上真机原封不动跑一遍。5.5 保命机制一定要从小脑层独立实现最后一项也是最重要的一项安全兜底。紧急急停、碰撞检测、电机过流保护、跌倒自恢复这些机制必须放在小脑层独立于大脑运行。也就是说哪怕大脑进程死机、通信断连、模型输出乱码小脑也必须能在几毫秒内检测到异常然后执行安全姿态比如停下来、降低关节力矩、慢慢下蹲。我有一个习惯在整机通电测试之前先做一轮大脑断连测试直接把大脑进程杀掉看小脑能不能接管整机。这套测试如果过不了后面跑再炫的Demo我都觉得悬。从我手上这些项目走下来最大的体会是人形机器人的大脑和小脑不是一个可以“做减法”的系统而是两条腿走路。小脑决定下限大脑决定上限。先把小脑做稳让机器人站得住、走得稳再一层层叠加感知和智能这才是最稳妥的工程路径。接口设计上多花点时间把大脑指令的格式、能力边界、安全反馈定义清楚后面会给你省下大量来回调试的时间。这个领域现在发展太快新的模型、新的硬件层出不穷但我相信这套大脑加小脑的基本架构在人形机器人规模化落地之前会是大家共同遵守的底盘。