openEuler把Agent底座塞进OS

openEuler今天正式发布面向 Agentic Infra 的操作系统，把智能体所需的沙箱、KV Cache、记忆系统、安全治理和可观测能力，从应用框架继续下沉到操作系统层。

这不是给 Linux 加一个聊天助手，而是一次更底层的重新分工：过去由 Agent 框架、推理引擎和业务团队分别实现的公共能力，现在开始由操作系统统一接管。

11月13日，在北京举行的 Agentic Infra 操作系统大会暨 openEuler Summit 2026 上，openEuler宣布完成面向智能体基础设施的系统升级，并披露相关能力已在互联网、金融等行业的头部用户中商用落地。开放原子开源基金会理事长谢少锋同时表示，openEuler系操作系统国内累计装机量预计突破 2200万套。(ithome.com)

Agentic Infra到底是什么

Agentic Infra 是支撑AI智能体构建、运行、连接、监控和治理的一整套基础设施。

传统大模型应用通常是一问一答：收到请求、完成推理、返回结果。Agent则不同，它可能连续规划十几个步骤，调用浏览器、数据库、Shell和企业内部系统，并根据中间结果反复修正执行路径。

这意味着一次用户请求背后，可能同时拉起10个甚至100个短生命周期任务。每个任务都要分配计算资源、加载运行环境、读取上下文、调用外部工具，并留下可审计的执行记录。

如果继续把这些能力全部堆在应用层，开发团队很快会遇到四类问题：

1. 启动慢：每个工具调用都要创建隔离环境，沙箱冷启动时间直接进入用户等待时间。
2. 上下文贵：多轮任务不断重复计算历史Token，KV Cache无法有效跨请求、跨节点复用。
3. 记忆散：短期上下文、长期记忆、文件状态和任务状态分布在不同组件中，难以统一管理。
4. 权限失控：Agent可以调用真实工具，但应用层通常只能看到模型输出，很难完整掌握进程、文件和网络行为。

openEuler的判断是，这些问题已经不只是Agent框架的问题，而是新的操作系统负载问题。

过去操作系统管理的是进程、线程、内存、文件和设备；进入Agent时代后，它还需要理解Session、Tool Call、上下文、KV Cache和智能体身份。换句话说，Agent正在成为一种新的系统级工作负载。

四项能力被下沉到系统层

openEuler Agentic Infra操作系统的核心变化，是把沙箱、缓存、记忆和安全能力做成公共系统服务。

| 能力 | 传统实现位置 | openEuler的系统层方案 | 主要解决的问题 | |---|---|---|---| | Agent沙箱 | Agent框架、容器平台 | 镜像快照、远端懒加载、分层按需加载 | 冷启动慢、并发密度低 | | KV Cache | 单个推理引擎或服务实例 | 语义感知调度、多级缓存、DDR与HBM协同 | TTFT抖动、重复计算、显存不足 | | 智能体记忆 | 向量数据库或应用插件 | 上下文换页、长期记忆与KV Cache协同 | Token膨胀、跨会话状态割裂 | | Agent安全 | 应用层规则、工具白名单 | 动态沙箱、系统旁路观测、行为审计与回滚 | 提示注入、越权调用、过程不可追踪 |

这套思路最值得关注的地方，不是openEuler又做了一批AI组件，而是它试图确定Agent时代的系统调用边界。

在openEuler提出的架构中，底层是 Agent Kernel，负责在内核和超节点范围内完成原生调度与安全控制；中间层是 Agent Service，把安全、记忆和沙箱等能力抽象成类似“Agent POSIX”的公共原语；上层才是具体的Agent应用。

POSIX解决了应用如何一致地使用文件、进程和网络的问题，而所谓Agent POSIX想解决的是：不同Agent如何用相对一致的方式申请沙箱、读取记忆、复用缓存、调用工具和接受审计。

这个目标很大，也仍处在早期阶段，但方向是合理的。Agent生态当前最大的浪费之一，就是每个框架都在重复实现沙箱、记忆、权限和可观测系统，而且实现质量差异很大。

沙箱不再只是“套一个容器”

Agent沙箱是为智能体执行代码和操作工具提供隔离、限制与恢复能力的运行环境。

Agent执行环境的特点是数量多、生命周期短，而且启动频繁。一个传统业务容器运行数天甚至数月，几十秒部署时间可以接受；一个工具调用可能只执行3秒，如果沙箱本身需要2秒才能启动，基础设施开销就会吞掉大部分响应时间。

openEuler给出的优化路径包括镜像快照、远端懒加载和分层按需加载。其核心逻辑是：沙箱启动时不再完整拉取和加载整个镜像，而是先恢复最小可执行状态，真正用到某个文件或数据页时再读取。

在超节点环境中，openEuler还希望让多个沙箱共享镜像快照，避免每个计算节点重复拉取相同环境。这相当于把过去“每个工位都准备一整套工具箱”，改成“公共工具库加按需取用”。

安全模型也不再只依赖单层容器边界。openEuler此前披露的方案采用三级动态沙箱：

