工信部重磅部署“人工智能+软件”：AI开始进入操作系统内部，实时Linux将迎来什么变化？

2026年9月11日，一项与软件产业未来发展方向密切相关的政策正式进入公众视野。

工业和信息化部近日印发《“人工智能+软件”专项行动实施方案》（工信部信发〔2026〕209号），并于9月11日举行新闻发布会，对专项行动有关情况进行解读。此次《实施方案》并不是简单提出“软件+AI”的应用要求，而是进一步把操作系统、数据库、工业软件、智能体、软件安全以及软硬协同等基础能力纳入人工智能与软件融合发展的整体布局。

其中，一个非常值得关注的变化是：操作系统首次被明确放在人工智能软件智能化升级的重要位置。

《实施方案》提出，面向操作系统、数据库等基础软件，支持有条件的企业围绕模型原生、智能体调度、性能调优、运维管理和安全防护等环节实施智能化升级；同时支持基础软件企业与芯片、服务器等硬件厂商开展底层适配与软硬协同优化联合攻关，并提出建设15家以上适配中心。

这意味着一个非常重要的技术趋势正在逐渐清晰：

过去，人工智能主要是运行在操作系统之上的应用；未来，人工智能可能开始进入操作系统本身。

而这件事情对于实时 Linux、工业控制、机器人、边缘计算等领域的意义尤其值得关注。

因为对于普通消费软件来说，AI带来的变化可能主要体现在“软件更聪明”。

但对于操作系统来说，真正的问题却变成了：

当AI开始参与任务调度、资源管理、性能优化甚至系统运维之后，操作系统还能不能保持实时性、确定性和安全性？

这可能是未来国产基础软件需要回答的一道关键问题。

一、从“AI辅助”到“AI原生”：软件正在发生一次底层架构变化

这次政策中，一个非常值得关注的概念是：

AI辅助与AI原生。

9月11日工信部新闻发布会上，工信部信息技术发展司副司长王威伟在回答有关问题时表示，以工业软件为例，人工智能与工业软件的融合正在沿两条路径展开：一是“AI辅助”，即在既有软件架构基础上叠加智能功能；二是“AI原生”，即由模型承担软件核心能力，能力边界不断延伸，从而重塑软件的研发与运行逻辑。

这两种模式看起来只是程度上的区别，实际上背后代表的是两种完全不同的软件发展思路。

所谓“AI辅助”，比较容易理解。

例如传统CAD软件增加一个AI助手：

用户输入：

“帮我优化这个零件结构。”

AI给出建议。

传统开发工具加入代码生成：

“帮我生成一个设备通信模块。”

AI自动生成代码。

传统工业软件增加智能分析：

“分析这组生产数据，找出异常原因。”

这些都属于典型的AI辅助。

原来的软件架构没有发生根本变化，AI更多是一个外挂式能力。

而AI原生则完全不同。

如果模型开始承担软件的核心能力，那么软件的运行逻辑就可能从过去的：

用户
↓
应用程序
↓
固定逻辑
↓
执行结果

逐渐变成：

用户 / 环境
↓
AI模型
↓
理解 / 推理 / 规划
↓
智能体
↓
调用软件能力
↓
执行任务
↓
根据结果继续决策

软件不再只是“等待用户操作”。

它开始：

理解、判断、规划、执行和反馈。

这就是为什么工信部此次把“智能体软件”作为一个重要方向。

《实施方案》提出，到2028年，要在重点行业打造100个智能体软件标杆应用；到2030年，智能编程、智能体软件以及智能服务等新业态成为软件产业新的增长极。

更值得注意的是，官方对“AI原生”的定位并不只是一次产品升级，而是把它看作重塑软件竞争格局的一种新技术手段。

换句话说：

AI可能不只是帮助软件做得更好，而可能重新定义软件应该怎么做。

这时候，一个新的问题就出现了：

如果AI开始进入软件底层，那么操作系统会不会成为下一阶段AI原生软件竞争的重要入口？

答案很可能是肯定的。

二、为什么操作系统会成为“AI+软件”的关键底座？

很多人理解AI软件时，容易把注意力集中在模型上。

比如：

• 模型参数规模；

• 推理速度；

• 上下文长度；

• Agent能力；

• 多模态能力。

但模型真正运行起来，最终还是需要依赖操作系统。

从最底层看，一套复杂AI系统至少需要解决：

AI模型
↓
推理框架
↓
运行时
↓
内存管理
↓
CPU/GPU/NPU调度
↓
设备驱动
↓
操作系统
↓
芯片

因此，当AI模型越来越复杂之后，操作系统实际上承担了越来越重要的角色。

尤其是在边缘计算、机器人、工业控制等场景中，AI不可能永远运行在云端。

很多任务必须在设备本地完成。

例如工业机器人发现异常。

如果每一次判断都需要：

