LangGraph多智能体能力路由：动态专家选择与负载均衡

一、引言

钩子

你是否遇到过这种情况： 当你构建了一个由多个大模型或专业Agent组成的“超级团队”——有的精通数学推理、有的擅长代码生成、有的是情感分析小能手、还有的能写长篇技术文档——却发现整个系统要么反应慢得像蜗牛（每次都把问题丢给所有专家让它们抢或者轮着试），要么经常派“外行”干“内行”活（比如让写代码的Agent去解复杂的偏微分方程），更糟的是如果某个热门专家（比如GPT-4 Turbo或者CodeLlama）被频繁调用导致成本爆炸、甚至API限流？

这种场景在2024年的AI应用开发中太常见了。据OpenAI官方和LangChain社区的统计，在使用多Agent系统的开发者中，有超过65%的人遇到过能力不匹配导致的结果质量下降，42%的人被热门Agent的API限流或高成本困扰，38%的人觉得多Agent系统的响应时间不可控。那有没有一种技术，能像一个经验丰富的CTO（首席技术协调员） 一样，精准判断用户的问题属于哪个“技术栈”，然后动态挑选当前最空闲、成本最低、能力最强、响应最快的专家Agent来解决，甚至还能提前预判专家的负载，把任务“匀”给能力相近的备用Agent？

答案是肯定的——这就是我们今天要聊的核心主题：基于LangGraph的多智能体能力路由（Dynamic Expert Selection and Load Balancing in LangGraph Multi-Agent Systems）。

定义问题/阐述背景

1. 什么是多智能体系统（MAS）？

要聊能力路由，首先得明白什么是多智能体系统。从学术定义上来说，多智能体系统（Multi-Agent System, MAS） 是由多个具有自主性、交互性、反应性和主动性的智能体（Agent）组成的分布式计算系统。每个Agent都有自己的目标、知识库和行为规则，它们通过通信、协作、协商甚至竞争来完成单个Agent无法独立完成的复杂任务。

在大语言模型（LLM）时代，我们常说的“多智能体系统”通常指的是LLM驱动的多智能体系统（LLM-Based Multi-Agent System）。这里的每个Agent，本质上是一个“封装了特定能力的LLM实例+工具集+状态管理组件”——比如LangChain中的AgentExecutor，或者我们今天要重点讲的LangGraph中的节点（Node）。

2. 为什么需要多智能体系统？

单个LLM虽然已经很强大（比如GPT-4o能处理文本、图像、音频，能推理、写代码、做设计），但它仍然存在很多固有缺陷：

1. 能力有限性： 哪怕是GPT-4o，也不可能精通所有领域——比如让它解量子力学的多体薛定谔方程，或者让它优化硬件级别的汇编代码，结果往往不尽如人意；
2. 成本与速度的权衡： 能力越强的LLM（比如GPT-4 Turbo 128K、Claude 3 Opus），API调用成本越高（GPT-4 Turbo 128K的输入是$0.01/1K tokens，输出是$0.03/1K tokens，是GPT-3.5 Turbo 128K的5-10倍），响应时间也越长（Claude 3 Opus的平均响应时间通常在10秒以上，而GPT-3.5 Turbo仅需1-2秒）；
3. 知识库的局限性： 单个LLM的知识库是静态的（截止到训练数据的时间点），而且对于专业领域的知识（比如最新的法律条文、企业内部的技术文档、实时的股票行情），它要么不知道，要么会产生“幻觉（Hallucination）”；
4. 工具调用的局限性： 虽然现代LLM都支持工具调用（Function Calling/Tool Use），但单个LLM调用工具的次数有限，而且很难高效地管理复杂的工具链交互（比如“先查天气→再查航班→再查酒店→最后生成行程单”这种长链条任务）。

而多智能体系统，就是为了弥补单个LLM的这些缺陷而诞生的：

