跳到内容

多智能体系统

一个智能体一个使用LLM来决定应用程序控制流的系统。随着您开发这些系统,它们可能会随着时间变得越来越复杂,从而更难管理和扩展。例如,您可能会遇到以下问题:

  • 智能体可用的工具过多,导致对下一步要调用的工具做出错误决策
  • 上下文变得过于复杂,单个智能体难以跟踪
  • 系统需要多个专业领域(例如,规划器、研究员、数学专家等)

为了解决这些问题,您可以考虑将应用程序分解成多个更小、独立的智能体,并将它们组合成一个多智能体系统。这些独立的智能体可以像一个提示和一个LLM调用一样简单,也可以像一个ReAct智能体一样复杂(甚至更复杂!)。

使用多智能体系统的主要好处是:

  • 模块化:独立的智能体使开发、测试和维护智能体系统变得更容易。
  • 专业化:您可以创建专注于特定领域的专家智能体,这有助于提高整个系统的性能。
  • 控制:您可以明确控制智能体如何通信(而不是依赖函数调用)。

多智能体架构

在多智能体系统中,有几种连接智能体的方式:

  • 网络型:每个智能体都可以与其他所有智能体通信。任何智能体都可以决定下一步调用哪个智能体。
  • 主管型:每个智能体都与一个主管智能体通信。主管智能体决定下一步应该调用哪个智能体。
  • 主管(工具调用型):这是主管架构的一种特殊情况。单个智能体可以表示为工具。在这种情况下,主管智能体使用一个工具调用型LLM来决定调用哪个智能体工具,以及传递给这些智能体的参数。
  • 分层型:您可以定义一个包含主管的主管的多智能体系统。这是主管架构的一种泛化,允许更复杂的控制流。
  • 自定义多智能体工作流:每个智能体仅与一部分智能体通信。流程的某些部分是确定性的,并且只有一些智能体可以决定下一步调用哪个智能体。

交接

在多智能体架构中,智能体可以表示为图节点。每个智能体节点执行其步骤,并决定是完成执行还是路由到另一个智能体,包括可能路由到自身(例如,在一个循环中运行)。多智能体交互中的一个常见模式是交接,即一个智能体将控制权移交给另一个智能体。交接允许您指定:

要在LangGraph中实现交接,智能体节点可以返回Command对象,该对象允许您结合控制流和状态更新。

def agent(state) -> Command[Literal["agent", "another_agent"]]:
    # the condition for routing/halting can be anything, e.g. LLM tool call / structured output, etc.
    goto = get_next_agent(...)  # 'agent' / 'another_agent'
    return Command(
        # Specify which agent to call next
        goto=goto,
        # Update the graph state
        update={"my_state_key": "my_state_value"}
    )

在更复杂的场景中,当每个智能体节点本身都是一个图(即子图)时,某个智能体子图中的节点可能希望导航到不同的智能体。例如,如果您有两个智能体,alicebob(父图中的子图节点),并且 alice 需要导航到 bob,您可以在 Command 对象中设置 graph=Command.PARENT

def some_node_inside_alice(state):
    return Command(
        goto="bob",
        update={"my_state_key": "my_state_value"},
        # specify which graph to navigate to (defaults to the current graph)
        graph=Command.PARENT,
    )

注意

如果您需要支持使用Command(graph=Command.PARENT)进行通信的子图的可视化,您需要将它们包装在一个带有Command注解的节点函数中,例如,而不是这样:

builder.add_node(alice)

您需要这样做:

def call_alice(state) -> Command[Literal["bob"]]:
    return alice.invoke(state)

builder.add_node("alice", call_alice)

将交接作为工具

最常见的智能体类型之一是工具调用智能体。对于这类智能体,一种常见模式是将交接封装在工具调用中,例如:

API 参考:tool

from langchain_core.tools import tool

@tool
def transfer_to_bob():
    """Transfer to bob."""
    return Command(
        # name of the agent (node) to go to
        goto="bob",
        # data to send to the agent
        update={"my_state_key": "my_state_value"},
        # indicate to LangGraph that we need to navigate to
        # agent node in a parent graph
        graph=Command.PARENT,
    )

这是从工具更新图状态的一种特殊情况,除了状态更新之外,还包含了控制流。

重要

如果您想使用返回Command的工具,您可以使用预构建的create_react_agent / ToolNode 组件,或者实现您自己的工具执行节点,该节点收集工具返回的Command对象并返回它们的列表,例如:

