新书预告《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,ENDimport bigmodelfrom pydantic import BaseModelclass AgentState(BaseModel):message:strdef chatbot(state:AgentState):messagestate.messagellm bigmodel.llmreply llm.invoke(message).contentreturn {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的核心价值让大模型和工具从“单打独斗”变成“灵活协作的团队”。