• 你可以构建多个**“垂直领域专家Agent”**，每个Agent只精通一个或几个领域的知识，搭配专门的工具和提示词（Prompt Engineering）；
• 你可以构建多个**“能力梯度Agent”**，比如用GPT-3.5 Turbo处理简单的文本分类、聊天回复，用GPT-4o处理复杂的推理、多模态任务；
• 你可以构建多个**“知识库Agent”**，每个Agent连接不同的向量数据库（比如企业内部技术文档库、法律条文库、产品知识库）；
• 你可以构建多个**“工具链Agent”**，每个Agent负责一个小的、独立的子任务链，然后通过协调Agent把它们串联起来。

3. 什么是多智能体能力路由？为什么现在才火？

既然多智能体系统这么好，那为什么很多开发者用起来还是觉得糟心？核心原因就是缺少一个高效的“能力路由层”。

早期的多智能体系统，路由方式通常非常简单粗暴：

1. 静态路由（Static Routing）： 开发者在代码里写死“如果问题里有‘代码’→派CodeLlama；如果有‘数学’→派Wolfram Alpha Agent；如果都没有→派GPT-3.5 Turbo”。这种方式的优点是简单、快，但缺点也非常明显——它完全依赖开发者的主观判断，无法应对模糊问题（比如“给我写一个基于神经网络的偏微分方程求解代码”，到底是派CodeLlama还是Wolfram Alpha Agent？），也无法处理专家的临时故障、限流或负载过高的情况；
2. 轮询路由（Round-Robin Routing）： 把多个能力相近的Agent排成一个队列，每次来任务就按顺序派给下一个Agent。这种方式能简单地实现负载均衡，但完全不考虑任务的类型、Agent的当前状态（比如是否空闲、上次调用是否失败、API剩余配额还有多少），结果质量和响应时间都不可控；
3. 随机路由（Random Routing）： 从多个能力相近的Agent里随机挑一个。这比轮询路由还不靠谱，结果质量、响应时间、负载均衡都无法保证；
4. LLM路由（LLM-Based Routing）： 用一个“路由LLM”先分析用户的问题，然后生成要派给哪个专家Agent的指令。这种方式能应对模糊问题，但也存在很多问题——首先，路由LLM本身也需要成本和时间；其次，路由LLM也会产生“幻觉”，比如把数学问题派给写代码的Agent；最后，它仍然完全不考虑专家Agent的当前状态。

而基于LangGraph的动态能力路由，是在LLM路由的基础上，结合了状态管理（State Management）、能力图谱（Capability Graph）、实时负载监控（Real-Time Load Monitoring）、负载均衡算法（Load Balancing Algorithm）、容错机制（Fault Tolerance Mechanism） 等技术，构建的一个智能化、自适应、高可用、低成本、低延迟的多智能体协调层。

为什么现在才火？因为有了LangGraph！

在LangGraph出现之前，构建一个具有复杂状态管理、动态路由、容错机制的多智能体系统，简直是一场噩梦——你需要自己写大量的状态管理代码（比如用Redis、PostgreSQL或者内存变量来存储系统的状态），自己写路由逻辑，自己处理Agent之间的通信和同步，自己处理容错（比如Agent调用失败怎么办？重试几次？重试失败怎么办？），自己处理负载均衡，等等。而LangGraph的出现，彻底改变了这一切——它提供了一个基于状态机（State Machine）的、可视化的、可扩展的多智能体系统构建框架，让开发者可以像搭积木一样构建复杂的多智能体系统，而且内置了强大的状态管理、条件边（Conditional Edge）、循环（Loop）、并行（Parallel）、容错（Retry）等功能。

亮明观点/文章目标

本文的核心观点是： 基于LangGraph的动态能力路由，是构建高性能、高可用、低成本、可扩展的LLM驱动多智能体系统的核心基础设施。

读完这篇文章，你将学到：

