如果你正在用 Python 做 Agent 开发你一定绕不开两个名字LangChain和LangGraph。它们经常被放在一起提起但很多刚入门的朋友其实分不清——它们到底有什么区别谁负责什么能不能只用其中一个这篇文章就用一个你一定能听懂的类比把这两个框架的关系彻底讲清楚。先回到原点Agent 开发到底需要什么在聊框架之前我们先快速对齐一个认知开发一个 Agent本质上是在造一个会思考、会干活的助手。这个助手需要具备哪些能力能调用大模型理解用户意图、生成回复能使用外部工具搜索、查数据库、调用 API能按照一定的逻辑链条去执行任务先做什么、再做什么、遇到异常怎么处理能在执行过程中记住上下文状态上一步的结果要传给下一步这就引出了两个层次的需求基础组件的供给和任务流程的编排。而 LangChain 和 LangGraph恰好各自解决其中一个问题。LangChainPython Agent 开发的「乐高积木套装」LangChain 是什么你可以把 LangChain 想象成一个巨大的乐高积木套装。打开这个盒子你拿到的是模型积木统一调用 OpenAI、Claude、国产大模型等各种 LLM 的接口换模型就像换一块积木提示模板积木用结构化的方式管理 Prompt支持变量插值、少样本示例等工具积木把搜索、计算器、数据库查询、API 调用包装成模型可调用的标准工具检索积木对接向量数据库、文档加载器、嵌入模型快速搭建 RAG 链路链式调用积木把上述积木串成一个简单的线性链路Chain比如检索 → 拼接上下文 → 发给模型 → 返回答案LangChain 的定位就是把 AI 开发中高频使用的组件全部标准化、模块化。你不用关心每个大模型的 API 差异不用重复写文档切分和向量化的代码——积木已经给你准备好了拿来就能拼。但问题来了有了一堆积木你就能搭出一个复杂的 Agent 吗能——但只能搭出「线性结构」。就像用积木搭一根直直的长条从 A 到 B 到 C一路到底。而真正的 Agent 工作流远不止于此它需要条件分支“如果搜索结果为空换一个关键词重新搜”、需要循环“继续调用工具直到拿到满意结果”、需要状态管理“记住用户三回合前提到的那个参数”。这时候LangGraph 出场了。LangGraphAgent 工作流的「搭建图纸 装配线」LangGraph 是什么如果 LangChain 是积木套装那LangGraph 就是搭建图纸外加一条智能装配线。它的核心概念只有两个图Graph和状态State。图的思维把任务变成节点 边LangGraph 让你用有向图来描述 Agent 的工作流每个节点Node代表一个具体的步骤——比如调用模型思考、“执行某个工具”、“汇总结果”每条边Edge代表步骤之间的流转——可以是无条件走下一步也可以是根据条件选择走 A 还是走 B这就从一根筋走到底变成了灵活的多分支网络。ReAct 模式思考 → 行动 → 观察 → 再思考用图来表达再自然不过一个循环边把观察节点指回思考节点Agent 就能反复迭代直到完成任务。状态的思维让 Agent 拥有记忆LangGraph 另一个关键设计是内建的状态管理。整个图的每一步执行都会读写一个共享的 State 对象。这意味着上一步工具返回的结果下一步模型能自动看到多轮对话的上下文不会丢失你可以在任意节点插入人工审核Human-in-the-loop暂停流程、修改状态、再继续执行如果用一句话总结 LangGraph 的定位它不提供积木它定义积木怎么拼、按什么顺序拼、拼的过程中怎么记住已经拼到哪了。它们怎么配合——积木 图纸的协作模式讲了这么多最直观的理解方式就是回到那个类比LangChain 负责「有什么可以用」LangGraph 负责「按什么逻辑用」。在实际项目中它们的协作模式是这样的你用LangChain封装模型调用、定义工具、配置检索器、写好提示模板——把零件都准备好你用LangGraph画一张图定义节点每个节点里调用 LangChain 准备好的组件、定义边包括条件边和循环边、定义 State 的结构编译图跑起来——LangGraph 的运行时引擎就会按照图纸自动调度每个节点、管理状态流转、处理异常分支你写的代码大致长这样伪代码示意# LangChain 负责准备零件fromlangchain_core.toolsimporttoolfromlangchain_openaiimportChatOpenAI llmChatOpenAI(modelgpt-4)tooldefsearch(query:str)-str:搜索工具returnf搜索结果关于{query}的信息...tools[search]llm_with_toolsllm.bind_tools(tools)# LangGraph 负责编排流程fromlanggraph.graphimportStateGraph,MessagesState,START,ENDdefcall_model(state:MessagesState):return{messages:[llm_with_tools.invoke(state[messages])]}defshould_continue(state:MessagesState):last_msgstate[messages][-1]iflast_msg.tool_calls:returntools# 需要调工具走工具分支returnEND# 否则结束builderStateGraph(MessagesState)builder.add_node(agent,call_model)builder.add_node(tools,ToolNode(tools))builder.add_edge(START,agent)builder.add_conditional_edges(agent,should_continue)builder.add_edge(tools,agent)# 工具结果返回 agent形成循环graphbuilder.compile()你看LangChain 提供了ChatOpenAI、tool装饰器、bind_tools这些零件而 LangGraph 提供了StateGraph、条件边、循环边这些编排能力。两者分工明确谁也替代不了谁。为什么不用其中一个就够了你可能还会问我就写个简单的问答机器人非要用两个框架吗实话实说——简单的场景确实可以只用 LangChain。一个create_retrieval_chain配上RunnablePassthrough几行代码就能跑起来。但一旦你的需求升级到以下任何一种情况LangGraph 就变成刚需Agent 需要多次工具调用且结果之间相互依赖需要在工具执行前后插入人工审核节点需要并行执行多个子任务再汇总执行链路存在复杂的分支和异常处理需要持久化状态支持暂停恢复现实是绝大部分有实际价值的 Agent 都会走到这些场景。这也是为什么 LangChain 官方现在把 LangGraph 作为构建 Agent 的首选方案——它承认单纯的链式调用已经不够用了。Python 生态的优势与代价最后聊一点来自实践的真实体感。结合第二篇文章的选型分析Python 生态做 Agent 开发有一个很鲜明的特点上手极快但要写好、写稳需要额外的工程纪律。Python 的动态类型让你几小时内就能跑通一个 DemoLangChain 加上 LangGraph 的组合让复杂工作流的开发体验非常顺滑。但当项目体量变大、团队成员变多、需要长期维护时缺乏编译时检查的问题就会逐渐显现——一个函数签名的改动可能要到线上才暴露代码读起来也需要大量脑内推断类型。这不是说 Python 不好而是提醒你选 Python 框架做 Agent意味着你享受了最高效的从零到一但同时需要主动建立类型约束、单元测试、代码审查这些工程习惯来对冲长期维护的风险。如果你本身是 Python 生态的开发者这个成本是可控的如果团队以 Java 或 Go 为主那去看 Spring AI Alibaba 或 Eino 可能是更自然的选择。但无论选哪个语言LangChain LangGraph 所定义的组件化 图编排这套思想都是 Agent 开发的通用范式值得理解透彻。一句话总结LangChain 是乐高积木套装——它告诉你能用什么零件LangGraph 是搭建图纸和装配线——它告诉你零件怎么拼、按什么顺序拼、拼到一半出问题了怎么办。两者各司其职合在一起才是 Python Agent 开发的完整工具箱。