从“拼身体”到“拼大脑”:具身智能进入真实场景后,实时控制才是真正的底座
最近一段时间,机器人行业正在发生一个比较明显的变化。
过去几年,人们讨论机器人时,经常会把注意力放在“身体能力”上:能不能跑、能不能跳、能不能完成复杂动作,机械臂能不能快速抓取物体。到了2026年,随着大模型、视觉感知和具身智能技术不断发展,行业关注点开始逐渐发生变化。现在真正值得关注的问题已经不只是机器人“能做什么动作”,而是它能不能进入真实的工作流程,并且持续、稳定地把工作做好。
9月9日至12日在上海举行的2026 Inclusion·外滩大会,就释放出了一个非常明显的信号。此次大会有40余家具身智能厂商集中亮相,与过去偏重运动能力展示不同,本届展区出现了越来越多与真实产业流程结合的案例,覆盖药房、工业制造、物流分拣、巡检、康养等场景。机器人正在从实验室里的“演示设备”,逐渐变成真正参与生产和服务流程的“工作设备”。
其中一个非常有代表性的案例,是蚂蚁灵波展示的机器人智慧药房。据公开报道,相关机器人已经在上海国大药房真实门店开展药品分拣工作,在不改变原有门店布局和药品摆放的情况下,需要在约80厘米宽的货架通道中自主完成订单接收、药品识别、分拣和交付。与此同时,LingBot-VLA 2.0还在探索“一脑多机”的模式,面向不同厂商、不同机器人构型进行适配。
这些信息表面上看是在说明具身智能模型越来越强,但从工程技术角度看,它背后其实对应着一个更加值得关注的变化:
机器人行业正在从“拼身体”逐渐走向“拼大脑”,而当大脑真正进入机器人之后,实时控制的重要性反而会越来越高。
从“会动作”到“会干活”,机器人真正面对的是一个实时闭环
如果把一个真正进入生产环境的机器人拆开来看,它实际上并不是简单地由一个大模型直接控制机械臂。
机器人首先需要通过摄像头、力传感器、位置传感器等设备感知环境,然后由AI模型理解当前场景,再根据任务目标进行决策和动作规划,最终把规划结果交给运动控制系统,由控制器驱动电机、关节和执行机构完成动作。
因此,一个完整的机器人控制链路可以抽象成:
环境感知
↓
AI理解与推理
↓
决策与动作规划
↓
运动控制
↓
伺服与执行机构
↓
机器人动作
↓
传感器反馈
↓
再次感知与调整
这个过程并不是执行一次就结束,而是一个不断循环的闭环。
机器人看到目标之后,需要判断下一步怎么做;执行动作之后,又要根据新的传感器数据判断当前动作是否达到预期;如果环境发生变化,还需要重新调整后续动作。
这也是具身智能与传统自动化控制一个非常重要的区别。
传统工业控制系统往往可以针对确定的输入和确定的设备建立比较明确的控制逻辑,而具身智能面对的是真实世界。目标物体的位置可能发生变化,环境可能存在遮挡,机器人可能受到外部扰动,甚至同一个动作在不同情况下都需要进行不同程度的调整。
因此,未来机器人很可能越来越多地采用类似“感知—预测—执行—反馈—修正”的在线闭环。
而一旦进入这个闭环,一个过去在AI领域没有那么突出的指标,就会变得非常重要:
时间。
AI模型可以非常聪明,但如果它在需要的时候没有及时给出结果,机器人依然可能无法完成动作。
AI推理很快,为什么机器人仍然可能“不实时”?
很多人第一次接触机器人AI控制时,容易把“算力”和“实时性”混在一起。
例如,一套AI模型平均只需要10毫秒完成一次推理,看起来已经非常快。但对于机器人控制系统来说,平均10毫秒并不一定意味着它就是实时的。
假设机器人存在一个严格的控制周期:
0ms 1ms 2ms 3ms 4ms
|---------|---------|---------|---------|
控制 控制 控制 控制
理想情况下,每一个周期都应该在规定时间窗口内完成计算并产生控制输出。
但实际运行时,系统可能同时存在AI推理、视觉处理、网络通信、日志记录、传感器采集、后台任务以及操作系统内核活动。
某一个时刻,实时控制任务需要运行,但CPU正在处理其他任务;或者一个设备中断突然进入;又或者任务需要等待一个共享资源。
最终可能出现这样的情况:
0ms 1ms 2ms 3ms 4ms
|---------|---------|---------|---------|
控制---------------->
延迟
从平均性能来看,系统可能依然非常快,但某一次控制周期已经超过了规定的时间窗口。
这就是实时系统和普通高性能系统之间非常重要的区别。
高性能关注的是平均情况下能做多少;实时系统更加关注最坏情况下什么时候必须完成。
因此,对于机器人而言,“平均推理延迟”只是一个指标,还需要进一步关注延迟的波动以及最坏情况下的响应时间。
尤其当机器人开始进行高速运动控制、精细抓取、力反馈或者人机协作时,这种差异会更加明显。
“一脑多机”真正的工程难点,其实是软硬件解耦
这次外滩大会上另一个值得关注的关键词,是“一脑多机”。
从产品宣传角度来看,一脑多机很好理解:同一套机器人“大脑”,可以适配不同品牌、不同结构的机器人。
但从工程实现角度来看,这其实提出了一个很大的挑战。
假设机器人A是一台单臂机械臂,机器人B是一台双臂机器人,机器人C是一台轮式机器人,它们的关节数量、运动学模型、传感器、执行机构、驱动方式甚至底层计算平台都可能不同。
如果AI模型直接和这些具体硬件打交道,那么每换一种机器人,就意味着需要重新适配大量软件。
因此,更合理的架构应该是在AI和具体硬件之间建立一层或者多层抽象。
例如:
AI模型
↓
任务/动作抽象
↓
运动规划
↓
运动控制抽象层
↓
实时控制系统
↓
驱动
↓
机器人硬件
上层AI不需要知道每一个电机的具体实现方式,而是通过统一的动作接口向下层系统提出要求。
下层系统则负责把这些抽象动作转换成具体机器人可以执行的控制指令。
从这个角度来看,“一脑多机”与工业控制领域近年来不断强调的软件定义、软硬件解耦,其实存在非常相似的技术逻辑。
软件越希望跨硬件复用,越需要一个稳定、清晰且低延迟的抽象层。
但这里又会产生一个新的问题。
抽象层越多,会不会带来更多延迟?
答案是:确实存在这种可能。
如果AI决策、动作抽象、运动规划、通信、控制以及驱动之间存在过多的软件层级,那么一次动作从模型产生到最终执行机构响应之间,就可能产生额外的调度和通信开销。
对于普通应用而言,这些开销可能完全可以接受。
但对于毫秒级甚至更短周期的实时控制而言,每一个环节都需要重新考虑。
因此,“一脑多机”不仅仅是AI模型适配能力的问题,它实际上也对底层实时软件提出了新的要求。
当AI和实时控制运行在同一台机器上,真正的问题开始出现
未来的机器人控制器很可能不会只运行一个实时控制程序。
同一台设备上可能同时运行视觉模型、AI推理、路径规划、传感器处理、运动控制、设备驱动、通信协议以及各种系统服务。
这些任务的计算特征完全不同。
AI推理可能需要大量CPU、GPU或NPU资源,但对几十毫秒的延迟波动可能没有那么敏感;后台日志任务可以稍晚一点执行;网络管理任务也不一定需要严格的时间约束。
但运动控制任务可能要求在固定的控制周期内完成。
这意味着未来机器人操作系统面对的一个关键问题,很可能不是“让所有任务都实时”,而是:
让不同实时等级、不同计算负载的任务能够在同一个系统中稳定共存。
例如一个多核CPU系统:
CPU Core 0 AI / Vision
CPU Core 1 AI / Vision
CPU Core 2 System / Network
CPU Core 3 Real-Time Control
这种资源规划的意义就在于,让不同类型的任务尽量不要互相影响。
如果AI推理突然产生大量计算负载,不能让它直接把实时控制任务需要的CPU资源全部占用;如果大量设备中断集中到实时CPU上,也可能导致实时任务的执行时间产生波动。
因此,机器人控制器未来需要的不只是更强的芯片,还需要更加精细的系统资源管理。
这也是实时Linux技术开始重新受到关注的重要原因之一。
PREEMPT_RT解决的是“及时运行”,核心隔离解决的是“减少干扰”
在实时Linux系统中,PREEMPT_RT是一个非常重要的技术路线。
它的核心目标并不是让CPU本身变快,而是通过提高Linux内核的可抢占能力,让实时任务在变得可运行之后能够更加及时地获得CPU执行机会。
简单来说,如果一个高优先级实时任务已经准备好运行,而当前内核执行路径存在较长的不可抢占区,那么这个实时任务就可能需要等待。
PREEMPT_RT通过对内核执行机制进行大量实时化改造,使更多内核执行路径具备更好的可抢占性,从而降低这类调度延迟。
但即使采用了PREEMPT_RT,也不意味着系统中的实时任务从此不会受到任何干扰。
假设一个实时任务被安排在CPU Core 3上运行:
CPU Core 0 普通任务
CPU Core 1 普通任务
CPU Core 2 普通任务
CPU Core 3 RT Task
表面上看,实时任务已经“绑核”。
但如果CPU Core 3上仍然不断出现IRQ、定时器、内核线程、workqueue或者其他内核活动,那么这个CPU实际上仍然不是一个完全独立的实时执行环境。
这就涉及CPU核心隔离。
CPU Affinity主要解决的是:
这个任务在哪个CPU上运行。
而CPU Core Isolation进一步关注的是:
这个CPU核心上还运行了哪些其他事情。
所以实时系统中的核心隔离,并不是简单地把一个任务绑定到某个CPU,而是需要从整个系统角度规划CPU资源,把普通任务、IRQ以及其他非实时活动尽可能安排到非实时CPU上,为关键实时任务创造更加可控的执行环境。
可以用一句话概括两者的关系:
PREEMPT_RT解决的是实时任务能不能及时运行,核心隔离解决的是实时任务运行时会不会被其他任务干扰。
这两者并不是互相替代,而是实时Linux系统中不同层面的技术手段。
从“机器人会不会动”到“机器人能不能稳定工作”,底层实时性越来越重要
这次外滩大会让我觉得最值得关注的,并不是某一个机器人又完成了一个多么复杂的动作,而是机器人正在逐渐离开“演示场景”。
当机器人进入药房、工厂、物流仓库和医院之后,评价它的标准就会发生变化。
实验室里的机器人可以在理想条件下完成一次成功抓取。
但真实工作环境不会一直这么理想。
货架之间可能只有80厘米的通道;物品摆放可能并不完全规则;传感器数据可能受到环境影响;机器人需要同时处理多个任务;AI模型需要不断根据新的观察调整动作。
此时,机器人真正需要解决的是一个连续的实时闭环。
它需要在有限的时间内完成感知、推理、规划和控制,并且在环境发生变化时不断修正自己的动作。
这意味着具身智能未来的竞争,可能逐渐形成一条越来越完整的技术链:
AI模型
↓
环境理解
↓
动作预测与规划
↓
实时控制
↓
实时操作系统
↓
芯片与驱动
↓
机器人本体
其中任何一层出现明显问题,都可能影响最终的机器人行为。
AI模型可以负责“想明白下一步应该做什么”,但最终真正把这个动作变成现实世界中的运动,还需要依赖底层控制系统。
这也是为什么,随着机器人越来越智能,操作系统和实时控制反而可能成为更加重要的底座。
实时Linux可能成为AI进入物理世界之后的一块关键基础设施
过去我们谈操作系统,更多时候关注的是兼容性、稳定性、性能和生态。
但当AI真正进入物理世界以后,操作系统还需要面对一个更加严格的问题:
时间确定性。
对于服务器上的AI应用来说,一次推理晚几十毫秒,可能只是吞吐或者用户体验发生变化。
但对于机械臂、机器人、工业控制设备而言,同样的延迟可能直接对应一次动作偏差。
因此,未来机器人操作系统需要解决的问题,很可能不是简单地“让Linux跑AI”,而是如何让AI计算、视觉处理、运动规划和实时控制在同一套系统中合理共存。
这也是实时Linux值得持续关注的地方。
通过PREEMPT_RT等实时内核技术,可以改善Linux内核的实时响应能力;通过实时调度,可以根据不同任务的时间约束合理分配CPU;通过CPU核心隔离和IRQ管理,可以进一步降低非实时任务对关键实时任务的干扰;再结合驱动、硬件和应用层面的优化,最终构建一个更加可预测的实时运行环境。
对于机器人而言,这种底层能力最终并不会直接出现在产品宣传页面上。
用户看到的是机械臂更加平稳的运动、更稳定的抓取、更及时的反馈以及更可靠的连续工作。
但这些表现的背后,很可能就是操作系统、调度、中断、驱动和硬件共同作用的结果。
望获OS关注的,正是AI之下的实时控制底座
具身智能的发展正在让机器人软件栈变得越来越复杂。
上层需要AI模型理解世界,中间需要动作规划和控制框架,底层则需要操作系统、驱动和芯片提供稳定的运行环境。
当AI与实时控制开始逐渐进入同一个计算平台,底层操作系统需要解决的就不再只是“能不能运行”,而是如何在复杂负载下保证关键任务的实时性。
这也是望获OS持续关注实时Linux技术路线的重要原因。
望获OS定位于全栈国产嵌入式硬实时操作系统研发与技术服务,面向工业控制、机器人、边缘计算、实时仿真等对确定性和实时性有较高要求的场景,关注的不只是单个应用程序的运行效率,更包括实时调度、CPU资源管理、中断管理以及系统级实时资源隔离等问题。
对于正在快速发展的具身智能产业来说,这些能力的重要性可能还会不断提高。
因为机器人越聪明,系统中需要同时运行的任务就越多;机器人进入的场景越复杂,对实时控制稳定性的要求也就越高。
AI解决的是“机器人能不能理解和决策”,实时操作系统解决的则是“这些决策能不能在正确的时间稳定地变成动作”。
写在最后
从外滩大会这次展示出来的趋势来看,具身智能正在经历一个非常明显的变化:机器人开始从“展示能力”走向“承担工作”,行业竞争也开始从单纯比较机器人本体性能,逐渐转向比较模型、软件、控制和硬件协同的综合能力。
“一脑多机”意味着机器人软件正在尝试摆脱对单一本体的强绑定;“边预测、边行动、边调整”的动作模型,则意味着AI正在更加深入地参与机器人的闭环控制。
而当AI真正进入物理世界以后,一个问题就无法绕开:
聪明的大脑,如何在正确的时间指挥身体完成正确的动作?
这时候,实时控制就不再只是机器人系统里一个底层的技术细节,而可能成为具身智能规模化落地的重要基础能力。
未来机器人之间的竞争,可能不再只是“谁的身体更强”,也不只是“谁的大模型更聪明”。
真正决定机器人能否从Demo走向规模化应用的,很可能是:
AI模型 + 实时控制 + 操作系统 + 芯片 + 机器人本体,能不能真正形成一个稳定可靠的整体。
而这,也许才是“从拼身体到拼大脑”之后,机器人产业下一阶段真正值得关注的技术底座。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
所有评论(0)