1. 多智能体能力路由的核心概念、关键术语、数学模型和算法原理；
2. LangGraph的核心功能、架构设计和使用方法（如果你还不熟悉LangGraph，这部分可以帮你快速入门）；
3. 如何从零开始构建一个基于LangGraph的动态能力路由系统——包括能力图谱的设计、实时负载监控的实现、动态专家选择算法的实现、负载均衡算法的实现、容错机制的实现，以及完整的代码示例；
4. 如何优化动态能力路由系统的性能、成本和可用性——包括常见的陷阱与避坑指南、最佳实践总结；
5. 多智能体能力路由的行业发展历史、现状和未来趋势。

本文的主要内容预告：

• 第二章：我们会介绍多智能体能力路由和LangGraph的基础知识和背景铺垫，包括核心概念定义、相关工具/技术概览、关键术语对比；
• 第三章：这是文章的核心部分，我们会通过一个实战项目——“企业级AI客服与技术支持系统” 来教你如何从零开始构建一个基于LangGraph的动态能力路由系统，包括项目介绍、环境安装、系统功能设计、系统架构设计、系统接口设计、系统核心实现源代码、实际场景应用演示；
• 第四章：我们会探讨动态能力路由系统的进阶问题和最佳实践，包括常见的陷阱与避坑指南、性能优化、成本考量、高可用设计、最佳实践总结；
• 第五章：我们会回顾多智能体能力路由的行业发展历史，分析现状和未来趋势，最后给你一些行动号召和进一步学习的资源链接。

二、基础知识/背景铺垫

核心概念定义

在深入讲解基于LangGraph的动态能力路由之前，我们需要先明确一些核心概念和关键术语——这些概念不仅是本文的基础，也是整个LLM驱动多智能体系统领域的通用术语。

1. 多智能体系统相关概念

（1）智能体（Agent）

在LLM驱动的多智能体系统中，智能体（Agent） 是一个具有自主性、交互性、反应性和主动性的计算实体，通常由以下几个部分组成：

1. 大语言模型（LLM）： Agent的“大脑”，负责理解用户的问题、生成思考过程、调用工具、生成最终结果；
2. 提示词模板（Prompt Template）： 告诉Agent“你是谁、你能做什么、你不能做什么、你应该怎么做”的“工作手册”；
3. 工具集（Toolkit）： Agent可以调用的“外部工具”，比如搜索引擎（Google Search、Bing Search）、计算器（Wolfram Alpha）、向量数据库检索（Pinecone、Weaviate、ChromaDB）、代码执行器（Python REPL、Jupyter Notebook）、API调用器（REST API、GraphQL API）等；
4. 状态读写接口（State Read/Write Interface）： Agent和系统状态之间的“桥梁”——Agent可以从状态中读取信息（比如用户的历史对话记录、之前Agent的执行结果、当前系统的负载情况），也可以向状态中写入信息（比如自己的执行结果、中间思考过程、下一步要调用的Agent或工具）；
5. 行为规则（Behavior Rules）： Agent的“行为准则”，比如“如果调用工具失败，重试3次，每次间隔1秒”、“如果用户的问题涉及敏感信息，拒绝回答”、“如果需要其他Agent的帮助，向协调Agent发送请求”。

在LangGraph中，Agent通常被封装成一个节点（Node）——你可以把LangGraph看作是一个“节点的网络”，每个节点代表一个Agent或一个工具调用，节点之间的边（Edge）代表数据的流动和任务的跳转。

（2）协调Agent（Coordinator Agent）

协调Agent是多智能体系统的“大脑中枢”或“CTO”，负责：

1. 接收用户的问题；
2. 分析用户的问题（类型、复杂度、优先级、敏感程度等）；
3. 根据能力图谱和实时负载情况，动态选择合适的专家Agent；
4. 将任务分配给选中的专家Agent；
5. 监控专家Agent的执行过程（是否成功、是否超时、结果质量如何）；
6. 如果专家Agent执行失败或超时，进行容错处理（重试、切换到备用Agent、降级处理等）；
7. 收集所有专家Agent的执行结果，进行整合和优化，生成最终的回复给用户；
8. 更新系统的状态（比如用户的历史对话记录、专家Agent的负载情况、执行日志等）。

