从接工单到算ROI，安努智能押注具身智能商业化|具身|安努智能|工位|底层逻辑|本体|机器人|自动化

8月26日，上海，在SAP机器人产业创新日的活动上，四类厂商出现在了同一场讨论里。

在标杆客户圆桌上，SAP副总裁薛建敏、英特尔中国边缘计算事业部行业解决方案高级架构师林丽莉、智元机器人中国区副总裁杨科，以及安努智能董事长兼CEO文宏杰，讨论了一个话题——具身智能如何真正进入工厂。

内容很快转向Intel成都工厂正在验证的仓储物流场景。SAP系统里已经有工单，也知道什么时间、什么地点需要什么物料；机器人具备搬运和执行能力；Intel提供实际工业场景和边缘计算基础。但过去，业务系统里的任务与机器人端的执行相对独立，工单并不能直接转化为机器人可执行的动作。

这次项目要解决的，正是两者之间的执行链路，让业务任务直接下达到机器人，由机器人完成任务，再把执行状态和结果返回系统。

这和过去几年行业里常见的机器人Demo不太一样。

机器人真正进入产线后，工厂看的已经不只是模型参数和动作表现。能不能稳定运行，异常后能否恢复，下一个工位能不能更快部署，以及最终能不能算清投资回报，开始成为更现实的问题。

机器人开始“接单”，具身智能接入生产系统

仓储物流并不是制造业里的新问题。变化在于，机器人开始接入企业业务系统，由工单驱动执行。

这次项目中，SAP负责企业业务系统，管理订单、库存、仓储和流程权限；Intel提供实际工业场景和边缘计算基础；智元提供机器人本体；安努位于中间环节，把企业系统里的业务任务转换成机器人可以执行的流程。

文宏杰将安努所在的这一层称为“部署层和场景智能层”。

在圆桌现场，他对安努做了一个更形象的描述：把各种不同的机器人本体接入同一条生产线，再与SAP等企业系统形成连接。

“我们干的是脏活、苦活、累活，但其实我们觉得这才是具身智能最有价值的环节。”

△Intel-SAP-安努智能联合发布具身智能产线一体化方案

以SAP EWM发出的仓储任务为例，安努负责解析工单、理解任务，调用对应的Skill并调度机器人，机器人完成选料、搬运和送达。执行过程中产生的状态、异常和结果，再返回SAP系统。

工单由此不再停留在软件系统中，而是可以驱动机器人完成现场任务，并重新进入原有业务流程。

目前，安努已经完成从SAP业务任务到机器人执行、再到结果回传的链路打通，Intel成都仓储场景仍处于验证阶段。文宏杰也强调，技术链路跑通并不等于规模商用，后续仍要经过工厂合规、验收以及多站点复制。

“接上系统”只是第一步。

文宏杰在圆桌上提到，外界容易认为系统打通是一件简单的事情，“但是稳定运行是非常需要工程化的事情”。对于工业现场而言，更难的是让这套业务流程长期、稳定地运行在机器人本体上。

Demo之后，工厂开始算稳定性和ROI

圆桌结束后，文宏杰在36氪的专访中谈到一个判断：“Demo看的是能力上限，工业客户看的是能力下限。”

机器人完成一次抓取或搬运，只能证明这项能力存在。到了工厂，换一个班次、改变光照或更换物料后还能不能正常工作，出现异常后多久能够恢复，往往比一次动作做得多快更重要。

文宏杰举例说，一个动作即使快10%，如果每天需要多次人工干预，商业价值也可能不如一个稍慢、但更加稳定、容易维护的方案。

富临精工的现场就遇到过类似问题。

原来使用的灰色料箱换成黑色后，因为反射光减少，视觉和雷达识别受到影响，机器人的抓取表现随之下降。工人临时经过、物料位置偏移、夹具磨损、导航误差，也都可能影响连续作业。

很多问题很难在实验室里提前穷尽，只能在真实产线上长时间运行后逐步暴露。

安努团队因此长期驻场富临精工。据公司披露，目前设备平均故障间隔时间（MTBF）已经超过300小时。

另一个变化发生在部署周期上。

