直接从Figure 03发布那几天说起吧。我在技术社区里刷到不少讨论帖，国内外的反应差异很大，有人盯着22个自由度的手部做拆解分析，有人把Helix的演示视频反复逐帧看，也有不少做传统机器人控制的工程师在问同一个问题：端到端真的能进工厂吗？作为一个从机械臂控制转到具身智能方向的人，我觉得这次发布的信息量不算小，值得把硬件和系统拆开揉碎了聊一遍，尤其适合准备切入具身智能领域、或者正在规划相关学习路线的朋友当作一个完整的参考案例来读。
1. Figure 03硬件突破：从关节设计到整机工程
1.1 自由度数翻倍背后的结构逻辑
先说硬件。Figure 03最直观的变化是整机自由度的提升。总自由度来到接近40，其中光是单手就给了22个自由度，这个数字在人形机器人品类里属于第一梯队。
我们对比一下前代产品就明白了：上一代手部自由度大约是12个，每根手指大致2个自由度，能完成抓取但精细操作受限。这次单手指做到4自由度以上，意味着手指可以独立完成侧摆、屈曲、外展这些动作，不再只是“捏”和“握”。举个生活场景，端一杯水不放洒和拧开一个瓶盖，对手指运动的需求完全不同。前者只要包络式抓握，后者需要拇指对掌加食指中指的精细协同，手指自由度不够，拧瓶盖这种动作根本做不出连续力矩控制。
我的判断是，22自由度手部设计不是单纯追求“看起来像人”，实际目标是覆盖更宽的操作任务类别。工厂里大量装配动作的共性模态——零件对接、螺丝拧紧、线束插拔——本质上都需要高自由度手指加高精度力矩感知的配合。这也解释了为什么Figure团队在发布会里专门演示了类似双手操作零件的场景。
1.2 关节集成度与散热设计的平衡处理
另一个容易被忽视的硬件亮点是关节模组的集成度。人形机器人全身几十个关节，每个关节都要集成电机、减速器、编码器、驱动器、力矩传感器，传统做法是分散布置，线束非常多，故障率高。Figure 03采用了更接近工业伺服关节的一体化方案，电机、减速机构、传感、驱动做到了高度集成，单关节的功率密度和响应带宽都明显提升。
这里有个容易被外行忽略的工程难点：散热。高密度集成意味着热量集中，而人形机器人的手臂、手指又不可能像工业机械臂那样加装大体积散热鳍片。Figure 03的做法是在结构件上做了热管理设计，同时把高功率关节集中在需要爆发力的部位，低功率部位则压缩体积。这个设计哲学很值得国内硬件团队学习：不是所有关节都追求扭矩上限，而是根据任务需求做分级配置，该省的地方一定要省。
1.3 机载算力升级与功耗分配
Figure 03在机载计算平台上也做了明显升级，板载算力相比前代提高了大约3倍。算力提升的直接意义是：视觉感知、语义理解、运动规划这些重计算任务可以全部在机器人本体上实时完成，不再依赖外部服务器的无线回传。
这一点对实际部署的影响非常大。我们团队此前测试过其他品牌的机器人原型机，一旦需要远程计算，通信延迟就成了不确定因素，网络稍有波动，整个操作序列就要暂停。Figure 03把推理放在机载，意味着在工厂现场、仓储环境这类没有专用5G网络的场景下也能保持低延迟闭环。
当然，性能提升不是免费的。功耗问题必须正视：算力增加，电池负担上升，整机续航能力面临压力。Figure团队的思路是在任务层做功耗分配——待机状态强制低功耗，简单操作不启用大模型推理，只有遇到复杂任务才把全部算力拉满。这种思路在实际工程项目里非常实用，只谈峰值性能不谈功耗优化的机器人在产线上反而是灾难。
2. Helix端到端控制系统：架构、训练与涌现行为
2.1 端到端与分层式路线的本质差异
Helix才是这次发布真正值得关注的软件系统。要理解它的价值，得先回到当前机器人控制系统的主流路线之争。
传统机器人控制是典型的分层级pipeline：感知模块识别物体，定位模块计算坐标，运动规划模块生成轨迹，底层伺服模块执行轨迹。每个模块独立训练、独立调参，模块之间用接口连接。这套体系成熟稳定，但有个巨大瓶颈——面对非结构化场景时，中间某一环出错，整套系统就会崩溃。而且每新增一个操作任务，工程团队都要重新调整中间表示，开发周期很长。
端到端路线想解决的就是这个问题，把“感知到控制”压缩成一个完整模型，输入是视觉和语言指令，输出直接是关节动作。Helix采用的就是这种思路。这样模型自己学习视觉、语义、运动之间的内在关联，不需要人为定义中间表示，相当于从“多个专家通过接口协作”变成了“一个大脑直接发指令”。
用生活化类比解释：传统方案就像餐厅里点餐，客人说话（语言）→服务员记单（感知）→后厨做菜（规划）→传菜员上菜（执行），每一环都需要沟通和交接，任何一环听错就全乱。端到端方案等于一个厨师直接听客人说话、自己决定怎么做、自己动手出菜，理解、规划、执行是一条线完成的，效率和适应能力自然更强。
2.2 双系统架构：快思考与慢思考的协同
Helix架构最核心的设计是双系统协同。第一个系统是经过大规模数据预训练的视觉语言模型，负责慢思考：理解环境、解析语义指令、推理任务目标。第二个系统是负责快反应的控制模型，将语义意图快速映射成高频的关节动作指令。
双系统的分工逻辑很清晰。视觉语言模型学的是“世界知识”，比如看到螺丝刀知道它是用来拧螺丝的，这个知识来自互联网规模的数据，覆盖面广但推理速度慢。控制模型学的是“肌肉记忆”，输入是高层意图，输出是连续动作序列，推理速度要求很高。Helix的创新点在于让慢系统做决策，快系统做执行，两者通过一个紧耦合的接口协作。
实测效果上，Helix能实现类人水平的双手操作，完成抓取、转移、协作类复杂任务，这在端到端控制系统里是巨大的进步。因为双臂协同对两个手臂的协调性要求极高，左手的动作要为右手的下一步操作预留空间，模型必须建立双臂统一的空间表征，这种能力在单臂方案里根本无法涌现。
2.3 训练数据策略：遥操作采集与仿真叠加
很多读者会好奇，这种端到端控制模型是怎么训出来的？Helix的数据策略很务实——大量使用遥操作采集的数据。
具体流程是这样的：操作员戴上VR设备，通过动捕手套操控机器人完成一系列任务。机器人的每一个关节角、手部压力数据、视觉画面被同步记录，形成“视觉观察+语言指令+动作序列”的三元组训练样本。一个熟练的操作员一天大概能采集几百条有效演示数据，积累到一定规模后，模型就能够学会对语言指令进行泛化——哪怕换一个物体位置、换一种说法，模型依然能理解意图并执行。
这里有个科普点：端到端模型不是“喂数据就行了”，数据分布直接决定模型能力的上限。如果采集数据里都是固定台位、固定物体的操作，模型学到的只是过拟合套路，换个环境就不灵了。Helix团队的做法是刻意制造数据多样性——采集中随机改变物体起始位置、环境光照、干扰物体，让模型学会真正的“任务理解”，而不是死记硬背轨迹。
2.4 涌现能力：多机协作与跨本体泛化
Helix展示了一个非常值得注意的现象——涌现的协作行为。在多机测试中，两台机器人在没有显式通信的情况下完成协同搬运，一台机器人会主动为另一台机器人留出操作空间，这种能力并不是工程师显式编程实现的。
理解涌现这件事，要把视角从“编写行为”切换到“训练能力”。当模型在训练中见过足够多的“主体在不同场景下完成目标”的样本后，它会学到一种泛化的操作策略，而不是固定的动作序列。策略的泛化就带来了跨任务的迁移能力——同一个模型，换一台机器人本体也能用。
这种跨本体泛化对行业的意义重大。目前市面上每款机器人都需要专门的软件适配，成本极高。如果一套端到端模型能实现跨平台部署，整个行业的软件成本结构都会发生变化。虽然现在Helix的跨本体演示还比较初级，但这个方向已经被验证可行了。
3. 具身智能agent的完整技术栈拆解
3.1 VLA模型的核心组成与运行逻辑
谈完Helix，我们把视野拉宽，看看具身智能agent背后的完整技术栈。
这几年具身智能最热的关键词是VLA，即视觉语言动作模型。它是把视觉理解（看到什么）、语言语义（任务意图）、动作生成（怎么动）三者融合在一个模型里的技术路线。
VLA模型的核心交互逻辑是：模型接收一个视觉画面输入和一个语言指令输入，在内部进行多模态融合推理，然后输出一个动作指令序列。工业界常用的实现方式是Transformer架构——视觉编码器把图像转换成token序列，语言编码器把指令转换成token序列，二者在共享的注意力层里交互，最后由动作解码器把语义表征映射为机器人的执行指令。
这里有一个非常关键的架构细节：动作指令是高频连续的，而语言模型擅长的是离散token预测，如何把两者对齐是整个VLA设计的核心难点。有的方案把动作空间离散化成若干个“动作token”参与训练，有的方案则在Transformer后面接一个单独的连续动作头，让模型先做语义推理，再做动作回归。Helix用的是类似后者但更精密的设计，用快系统来承担连续动作生成的任务。
3.2 仿真训练与真机部署的工程闭环
具身智能模型开发的完整链路大致是：仿真数据生成、预训练模型构建、真机数据采集、联合微调、部署测试。几个环节缺一不可。
仿真训练是目前的标配，原因很简单——真实数据采集成本太高，一个熟练的遥操作员一天只能采几百条数据，而一个仿真环境可以并行开几千个进程，一天生成几百万条数据。常用仿真工具包括MuJoCo、Isaac Gym、Genesis。其中MuJoCo的物理精度高，适合细粒度操作；Isaac Gym的并行效率突出，适合强化学习的大规模采样；Genesis是这两年新出的，号称是“AI原生”仿真环境，很多团队已经在试用。
但仿真数据有个天然问题——sim-to-real gap（仿真到现实的鸿沟），仿真里学到的动作在真实机器人上执行时往往会出现偏差。业界通行的做法是，先在仿真里大规模预训练模型的基础能力，再用真机数据微调，让模型在“学会了原理”的基础上“适配真机的手感”。Helix的训练共享了这个范式，先用海量互联网数据和仿真数据训练慢系统，再用真机遥操作数据训练快系统和接口层。
3.3 具身智能agent对环境感知的更高要求
不同于聊天机器人只需要理解文本，具身智能agent必须对三维物理空间有实时的感知能力。这个感知不只是“识别出画面里有个杯子”，而是要输出空间位置信息、物体姿态、可操作点，甚至是物体的材质属性。
Helix的核心突破之一在于这些信息不需通过明确模块提取，视觉语言模型直接从原始视觉流中提炼出空间语义，快系统再把这些语义转译成精确的关节指令。整个感知与执行的延迟被控制在极低水平，无需外部遥测设备的辅助，就能实时规划出精准的动作轨迹。
这里补充一个工程细节：端到端模型虽然不需要显式感知模块，但训练时依然需要空间标注信息。遥操作数据里，机器人手部的6D位姿就是天然的标注，模型能通过自监督学到“手往哪个方向移动会产生什么样的视觉变化”，这种视觉-运动联动的学习机制是经典机器人技术难以直接给出的。
4. 具身智能学习路线：从入门基础到拿到Offer
4.1 三个阶段的学习路径规划
如果看到这里你决定要进入具身智能方向，我根据近两年的招聘需求和模型演进趋势，给你梳理一条可落地的学习路线。
第一阶段是基础期，重点补齐三个领域的知识栈。编程方面，熟练掌握Python和PyTorch，能独立完成数据加载、模型训练、推理部署的闭环。深度学习方面，吃透Transformer架构的原理，理解自注意力机制、多模态对齐这些关键概念。机器人学方面，理解刚体变换、正逆运动学、机械臂基础控制。
第二阶段是进阶期，进入具身智能的核心领域。精读VLA方向的经典论文，掌握RT-1、RT-2、Octo、OpenVLA这些代表性模型的架构设计和实验方法。条件允许的话，在校学生尽量参与真实的机械臂项目，哪怕是从给师兄师姐打下手开始，也比纯刷论文有价值得多。实验环境方面，先在MuJoCo或Isaac Gym里跑通一个简单的“抓取”任务闭环，再尽可能迁移到真机上。
第三阶段是实战期，锁定一个具体方向深挖，可以是数据侧（哪里找数据、怎么采数据）、训练侧（模型架构怎么进、多模态怎么对齐），或者部署侧（模型怎么上真机、延迟怎么压）。面试官更看重的是在特定方向上有深入思考的候选人，而不是什么都了解一点的“万金油”。
4.2 核心技能要求与知识点清单
技术栈方面有明确的期望清单。算法上，多模态模型、VLA、Diffusion Policy、强化学习是关键词；工程上，模型部署、数据管线、ROS2、Isaac系列工具链是高频要求；架构上，微调、LoRA、推理加速、量化都是加分项。
给大家一个具体的技能对标：一个合格的具身智能算法工程师，至少要能独立完成“读一篇VLA最新论文→用自己的数据管线训练→在仿真或真机里跑通一个操作任务”的闭环。如果你能做到这一点，已经超过大部分候选手了。
这里多说一句，高质量的基础比追逐热门模型更重要。近一年时间模型架构在快速迭代，但背后的机器人学基础知识和深度学习方法论始终通用，基础薄弱的人追新模型会非常吃力。
4.3 具身智能面试高频考点与实例解析
面试环节，我把最近半年出现频率较高的考点汇总成一张速查表，供大家参考：
| 考点方向 | 常见问题 | 考察意图 |
|---|---|---|
| VLA原理 | VLA模型的正向传播流程是什么？视觉特征和语言特征在哪里做融合？ | 确认不是只背概念，而是理解架构细节 |
| 端到端对比 | 端到端控制和模块化控制各自的优缺点是什么？适用场景有什么区别？ | 考察系统思考能力，是否理解技术路线选择的trade-off |
| 数据工程 | 遥操作数据采集的瓶颈有哪些？如何设计数据多样性策略？ | 实战中数据往往是最大的工程问题 |
| 部署层面 | 模型推理延迟高怎么办？动作序列如何平滑与底层控制器衔接？ | 考察工程思维，是否理解部署中的实际问题 |
| sim-to-real | 仿真训练的策略迁移到真机上失败，你会怎么排查？ | 面试中最高频的场景题，强烈建议提前准备 |
面试例题：如果sim-to-real迁移后机器人在真机上抓取精度明显下降，你会如何排查？较好的答题思路包含四个层次：先确认域差距大小，如果偏差小说明仿真物理参数基本准确，可以微调控制层解决；如果偏差大，可能是物体纹理、摩擦系数的仿真参数与现实差距过大，需要调整域随机化范围；再考虑是否需要补充真机数据参与训练，最后才考虑是否要改变模型架构或训练目标。
4.4 入行避坑指南与市场现状
学习过程中有几个主要误区值得提醒。第一个是忽略真机实践，只依赖仿真项目。仿真中模型表现很好，一到真机就崩溃，这在面试里很容易被追问，没有真机经验的候选人表现往往不尽如人意。第二个是盲目追逐新模型，忽视基础。每天刷最新论文却写不出Transformer的完整实现，在面试中印象分会大打折扣。第三个是不重视系统工程能力。具身智能最终要落地到机器人本体上，模型效果再好，部署不下去就是无效方案。
行业现状方面，目前具身智能岗位的供给和需求之间存在明显缺口，真正能把模型跑上真机的人才依然稀缺。从这个角度来说，这是一个值得投入的方向，但请记住：它更考验工程落地能力，不是单靠刷榜刷论文就能胜出的。
5. 实践中的难点与各团队反馈的常见问题
5.1 端到端系统部署中的实际问题汇总
根据行业交流和自身测试经验，我把当前端到端系统在部署中碰到的高频问题整理如下：
| 问题类型 | 具体表现 | 推荐排查方向 |
|---|---|---|
| 延迟超标 | 指令执行延迟接近秒级，实时感差 | 优先检查慢系统推理耗时，看是否可以通过蒸馏压缩；再看控制频率是否与快系统不匹配 |
| 数据污染 | 训练模型在特定场景失效 | 检查数据的多样性是否足够，是否存在大量重复、无效演示 |
| 任务遗忘 | 训练新任务后旧任务能力明显退化 | 引入数据回放（replay buffer），或者在联合训练时混合历史数据 |
| 抖动明显 | 高精度定位时末端频繁抖动 | 调整神经网络输出后的平滑滤波参数，或检查底层伺服控制器的刚度匹配 |
| 跨本体迁移失败 | 模型A机器能用，换B机器失效 | 检查传感器坐标系的差异，重新采集少量目标机器人的数据做适配 |
5.2 仿真到实物迁移的经验体会
仿真是目前几乎所有团队都要用的工具，但也是踩坑最多的环节。我刚入行时一度相信仿真效果等于真机效果，直到第一次做sim-to-real迁移，模型在仿真里稳稳抓取，在真机上一碰物体就掉，才明白仿真环境的物理近似度远没有想象中那么高。
现在我的处理流程是：先做物理参数校准，用真机采集一些基础动作数据来校准仿真的摩擦参数和质心参数；再加大域随机化范围，包括光照、摩擦系数、物体尺寸和质量，逼模型学到真正鲁棒的特征；最后一定要在真机上做小规模数据补充，哪怕几十条也行，微调之后效果提升往往非常明显。
这也能解释为什么Figure的团队会花大代价建设遥控数据采集工位。数据质量和规模是端到端模型的根本，没有任何技术能替代这一部分工作量。
5.3 数据采集与标注环节的成本控制策略
数据采集团队常见的成本瓶颈主要有三个：时间成本、硬件损耗、人力门槛。遥操作采集需要熟练操作安全员，培养周期长，而且长时间采集容易疲劳，数据质量会下降。
行业当前比较务实的做法是“自动化采集+人工抽检”的组合：在固定任务范围内，让机器人尝试“自采”，也就是利用已有的基线策略自动执行任务，把成功样本和失败样本都记录下来，人工只需要标注语义指令和抽检质量。这种方式能大幅提高数据产量，也顺带解决了模型探索能力训练所需的负面样本问题。
5.4 具身智能项目评测体系的思考
评测一直是具身智能这个方向的短板。目前业界普遍还没有一个公认的标准基准，大家普遍的做法是直接看演示视频——模型能稳定完成哪些任务、泛化到什么程度，靠肉眼判断效果好坏。这种方式在社区交流中还勉强可用，但在工程验收和产品化层面远远不够严谨。
我在内部项目中会建立一个分层评测体系：基础层测单任务的连续完成任务成功率，统计多次试验的成功率均值；中间层测任务的泛化能力，刻意更换物体材质、位置、光线条件；评测层测模型的鲁棒性，加入干扰物体、随机扰动、指令变更等极端情况。这套方法虽然不是行业标准，但至少能帮助我们在迭代中筛掉看似有效、实则过拟合的方案。
写在最后的几点观察
从硬件自由度的大幅提升，到Helix双系统端到端方案在复杂协同任务上的表现，这组文宣背后确实藏着具身智能赛道的关键趋势——数据规模、算力平台与模型结构开始融合成一个整体系统设计。
我自己在实际测试端到端控制系统时最大的体会是：一个模型的泛化能力，几乎完全是由训练数据的覆盖度决定的，所谓的“聪明”更多来自海量多场景样本的堆叠，而不是算法本身有多么先进的推理能力。从这一点上讲，那些在数据采集和仿真环境上真正投入的团队，才能构建起持久的竞争优势。
另外，关于Figure 03这类硬件，我想说一个容易被低估的点：当一个产品能把自由度、算力、散热、功耗这些互相矛盾的约束都平衡好，说明这个团队已经不只是实验室方案，而是真正站在产品化和量产的角度做工程决策。
如果你正准备进入这个领域，我的建议是：打好机器人学和深度学习的地基，参与真实项目，尽早接触真机，然后选择一个细分方向深扎下去。具身智能是一条长赛道，现在入场，正是好的时机。
