写在前面我开始做RAG应用时LangChain的SequentialChain和RetrievalQA已经足够解决大部分问题。后来社区开始讨论LangGraph我当时的反应是“又一个过度设计的框架”直到我尝试构建一个需要多轮反思、工具调用、状态持久化的Agent时才发现Chain的线性执行模型根本兜不住。本文不会劝你弃用LangChain而是帮你理清什么时候Chain足够什么时候必须上Graph以及两者如何协同。一、LangChain线性的“管道”适合大多数任务LangChain最核心的抽象是Chain——一个将多个组件LLM、Prompt、检索器、工具串行连接起来的管道。# 一个典型的RAG Chain from langchain.chains import RetrievalQA qa_chain RetrievalQA.from_chain_type( llmllm, retrievervector_store.as_retriever() ) result qa_chain.invoke({query: 什么是RAG})这个链的执行是确定性的、单向的输入 → 检索 → LLM → 输出。没有任何分支、循环或状态记忆。Chain的局限无法实现“如果答案不够好再检索一次”的逻辑无法在多轮对话中维护复杂状态虽然ConversationBufferMemory可以但它是外部存储不是执行流的一部分无法并行执行多个分支无法在执行过程中暂停、等待人工输入、然后恢复但对于80%的RAG和简单问答场景Chain已经足够。这也是为什么很多开发者觉得“LangGraph没用”。二、LangGraph有状态的图为复杂Agent而生LangGraph把任务建模为图Graph节点Node执行操作边Edge定义流向并引入状态State在节点间传递。最关键的是它支持循环和条件分支。from langgraph.graph import StateGraph, END class AgentState(TypedDict): messages: list iteration: int graph StateGraph(AgentState) # 添加节点 graph.add_node(think, think_node) graph.add_node(act, act_node) graph.add_node(reflect, reflect_node) # 添加条件边 graph.add_conditional_edges( think, should_continue, {True: act, False: END} ) graph.add_edge(act, reflect) graph.add_edge(reflect, think) # 循环这种图结构天然支持循环Agent反复“思考-行动-观察”直到任务完成分支根据不同条件走不同路径并行多个节点同时执行状态持久化图执行过程中的状态可以序列化、暂停、恢复三、核心区别一张表看懂一个形象的类比Chain 工厂流水线传送带一直往前走不可回头Graph 地铁线路图可以在不同线路间换乘、环线、重复坐下图直观对比了两者的执行模式四、为什么你觉得“LangChain就够了”因为你遇到的任务大多是单轮或线性多轮的✅ 单轮知识问答RAG✅ 固定流程的数据处理加载→拆分→嵌入→存储✅ 带记忆的简单聊天ConversationChain这些场景下Chain的简单性反而是优势。LangGraph不会带来任何收益只会增加复杂度。但是当你需要以下能力时Chain就会力不从心自我反思Agent先回答然后自我评估是否满意不满意就重新检索或重新生成。多工具协同先调用搜索工具根据搜索结果决定下一步是调用计算器还是数据库查询。人机协作Agent遇到不确定的问题时暂停并询问用户收到回复后继续执行。多Agent辩论多个Agent各执一词最后综合答案。长时间运行的任务需要持久化执行状态随时中断和恢复。下面这个例子展示了一个需要循环的Agent场景用LangChain实现这种循环你只能手动写while循环并自己管理状态。而LangGraph把这些模式固化为框架能力。五、实战对比用两者实现同一个“反思式RAG”需求用户提问后Agent检索知识库生成答案然后自我评估答案是否基于检索内容。如果发现“幻觉”则重新检索并生成。使用LangChain需要hackdef reflective_rag(question, max_iter3): for i in range(max_iter): docs retriever.get_relevant_documents(question) answer llm.predict(fContext: {docs}\nQ: {question}) critique llm.predict(fIs this answer based on the context? Answer yes/no. Answer: {answer}) if yes in critique.lower(): return answer # 否则继续循环但需要修改question或检索策略 question fBased on the documents: {docs}\nRe-answer: {question} return 无法给出可靠答案问题手动管理循环、状态、退出条件代码杂乱。使用LangGraph原生支持from langgraph.graph import StateGraph, END from langgraph.checkpoint import MemorySaver class ReflectiveState(TypedDict): question: str docs: list answer: str critique: str iteration: int def retrieve(state): state[docs] retriever.get_relevant_documents(state[question]) return state def generate(state): state[answer] llm.predict(fContext: {state[docs]}\nQ: {state[question]}) return state def evaluate(state): critique llm.predict(fIs answer based on context? Answer: {state[answer]}) state[critique] critique state[iteration] 1 return state def should_continue(state): if yes in state[critique].lower() or state[iteration] 3: return END return generate # 重新生成 builder StateGraph(ReflectiveState) builder.add_node(retrieve, retrieve) builder.add_node(generate, generate) builder.add_node(evaluate, evaluate) builder.set_entry_point(retrieve) builder.add_edge(retrieve, generate) builder.add_edge(generate, evaluate) builder.add_conditional_edges(evaluate, should_continue) graph builder.compile(checkpointerMemorySaver())优势清晰、可扩展、自带状态持久化、可随时中断恢复。六、总结不是替代而是互补LangChain是工具箱LLM、PromptTemplate、Retriever、Tool、Chain适合快速构建线性流程。LangGraph是工作流编排器基于图适合需要循环、分支、状态持久化的复杂Agent。选型建议一个形象的总结LangChain是自行车——简单、轻便、80%的场景够用。LangGraph是汽车——复杂、强大、需要时才能体现价值。你不会每天开着汽车去买菜但长途旅行时自行车到不了。如果你现在只用LangChain就能满足需求请继续用。当你遇到“这个Agent为什么总是重复同样错误”、“怎么让人工介入”、“如何实现反思”时再来学习LangGraph——它会让你豁然开朗。