rag 多智能体

随着大型语言模型（LLM）的出现，以LLM为核心构建的Agent系统近期受到了广泛关注。Agent系统旨在利用LLM的归纳推理能力，为不同的Agent分配角色和任务信息，并配备相应的工具插件，以完成复杂的任务。目前，更常见的框架主要集中在单Agent场景下。单Agent的核心在于LLM与工具的协同配合。LLM根据用户任务的理解，推理出需要调用的工具，并根据调用结果向用户提供反馈。在任务完成过程中，Agent可能需要与用户进行多轮交互。与此同时，越来越多的Agent框架开始关注多Agent场景。为了完成任务，多Agent会为不同的Agent指定不同的角色，并通过Agent之间的协作来完成复杂的任务。与单Agent相比，在任务完成过程中，与用户的交互可能会减少一些。[heading2]主要组成部分[content]为构建一个多Agent框架，我们需要思考相对于单Agent，框架中增加了哪些组件。环境（environment）：所有Agent应该处于同一个环境中。环境中包含全局状态信息，Agent与环境之间存在信息的交互与更新。阶段（stage）：为了完成复杂任务，现有多Agent框架通常采用SOP思想，将复杂任务分解为多个子任务。控制器（controller）：控制器可以是LLM，也可以是预先定义好的规则。它主要负责环境在不同Agent和阶段之间的切换。记忆：在单Agent中，记忆只包括用户、LLM回应和工具调用结果等部分。而在多Agent框架中，由于Agent数量增多，导致消息数量增多。同时，每条消息可能需要记录发送方、接收方等字段。

[title]突发！OpenAI官方开源多智能体框架「Swarm」[heading1]为啥用Swarm的多智能体脚趾头：因为是OpenAI出的。（君不见现在大多数大模型都在遵循OpenAI的接口规范...他们对自己做的东西更了解）脑门：其实单Agent这块，没有啥花里胡哨的东西，简单业务，OpenAI就一个/api/completions接口。但是「Handoffs」这块，Swarm的确做的非常优雅。（这里不得不给自己吹个牛，年初我就写了Swarm类似的多智能体了。）多智能体的核心难题其实是不同智能体之间的通信问题。怎麼传递，传哪些信息，这些都很重要。其实之前很多多智能体开源框架，走的都是Room/Group的思路，就是把各个智能体都扔到一个大空间里，然后每个智能体都接收信息，每个智能体都存储信息。不说效率低下，光token的消耗都扛不住。实际上，多智能体，也只要在必要的时候被call起就可以，回到我们上文10086客服的例子。当接线小姐姐识别到这是个宽带问题需要转接的时候，她需要做2个事情：1.找到宽带部门的小姐姐，把会话权限交接过去；2.把记录「Messages」和我的问题「Query」交接过去（实际上会自动记录，共享查阅）那如果我们需要构建这样的一个客服多智能体，是不是只需要准备两个Agent：一个普通接线客服，一个宽带客服。Swarm的「Handoffs」处理了交接的逻辑。下面我用官方的例子魔改一下客服例子，方便大家理解。执行这段代码，打印出来的对话记录就可能会是是不是就变得非常清晰了？总得来说就是：

[title]AI智能体：企业自动化的新架构- Menlo Ventures[heading3]轨道上的智能体人我们下一类要研究的智能体是轨道智能体。与决策智能体相比,轨道智能体被赋予了更高级的目标(例如,"将此发票与总账调节"、"帮助客户解决登录问题"、"重构此代码"),并赋予了更多自由度来选择实现这些目标的方法和工具。与此同时,这些智能体仍受程序性知识的指导,了解组织期望智能体如何执行(以自然语言编写的规则手册或说明手册表示的"轨道")；拥有预定义的工具,可在外部软件系统中执行一组操作；并受到防止幻觉的保护栏和其他审查措施的约束。在运行时，这种设计可能会产生以下模式:规划智能体评估应用程序相对于手册（即当前位于DAG中的哪个节点）的当前状态,并检查从该节点开始的所有动作链。智能体人选择并执行最佳链条。每个链条可能包括预定义为代码的预写操作,或者甚至包括可执行特定任务的额外智能体人,包括传统的RAG。在采取任何行动之前,该系统都会进行审查和确保一致性和一致性的护栏规划智能体根据规则手册评估新状态,并重复该过程——从有向无环图中的新节点中选择最佳链来再次执行。请注意,这种架构为之前的设计增加了另一层复杂性,这可能需要额外的数据基础设施支持,包括持久化执行、状态和内存管理(包括情节性、工作和长期记忆)、多智能体协调以及防护机制。