传感器
↓
机器人
↓
网络
↓
云端AI
↓
返回结果
↓
机器人执行

那么网络延迟、网络抖动甚至网络中断都会成为问题。

因此越来越多AI能力会下沉到边缘设备。

于是设备本地可能同时运行：

• AI模型；

• 视觉算法；

• 传感器采集；

• 实时控制；

• 网络通信；

• 数据处理；

• 安全任务。

这时候，操作系统就不再只是负责“让软件运行”。

它需要开始解决：

AI任务应该什么时候运行？

AI任务可以占用多少CPU？

AI推理是否可以影响实时控制？

不同智能体之间如何分配资源？

AI出现异常时，关键控制任务能否继续运行？

AI生成的代码或者策略出现问题后，系统能否进行限制和追溯？

这恰恰对应了此次《实施方案》中直接点出的几个关键词：

智能体调度、性能调优、运维管理、安全防护。

因此，从技术角度看，“AI+操作系统”并不是简单地在Linux桌面上装一个AI助手。

真正值得关注的是：

AI开始参与操作系统层面的资源调度和系统管理。

而这对于实时操作系统来说，挑战会更加明显。

三、AI进入操作系统之后，实时Linux面临的真正挑战是什么？

如果只是普通办公电脑，那么AI占用CPU多一点、少一点，通常不会造成严重后果。

但是工业控制、机器人、能源、电力、航空航天等系统不一样。

这些系统往往存在明确的实时任务。

例如一个工业控制系统可能需要：

传感器采集
↓
控制算法
↓
输出控制
↓
执行机构

整个闭环必须在固定时间内完成。

假设一个控制周期是1ms。

系统真正关心的不是：

平均执行时间是多少？

而是：

最坏情况下会不会超过1ms？

这就是实时系统和普通计算系统的重要区别。

普通系统追求：

平均性能。

实时系统更加关注：

确定性。

因此，当AI开始进入操作系统以后，就产生了一个非常现实的矛盾。

AI任务通常具有：

• 计算量大；

• 执行时间不确定；

• 数据量变化大；

• 模型复杂；

• 资源需求动态变化。

而实时控制任务则要求：

• 响应时间稳定；

• 优先级明确；

• 调度可预测；

• 延迟可控；

• 关键任务不能被随意干扰。

两者放到同一个系统里面，天然存在资源竞争。

例如：

CPU
│
┌───────┴────────┐
│ │
AI推理 实时控制
│ │
大量计算资源 周期性执行
│ │
└───────┬────────┘
↓
资源竞争

如果AI推理突然进入高负载状态，会不会影响实时控制？

如果智能体不断创建任务，会不会影响关键线程？

如果AI服务大量访问内存，会不会增加实时任务延迟？

如果AI相关网络任务产生大量中断，会不会影响实时核心？

这些问题最终都指向操作系统的一个核心能力：

资源隔离。

这也是为什么对于实时Linux而言，未来的竞争可能不会仅仅是“谁的实时补丁更强”，而是：

谁能够在AI、通用计算与实时任务共存的情况下，仍然保持关键任务的确定性。

这也是望获 OS 所重点关注的技术方向之一。

四、从“核心隔离”看AI与实时任务如何共存

在复杂嵌入式系统中，一个非常重要的设计思路就是：

核心隔离。

简单来说，就是不要让所有任务都去争抢同一组CPU资源。

可以将多核CPU划分成不同的执行区域：

多核CPU
│
┌────────────┴────────────┐
│ │
通用计算域 实时控制域
│ │
AI / Agent 控制任务
视觉算法 传感采集
网络服务 电机控制
数据处理 安全任务
│ │
↓ ↓
Linux通用环境 实时执行环境

这样设计的核心目的并不是让CPU“跑得更快”。

而是：

减少不同类型任务之间的相互干扰。

例如：

AI任务可以集中运行在通用计算核心。

实时控制任务运行在经过隔离的实时核心。

网络中断、普通系统服务等非关键活动尽量不要进入实时核心。

这样即使AI模型突然进入高负载状态，也不会轻易影响实时控制任务。

这就是核心隔离真正有价值的地方。

当然，真正的隔离并不是简单地执行一个CPU affinity命令。

因为影响实时性的因素还有很多：

• IRQ中断；

• 内核线程；

• 定时器；

• RCU活动；

• 驱动；

• I/O；

• 网络；

• 内存竞争；

• 调度器活动。

因此完整的实时隔离需要从多个层面考虑。

可以简单理解为：

核心隔离
│
├── CPU任务隔离
├── 中断隔离
├── 内核活动隔离
├── 驱动影响控制
├── 调度策略
└── 资源访问控制
↓
稳定实时执行域

这也是为什么“实时Linux”真正难的地方，并不是简单地给Linux加一个实时补丁。

而是要解决：

