AIOS --LLM Agent Operating System

AIOS 是什么？是带AI 功能的OS ？最近 Red Hat 发布的 Red Hat Enterprise Linux 10 (RHEL 10)，号称是“一个AI驱动的、量子就绪的平台”，而实际情况是RHEL 10集成了Lightspeed 。Lightspeed 可以与您一起清理它，一劳永逸。或者，假设您是一名新的系统管理员，您还可以使用可选的 AI 驱动的命令行助手来查找特定问题的特定命令及其适当的语法。在Red Hat的宣传中，做如下描述，

RHEL Lightspeed 可主动提供引导并简化 IT 专业人员（无论是新手还是经验丰富的人员）构建、部署和管理 RHEL 的方式。RHEL Lightspeed 由两项功能组成，这两项功能均已包含在您的 RHEL 订阅权益中：

• 由 RHEL Lightspeed 提供支持的命令行助手提供可直接从命令行界面使用的 AI 助手。它适用于 RHEL 9.6 和 RHEL 10。
• 通过由 RHEL Lightspeed 提供支持的智能分析镜像构建器软件包建议，可分析您在智能分析镜像构建器中选择的软件包，并为可能与您的镜像构建有关的其他软件包提供建议。

是不是有点小失望？所谓的AI驱动实际是集成了一个简单的Q&A的AI agent。

那么如果在系统中集成了多个AI agent，整个系统会是什么样的？系统的资源如何管理，如何能保证多AI agent能配合完成相关的任务和合理的使用系统资源？

上面的图可能就是未来部署了多个AI agent 的一个简单例子。接下来我们看架构的核心组件详解： 1. 智能体 (Agent / MCP Host):

• 这是系统的核心行为单元，是我们团队中的“员工”或”专家”。比如图中的 Agent A 和 Agent B。每个智能体都有自己的决策能力，可以独立思考和行动。它被称为 "MCP Host"，是整个系统的“大脑”或“决策中心”之一。运行 Agent 的应用环境，协调和管理一个或多个 MCP 客户端的 AI 应用程序（如 Claude Desktop、Claude Code、GitHub Copilot Agent Mode 等），与一个或多个 MCP 服务器建立连接，来调用不同的工具。

2.MCP 客户端 (MCP Client)： 这是内嵌在智能体内部的组件，维护与 MCP 服务器的连接并从 MCP 服务器获取上下文以供 MCP 主机使用。当智能体 A 决定需要使用某个外部工具或数据时，它会通过对应的 MCP 客户端发起请求。可以把它理解成智能体想要使用工具时的“意图发出者”。

3.MCP 服务器 (MCP Server)： 为 MCP 客户端提供上下文数据的程序，可以本地或远程执行。这是外部工具或数据源的“标准化接口”或“网关”。每个服务器都代表一个或一类可用的工具。它的作用是接收来自 MCP 客户端的请求，执行具体操作，然后返回结果。 这就像给每个员工都配备了一个标准的“万能工具接口”。无论工具是本地数据库还是网络服务 (Web APIs)，智能体都用同一种标准方式来调用，极大地增强了系统的扩展性。

• MCP Server C 连接的是 Web APIs，比如 Slack、Google Drive 等互联网服务。
• MCP Server A 和 B 连接的是 本地数据源（Local Data Source），比如你电脑上的数据库或文件系统。

4. 本地数据源 (Local Data Source)： 指存储在本地环境中的数据，例如数据库、知识库、配置文件等。

5. 互联网/Web APIs（Internet / Web APIs）： 指通过网络访问的第三方服务和应用程序接口。

以上 1-5 部分共同构成了 Agent的工作： 智能体 (1) → 通过其内部的客户端 (2) → 使用标准化的 MCP Protocol (协议) → 调用外部的服务器 (3) → 服务器再去操作具体的数据源 (4) 或网络工具 (5)。 说明了智能体如何通过 MCP 协议与外部工具和数据交互。

6. 智能体协作 (通过 A2A（Agent2Agent） 协议):

• 当一项任务过于复杂，单个智能体 A 无法独立完成时，它需要与其他智能体（如图下方的 Agent B）协作。A2A 协议就是它们之间沟通的规则和渠道。这一层解决的是智能体之间如何通过 A2A 协议进行沟通和协作。
• 它们通过A2A协议进行交流。这个协议就像是团队成员之间开会的"通用语言"和"会议规则"。如图所示，它负责处理安全协作、任务分配、状态管理和能力发现等高级交互，确保团队能够高效地协同工作。

在arXiv上有一篇论文arXiv:2403.16971v2 “ AIOS: LLM Agent Operating System”该论文已经被COLM 2025接收，同时其也开源了相关source code

