化妆品网站建设网站,惠州网站关键字优化,网络营销推广处点,循化网站建设公司引言
这是一篇有意思的论文AIOS: LLM Agent Operating System#xff0c;把LLM智能体(代理)看成是操作系统。
基于大语言模型(LLMs)的智能代理的集成和部署过程中存在着许多挑战#xff0c;其中问题包括代理请求在LLM上的次优调度和资源分配#xff0c;代理和LLM之间在交互…引言
这是一篇有意思的论文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 较大时这一好处尤为显著。
6. 结论
本文提出了AIOS架构展示了促进基于LLM的代理开发和部署的潜力培育了一个更协调、有效和高效的AIOS-Agent生态系统。
总结
⭐ 作者借鉴操作系统的知识把LLM多智能体的协作看成是一个操作系统包括短期的内存(记忆)管理器和长期的存储管理器、智能体调度器、访问管理器等。