如何让一个复杂的软件生态，在拥有AI、网络、图形、数据处理等大量任务的同时，依然保证关键任务的实时确定性。

从这个角度来看，工信部此次把“性能调优”和“智能体调度”直接纳入操作系统智能化升级任务，实际上释放出了一个非常重要的信号：

未来的操作系统调度，很可能会越来越智能，但智能调度不能牺牲实时确定性。

这会成为实时操作系统新的技术挑战。

五、AI越深入基础软件，安全问题也越不能被忽视

此次《“人工智能+软件”专项行动实施方案》还有一个非常重要的关键词：

安全。

《实施方案》提出，要提升软件领域安全保障能力，在开发环节突出“以智促安、防治结合”，在产品环节突出“行为可控、全程可溯”。同时提出利用大模型和智能编程工具开展漏洞挖掘、缺陷自动识别、风险评估以及智能安全检测等工作。

这实际上说明，AI进入软件产业以后，安全已经不能再作为软件生命周期最后一个环节来考虑。

尤其当AI开始进入操作系统和基础软件之后，安全边界会发生变化。

传统软件可能是：

应用
↓
操作系统
↓
硬件

AI原生软件可能变成：

模型
↓
智能体
↓
软件
↓
操作系统
↓
硬件

智能体具有：

感知、记忆、决策、交互、执行等能力。

这意味着它可能不再只是“读取信息”。

它可能直接调用：

• 文件；

• 网络；

• 系统服务；

• 外设；

• 数据库；

• 工业控制接口。

因此，一个AI智能体如果拥有过高权限，就可能从“软件助手”变成一个真正能够影响系统运行状态的执行主体。

这时候，操作系统需要解决的问题就变成：

AI可以做什么？

AI不能做什么？

AI可以访问哪些资源？

AI出现异常之后如何限制？

AI的操作能不能被记录和追溯？

这也是“安全防护”“行为可控”“全程可溯”这些政策关键词背后的技术逻辑。

对于机器人、工业控制等实时系统来说，这一点尤其重要。

例如，一个AI系统可以负责识别环境、规划路径，但如果它能够直接修改底层安全控制逻辑，就会带来完全不同的安全风险。

因此未来更加合理的架构可能是：

AI / Agent
│
决策与规划
│
权限控制
│
安全隔离边界
│
实时控制域
│
硬件设备

也就是说：

让AI拥有智能，但不要让AI天然拥有无限权限。

而操作系统恰恰是实现这种边界控制的重要基础。

六、从“AI+工业软件”到“AI+实时操作系统”，工业软件正在进入新的融合阶段

此次政策并没有只关注操作系统。

工业软件同样被放到了非常重要的位置。

《实施方案》明确提出，要推动CAD、CAE、EDA等通用工业软件与人工智能深度融合，面向制图、设计、仿真等场景实施智能化升级；同时支持工业企业与软件企业合作，将工业经验、工艺参数等知识封装为可复用的模型库和工业组件，并推进工业互联网平台集成大模型能力，提高数据分析、生产调度和多智能体协同决策水平。

这实际上对应了工业数字化正在发生的一次变化。

过去工业软件更多是：

把人的经验固化成软件。

未来AI工业软件则可能变成：

让软件理解人的经验，并根据环境动态执行。

例如：

传统CAE：

工程师建模
↓
设置参数
↓
运行仿真
↓
人工分析结果

AI增强后的CAE：

工程师提出目标
↓
AI理解需求
↓
自动建立模型
↓
自动选择参数
↓
运行仿真
↓
分析结果
↓
提出优化方案

软件从“工具”逐渐变成“智能伙伴”。

但一旦进入真实工业现场，事情又会复杂起来。

因为仿真软件可以允许AI不断试错。

但是生产设备不能。

AI可以在虚拟环境中尝试10000次。

但真正的工业控制设备，每一次输出都可能影响真实设备。

因此工业软件智能化和工业控制智能化之间，还隔着一个非常重要的基础设施：

实时、安全、可靠的操作系统。

七、这也是望获OS为什么要关注“AI时代的实时操作系统”

人工智能正在改变上层应用，但越是复杂的AI系统，越需要一个稳定的底层运行环境。

对于工业控制、机器人、边缘计算等场景而言，真正需要解决的问题不是：

“能不能运行AI？”

而是：

“AI运行起来以后，会不会影响原本必须稳定运行的任务？”

这正是望获 OS 所关注的技术方向。

望获 OS 定位于全栈国产嵌入式硬实时操作系统研发与技术服务，产品覆盖实时Linux等方向，重点关注硬实时、高安全、高可靠以及国产芯片和工业生态适配。

其中，一个非常重要的技术思路就是：

核心隔离。

简单来说，就是通过系统架构和资源管理，将不同实时等级、不同安全等级、不同计算需求的任务进行合理隔离。

例如：

