[论文笔记]AIOS: LLM Agent Operating System

本文主要是介绍[论文笔记]AIOS: LLM Agent Operating System，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

引言

这是一篇有意思的论文AIOS: LLM Agent Operating System，把LLM智能体(代理)看成是操作系统。

基于大语言模型(LLMs)的智能代理的集成和部署过程中存在着许多挑战，其中问题包括代理请求在LLM上的次优调度和资源分配，代理和LLM之间在交互过程中保持上下文的困难，以及集成具有不同能力和专业化的异构代理时固有的复杂性。代理数量和复杂性的迅速增加进一步加剧了这些问题，通常导致资源的瓶颈和次优利用。

受到这些挑战的启发，本篇工作提出了AIOS，一种LLM代理操作系统，将大语言模型嵌入操作系统(OS)作为OS的大脑。具体而言，AIOS旨在优化资源分配，促进代理之间的上下文切换，实现代理的并发执行，为代理提供工具服务，并维护代理的访问。

项目开源在：https://github.com/agiresearch/AIOS

1. 总体介绍

在自主代理领域，人们致力于开发能够独立运行、做出决策并执行任务的系统，无需或只需最小限度的人类干预。这些代理被设计为理解指令、处理信息、做出决策并采取行动以实现自主状态。大语言模型的出现为代理开发带来了新的可能性。当前的LLMs已经展现出在理解指令、推理和解决问题、与人类用户以及外部环境进行交互方面的强大能力。建立在这些强大的LLMs之上，新兴的基于LLM的代理在各种环境中展现出强大的任务完成能力，从虚拟助手到涉及复杂和创造性问题解决、规划和推理的更复杂系统。

一个引人注目的例子是基于LLM的代理如何解决真实世界任务，如图1所示。在用户提出旅行组织请求后，旅行代理将任务分解为可执行步骤。然后，它按顺序执行这些步骤以预订航班、预订酒店、处理付款，并根据用户的喜好更新日历。在计划执行过程中，代理展现出推理和决策能力，使其与仅受制于预定义功能或工作流程的传统软件应用区分开来。要实现这一旅行场景，代理需要与LLM服务（例如，检索和理解用户喜好、决定调用哪种工具API、生成评论和响应）以及传统操作系统（OS）服务（例如，访问磁盘驱动器和执行软件）进行交互。

随着代理数量和复杂性的指数增长，LLM和OS的功能面临越来越大的压力。例如，在有限的LLM资源中安排和优先处理代理请求是一个重要的挑战。此外，处理具有庞大上下文的情况时，LLM的生成过程可能需要很长时间，有时会导致调度程序挂起生成。这带来了一个问题，即制定一种快照机制来记录LLM当前的生成结果，从而即使在LLM尚未完成对当前请求的响应生成时也能实现暂停/继续行为。此外，一旦一个代理获得可调用工具列表，确定调用这些工具的最佳顺序又带来了另一个挑战，因为多个代理可能需要调用相同的工具。此外，多个代理的并发操作需要一个强大的内存管理系统，跨不同代理进行管理，同时确保对隐私和访问控制措施的严格执行。

为了解决上述挑战，作者提出了AIOS，一种LLM代理操作系统（图2），旨在提供LLM和OS功能的模块隔离和聚合。为了解决与LLM相关的任务和与LLM无关的任务之间可能出现的冲突，作者提出了设计LLM特定内核的方案。这个内核分离了类似操作系统的职责，特别是与LLM代理、它们对应的资源和开发工具包相关的职责。通过这种分离，LLM内核旨在增强LLM相关活动的管理和协调。在所提出的LLM内核中，设计了一套模块，每个模块专门应对与LLM操作相关的独特功能。下面概述了这些模块及其各自的功能：

代理调度器(Agent Scheduler)：优先处理和安排代理请求，以优化LLM的利用。
上下文管理器(Context Manager)：支持在LLM中快照和恢复中间生成状态以及LLM上下文窗口的管理。
记忆管理器(Memory Manager)：为每个代理的交互日志提供短期记忆。
存储管理器(Storage Manager)：将代理的交互日志持久化到长期存储，以便未来检索。
工具管理器(Tool Manager)：管理代理调用外部API工具（例如搜索、科学计算）。
访问管理器(Access Manager)：在代理之间执行隐私和访问控制策略。

除了这些模块，内核通过LLM系统调用接口公开了一个接口，代理可以透明地利用这些服务。此外，设计了AIOS SDK来进一步封装LLM系统调用，为代理开发人员提供更方便的代理库函数。利用AIOS架构，像旅行规划器这样的代理可以将其任务分解成步骤，流畅地结合LLM推理（例如计划生成和工具调用决策）和OS级别的操作（例如访问存储和执行软件服务）。这种能力的协同组合使多个LLM代理能够处理越来越复杂、多模态的任务，这些任务需要推理、执行和与物理世界的交互。

