如果你现在资源有限，还在决定“具身智能”到底先落在哪一层，我的判断很明确：先别追更大的模型，也先别急着把概念讲圆。对大多数做人形机器人原型的小团队，真正该先做的不是“把智能接上去”，而是把一个最小任务闭环跑实，把人工接管、失败分桶、日志回放和机体约束接成一条能反复验证的链。做不到这一点，后面不管你接 VLM、模仿学习还是更复杂的策略，系统都只会更像一套会演示的拼接物，而不是一套在变强的机器人。
这篇最想逼你先做出的判断
如果你只能先补一层，我建议大多数团队优先补的不是模型层，而是闭环基础设施层。这不是保守，而是现实。更直白一点说：
- 先把任务边界冻住
- 先把人工接管和失败回放做出来
- 先把机体约束写进任务接口
- 先让同一个任务能连续复现几十次
这些东西听起来不“聪明”，但它们决定了你后面加上的任何智能，到底是在放大能力，还是在放大混乱。
先别再被这 4 个误解带偏
- 误解 1：具身智能先等于接大模型。
模型最多决定任务理解的一部分，真正决定机器人能不能稳定干活的，往往是感知延迟、状态估计、机体可达性、接触稳定性、失败恢复和人工接管。 - 误解 2：先把“大脑”做聪明，身体约束后面再补。
现实里通常正相反。执行器带宽、热降额、相机视角、夹爪回差、供电边界，都会直接改写高层策略还能不能落地。 - 误解 3：几个好看的 demo 拼起来，就算系统能力成立。
如果同一个任务不能稳定复现、失败不能分桶、日志不能回放、接管不能安全进入，那仍然只是展示，不是能力。 - 误解 4：具身智能默认应该从全身双足开始。
对多数团队，更稳的路径是先在受限场景里做出完整闭环，例如上半身取放、移动底盘加双臂操作、固定工位双手协作，再决定什么时候值得引入 locomotion 约束。
资源有限时，优先级到底怎么排
如果你是 1 到 10 人的小团队，我更建议按下面这个顺序分配资源，而不是同时把每一层都补一点。
- 第一优先级：最小任务闭环
先定义一个 1 到 2 周内能重复跑几十次的小任务，例如固定工位抓取、上半身取放、简单到位操作。开始条件、结束条件、失败类型必须先写清楚。 - 第二优先级：人工接管 + 失败回放
先让系统在做错时能被接住，并且做错之后能知道错在哪一层。没有这层，后面每一次“优化”都像瞎调。 - 第三优先级：机体约束进入接口
高层不能只输出“去抓这个杯子”，而要明确以什么姿态窗口、什么入射方向、什么安全速度、什么热/功率边界去完成。 - 第四优先级：稳定遥操作和数据录制
遥操作不是临时演示工具，而是闭环打样、失败样本收集和人工接管基础设施。 - 第五优先级：训练和更高层任务接口
前四层没收住，就不要过早把希望押在更大的模型或更复杂的 policy 上。
这条顺序的重点不是保守，而是承认一个现实。对大多数团队来说，最稀缺的不是“模型能力”，而是能把系统持续做实的验证链。谁先把这条链搭起来，谁后面接上的智能才更可能真的留下来。
现在先不要做的 4 件事
- 先不要写“家庭服务”“通用操作”“复杂协作”这种大目标。
目标越大，任务边界越冻不住，最后很容易一个闭环都跑不稳。 - 先不要把训练能力当成项目进展的默认指标。
如果 episode 结构不稳定、失败事件没记录、回放链路不通，训练只是在堆实验垃圾。 - 先不要默认从双足 locomotion 开始。
除非你的核心目标就是腿部能力，否则它大概率会在过早阶段吞掉你最宝贵的调试预算。 - 先不要把“看起来更聪明”当成能力成立。
会说、会规划、会出一段漂亮轨迹，都不等于系统能稳定复现任务。凡是不能稳定复现、不能安全接管、不能回放定位的“聪明”，默认都先按演示处理，不按能力处理。
最像进展，其实最容易骗人的 5 种假进展
- 一次成功视频。
只能拍出来一次，不能在受控条件下连续跑 20 到 50 次，就不能算能力成立。 - 模型输出更像人话。
如果底层执行还是经常失手、超时、接触不稳，那只是上层更会讲故事了。 - 仿真里很顺。
如果仿真和实机不共享任务接口、动作边界和失败脚本，它更像宣传素材，不像工程资产。 - 成功样本越来越多。
如果失败样本没留下、没标注、没分桶，你只是在积累乐观偏差。 - 模块越来越全。
模块变多不等于系统更强。没有清楚边界和生命周期管理，模块越多，问题越难定位。 - 每一层看起来都在推进。
感知在补、policy 在训、仿真在跑、界面在做，但没有任何一条任务链能稳定闭环，这种“全面推进”往往就是最贵的停滞。
什么情况下, 我才会说你真的在做具身智能
我不会先看你用了哪个模型，也不会先看机器人会不会说漂亮的话。我会先看这 6 条：
- 同一任务能否在受控条件下连续成功 20 到 50 次。
- 失败是否能稳定分进少数几类。 例如视觉丢失、接近姿态错误、抓取接触不足、动作越界、超时。
- 每次失败后能否靠日志或回放定位到具体层级。
- 人工接管是否真的可用。 不是急停就结束，而是能安全接住并把任务拉回到可继续状态。
- 改一版策略后，旧任务是否能自动回归。
- 高层模块是否尊重机体边界。 不会因为“目标很重要”就逼执行层去做超出能力的动作。
如果这 6 条里大部分还做不到，那我更建议你把当前阶段定义成正在搭具身闭环基础设施，而不是急着宣布自己已经做出了“具身智能系统”。这个边界很重要，因为很多团队不是死在能力不够，而是死在过早宣布自己已经拥有能力。
哪些团队最容易把力气花错地方
- 硬件和控制还没稳，就急着追高层智能包装的团队。
这类团队通常最会做 demo，也最难稳定升级。 - 把 teleop 只当临时演示工具的团队。
结果是任务打样、失败收集和人工接管三件事全都没有基础设施。 - 只留成功样本、不愿保留失败证据的团队。
最后越来越会讲成果，越来越不会改系统。 - 仿真和实机各写一套接口的团队。
训练、回归、部署永远断开，sim-to-real 只剩口号。
如果你明天就要开始做，我建议按这个顺序推进
- 选一个 1 到 2 周内能反复复测的小任务，不准写空泛目标
- 把 teleop、录制、回放、人工接管先跑通
- 补齐任务接口里的机体约束和安全边界
- 把失败事件结构定下来，让训练和排错共用同一套 episode 记录
- 只有当前 4 步已经稳定后，再去考虑模仿学习、强化学习或更高层语言任务接口
如果前 4 步还没收住，就不要再给自己加新的“智能层”任务。那通常不是提速，而是在给系统制造新的不确定性来源。
延伸阅读与参考来源
- Mobile ALOHA: Learning Bimanual Mobile Manipulation with Low-Cost Whole-Body Teleoperation
- Open-TeleVision: Teleoperation with Immersive Active Visual Feedback
- LeRobot Documentation: Imitation Learning on Real-World Robots
- Isaac Lab: Unified framework for robot learning built on NVIDIA Isaac Sim