在基于LangGraph的动态能力路由系统中，协调Agent通常是系统的入口节点（Entry Node） 和决策节点（Decision Node）——它通过条件边（Conditional Edge）来决定任务的下一步跳转。

（3）专家Agent（Expert Agent）

专家Agent是多智能体系统的“技术骨干”，负责执行特定的、垂直的、复杂的子任务。专家Agent通常分为以下几种类型：

1. 垂直领域专家Agent（Domain-Specific Expert Agent）： 只精通一个或几个垂直领域的知识，比如法律专家Agent、医疗专家Agent、金融专家Agent、技术支持专家Agent等；
2. 能力专家Agent（Capability-Specific Expert Agent）： 只擅长一种或几种特定的能力，比如数学推理专家Agent、代码生成专家Agent、多模态分析专家Agent、文本摘要专家Agent、翻译专家Agent等；
3. 知识库专家Agent（Knowledge Base Expert Agent）： 连接特定的向量数据库，负责检索和整合知识库中的信息，比如企业内部技术文档库Agent、产品知识库Agent、法律条文库Agent等；
4. 工具链专家Agent（Toolchain Expert Agent）： 负责执行一个小的、独立的子任务链，比如“行程规划Agent”（先查天气→再查航班→再查酒店→最后生成行程单）、“订单处理Agent”（先验证用户身份→再查询订单信息→再处理退款/换货请求→最后生成处理结果）等。

（4）能力图谱（Capability Graph）

能力图谱是多智能体系统的“人才档案库”，它存储了每个专家Agent的基本信息、能力标签、能力评分、成本信息、性能信息、可用性信息等。能力图谱通常是一个有向加权图（Directed Weighted Graph） 或者一个知识图谱（Knowledge Graph）——节点代表专家Agent，边代表Agent之间的协作关系（比如“数学推理专家Agent”可以调用“代码生成专家Agent”来实现数学算法），权重代表协作的优先级或成本。

能力图谱的设计是动态能力路由系统的核心环节——能力图谱越完善、越准确，动态专家选择的结果就越好。

（5）系统状态（System State）

系统状态是多智能体系统的“记忆库”，它存储了系统运行过程中的所有信息，通常分为以下几种类型：

1. 用户状态（User State）： 用户的基本信息（ID、姓名、年龄、性别、职业等）、历史对话记录、历史请求记录、偏好设置（比如喜欢用中文还是英文回复、喜欢简洁的回复还是详细的回复、喜欢用成本低的Agent还是能力强的Agent等）；
2. 任务状态（Task State）： 当前任务的基本信息（ID、类型、复杂度、优先级、敏感程度、创建时间、截止时间等）、执行进度、中间结果、失败原因（如果有的话）；
3. 专家Agent状态（Expert Agent State）： 每个专家Agent的基本信息（ID、名称、类型、能力标签、能力评分等）、实时负载情况（当前正在处理的任务数、API剩余配额、最近一次调用的时间、最近一次调用的响应时间、最近一次调用的成功率等）、历史执行记录；
4. 系统全局状态（Global System State）： 系统的整体运行情况（当前正在处理的总任务数、总负载率、平均响应时间、总成功率、总API调用成本等）、配置信息（能力图谱的配置、负载均衡算法的配置、容错机制的配置等）。

在LangGraph中，系统状态通常被封装成一个TypedDict（类型字典）或者一个Pydantic模型——你可以在创建LangGraph的时候定义状态的结构，然后每个节点都可以读写这个状态。

2. 能力路由相关概念

（1）能力路由（Capability Routing）

能力路由是指根据任务的特征（类型、复杂度、优先级、敏感程度等）和Agent的特征（能力标签、能力评分、成本、性能、可用性、实时负载等），将任务动态分配给最合适的Agent来执行的过程。

能力路由的核心目标是：