富临首个工位最初用了约4个月，随后同产线部署压缩到约1周。据安努方面披露，部分成熟同类工位已经进入3天级部署。文宏杰同时强调，目前明确验证的是从4个月缩短到1周；3天主要适用于产品边界清晰、接口和本体已经适配的成熟标准场景，全新的非标任务仍需重新评估。

这也是文宏杰反复强调“部署”的原因。

在他的定义里，部署并不等同于传统集成。集成和二次开发只是其中的一部分，更重要的是把一个项目中高度非标的方案逐步做成可复用产品，让同一套流程、模型和Skill可以向新的工位和机器人迁移。

富临项目还有一组更直接的运营数据。

需要人工介入的问题，已经从每天超过10次下降到每周约2至3次；单台机器人单班效率约为单个人工的70%，通过换电实现两班连续运行后，综合相当于约1.4名产业工人。按照安努现有成本模型测算，投资回收期约3年。

对工业客户而言，机器人完成一次任务只能证明技术可用。能否降低人工干预、缩短部署周期，并最终把ROI算清楚，才决定它能不能真正进入生产。

先啃部署再迭代模型，安努押注现场

文宏杰曾经是一名产业及投资老兵。

他在访谈中说，以前看一家公司，往往先看技术路线、团队背景、市场空间和资本效率。真正进入工厂以后，他对具身智能的理解发生了变化。

真实产线上，机械、算法、控制、工艺和安全相互牵连。单项技术指标做得足够好，并不能保证整套系统长期运行。

安努的路线也因此逐渐明确。

过去一年，不少具身智能公司先做模型，再寻找落地场景。安努选择先进入工厂，把部署过程中暴露的问题解决掉，再用真实数据迭代模型。

公司内部有一句话：“模型可以开源，但部署经验无法开源。”

安努也把工厂项目看成产品研发的一部分。团队进入场景后采集真实数据，机器人上岗后持续记录工况和失败案例，再通过后训练和强化学习迭代。已经解决的问题如果具备共性，则进一步沉淀为Skill、模型和部署工具，供下一个工位和下一类机器人使用。

安努内部把这套工作方式类比为FDE（Forward Deployed Engineering，前沿部署工程）。工程师进入客户现场解决问题，但项目结束后，真正需要留下来的不是驻场人力，而是能够继续复用的产品能力。

文宏杰在圆桌上把这套逻辑称为“数据飞轮”。

机器人进入产线以后，在运行中不断积累数据，再通过训练继续升级。只有这套循环真正跑起来，机器人能力才可能随着实际使用持续提高。

在文宏杰看来，这也是具身智能与传统工业自动化的一项重要区别。过去的协作机器人和自动化设备更多依赖预设规则，具身智能则试图让机器人具备持续学习和适应环境的能力。

他在圆桌上说，希望具身智能最终能够“让工厂里的每一个岗位都持续学习、自主升级，成为工匠大师”。

这条路径也决定了安努目前的资源投入方向。

安努没有自己造机器人本体，也没有把资源全部押在一个通用基础模型上。公司希望长期沉淀的是工业数据、工艺Know-how、垂类模型、Skill、调度系统以及不同本体之间的适配能力。

可复制性决定商业化上限

项目越多，具身智能公司越容易遇到一个现实问题，那就是交付团队是否也必须同步扩大。

如果每进入一家工厂、增加一个工位，都要重新派工程师驻场、采数据、写接口和调系统，那么收入增长的同时，交付成本也会同步增加。

文宏杰判断一个项目是否开始产品化，看的是第二次交付有没有发生变化。

核心流程能否被拆成标准Skill和接口，失败数据能否自动回流，新客户是否只需要少量数据微调和适配，而不用重新开发整套系统，都是他关注的指标。

安努希望最终形成的，是一层可以连接不同企业系统和机器人本体的软件能力。就像机器人世界里的“Office系统”或核心APP。按照文宏杰的设想，上层企业业务系统保持稳定，中间由安努负责理解任务、选择模型、组合Skill并调度机器人，底层则根据不同场景接入不同本体。即使更换机器人品牌，已有的工艺知识、数据和系统接口也不需要全部推倒重来。