如果说前几年人形机器人最容易让人记住的是“能跑、能跳、能翻跟头”，那么到了2026年，机器人行业正在开始进入一个完全不同的阶段。

9月9日至13日，2026年中国国际服务贸易交易会在北京首钢园举行。本届服贸会吸引了1800余家企业现场设展，人工智能、机器人等新技术成为展会中的重要看点。与过去单纯展示机器人运动能力不同，今年现场出现了越来越多与真实服务场景结合的应用：机器人开始进入零售、邮政等实际工作流程，曾经在运动场上展示高难度动作的机器人，也开始在展馆里承担售货、取件、盖章、递送等任务。

例如，Galbot G1在现场已经不再只是进行动作展示，而是进入类似售货员的服务场景，为观众递送零食和饮料；另一款轮式双臂机器人则可以完成明信片取件、盖章和投递等连续操作。

天工Ultra、天工Omni等机器人也在本届服贸会上亮相。过去，它们更多因为运动能力、竞赛成绩等被公众认识，而现在机器人正在越来越多地进入“工作”这个语境。

这背后其实意味着一个非常重要的产业变化：

机器人真正的竞争，正在从“能不能完成一次精彩动作”，转向“能不能把一项工作稳定地做一整天”。

而这恰恰是一个非常典型的操作系统和实时控制问题。

---

机器人从“会做动作”到“持续工作”，难度完全不一样

一台机器人完成一次抓取动作，并不意味着它已经具备了真正的服务能力。

如果是在实验室或者展台环境中，机器人可以提前知道目标在哪里，环境也相对可控。即使偶尔出现一次动作失败，也可以重新启动程序，再进行一次演示。

但如果机器人真的成为商场里的售货员、物流仓库里的搬运工，或者养老场景中的服务设备，系统面对的就不再是“一次动作成功率”这么简单的问题。

它需要连续工作几个小时甚至更长时间，需要不断处理传感器数据、视觉信息、用户指令、运动控制和环境变化。

某一个传感器出现异常怎么办？

某一个控制任务突然超时怎么办？

AI推理进程出现异常怎么办？

机器人运动过程中某个任务发生故障怎么办？

系统重启之后，能不能快速恢复到正常状态？

这些问题可能比机器人能不能完成一个漂亮的后空翻更加重要。

因为对于真正的服务机器人来说，用户并不关心它能不能做出多么炫酷的动作。

用户更关心的是：

我叫它拿一瓶水，它能不能稳定地拿到；我让它连续工作8个小时，它会不会中途突然失控；出现异常之后，它能不能快速恢复。

这也是机器人产业从“演示阶段”走向“常态化上岗”之后，必须面对的工程问题。

---

真正的机器人智能，不只是“大脑聪明”，还要让大小脑配合起来

现在讨论具身智能，经常会提到“具身大脑”。

大模型、视觉语言模型、VLA模型等技术，让机器人拥有了越来越强的环境理解和任务规划能力。

过去机器人可能需要人为编写大量固定规则：

检测目标
↓
移动到目标位置
↓
机械臂下降
↓
夹取
↓
移动
↓
放下

现在，AI可以参与更复杂的环境理解和任务决策。

机器人可以根据摄像头看到的场景判断目标物体，可以理解自然语言指令，也可以根据环境变化调整动作策略。

这意味着机器人正在从“程序驱动”逐渐走向“模型驱动”。

但问题也随之出现了。

AI模型擅长的是理解和决策，而机器人最终完成动作，依然需要依靠底层实时控制系统。

可以把整个机器人系统简单理解成“大脑”和“身体”之间的协作：

        AI大脑
          ↓
    环境理解 / 任务决策
          ↓
      动作规划
          ↓
    实时控制系统
          ↓
    驱动器 / 伺服
          ↓
      电机 / 关节
          ↓
      机器人身体

AI可以告诉机器人“我要把这个杯子拿起来”。

但是，真正执行的时候，需要控制机械臂以什么速度运动、关节移动多少角度、受到外力之后如何调整，以及什么时候停止。

尤其在精细操作中，机器人面对的并不是一个静态世界。

手碰到物体之后，力传感器会产生新的数据；物体发生轻微位移之后，视觉系统会得到新的信息；机械结构产生误差之后，控制器需要进一步修正。

这实际上形成了一个不断循环的实时闭环：

感知 → 计算 → 控制 → 执行 → 反馈 → 再控制。

而这个闭环能否稳定运行，很大程度上取决于底层实时系统。

---

为什么机器人越来越聪明之后，反而更加需要实时Linux？

这里有一个非常容易被忽视的问题。

很多人会认为，只要机器人的CPU、GPU或者NPU足够强，AI模型运行得足够快，机器人自然就能够做到实时控制。

