一、基于 LangGraph 理解 LLM 智能体如何相互转移控制权

大语言模型（LLM）的推理能力结合记忆、规划和工具使用功能后，形成了所谓的智能体（Agent），这大幅扩展了 LLM 能够完成的任务范围。

然而，单个智能体也存在明显的局限性。当一个智能体配备了过多工具或处理过大的上下文时，往往会导致决策质量下降、响应效果不佳。

正因如此,多智能体系统开始流行起来,因为这类系统能够应对日益复杂的应用场景。

多智能体系统将众多专业化的智能体连接在一起协同工作,每个智能体专注于特定任务,系统则负责将查询路由到合适的专家那里。

客户支持场景下的多智能体系统示例

可以把这种架构想象成一个专家团队在协作,每个成员通过"分而治之"的方式贡献自己的专业技能。

本文将深入探讨多智能体系统中的一个核心概念：智能体之间如何转移控制权。

1. LangGraph 框架简介

这个之前写过相关基础教程的文章，不熟悉这个框架的小伙伴可以翻一番之前的内容

LangGraph 是一个开源的编排框架,用于构建有状态的、基于 LLM 的智能体系统,能够可靠地处理复杂任务。

该框架允许开发者将工作流设计为图结构,其中每个图由节点（代表任务或 LLM 调用）和边（代表控制流）组成。

LangGraph 成为构建智能体系统的首选框架,主要有以下几个优势：

• 底层可控性强：提供对转换、状态和每个智能体执行过程的精确控制
• 基于图的工作流透明直观：让复杂逻辑易于理解、设置和追踪
• 灵活的非对话工作流：支持对话式智能体之外的编排方式（例如相比 AutoGen 等框架）

下图展示了一个用于检索增强生成（RAG）的图工作流设计：

用于检索增强生成的 LangGraph 图示例

2. 智能体交接的定义

首先需要理解什么是"交接"（handoff）。

智能体交接是指一个智能体在完成工作后,直接且动态地将控制权传递给另一个智能体的时刻。

这一机制至关重要,因为系统需要将任务路由到最适合提供上下文相关响应的智能体。

从技术角度看,交接发生在一个智能体将控制权、责任或对话上下文转移给另一个智能体,以确保交互的连续性和相关性。

下图展示了基于监督者模式的三智能体架构,其中中央智能体协调专业的工作智能体（研究智能体和文档编写智能体）。

在这种架构中,监督者与每个工作智能体之间可以双向交接。每个工作智能体通过集成特定工具集和定制化提示词来获得专业能力。

假设用户查询是"研究社交媒体使用如何影响青少年心理健康"。

监督者智能体在了解用户查询的性质以及可用的工作智能体后,会将任务交接给研究智能体来执行下一轮操作。

整个流程如下：

1. 监督者智能体分析用户意图,判断需要研究智能体的协助
2. 监督者将控制权（和状态*）传递给研究智能体
3. 研究智能体执行任务,并决定是交接回监督者还是结束对话

*状态（State）是多智能体系统的短期记忆,捕获最近的对话和关键信息,使每个智能体能够基于先前的上下文和信息采取适当行动。

3. 示例场景

接下来通过一个具体示例来演示整个流程。

这里将构建一个能够回答新加坡房产相关查询的房地产助手,采用流行的监督者(supervisor)模式设计成三智能体系统。

在这个场景中,有一个房地产经理（监督者）可以调用两个专业工作智能体：

• 房产信息智能体：处理房产详细信息相关的查询
• 交易历史智能体：处理房产交易和市场趋势相关的查询

为简化演示,这里的路由是单向的,即工作智能体完成任务后对话即结束。

三智能体监督者架构的图示

为使协调机制正常工作,监督者智能体必须了解自己的角色、整体工作流程以及可调用的智能体。通过如下提示词实现：