2. 相关工作

2.2 大型语言模型代理

基于大型语言模型的自主代理将自然语言指令作为复杂任务求解的输入。关于基于LLM代理的研究通常可以分为单代理系统和多代理系统。

基于LLM的单代理系统 基于LLM的单代理系统(single-agent systems,SAS)使用单个LLM代理进行复杂任务求解，如旅行规划、个性化推荐和艺术设计。该代理接收用户的自然语言指令作为输入，并将任务分解为一个多步计划以完成任务求解，其中每个步骤可能调用外部工具完成，例如收集信息、执行专业模型或与外部世界进行交互。

基于LLM的多代理系统 基于LLM的多代理系统(multi-agent systems,MAS)利用多个代理之间的交互来解决问题。多个代理之间的关系可能是合作的、竞争的，或是合作和竞争的混合。在合作的多代理系统中，每个代理接收并评估其他代理提供的信息，从而共同合作解决复杂任务，如角色扮演、社会模拟和软件开发。在竞争性多代理系统中，代理可能在游戏环境中进行辩论、谈判和竞争以实现自己的目标。一些多代理系统可能在代理之间同时表现出合作和竞争。

3. AIOS层

如图2所示，AIOS架构分为三个独立的层级：应用层(application layer)、内核层(kernel layer)和硬件层(hardware layer)。这种分层架构确保了系统各个部分的职责清晰划分。每个更高级别的层次都会对其下层的复杂性进行抽象，通过接口或特定模块促进交互，从而增强模块化并简化跨不同层级的系统交互。

应用层 在应用层，代理应用程序被开发和部署，如旅行代理或数学代理。在这一层，AIOS提供了AIOS SDK，通过更高级别的系统调用抽象简化了代理开发人员的开发过程。该SDK通过提供一个丰富的工具包来为代理应用程序的开发提供便利，该工具包抽象化了更低层次系统功能的复杂性。这使开发人员能够专注于代理的基本逻辑和功能，促进更高效的开发过程。

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

硬件层 硬件层包括系统的物理组件，包括CPU、GPU、内存、磁盘和外围设备。需要注意的是，LLM内核的系统调用不能直接与硬件交互。相反，这些调用与操作系统的系统调用接口交互，后者再管理硬件资源。这种间接交互确保了一层抽象和安全性，使LLM内核能够利用硬件能力而无需直接进行硬件管理，从而保持系统的完整性和效率。

4 AIOS实现

4.1 代理调度器

代理调度器旨在以高效的方式管理代理请求。考虑图3中的各种代理（表示为A、B和C），每个代理都有多个执行步骤。在顺序执行范例中，代理任务按照线性顺序处理，其中来自同一代理的步骤将首先处理。这可能导致排在序列后面的任务等待时间增加。

代理调度器设计如图3所示。在图中，A1、A2、A3代表代理A的执行步骤，B1、B2代表代理B的执行步骤，C1、C2、C3代表代理C的执行步骤。顺序执行将导致代理任务按照线性顺序依次执行，这可能会增加后续任务的等待时间。而并发执行则可以减少等待时间。

代理调度器根据特定的调度算法（如FIFO、Round Robin等）来管理代理任务的执行顺序，以优化系统性能和资源利用率。通过并发执行，调度器显著平衡了每个代理的等待时间和周转时间，因为来自不同代理的任务被交错执行并并行执行。这种并发方法通过时间轴展示，其中来自不同代理的任务以交错方式处理（例如，A1、B1、C1、B2、A2、A3、C2、C3），确保没有单个代理垄断处理资源，且空闲时间被最小化。

上下文管理器

上下文管理器负责管理提供给LLM的上下文以及在给定某个上下文时生成过程。它主要涉及两个关键函数：上下文快照(snapshot)和还原(restoration)，以及上下文窗口管理(context window management)。

上下文快照和还原 考虑到调度算法可能涉及时间量子操作(例如 Round-Robin)，并且代理请求可能会被调度器挂起。即使LLM尚未完全生成响应，也会发生这种挂起。因此，需要一种机制来保留LLM生成过程的状态，确保一旦资源再次可用，就可以准确恢复。

AIOS提供了上下文管理器中的快照和还原机制来解决这个问题，可以从图4中看到。使用典型的LLM中的束搜索过程，用于说明生成解码过程。为简单起见，将束宽度设置为1。具体来说，考虑代理请求为：确定航班UA057的目的地是否会下雨。在每个步骤中，LLM评估多个潜在候选项，并保留最有希望的路径以便根据预定义的光束宽度进一步扩展。