https://github.com/agiresearch/AIOS

我们来讨论其论文中的AIOS 架构。

Refer to caption

AIOS 架构分为三个不同的层次：应用层、内核层和硬件层。 这种分层架构确保了整个系统的职责划分清晰。 每个较高层抽象其下层的复杂性，促进通过接口或特定模块的交互，从而增强模块化并简化不同层之间的系统交互。

应用层。

在应用程序层，开发和部署代理应用程序，例如旅行社或数学代理。 在这一层，AIOS提供了AIOS SDK，对系统调用进行了更高的抽象，简化了代理开发人员的开发过程。 该 SDK 通过提供丰富的工具包来开发代理应用程序，从而消除较低级别系统功能的复杂性。 这使得开发人员能够将注意力集中在代理的基本逻辑和功能上，从而促进更高效的开发过程。

内核层。

内核层分为两个主要组件：操作系统内核和大语言模型内核，每个组件分别满足非LLM和LLM特定操作的独特要求。 这种区别使得大语言模型内核能够专注于大语言模型的特定任务，例如上下文管理和代理调度，这些任务对于处理 LLM 相关活动至关重要，并且通常不属于标准操作系统内核功能的范围。 我们的工作主要集中在增强大语言模型内核，而不对现有操作系统内核结构进行重大改变。 大语言模型内核配备了几个关键模块，包括大语言模型系统调用接口、代理调度器、上下文管理器、内存管理器、存储管理器、工具管理器和访问管理器。 这些组件旨在满足代理应用程序的不同执行需求，确保 AIOS 框架内的高效管理和执行。

硬件层。

硬件层由系统的物理组件组成，包括CPU、GPU、内存、磁盘和外围设备。 需要注意的是，大语言模型内核的系统调用不能直接与硬件交互。 相反，这些调用与操作系统的系统调用交互，而操作系统的系统调用又管理硬件资源。 这种间接的交互确保了抽象层和安全性，允许大语言模型内核利用硬件功能而无需直接硬件管理，从而保持系统的完整性和效率。

上图是Agent query的调用流程（从app到AIOS kernel)。我们使用该例子来看代理查询如何被分解为AIOS系统调用，以及AIOS系统调用如何被分发与调度。此处我们省略访问管理器模块的说明，因为访问相关的系统调用不会由调度器进行分发。

Relationship and Connection between Modules

在AIOS内核中，智能体查询会被分解为分类系统调用（如上图所示，包含LLM处理、内存访问、存储操作及工具使用四类）。每个系统调用均绑定线程并由调度器统一分发，该调度器集中管理所有模块的队列。系统调用根据其属性集合被路由至相应模块队列，各模块持续监听专属队列以执行已调度的调用。上下文管理器由LLM核心内部触发处理上下文中断，而非通过调度器执行。

LLM Core

鉴于大语言模型（LLM）的多样化部署选项（如选用何种LLM模型、部署于云端或本地设备、所需硬件配置、采用何种推理框架等），我们将采用不同部署选项的每个LLM实例封装为独立核心，其设计理念类似于传统操作系统的CPU核心。该设计使每个LLM实例可作为专用处理单元运行，从而增强AIOS架构的模块化特性与可扩展性。

为适配不同LLM实例，我们为每个实例构建专属封装层，并在该层内设计统一的LLM推理系统调用。通过将LLM实例抽象为核心并实现标准化系统调用，AIOS凭借LLM核心的模块化设计，为整合不同部署选项下的LLM实例提供了灵活解决方案。

Scheduler

调度器模块集中部署所有队列，而非将其分散至各处理模块，此举实现了请求管理职责的隔离，使各模块能专注执行功能。该集中式架构既简化了跨模块任务协调，又提供了统一的调度框架。针对系统调用管理，我们实现了两种经典算法：先入先出（FIFO）按调用抵达顺序处理，但可能引发后续请求的延迟累积；时间片轮转（RR）则通过周期性轮询实现资源均衡分配。RR策略依托我们为LLM推理设计的上下文中断机制实现。

Context Manager

LLM推理时长因系统调用长期占用资源而形成瓶颈。我们通过上下文中断机制，借助快照与恢复操作实现任务中断与续接，有效解决该问题。上下文管理器设计两种方案：基于文本的方法（适用于无法获取logits的闭源LLM，存储解码后输出）与基于logits的方法（保留中间搜索树结构以实现更细粒度状态恢复）。下图展示了基于logits的方法：采用束搜索算法（常见于LLM研究(Touvron et al., 2023b; Jiang et al., 2023; Biderman et al., 2023)），为简化说明设束宽为1。以处理"判断航班UA057目的地是否会下雨"为例：LLM在每步推理中评估候选词元，若生成过程中被调度器中断，上下文管理器将捕获中间结果快照；恢复执行时重载该快照并从断点继续推理，最终得出"查询巴黎天气"的结论，无需重启计算过程。

