详解5个最需要了解的AI多智能体编排框架,你将如何选择?【上】

大模型向量数据库云通信

picture.image

CAMPING

点个蓝字关注我们

picture.image

在生成式AI的应用领域,多智能体系统(Multi-Agent System)展示了巨大的发展潜力,但同时也具有较大的复杂性,因此也涌现出众多用于多智能体编排与开发的独立框架。最近OpenAI公司也出人意料的发布了一个实验性的多智能体编排框架Swam,有理由相信多智能体系统将在未来的AI应用领域扮演越来越重要的角色。

picture.image

我们将对当前五个重要的多智能体编排框架做详解与比较,帮助大家深入认识多智能体系统及其开发。本篇为第一篇:

  • 认识多智能体系统
  • 多智能体编排及5个常见框架
  • 之一:OpenAI的Swam

01

认识多智能体系统

多智能体系统(Multi-Agent System) 允许你把复杂的工作任务分解并交给多个承担特定角色的AI智能体来共同完成,这种方式拓展了单个智能体所能实现的可能性,并被证明可能产生更高质量、更快与更值得信赖的结果。比如一个AI软件公司,可能包括了PM、架构师、程序员等多个AI智能体角色:

picture.image

多智能体系统已经成为AI智能体发展的重大内驱力,具备了一些独特优势:

  • 分工协作: 每个智能体可以做针对性的设计(如采用特别的模型),以专注在更适合自己的特定任务并实现协作,有助于提高任务完成质量。

picture.image

picture.image

比如,一个常见的方法是在多个智能体系统中安排“验证”或“审查“的角色,对其他智能体的工作成果进行反思、质检与改进。

picture.image

  • 并行处理: 某些场景下多个智能体可以并行执行子任务,缩短任务时间。
  • 过程更透明: 多智能体系统的工作流编排让智能体之间的交互与推理更透明,增强了AI输出的可解释性,更好的呈现集体决策的过程。
  • 灵活性与扩展: 多智能体系统更易于做局部动态调整与扩展,以适应业务变化。
  • 容错性: 必要时可以设计多智能体之间的任务转移,提高系统整体可用性。

02

多智能体编排及5个常见框架

当开始构建一个多智能体系统,你首先需要考虑的核心问题就是如何编排你的 多智能体工作流 。包括:

  • 规划可能需要的智能体角色与组织结构。

  • 明确每个智能体角色的能力、知识和任务职责。

  • 编排多个智能体的协同工作流程,确保完成共同的任务目标

这是多智能体系统的关键设计步骤。你需要确定多个智能体之间如何通信与协作;哪些智能体可以把任务委派给其他智能体;哪些智能体可以并行执行任务,哪些智能体任务则需要串行;是需要一个管理智能体来统一委派任务,还是依靠智能体之间的对话来实现任务分配等。

picture.image

多个智能体可能存在多种协作关系

  • 设计优化多智能体的工作性能,以更好更快的完成任务。
  • 针对不同的任务,选择不同能力甚至不同领域的模型驱动。

通常我们会借助成熟的多智能体开发框架来完成这样的编排工作。 这不仅是帮助减少开发工作量,更重要的是借助框架设计良好的组件与范式,以提升多智能体系统的灵活性、适应性与弹性。

我们将重点介绍以下五个常见的多智能体编排框架(通常也是完整的AI智能体开发框架):

  • OpenAI的Swam

最近推出的来自OpenAI公司的实验性框架,因为OpenAI而受到关注。

  • Microsoft的AutoGen

来自微软公司强大的智能体开发框架,从出生就是面向多智能体系统开发,其主要特点是通过智能体对话实现交互与协作。

  • LangChain的LangGraph

著名的LangChain在2024年初推出的独立框架,主要面向复杂的RAG与Agent应用开发,特点是用Graph结构来设计与表示工作流。

  • Crew.AI的CrewAI

另一个强大的多智能体编排框架,采用基于角色扮演的多智能体设计,提供简洁的智能体、工具与任务的定义,以及多种协同模式。

  • LlamaIndex的Workflows

另一家流行的LLM框架LlamaIndex推出的面向复杂RAG与Agent工作流开发的新特性,与LangGraph的最大区别是采用动态的事件驱动架构。

接下来我们对这五个框架的编排能力与方式做演示与对比,以帮助开发者在项目中决策适合自己的工具。

picture.image

picture.image

  • 由于我们关注的重点是多智能体之间的协作编排,而非单个智能体的内部工作流,所以对单个智能体会尽量简单的模拟实现。

  • 不同的框架是可以协作使用的, 比如把LangGraph开发的单个智能体利用Swam与其他智能体编排到一起。

picture.image

03

多智能体编排之OpenAI Swam

后续的介绍中我们都将以一个简单的Supervision协作模式的多智能体工作流为例。在这种模式中,一个监管者Agent负责调度多个Agent共同完成任务:

picture.image

【关于OpenAI Swam】

客观说,Swam是这些框架中最轻量级,但也是功能最弱的一个,之所以放在第一个介绍,源自于OpenAI在AI领域强大的影响力。相比于其他的多智能体框架,其最大的特点是:

  • 功能极简,没有多余功能
  • 学习与使用非常简单
  • 灵活性与客户化能力较差
  • 暂时只支持OpenAI模型(可借助第三方项目支持ollama)
  • 还处于实验性阶段
  • 无社区支持(太简单,一般也用不上)

【核心概念】

