开源 | AIOS: 大语言模型时代的Agent应用操作系统，更好更快的构建复杂Agent应用

发布时间：2024 年 03 月 25 日

Agent 人工智能 操作系统

摘要

在部署和集成基于 LLM 的智能代理时，面临的诸多挑战严重制约了其效能和效率，如对 LLM 资源分配和调度的不合理，交互过程中的上下文保持难题，以及整合具备不同能力和专长的异构代理所固有的复杂性。随着代理数量和复杂度的增长，这些问题越发突出，往往导致资源利用率低下和系统瓶颈。因此，我们推出了 AIOS——一款将大型语言模型融入操作系统核心的 LLM 代理操作系统。AIOS 特别设计以优化资源分配，简化跨代理上下文切换，支持代理并行执行，提供工具服务功能，并确保对代理的有效访问控制。本文详述了该操作系统的架构设计，明确了要解决的核心问题，并初步展示了 AIOS 的设计与实现方案。通过实验证明，AIOS 模块在处理多代理并发执行时表现出良好的可靠性和高效性。我们的目标不仅是提升 LLM 代理的性能和效率，更是要为未来构建和完善 AIOS 生态系统树立典范。目前该项目已在 GitHub 开源，地址为https://github.com/agiresearch/AIOS。

缘起

随着 ChatGPT 等大语言模型的问世，智能体应用(Agent 应用)迎来了井喷式发展。正如吴恩达（编者注）最佳所说的划重点 | 吴恩达：Agent模式将在不久的将来超过下一代模型，Agent 应用可能是通向 AGI 应用的道路，性能可能超过 GPT5。

如上图所示，展示了一个基于 LLM 的 Agent 应用如何解决真实世界中的旅行规划问题。Agent 将用户的旅行请求细化为一系列可操作的步骤，然后依次执行，包括预订航班、酒店、处理支付和更新日历，以满足用户的个性化需求。在执行过程中，Agent 应用依赖大语言模型强大的理解和推理能力，与传统软件应用相比，它们通常受限于固定的功能集或工作流程。为了完成这一旅行规划，代理需要与 LLM 服务进行交互，如获取和理解用户偏好、选择合适的工具 API、生成反馈等，同时也需要与操作系统服务进行交互，如访问磁盘驱动和执行软件操作。

随着 Agent 类应用数量和复杂性井喷式发展，大语言模型和操作系统逐渐成为 Agent 类应用发展的瓶颈。比如：大语言模型的推理成本高昂，如何在有限的 LLM 资源中有效调度和优先处理代理请求？比如：LLM 在处理长篇上下文的时候，生成过程往往比较费时间，甚至被意外中断。

基于以上这些问题，作者提出需要设计一种机制，能够捕捉 LLM 当前的生成结果，实现即使在 LLM 尚未完成当前请求的响应生成时的暂停和恢复功能。而且，当代理获取了可用工具列表后，如何确定最优的调用顺序也是一个问题，尤其是多个代理可能需要同时调用同一工具。此外，多个代理的同时运行还需要一个强大的内存管理系统，以确保不同代理间的内存管理，并严格实施隐私和访问控制措施。

基于这样的想法，作者提出了AIOS——一种 LLM Agent 应用操作系统，旨在实现模块隔离和整合 LLM 与 OS 的功能。为了解决 LLM 相关任务与其他任务之间可能出现的冲突，我们提出了一个专门针对 LLM 的内核设计。该内核将 OS 的职责进行划分，尤其是那些与监督 LLM Agent、管理其资源和开发工具包相关的职责。通过这种划分，LLM 内核致力于提升 LLM 相关活动的管理和协调效率。在这个 LLM 内核中，我们开发了一系列模块，每个模块都专注于处理 LLM 操作中的特定功能。

什么是大语言模型 Agent 应用

基于大型语言模型（LLM）的自主 Agent 应用是指能够接收自然语言指令，用以完成复杂的任务解决工作。这类 Agent 主要分为两类：单 Agent 系统和多 Agent 系统。

在单 Agent 系统中（Single Agent System, SAS），一个 LLM 代理独立承担起如旅行规划、个性化推荐和艺术设计等复杂任务。代理接收用户的自然语言指令，将任务拆解成多个步骤，并可能调用外部工具来完成每一步，包括搜集信息、运行专业模型或与外部世界互动。单 Agent 应用可能会在数字环境或物理环境中运行，或者两者兼顾，具体取决于任务的性质。例如，在虚拟或数字环境中的代理可能会调用 API、浏览网站或执行代码，而在物理环境中的 Agent 则可能操纵物体、进行实验或做出实际决策。