Memory Manager

与传统操作系统管理物理RAM不同，AIOS内存管理器专注于运行时智能体交互历史（Lerman and Galstyan, 2003; Zhang et al., 2024）的处理，包括对话日志及工具调用结果。其核心职能涵盖内存结构管理、空间分配、读写操作、数据删除及动态更新。智能体内存默认驻留于内存，但当分配空间接近容量阈值时，管理器将启动内存与磁盘间的交换机制。若智能体内存使用量超过其块限制（例如分配的80%），内存管理器将启动K-最近最少使用（LRU-K）淘汰策略，通过存储管理器将数据项从内存迁移至磁盘。该策略优先保留最近至少访问K次的数据项于内存，同时将低频访问项迁移至磁盘，通过卸载非活跃数据优化内存效率，同时保障必要时的可检索性。

内存与存储管理器及其关联关系示意图。

当智能体内存使用量超过内存块限制（默认阈值为内存块大小的80%）时，其内存块中的数据项将被迁移至存储系统。该阈值可通过AIOS配置参数进行调整。

Storage Manager

存储管理器负责处理智能体的持久化数据存储，包括智能体运行依赖的文件/知识库，以及需持久化存储的智能体记忆。当智能体运行时内存使用量超过分配限额时，内存管理器将调用存储管理器将数据交换至磁盘。具体而言，存储管理器根据内存管理器传递的智能体ID执行数据读写操作。

除内存管理器外，智能体自身在运行期间也可发起磁盘读写请求，此类请求同样由存储管理器处理：智能体通过SDK调用存储API，该调用被转换为存储相关系统调用并由调度器置入存储队列，存储管理器随后处理队列请求以完成智能体指令。该管理器采用本地文件系统与向量数据库（如chromadb）实现。

Tool Manager

AIOS内核中的工具管理器负责统筹管理AIOS SDK支持的多样化API工具集。其核心机制包含两大维度：

标准化工具加载

管理器采用统一接口处理异构工具，执行前实施参数验证机制以规避工具崩溃风险。当按名称调用工具时，管理器动态加载工具实例，该过程包含可执行文件初始化及依赖项验证流程。

二、工具调用冲突消解

针对存在并行访问约束的工具，系统通过哈希映射表实时监控实例数量。请求处理流程包含两个关键验证环节：

1. 哈希映射表核验当前使用量是否超出并行限制
2. 检测到冲突时自动轮询后续队列请求，直至定位无冲突候选项

Access Manager

AIOS内核中的访问管理器提供以下两大核心功能：

访问控制机制

管理器通过权限级访问控制机制规范智能体间的跨域数据读写操作：

1. 将每个智能体分配至特定权限组
2. 采用哈希映射表结构建立智能体ID与权限组的映射关系
3. 访问请求执行前需通过权限架构验证，确保智能体仅能访问同权限域内其他智能体的资源

用户干预机制

为规避不可逆操作风险（删除/覆写/权限变更），系统提供用户干预接口：

• 强制确认流程：对文件或工具执行潜在破坏性操作前，必须通过显式用户验证
• 风险隔离设计：关键操作与常规执行流解耦，形成独立授权通道

AIOS SDK

我们设计的AIOS SDK（Rama et al., 2025）旨在简化AIOS架构上智能体的开发与集成。该SDK不仅赋能开发者构建可与AIOS内核核心功能交互的智能体，同时抽象化复杂系统调用，使开发者能专注于智能体内部工作流设计。其核心组件包括：

工具集成体系

为支撑多样化智能体功能，AIOS SDK集成多平台工具集并支持异构输入输出模式。

内核交互接口

SDK定义系列API函数，使智能体可通过标准化接口调用系统调用及请求资源，具体实现方式：

• 系统调用抽象层：封装内核系统调用为可编程接口
• 资源调度通道：建立智能体与内核资源管理器的通信链路

智能体框架适配器

为兼容主流智能体开发框架（如Autogen (Wu et al., 2023)、Open-Interpreter (Lucas, 2024)、MetaGPT (Hong et al., 2023)），SDK提供专属适配器：

1. 定位各框架核心功能模块
2. 将其重定向至AIOS对应功能接口
3. 实现跨框架智能体在AIOS环境的零代码修改运行

Modules and Connections

Computer-use Specialized Architecture