当这种生成过程在中间步骤被调度器挂起时，上下文管理器使用快照函数来捕获和存储LLM的光束搜索树的当前状态，包括为生成响应正在探索的所有中间概率和路径。在恢复时，使用还原函数重新加载从快照中保存的状态，允许LLM从挂起点恢复其生成过程，最终得到答案：在巴黎搜索天气。这样，上下文管理器确保一个代理请求的临时挂起不会导致进度丢失，从而在不损害响应生成的质量和效率的情况下优化资源使用。

上下文窗口管理 为了解决长上下文超过LLM上下文窗口限制所带来的挑战，上下文管理器还需要管理上下文窗口的潜在扩展。具体来说，AIOS中的上下文管理器支持基本文本摘要和其他扩展技术，以管理上下文窗口。通过这种方式，它可以帮助增强LLM处理和理解广泛上下文的能力，而不会损害信息的完整性或相关性。

4.3 记忆管理器

如图5所示，记忆(Memory)管理器在代理程序的生命周期内管理短期记忆(short-term memory)，确保数据仅在代理程序处于活动状态时存储和访问，无论是等待执行还是在运行时。当前的AIOS支持独立存储每个代理的记忆，其他代理无法直接访问，除非经过访问管理器授权。与后文介绍的存储管理器相比，记忆管理器能够实现快速数据检索和处理，促进对用户查询和交互的迅速响应，而不会使AIOS的存储负担过重。

4.4 存储管理器

存储管理器负责数据的长期保存，监督需要无限期保留的信息的存储，超出任何单个代理程序的活动声生命周期。AIOS中的永久存储是通过各种持久性介质实现的，如本地文件、数据库或基于云的解决方案，确保数据的完整性和可用性，供将来参考或分析。存储管理器支持检索增强。通过存储用户偏好并维护历史交互日志，存储管理器可以丰富代理程序的知识更新并增强长期用户体验。

4.5 工具管理器

AIOS系统中的工具管理器管理着增强LLM功能的各种API工具。如表1所示，工具管理器整合了各种来源的常用工具，并将它们分类到不同的类别中，涵盖了Web搜索、科学计算、数据库检索、图像处理等。

4.6 访问管理器

访问管理器通过为每个代理管理专用权限组，协调不同代理之间的访问控制操作。被排除在代理的特权组之外的其他代理将被拒绝访问其资源，比如交互历史。为进一步增强系统的透明性，访问管理器编制并维护审计日志。

4.7 LLM系统调用

LLM内核中的LLM系统调用接口旨在提供基本的LLM调用操作函数。该接口充当了复杂代理请求与执行不同内核模块之间的桥梁。正如表2所示，类似于操作系统系统调用，LLM系统调用提供了一套跨越内核模块的基本功能，包括代理管理、环境处理、内存和存储操作以及访问控制。

4.8 AIOS SDK

AIOS SDK为开发人员提供一个多功能工具包，用于在AIOS内部构建复杂的代理应用程序。该SDK涵盖了广泛的功能，从初始化代理和管理代理生命周期到促进复杂操作，如资源监控和代理任务的制定计划。当前在AIOS中支持的SDK功能如表3所示。

5. 评估

5.2 实验结果

一致性分析 为了回答一致性问题，首先分别运行了三个构建的代理以生成结果。随后并行执行这些代理，并在每个步骤捕获它们的输出。为了评估多个代理同时运行和单个代理依次运行时输出的一致性，利用 BLEU 分数和 BERT 分数 [ 作为评估指标。这两个指标的取值范围都是从 0.0 到 1.0，单个代理情境产生的输出作为参考标准，将温度参数设置为 0 以消除随机性的影响。正如表4所示，BLEU 分数和 BERT 分数都达到了 1.0 的数值，表明在多代理和单代理配置下生成的输出完美一致。

性能分析 为了回答效率问题，对比了采用 FIFO 调度和非调度方法的 AIOS，在这两种方法下前述的三个代理同时运行。在非调度设置下，三个代理按照预定义的顺序依次执行：数学代理、叙述代理和记录代理。采用了两个指标来评估时间效率：等待时间（代理请求提交到开始的时间间隔）和周转时间（代理请求提交到完成的时间间隔）。由于每个代理将向 LLM 发送多个请求，每个代理的等待时间和周转时间分别被计算为其发送的所有请求的等待时间和周转时间的平均值。为减少随机性，分别对采用和不采用调度的这三个代理进行了五次独立试验并报告结果。如表5所示，非调度方法对于序列中较早的代理表现出良好的性能，但以延长后续代理的等待时间和周转时间为代价。相反，AIOS的调度机制有效地调节了等待时间和周转时间，尤其是在 LLM 较大时，这一好处尤为显著。