1. 最大化结果质量（Maximize Result Quality）： 派最合适的专家Agent来执行任务，避免“外行”干“内行”活；
2. 最小化响应时间（Minimize Response Time）： 派当前最空闲、响应最快的Agent来执行任务，避免任务排队；
3. 最小化成本（Minimize Cost）： 在保证结果质量和响应时间的前提下，派成本最低的Agent来执行任务；
4. 最大化系统可用性（Maximize System Availability）： 避免某个Agent被频繁调用导致过载、限流或故障，确保系统能够持续稳定地运行。

（2）静态路由（Static Routing）

静态路由是指开发者在代码里写死任务的路由规则——比如“如果问题里有‘代码’→派CodeLlama；如果有‘数学’→派Wolfram Alpha Agent；如果都没有→派GPT-3.5 Turbo”。

静态路由的优点是：

1. 简单、易实现；
2. 路由速度快（不需要任何计算或分析）；
3. 结果可预测（开发者完全知道任务会派给哪个Agent）。

静态路由的缺点是：

1. 无法应对模糊问题（比如“给我写一个基于神经网络的偏微分方程求解代码”，到底是派CodeLlama还是Wolfram Alpha Agent？）；
2. 无法处理Agent的临时故障、限流或负载过高的情况；
3. 无法优化成本和响应时间；
4. 可扩展性差（每次添加新的Agent或修改路由规则，都需要修改代码）。

（3）LLM路由（LLM-Based Routing）

LLM路由是指用一个“路由LLM”先分析用户的问题，然后生成要派给哪个专家Agent的指令。

LLM路由的优点是：

1. 能应对模糊问题（路由LLM可以理解自然语言的模糊性）；
2. 可扩展性好（每次添加新的Agent，只需要更新路由LLM的提示词模板，不需要修改代码）；
3. 结果质量相对较高（路由LLM的判断通常比开发者的主观判断更准确）。

LLM路由的缺点是：

1. 路由LLM本身也需要成本和时间；
2. 路由LLM也会产生“幻觉”，比如把数学问题派给写代码的Agent；
3. 完全不考虑Agent的当前状态（比如是否空闲、上次调用是否失败、API剩余配额还有多少）；
4. 结果不可预测（路由LLM的判断可能会因为提示词的细微变化而改变）。

（4）动态能力路由（Dynamic Capability Routing）

动态能力路由是指在LLM路由的基础上，结合了状态管理、能力图谱、实时负载监控、负载均衡算法、容错机制等技术，构建的一个智能化、自适应、高可用、低成本、低延迟的路由层。

动态能力路由的优点是：

1. 能应对模糊问题；
2. 能处理Agent的临时故障、限流或负载过高的情况；
3. 能同时优化结果质量、响应时间、成本和系统可用性；
4. 可扩展性好；
5. 结果可预测（通过能力图谱和算法来控制路由结果）。

动态能力路由的缺点是：

1. 实现复杂度相对较高；
2. 需要额外的基础设施（比如状态存储、负载监控、能力图谱存储）。

（5）负载均衡（Load Balancing）

负载均衡是指将任务均匀地分配给多个能力相近的Agent来执行，避免某个Agent被频繁调用导致过载、限流或故障。

常见的负载均衡算法有：

1. 轮询算法（Round-Robin Algorithm）： 把多个能力相近的Agent排成一个队列，每次来任务就按顺序派给下一个Agent；
2. 加权轮询算法（Weighted Round-Robin Algorithm）： 给每个能力相近的Agent分配一个权重（权重越高，被分配的任务越多），然后按权重比例来分配任务；
3. 最少连接算法（Least Connections Algorithm）： 派给当前正在处理的任务数最少的Agent；
4. 加权最少连接算法（Weighted Least Connections Algorithm）： 派给当前正在处理的任务数/权重比值最小的Agent；
5. 响应时间加权算法（Response Time Weighted Algorithm）： 派给最近一次调用的响应时间最短的Agent；
6. 随机算法（Random Algorithm）： 从多个能力相近的Agent里随机挑一个；
7. 一致性哈希算法（Consistent Hashing Algorithm）： 用任务的特征（比如任务ID、用户ID）作为哈希键，将任务映射到一个环形的哈希空间上，然后派给哈希空间上离任务最近的Agent；
8. 自适应算法（Adaptive Algorithm）： 根据Agent的实时状态（当前正在处理的任务数、API剩余配额、最近一次调用的响应时间、最近一次调用的成功率等），动态调整负载均衡策略。