def call_tools(state):
    ...
    commands = [tools_by_name[tool_call["name"]].invoke(tool_call) for tool_call in tool_calls]
    return commands

现在让我们更详细地了解不同的多智能体架构。

网络型

在这种架构中,智能体被定义为图节点。每个智能体都可以与其他所有智能体通信(多对多连接),并且可以决定下一步调用哪个智能体。这种架构适用于没有明确的智能体层次结构或特定调用顺序的问题。

API 参考:ChatOpenAI | Command | StateGraph | START | END

from typing import Literal
from langchain_openai import ChatOpenAI
from langgraph.types import Command
from langgraph.graph import StateGraph, MessagesState, START, END

model = ChatOpenAI()

def agent_1(state: MessagesState) -> Command[Literal["agent_2", "agent_3", END]]:
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # to determine which agent to call next. a common pattern is to call the model
    # with a structured output (e.g. force it to return an output with a "next_agent" field)
    response = model.invoke(...)
    # route to one of the agents or exit based on the LLM's decision
    # if the LLM returns "__end__", the graph will finish execution
    return Command(
        goto=response["next_agent"],
        update={"messages": [response["content"]]},
    )

def agent_2(state: MessagesState) -> Command[Literal["agent_1", "agent_3", END]]:
    response = model.invoke(...)
    return Command(
        goto=response["next_agent"],
        update={"messages": [response["content"]]},
    )

def agent_3(state: MessagesState) -> Command[Literal["agent_1", "agent_2", END]]:
    ...
    return Command(
        goto=response["next_agent"],
        update={"messages": [response["content"]]},
    )

builder = StateGraph(MessagesState)
builder.add_node(agent_1)
builder.add_node(agent_2)
builder.add_node(agent_3)

builder.add_edge(START, "agent_1")
network = builder.compile()

主管型

在这种架构中,我们将智能体定义为节点,并添加一个主管节点(LLM),由它决定下一步应该调用哪个智能体节点。我们使用Command根据主管的决策将执行路由到适当的智能体节点。这种架构也非常适合并行运行多个智能体或使用map-reduce模式。

API 参考:ChatOpenAI | Command | StateGraph | START | END

from typing import Literal
from langchain_openai import ChatOpenAI
from langgraph.types import Command
from langgraph.graph import StateGraph, MessagesState, START, END

model = ChatOpenAI()

def supervisor(state: MessagesState) -> Command[Literal["agent_1", "agent_2", END]]:
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # to determine which agent to call next. a common pattern is to call the model
    # with a structured output (e.g. force it to return an output with a "next_agent" field)
    response = model.invoke(...)
    # route to one of the agents or exit based on the supervisor's decision
    # if the supervisor returns "__end__", the graph will finish execution
    return Command(goto=response["next_agent"])

def agent_1(state: MessagesState) -> Command[Literal["supervisor"]]:
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # and add any additional logic (different models, custom prompts, structured output, etc.)
    response = model.invoke(...)
    return Command(
        goto="supervisor",
        update={"messages": [response]},
    )

def agent_2(state: MessagesState) -> Command[Literal["supervisor"]]:
    response = model.invoke(...)
    return Command(
        goto="supervisor",
        update={"messages": [response]},
    )

builder = StateGraph(MessagesState)
builder.add_node(supervisor)
builder.add_node(agent_1)
builder.add_node(agent_2)

builder.add_edge(START, "supervisor")

supervisor = builder.compile()

请查看此教程,了解主管型多智能体架构的示例。

主管(工具调用型)

主管型架构的这个变体中,我们定义了一个主管智能体,负责调用子智能体。子智能体以工具的形式暴露给主管,主管智能体决定下一步调用哪个工具。主管智能体遵循标准实现,作为一个LLM在一个循环中运行,不断调用工具直到决定停止。

API 参考:ChatOpenAI | InjectedState | create_react_agent

from typing import Annotated
from langchain_openai import ChatOpenAI
from langgraph.prebuilt import InjectedState, create_react_agent

model = ChatOpenAI()

# this is the agent function that will be called as tool
# notice that you can pass the state to the tool via InjectedState annotation
def agent_1(state: Annotated[dict, InjectedState]):
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # and add any additional logic (different models, custom prompts, structured output, etc.)
    response = model.invoke(...)
    # return the LLM response as a string (expected tool response format)
    # this will be automatically turned to ToolMessage
    # by the prebuilt create_react_agent (supervisor)
    return response.content