实际上并不是这样。

假设AI模型平均100次推理中有99次只需要10毫秒，但偶尔一次需要200毫秒。

对于很多互联网应用而言，这可能只是一次明显的卡顿。

但如果机器人正在进行实时控制，那么这一次200毫秒的延迟就可能直接影响动作执行。

因为机器人不是简单地“算出一个结果就结束”，而是需要不断按照固定时间节拍运行。

例如一个控制周期可以理解为：

|----1ms----|----1ms----|----1ms----|----1ms----|
     ↑           ↑           ↑           ↑
   控制1       控制2       控制3       控制4

如果某一次控制任务没有在规定时间内完成，那么下一次控制周期就可能受到影响。

因此，机器人控制系统关注的并不仅仅是平均延迟，而是延迟是否可预测，以及最坏情况下的响应时间到底是多少。

这也是实时Linux与普通Linux之间一个非常重要的区别。

普通Linux追求的是通用性、吞吐量和整体性能；实时Linux则需要进一步考虑任务的响应时间和时间确定性。

当AI推理、视觉计算、通信、日志、设备驱动和实时控制全部运行在同一台机器人控制器上时，这个问题会变得更加明显。

---

力控为什么会成为机器人进入真实场景之后的关键能力？

机器人进入真实服务场景后，还有一个问题会越来越重要，那就是力控制。

如果机器人只是走路或者进行比较粗粒度的移动，位置控制可能已经可以满足很多需求。

但当机器人开始拿东西、推东西、插东西、抓取柔性物体，甚至与人发生接触时，仅仅知道“手在哪里”是不够的。

机器人还需要知道：

手现在受到多大的力。

例如机械臂抓取一个杯子。

如果抓得太松，杯子可能掉下来；如果抓得太紧，又可能把杯子夹碎。

因此，机器人需要不断读取力传感器的数据，根据当前的受力情况调整电机输出。

这就形成了典型的力控闭环：

目标力
  ↓
控制器
  ↓
执行机构
  ↓
机器人与物体接触
  ↓
力传感器
  ↓
反馈
  ↓
控制器修正输出

这个闭环对时间的要求非常高。

因为从传感器采集数据，到控制器处理数据，再到执行机构产生新的动作，中间每增加一段不可预测的延迟，都可能影响最终控制效果。

近年来机器人领域也开始出现越来越多围绕接触丰富操作、力觉反馈和高精度控制的研究，这说明具身智能正在从“看懂环境、完成动作”进一步走向“理解接触、控制接触”。例如近期的机器人操作研究已经开始将视觉语义信息与腕部力矩历史结合，用于更加精细的接触操作。

所以，随着机器人越来越多地承担真实工作，实时控制的价值也会越来越明显。

---

真正困难的不是“出故障”，而是“出故障之后怎么办”

机器人进入真实场景之后，还有一个经常被低估的问题：

系统一定会出故障。

任何复杂的软件系统都不可能保证永远不出问题。

真正成熟的机器人系统，不应该把目标设定成“永不发生故障”，而应该考虑：

发生故障以后，系统能不能快速发现、快速定位、快速恢复。

比如一个非关键的后台任务出现异常，可以直接重启这个任务。

一个AI推理进程崩溃，可以尝试重新拉起。

某个通信服务发生异常，可以重新建立连接。

但如果实时控制线程发生异常，就不能简单地让整个机器人进入不可控状态。

这意味着未来机器人操作系统需要具备更加清晰的任务分层和资源隔离能力。

可以把机器人系统划分成不同的任务区域：

┌─────────────────────────────┐
│ AI推理 / 视觉 / 大模型       │
├─────────────────────────────┤
│ 网络 / 日志 / 普通系统服务    │
├─────────────────────────────┤
│ 实时控制 / 伺服 / 力控        │
└─────────────────────────────┘

不同任务拥有不同的实时等级。

当普通任务出现问题时，不能轻易影响核心控制任务。

这时候，操作系统层面的进程隔离、CPU资源隔离、实时调度、中断管理等能力就变得非常重要。

机器人系统真正需要的，不只是“高性能”，而是“故障可控”。

---

CPU核心隔离：给实时控制留出一块“安静的CPU”

这也是实时Linux非常重要的一项技术。

假设机器人控制器采用多核CPU：

CPU 0     AI / Vision
CPU 1     AI / Vision
CPU 2     Network / System
CPU 3     RT Control

最理想的情况，是让CPU 3主要承担实时控制任务。

但问题是，仅仅把实时控制任务绑定到CPU 3还不够。

因为CPU 3上可能仍然存在各种系统活动，例如中断、内核线程、定时器、workqueue等。

