点击下方卡片，关注【Xbotics具身智能实验室】公众号
你想要的这里都有~~
作者/木木
最近听了深圳地瓜机器人有限公司（下称“地瓜机器人”）软件平台副总裁秦玉森的一场访谈，对具身智能 Infra 有了更深入的了解，写出来和大家分享。
访谈中，森哥从算法工程师每天都会遇到的一件事讲起。
算法工程师想验证一小段程序，要先打通电脑、服务器和机器人的底层子系统，处理环境和依赖，再协调不同团队的人配合。等到代码终于能在真机上运行，一天可能已经过去了大半。
每天工作 10 个小时，真正用来验证核心算法的时间，可能只有 1 到 2 小时。剩下的时间，都花在了让系统跑起来这件事上。
这些准备工作一层层叠起来，算法迭代也就慢了下来。具身智能 Infra 要做的，就是把这段链路压短，让工程师更快拿到真机反馈，开始下一轮验证。
森哥借用自动驾驶中的OTA来类比Infra 在持续迭代中的作用：自动驾驶通过 OTA，把新的软件版本持续推送到车辆上。具身智能的开发链路更长，要把开发、仿真、训练、评测、部署和真机反馈连起来。OTA 对应其中的部署和更新环节，也是整个系统里很重要的一部分。
所以，具身智能 Infra 要缩短的，是想法、代码、模型、机器人行为、真实反馈和下一次迭代之间的距离。单靠一个模型训练平台，很难把这条链路全部跑通。
从写代码到真机反馈，一次迭代要经过哪些步骤
把已经确定的软件包推送到设备，只覆盖了部署环节。具身智能开发还要处理更前面的工作，团队往往仍在寻找适合当前任务的软件版本和算法方案。
一个想法变成机器人的实际动作，要经过代码开发、编译、仿真、训练、评测和部署。机器人运行起来后，还要采集数据、分析失败、完成回放或标注，再进入下一轮训练。
这是一条完整的机器人开发闭环。开发、仿真、数据、训练、评测、部署和真机反馈都要接得上。任何一个环节太慢，都会拖住下一次实验。
所以，判断一家机器人公司的研发效率，可以看模型当前的成功率，也可以看一个更具体的数字，一天能完成多少次有效实验。
假设 A 公司完成一次修改参数、真机验证、获取数据、定位失败、修改模型的循环需要 3 天，B 公司只需要 3 小时。即使两家公司今天的算法水平相同，半年后也会拉开很大差距。每轮实验都快一点，经过几个月的连续积累，差距就会变得非常明显。
这种变化，工程师的感受最直接。
森哥提到自己负责算法平台部门时的体会，工程师亲手做出来的东西，很快就能在机器人上运行，大家开玩笑把这种状态叫作育娃速度加倍。机器人开发确实很像养孩子，今天不会抓，明天会抓了，下周抓稳了，之后还能慢慢学会处理异常。
开发者最有成就感的时刻，往往是看到自己写的代码变成机器人的新动作、新能力。Infra 把中间的等待压缩下来，工程师修改代码之后，可以更快看到机器人学会了什么。
算法工程师兼职搭工具，已经跟不上迭代速度
行业发展较慢、竞争压力较小时，企业没有那么强的时间压力。从全生命周期成本，也就是 TCO 来看，让算法工程师兼顾内部工具的开发会更省钱。
过去十几年，很多机器人公司都是这样工作的。算法团队一边做算法，一边写部署脚本，搭 Docker 环境、日志系统、数据转换工具和标定程序。不同团队遇到相似的问题，又各自做一套，重复工作越来越多。
这也带来一个很典型的现象，叫作上半年做产出，下半年做产能。
团队上半年忙着交付功能。做着做着，测试太慢、部署太麻烦、日志查不到、模型版本混乱等问题逐渐堆起来。到了下半年，只能停下来补工具、改流程，为下一年的研发做准备。业务团队既要开发机器人的能力，也要开发支撑这些能力的工具。
行业进入高速发展期后，这套工作方式开始跟不上节奏。模型、硬件和应用都在快速变化，晚几天完成一次验证，后面的开发都会受到影响。于是，团队开始出现更明确的分工，一拨人负责算法和产品能力，另一拨人专门提高研发效率、建设开发闭环。
森哥的判断很直接：行业发展得足够快，一部分人专门做产出，另一部分人专门提高产能，才会成为有价值的分工。企业愿意为了速度购买产品和服务，也说明迭代效率已经产生了直接的竞争价值。
当企业开始为迭代速度设立专门团队、购买产品和服务，专业 Infra 的需求也随之出现。
一套具身智能 Infra 具体要解决哪些问题
如果目标是缩短从想法到真机反馈的时间，具身智能 Infra 就要覆盖机器人开发的完整过程。GPU、数据集、训练脚本和实验管理都很重要，训练位于整条链路的中间，很多耗时的问题出现在训练前后。
算法工程师每天遇到的问题很具体。代码写好后，要适配不同机器人的接口，把模型从服务器部署到边缘设备，还要确认软件版本与机器人固件是否匹配。
机器人开始运行后，每次实验所用的模型、参数和标定文件都要留档，传感器数据、控制指令、模型输出和系统日志也要完整记录。出现失败时，团队需要快速定位问题，在仿真中复现，再把重新训练后的模型部署到几台机器人上继续验证。
一套完整的具身智能 Infra，要贯穿这样一条链路。
开发 → 仿真 → 数据 → 训练 → 评测 → 部署 → 真机运行 → 监控 → 回放 → 失败分析 → 数据回流 → 再训练。
它更像机器人的开发操作系统，把各个环节接在一起，让每次实验都能被完整记录，并在后续开发中复现和复用。
第一层，设备与运行时基础设施
这一层负责让代码稳定运行在机器人上，涵盖设备管理、算力调度、容器环境、依赖管理、远程部署、版本控制、日志采集、状态监控，以及不同机器人本体的接口适配。
这一层的目标，是让算法工程师可以像调用云服务器一样调用机器人，不用反复确认机器人连接了哪台工控机、使用什么网络、启动了哪些 ROS 节点。准备环境的时间少一点，验证算法的时间就能多一点。
第二层，开发与仿真基础设施
机器人算法不能每次都从真机开始验证。理想的 Infra 要让同一套代码在本地、仿真、硬件在环和真实机器人之间顺畅迁移，支持单元测试、场景测试、回归测试和大规模并行仿真。
Isaac Sim、MuJoCo 和 Genesis 都可以提供仿真能力。有了工具只是第一步，仿真还要进入日常研发流程。工程师在仿真中发现的问题要能回到代码，真机上的失败也要能在仿真中复现。这样一来，仿真才能真正接入开发闭环。
第三层，数据基础设施
机器人数据记录的是一段完整的行为过程。图像、深度图、点云、关节状态、力矩、动作指令、语言指令、模型中间输出、系统日志和环境状态，都带着严格的时间关系。
所以，数据平台要帮助工程师回答一个非常切实的问题，这次失败到底发生了什么？
模型抓偏了，可能来自视觉检测错误、位姿估计漂移、轨迹规划失败，也可能来自控制延迟。工程师需要迅速找到对应的数据片段，完成搜索、回放和标注，再把它送回训练集。现实世界中的一次实验成本很高，记录得越完整，后续可以复用的次数越多。
第四层，训练与模型基础设施
这一层包括数据集管理、训练任务调度、GPU 集群、分布式训练、模型版本管理、实验追踪和超参数管理，也要支持 VLA、Diffusion Policy、ACT、RL 等不同算法范式。
模型训练完成后，还要确认它有没有让机器人变强。模型用了哪些数据、参数改了什么、结果比上一版好多少，都要留下清楚的记录，方便团队比较和复现。
第五层，评测基础设施
机器人模型很难只靠一个 Benchmark 说明效果。一个策略上线前，团队要知道它在不同物体、不同光照、不同桌高、不同机器人和不同初始位姿下的成功率，也要清楚常见的失败类型，以及性能相较上一版本的具体变化。
机器人 Infra 迟早会引入类似 CI/CD 的流程。提交一次代码后，系统自动完成仿真测试、模型评测、真机小规模测试、性能对比和回归测试。算法迭代也会逐渐从主观感受，转向明确的测试结果。
假设 V128 相比 V127，在 200 个场景、3000 次仿真和 100 次真机测试中，整体成功率提升 3.7%，但透明物体场景下降 5.2%。一份 Robot CI 报告可以把这些变化明确写出来，让团队知道哪些能力进步了，哪些问题还要继续处理。
第六层，部署与机器人集群基础设施
当机器人数量从 3 台增加到 30 台、300 台、3000 台，管理重点就会从单台机器人转向整个集群。团队要统一管理每台机器人的模型版本和相机标定参数，追踪异常版本，并支持 5% 灰度升级和自动回滚。
这些都属于机器人集群管理，也就是 Fleet 基础设施。OTA 在这一层承担模型和软件版本的持续推送、灰度发布与回滚，成为具身智能 Infra 中负责部署和更新的一环。
在这六层之外，还有持续学习和数据闭环。
机器人部署到现实环境后，会不断产生新的数据。系统需要发现失败案例、长尾案例和模型不确定的案例，把对应数据送回标注、训练和评测系统，用于下一轮模型训练。
整个过程会形成一条循环。
Robot → Data → Training → Evaluation → Deployment → Robot。
机器人在现实世界工作，也在为下一轮训练生产数据。一次失败被记录、分析并送回训练系统后，就有机会转化为下一版模型的训练材料。
前五层把开发、仿真、数据、训练和评测接起来，第六层负责把模型稳定部署到更多机器人上，持续学习再把真机数据送回下一轮训练。
如果给具身智能 Infra 画出一个大致范围，它至少要覆盖 Robot Runtime、Simulation、Data、Training、Evaluation、Deployment、Observability、Fleet 和 Continuous Learning。模型训练平台是这套系统中的一个模块。
理想状态下，算法工程师修改一段代码，或者训练出一个新模型，只需要提交一次，系统就能自动完成环境构建、仿真回归、模型评测、机器人部署、真机测试、数据记录和失败回流。
到那时，开发者可以把更多时间留给两个问题，想让机器人获得什么新能力，以及它现在为什么还做不到。环境配置、版本核对、日志收集和重复部署等工作，可以逐步交给 Infra 完成。
算法和机器人都在变，Infra 该怎么建
把上面这些能力全部做出来很有吸引力，真正开始建设时却有一个绕不开的难题，具身智能的底层技术还没有收敛。
传统云计算依赖的 CPU、Linux 和 TCP/IP 已经长期稳定，具身智能使用的算法范式、机器人本体和软硬件接口仍在快速变化。今天适用的模型和开发流程，过一段时间可能就要调整。
森哥在访谈中也谈到了这种不确定性。具身智能的前沿技术尚未收敛，行业也还没有完全看清，哪些问题最终会成为各家公司都要解决的共性问题。
因此，Infra 不能过度设计。系统要保持开放、模块化和可替换，能够接入不同机器人，也能容纳模型和算法范式的变化。如果一套系统和某一种本体、某一类模型绑得太紧，底层技术一变，上面的工具也要跟着重做。
谈到目前的建设进度时，森哥用 59 和 61 来形容这种持续追赶的状态。Infra 今天从 59 推进到 61，第二天模型、机器人或任务发生变化，按照新的要求重新衡量，原先的 61 可能又成了 59。
这个比喻想表达的是，具身智能仍在探索，Infra 很难等技术路线完全确定后再开始建设。现阶段只能先解决已经出现的问题，再跟着业务继续调整。森哥把这个原则概括为够用就行，赶紧往前跑。
技术路线今天走到 61%，明天可能又回到 59%。可无论模型和机器人怎样变化，设备仍要连接，数据仍要记录，模型仍要部署，失败仍要回放。Infra 要做的，就是让这些反复发生的工作越来越快、越来越稳。
回到文章开头，衡量一套 Infra 有没有价值，还是要看一个最具体的数字，一家公司一天能完成多少次有效实验。
当一次完整迭代从 3 天缩短到 3 小时，省下来的时间会直接变成更多真机反馈，团队也能更快开始下一轮实验。机器人公司的长期差距，就是在这样一轮轮实验中拉开的。
-END-
Ask Me Anything｜提问箱
对文章有疑惑，或想聊更深？欢迎把你的问题丢给我们：技术方案、实操踩坑、课程与资料、项目合作、职业发展，都可以问。
怎么问：在评论区留言，或私信公众号
我们会做什么：每周集中整理高质量问题并公开回复，重点问题邀请作者或嘉宾深度解答；典型问题会加入知识库并持续更新。
提问小提示：尽量说明「你的目标—当前做法—期望产出」，附上必要信息（硬件/软件版本、数据规模等），能更快获得有用答案。
一起把问题变成知识，推动社区进步 🚀