Swam的几个核心概念包括 Agents (智能体), handoffs (转交)与 context_variables (上下文变量)。

Agents:

也就是智能体。在Swam中,智能体其实是对OpenAI模型与Function Calling特性的简单封装与抽象。可以认为:

Agent=Instruction(指令) + LLM(如gpt-4o) + Functions

Handoffs:

交接是Swam中实现编排的重点,用来把会话转交给另一个智能体,从而达到多个智能体协作的目的。其本质是一个转移函数,返回值是需要转交的目的智能体;并把转移函数作为源智能体的一个Function提供,由其在必要的时候调用以实现转接:

picture.image

context_variables:

用于在用户输入、多个Agent之间传递上下文,类似于LangGraph中的State。比如你可以在输入时传入用户名称,并在后续Agent中读取它。

【测试用例实现】

现在使用swam来实现上面的测试用例。

首先定义两个简单的工具,一个是网络搜索(借助Tavily的API),一个是邮件发送(模拟);然后定义两个Agent分别使用这两个工具;最后创建一个supervisor角色的Agent,这是一个分派者,暂时不分配任何实质工具:


          
from swarm import Agentfrom langchain_community.tools.tavily_search import TavilySearchResultsdef search_web(query: str) -> str:    """用于搜索网络信息"""    search = TavilySearchResults(max_results=3)    results = search.invoke(query)    return "\n".join([r["content"] for r in results])
          
#这里演示context_variables用法def mail_tool(context_variables, subject: str, body: str,recipient: str = None) -> str:    """用于发送邮件"""    recipient = recipient or context_variables["email"]     print(f"开始发送邮件,收件人:{recipient},主题:{subject},内容:{body}")    return f"Sent email to {recipient} with subject '{subject}' and body '{body}'"search_agent = Agent(    name="Search Agent",model='gpt-4o-mini',     instructions="你是一个可以回答用户问题和搜索网络信息的AI助手。",    functions=[search_web]    )mail_agent = Agent(    name="Mail Agent",model='gpt-4o-mini',    instructions="你是一个可以发送邮件的AI助手。",    functions=[mail_tool]    )supervisor_agent = Agent(    name="Supervisor Agent",model='gpt-4o-mini',    instructions="评估用户问题并拆分任务,判断需要的第一个AI助手",parallel_tool_calls=False    )
      

接下来,需要编排三个Agent之间的关系,如上文介绍,创建三个handoff函数以实现转接功能,并把函数添加到已有Agent的工具箱(functions)即可。

注意这里我们让supervisor_agent可以把任务转交给search_agent或者mail_agent,但Search_agent与mail_agent之间不能互相转交,而只可以转交回supervisor_agent:


        
            

          def transfer\_back\_to\_triage():  
    """如果用户的问题超出当前AI助手的能力范围,则将其转回给主管理AI"""  
    return supervisor\_agent  
  
def transfer\_to\_search():  
    """将问题转交给搜索AI助手处理"""  
    return search\_agent  
  
def transfer\_to\_mail():  
    """将问题转交给邮件AI助手处理"""  
    return mail\_agent  
  
supervisor\_agent.functions = [transfer\_to\_search, transfer\_to\_mail]  
search\_agent.functions.append(transfer\_back\_to\_triage)  
mail\_agent.functions.append(transfer\_back\_to\_triage)
        
      

OK,现在就已经完成了全部代码。

【效果测试】

来做个简单测试,可以借助OpenAI提供的run_demo_loop方法,输入起始的Agent与上下文即可:


        
            

          from swarm.repl import run\_demo\_loop  
if \_\_name\_\_ == "\_\_main\_\_":  
    run\_demo\_loop(supervisor\_agent, stream=False, context\_variables={"email": "John@example.com"})
        
      

一起看下最终的效果:

picture.image

这里看到:

在第一个任务中:监管Agent把任务转交给了Search Agent,并由它输出了最终任务结果;

在紧接着的第二个任务中:由于之前已经切换到了Search Agent,因此首先它会把任务转交回监管者(transfer_back_to_triage);然后再由监管者重新转交给Mail Agent,并完成任务;

再来一个相对复杂的任务要求:

picture.image

这个任务要求连续的使用两个Agent协作完成任务,图中的彩色字清晰的显示了内部的任务转交过程。

【总结】

以上基本就是Swam的全部了,非常简单。存在的不足是:

  • 可定制化程度较低,对于复杂的工作流可能难以胜任
  • 较依赖于大模型自身的推理能力实现协作,存在较大不确定性
  • 单个智能体的开发支持弱,需要借助其他框架。

尽管如此,Swam简单易用的特性却也给一些业务复杂度不高,同时又需要整合大量独立任务与指令的智能体应用提供了另一种可能性。它提供了非常简洁的抽象帮助实现创建Agent、工具、提示与工作流,且Swam的源代码也非常易懂,也完全可以根据自身需要做深度定制。

在下一篇中,我们将对比介绍同一案例在其他框架中的实现。

picture.image

实测|基于多模态嵌入的AI搜索与RAG应用实现,释放企业数据真正价值

实操|如何优雅的实现RAG与GraphRAG应用中的知识文档增量更新?

当LangGraph遇上Mem0:如何让你的AI Agent具有更智能的记忆与个性化的体验?

关于生成式AI与大模型在企业端的应用:决策者应该了解的8个重要事实

picture.image

END

关注我,不迷路

交流请识别以下名片

picture.image

0
0
0
0
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论