SUPERVISOR_PROMPT = """你是新加坡的房地产监督者,负责将查询路由到专家或直接处理。可用的专家：- transaction_history_agent - 处理销售历史、市场趋势、过往交易- property_profile_agent - 处理房产详情、特征、位置信息你的任务：1. 确定应路由到哪个智能体（如果应该直接处理则选"none"）2. 提取提到的任何房产名称（如"38 Oxley Road"、"One Oxley Rise"）3. 如果无需路由,提供对话式响应对于销售/市场数据查询,路由到 transaction_history_agent。对于房产详情查询,路由到 property_profile_agent。对于问候、非房地产话题或不明确的查询,使用"none"（提供礼貌回应）。根据对话历史做出决策并提取房产名称。"""

注意提示词中明确定义了交接条件的指令。

监督者节点的条件路由代码如下：

defsupervisor_conditional_node(state: SupervisorState) -> dict: messages = state["messages"]# 用完整对话历史调用监督者 response = supervisor_llm.invoke([SystemMessage(content=SUPERVISOR_PROMPT)] + messages)return {"messages": [AIMessage(content=response.content, name="supervisor")]}

虽然多智能体系统可以遵循不同的设计模式并扩展到更多节点,但这个简单示例能让读者专注于智能体交接的核心概念。

下面的截图展示了房地产多智能体系统对用户查询的输出结果：

由于重点是智能体交接,这里不会详述完整的 LangGraph 设置代码（如提示词、节点、LLM 调用等）。完整实现代码可在 GitHub 仓库中查看。

4. LangGraph 中的交接机制

LangGraph 中有两种智能体交接机制：

• Conditional Edges条件边
• Command 对象

4.1 条件边（基于静态路由的交接）

条件边是传统的图路由方法,用于在智能体之间交接控制权。

在图中,节点执行工作,边决定下一步做什么。

边是决定路由逻辑（即下一个执行哪个节点）的函数。这种路由可以是直接的固定转换,也可以基于特定条件（即条件边）。

简单来说,条件边的流程如下：

1. 节点生成输出
2. 输出作为输入传递给条件边
3. 条件边中的函数评估输出并选择下一个要运行的节点

房地产助手示例场景中的条件边

在 LangGraph 中,通过在 StateGraph 实例上调用add_conditional_edges来定义条件边：

graph.add_conditional_edges(source="start_node", path=routing_function)

• source参数指定起始节点,表示该节点完成后条件路由开始生效
• path参数接收条件函数,其返回值控制图接下来移动到哪个节点

先来看房地产示例中的路由函数should_continue：

defshould_continue( state: SupervisorState,) -> Literal["transaction_history_agent", "property_profile_agent", "end"]:"""从监督者消息中提取路由决策。 在监督者的最新消息中查找智能体名称以确定路由。 如果监督者提供直接响应（无需路由）则返回"end"。 """# 查找最新的监督者消息for msg inreversed(state["messages"]):if (isinstance(msg, AIMessage)andhasattr(msg, "name")and msg.name == "supervisor" ): content = msg.content.strip().lower()# 检查内容中是否有智能体名称if"transaction_history_agent"in content:return"transaction_history_agent"elif"property_profile_agent"in content:return"property_profile_agent"return"end"# 未找到智能体名称 - 监督者直接处理return"end"

路由函数的工作流程：

1. 读取监督者的最新响应并决定下一步操作
2. 检查监督者是否明确要求将任务交接给两个工作智能体之一
3. 当监督者指定某个工作智能体时,函数返回该智能体的名称字符串,触发向该智能体的交接
4. 如果监督者未请求任何工作智能体,函数返回 “end”,表示监督者已完成响应,工作流结束

设置好路由函数后,接下来定义条件边：

graph.add_conditional_edges( source="supervisor", path=should_continue, path_map={"transaction_history_agent": "transaction_history_agent","property_profile_agent": "property_profile_agent","end": END, },)

• supervisor节点作为流程的源入口点,首先接收并分析用户查询
• 监督者完成处理后,路由函数should_continue开始工作,检查监督者的响应以确定交接决策
• path_map字典将路由函数的返回值转换为图目标。这是必需的,因为should_continue可能返回 “end”,path_map会将其转换为END（LangGraph 的停止信号）

以上内容展示了智能体交接的工作原理：监督者输出特定字符串,条件函数使用这些字符串来路由到下一个智能体或终止流程。

4.2 Command 对象（动态交接）

