机器人技术这两年处在一个很有意思的节点一边是人形机器人不断更新形态另一边是 Physical AI 的概念被频繁提起。很多做算法、控制、嵌入式甚至后端开发的工程师都在问同一个问题下一步到底是押注人形还是押注 Physical AI还是说两者本来就不该分开讨论。这篇文章把三个词拆开讲清楚梳理各自的边界和依赖关系再给出从仿真工具链切入的实际路径。适合正在选方向的开发者、做技术预研的团队以及想理解机器人领域技术分层的学生阅读。读完以后你会对机器人系统需要哪些模块、为什么人形不等于智能、以及如何用一套最小闭环评价一个机器人方案有一个完整判断。1. 先分清 Robotic、Humanoid 和 Physical AI 三个词在讨论什么很多人讨论机器人时会把机器人的“外形”“智能水平”和“应用场景”混在一起。这种混淆在生产里会造成很实际的后果团队花大量精力做了一台外观接近人的设备却不知道自己要解决的到底是感知问题、控制问题还是决策问题。所以第一步不是比较哪家机器人更强而是先把这三个概念在工程上拆开。1.1 从“机器人”到“人形机器人”形态不是目标而是约束机器人Robot是一个非常宽泛的术语。工业机械臂、AGV 小车、四足机器人、扫地机器人都可以叫机器人。它们的共同特点是由传感器感知环境由控制器计算动作由执行机构产生物理运动。也就是说只要是一个“感知-决策-执行”的物理闭环就可以称为机器人。人形机器人Humanoid是机器人中的一个子类它的核心特征是形态上模仿人类双腿、躯干、双臂通常还有头部和灵巧手。为什么很多团队愿意做这个形态核心原因是人类的生产和生活环境是按人体构造设计的。楼梯、门把手、座椅、工具、货架它们的尺寸和操作方式都默认适配人的手和脚。如果机器人想在这些场景里工作而不改造环境那“像人”在物理层面就是最高效的约束条件。但要注意人形是一种约束不是一种能力。人形带来了双足平衡问题、高自由度控制问题、功耗问题、散热问题还有关节机构的成本问题。它只是换取“环境适配性”的一种代价高昂的形态方案。实际产品里场景越窄越不需要人形。1.2 Physical AI 解决的是“物理世界里的智能”问题Physical AI 这个说法核心不在“Robot”而在“AI”。它指的是让 AI 系统能在物理世界中感知、理解、推理并采取行动而不是只在文本、图片和视频这些数字符号里工作。大语言模型在数字世界处理的是 tokenPhysical AI 处理的是传感器数据、电机状态和物理反馈。从这个角度看Physical AI 更像是一种技术范式而不是某个硬件产品。它要求系统具备四个能力感知能力理解摄像头、激光雷达、触觉、力传感器传回的信息。世界模型对物理规律有基本预期知道物体掉下来会砸到脚知道门要推着开而不是拽着开。行动能力把高层意图转换成具体的关节运动、末端轨迹或力矩指令。反馈修正动作执行后通过传感器结果调整下一步计划而不是一次性开环执行。如果把人形机器人看成“身体”那 Physical AI 更像“大脑加小脑加脊髓”的整套神经体系。没有这套体系的人形机器人只是一个高自由度机械结构没有物理载体的 Physical AI 也只是仿真世界里的算法实验。1.3 用一张表建立选型坐标系为了在实际项目里快速对齐可以按下面的表格做初步划分。这张表的意义不是下结论而是帮助团队判断你遇到的问题到底属于哪一层。维度机器人人形机器人Physical AI关注核心机械、控制、传感、任务执行形态、平衡、拟人交互、环境适配感知、推理、学习、泛化能力主要难题精度、稳定性、可靠性高自由度控制、能耗、成本数据、模型泛化、sim-to-real成功标志能在特定场景稳定完成任务能在人类环境完成多类操作能在新场景中直接迁移能力典型输出自动化设备、工厂产线通用操作平台、交互机器人算法栈、仿真系统、智能体依赖关系是 Physical AI 的物理载体是 Physical AI 的一种载体可以部署在多种机器人形态上结论已经比较明显人形和 Physical AI 不是竞争关系而是“形态方案”和“智能方案”的关系。前者回答“做成什么样”后者回答“怎么让它聪明起来”。真正需要决策的不是二选一而是你的场景是否需要人形这种形态以及你的团队是否具备构建 Physical AI 所需的数据、仿真和算法能力。2. 人形机器人的技术栈看起来是形态实际是系统工程人形机器人给人的第一直觉是“硬件复杂”但它真正的难点在于感知、决策、控制、执行、算力和功耗必须作为一个整体被设计。任何一个环节掉队整机都会表现为“看起来能动但干不了活儿”。下面按层次拆开看。2.1 感知层多模态融合不只是堆传感器人形机器人的感知比单一工位的机械臂更复杂。机械臂通常固定在一个位置感知范围是半静态的。人形机器人要移动、转身、伸手、弯腰感知系统必须同时处理不同坐标系下的数据并在运动过程中持续更新环境模型。一个完整的感知栈通常包含几类输入视觉RGB 相机用于物体识别和语义理解深度相机或激光雷达用于建图和避障。惯性IMU 提供加速度和角速度是平衡控制的重要信号源。力与触觉关节力矩传感器、脚底压力传感器、指尖触觉传感器用于检测接触状态。关节状态编码器提供每个关节的位置和速度是运动控制闭环的基础。这里常见的误区是认为传感器越多越好。实际上多模态融合的难点是时间同步和坐标对齐。视觉和 IMU 的采样频率不同视觉和力矩传感器的延迟不同如果不对数据进行同步任何“融合算法”都会因为相位差而失真。工程上通常需要单独维护一个传感器校准和时间同步模块而不是把所有数据直接丢给模型。2.2 决策层从大模型到世界模型的迁移路径人形机器人需要一个能理解任务意图的系统。比如用户说“把桌上的水杯拿给我”机器人要先完成语义理解、物体定位、路径规划、抓取姿态生成和轨迹生成。传统做法是把这些步骤拆成独立模块用规则或专用模型串联起来。而 Physical AI 进入决策层后越来越多人尝试用端到端或者大模型驱动的方式缩短这个链路。VLM视觉语言模型可以帮助机器人理解场景和指令强化学习和模仿学习可以帮助机器人学会操作策略世界模型则试图让机器人对物理过程有预测能力。但要注意决策层并不一定等于“直接用一个大模型输出电机指令”。受限于算力、实时性和稳定性现在的多数系统仍然采用分层结构任务规划层用大模型或规则理解任务输出子目标序列。运动规划层对每个子目标规划机器人本体的路径和动作。实时控制层在毫秒级周期里计算关节力矩保证稳定性和安全性。这种分层在工程上更容易调试。每一层出了问题都能单独定位。2.3 控制层运动学、动力学与稳定性控制控制层是区分“能动的机器人”和“能用的机器人”的分水岭。机械臂的控制可以依赖运动学逆解加 PID因为基座固定、结构刚度高。人形机器人不同它是一套浮基系统脚部和地面的接触状态随时变化质心位置必须保持在支撑多边形内否则就会摔倒。于是就有了几个必须处理的问题动力学建模要计算足底力、关节力矩和姿态变化之间的关系。稳定性判据零力矩点ZMP是最经典的判据之一适合双足静态或准静态行走但快速跑跳场景需要更复杂的受控动力学。模型预测控制MPC在线求解未来一段时间内的最优控制输入是人形机器人运动控制的主流方法之一。全身控制WBC同时考虑手臂操作和腿部平衡把多个任务按优先级映射到全身关节力矩。这些模块的计算量很大。即使在仿真里跑通也不代表硬件上能跑。控制频率、整机惯量、关节延迟、通信时延每一样都会影响稳定性。2.4 算力与功耗移动机器人的资源约束人形机器人和数据中心服务器完全不同。它自带电池功率有限计算设备集成在机体内散热条件差还要考虑整机重量分布。多块高功耗 GPU 直接上机的方案在实验室可以在产品设计里很难长期使用。实际设计时会有几种策略机载算力做实时控制远端算力做大模型推理。通信链路需要稳定且要设计断网降级逻辑。在模型端做量化蒸馏把大模型压缩成能在边缘设备上执行的版本。按任务触发不同算力需求待机时低功耗模式操作时高负载模式而不是让所有模块常驻。算力规划要在整机定义阶段就做不能等控制算法写完了再考虑。很多项目一开始没有预留功耗余量后来算法复杂度上来发现整机变重、续航变短只能回头改硬件。3. Physical AI 的核心机制感知-推理-行动闭环如果只看硬件人形机器人很容易被误解为“伺服电机加结构件的组合”。真正让它具备价值的是那个闭环系统每执行一步动作都能观察动作带来的物理变化并据此调整下一步。这个闭环能力比“是不是人形”重要得多。3.1 具身闭环为什么比纯模型更重要数字世界里的 AI输出是一次性的比如生成一段文字、一张图片。物理世界里的 AI 不一样它的一举一动都会改变环境状态环境状态的改变又会影响它的下一步决策。所以 Physical AI 的核心不是单个模型的精度而是闭环的鲁棒性。这里有一个很容易迷惑人的点一个模型在离线数据集上评测效果很好部署到机器人上却表现很差。原因通常是离线评测只测了“模型输出”没有测“模型输出执行后环境如何变化”。真正有效的评估必须让机器人在环境里执行动作再根据执行结果反馈调节。这也是为什么现在很多团队宁愿在仿真里做大量随机化实验也不愿意只在离线数据上刷指标。闭环数据是 Physical AI 和普通深度学习之间最本质的区别。3.2 数据从哪来仿真数据、遥操作数据与真实数据Physical AI 训练需要大量“状态-动作-结果”三元组数据。数据的来源一般有三类各有取舍数据来源优点问题仿真数据成本低、可批量生成、可做领域随机化与真实物理存在偏差直接迁移会失败遥操作数据包含真实人类操作经验质量高采集慢、成本高难以规模化真实机器人自主数据与部署条件一致最可靠获取缓慢需要机器人和安全措施支持在实际项目里通常不是只用一种数据而是用仿真数据做预训练用真实数据做微调再用遥操作数据补充长尾场景。这条链路的工作量往往比写模型本身更大。这也是“Physical AI 难落地”的最现实原因卡点很少是算法创新而是数据管线。3.3 Physical AI 不只是大模型还需要“世界模型”和“反馈回路”大模型在 Physical AI 里能解决的是“语义理解和任务分解”但它缺乏对物理过程的连续预测。比如让大模型规划“把积木从 A 点推到 B 点”它知道步骤但对摩擦力、接触力、物体滑动轨迹没有感觉。要让机器人稳定执行需要所谓的“世界模型”——一个能根据当前状态预测下一时刻状态的模型。世界模型可以基于物理仿真器构建也可以基于数据学习。工程上最常见的做法是用物理仿真器作为“可微世界模型”在训练阶段用强化学习策略在仿真中大量试错再用领域随机化提高策略对真实世界的适应度。反馈回路也不可忽视。即使是同一个动作每次执行时接触力、初始姿态、物体材质都会有微小差异。如果没有力反馈和视觉反馈机器人只能在固定工况下工作。这正是 Physical AI 相对传统规则控制的长期优势它能利用反馈实时调整而不是把所有可能性都预先写死在程序里。4. 二选一不是答案形态与智能的分层架构对团队来说真正的落地问题是如果资源有限是先把人形硬件做扎实还是先把 Physical AI 能力做出来我的判断是这个问题本身设计得不对。正确的问题是你服务的场景需要什么形态需要什么智能能力以及这两者如何在系统中分层解耦。4.1 人形装的是 Physical AI 的“通用性”而不是人类的“外形”人形机器人的价值表面看是形态像人深层看是它提供了一组“泛化能力”的物理基础。人类环境里的绝大多数工具和空间都按人体尺寸设计这意味着一个人形机器人理论上可以操作人类的所有工具走人类的所有通道待人类的所有工位。这就是通用性。这种通用性的代价非常大。双足平衡、双手协作、灵巧操作每一项都是工程上极其复杂的课题。所以做产品的人必须想清楚一件事这个场景真的需要通用性吗如果只是一个仓库分拣任务轮式机器人加一个机械臂可能又便宜又稳定。如果是一个需要上下楼梯、跨过障碍、使用人类工具的巡检场景人形形态才有显著优势。选择人形本质上是在为“未来未知任务”提前购买保险。而保险是否值得取决于你对未来场景的确定性判断。4.2 专用形态在现阶段更容易落地人形更适合做平台从研发投入和商业回报看专用形态在短期内更容易完成闭环。四足机器人适合巡检复杂地形轮式底盘适合室内搬运固定机械臂适合高精度重复操作。这些形态都把问题限制在可控范围内硬件成本和算法难度都更低。人形机器人更适合被定义成一个通用平台而不是直接追某个具体 KPI。它的价值在于建立一套“能装进人类环境里的物理智能系统”后续可以通过软件更新、末端工具更换、技能库扩展来适配不同任务。这更像智能手机的早期定位硬件平台先立住生态和应用再长出来。因此团队规划时也不要把人形项目当成一个短期交付项目来做。它从第一天起就要考虑接口开放、仿真环境、数据采集、任务编排这些平台化能力。4.3 分层设计把形态、算法、任务解耦无论做专用机器人还是人形机器人最稳妥的架构都是分层设计。每一层只依赖下层的抽象能力不依赖具体形态任务层定义“做什么”例如取一杯水、搬运箱子、巡检设备。技能层定义“会做什么”例如导航、抓取、放置、开门、爬梯。算法层提供可复用的感知、规划、控制、学习模块。硬件层提供执行能力包括结构、关节、传感器、算力。如果硬件从轮式换成双足任务层和技能层的代码应该尽量不变只需要替换运动控制算法和感知配置。如果算法从传统规划换成强化学习硬件层也不应该受影响。这样当技术路线快速变化时团队不需要推翻重来。这是“形态与智能结合”的正确方式而不是把两者焊死在一起。5. 开发者怎么进入这个方向从仿真工具链开始无论最终选人形还是其它形态学习路径都应该是从仿真开始。仿真成本低、可重复、数据可视化清晰能帮你快速理解机器人系统的核心链路。对开发者来说最友好的入口是接触一套成熟的机器人工具箱再加上一两个主流仿真环境。5.1 推荐的学习工具链MuJoCo、Isaac Lab、Robotics Toolbox“Robotics Toolbox”这个词可以指多个工具集合最常见的包括 Peter Corke 的 Robotics Toolbox for Python它和 Spatial Math Toolbox 配合用于机器人运动学、动力学、轨迹规划的学习与调试。它提供的不是 GPU 级仿真而是轻量的算法研究环境特别适合理解 D-H 参数、正逆运动学、雅可比矩阵这些基础概念。如果需要更真实的物理仿真推荐从下面几个环境入手工具定位适合场景Robotics Toolbox for Python轻量算法库运动学、动力学、轨迹规划入门MuJoCo高速物理仿真器强化学习、接触场景、控制验证Isaac Lab / Isaac SimGPU 加速仿真平台大规模并行训练、机器人技能学习Gazebo开源机器人仿真环境ROS 生态集成、系统级仿真这几个工具不是互相替代的关系而是学习路线上前后相接。先用 Robotics Toolbox 把运动学和动力学基础打牢再用 MuJoCo 尝试物理仿真和控制最后用 Isaac Lab 这类平台做批量训练。5.2 最小验证在仿真里控制一个机器人完成定点运动下面用 Robotics Toolbox for Python 的思路演示一个最小闭环加载一个机器人模型给定一个目标末端位姿求解关节角然后检查运动学上是否可达。这段代码重点在理解流程实际项目中需要按自己的模型文件调整路径和参数。import roboticstoolbox as rtb from spatialmath import SE3 # 方式一从内置模型库加载 Panda 机械臂模型 robot rtb.models.DH.Panda() # 设定一个目标末端位姿 T_target SE3(0.5, 0.0, 0.4) * SE3.Rz(0.5) # 使用逆运动学求解关节角q0 是初始关节位置 sol robot.ikine_LM(T_target, q0robot.qr) if sol.success: print(解算成功关节角为, sol.q) else: print(当前目标位姿不可达需要调整目标位置或工具坐标系)这里的robot.qr表示默认的参考关节角ikine_LM使用 Levenberg-Marquardt 方法求解数值逆解。对于机械臂来说这个流程足够说明运动学闭环。如果要理解人形或双足还需要加入动力学、接触力和平衡控制建议进一步在 MuJoCo 中构建带地形的模型。用 MuJoCo 做物理仿真时最小闭环一般是加载模型、设置初始控制量、逐步推进仿真时间import mujoco # 从 XML 文件加载模型模型文件中需要定义连杆、关节、传感器和地形 model mujoco.MjModel.from_xml_path(simple_hopper.xml) data mujoco.MjData(model) # 设置关节目标位置或执行器控制量 data.ctrl[:] [1.0, 0.5] # 逐步推演 1000 步观察运动状态 for step in range(1000): mujoco.mj_step(model, data) print(最终关节位置, data.qpos) print(最终关节速度, data.qvel)这段代码里的simple_hopper.xml需要自己去定义没有它会直接报模型加载失败。这也是第一个真实练习搞清楚模型 XML 里link、joint、actuator、sensor分别描述什么后面控制策略才有效果。5.3 从仿真到真机要补哪些模块仿真跑通只是第一步。把算法放到真实机器人上还需要补齐下面这些模块控制器接口统一把仿真里的关节目标转换为真实电机的位置、速度或力矩指令。状态估计真实机器人拿不到仿真里的全局状态需要依赖编码器、IMU、视觉里程计融合。安全保护力矩限制、关节限位、碰撞检测、急停逻辑都会在真机上成为硬性要求。时间同步控制循环、传感器采集、通信总线必须严格同步否则控制指令可能过期执行。系统监控记录每个关节的温度、电流、错误码用于故障定位。这些内容在仿真里通常被简化或省略。很多初学团队栽在这里仿真里算法精度很高真机上第一秒钟就出现剧烈抖动。原因很可能不是算法而是控制频率不匹配、指令延迟太大或者状态反馈噪声过高。5.4 运行验证和结果判断学习阶段不要只满足于“程序没报错”。一个机器人控制实验是否有效要按以下顺序判断机器人是否稳定运行没有异常抖动或发散。关节位置和速度是否在限位范围内。末端轨迹是否达到目标位姿误差在可以接受的范围内。改变初始条件或环境扰动后系统是否仍能收敛。系统日志中是否出现超时、计算溢出、状态估计异常。如果只是追求“跑起来”很多问题都会被掩盖。建议从一开始就建立简单的数据记录机制把关键状态保存下来至少包括时间戳、关节指令、关节实际值、控制误差。没有这份数据后续排错会非常被动。5.5 学习环境与生产环境的差异仿真适合学习和预研但生产级机器人必须做更多环境适配。下面是常见差异项目学习/仿真环境生产环境硬件故障仿真默认无故障电机过温、编码器丢信号、通信中断都要处理环境差异固定地形、固定光照光照变化、表面摩擦变化、动态障碍计算资源可任意使用大模型功耗、算力、时延受限数据反馈得到完整状态只有局部观测和噪声测量安全要求可随便试错需要碰撞停止、力限制、人员防护所以在仿真里做 demo 时就要刻意加入随机扰动和传感器噪声而不是总在理想条件下测试。6. 常见坑与排查路径这一节整理几个在实际项目里最常遇到的坑。每条都按“现象、原因、处理方式、预防建议”的结构展开。6.1 仿真能跑、真机不能用sim-to-real 的三大偏差现象策略在仿真环境中表现很好迁移到真实机器人后剧烈抖动、摔倒或者完全失效。原因仿真和真实系统之间存在三大偏差物理参数偏差摩擦力、质量分布、延迟不同、状态观测偏差仿真直接给出真值真机只能靠估计、执行器偏差真实电机的力矩响应和延迟与仿真模型不一致。检查方式先对比仿真和真机的关节响应曲线看力矩到速度的时间延迟是否一致再对比足底压力或接触力的峰值和分布最后观察状态估计噪声水平。处理方式采用领域随机化在训练时随机扰动质量、摩擦、延迟等参数部署前增加真实数据微调真机首测从小角度、低速开始逐步增加难度。预防建议在所有仿真实验中都加入“参数随机化开关”默认训练随机域版本不训练单点版本。6.2 自由度堆得越高控制越不稳定现象整机自由度多、形态炫酷但实际运行中经常出现局部振动、关节过热、能耗过高。原因每个增加的自由度都会引入额外的动力学耦合、摩擦和冗余求解问题。控制算法需要在高维空间里规划计算复杂度和不稳定因素都会增加。检查方式查看稳定控制时的关节力矩方差如果某些关节频繁正负切换说明控制律可能在对抗模型误差检查能耗分布看哪些关节功耗异常偏高。处理方式判断自由度是否服务于任务需求。用不到的自由度可以锁定或取消对冗余机构引入任务优先级和二次规划约束增加关节阻尼并做力矩平滑。预防建议自由度不是产品卖点是成本项。先列出目标任务需要的最小自由度数再预留 20% 余量而不是反向堆砌。6.3 数据不够就迷信大模型现象团队把大量精力投入到 VLM 和端到端模型上但机器人在新场景下仍然表现不佳连简单的抓取都能失败。原因大模型擅长语义理解和常识推理但它没有足够多的物理交互数据来支撑精确操作。机器人操作需要毫秒级反馈和高精度执行这与文本生成的任务性质完全不同。检查方式把失败样本分类看是“错误理解指令”还是“执行路径错误”还是“接触力控制失败”。不同类型需要不同解法。处理方式先用传统规划或强化学习解决底层运动控制再在上层叠加 VLM 进行任务理解。把端到端模型的应用范围限制在数据丰富的闭环任务里。预防建议不要用“模型规模”衡量项目进展用“任务成功率”和“泛化能力”作为最终指标。6.4 排错清单按顺序排查机器人系统问题时可以参照这份清单传感器数据是否合理检查视觉、IMU、编码器、力传感器的数值范围和噪声。状态估计是否收敛查看姿态估计、位置估计的残差。控制指令是否准时到达检查控制周期内是否有丢包、超时、总线竞争。执行器是否正常响应对比指令力矩和实际力矩曲线。算法输出是否在限位内检查规划轨迹是否超出关节限位或碰撞边界。模型参数是否匹配当前硬件质量、惯性、摩擦、动力学是否与设计一致。日志是否完整确认关键事件都有记录否则很难回放问题。大部分所谓“玄学问题”最终都能定位到这七条中的某一条。7. 选型建议与落地路线最后落到一个实际问题一个团队到底该怎么决策。这里不给出绝对答案因为场景差异太大但可以提供一个判断框架。7.1 三个问题决定先做专用机器人还是人形第一个问题任务环境是否需要双足和双手。如果只需要在平整地面移动或只需要固定工位操作那轮式底盘加机械臂就能解决不需要人形。第二个问题任务是否长期不变。如果任务是标准化重复劳动专用机器人能获得更好的稳定性和经济性如果任务种类会持续变化人形平台带来的通用性才有价值。第三个问题团队是否具备动力学、全身控制和多模态交互的系统能力。人形机器人对算法栈完整度要求很高任何一个模块缺口都会导致整机无法落地。三个问题都偏向“通用、变化、能力完整”时人形才是合理方向否则优先做专用形态把 Physical AI 的算法能力逐步沉淀到通用平台上。7.2 评估指标稳定性、成功率、泛化能力、安全无论选择哪种路线评估都不能只看单次 demo。建议从四个维度建立指标体系指标定义建议最低标准成功率任务在多轮测试中的完成比例不低于 95%且连续稳定稳定性长时间运行无发散、无摔倒、无急停连续运行时间至少达到设计值泛化能力在新场景、新物体、新初始化条件下是否仍可工作至少覆盖 80% 的预期变量安全性遇到碰撞、故障、未知情况时的降级行为必须在毫秒级触发保护逻辑这四个维度都要留自动化测试记录否则后期无法判断算法迭代是否真正变好。7.3 团队路径建议一个合理的技术路线可以分成三步。第一步用现成机械臂或轮式底盘做算法闭环。完成感知、规划、控制的基本链路积累数据采集和仿真训练经验。第二步在仿真里构建双足或人形模型用强化学习跑通行走、避障、简单操作任务重点积累动力学和稳定性控制经验。第三步再进入真机验证。从小型人形或半身平台开始逐步过渡到全尺寸平台。每一步都保留仿真测试和数据记录机制作为算法迭代的基线。这样走风险可以被拆散。每次只引入一个新变量而不是一开始就同时挑战人形硬件、Physical AI 算法和完整应用场景。回到最初的问题机器人的下一步是人形还是 Physical AI还是两者结合。在工程视角下最合理的答案不是二选一而是把人形理解为物理形态把 Physical AI 理解为智能能力再把两者放进一套分层架构里逐步构建。对于大多数开发者真正值得投入的不是对形态的争论而是用仿真工具链把手上的感知、控制、数据闭环先跑通。有了这个闭环无论是人形还是专用机器人算法都能找到它发挥作用的位置。