这些活动都可能在某个时间点占用CPU资源，从而给实时任务带来额外延迟。

因此，真正的CPU核心隔离并不是简单的“把任务绑到某个CPU”。

它需要从整个系统角度考虑：

哪些任务应该运行在实时CPU？哪些任务应该搬走？哪些IRQ应该迁移？哪些内核活动需要控制？

这也是为什么在实时Linux系统中，PREEMPT_RT与CPU核心隔离往往需要配合使用。

PREEMPT_RT解决的是内核路径的可抢占性问题，让实时任务能够更加及时地获得CPU。

而CPU核心隔离解决的是资源竞争和系统干扰问题，让实时任务运行时尽量减少来自其他任务和系统活动的影响。

简单概括就是：

PREEMPT_RT解决“能不能及时运行”，核心隔离解决“运行的时候会不会被干扰”。

对于机器人这种同时运行AI、视觉、网络和实时控制任务的复杂系统来说，这种资源隔离尤其重要。

---

从服贸会看机器人产业的下一个拐点：不是“机器人能不能干活”，而是“能不能长期干活”

回到这次服贸会。

Galbot G1开始做售货员，机器人开始进入邮政服务流程，天工Ultra等机器人从竞技场走向真实展示和应用场景。

这些变化看起来只是“应用场景增加了”，但从技术发展角度看，它们其实意味着机器人行业正在进入一个新的阶段。

过去机器人需要证明：

“我能做到。”

现在机器人需要证明：

“我可以持续做到。”

这两个问题之间存在巨大的工程鸿沟。

一次成功动作，只需要解决算法问题。

连续工作几个小时，需要解决系统问题。

一个机器人能够完成任务，需要解决AI和控制问题。

一批机器人能够长期稳定部署，则需要解决操作系统、硬件、驱动、通信、故障恢复和运维问题。

因此，未来机器人产业的竞争，很可能会逐渐从单一的本体性能竞争，转向一套更加完整的软硬件系统能力竞争。

---

机器人真正进入社会之后，操作系统会成为隐藏在背后的关键底座

人形机器人最吸引普通人的地方，是它越来越像“人”。

它可以走路，可以抓东西，可以和人交流，也可以完成越来越复杂的任务。

但对于工程师来说，真正值得关注的其实是这些动作背后的系统。

当机器人进入商场、工厂、仓库、医院、养老机构之后，它面对的是一个持续运行、任务复杂、环境变化不断的真实系统。

AI需要算力。

视觉需要算力。

运动规划需要算力。

力控需要实时性。

通信需要稳定性。

而所有这些任务最终都需要落到一个具体的计算平台和操作系统上。

因此，未来机器人底座可能逐渐形成这样一套技术架构：

        具身智能大模型
              ↓
       感知 / 规划 / 决策
              ↓
         机器人控制框架
              ↓
 ┌───────────────────────┐
 │     实时操作系统       │
 │                       │
 │ 实时调度 / IRQ管理     │
 │ CPU核心隔离 / 资源管理 │
 │ 驱动 / 通信 / 故障恢复 │
 └───────────────────────┘
              ↓
       国产CPU / SoC
              ↓
       电机 / 伺服 / 传感器
              ↓
          机器人本体

这也是为什么，机器人产业越往真实应用走，实时操作系统的重要性反而可能越来越高。

---

望获OS：为机器人和工业控制提供实时系统底座

从机器人产业的发展趋势来看，AI正在解决“机器人如何理解和决策”的问题，而实时操作系统需要解决的是“这些决策如何稳定、及时地变成动作”。

对于机器人、工业控制、边缘计算等场景而言，真正需要关注的不只是CPU有多少核、AI模型有多大，而是整个系统能否在复杂负载下保持稳定、可预测的实时响应。

望获OS持续关注的正是这一层基础能力。

作为全栈国产嵌入式硬实时操作系统，望获OS围绕实时Linux、实时调度、CPU资源管理、核心隔离、中断管理以及国产芯片适配等方向进行技术研发，面向机器人、工业控制、边缘计算等对实时性、可靠性和自主可控有较高要求的应用场景。

尤其对于未来“AI+机器人”的混合计算架构而言，如何让AI任务与实时控制任务在同一计算平台上稳定共存，将会成为操作系统层面值得持续研究的问题。

AI负责让机器人更聪明，实时操作系统负责让机器人在正确的时间稳定地行动。

当机器人从展台走向工厂、商场、仓库和养老服务场景，真正决定它能否“常态化上岗”的，也许已经不再只是它能做出多么惊艳的动作，而是它能不能在复杂环境中连续、稳定、可预测地工作。

这或许正是机器人产业从“炫技”走向“上岗”之后，真正值得关注的下一道技术门槛。