在基于LangGraph的动态能力路由系统中，我们通常会使用加权最少连接算法或者自适应算法，因为它们能同时考虑Agent的能力和实时负载情况。

（6）容错机制（Fault Tolerance Mechanism）

容错机制是指当Agent调用失败或超时时，系统能够自动处理，确保任务能够继续执行或者优雅地失败。

常见的容错机制有：

1. 重试机制（Retry Mechanism）： 当Agent调用失败或超时时，自动重试几次（重试次数、重试间隔、重试条件可以配置）；
2. 降级机制（Fallback Mechanism）： 当所有重试都失败时，切换到一个能力稍弱但更稳定的备用Agent，或者返回一个预定义的降级结果；
3. 熔断机制（Circuit Breaker Mechanism）： 当某个Agent的失败率超过某个阈值时，暂时停止向该Agent分配任务（熔断），过一段时间后再尝试向该Agent分配任务（半开），如果成功则恢复正常（闭合），如果失败则继续熔断；
4. 限流机制（Rate Limiting Mechanism）： 当某个Agent的API调用频率超过某个阈值时，暂时停止向该Agent分配任务，或者将任务排队等待。

在基于LangGraph的动态能力路由系统中，我们通常会使用重试机制+降级机制+熔断机制的组合，因为它们能最大程度地保证系统的可用性。

3. LangGraph相关概念

（1）LangGraph

LangGraph是LangChain团队在2023年底推出的一个基于状态机的、可视化的、可扩展的多智能体系统构建框架。LangGraph的核心思想是：将复杂的多智能体系统建模成一个有向图（Directed Graph），其中节点代表Agent或工具调用，边代表数据的流动和任务的跳转，状态贯穿整个图的执行过程。

LangGraph的核心优势是：

1. 强大的状态管理： 内置了类型安全的状态管理功能，支持状态的读写、合并、持久化；
2. 灵活的控制流： 支持条件边（Conditional Edge）、循环（Loop）、并行（Parallel）、分支（Branch）等复杂的控制流；
3. 可视化的调试工具： 内置了可视化的调试工具（LangSmith集成），可以清晰地看到图的执行过程、状态的变化、每个节点的输入输出；
4. 高可扩展性： 支持自定义节点、自定义边、自定义状态合并规则；
5. 内置的容错机制： 支持节点级别的重试、超时、降级；
6. LangChain生态集成： 可以无缝集成LangChain的所有组件（LLM、提示词模板、工具、向量数据库等）。

（2）节点（Node）

在LangGraph中，节点（Node） 是图的基本执行单元，代表一个Agent、一个工具调用、一个状态修改操作，或者任何其他的计算逻辑。

节点的输入是当前的系统状态，节点的输出是一个新的状态（或者状态的一部分）。LangGraph会自动将节点的输出合并到当前的系统状态中。

在LangGraph中，你可以通过add_node方法来添加节点：

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from operator import add

# 定义状态结构
class State(TypedDict):
    messages: Annotated[list, add]  # 消息列表，使用add操作合并
    current_agent: str  # 当前正在处理任务的Agent
    load_info: dict  # 所有Agent的实时负载信息

# 创建图
graph = StateGraph(State)

# 定义一个节点：路由Agent
def router_node(state: State) -> dict:
    # 这里写路由Agent的逻辑
    return {"current_agent": "code_agent"}

# 添加节点
graph.add_node("router", router_node)