def agent_2(state: Annotated[dict, InjectedState]):
    response = model.invoke(...)
    return response.content

tools = [agent_1, agent_2]
# the simplest way to build a supervisor w/ tool-calling is to use prebuilt ReAct agent graph
# that consists of a tool-calling LLM node (i.e. supervisor) and a tool-executing node
supervisor = create_react_agent(model, tools)

分层型

随着您向系统中添加更多智能体,主管管理所有智能体可能会变得过于困难。主管可能会开始对下一步调用哪个智能体做出糟糕的决策,或者上下文可能变得过于复杂,单个主管难以跟踪。换句话说,您最终会遇到最初促使采用多智能体架构的相同问题。

为了解决这个问题,您可以分层设计您的系统。例如,您可以创建由各个主管管理的独立、专业的智能体团队,以及一个顶层主管来管理这些团队。

API 参考:ChatOpenAI | StateGraph | START | END | Command

from typing import Literal
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.types import Command
model = ChatOpenAI()

# define team 1 (same as the single supervisor example above)

def team_1_supervisor(state: MessagesState) -> Command[Literal["team_1_agent_1", "team_1_agent_2", END]]:
    response = model.invoke(...)
    return Command(goto=response["next_agent"])

def team_1_agent_1(state: MessagesState) -> Command[Literal["team_1_supervisor"]]:
    response = model.invoke(...)
    return Command(goto="team_1_supervisor", update={"messages": [response]})

def team_1_agent_2(state: MessagesState) -> Command[Literal["team_1_supervisor"]]:
    response = model.invoke(...)
    return Command(goto="team_1_supervisor", update={"messages": [response]})

team_1_builder = StateGraph(Team1State)
team_1_builder.add_node(team_1_supervisor)
team_1_builder.add_node(team_1_agent_1)
team_1_builder.add_node(team_1_agent_2)
team_1_builder.add_edge(START, "team_1_supervisor")
team_1_graph = team_1_builder.compile()

# define team 2 (same as the single supervisor example above)
class Team2State(MessagesState):
    next: Literal["team_2_agent_1", "team_2_agent_2", "__end__"]

def team_2_supervisor(state: Team2State):
    ...

def team_2_agent_1(state: Team2State):
    ...

def team_2_agent_2(state: Team2State):
    ...

team_2_builder = StateGraph(Team2State)
...
team_2_graph = team_2_builder.compile()


# define top-level supervisor

builder = StateGraph(MessagesState)
def top_level_supervisor(state: MessagesState) -> Command[Literal["team_1_graph", "team_2_graph", END]]:
    # you can pass relevant parts of the state to the LLM (e.g., state["messages"])
    # to determine which team to call next. a common pattern is to call the model
    # with a structured output (e.g. force it to return an output with a "next_team" field)
    response = model.invoke(...)
    # route to one of the teams or exit based on the supervisor's decision
    # if the supervisor returns "__end__", the graph will finish execution
    return Command(goto=response["next_team"])

builder = StateGraph(MessagesState)
builder.add_node(top_level_supervisor)
builder.add_node("team_1_graph", team_1_graph)
builder.add_node("team_2_graph", team_2_graph)
builder.add_edge(START, "top_level_supervisor")
builder.add_edge("team_1_graph", "top_level_supervisor")
builder.add_edge("team_2_graph", "top_level_supervisor")
graph = builder.compile()

自定义多智能体工作流

在这种架构中,我们将单个智能体添加为图节点,并提前在一个自定义工作流中定义智能体的调用顺序。在LangGraph中,工作流可以通过两种方式定义:

  • 显式控制流(普通边):LangGraph允许您通过普通图边显式定义应用程序的控制流(即智能体如何通信的序列)。这是上述架构中最具确定性的变体——我们总是提前知道下一个智能体将是哪个。

  • 动态控制流(Command):在LangGraph中,您可以允许LLM决定应用程序控制流的一部分。这可以通过使用Command来实现。一个特殊情况是主管(工具调用型)架构。在这种情况下,为主管智能体提供支持的工具调用型LLM将决定工具(智能体)的调用顺序。

API 参考:ChatOpenAI | StateGraph | START

from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, MessagesState, START

