❝ 本文译自LangGraph: Multi-Agent Workflows一文,Mixtral 8x7B让AI圈见识到了混合专家模型的威力,那么随着LangGraph的发布,众多应用开发者也能在应用层随心搭建自己的多专家模型了。
❞
上周,我们重点介绍了LangGraph- 一个新的包(同时提供Python 和 JS 版本),用于更好地支持包含循环的LLM工作流的创建,循环是大多数代理运行时的关键组成部分。作为发布的一部分,我们强调了两个简单的运行时:一个等效于 LangChain
中的AgentExecutor,另一个是针对消息传递和聊天模型的该版本。
今天,我们很高兴强调 LangGraph
的第二组用例-多代理工作流。在这篇博客中,我们将介绍:
- “多代理”是什么意思?
- 为什么“多代理”工作流很有趣?
- 使用LangGraph进行多代理工作流的三个具体示例
- 基于LangGraph使用多代理工作流构建的两个第三方应用程序示例(GPT-Newspaper和CrewAI)
- 与其他框架(Autogen和CrewAI)的比较
什么是“多代理”?
💡
当我们谈论“多代理”时,我们谈论的是
- 「1.多个独立的演员」
- 「2.由语言模型提供动力」
- 「3.以特定方式连接」
每个代理都可以拥有自己的提示、LLM、工具和其他自定义代码,以便与其他代理最好地协作。
这意味着在考虑不同的多代理工作流时有两个主要注意事项:
- 「1. 多个独立代理是什么?」
- 「2. 这些代理是如何连接的?」
这种思维非常适合图形式的表示,例如 LangGraph
提供的表示。在这种方法中,每个代理都是图中的一个节点,它们的连接表示为边。控制流由边管理,它们通过向图的状态添加内容来进行通信。
注意:一个非常相关的概念是**「状态机」** 的概念,我们明确地将其称为认知体系结构的一类。从这个角度来看,独立的代理节点变成了状态,这些代理是如何连接的就是过渡矩阵。[由于状态机可以看作是一个标记的、有向的图](https://www.cs.cornell.edu/courses/cs211/2006sp/Lectures/L26-MoreGraphs/state\_mach.html?ref=blog.langchain.dev#:~:text=State machine as a graph,labeled with the corresponding events.),我们将以相同的方式考虑这些事情。
多代理设计的优点
“如果一个代理无法很好地工作,那么为什么多代理有用?”
- 分组工具/职责可以产生更好的结果。代理更有可能在专注的任务上成功,而不是必须从几十个工具中选择。
- 分开的提示可以产生更好的结果。每个提示都可以有自己的说明和少量示例。每个代理甚至可以由单独微调的LLM提供动力!
- 有助于开发的概念模型。您可以单独评估和改进每个代理,而不会破坏更大的应用程序。
多代理设计允许您将复杂的问题分解为可以由专业代理和LLM程序目标的可管理工作单元。
多代理示例
我们已经向 LangGraph
存储库添加了三个独立的多代理工作流示例。这些示例对上述两个问题的回答略有不同,我们将在重点介绍示例时介绍这些回答。需要注意的是,我们可以强调的这三个示例只是我们可以强调的可能示例的一小部分——肯定还有其他示例,我们期待看到社区提出的内容!
多代理协作
「代码链接」 :
- Python
- JS
在此示例中,不同的代理在**「共享」** 的讯息草稿上进行协作。这意味着他们所做的任何工作对另一方都是可见的。这的好处是其他代理可以看到所有单独的步骤。这的缺点是有时这些信息的传递显得过于冗长和不必要,有时只需要代理的最终答案就足够了。我们称之为**「协作」** ,因为该草稿的共享性质。
「多个独立代理是什么?」
在这种情况下,独立代理实际上只是单次LLM调用。具体来说,它们是特定的提示模板(以特定方式格式化输入,并包含特定的系统消息)以及LLM调用。
「这些代理是如何连接的?」
以下是这些代理的连接方式的可视化:
img
主要控制状态转换的因素是**「路由器」** ,但它是一个基于规则的路由器,因此相当简单。基本上,在每次LLM调用之后,它会查看输出。如果调用了工具,则调用该工具。如果没有调用工具且LLM响应“最终答案”,则返回给用户。否则(如果没有调用工具且LLM未响应“最终答案”),则转到另一个LLM。
代理主管
「示例:」
- Python
- JS
在此示例中,连接了多个代理,但与上述相比,它们没有共享草稿。相反,它们有自己的独立草稿,然后它们的最终响应会附加到全局草稿上。
「多个独立代理是什么?」
在这种情况下,独立代理就是LangChain代理。这意味着它们有自己的个性化提示、LLM和工具。调用时,不仅仅是单次LLM调用,而是AgentExecutor的运行。
「这些代理是如何连接的?」
「代理主管」 负责路由到各个代理。
img
通过这种方式,主管也可以被视为一个代理,其工具是其他代理!
分层代理团队
「示例:」
- Python
- JS
这与上述示例类似,但是现在节点中的代理实际上是其他 LangGraph
对象本身。这比使用LangChain AgentExecutor作为代理运行时提供了更多的灵活性。我们将其称为分层团队,因为子代理在某种程度上可以被视为团队。
「多个独立代理是什么?」
这些现在是其他 LangGraph
代理。
「这些代理是如何连接的?」
一个主管代理将它们连接在一起。
img
视频演示
我们添加了一个视频来演示这三个示例。希望这有助于让这些复杂的主题更容易理解!
第三方应用程序
作为此次发布的一部分,我们也很高兴突出显示一些基于LangGraph构建并利用多个代理概念的应用程序。
GPT-Newspaper
这是GPT-Researcher构思的一个新项目。 GPT-Newspaper是一个创新的自治代理,旨在创建根据用户偏好定制个性化报纸。 GPT Newspaper通过利用AI的力量根据个人口味和兴趣策划、撰写、设计和编辑内容,从而革新了我们消费新闻的方式。 该体系结构由六个专门的子代理组成。 有一个关键步骤-作家<>评价循环,这增加了一个有用的循环。
img
Crew AI示例
Joao Moura 搭建了一个很棒的示例,展示了如何使用 CrewAI 与 LangChain 和 LangGraph 自动处理电子邮件并创建草稿。 CrewAI 协调自治 AI 代理,使他们能够高效协作和执行复杂任务。
该图中的示例如下所示:
img
他还制作了一个精彩的视频来展示这一点。
其他框架
LangGraph 不是最早支持多代理工作流的框架。市面上多代理工作流框架之间的主要区别在很大程度上存在于它们引入的心智模型和概念中。
Autogen
Autogen被视为最早的多代理框架。 LangGraph 和 Autogen 之间心智模型最大的区别在于代理的构建方式。 LangGraph 更喜欢一种方法,其中明确定义不同的代理和转换概率,并将其表示为图形。 Autogen 将其表示为更像“对话”。 我们认为这个“图”框架使其在构建更复杂和更有见地的工作流程时更具直观性和更好的开发人员体验,在这些工作流程中,您真正想要控制节点之间的转换概率。 它还支持不明确归入“对话”范畴的工作流程。
LangGraph 和 Autogen 之间的另一个关键区别是 LangGraph 完全集成到了 LangChain 生态系统中,这意味着您可以充分利用 LangChain 的所有集成和 LangSmith 可观察性。
CrewAI
我们要突出的另一个关键框架是 CrewAI。 CrewAI 最近出现为一种流行的方式来创建多代理“团队”。 与 LangGraph 相比,CrewAI 是一个更高级别的框架。 事实上,我们正在与 CrewAI 团队积极合作,将 LangGraph 集成到 CrewAI 中! 我们认为 CrewAI 到达了一个**「很棒的」** 更高级别的 DevEx,我们希望支持这一点。
今天的内容就到这里,如果老铁觉得还行,可以来一波三连,感谢!
PS
:
AI小智技术交流群(技术交流、摸鱼、白嫖课程为主)又不定时开放了,感兴趣的朋友,可以在下方公号内回复:666,即可进入。
老规矩
,道友们还记得么,
右下角的 “在看” 点一下
, 如果感觉文章内容不错的话,记得分享朋友圈让更多的人知道!