多 Agent 系统（Multiple Agent System, MAS）则利用多个 Agent 之间的相互作用来共同解决问题。这些 Agent 之间可能是合作关系，也可能是竞争关系，或者两者兼有。在合作型的多代理系统中，代理们互相获取和评估信息，共同完成复杂任务，如角色扮演、社交模拟和软件开发。而在竞争型的多 Agent 系统中，代理们可能在一个游戏环境中通过辩论、谈判和竞争来达成目标，比如提升谈判技巧或就正确答案进行辩论。有些系统则同时展现出合作与竞争的特性。例如，WarAgent 通过将每个国家建模为 LLM 代理，研究国家间的互动如何引发国际冲突，这些国家可能会进行合作，如结盟和签订和平协议，或者相互竞争，如进行军备竞赛、动员和宣战。

什么是 AIOS

如上图所示，AIOS 系统架构分为三个清晰的层次：应用层、内核层和硬件层。这样的分层设计明确了系统的职责划分。每一层都在其下层的基础上提供更高级别的抽象，通过接口和模块简化了层与层之间的交互，增强了系统的模块化和易用性。

在应用层，可以开发和部署各种Agent应用，例如旅行规划Agent或数学问题解决Agent。AIOS 在这一层提供了 AIOS 软件开发工具包（SDK），它通过更高级别的系统调用抽象，简化了代理开发者的开发流程。该 SDK 包含了丰富的工具集，隐藏了底层系统功能的复杂性，让开发者能够专注于代理的核心逻辑和功能开发，从而提高了开发效率。

内核层进一步细分为两个主要部分：操作系统内核和大语言模型 Agent 应用内核，它们分别满足非大语言模型 Agent 应用和大语言模型 Agent 应用特定的操作需求。这种分离使得大语言模型 Agent 应用内核能够专注于其特有的任务，例如上下文管理和代理调度，这些任务对于处理大语言模型 Agent 应用相关活动至关重要，而传统操作系统内核通常不涉及这些功能。我们的工作重点是提升大语言模型 Agent 应用内核的性能，同时尽量不改变现有操作系统内核的结构。大语言模型 Agent 应用内核内置了多个关键模块，如系统调用接口、代理调度器、上下文管理器、内存管理器、存储管理器、工具管理器和访问管理器，它们共同确保了代理应用在 AIOS 框架内得到高效的管理和顺畅的执行。这些模块的具体内容将在后续章节详细阐述。

硬件层包含了系统的所有物理组件，如中央处理器（CPU）、图形处理器（GPU）、内存、硬盘和外围设备等。值得注意的是，大语言模型 Agent 应用内核的系统调用并不直接与硬件组件交互，而是通过操作系统的系统调用来实现，这样可以管理硬件资源。这种间接的交互方式提供了必要的抽象层和安全保障，使得大语言模型 Agent 应用内核能够充分利用硬件的能力，而无需直接进行硬件管理，保障了系统的稳定性和高效运行。

AIOS运行原理

Agent 调度器

Agent调度器的设计目的是高效地处理代理的请求。如上图所示，有多个Agent（标记为A、B和C），每个Agent包含多个执行步骤。在传统的顺序执行模式下，任务会按照线性顺序逐一处理，同一代理的步骤会被优先处理。这种做法可能会导致后续任务的等待时间变长。

通过采用循环调度（Round-robin scheduling）等调度算法，可以优化任务处理过程。调度器通过并行交错执行不同代理的任务，显著改善了每个代理的等待时间和响应时间。这种并发处理方式通过时间线展示，不同代理的任务被交替处理，例如A1、B1、C1、B2、A2、A3、C2、C3，确保每个代理都能公平地使用处理资源，同时减少空闲时间。除了传统的调度算法，未来还可以引入更高级的调度算法，这些算法可以考虑代理请求之间的依赖关系，进一步提升调度效率。

上下文管理器

如上图所示，上下文管理器负责维护大语言模型Agent应用的上下文信息及其生成过程。它主要承担两项重要职责：上下文快照与恢复，以及上下文窗口的管理。

在处理过程中，可能会因为调度算法（如Round-Robin）的时间片操作而导致代理请求被暂停，即便LLM尚未完全生成回应。因此，需要一种机制来保存LLM生成过程中的当前状态，以确保在资源再次可用时能够精确地恢复。

AIOS的上下文管理器提供了快照和恢复功能，如上图所示。我们以beam search为例，这是一种在大语言模型Agent应用中常用的搜索算法，来展示生成性解码过程。为了简化说明，我们将beam width设定为1。例如，代理请求的任务是判断UA057航班目的地是否会下雨。LLM在每一步都会评估多个可能的候选选项，并根据设定的beam width保留最有希望的路径进行扩展。

当生成过程在某一中间步骤被调度器暂停时，上下文管理器通过快照功能捕获并保存LLM的beam search树的当前状态，包括所有正在探索的中间概率和路径。当生成过程恢复时，恢复功能将重新加载快照中保存的状态，使LLM能够从暂停的地方继续生成过程，直至得出最终答案：查询巴黎的天气。这样，上下文管理器确保了即使代理请求暂时中断，也不会造成工作进度的丢失，优化了资源利用，同时保证了响应生成的质量和效率。

