有幸在《北京智源大会》的论文分享中，了解到这个有趣的工作。思路比较好，比较贴合工程同学理解落地，同时也在分享中，介绍了一些手段可以提高LLM进行Plan的质量。如今整理出来share给大家。
作者介绍
这篇文章的作者名单如下：
- Kai Mei - 罗格斯大学（Rutgers University）
- Zelong Li - 罗格斯大学（Rutgers University）
- Shuyuan Xu - 罗格斯大学（Rutgers University）
- Ruosong Ye - 罗格斯大学（Rutgers University）
- Yingqiang Ge - 罗格斯大学（Rutgers University）
- Yongfeng Zhang - 罗格斯大学（Rutgers University）
所有作者都隶属于罗格斯大学，这是一所位于美国新泽西州的著名公立研究型大学。罗格斯大学以其在多个学术领域的研究和教育成就而闻名，包括计算机科学、工程、社会科学和人文学科等。
作者们还开源了对应的代码，地址在这里，大家可以自取。
论文速览
这篇论文介绍了AIOS（LLM Agent Operating System），一个将大型语言模型（LLM）集成到操作系统中的智能代理操作系统。以下是该论文的主要创新点：
- 「LLM与操作系统的融合」：AIOS将LLM作为操作系统的“大脑”，提出了一个具有“灵魂”的操作系统，这是向通用人工智能（AGI）迈进的重要一步。
- 「资源分配优化」：AIOS设计了专门的模块来优化LLM的资源分配，提高代理请求的调度效率。
- 「上下文管理」：通过上下文管理器，AIOS能够在代理与LLM之间的交互中保持上下文，支持LLM生成过程中的快照和恢复，即使在LLM未完成当前请求的响应生成时也能暂停/恢复。
- 「并发执行支持」：AIOS允许多个代理并发执行，提高了资源的利用效率，并减少了瓶颈。
- 「工具服务管理」：AIOS提供了工具管理器，用于管理代理调用外部API工具，如搜索、科学计算等。
- 「访问控制」：AIOS通过访问管理器来执行代理之间的隐私和访问控制策略，确保了系统的安全性。
- 「模块化设计」：AIOS的架构包括应用层、内核层和硬件层，这种分层设计提高了模块化和简化了不同层之间的系统交互。
- 「LLM系统调用接口」：AIOS设计了LLM系统调用接口，使得代理可以透明地利用这些服务。
- 「AIOS SDK」：为了进一步封装LLM系统调用，AIOS设计了SDK，为代理开发者提供了更方便的代理库函数。
- 「实验验证」：论文通过实验验证了AIOS模块在并发执行多个代理时的可靠性和效率，展示了AIOS在提高LLM代理性能和效率方面的潜力。
- 「开源项目」：AIOS项目是开源的，这有助于社区的参与和生态系统的发展。
这些创新点展示了AIOS在设计和实现上的独特之处，旨在解决LLM代理集成和部署中的挑战，推动LLM技术在更广泛领域的应用。
看几个复杂的任务
这里我们可以看到有两个主体部分组成：指令 + 领域模型
在中间的Prompt部分，主要是用来描述让LLM的工作。
+ 先明确角色的扮演，具备可以Plan任务的能力
+ 明确可以使用工具（Tools），具体的Tools的名称和描述在Prompt中也有呈现
+ 明确任务：XXXXXX
LLM会先生成解决问题的Plan，然后根据Plan本身去执行，最终可以得到一个我们期望的输出（Report）。
「我们有几个发现」
- 生成这个Plan有一定的顺序性，也就是说，在执行的过程中是有顺序依赖的；
- 这个顺序依赖中，有一些是可以并行执行的，有一些是有一些上下文依赖的；
- Plan中的内容都是文本，缺少我们常见的函数调用中的函数名和函数参数等；
我们可以再来看一个例子。针对这个例子我们就不过多的赘述了。
LLM Based Agents
在论文中，Figure 1 展示了一个名为“Travel Agent”的LLM（大型语言模型）基础代理如何利用LLM和操作系统（OS）级别的资源及功能来完成用户提出的旅行计划任务。以下是该图的详细阐述：
-
「用户请求」：用户向代理提出了一个旅行计划的请求，即从旧金山飞往纽约进行下个月的商务旅行，并请求帮助组织行程。
-
「代理响应」：Travel Agent 理解了请求，并计划根据用户以往的偏好来安排行程。
-
「步骤分解」：
- 「偏好检索」：代理首先检索用户的旅行偏好。
- 「航班和酒店推荐」：基于用户的偏好，代理推荐航班和酒店。
- 「照片ID上传」：代理可能需要用户上传照片ID，用于身份验证或其他旅行文件。
- 「座位选择」：代理帮助用户选择飞机座位。
- 「添加票证到日历」：代理将旅行票务信息添加到用户的日历中，以便于用户管理和提醒。
- 「支付处理」：代理处理旅行相关的支付事宜。
- 「评论和提示」：代理提供旅行相关的评论和提示，可能包括旅行目的地的注意事项或建议。
-
「资源利用」：
- 「LLM存储」：代理在LLM存储中管理用户偏好和历史交互。
- 「工具API」：代理调用由LLM管理的工具API来执行特定任务，如搜索航班或酒店信息。
- 「磁盘存储」：操作系统管理的磁盘存储用于长期存储代理交互日志。
- 「软件」：操作系统负责执行软件服务，如日历应用或支付处理软件。
-
「功能管理」：
- 「文本生成」：由LLM管理的文本生成功能用于创建旅行建议和用户交互的回复。
- 「步骤1到步骤7」：每个步骤代表代理完成任务的不同阶段，展示了从理解用户请求到执行具体操作的完整流程。
Figure 1 通过这个例子，展示了LLM基础代理如何结合LLM的高级认知功能和操作系统的传统计算功能，以实现复杂任务的自动化和优化。这种协同作用不仅提高了任务执行的效率，还增强了用户体验。
几个显著的特征
- 可以生成Planning：将复杂的任务，拆解成比较小的可以解决的子问题 + 使用工具：可以主动的根据任务来选择任务解决相关的问题
这里我们就要使用这类经典的图片了哈～～～
Agents vs CoT Prompt
比较熟悉Prompt技术的同学应该很快就会想到，CoT等一些Prompt技术，主要的点在如何去生成高质量的、尽量完整的、可以让模型思考的提示词。最终还是期望LLM可以给出一些高质量的推断。
而Agents任务的重点在如何更高级的拆解任务，如何能让让LLM理解问题、理解任务、理解工具，完成特定的工作。可以理解为给模型添加一些外挂，让他自主帮我们解决问题。
如何确保任务的拆解？
论文：《OpenAGI： When LLM Meets Domain Experts》
让LLM来进行任务的拆解，一定是要需要去设计一些数据集来辅助评估模型的效果的。这里给出一个在图像领域上的一个数据集和实验工作。
「核心思想」
❝
文章中的图展示了OpenAGI平台处理基准任务的流程。具体内容包括：
- 「任务描述」：以自然语言形式给出的任务，例如“Restore noisy, low-resolutioned, blurry and grayscale images to regular images”（将嘈杂、低分辨率、模糊和黑白的图像恢复为常规图像）。
- 「指令LLM」：大型语言模型（LLM）接收任务描述，并生成一个解决问题的计划。
- 「计划执行」：根据LLM生成的计划，选择合适的领域专家模型（工具、模块、网络、插件或API）来执行任务。例如，使用图像去噪、去模糊、超分辨率和着色模型来处理图像。
- 「任务特定数据集」：为任务提供特定的数据集，用于模型的训练和测试。
- 「预测」：领域专家模型对输入数据进行处理，生成预测结果。
- 「评估」：通过与真实标签或通过人类评估比较，对LLM的计划执行结果进行评估。
- 「领域专家模型」：列出了用于任务的领域专家模型，包括图像去噪、去模糊、超分辨率、着色等。
- 「OpenAGI流程图」：展示了从接收任务描述到执行计划，再到评估结果的整个OpenAGI处理流程。
这个流程图说明了OpenAGI如何将自然语言任务转换为一系列可执行的步骤，并利用领域专家模型来解决问题，最后对结果进行评估，以实现自我完善和优化。
❞
「论文速览」
❝
文章标题：OpenAGI: When LLM Meets Domain Experts
作者：Yingqiang Ge, Wenyue Hua, Kai Mei, Jianchao Ji, Juntao Tan, Shuyuan Xu, Zelong Li, Yongfeng Zhang，均来自Rutgers University。
摘要：
本文介绍了一个名为OpenAGI的开源研究与开发平台，旨在解决现实世界中的多步骤复杂任务。OpenAGI结合了大型语言模型（LLMs）与特定领域的专家模型，以实现人工智能的通用性（AGI）。该平台采用了双重策略：一方面，它集成了标准基准任务用于评估和测试；另一方面，它也包括了开放式任务，这些任务可以扩展更多的模型、工具、插件或API，以促进创造性的问题解决。任务以自然语言查询的形式呈现给LLM，然后LLM选择并执行适当的模型。此外，作者提出了一种基于任务反馈的强化学习（RLTF）机制，该机制利用任务结果来提升LLM的问题解决能力，形成了一个自我完善的AI反馈循环。尽管AGI是一个广泛且多方面的研究挑战，没有单一定义的解决路径，但将LLM与特定领域的专家模型相结合，模仿人类将一般和专业智能结合的方式，为实现AGI提供了一个有希望的方法。作者开源了OpenAGI项目的代码、数据集、基准、评估方法和UI演示，以促进社区参与AGI的进步。
- 引言：
文章讨论了人类智能（HI）在结合基本技能解决复杂任务方面的能力，这种能力对于人工智能（AI）至关重要。作者提出，机器智能应该具备综合各种技能的能力，以形成解决复杂问题的复杂技能。在计算机科学中，每种技能都被称为一个领域专家“模型”，即具有定义功能的可重用工具、模块、网络、插件或API。领域专家模型可以综合成一个更大的“计划”，以执行更复杂的任务。作者指出，大型语言模型（LLMs）展示了出色的学习和推理能力，非常适合选择、综合和执行外部专家模型来解决复杂任务。- 相关工作：
文章讨论了LLMs和AI代理的最新进展，以及如何通过结合不同领域的知识和技能来推动通用人工智能（AGI）的发展。- OpenAGI平台：
详细介绍了OpenAGI平台的特点，包括其基准任务和开放式任务。基准任务配备了特定任务的数据集和评估指标，而开放式任务则允许更多的创造性和想象力，以探索可能在更受限的任务框架中不会出现的创新解决方案。- 基于任务反馈的强化学习（RLTF）：
提出了一种利用任务执行后的性能反馈来指导LLMs学习方向的方法。这种方法可以改善LLMs的策略，使其更加健壮和适应性强。- 实验：
展示了在不同学习模式下，使用OpenAGI管道评估各种LLMs的实验结果。结果表明，即使是规模较小的LLMs，当与适当的学习方法（如RLTF）结合使用时，也有可能超越参数数量大得多的模型。- 结论和未来工作：
文章总结了OpenAGI平台的主要贡献，并提出了未来的研究方向，包括人机协作、可信赖的代理以及自我完善的智能代理。❞
进一步保证Plan的质量？
论文：《Formal-LLM: Integrating Formal Language and Natural Language for Controllable LLM-based Agents》
「论文速览」
❝
「摘要」
论文提出了一个新的框架“Formal-LLM”，旨在通过整合自然语言的表达力和形式语言的精确性，提高基于大型语言模型（LLM）的智能代理的计划生成过程的可控性。该框架允许用户通过自动机来表达规划过程中的要求或约束，然后LLM在自动机的监督下生成计划，确保生成的计划满足约束条件。实验表明，该框架在基准任务和实际任务中提高了超过50%的整体性能，证明了其有效性。
- 引言
介绍了LLM在自动生成和执行多步骤计划以解决复杂任务方面的应用。然而，LLM生成的内容过程难以控制，导致生成的计划可能无效或不可执行。为了解决这个问题，提出了Formal-LLM框架。
- 相关工作
讨论了LLM基础的AI代理和可控LLM生成的相关研究。
- 预备知识
介绍了上下文无关文法（CFG）和下推自动机（PDA），这些是构建Formal-LLM框架的基础。
- Formal-LLM框架
详细描述了框架的动机和挑战，如何将约束转化为自动机，以及如何使用自动机指导LLM进行规划。
- 实验
展示了在不同LLM上测试Formal-LLM框架的结果，包括闭源和开源LLM，以及在基准任务和实际任务上的性能。
- 结论和未来工作
总结了Formal-LLM框架的贡献，并提出了未来可能的研究方向。
附录：包含了基准任务和工具的列表、实现细节、提示示例以及实际任务的完整结果。
论文的主要贡献在于提出了一种新的方法来提高LLM代理在生成计划时的可控性，通过形式化约束来确保计划的有效性和可执行性。论文还提供了一个开源的实现，供研究社区进一步探索和改进。
❞
**「其实，我个人理解这个事情，就是要用一种可以编译的语言来对LLM的指令进行编译。也就是说要去设计一个LLM的指令的语法，这个语法有一个解析器，后续可以针对这个进行优化。**论文作者的主要贡献就是指令的有限状态机设计，但是设计还不是自动化的，可以进行改进。」
向多个Agents迈进
这一步也是上面可以Plan之后的一个必然，如果我们的任务在完成拆分后，就可以清晰的知道哪些子任务之间是有一定的依赖的。这样我们就可以把任务拆成一个图，在这个图中的非依赖路径的内容是可以并行操作的，如果需要并行处理不同的事情的话，其实就是要多个Agents一起运行了。
一个有趣的例子
论文：《War and Peace (WarAgent): LLM-based Multi-Agent Simulation of World Wars》
这里我们可以看到不同的Agent之前的交互式非常复杂的。如果想去复现这些场景实验在工程上需要耗费大量的工作的。
多Agents交互带来的麻烦
大家执行分析上图，可以看看 Agent 之间交互的情况如何？这就变成了一个复杂的网络交互问题。
分享的嘉宾试图在用OS的架构来解决Agent间通信和调度的问题。
LLM Agent Operation System（AIOS）
我们来类比下大家熟悉的OS，可以一起看下AIOS有哪些部分。这里就不一一赘述了。码字太累～～～
AIOS Architecture
在论文中，Figure 2 提供了AIOS（LLM Agent Operating System）架构的概览。以下是该图的详细描述：
-
「应用层（Application Layer）」：
- 包含各种代理应用程序，如旅行代理（Travel Agent）、数学代理（Math Agent）和编程代理（Coding Agent）。
- AIOS提供AIOS SDK，为代理开发人员提供系统调用的更高抽象，简化开发过程。
-
「内核层（Kernel Layer）」：
-
分为操作系统内核（OS Kernel）和LLM内核（LLM Kernel）。
-
「OS Kernel」：处理非LLM特定的操作，如进程调度和硬件驱动。
-
「LLM Kernel」：专注于LLM特定的任务，如上下文管理和代理调度。它包括以下模块：
- 「Agent Scheduler」：优先级排序和调度代理请求以优化LLM的使用。
- 「Context Manager」：管理LLM提供的上下文和生成过程，包括上下文快照和恢复，以及上下文窗口管理。
- 「Memory Manager」：为每个代理的交互日志提供短期记忆。
- 「Storage Manager」：将代理交互日志持久化到长期存储中，以便将来检索。
- 「Tool Manager」：管理代理调用外部API工具（例如搜索、科学计算）。
- 「Access Manager」：在代理之间执行隐私和访问控制策略。
-
-
「硬件层（Hardware Layer）」：
- 包括系统的物理组件，如CPU、GPU、内存、硬盘和外围设备。
- LLM内核的系统调用不直接与硬件交互，而是通过OS的系统调用来管理硬件资源。
-
「LLM系统调用接口（LLM System Call Interface）」：
- 提供基本的LLM调用操作功能，作为复杂代理请求和不同内核模块执行之间的桥梁。
-
「OS系统调用接口（OS System Call Interface）」：
- 允许LLM内核通过操作系统内核与硬件层进行交互。
-
「代理间的交互」：
- 展示了非LLM相关调用和LLM相关调用，说明了不同代理如何利用AIOS提供的服务。
Figure 2 通过展示AIOS的三层架构，阐明了如何将LLM的强大功能与操作系统的资源管理能力结合起来，以支持复杂任务的自动化和优化。这种设计使得AIOS能够高效地管理和协调LLM代理的活动，同时确保系统的安全性和模块化。
对比看下计算机操作系统的发展路径，更好的理解下LLM OS的发展路线。
Agent Scheduler
在论文中，Figure 3 旨在阐释AIOS（LLM Agent Operating System）中的代理调度器（Agent Scheduler）如何优化多个代理（Agent）请求的处理。以下是该图的详细描述：
-
「代理和执行步骤」：
- 图中用字母A、B、C代表不同的代理，每个代理有多个执行步骤（例如A1、A2、B1等），这些步骤代表了代理需要执行的任务或请求。
-
「顺序执行（Sequential Execution）」：
- 在顺序执行模式下，代理任务按照它们到达的顺序依次处理。这意味着来自同一代理的步骤会连续执行，而其他代理的任务则需要等待当前代理的所有步骤完成后才能开始执行。
- 这种模式可能导致后续排队的代理任务等待时间较长，因为它们必须等待前面的代理任务全部完成后才能开始执行。
-
「并发执行（Concurrent Execution）」：
- 与顺序执行相对，代理调度器采用并发执行策略，通过交错执行不同代理的任务来优化等待时间和周转时间。
- 并发执行模式下，不同代理的任务可以相互交错执行，例如：A1、B1、C1、B2、A2、A3、C2、C3。这种执行方式可以减少任何单个代理对处理资源的垄断，同时最小化空闲时间。
-
「调度策略」：
- 图中提到了几种可能的调度算法，如先进先出（FIFO）和轮询（Round Robin，RR）。这些算法用于优化代理请求的处理顺序。
- 代理调度器可以根据这些算法来决定任务的执行顺序，以提高整体的系统效率和响应速度。
-
「调度器的作用」：
- 代理调度器的主要目标是平衡每个代理的等待时间和周转时间，确保系统资源得到合理分配，避免某些代理因等待而造成延迟。
Figure 3 通过对比顺序执行和并发执行两种模式，展示了AIOS中代理调度器如何通过采用不同的调度策略来提高多代理系统的性能和效率。这种设计使得系统能够更好地处理大量并发的代理请求，同时保持响应速度和资源利用率。
Context Manager
在论文中，Figure 4 展示了AIOS（LLM Agent Operating System）中的上下文管理器（Context Manager）如何处理和维护大型语言模型（LLM）在生成响应过程中的上下文快照和恢复。以下是该图的详细描述：
-
「上下文快照和恢复的需求」：
- 当LLM在处理代理请求时，可能会因为调度器的时间片操作（例如轮询调度）而被暂停，即使此时LLM尚未完成对当前请求的响应生成。
- 为了确保暂停后的请求能够从暂停点准确恢复，上下文管理器需要捕获并保存LLM当前的生成状态。
-
「Beam Search 过程」：
- 图中以Beam Search（束搜索）为例来说明LLM的生成解码过程。Beam Search 是LLM中常用的一种搜索算法，用于从多个可能的候选中选择最优的响应。
- 为了简化说明，图中将束宽度（beam width）设置为1，意味着在每一步中，LLM只考虑单一最有可能的候选路径进行扩展。
-
「上下文快照（Snapshot）」：
- 当LLM的生成过程被调度器暂停时，上下文管理器会使用快照功能来捕获并存储当前LLM的束搜索树状态，包括所有正在探索的中间概率和路径。
-
「上下文恢复（Restore）」：
- 当LLM的生成过程恢复时，上下文管理器使用恢复功能来重新加载之前保存的状态，允许LLM从暂停点继续其生成过程。
-
「具体示例」：
- 图中给出了一个代理请求的例子：“Determine whether there will be a rain in the destination of flight UA057.”（确定航班UA057目的地是否会下雨。）
- LLM在处理这个请求时，上下文管理器在不同的时间点进行了快照和恢复操作，以确保即使在暂停和恢复过程中，也能准确完成最终的响应：“Search weather in Paris.”（搜索巴黎的天气。）
Figure 4 通过展示上下文管理器的快照和恢复机制，强调了在多代理并发执行环境中，如何有效地维护和恢复LLM的生成状态，以确保响应的连续性和完整性。这种机制对于提高LLM代理在处理复杂任务时的效率和可靠性至关重要。
这里主要的点在于如何工程化解决个性化和记忆的问题，这部分不是特别复杂，相信在工程中会有自己特定的方法的。
几点展望
如果LLM OS（大型语言模型操作系统）能够实现，它将为人工智能领域带来一系列深远的好处和变革。以下是一些可能的展望：
-
「更高效的资源管理」：
- LLM OS可以优化计算资源的分配，使得大型语言模型能够更高效地处理并发请求，减少等待时间，提高整体的系统性能。
-
「上下文保持和恢复」：
- 通过上下文管理器，LLM OS能够保持用户交互的连续性，即使在处理过程中发生中断，也能准确恢复上下文，提供流畅的用户体验。
-
「增强的多任务处理能力」：
- 操作系统级别的支持将使得多个代理能够同时运行，每个代理可以专注于其特定的任务，同时操作系统协调它们之间的交互，实现更复杂的多任务处理。
-
「简化的代理开发」：
- AIOS SDK将提供一套丰富的工具和库，使得开发者能够更容易地创建和部署LLM代理，无需深入了解底层的复杂性。
-
「提升的安全性和隐私保护」：
- 通过精细的访问控制和隐私保护措施，LLM OS能够确保用户数据的安全，防止未授权访问和数据泄露。
-
「促进人工智能的普及」：
- 随着LLM OS的实现，更多的人将能够接触和利用大型语言模型的强大功能，推动人工智能技术的普及和应用。
-
「跨领域的应用拓展」：
- 操作系统级别的集成将使得LLM能够更容易地应用于不同领域，如医疗、法律、教育和娱乐等，带来行业变革。
-
「促进人机交互」：
- LLM OS将使得机器更能理解人类的语言和指令，极大地提升人机交互的自然度和效率。
-
「推动自动化和创新」：
- 高效的LLM代理可以自动化许多复杂的任务，释放人类从事更有创造性和战略性工作的能力。
-
「支持持续学习和适应」：
- 随着时间的推移，LLM OS可以持续学习和适应新的数据和场景，不断优化其性能和响应能力。
-
「促进多代理协作」：
- 在多代理系统中，LLM OS可以协调不同代理之间的合作与竞争，实现更复杂的群体智能行为。
-
「提高系统的可扩展性」：
- LLM OS的设计允许系统轻松扩展，以适应不断增长的计算需求和更大规模的部署。
实现LLM OS将是一个复杂的过程，涉及多学科的合作和技术的创新，但其潜在的好处是巨大的，可能会彻底改变我们与机器交互的方式。
本文使用 markdown.com.cn 排版