• Conch沙箱负责智能体整体运行环境；
• Session沙箱隔离一次会话或任务；
• Tool沙箱限制单次工具调用的权限和资源。

分层隔离的价值在于，企业可以针对不同风险粒度设置策略。读取公开网页和执行数据库写操作，不应该拥有同样的文件、网络和凭据权限。

openEuler还提出“事前检测、事中拦截、事后恢复”的三段式治理：事前识别Prompt注入并绑定可信身份，事中拦截高危操作并保留审计轨迹，事后通过文件快照进行毫秒级回滚。

这里真正困难的部分并不是拦截一条危险命令，而是把模型意图、工具调用和最终系统行为串成同一条证据链。一个Agent可能先读取邮件，再从附件中提取指令，最后调用Shell删除文件；只看其中任何一个步骤，都可能显得正常。

KV Cache开始由操作系统参与调度

KV Cache 是大模型保存已计算注意力键值状态的缓存，用来避免在后续生成中重复处理相同上下文。

对于普通聊天，KV Cache主要影响单次对话的生成效率；对于Agent，它会直接决定多步骤任务能否稳定运行。Agent经常反复访问相似上下文，还可能分叉出多个子任务，如果缓存只能留在某张加速卡的显存中，任务一旦迁移或被抢占，就要重新计算。

openEuler目前形成了几层不同的优化路径：

| 组件或机制 | 作用 | 对Agent负载的价值 | |---|---|---| | ram-a-kv | 根据Agent语义和任务关系预测缓存重用 | 在下一次推理前主动预取或淘汰KV块 | | MemFabric | 聚合传输KV Cache，协同使用DDR与HBM | 缓解高并发下显存容量不足 | | LMCache-Ascend | 构建面向昇腾的多级KV缓存池 | 支持KV Cache卸载、复用和分布式存储后端 | | KVC-Gateway | 在请求入口进行缓存感知调度 | 尽量把请求送到已有相关缓存的节点 |

传统缓存策略通常依赖LRU，也就是优先淘汰最久没有使用的数据。这种办法不理解Agent任务语义：某段缓存刚刚没有使用，不代表下一步不会立即需要。

ram-a-kv的思路是把Agent上下文映射到具体KV块，根据会话分叉、任务阶段和历史行为预测复用关系，再提前执行prefetch、evict或demotion。其开源仓库将自身定义为面向AI Agent的“推理感知记忆基础设施”，同时包含长期记忆与KV Cache协调组件。(github.com)

这相当于让缓存系统从仓库管理员升级成调度员：过去只记录哪些货物最近被拿过，现在还要预测下一道工序将使用什么材料，并提前搬到生产线旁边。

openEuler公布的一项广告业务实践显示，通过优化DDR内存与加速卡之间的数据传输并减少跨节点通信，KV Cache读写时延下降接近 84%。这个数字足够醒目，但目前公开信息没有给出模型规模、并发量、硬件拓扑和测试基线，因此它更适合作为场景案例，而不是跨平台通用结论。

记忆系统不是再接一个向量数据库

智能体记忆系统是保存、筛选和检索Agent历史状态、用户信息与任务经验的持久化机制。

目前很多Agent产品所谓的“长期记忆”，本质上是把对话切片后写入向量数据库，需要时做一次语义检索。这种方式能解决部分信息召回问题，却没有解决上下文成本、任务状态一致性和缓存协同问题。

openEuler的路线更接近操作系统中的虚拟内存：不是把所有历史内容永久塞在模型上下文里，而是保留引用，在需要时再把数据换入。

其SCCS上下文方案会对长任务中的数据本体进行压缩替换和按需取回。类比来看，模型上下文是昂贵的内存，外部存储是容量更大的磁盘；Agent不需要一直背着所有文件内容，只需要知道文件在哪里、何时应该重新加载。

RAM-A项目则把长期记忆与KV Cache协调放在同一仓库内，长期记忆部分支持语义检索、关键词检索和可选图记忆，KV部分负责根据Agent行为主动管理缓存。(github.com)

这意味着“记住什么”和“哪些内容已经完成推理计算”开始被放进同一个系统视角中。前者决定语义连续性，后者决定计算连续性，两者过去往往由完全不同的团队维护。

安全能力必须看到模型以下的行为

Agent安全治理是对智能体身份、输入、工具权限、执行过程和结果进行持续控制与审计的机制。

应用层护栏通常只能检查Prompt和模型输出，但真正危险的动作发生在模型以下：进程启动了什么程序、读取了哪个文件、访问了哪个域名、是否把敏感数据写入外部服务。

openEuler的AcTrail采用系统旁路观测思路，在尽量不修改Agent代码和推理流程的情况下，把模型交互、工具调用与底层系统行为关联起来。AgentCensor则负责安全策略配置、动态更新和热加载。

旁路观测的优势是框架无关。无论上层使用何种Agent开发框架，只要最终运行在系统上，其文件、进程、网络和设备访问就会留下痕迹。