model = ChatOpenAI()

def agent_1(state: MessagesState):
    response = model.invoke(...)
    return {"messages": [response]}

def agent_2(state: MessagesState):
    response = model.invoke(...)
    return {"messages": [response]}

builder = StateGraph(MessagesState)
builder.add_node(agent_1)
builder.add_node(agent_2)
# define the flow explicitly
builder.add_edge(START, "agent_1")
builder.add_edge("agent_1", "agent_2")

通信与状态管理

在构建多智能体系统时,最重要的是弄清楚智能体如何通信。

智能体之间一种常见、通用的通信方式是通过消息列表。这引出了以下问题:

此外,如果您正在处理更复杂的智能体,或者希望将单个智能体的状态与多智能体系统状态分开,您可能需要使用不同的状态模式

交接与工具调用

在智能体之间传递的“载荷”是什么?在上面讨论的大多数架构中,智能体通过交接进行通信,并将图状态作为交接载荷的一部分传递。具体来说,智能体将消息列表作为图状态的一部分进行传递。在主管(工具调用型)的情况下,载荷是工具调用参数。

智能体之间的消息传递

智能体之间最常见的通信方式是通过共享状态通道,通常是消息列表。这假设状态中总有至少一个智能体共享的通道(键)(例如,messages)。当通过共享消息列表通信时,还有一个额外的考虑:智能体应该共享其思考过程的完整历史记录还是只共享最终结果

共享完整的思考过程

智能体可以与所有其他智能体共享其思考过程的完整历史记录(即,“草稿本”)。这个“草稿本”通常看起来像一个消息列表。共享完整思考过程的好处是,它可能有助于其他智能体做出更好的决策,并提高整个系统的推理能力。缺点是,随着智能体数量和复杂性的增加,“草稿本”会迅速增长,可能需要额外的内存管理策略。

仅共享最终结果

智能体可以拥有自己的私有“草稿本”,并仅与其余智能体共享最终结果。这种方法可能更适用于拥有许多智能体或更复杂智能体的系统。在这种情况下,您需要使用不同的状态模式来定义智能体。

对于作为工具调用的智能体,主管根据工具模式确定输入。此外,LangGraph允许在运行时将状态传递给单个工具,因此如果需要,下属智能体可以访问父状态。

在消息中指示智能体名称

指出特定AI消息来自哪个智能体可能很有帮助,特别是对于长消息历史记录。一些LLM提供商(如OpenAI)支持向消息添加name参数——您可以使用它将智能体名称附加到消息中。如果不支持,您可以考虑手动将智能体名称注入消息内容,例如,<agent>alice</agent><message>message from alice</message>

在消息历史中表示交接

交接通常通过LLM调用专用的交接工具来完成。这表示为一个带有工具调用的AI消息,并传递给下一个智能体(LLM)。大多数LLM提供商不支持接收带有工具调用但没有相应工具消息的AI消息。

因此,您有两种选择:

  1. 向消息列表添加一个额外的工具消息,例如,“已成功转移到智能体X”
  2. 移除带有工具调用的AI消息

实践中,我们发现大多数开发者选择选项(1)。

子智能体的状态管理

一种常见的做法是让多个智能体在共享消息列表上通信,但只将它们的最终消息添加到列表中。这意味着任何中间消息(例如,工具调用)都不会保存在此列表中。

如果您确实想保存这些消息,以便将来调用此特定子智能体时可以将其传回,该怎么办?

实现此目的有两种高级方法:

  1. 将这些消息存储在共享消息列表中,但在将其传递给子智能体LLM之前过滤该列表。例如,您可以选择过滤掉来自其他智能体的所有工具调用。
  2. 在子智能体的图状态中为每个智能体存储一个单独的消息列表(例如,alice_messages)。这将是它们对消息历史记录的“视图”。

使用不同的状态模式

一个智能体可能需要拥有与其余智能体不同的状态模式。例如,一个搜索智能体可能只需要跟踪查询和检索到的文档。在LangGraph中,有两种方法可以实现这一点:

  • 定义具有独立状态模式的子图智能体。如果子图和父图之间没有共享状态键(通道),则重要的是添加输入/输出转换,以便父图知道如何与子图通信。
  • 定义具有私有输入状态模式的智能体节点函数,该模式与整体图状态模式不同。这允许传递仅执行该特定智能体所需的信息。