┌──────────────────────────────────────┐
│ AI / 应用层 │
│ 大模型 · Agent · 视觉 · 数据分析 │
└──────────────────────────────────────┘
│
通用计算资源
│
══════════════ 隔离边界 ══════════════
│
┌──────────────────────────────────────┐
│ 实时控制域 │
│ 电机 · 传感器 · 控制算法 · 安全任务 │
└──────────────────────────────────────┘
│
┌──────────────────────────────────────┐
│ 实时内核 │
│ 调度 · 中断 · 内存 · 驱动 · 隔离 │
└──────────────────────────────────────┘
│
┌──────────────────────────────────────┐
│ 国产芯片 │
└──────────────────────────────────────┘

这种思路对于未来的智能机器人、工业控制、智能制造、能源电力、实时仿真等场景都具有现实意义。

因为未来的设备很可能同时拥有：

AI + 网络 + 实时控制 + 多传感器 + 边缘计算。

它们需要的不是一个“只能跑实时任务”的封闭系统，而是：

一个能够让AI、通用计算和硬实时任务共存，同时保持关键任务确定性的操作系统。

这可能就是未来实时Linux真正需要解决的问题。

八、从“软件智能化”走向“基础软件智能化”，国产操作系统迎来新的窗口期

这次《“人工智能+软件”专项行动实施方案》提出的目标并不小。

到2028年，要推广应用覆盖2万家规模以上软件企业，累计组织实施100项软件企业智能化技改项目，在重点行业打造100个智能体软件标杆应用，建设15家以上适配中心，并孵化5个以上优质开源项目；到2030年，关键软件全面实现智能化升级，智能编程、智能体软件和智能服务等新业态成为产业新的增长极。

这说明“AI+软件”已经不再只是企业自发探索，而正在进入一个更加系统化的发展阶段。

尤其值得关注的是：

操作系统被直接纳入这一轮软件智能化升级。

这意味着未来的操作系统可能出现一系列新的变化：

第一，操作系统本身会更加智能。

过去操作系统主要负责：

调度、内存、文件、网络、驱动。

未来可能进一步通过AI参与：

性能调优、资源调度、异常分析、运维管理。

第二，操作系统会更加适应AI硬件。

CPU、GPU、NPU以及各种专用加速器之间需要更加紧密的软硬件协同。

第三，操作系统会更加关注智能体。

当Agent从应用层逐渐向系统层渗透之后，操作系统需要提供更加明确的权限、资源和安全边界。

第四，操作系统会更加重视安全。

AI本身可以帮助发现漏洞，也可能成为新的攻击面，因此安全机制必须深入到开发、部署、运行和运维全生命周期。

第五，对于工业和嵌入式领域而言：

实时性仍然不会消失。

相反，AI越复杂，实时性的重要性可能越高。

因为AI解决的是：

“系统应该做什么。”

而实时操作系统需要解决的是：

“系统必须在什么时候完成。”

结语：AI正在进入操作系统，而实时性决定了AI能走多远

如果把这次工信部发布的《“人工智能+软件”专项行动实施方案》简单理解成一次“软件行业AI升级”，可能会低估这份政策释放出的技术信号。

真正值得关注的是：

AI正在从应用层向软件底座逐渐深入。

从智能编程，到智能体；

从工业软件，到操作系统；

从模型调用，到智能调度；

从软件功能，到运行时性能优化；

从AI能力，到安全防护。

软件正在经历一次从“工具”向“智能系统”的变化。

而当这种变化进一步进入机器人、工业控制、智能制造、能源电力、航空航天等实体场景之后，一个问题会变得越来越重要：

AI可以不确定，但关键控制系统不能不确定。

AI可以不断学习。

模型可以不断升级。

智能体可以不断增加新的能力。

但是对于一个正在运行的工业设备、一台机器人或者一套关键控制系统而言，安全任务、实时任务和核心控制任务必须始终保持可预测、可控制。

因此，AI时代的操作系统可能需要同时具备两种看似矛盾的能力：

一方面足够智能。

能够理解AI模型、支持智能体、进行性能优化和智能运维。

另一方面足够确定。

能够保证关键任务的实时性、安全边界和系统可靠性。

这也是实时Linux未来值得关注的方向。

从“AI辅助软件”到“AI原生软件”，再到“AI原生基础软件”，操作系统正在成为人工智能产业下一阶段竞争的重要底座。

对于望获 OS 而言，围绕硬实时、核心隔离、高安全、高可靠以及国产芯片与工业生态适配持续构建底层能力，本质上也是在回答同一个问题：

当越来越多AI进入真实世界，谁来保证这些智能能力能够稳定、实时、安全地运行？

答案不会只存在于模型本身。

更底层的答案，仍然在操作系统。

而这可能正是“人工智能+软件”之后，国产实时操作系统迎来的又一个重要技术窗口。