（3）边（Edge）

在LangGraph中，边（Edge） 代表图中节点之间的连接，决定了任务的下一步跳转。

LangGraph支持以下几种类型的边：

1. 普通边（Normal Edge）： 从一个节点直接跳转到另一个节点；
2. 条件边（Conditional Edge）： 根据当前的系统状态，动态决定跳转到哪个节点；
3. 入口边（Entry Edge）： 图的入口，从外部跳转到第一个节点；
4. 出口边（Exit Edge）： 图的出口，跳转到END节点，结束图的执行。

在LangGraph中，你可以通过add_edge、add_conditional_edges、set_entry_point、set_finish_point方法来添加边：

# 添加普通边：从code_agent节点跳转到END节点
graph.add_edge("code_agent", END)

# 定义条件边的路由函数
def conditional_router(state: State) -> str:
    # 根据当前的系统状态，动态决定跳转到哪个节点
    if state["current_agent"] == "code_agent":
        return "code_agent"
    elif state["current_agent"] == "math_agent":
        return "math_agent"
    else:
        return "general_agent"

# 添加条件边：从router节点跳转到不同的专家Agent节点
graph.add_conditional_edges(
    "router",
    conditional_router,
    {
        "code_agent": "code_agent",
        "math_agent": "math_agent",
        "general_agent": "general_agent"
    }
)

# 设置入口边：从外部跳转到router节点
graph.set_entry_point("router")

（4）状态（State）

在LangGraph中，状态（State） 是图的核心，贯穿整个图的执行过程。状态存储了图运行过程中的所有信息，每个节点都可以读写这个状态。

LangGraph支持两种类型的状态：

1. 无类型状态（Untyped State）： 一个普通的Python字典，没有类型安全检查；
2. 类型安全状态（Typed State）： 一个TypedDict或者一个Pydantic模型，支持类型安全检查。

在LangGraph中，你可以通过Annotated和operator模块来定义状态的合并规则——因为在并行执行多个节点的时候，每个节点都会输出一个新的状态（或者状态的一部分），LangGraph需要知道如何将这些状态合并成一个统一的状态。

常见的状态合并规则有：

1. operator.add：将两个列表或字符串合并；
2. operator.or_：将两个字典合并（如果有冲突，后面的覆盖前面的）；
3. 自定义合并函数：你可以自己写一个合并函数，来处理更复杂的合并逻辑。

（5）编译（Compile）

在LangGraph中，你需要先编译（Compile） 图，然后才能执行它。编译的过程会将图转换成一个可执行的状态机，同时会进行一些优化和验证（比如检查是否有循环引用、检查状态的合并规则是否正确等）。

在LangGraph中，你可以通过compile方法来编译图：

# 编译图
app = graph.compile()

（6）执行（Execute）

在LangGraph中，你可以通过invoke、stream、batch方法来执行图：

1. invoke：同步执行图，返回最终的状态；
2. stream：异步执行图，返回一个状态的迭代器（可以实时看到图的执行过程）；
3. batch：批量执行图，返回一个最终状态的列表。

# 同步执行图
initial_state = {"messages": [("user", "给我写一个Python的冒泡排序代码")]}
final_state = app.invoke(initial_state)

# 打印最终的消息
print(final_state["messages"][-1][1])

相关工具/技术概览

在构建基于LangGraph的动态能力路由系统时，我们通常会用到以下几种工具/技术：

关键术语对比

为了帮助你更好地理解这些概念，我们来做一个关键术语对比：

1. 静态路由 vs LLM路由 vs 动态能力路由

2. LangChain AgentExecutor vs LangGraph

3. 垂直领域专家Agent vs 能力专家Agent vs 知识库专家Agent vs 工具链专家Agent

概念之间的关系

为了帮助你更好地理解这些概念之间的关系，我们来画一个ER实体关系图和一个交互关系图：

1. ER实体关系图（Mermaid）

2. 交互关系图（Mermaid）