尧图网页设计 
LangChain 与 LangGraph 实战入门从链式调用到图状态编排新手第一次打开 LangChain 文档通常会有两种反应要么觉得这不就是帮我调 API 的封装吗要么被一堆概念——Chain、Agent、Memory、Retriever、Tool——砸晕。两种反应都正常但也都片面。LangChain 的真正价值不是省掉那几行 requests 代码而是把大模型应用的通用组件——模型接入、提示词管理、检索、记忆、工具调用——沉淀成标准模块让你像搭积木一样拼出业务链路。而 LangGraph 则更进一步把复杂工作流从链升级为图解决了循环、分支、状态恢复这些生产级难题。这篇文章用一个完整项目带你打通这两个框架的入门到实战。一、先搞清楚框架的定位Chain 与 Graph 的分工很多人分不清 LangChain 和 LangGraph 的关系。简单说LangGraph 是建立在 LangChain 之上的工作流编排框架二者面向不同复杂度的问题。LangChain 解决的是线性组装。它的核心抽象是 Chain链把提示模板 → 模型调用 → 输出解析串成一条流水线再支持加记忆、接检索。它适合交互模式固定的应用问答机器人、摘要工具、翻译系统。你可以把 LangChain 想象成一条流水线原料从一头进去成品从另一头出来。LangGraph 解决的是非线性编排。它的核心抽象是 Graph图节点Node是执行单元边Edge定义流转条件支持循环Agent 反复思考→行动、分支按条件走不同路径、并行多路同时执行、检查点中断后从断点恢复。它把工作流画成一张有向图每个步骤的结果存进共享状态State后续节点都能访问。用一句话记住二者分工流程是线性的用 Chain流程有循环分支用 Graph。Agent 类的自主决策系统天然带循环所以工程实践中 Agent 的主流实现是 LangGraph而不是裸的 LangChain。二、LangChain 最小实战搭一条带记忆的问答链先从最实用的场景入手搭一个能记住上下文的客服问答链。第一步统一模型接入。LangChain 把所有模型封装成统一的 ChatModel 接口切换厂商只改一行配置fromlangchain_openaiimportChatOpenAI llmChatOpenAI(modelqwen-plus,api_keyyour-key,base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1,temperature0.3,) 第二步设计提示词模板。不要直接拼字符串用 PromptTemplate 把变量和模板分离 pythonfromlangchain.promptsimportPromptTemplate template你是一位耐心的电商客服。 用户问题{question} 请用不超过 100 字回答。promptPromptTemplate.from_template(template)第三步加上记忆。LangChain 记忆机制的本质是保存历史 → 下一轮重新注入提示词用MessagesPlaceholder在模板里占位fromlangchain.memoryimportConversationBufferMemoryfromlangchain_core.promptsimportMessagesPlaceholder memoryConversationBufferMemory(return_messagesTrue)promptChatPromptTemplate.from_messages([(system,你是电商客服回答简洁专业),MessagesPlaceholder(variable_namehistory),(human,{input}),])chainprompt|llm# LangChain 0.3 的管道语法第四步跑起来并管理历史resultchain.invoke({input:我的订单 3 天没到货怎么回事,history:memory.chat_memory.messages})memory.chat_memory.add_user_message(我的订单 3 天没到货)memory.chat_memory.add_ai_message(result.content)注意生产环境要用ConversationBufferWindowMemory只保留最近 N 轮或ConversationSummaryMemory把旧对话摘要压缩否则历史无限膨胀token 成本爆炸。三、LangGraph 核心概念State、Node、EdgeLangGraph 的思维模型和传统编程差异很大建议先建立三个概念State状态工作流执行中需要保存和传递的数据是一个 TypedDict。每个节点的返回值都会合并进 State后续节点可以读取。这是 LangGraph 与普通函数调用的本质区别——状态是显式的、跨节点共享的。Node节点一个执行单元接收 State返回 State 的一部分。节点里可以是模型调用、工具调用、任意 Python 函数。Edge边定义节点之间的流转关系。普通边是执行完 A 去 B条件边是根据 State 里的字段决定去哪个分支还有 START 和 END 两个特殊节点标记工作流的起点和终点。fromtypingimportTypedDict,Annotatedfromlanggraph.graphimportStateGraph,ENDclassState(TypedDict):question:strplan:stranswer:strdefplan_node(state:State)-dict:# 调用模型生成执行计划return{plan:1. 检索资料 2. 组织回答}defanswer_node(state:State)-dict:return{answer:f根据计划[{state[plan]}]这是最终答案}graphStateGraph(State)graph.add_node(plan,plan_node)graph.add_node(answer,answer_node)graph.add_edge(plan,answer)graph.add_edge(answer,END)graph.set_entry_point(plan)appgraph.compile()resultapp.invoke({question:帮我分析一下竞品})这个例子很简单但它揭示了 LangGraph 的核心价值流程可见、可控、可恢复。真实项目中节点之间的流转会变成这样“先判断用户意图 → 意图是查资料就走 RAG 分支 → 是算数据就走代码执行分支 → 失败就进入降级节点”。这种多分支流程用 if-else 硬写会变成意大利面条用图来表达则一目了然。四、LangGraph 实战做一个带工具调用的研究助手接下来做一个真正有价值的案例一个研究助手 Agent——用户抛出一个问题Agent 自己决定是直接回答还是先调用搜索工具找资料再综合成答案。这正是Agent 与普通链的分水岭模型不再是一次输出而是进入思考→行动→观察→再思考的循环。先定义两个工具搜索和计算。工具的description极其重要因为模型就是靠它判断什么时候该用哪个工具fromlangchain_core.toolsimporttooltooldefweb_search(query:str)-str:在互联网上搜索最新信息。当问题涉及实时数据、新闻或外部资料时使用。returnsearch_engine(query)tooldefcalculator(expression:str)-str:执行数学计算。当用户要求计算、比较数字时使用。returnstr(eval(expression)) 然后让模型具备工具决策能力把工具以 JSON Schema 形式注入请求模型返回的响应中会携带 tool_calls 字段指示我想调用哪个工具、传什么参数。你的代码执行工具后把结果以 tool 角色消息回传给模型模型继续生成。 pythonfromlanggraph.prebuiltimportcreate_react_agent agentcreate_react_agent(llm,tools[web_search,calculator],prompt你是一个严谨的研究助手先思考需要什么信息再决定是否调用工具。,) create_react_agent 是 LangGraph 提供的现成 Agent 实现它内置了完整的思考-行动-观察循环模型每轮先判断要不要调工具调用后拿到结果再判断下一步直到它认为可以输出最终答案或触发停止条件。这个预构建 Agent 非常适合快速验证但生产系统通常要自己定制循环——增加最大步数限制、超时熔断、目标达成判定防止模型死循环或跑偏。## 五、LangSmith 与可观测性调试 Agent 的必备工具手写 Agent 循环最痛苦的是黑盒模型到底在想什么为什么它调了那个工具哪个节点的状态出了问题LangSmith 解决的就是这个问题——它把每一次运行的完整轨迹记录下来每个节点的输入输出、模型调用详情、token 消耗、耗时。 接入非常简单设置两个环境变量即可 bash export LANGSMITH_TRACINGtrue export LANGSMITH_API_KEYyour-key之后每次invoke会自动上报轨迹你可以在 LangSmith 控制台看到一张可交互的调用图从用户提问开始哪个节点做了规划、哪个节点调了工具、工具返回了什么、最终答案怎么生成全部可视。调试时还能直接回放某次失败运行对比不同 prompt 的效果差异。我的建议是从项目第一天就接上追踪不要等出了问题再补。Agent 类应用的调试成本远高于普通后端一份完整的调用轨迹能帮你省掉大量的猜测时间。六、工程实践从 Demo 到生产的四个关键改造框架能帮你把 Demo 跑起来但生产环境有一堆框架不管的事需要你自己补上第一状态持久化。LangGraph 的 State 默认在内存里进程重启就丢。生产环境配置checkpointer如 SqliteSaver 或 PostgresSaver让任务状态持久化到数据库这样长任务中断后可以从断点恢复也支持并发任务的隔离。多用户系统里State 还要带上 user_id防止会话串号。第二循环控制与预算。Agent 循环必须有硬性边界最大执行步数比如 10 步、单步超时比如 30 秒、总 token 预算。否则一个失控的 Agent 可能在失败的工具上反复重试把账单烧穿。LangGraph 支持RecursionLimit超出后强制终止并走降级路径。第三工具安全。Agent 能调用的工具就是它的能力边界也是安全边界。所有工具要做参数校验防止注入恶意参数、权限校验区分管理员工具与普通用户工具、敏感操作二次确认删除、转账类操作必须人工确认。还要在 prompt 里约束模型工具只做它该做的事。第四错误降级。Agent 不是每次都成功的。设计上要预设失败路径模型输出格式错误 → 重试一次工具调用失败 → 换工具或告知用户整体失败 → 返回兜底答案并记录日志。生产系统的可靠性不是靠模型足够聪明而是靠失败时有退路。七、框架之外什么时候别用框架最后说点反共识的不是所有场景都需要 LangChain 或 LangGraph。如果你的应用只是调 API 拼 prompt手写一个几百行的调用封装可能比引入框架更清爽——少一层抽象少一堆版本兼容问题。框架的价值在于帮你处理通用但繁琐的能力记忆、检索、工具注册、状态管理当这些能力你确实需要且系统复杂度足够高时它们才真正划算。判断标准很简单如果业务逻辑里的分支和循环超过三四个或者你需要跨重启恢复任务状态就值得上 LangGraph如果只是几条固定流程Chain 甚至裸代码都够用。技术选型没有银弹匹配需求才是最好的方案。结语LangChain 和 LangGraph 代表的不是某个库而是一种工程思维把大模型应用的通用能力沉淀为模块把复杂流程建模为可见可控的图。入门它们的正确路径不是背文档而是带着真实业务问题去实践——先搭一条链再升级成图最后补齐状态、追踪、降级这些生产细节。当你亲手把一个会循环决策的 Agent 跑起来并能在控制台里看清它每一步的思考过程时你才真正跨过了会用框架到会造系统的门槛。 LangChain 与 LangGraph 实战入门：从链式调用到图状态编排
LangChain 与 LangGraph 实战入门从链式调用到图状态编排新手第一次打开 LangChain 文档通常会有两种反应要么觉得这不就是帮我调 API 的封装吗要么被一堆概念——Chain、Agent、Memory、Retriever、Tool——砸晕。两种反应都正常但也都片面。LangChain 的真正价值不是省掉那几行 requests 代码而是把大模型应用的通用组件——模型接入、提示词管理、检索、记忆、工具调用——沉淀成标准模块让你像搭积木一样拼出业务链路。而 LangGraph 则更进一步把复杂工作流从链升级为图解决了循环、分支、状态恢复这些生产级难题。这篇文章用一个完整项目带你打通这两个框架的入门到实战。一、先搞清楚框架的定位Chain 与 Graph 的分工很多人分不清 LangChain 和 LangGraph 的关系。简单说LangGraph 是建立在 LangChain 之上的工作流编排框架二者面向不同复杂度的问题。LangChain 解决的是线性组装。它的核心抽象是 Chain链把提示模板 → 模型调用 → 输出解析串成一条流水线再支持加记忆、接检索。它适合交互模式固定的应用问答机器人、摘要工具、翻译系统。你可以把 LangChain 想象成一条流水线原料从一头进去成品从另一头出来。LangGraph 解决的是非线性编排。它的核心抽象是 Graph图节点Node是执行单元边Edge定义流转条件支持循环Agent 反复思考→行动、分支按条件走不同路径、并行多路同时执行、检查点中断后从断点恢复。它把工作流画成一张有向图每个步骤的结果存进共享状态State后续节点都能访问。用一句话记住二者分工流程是线性的用 Chain流程有循环分支用 Graph。Agent 类的自主决策系统天然带循环所以工程实践中 Agent 的主流实现是 LangGraph而不是裸的 LangChain。二、LangChain 最小实战搭一条带记忆的问答链先从最实用的场景入手搭一个能记住上下文的客服问答链。第一步统一模型接入。LangChain 把所有模型封装成统一的 ChatModel 接口切换厂商只改一行配置fromlangchain_openaiimportChatOpenAI llmChatOpenAI(modelqwen-plus,api_keyyour-key,base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1,temperature0.3,) 第二步设计提示词模板。不要直接拼字符串用 PromptTemplate 把变量和模板分离 pythonfromlangchain.promptsimportPromptTemplate template你是一位耐心的电商客服。 用户问题{question} 请用不超过 100 字回答。promptPromptTemplate.from_template(template)第三步加上记忆。LangChain 记忆机制的本质是保存历史 → 下一轮重新注入提示词用MessagesPlaceholder在模板里占位fromlangchain.memoryimportConversationBufferMemoryfromlangchain_core.promptsimportMessagesPlaceholder memoryConversationBufferMemory(return_messagesTrue)promptChatPromptTemplate.from_messages([(system,你是电商客服回答简洁专业),MessagesPlaceholder(variable_namehistory),(human,{input}),])chainprompt|llm# LangChain 0.3 的管道语法第四步跑起来并管理历史resultchain.invoke({input:我的订单 3 天没到货怎么回事,history:memory.chat_memory.messages})memory.chat_memory.add_user_message(我的订单 3 天没到货)memory.chat_memory.add_ai_message(result.content)注意生产环境要用ConversationBufferWindowMemory只保留最近 N 轮或ConversationSummaryMemory把旧对话摘要压缩否则历史无限膨胀token 成本爆炸。三、LangGraph 核心概念State、Node、EdgeLangGraph 的思维模型和传统编程差异很大建议先建立三个概念State状态工作流执行中需要保存和传递的数据是一个 TypedDict。每个节点的返回值都会合并进 State后续节点可以读取。这是 LangGraph 与普通函数调用的本质区别——状态是显式的、跨节点共享的。Node节点一个执行单元接收 State返回 State 的一部分。节点里可以是模型调用、工具调用、任意 Python 函数。Edge边定义节点之间的流转关系。普通边是执行完 A 去 B条件边是根据 State 里的字段决定去哪个分支还有 START 和 END 两个特殊节点标记工作流的起点和终点。fromtypingimportTypedDict,Annotatedfromlanggraph.graphimportStateGraph,ENDclassState(TypedDict):question:strplan:stranswer:strdefplan_node(state:State)-dict:# 调用模型生成执行计划return{plan:1. 检索资料 2. 组织回答}defanswer_node(state:State)-dict:return{answer:f根据计划[{state[plan]}]这是最终答案}graphStateGraph(State)graph.add_node(plan,plan_node)graph.add_node(answer,answer_node)graph.add_edge(plan,answer)graph.add_edge(answer,END)graph.set_entry_point(plan)appgraph.compile()resultapp.invoke({question:帮我分析一下竞品})这个例子很简单但它揭示了 LangGraph 的核心价值流程可见、可控、可恢复。真实项目中节点之间的流转会变成这样“先判断用户意图 → 意图是查资料就走 RAG 分支 → 是算数据就走代码执行分支 → 失败就进入降级节点”。这种多分支流程用 if-else 硬写会变成意大利面条用图来表达则一目了然。四、LangGraph 实战做一个带工具调用的研究助手接下来做一个真正有价值的案例一个研究助手 Agent——用户抛出一个问题Agent 自己决定是直接回答还是先调用搜索工具找资料再综合成答案。这正是Agent 与普通链的分水岭模型不再是一次输出而是进入思考→行动→观察→再思考的循环。先定义两个工具搜索和计算。工具的description极其重要因为模型就是靠它判断什么时候该用哪个工具fromlangchain_core.toolsimporttooltooldefweb_search(query:str)-str:在互联网上搜索最新信息。当问题涉及实时数据、新闻或外部资料时使用。returnsearch_engine(query)tooldefcalculator(expression:str)-str:执行数学计算。当用户要求计算、比较数字时使用。returnstr(eval(expression)) 然后让模型具备工具决策能力把工具以 JSON Schema 形式注入请求模型返回的响应中会携带 tool_calls 字段指示我想调用哪个工具、传什么参数。你的代码执行工具后把结果以 tool 角色消息回传给模型模型继续生成。 pythonfromlanggraph.prebuiltimportcreate_react_agent agentcreate_react_agent(llm,tools[web_search,calculator],prompt你是一个严谨的研究助手先思考需要什么信息再决定是否调用工具。,) create_react_agent 是 LangGraph 提供的现成 Agent 实现它内置了完整的思考-行动-观察循环模型每轮先判断要不要调工具调用后拿到结果再判断下一步直到它认为可以输出最终答案或触发停止条件。这个预构建 Agent 非常适合快速验证但生产系统通常要自己定制循环——增加最大步数限制、超时熔断、目标达成判定防止模型死循环或跑偏。## 五、LangSmith 与可观测性调试 Agent 的必备工具手写 Agent 循环最痛苦的是黑盒模型到底在想什么为什么它调了那个工具哪个节点的状态出了问题LangSmith 解决的就是这个问题——它把每一次运行的完整轨迹记录下来每个节点的输入输出、模型调用详情、token 消耗、耗时。 接入非常简单设置两个环境变量即可 bash export LANGSMITH_TRACINGtrue export LANGSMITH_API_KEYyour-key之后每次invoke会自动上报轨迹你可以在 LangSmith 控制台看到一张可交互的调用图从用户提问开始哪个节点做了规划、哪个节点调了工具、工具返回了什么、最终答案怎么生成全部可视。调试时还能直接回放某次失败运行对比不同 prompt 的效果差异。我的建议是从项目第一天就接上追踪不要等出了问题再补。Agent 类应用的调试成本远高于普通后端一份完整的调用轨迹能帮你省掉大量的猜测时间。六、工程实践从 Demo 到生产的四个关键改造框架能帮你把 Demo 跑起来但生产环境有一堆框架不管的事需要你自己补上第一状态持久化。LangGraph 的 State 默认在内存里进程重启就丢。生产环境配置checkpointer如 SqliteSaver 或 PostgresSaver让任务状态持久化到数据库这样长任务中断后可以从断点恢复也支持并发任务的隔离。多用户系统里State 还要带上 user_id防止会话串号。第二循环控制与预算。Agent 循环必须有硬性边界最大执行步数比如 10 步、单步超时比如 30 秒、总 token 预算。否则一个失控的 Agent 可能在失败的工具上反复重试把账单烧穿。LangGraph 支持RecursionLimit超出后强制终止并走降级路径。第三工具安全。Agent 能调用的工具就是它的能力边界也是安全边界。所有工具要做参数校验防止注入恶意参数、权限校验区分管理员工具与普通用户工具、敏感操作二次确认删除、转账类操作必须人工确认。还要在 prompt 里约束模型工具只做它该做的事。第四错误降级。Agent 不是每次都成功的。设计上要预设失败路径模型输出格式错误 → 重试一次工具调用失败 → 换工具或告知用户整体失败 → 返回兜底答案并记录日志。生产系统的可靠性不是靠模型足够聪明而是靠失败时有退路。七、框架之外什么时候别用框架最后说点反共识的不是所有场景都需要 LangChain 或 LangGraph。如果你的应用只是调 API 拼 prompt手写一个几百行的调用封装可能比引入框架更清爽——少一层抽象少一堆版本兼容问题。框架的价值在于帮你处理通用但繁琐的能力记忆、检索、工具注册、状态管理当这些能力你确实需要且系统复杂度足够高时它们才真正划算。判断标准很简单如果业务逻辑里的分支和循环超过三四个或者你需要跨重启恢复任务状态就值得上 LangGraph如果只是几条固定流程Chain 甚至裸代码都够用。技术选型没有银弹匹配需求才是最好的方案。结语LangChain 和 LangGraph 代表的不是某个库而是一种工程思维把大模型应用的通用能力沉淀为模块把复杂流程建模为可见可控的图。入门它们的正确路径不是背文档而是带着真实业务问题去实践——先搭一条链再升级成图最后补齐状态、追踪、降级这些生产细节。当你亲手把一个会循环决策的 Agent 跑起来并能在控制台里看清它每一步的思考过程时你才真正跨过了会用框架到会造系统的门槛。