条件边适用于简单、可预测的流程,但一旦逻辑变得复杂,组合多个条件边会变得繁琐且不直观。

为了让多智能体工作流更灵活、更易于设计,引入了 Command 类型来结合状态更新和控制流。

Command 简化了操作方式,允许节点返回一个 Command 对象,该对象既能更新图状态,又能指定下一个要执行的节点。

节点不再依赖预定义的边,而是可以在运行时根据自身逻辑直接动态确定下一步。

这使得"无边图"成为可能,路由逻辑存在于智能体内部而非混乱的条件规则中,从而以更清晰、更灵活的方式编排交接。

以下是在路由节点中使用 Command 的最小代码示例：

defrouter(state):# 从当前图状态读取用户意图 user_intent = state.get("intent")# 基于简单逻辑决定下一个调用哪个智能体# 这展示了如何选择目标节点if user_intent == "search":return Command( update={"task": "run_search"}, # 更新部分状态 goto="search_agent"# 显式路由到此节点 )else:return Command( update={"task": "create_summary"}, goto="summary_agent" )

在上述代码中,路由智能体节点读取状态、决定接下来应该运行什么,并返回一个 Command 对象来更新图状态并指向下一个节点。

由于节点通过goto参数选择下一步,因此无需使用add_conditional_edges定义条件边。

Command 让交接逻辑存在于节点而非边中。因此,监督者节点的代码会更长：

defsupervisor_command_node( state: SupervisorState,) -> Command[Literal["transaction_history_agent", "property_profile_agent"]]:"""使用 Command 进行路由 + 状态更新的监督者节点。 使用结构化输出来： 1. 确定路由到哪个智能体 2. 从查询中提取 property_name 3. 通过 Command.update 更新状态 这展示了 Command 的强大之处：在一个函数中完成路由 + 状态更新。 """ messages = state["messages"]# 从监督者 LLM 获取结构化决策 llm_with_structure = supervisor_llm.with_structured_output(SupervisorDecision) decision: SupervisorDecision = llm_with_structure.invoke( [SystemMessage(content=SUPERVISOR_PROMPT)] + messages )# 如果无需路由,监督者直接处理if decision.next_agent == "none":return Command[str]( goto="__end__", update={"messages": [AIMessage(content=decision.response, name="supervisor")]}, )# 构建包含提取上下文的状态更新字典 update_dict = {"messages": [AIMessage(content=f"Routing to {decision.next_agent}", name="supervisor")]}if decision.property_name: update_dict["property_name"] = decision.property_namereturn Command(goto=decision.next_agent, update=update_dict)

工作流程如下：

1. 监督者节点调用 LLM 返回SupervisorDecision结构化输出对象,包含两个关键信息：要交接给哪个智能体,以及相关上下文（如从用户消息中提取的房产名称）
2. 如果不需要工作智能体,监督者直接响应。节点返回一个 Command,用响应更新消息并结束图
3. 如果需要交接,节点构建更新字典。包含来自监督者的路由消息和提取的上下文（如房产名称）到图状态中,以便下一个智能体可以立即使用
4. 最后,节点返回一个 Command,使用goto指定下一个智能体,并应用状态更新（即更新property_name）

Literal["transaction_history_agent", "property_profile_agent"]类型提示让系统即使在未显式定义边的情况下也能生成完整的 Mermaid 图。实际的交接流程由goto参数处理。

使用Command但仍显示边的房地产多智能体系统

使用 Command 后,节点直接决定接下来运行哪个智能体以及传递什么信息。这消除了独立的路由规则,保持交接逻辑的简洁。

4.3 何时使用条件边还是 Command？

在交接场景下选择条件边还是 Command 的指导原则：

使用条件边的情况：

• 只需要基于当前图状态决定运行哪个节点,而不改变状态

使用 Command 的情况：

• 节点需要同时修改状态并确定下一个节点
• 这在多智能体交接中很有用,因为路由到另一个智能体通常需要传递一些信息给该智能体

在实际工作中,作者已经基本转向使用 Command 而非条件边,因为许多多智能体系统需要在路由决策的同时协调图状态更新。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】