弁言
这是一篇有意思的论文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多智能体的协作当作是一个操纵系统，包括短期的内存(记忆)管理器和长期的存储管理器、智能体调度器、访问管理器等。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