开源的Agent Insight项目已经支持通过AcTrail和OTLP等方式采集Agent执行数据，并覆盖LangChain、LangGraph、LlamaIndex、Dify及多种代码Agent。这说明openEuler的可观测路线并不只想服务单一框架。(github.com)

但系统层治理也不是万能药。操作系统可以知道某个进程读取了客户名单，却未必能独立判断这次读取是否符合业务目的。完整的Agent安全仍然需要模型语义、企业身份系统和系统行为三层联合判断。

它和Kubernetes、Agent框架不是替代关系

openEuler Agentic Infra操作系统更像Agent运行底座，而不是新的Agent开发框架。

| 层级 | 典型职责 | openEuler Agentic Infra的关系 | |---|---|---| | Agent框架 | 规划、工作流、工具编排、模型调用 | 继续负责应用逻辑 | | Kubernetes等编排平台 | 服务部署、扩缩容、容器调度 | 负责集群级资源编排 | | 推理引擎 | 模型执行、批处理、算子优化 | 提供具体推理能力 | | Agentic Infra OS | 沙箱、缓存、记忆、安全、系统级观测 | 提供跨框架公共能力 | | CPU、GPU、NPU与超节点 | 执行计算和互联 | 提供底层硬件资源 |

Kubernetes擅长管理相对稳定的服务副本，但Agent会产生大量临时、关联性强的短任务；Agent框架擅长表达任务逻辑，却不应该自己实现文件系统快照和异构内存调度；推理引擎了解模型，却通常缺少跨节点、跨任务的全局视角。

openEuler试图填补的正是这些系统之间的缝隙。

它的优势在于已经拥有操作系统装机基础和产业生态，而不是从零构建一个Agent运行时。openEuler于2019年正式开源，2024年11月披露累计装机量超过1000万套；到2026年11月预计突破2200万套，约两年增长超过一倍。(ithome.com)

2200万套装机量不等于2200万套Agent基础设施，但它意味着openEuler有机会通过版本升级，把新能力送进金融、电信、能源和互联网等现有环境。对于基础软件而言，分发渠道往往和技术本身一样重要。

SP5发布，但成熟度仍要看交付

openEuler 24.03 LTS SP5是此次大会发布的长期支持版本更新。

根据现场信息，开放原子开源欧拉委员会主席熊伟在会上发布了openEuler 24.03 LTS SP5。与此同时，openEuler 26.09创新版本已经提前承载ram-a-kv、MemFabric、LMCache-Ascend、ModelFS、AcTrail和AgentCensor等AI特性。

这形成了典型的双线节奏：创新版本先快速验证技术，LTS版本再承担企业生产部署。

不过，截至11月13日发稿时，公开容器镜像资料仍主要列出24.03 LTS SP4，GitHub的release-management仓库已出现SP5分支，但完整镜像、版本说明和生命周期信息仍有待进一步同步。(github.com)

对于开发者和企业用户来说，接下来真正需要观察的不是发布会上的架构图，而是三件更具体的事：

• 沙箱冷启动和并发密度能否公布可复现测试；
• KV Cache优化能否跨模型、推理引擎和硬件平台工作；
• Agent安全策略能否接入企业现有IAM、审计与合规系统。

openEuler押注的是Agent规模化之后

openEuler这次发布的价值，在于它提前处理Agent数量增长后才会暴露的系统问题。

如果企业只有一个内部问答机器人，系统层Agent能力显得过重；如果一个请求会拉起几十个子任务，数千名员工每天调用数百次Agent，沙箱启动、缓存迁移、状态恢复和安全审计就会迅速变成成本中心。

从这个角度看，openEuler不是在追赶某个热门Agent框架，而是在押注Agent会像容器一样成为普遍工作负载。

这条路线的风险同样明显。Agent POSIX尚未成为产业标准，许多组件仍带有特定硬件和超节点生态的色彩；企业是否愿意把记忆、权限和缓存管理交给操作系统，也需要时间验证。

但把公共能力下沉是基础设施成熟的常见路径。数据库不再要求应用自己管理磁盘页，容器不再要求每个服务自己实现资源隔离，Agent最终也不应该让每个开发团队重新发明沙箱、记忆和审计系统。

openEuler给出的答案未必会成为唯一答案，但它抓住了一个真实问题：当Agent从Demo变成生产系统，竞争重点将从“能不能完成任务”，转向“能否以可控成本、安全地完成一百万次任务”。

参考来源

• IT之家：openEuler发布面向Agentic Infra的操作系统——大会发布信息、2200万套装机量、SP5版本及全球化进展。
• GitHub：openEuler RAM-A项目——长期记忆与语义感知KV Cache调度的开源实现说明。
• GitHub：openEuler Agent Insight项目——Agent可观测、执行诊断及AcTrail接入能力。
• GitHub：openEuler release-management——openEuler版本分支与SP5发布管理信息。
• GitHub：LMCache-Ascend——面向昇腾NPU的多级KV Cache与推理引擎集成项目。