为什么需要LangGraph，当链式调用不够用的时候

为什么需要LangGraph当链式调用不够用的时候前面写了很多LangChain的链式调用。LLMChain、SequentialChain、路由链能处理大部分场景。但你迟早会遇到一个问题。有些任务用链式调用怎么写都别扭。任务有分支根据中间结果决定走哪条路。任务有循环做完了检查一下不满意要重来。任务有状态中间产生的信息要在多个步骤之间传递和修改。这些场景链式调用的一条直线走到底的模式就不够用了。你需要图。这一篇我们讲为什么需要LangGraph它跟LangChain的链式调用有什么区别什么时候该用它。链式调用的局限先看链式调用为什么不够用。链式调用的本质是流水线。输入进来经过一串固定的步骤输出结果。每一步的输出是下一步的输入像管道一样一路向前。这种模式简单清晰适合线性的任务。写文章、翻译、摘要这些任务从头到尾一条线用链式调用很自然。但真实世界的任务不总是线性的。条件分支。Agent执行一个任务中间需要做判断。如果搜索到了相关资料就走分析路径没搜到就走提问路径。链式调用不支持如果…就走A路径否则走B路径。循环重试。Agent写了一段代码测试发现报错了需要修改后重新测试。这个写-测-改-再测的过程是循环的。链式调用只能走一遍不能循环。状态管理。复杂任务中间会产生很多状态信息。当前进行到第几步、已经收集了哪些信息、哪些步骤完成了哪些没完成。这些状态需要在多个步骤之间共享和更新。链式调用没有显式的状态管理机制。并行执行。有些任务可以并行。同时搜索三个不同的关键词同时分析多个文档。链式调用是串行的不方便做并行。LangGraph就是用来解决这些问题的。LangGraph是什么LangGraph是LangChain团队推出的一个扩展库专门用来构建有状态的、多步骤的复杂Agent工作流。核心概念是图。把Agent的工作流表示成一个有向图。图的节点是处理步骤图的边定义了步骤之间的跳转关系。跟链式调用的区别在于图可以表达更复杂的控制流。图可以有条件边。从节点A出来根据条件决定走向节点B还是节点C。这就是条件分支。图可以有环。从节点B走到节点C再从节点C走回节点B。这就是循环。图有全局状态。所有节点共享一个状态对象每个节点可以读取和修改状态。这就是状态管理。图可以有并行节点。多个节点同时执行等全部完成后再继续。这就是并行。什么时候用LangGraph不是所有场景都需要LangGraph。简单的任务用LangChain的链式调用就够了没必要上LangGraph。LangGraph适合这些场景。多步骤决策任务。任务需要多个步骤步骤之间有依赖关系和条件判断。比如调研一个技术方案这个任务需要先搜索资料然后判断资料够不够够了就分析总结不够就换个关键词重新搜。需要反思和重试的任务。Agent做完一步以后要检查结果不对就重来。比如写代码-测试-修bug-再测试的循环。多Agent协作。多个Agent分工合作有的负责规划有的负责执行有的负责审查。Agent之间有消息传递和状态共享。复杂的状态管理。任务执行过程中需要维护复杂的状态比如对话历史、任务进度、中间结果。需要在多个步骤之间共享和更新。如果你的任务是线性的、单步的、不需要循环和分支的就用LangChain的链式调用。更简单、更好维护。如果你的任务有分支、有循环、有复杂状态就上LangGraph。一个直观的例子来看一个LangGraph能做但链式调用做不了的例子。假设我们要做一个研究Agent。用户给一个研究主题Agent先搜索资料然后判断资料够不够。够了就写总结不够就换个角度再搜。写完总结后自我检查质量不行就重写。这个工作流是这样的。搜索 - 判断够不够 - 够了 - 写总结 - 检查质量 - 不行 - 重写总结- 不够 - 换关键词 - 搜索回到第一步这里有条件判断够不够、质量行不行有循环重新搜索、重写总结有状态管理搜索到的资料、总结的内容。用链式调用没法表达这种流程。用LangGraph就可以。fromlanggraph.graphimportStateGraph,ENDfromtypingimportTypedDict,List# 定义状态classResearchState(TypedDict):topic:strsearch_results:List[str]summary:strquality_check:strsearch_count:int# 定义节点defsearch_node(state):# 搜索资料topicstate[topic]# ... 执行搜索resultsstate.get(search_results,[])results.append(f关于{topic}的搜索结果...)return{search_results:results,search_count:state.get(search_count,0)1}defjudge_node(state):# 判断资料够不够resultsstate[search_results]iflen(results)3:return{quality_check:enough}return{quality_check:not_enough}defsummarize_node(state):# 写总结resultsstate[search_results]summaryf基于{len(results)}条资料的总结...return{summary:summary}defcheck_node(state):# 检查质量summarystate[summary]iflen(summary)20:return{quality_check:good}return{quality_check:bad}# 定义条件边defshould_search_or_summarize(state):ifstate[quality_check]enough:returnsummarizereturnsearchdefshould_finish_or_rewrite(state):ifstate[quality_check]good:returnENDreturnsummarize# 构建图workflowStateGraph(ResearchState)# 添加节点workflow.add_node(search,search_node)workflow.add_node(judge,judge_node)workflow.add_node(summarize,summarize_node)workflow.add_node(check,check_node)# 设置入口workflow.set_entry_point(search)# 添加边workflow.add_edge(search,judge)workflow.add_conditional_edges(judge,should_search_or_summarize)workflow.add_edge(summarize,check)workflow.add_conditional_edges(check,should_finish_or_rewrite)# 编译appworkflow.compile()# 运行resultapp.invoke({topic:AI Agent开发,search_results:[],summary:,quality_check:,search_count:0,})print(result[summary])print(f搜索次数:{result[search_count]})这段代码定义了一个有分支、有循环的研究Agent工作流。搜索完判断够不够不够就回去再搜够了就写总结。写完检查质量不行就重写。用链式调用是写不出这种流程的。这就是LangGraph的价值。LangGraph和LangChain的关系很多人搞不清LangGraph和LangChain的关系。LangChain是基础框架提供了Chain、Agent、Tool、Memory、Retriever这些核心组件。适合大部分Agent开发场景。LangGraph是LangChain的扩展专门处理复杂的工作流。它在LangChain的基础上增加了图结构的状态管理能力。两者的关系是互补的。LangChain管基础组件LangGraph管复杂流程。实际项目里经常一起用LangGraph的节点里调用LangChain的组件。安装也很简单。pipinstalllanggraph下一篇我们深入LangGraph的核心概念。节点、边、状态、条件边每个概念怎么用有什么讲究。