2025 年具身智能最值得看的消息不是又发了多大的模型而是机器人到底进了哪个真实岗位。这次我们看一个清华系具身智能公司的融资和落地进展公司拿到数亿元融资机器人已经在京东超市规模化试岗消息由 36 氪硬氪首发。对开发者来说这件事有四个关键信息第一清华系意味着技术底座来自高校实验室模型和数据能力是核心资产第二数亿元融资说明资本在赌“场景落地”而不是“概念演示”第三京东超市是高频、结构化、有严格坪效要求的真实零售场景比工厂和展厅更考验稳定性第四规模化落地意味着不再是一两台样机而是一支机器人群体的协同运营。本文不猜测估值和竞对格局只从技术工程角度拆解具身智能在商超场景要解决什么问题、系统架构怎么搭、任务调度接口怎么设计、验收测试怎么过、部署会遇到哪些坑以及开发者和使用者必须遵守的安全合规边界。1. 事件核心速览与行业信号先把这个事件的关键信息整理成一张速览表方便后续展开讨论。维度说明融资主体清华系具身智能企业具体技术团队以公开报道为准融资金额数亿元人民币消息来源36 氪硬氪首发核心场景京东超市门店/仓配场景已落地能力机器人规模化试岗涉及零售门店常见岗位行业信号具身智能从实验室 demo 走向真实商业运营开发者关注点模型训练、机器人调度、接口设计、验收测试、数据回流这个事件释放的信号很明确具身智能的竞争已经从“谁能走两步”“谁能抓个杯子”进入“谁能在真实门店连续跑一个月不出事故”的阶段。京东超市这类场景包含货架盘点、缺货检测、商品补货、搬运、巡店等多个可自动化岗位任何一个岗位跑通都意味着一个新的人力替代模型出现。对工程师来说这不仅是新闻更是一个技术分水岭过去人形机器人项目大多停留在“演示视频”现在头部企业把机器人群放进了真实营业环境后端必然要配套调度系统、任务系统、监控系统和数据回流系统。这些都是值得跟踪的工程机会。2. 具身智能是什么从“感知”到“执行”的闭环具身智能Embodied AI和传统机器人的核心区别在于它不依赖预先写死的规则而是通过感知、决策、执行三者的闭环来完成物理世界中的任务。一个典型的超市场景任务可以拆成这样的闭环感知RGB-D 相机识别货架上的商品激光雷达构建门店地图。决策大模型理解“货架 A03 缺货”这个状态规划补货动作。执行机械臂抓取指定商品放到对应货位。校验视觉反馈确认摆放正确更新库存数据。如果只是在实验室做单品抓取这套闭环只算论文级实现。但放到京东超市问题会变成货架反光、商品包装变形、临时堆货、顾客走动阻挡、同一商品多个摆放位置、甚至门店灯光变化都会让模型失效。规模化落地的难点不是某一个环节做得漂亮而是整条闭环在长尾场景下保持稳定。从技术路线看目前的具身智能通常采用“分层架构”层级作用常见技术任务层理解指令、拆解步骤大语言模型、任务规划运动层生成轨迹、控制机械臂/底盘VLA 模型、MPC、强化学习感知层环境建模、物体识别视觉大模型、SLAM、点云执行层完成物理动作机器臂、移动底盘、灵巧手这种分层的好处是每一层可以独立测试和替换适应不同硬件平台。缺点是层与层之间的延迟会累积真实门店里从“看到缺货”到“完成补货”如果超过几秒钟用户体验就会明显下降。从公开报道看清华系团队往往在模型层有更强积累这也是资本愿意给数亿元融资的核心原因硬件可以代工但模型能力、数据飞轮和场景Know-how短期内很难复制。3. 清华系创业公司的技术路线特点清华系具身智能企业的典型特点是“高校实验室成果产业化”。这类团队的常见构成是学术界教授担任首席科学家博士生和工程师做核心技术外部职业经理人负责商业化。技术路线上这类团队通常押注三个方向端到端视觉-语言-动作模型VLA直接把“图像语言指令”映射到机器人动作。优点是泛化能力强缺点是训练数据需求极大、真实场景推理延迟高。遥操作数据采集通过人工遥控机器人完成大量真实操作再把轨迹数据拿来训练模型。优点是可复现性好缺点是数据规模受采集成本限制。仿真到真实迁移Sim2Real先在仿真环境里生成海量训练数据再迁移到真机。优点是成本低缺点是仿真与真实之间存在“域差”需要额外做域随机化。京东超市场景对这三条路线都有很强的检验价值门店空间大、SKU 多、光照变化明显、人流不可控正好覆盖了“数据多样性”和“异常稀疏性”两个难点。如果机器人群能在这种场景下稳定运营说明数据飞轮已经跑通。从落地位置看机器人“规模化落地”不等于每个门店都部署全套人形机器人更可能是一套混合方案轮式底盘负责巡店和盘点双臂机器人负责补货机械臂配合输送线负责后场分拣。这种人机混合、多形态并行的思路比单纯押注人形本体更务实。4. 京东超市场景拆解机器人在零售门店做什么零售门店不是单一任务场景而是一组岗位的集合。要判断机器人落地是否有效需要先拆解岗位。岗位任务内容技术难点机器人形态巡店/盘点识别货架商品、统计库存长走廊 SLAM、货架透视遮挡轮式底盘摄像头缺货检测发现空位、判断补货需求遮挡判断、商品相似度视觉识别自动补货从后场取货、放到货架抓取规划、货位匹配移动机械臂搬运商品从收货区到后场/货架路径规划、动态避障仓储机器人/AMR数据采集全场环视采集训练数据数据标注、回流任意形态其中库存盘点是目前最容易落地的岗位。原因很直接盘点是“观察型”任务不涉及复杂物理交互即使抓取能力不成熟只要视觉识别和导航稳定就能产生业务价值。缺货检测也类似本质是“找出空货架并通知人类/补货系统”。自动补货和搬运则属于“物理干预型”任务难度显著更高。机械臂要在不规则的货架上识别目标商品、规划抓取姿态、避免压坏商品整个过程需要毫秒级决策和人机安全距离控制。这也是为什么很多项目先做盘点、再做补货、最后才做全流程操作。京东超市这类门店还有一个好处货架布局相对标准化SKU 陈列规则明确。这种“部分结构化”的环境恰恰是具身智能从实验室走向量产的最佳过渡场景。如果环境完全非结构化技术挑战太高如果完全标准化传统自动化设备就够用不需要具身智能。5. 从实验室到规模化落地系统架构与硬件门槛如果一个机器人要在京东超市规模化工作它不能是“单机运行”必须嵌入一套完整的软硬件体系。下面是一个零售场景通用的具身智能系统架构。云端训练/数据平台 ↓ 边缘推理/调度服务 ↓ 门店机器人集群 ├── 感知模块相机、激光雷达 ├── 决策模块VLA/任务规划 └── 执行模块底盘、机械臂硬件门槛从四个维度看维度典型要求训练侧GPU 服务器集群训练 VLA 模型通常需要多卡并行推理侧车规级或嵌入式 GPU如 Jetson Orin 级别传感器RGB-D 相机、激光雷达、IMU、编码器通信Wi-Fi 6 或 5G 专网低延迟任务指令下发这里必须强调具体显存和算力需求完全取决于模型规模和任务复杂度不能只看单卡跑分。训练一个具身智能大模型的算力开销远高于传统目标检测模型但实际部署时通常会做模型蒸馏和量化压缩把推理放到边缘设备上。消费者和企业用户在评估时要以供应商给出的“最低运行配置”和实测车端延迟为准。从公开报道和行业惯例看规模化落地的关键不是单机能力而是“边缘成本”和“运维成本”。一台机器人如果每天运行 10 小时电池续航、充电策略、故障自检、远程升级都需要配套方案。这也是为什么很多具身智能公司会同时做“云端大脑”和“边缘盒子”把重计算放在云端把轻推理放在车端。6. 软件平台与任务调度接口设计机器人群落地之后真正考验工程能力的不是单个机器人的控制而是多台机器人的任务调度。这部分也是开发者最容易切入的技术点之一。一个标准的任务调度流程通常包含任务下发调度服务向机器人发送任务。状态上报机器人实时上报位置、电量、任务状态。动态调整高峰期或异常时重新分配任务。结果回传任务执行完成后回传日志和数据。下面是一个通用的任务调度 HTTP 接口示例实际使用时需要按项目提供的 API 文档调整地址和参数。import requests url http://192.168.1.10:8080/api/v1/tasks payload { task_id: shelf-inventory-001, task_type: inventory_check, store_id: jd_supermarket_beijing_01, priority: 1, params: { aisle: A03, check_empty: True, image_output: /data/output/inventory } } response requests.post(url, jsonpayload, timeout30) print(response.status_code) print(response.json())如果使用 ROS 2 风格的接口任务下发更接近 action 的调用形式这里给一个通用示例模板# 伪代码实际话题和服务名取决于项目 from action_msgs.msg import GoalStatus from example_interfaces.action import MoveToShelf client action_client(/robot/go_to_shelf, MoveToShelf) goal MoveToShelf.Goal() goal.shelf_id A03 client.send_goal(goal) result client.wait_for_result(timeout30) print(GoalStatus.STATUS_SUCCESS result.status)调度系统还需要定义机器人的能力描述便于任务自动匹配。下面是一个 JSON 配置示例描述机器人池和任务队列策略{ robot_pool: [ {robot_id: G1, type: inventory_base, capabilities: [navigation, inventory]}, {robot_id: G2, type: restock_arm, capabilities: [grasp, restock, navigation]} ], task_queue: { max_concurrent: 5, retry_times: 3, timeout_minutes: 10 }, failure_strategy: reassign_to_other_robot }实际项目中任务调度还要考虑机器人电量、当前任务剩余时间、货架区是否被占用等因素。建议把调度设计成“可插拔”的模块先用简单轮询调度后续再替换成基于强化学习的动态调度。不要一开始就上复杂算法零售场景的收益主要来自稳定性和可维护性。7. 功能测试与效果验证从演示到可复现很多具身智能项目在 demo 阶段很惊艳一上真实场景就崩。根本原因是测试维度和验收标准没有对齐。下面是一套面向商超场景的通用测试与验证流程。测试维度测试内容通过标准感知准确性商品识别、缺货检测 F1按供应商验收标准通常要求高召回高精确导航稳定性连续运行 8 小时不脱轨无人工干预完成巡店抓取成功率各类商品抓取成功率按 SKU 类型分开统计任务调度多任务并发、任务重分配队列不丢失超时能重试故障恢复断网、断电、机械手卡死能自动报警并进入安全状态数据回流日志、图片、任务结果完整数据格式校验通过具体操作上建议分三步。第一步小规模灰度。先选一个门店的固定时段、固定通道跑 1 台机器人收集真实数据。重点是跑通“感知 - 决策 - 执行 - 数据回流”的完整链路。第二步异常样本扩充。真实门店最大的问题是长尾场景比如商品被顾客拿走、货架被临时调整、地面有积水。针对这些异常需要人工构建测试用例确认模型不会产生危险动作。第三步规模化压力测试。5 台以上机器人在同一门店同时运行测试调度系统的并发能力。这里要重点观察任务下发延迟、地图更新冲突、机器人相互避让是否正常。测试过程中建议全程录制视频并保存原始传感器数据。具身智能项目的失败往往难以复现有原始数据才能快速定位是感知问题、控制问题还是调度问题。8. 资源占用与性能观察区别于纯云端 AI具身智能系统必须同时关注云端和边缘端的资源占用。性能观察的目标是保证机器人响应延迟在可接受范围内同时避免边缘设备过热降频。观察项工具关注点GPU 显存/利用率nvidia-smi推理耗时、显存峰值CPU 占用top / htop调度进程、感知进程负载温度jetson-stats / sensors是否降频网络延迟ping / mqtt 日志任务下发延迟电机电流底盘驱动日志是否过载云端训练侧VLA 模型训练时的显存占用通常与模型参数量和 batch size 强相关。实际训练前建议先做一个小规模“冒烟测试”确认数据加载、分布式训练、checkpoint 保存都正常再开始大规模训练。边缘推理侧常用的优化手段包括TensorRT 加速、模型量化、剪枝、只对关键区域做高分辨率推理。如果一个门店部署 10 台机器人边缘端的算力成本会成为一个不可忽视的运营指标。这里的核心原则是能用小模型解决的任务就不要上大模型能用传统算法解决的任务就不要上神经网络。另外机器人集群运行时会产生大量日志和传感器数据。建议设计数据采集开关按任务类型决定是否保存视频和点云避免数据量失控。数据回传建议使用断点续传防止弱网环境下数据丢失。9. 常见问题与排查方法具身智能落地运行的故障类型和纯软件系统有很大差异。下面是一份面向商超场景的常见问题排查表。问题现象可能原因排查方式解决方案机器人定位漂移货架变动、光线变化、激光雷达被遮挡查看 SLAM 地图与当前点云重新建图加入地标特征商品识别错误相似包装、反光、遮挡保存识别结果图片并人工复核扩充训练数据加入数据增强抓取失败商品尺寸异常、姿态估计偏差回放操作视频和机械臂日志增加抓取策略分支或人工介入任务下发超时网络波动、调度服务负载过高检查 API 日志和网络延迟增加超时重试降低并发多机器人冲突地图共享冲突、路径规划不协调查看各机器人轨迹引入交通管制模块设置优先级边缘设备过热降频散热不足、连续高负载推理查看温度日志增加散热降低推理频率数据回传丢失断网或存储空间不足检查边缘存储队列增加断点续传和磁盘水位告警机器人无法进入营业区安全策略拦截或人员未授权查看权限系统和安全日志完善白名单与授权流程排查具身智能问题时最高效的手段是保留“时间线回放”把机器人位姿、图像、任务状态、控制指令放到同一条时间轴上对齐查看。这样可以快速判断问题出在感知、决策还是执行层而不是靠猜。10. 规模化落地的成本逻辑与商业可行性融资数亿元本质是在赌“机器人替代人工”的商业模型可以成立。零售门店员工成本占运营成本比例较高如果机器人能在盘点、补货等岗位提供稳定产出ROI 会随着人力成本上升而越来越明显。从成本结构看规模化落地至少要考量四块成本项说明硬件成本机器人本体、传感器、电池、通信设备软件成本模型训练、算法授权、调度平台开发部署成本门店测绘、网络改造、系统对接运维成本维修、升级、数据标注、现场运营人员规模化摊薄的关键是“同一套模型能否低成本迁移到多个门店”。如果每个门店都要重新训练一次模型成本模型就很差如果使用基础模型加小样本适配就能形成规模效应。这也是具身智能公司强调“数据飞轮”的原因门店越多采集的真实数据越多模型越强反过来又支持进入更多场景。京东超市场景的可复制性较强因为零售门店的布局和动线有一定标准化程度。但也要看到商超场景的客单价低、利润薄机器人部署必须做到“少投入、多产出”盲目追求炫技功能无法商业化。未来 1 到 2 年真正跑出商业闭环的具身智能企业大概率是先把单场景做深做透、再复制扩张而不是同时铺十几个场景。11. 安全合规与数据边界具身智能进入真实营业场所安全与合规是底线不是可选项。任何机器人系统在商超环境中运行都必须满足以下几个基本要求。第一人身安全。机器人运行区域需要明确划分机械臂运动速度、力矩和急停逻辑必须有硬限制。人机交互场景中建议设置安全围栏、安全激光扫描仪和紧急停机按钮。涉及“人形机器人”或“机械臂”的应用更要关注机械结构可能造成的夹伤、碰撞风险。第二数据合规。机器人在门店采集的图像、点云数据可能包含顾客人脸、员工动作等个人信息。部署前必须进行匿名化处理方案设计明确哪些数据可以采集、可以保存、可以回流训练。涉及个人生物特征的项目必须遵守相关隐私保护法规并获得相应授权。第三版权合规。机器人识别和搬运的商品可能涉及品牌包装、商标训练数据中的商品图片、宣传物料不得未经授权用于商业模型训练。使用第三方模型、开源代码时同样需要保留许可证信息并遵守版权条款。第四运营合规。机器人进入商业场所运营需要评估相关安全标准和企业内部管理制度。不同地区可能有不同的安全认证要求应以当地法规和实际业务方要求为准不能直接照搬演示环境配置。对开发者来说在写代码时要主动加入数据脱敏、访问控制、操作留痕等机制。这不是额外负担而是规模化部署的前置条件。机器人厂商和门店运营方都应该把安全测试列入验收清单而不是等问题发生后再补救。12. 总结与下一步这次清华系具身智能企业获数亿元融资、机器人在京东超市规模化试岗的消息给出了一个清晰的行业信号具身智能正在从“技术叙事”转向“运营叙事”。对开发者来说最先应该关注的是任务调度接口和数据回流体系因为这两块是规模化部署最容易产生工程需求的地方。最容易踩的坑则是只看模型效果、忽略真实场景的稳定性和安全性。建议先找一个小场景做灰度把完整链路跑通再逐步扩大规模。后续可以继续跟踪的方向包括机器人是否从盘点、缺货检测扩展到补货、搬运等物理操作岗位模型迭代速度是否能跟上门店 SKU 变化调度系统在多门店复制时是否足够通用以及这类项目的商业模式能否在零售行业形成真正的 ROI 正循环。无论你是做机器人算法、后端调度还是关注具身智能商业化落地这个案例都值得收藏备用。真实场景才是检验具身智能的最终标准。