很多团队把“更大的模型”当成人形机器人能力升级的起点，但真正决定系统能不能落地的，往往是智能怎么分层部署。这篇文章要解决的核心问题是：一台人形机器人，哪些能力必须留在本体实时环里，哪些适合放到边缘端做感知与任务编排，哪些又应该留给云端做训练、回放、版本管理和数据闭环。它适合正在搭 humanoid 原型机、实验平台或小规模部署系统的读者。最关键的工程判断不是模型参数量，而是你有没有把延迟、带宽、失效模式和回退路径先设计清楚。
这篇适合谁
- 正在搭人形机器人原型，希望把本体控制、感知、规划、训练流程分开的团队
- 已经有单机 demo，但一接入外部相机、边缘盒子或远程运维就开始不稳定的开发者
- 想把策略训练、数据回放、模型更新和现场部署串起来的人
- 准备做小规模 robot fleet，却还没有想清楚软件分层和版本边界的人
先纠正几个很常见的误区
- 误区 1：所有智能都尽量放在机器人本体上。
本体上应该放“掉线也必须继续安全运行”的能力，而不是把所有大模型、日志分析、任务配置都塞进去。 - 误区 2：上云就等于更高级。
云端适合训练、评测、数据治理和版本管理，不适合承担毫秒级闭环决策。 - 误区 3：先把模型跑起来，系统架构以后再补。
很多团队最后卡死在消息时序、接口契约、日志格式、模型热更新和故障回退，这些都不是后补能轻松补上的。 - 误区 4：只要 ROS 2 能通，系统就算打通了。
消息能通不代表部署能用。真正难的是优先级、时钟同步、资源抢占、重试策略、异常升级和回放一致性。
关键实现判断：先按“时延要求”和“失效代价”切层，不要按团队分工切层
人形机器人的分布式智能层，建议至少拆成三层：
- 本体实时层，负责关节控制、状态估计、接触判断、基础避障、急停、安全降级。这一层的原则是：网络断了也要继续活着。
- 边缘执行层，负责多相机感知、任务编排、地图/工位上下文、外部系统接口、较重但仍要低延迟的推理。这一层通常放在工位边缘盒子或现场服务器。
- 云端训练与运维层，负责数据汇总、回放分析、模型训练、评测基线、版本发布、灰度策略和故障归档。这一层追求的是效率与治理，不是实时性。
如果你是按“控制组一套、算法组一套、平台组一套”来划边界，后面几乎一定会出现重复状态、接口漂移和无人负责的灰区。更稳妥的切法是问两个问题：
- 这个模块最晚能容忍多大延迟？
- 这个模块一旦失效，最坏会造成什么后果？
凡是延迟预算紧、失效代价高的模块，越应该靠近本体；凡是需要更多算力、更多上下文、更多历史数据的模块，越适合往边缘和云端迁移。
分步实践指南
第一步，先画出你的能力分层表，而不是先画系统大图
先用一张表把系统能力拆开，至少列出这几列：模块名、输入、输出、最大允许延迟、失效后果、默认部署位置、回退策略。一个可用的起点如下：
- 关节控制器，1 到 2 ms，部署在本体控制机，失效则立刻触发安全停机
- 状态估计与接触检测，2 到 10 ms，部署在本体计算单元，失效则降级为低速模式
- 操作目标检测，50 到 150 ms，部署在边缘盒子，失效则切回保守动作模板或人工接管
- 任务规划与技能编排，100 到 500 ms，部署在边缘端，失效则保留当前安全状态并等待重试
- 日志上传与数据打包，秒级，部署在边缘或云同步代理，失效不应影响主任务执行
- 训练、评测、模型注册、回放分析，分钟到小时级，部署在云端
这一步做完，你后面所有部署、接口和测试都会清楚很多。很多系统之所以越做越乱，就是因为从来没有人把“延迟预算”和“失效代价”明文写下来。
第二步，给本体实时层设硬边界
本体实时层不要贪多，它的目标不是“最聪明”，而是“最稳、最可预测”。建议至少包含这些能力：
- 电机与驱动闭环
- IMU、编码器、力/接触信号读取
- 状态估计和姿态稳定
- 本体局部安全检测，例如关节过流、温度、跌倒风险、碰撞阈值
- 最小安全动作集，例如停下、撤回、下蹲、保持支撑
不要把依赖远程模型返回结果的关键动作许可放在这一层。一个常见事故模式是：机械臂或上肢要等外部识别结果回包才能决定是否收回，结果网络抖动时人和机器人都卡在危险区。
第三步，把边缘层当成“现场大脑”，而不是简单转发器
边缘层最有价值的角色，是把“本体视角”扩展成“任务视角”。它通常负责：
- 融合机器人本体相机、天花板相机、工位相机或外部传感器
- 维护任务上下文，例如当前工单、工位状态、可用工具、区域限制
- 运行较重的视觉或 VLA/VLM 推理，但输出要被约束成可执行的结构化结果
- 负责技能调用、任务编排、重试、异常升级、人工接管接口
- 与 WMS、MES、工位 PLC、门禁、充电系统等外部接口打通
这里我更推荐“结构化接口”，不推荐让大模型直接输出一长段自然语言给机器人。边缘层更像一个任务编排器，应该把模型输出整理成明确字段，例如目标对象、置信度、目标位姿、动作模板、前置检查项、失败后回退路径。
第四步，云端只做三件高价值的事：训练、治理、发布
云端最容易被滥用。一个健康的云端层，重点应放在：
- 训练与评测，做数据集整理、策略训练、离线回放、基线对比和回归评测
- 治理与可追溯，做模型注册、配置版本化、实验记录、日志归档、失败样本分桶
- 发布与回滚，做灰度发布、设备分组、版本锁定、回滚策略和发布审批
如果你现在把任务执行主链路依赖在云端 API 上，我会建议先收回来。现场系统断网、限速、隧道抖动、证书问题，都不应该直接让机器人丢失基本执行能力。
第五步，统一消息契约，不要让每层都维护一份“差不多”的状态
分布式系统最容易出事的地方，不是模型精度，而是状态不一致。建议你至少统一以下对象：
- 机器人状态，包含位姿、模式、错误码、电池、温度、当前技能、人工接管状态
- 任务状态，包含工单 ID、步骤编号、前置条件、超时、重试次数、完成判据
- 感知结果，包含来源传感器、时间戳、坐标系、置信度、候选对象列表
- 动作指令，包含目标、约束、授权来源、生效时限、取消条件
不要让本体、边缘、云端各自维护一份字段略有不同的 JSON。后面一到回放、审计和故障定位，就会发现根本对不上。
第六步，把日志和回放系统当成主功能来做
想把分布式智能层跑稳，必须能回答这几个问题：
- 某次失败是感知错了、规划错了，还是执行时环境变了？
- 边缘模型给出的候选结果，当时机器人到底收到了哪一份？
- 动作开始时，机器人看到的状态和任务系统记录的状态是否一致？
- 升级一个模型版本后，失败率究竟是下降了还是只是换了失败类型？
所以日志至少要覆盖：原始关键传感器摘要、结构化感知输出、技能输入输出、状态机跳转、模型版本号、配置版本号、人工接管记录、最终判定结果。没有回放系统，你的分布式架构最后会沦为“每次出问题都靠猜”。
第七步，先设计灰度发布和回退，再谈规模化
只要系统开始跨本体、边缘、云端三层运行，你就已经不是在部署一个程序，而是在运营一个机器人软件产品。至少要有这些机制：
- 设备分组发布，不要一次推全场
- 模型版本与配置版本解绑，避免问题扩大时无法定位
- 每次发布都要能一键回退到最近稳定版本
- 新模型先跑影子评测或旁路评测，再进入主链路
- 现场异常率、人工接管率、任务完成时间要持续监控
如果没有这些基础设施，你会发现系统越聪明，现场越不敢升级。
最容易翻车的地方
- 边缘端算力被视觉模型吃满，拖慢任务编排。
解决办法是把感知推理、任务调度、日志写盘分成不同进程或容器，并做 CPU/GPU 资源上限。 - 时间戳不统一，导致感知结果和动作执行对不上。
至少统一时钟源，并在每条关键消息里写清采集时间、发送时间、接收时间。 - 云端版本更新了，但边缘缓存没刷新。
必须让版本号进入运行时状态与日志，不要靠“感觉已经同步了”。 - 模型输出不可执行，只能靠人工理解。
把自由文本约束成结构化动作建议，必要时增加规则层做二次裁剪。 - 网络抖动时系统没有明确定义谁接管。
掉线后要明确回到本体保守模式、边缘重试模式还是人工接管模式，不能等现场人员临时判断。
怎么验证你的分布式智能层是不是靠谱
- 做一次断网演练，验证本体是否还能安全停机或保持最低能力
- 做一次边缘盒子重启演练，验证任务是否能中断保护、恢复或人工接管
- 做一次模型回滚演练，验证版本切换是否真的可追溯
- 做一次回放复盘，随机抽一条失败任务，检查能否从日志还原出关键决策链
- 做一次延迟压测，人为注入 100 到 500 ms 抖动，观察系统在哪一层先失稳
如果这些演练做不了，你的系统还不能算真正准备好进入持续运行阶段。
下一步怎么做
如果你刚开始搭系统，我建议按下面顺序推进：
- 先定义本体实时层边界和最小安全动作集
- 再把边缘层做成结构化任务编排器，而不是模型大杂烩
- 然后统一消息契约、日志格式和版本号
- 最后再补训练闭环、灰度发布和 fleet 运维能力
顺序不要反过来。先堆模型、最后补回退，是很多 humanoid 项目又贵又不稳的根源。