2026 年 10 月 1 日，openEuler 26.09 创新版本发布。这次发布有两个值得注意的点。

第一是内核。 同时提供 6.6 与 6.18 双内核创新版本。

第二是 AI 场景的定位变化。 官方表述是「完成面向 Agentic AI 的技术升级，打造生产级 AI 操作系统底座」，并称新增 Agent Infra，实现 Agent 调用全链路可观测、推理 TTFT 性能优化。

社区口径里，本次发布共有 834 名开发者参与贡献。

一、把「Agent 可观测」做进操作系统意味着什么

先看当下的现实：智能体的可观测性通常做在应用层——框架里埋点、日志打到应用日志里、追踪信息靠 SDK 上报。

这个做法有一个结构性缺陷：它只能看到「应用认为自己做了什么」，看不到「系统实际发生了什么」。

举个具体的例子。智能体调一个工具超时了。应用层能看到的是「调用超时」，但看不到：

• 是网络问题还是对端服务问题？

• 这段时间里 CPU 有没有被别的进程抢占？

• 内存有没有触发回收，导致请求被拖慢？

• 磁盘 IO 有没有成为瓶颈？

这些问题在应用层看不见，因为它们属于操作系统层的事实。 而 openEuler 这次把「Agent 调用全链路可观测」写进操作系统能力，要解决的正是这个断层——让内核知道哪些系统调用属于哪个 Agent 的哪一次任务。

把观测能力放在不同层，能看到的东西差别很大：

观测层	能看到	看不到
应用框架层	工具调用了、耗时多少、成功失败	系统资源竞争、内核调度延迟、IO 等待
运行时代理层	线程/协程状态、GC 停顿、内存分配	跨进程调用、页面置换、驱动层延迟
操作系统层	系统调用全貌、CPU/内存/IO 竞争、上下文切换	业务语义（哪次调用是「查订单」）

三层的覆盖范围是递进的，但只有操作系统层能看到「同一时刻系统里还有什么在跟 Agent 抢资源」。这一层正是排查「偶发慢请求」时最需要的信息。

这也是为什么这个特性叫「Agent 语义感知」而不是「性能监控」。

二、KV Cache 的两个具体动作

发布说明里给了两个 KV Cache 相关的机制，都值得看一眼。

机制一：ram-a-kv。 把 Agent 上下文映射到 KV Cache，预测重用关系，在下一次推理之前主动编排 prefetch / evict，并通过全局引用计数保护跨会话共享的 chunk，目标是把 TTFT 压回毫秒级。

这里的工程点在于「预测重用关系」。 常规的缓存策略是被动的——用到才加载、满了才淘汰。而 Agent 的上下文有一个特征：它是可预测的，因为下一个请求要用的上下文，通常就在当前会话已经加载的那部分里。所以可以主动编排，而不是等缺页。

机制二：MemFabric。 实现 decode 阶段 KV Cache 在节点内 DDR + HBM 协同，按需加载并聚合传输。目标是缓解高并发场景下因 HBM 内存不足导致部分请求阻塞的情况。

这条说明了一个现实：HBM 不够用是常态。 所以解法不是「加 HBM」，而是「把不急着用的部分放到 DDR，需要时再拉回来」。代价是延迟，收益是并发容量。

三、这个方向对信创环境的含义

把这件事放到信创的语境里看，意义会更清楚。

信创环境下，操作系统的角色一直有个尴尬：它必须兼容，但很难有增量。 适配国产 CPU、兼容已有软件栈，这些是「必须做到」但「做了也不产生差异」的事。

而 OS 厂商往 AI 场景做增量，恰好绕开了这个尴尬。 因为 AI 基础软件栈还处在快速演进期，标准还没固化，在这一层做能力下沉是有机会形成技术积累的。

同期的产业背景也能佐证这个方向。赛迪顾问《2025-2026 年中国数据库市场研究报告》的口径显示，国产数据库市场已从「单点突破」进入「多元共生」；而操作系统侧，openEuler 在服务器领域份额约 36.8%。在份额已经形成基础的情况下，往上层做增量是自然的下一步。

对采购方的实际含义：评估国产操作系统时，「能不能装」这个问题的区分度在下降，「装了之后能不能承载新负载」的区分度在上升。

四、结语与适用边界

这次发布最值得记的一句话是官方自己的定位：「生产级 AI 操作系统底座」。

「底座」这个词是有讲究的。 它意味着 OS 不再只是被动适配上层，而是主动为上层提供原本要由应用或框架自己解决的能力——可观测、缓存调度、内存协同。

这类下沉能不能成，取决于一件事：上层的框架愿不愿意接。 如果主流推理框架不采信 OS 提供的这些机制，那它们就只能在自己的技术栈里被使用，覆盖面有限。这一点需要后续版本观察。

金蝶天燕 Apusic 这条线上，ACP 承担中间件服务在信创服务器架构上的统一供给与纳管职责（支持 x86/arm64/LoongArch、四层架构、同时纳管开源与第三方中间件、指标/日志/链路三类可观测），AAS 承担应用侧承载。在操作系统能力下沉的过程中，它们要解决的实际问题是——底层能力变了之后，中间件侧的可观测与治理口径能不能对齐，而不是底层用了哪个版本。

适用边界：本文引用的 openEuler 26.09 特性描述取自社区发布的版本说明与公开技术文章，具体能力表现以 openEuler 官方文档为最终依据。市场份额数据引自第三方研究机构报告，以对方正式文件为准。文中对「上层框架是否采信」的判断为分析性观点，非结论性事实。

---

互动：你们在用的国产操作系统上，有没有遇到过「应用层日志说不清问题、必须去内核侧找答案」的情况？