新书预告《LangGraph智能体设计模式与多智能体开发》
3.1.1 LangGraph基础介绍
我们知道，LangGraph是一个基于图结构的开源框架，用于创建动态代理（Agent）及多代理工作流。作为LangChain生态系统的一部分，它也可以独立运行，核心优势在于支持循环流程、细粒度可控性和内置持久性，解决了传统有向无环图（DAG）框架无法处理循环逻辑的局限性。
1.核心特性与技术原理
- 循环与分支：LangGraph允许定义包含循环和条件分支的工作流，例如代理可多次调用工具优化结果（如改进RAG管道的检索质量），适应复杂任务需求。
- 状态管理：通过节点（执行步骤）和边（执行顺序与条件）构建图结构，状态在节点间传递并动态更新。例如，节点可调用LLM或工具，条件边根据状态决定下一步操作。
- 持久性与人工干预：自动保存每一步状态，支持暂停/恢复执行（如错误恢复或时间回溯），并允许人类审核或修改代理的下一步行动，实现“人在环（Human-in-the-Loop）”协作。
- 流式支持与集成：实时流式传输每个节点的输出（包括令牌流），并与LangChain无缝集成，提升开发效率。
2. 应用场景
LangGraph适用于自动化复杂业务流程：
- 客户服务：构建多轮对话机器人，提供个性化支持。
- 数据分析：代理协同检索多源信息并生成报告。
- 流程自动化：如订单处理、库存管理等需状态跟踪的场景。
- 教育/推荐系统：AI教师动态调整教学策略，或基于用户行为生成推荐。
3. 示例与部署
用户可通过Python代码定义图结构（如分类查询→生成响应→循环优化），并利用内置MemorySaver保存对话上下文，确保长期任务连续性。其商业平台支持生产环境部署，适合构建高可控、高可靠的智能系统。
LangGraph通过图计算模型（灵感源自Pregel和ApacheBeam）实现了灵活的任务编排，为开发动态AI应用提供了底层支持，推动多代理协作与自动化演进。
4. 一个简单、完整的LangGraph智能体
我们首先实现一个简单、完整的LangGraph智能体，代码如下：
from langgraph.graph import StateGraph,END
import bigmodel
from pydantic import BaseModel
class AgentState(BaseModel):
message:str
def chatbot(state:AgentState):
message=state.message
llm = bigmodel.llm
reply = llm.invoke(message).content
return {"message":reply}
graph_builder = StateGraph(AgentState)
graph_builder.add_node(chatbot)
graph_builder.set_entry_point("chatbot")
graph_builder.add_edge("chatbot", END)
graph = graph_builder.compile()
if __name__ == '__main__':
reply = graph.invoke({"message":"你好"})
print(reply)
输出结果如下：
{'message': '你好！很高兴见到你，有什么我可以帮忙的吗？😊'}
这段代码实现了一个极简的LangGraph聊天机器人，核心是通过图结构串联“输入－处理－输出”的完整流程，让大模型的对话能力以结构化方式运行。代码首先定义了AgentState状态模型，该模型仅包含message字段，既能够存储用户输入的初始消息，又能够承载大模型返回的回复，成为贯穿整个流程的状态载体。
核心处理逻辑封装在chatbot函数中，它接收AgentState实例后，提取其中的message内容，调用bigmodel中的大模型（LLM）进行处理，获取回复内容后，将其重新存入message字段并返回，完成“接收消息－调用大模型－生成回复”的核心逻辑闭环。
LangGraph的图结构搭建是这段代码的关键，它通过StateGraph构建了一个极简的线性流程。首先创建graph_builder对象并绑定AgentState，确保流程中状态的传递格式统一；接着将chatbot函数添加为图中的唯一节点，该节点既是处理逻辑的载体，也是流程的核心执行单元；随后设置chatbot为流程的入口点，意味着调用图时会直接触发该节点的逻辑；最后通过add_edge将chatbot节点与END连接，明确节点执行完成后流程即终止，形成“单一节点 + 线性流转”的简洁图结构。
代码的运行逻辑直观且易理解，在main函数中，通过graph.invoke({"message":"你好"})传入初始用户消息，触发图的执行：首先创建包含该消息的AgentState实例，传入chatbot节点；节点调用大模型处理“你好”并生成回复，更新AgentState中的message字段；流程执行到END后终止，返回包含最终回复的状态对象，最后打印输出结果。
这段代码的核心价值在于用最少的代码展示了LangGraph的核心逻辑——节点承载处理逻辑、状态模型传递数据、图结构定义流转路径，既适合入门理解LangGraph的基础用法，也可以在此基础上扩展更复杂的对话功能（如多轮对话记忆、分支处理等）。
3.1.2 LangGraph组件
LangChain框架基于“链”的模型调用与流程设计，虽然其能够较好地完成任务，但是简单的链不具备循环能力，对于多分支任务，则需要一个具备更精细控制能力的框架来支持复杂场景的LLM应用。
LangGraph的出现宣布智能体的使用进入多智能体框架领域，LangGraph是基于图论运作的，它提供了一种状态机的技术，可与驱动循环代理调用，实现有向有环图。因此，LangGraph有以下三个关键元素。
- State（状态）：一个共享的数据结构，表示应用程序的当前快照。它可以是任何Python类型，但通常是TypedDict或PydanticBaseModel。
- Nodes（节点）：编码代理逻辑的Python函数。它们接收当前的State作为输入，执行一些计算或辅助作用，并返回一个更新后的State。
- Edges（边）：Python函数，基于当前的State决定接下来执行哪个Node。它们可以是条件分支或固定转换。
通过组合Nodes和Edges，可以创建复杂、循环的工作流，随着时间的推移演化State。不过，真正的强大之处在于LangGraph如何管理这个State。需要强调的是，Nodes和Edges仅仅是Python函数——它们可以包含LLM，也可以只是普通的Python代码。
简而言之，Nodes是用于工作的模块，Edges告诉我们接下来该做什么。
LangGraph的底层图算法使用消息传递来定义一个通用程序。当一个Node完成其操作时，它会沿着一条或多条边发送消息给其他节点。这些接收节点随后执行它们的函数，将结果消息传递给下一组节点，过程继续，且程序以离散的“超级步骤”进行。
一个超级步骤可以被视为对图节点的一次迭代。并行运行的节点属于同一超级步骤，而顺序运行的节点属于不同的超级步骤。在图执行开始时，所有节点都处于非活动状态。当一个节点在其任何输入边（或“通道”）上收到新消息（状态）时，它会变为活动状态。活跃节点运行其函数并响应更新。
在每个超级步骤结束时，没有收到消息的节点会通过标记自己为非活动状态来停止投票。图执行在所有节点都为非活动且没有消息在传递时终止。
在定义图形时，首先要做的是定义图形的State。State包含图形的模式以及指定如何应用更新到State的reducer函数。State的模式将是所有Nodes和Edges在图中的输入模式，可以是TypedDict或Pydantic模型。所有节点将会发出对State的更新，然后通过指定的reducer函数应用这些更新。
试想一下：如果让大模型（比如Qwen、DeepSeek、GLM等）以及各种工具（查询天气的、计算数据的、调用数据库的）像一个小团队一样协作，既能分工干活，又能根据情况灵活调整流程，比如
“先让大模型想查询思路，再调用工具查数据，最后让大模型整理结果”，甚至遇到问题还能“返工”（比如数据不对就重新查）。
LangGraph就是为这个需求而生的。它的核心想法特别简单：给这些“团队成员”（大模型、工具）画一幅“协作地图”，让它们知道谁先上、谁后上，数据怎么传，遇到岔路该走哪条路——这幅“地图”就是所谓的“图结构”。
为了让这幅“地图”能落地，LangGraph定义了三个最基础的“地图规则”：节点、边和状态。我们一个个用大白话讲明白。
1. 节点（Nodes）：每个干活的“小站”
节点其实就是“团队里具体干活的角色”——无论是能思考的大模型，还是能动手的工具，甚至是能统筹安排的“小管家”（比如Agent，负责决定下一步做什么），都能当节点。
举个例子，如果你要做“查询天气并整理成文案”的任务，节点可以是：
- 大模型节点：负责理解需求（比如“查询北京今天天气”），生成工具能懂的查询指令。
- 天气工具节点：接收指令，实际去查天气数据。
- 文案节点：接收天气数据，整理成自然的话（比如“北京今天晴朗，21℃，适合户外活动”）。
简单来说，节点就是“谁来干活”，每个节点都有一个明确的任务：要么思考，要么动手。
2. 边（Edges）：连接小站的“路”，还能当“指路牌”
只有干活的“小站”还不够，还得告诉它们“怎么配合”——这就是“边”的作用。它本质是“节点之间的连接”，但不只是“传东西”，还能“做决策”。
可以把边分成两种“路”：
（1）“传送带”路：负责传数据。例如“天气工具节点”查出“北京21℃”，这条边就把这个数据送到文案节点，让文案节点有素材可用。
（2）“岔路口”路：负责做选择。例如查询天气时，可能遇到两种情况：“工具查到数据了”或“工具没查到（比如城市名错了）”。这时边就像“指路牌”：如果查到了，就把数据传给“文案节点”；如果没查到，就把“查不到”的消息传回“大模型节点”，让大模型提醒用户“是不是城市名错了”。
因此，边不仅是“路”，还是“智能指路牌”——让整个协作流程更灵活，能应对不同情况。
3. 状态空间（State）：记录全程的“共用记事本”
现在问题来了：如果流程需要“绕圈”（比如“查数据→大模型看数据不对→重新查数据”），或者多个节点需要共享信息（比如“文案节点不仅要天气数据，还要知道用户原本的需求是‘给老人看，要简单’”），该怎么记这些信息？
这就需要“状态”了——你可以把它理解成团队共用的“记事本”。
- 每次启动一个任务（比如“查询北京天气并整理成文案”），这个“记事本”就会打开。
- 每个节点干完活，都会在“记事本”上更新信息：比如天气工具节点写上“北京：晴朗，21℃”，文案节点写完文案后，再补上“最终文案：XXX”。
- 无论是“传送带”传数据，还是“岔路口”做选择，都要先看“记事本”中的内容：比如“岔路口”要判断“记事本中有没有天气数据”，再决定走哪条路。
- 直到任务结束，这个“记事本”才会关掉。
关键是，这个“记事本”不是固定的——每个节点都会动态更新它，后续的节点总能拿到最新的信息，哪怕流程绕圈也不会乱。例如大模型节点看到“记事本”中的天气数据不对，就会让天气工具节点重新查询，查询完再更新“记事本”，保证流程能顺畅走下去。
4. 总结：LangGraph其实就是“AI协作地图”
简单地说，LangGraph的逻辑可以浓缩成3个要点（见图3-3）：
- 节点=干活的“小站”（大模型、工具）。
- 边=连接小站的“路+指路牌”（传数据、做选择）。
- 状态（State）=记录全程的“共用记事本”（保证信息不丢、流程能循环）。
图3-3 协同合作的LangGraph
有了这三样，无论是简单的“查天气→写文案”，还是复杂的“分析数据→生成报告→用户提意见→修改报告”，都能像搭积木一样灵活搭建——这就是LangGraph的核心价值：让大模型和工具从“单打独斗”变成“灵活协作的团队”。