此外，为了应对长上下文对LLM的上下文窗口限制带来的挑战，上下文管理器还需管理上下文窗口的潜在扩展。AIOS的上下文管理器支持基础文本摘要，并整合了其他扩展技术，以管理上下文窗口。这有助于提升LLM处理和理解长篇上下文的能力，同时确保信息的完整性和相关性得到保障。

内存管理器

上图展示了内存管理器的工作原理，内存管理器负责管理代理生命周期内的短期记忆，确保数据在代理活跃期间——无论是在等待执行还是执行过程中——都能被存储和访问。AIOS目前能够支持为每个代理独立保存其内存，且这些内存对于其他代理来说不是公开可访问的，除非得到了访问管理器的许可。

在未来，可以将更为复杂的内存管理机制，例如代理间共享的内存池或者层级缓存，融入到AIOS中。与后续将要提及的存储管理器相比，内存管理器能够提供更快速的数据检索和处理能力，这有助于迅速回应用户的查询和互动，同时也不会对AIOS的存储系统造成过重的负担。

存储管理器

相对而言，存储管理器承担着数据长期保管的职责，它负责管理那些需要永久保留的信息，这些信息的存留时间远远超过了单个代理应用的生命周期。AIOS通过本地文件、数据库以及云端解决方案等多种持久化存储方式，确保了数据的完整性与可获取性，以便于未来的查询或分析。存储管理器还能够通过增强检索功能，来提升数据检索的效率。它通过记录用户的偏好设置和历史交互记录，不仅丰富了代理应用的知识库，还提升了用户的长期体验。

工具管理器

在AIOS系统内，工具管理器负责维护一系列API工具，这些工具极大地提升了大语言模型Agent应用的功能性。参照上表，工具管理器汇集并分类了来自多个平台的常用工具，类别包括网页搜索、科学计算、数据库查询和图像处理等。通过这种方式，工具管理器提供的工具能够处理多种类型的输入和输出（如图像和文本），进而为AIOS生态系统中的代理应用开发提供了便利。

访问管理器

访问管理器通过为每个Agent分配一个专门的权限组，来调控Agent间的访问权限。不属于某个Agent权限组的其他Agent无法访问该Agent的资源，例如其交互历史记录。为了增加系统的透明度，访问管理器还会建立和保持审计日志，详细记录访问请求、Agent行为以及对访问控制设置的任何更改，从而有效预防可能的权限滥用攻击。

大语言模型调用接口

专门设计用于执行基本的LLM调用操作。该接口作为代理应用发出的复杂请求与内核各模块执行之间的桥梁。参考上表，就像操作系统的系统调用一样，LLM系统调用也提供了一系列基础功能，这些功能贯穿于内核的各个模块之中，涵盖了代理管理、上下文处理、内存与存储操作以及访问控制等方面。未来的LLM系统调用列表还有扩展的空间，以便增加对更多操作的支持。

AIOS SDK

AIOS的软件开发工具包（SDK）为开发者打造了一个强大的多功能工具集，用于在AIOS环境下开发高端代理应用。该工具包覆盖了从代理初始化、生命周期管理到资源监控和代理任务生成计划等复杂操作的全方位功能。正如操作系统的不断完善一样，不断丰富和优化SDK，使其更加全面、易用，是一项持续的工作。目前AIOS所支持的SDK功能如上表，未来将持续进行更新与扩展，以适应代理应用的发展需求。

性能比较

作者对比分析了三种Agent同时运行时采用先进先出（FIFO）调度的AIOS与无调度方式的差异。在无调度模式下，三个代理按照既定的顺序执行：首先是数学代理，然后是叙述代理，最后是推荐代理。我们使用等待时间和周转时间这两个指标来衡量时间效率：等待时间指从提交代理请求到开始处理的时间间隔，而周转时间则是从提交请求到完全处理完成的时间长度。由于每个代理都会向大语言模型Agent应用发送多个请求，因此计算每个代理的等待时间和周转时间时，我们取其所有请求的等待时间和周转时间的平均值。为了减少随机误差，我们对这三种代理在有调度和无调度的条件下各进行了五次独立测试，并报告了结果。上表显示，在无调度方式下，序列靠前的代理表现较好，但后续代理则面临更长的等待时间和周转时间。与此相反，AIOS的调度机制能够高效地平衡各个代理的等待和处理时间，对于晚些时候提交请求的代理，尤其是当大语言模型Agent应用规模较大时，这种优势尤为明显。这说明我们的调度机制对于处理多个代理的并行操作至关重要。

Arxiv^[1]

通往 AGI 的神秘代码

if like_this_article():
    do_action('点赞')
    do_action('再看')
    add_wx_friend('iamxxn886')

if like_all_arxiv_articles():
    go_to_link('https://github.com/HuggingAGI/HuggingArxiv')    star_github_repo(''https://github.com/HuggingAGI/HuggingArxiv')

引用链接

[1] Arxiv: https://arxiv.org/abs/2403.16971