LangChain 与 LangGraph：从 Agent 应用到可控工作流的完整工程图谱

LangChain 与 LangGraph从 Agent 应用到可控工作流的完整工程图谱摘要LangChain 解决的是“怎么更快把模型、工具、检索、结构化输出和 Agent loop 组起来”LangGraph 解决的是“当这个 Agent 变成长流程、有状态、可中断、可恢复、可观测的系统时运行时怎么管”。如果说 LangChain 像一套 AI 应用开发框架LangGraph 更像 Agent 的状态机和运行时。二者不是谁替代谁而是从高层抽象到低层控制的一条坡道。说明本文按 2026-06-06 可访问的 LangChain / LangGraph 官方文档整理主线以 LangChain v1.x 和 LangGraph v1 为准。先给结论到底该怎么理解二者关系很多人第一次接触 LangChain 和 LangGraph会卡在一个问题上它们是不是重复了是不是有了 LangGraph 就不用 LangChain或者有了 LangChain 就不用 LangGraph更清晰的理解是LangChain 是 Agent 开发框架它提供模型接口、消息格式、工具封装、结构化输出、检索、create_agent、middleware 等上层能力让你快速把 LLM 应用搭起来。LangGraph 是 Agent 编排运行时它把任务建模成有状态图核心是 State、Node、Edge、Reducer、Checkpoint、Interrupt让复杂流程能循环、分支、暂停、恢复、追踪。LangChain 的create_agent构建在 LangGraph 之上官方 v1 文档已经把create_agent作为标准 agent 入口同时说明 LangChain agents 运行在 LangGraph 的 durable runtime 上。选型不是二选一简单 Agent 先用 LangChain当你需要复杂状态、条件路由、人工审批、可恢复长任务、多 Agent 协作时下沉到 LangGraph。一句话概括用 LangChain 快速接入“模型与工具”用 LangGraph 管住“状态与执行”。为什么 Agent 应用不能只靠一次模型调用最简单的 LLM 应用是这样的用户输入问题。把 prompt 发给模型。模型返回文本。前端展示答案。这类应用适合聊天、润色、摘要、简单问答。一旦需求变成下面这些就会开始失控需要查数据库、调接口、读文件、搜网页。需要返回稳定 JSON而不是一段自然语言。需要多步推理中途根据结果决定下一步。需要 RAG从企业知识库中检索材料再回答。需要人审比如写入数据库、发邮件、下单前必须审批。需要长时间运行任务可能跨进程、跨部署、跨会话恢复。需要调试每一步模型为什么调用这个工具状态什么时候变坏哪一步开始幻觉这时问题就从“怎么问模型”变成了“怎么组织一个会行动的系统”。LangChain 和 LangGraph 的价值也正是在这里出现前者降低接入模型和工具的成本后者提供可控的执行结构。LangChain把 LLM 应用的常用积木标准化LangChain 最值得理解的地方不是“它能不能帮你少写几行代码”而是它把 LLM 应用中的常见对象标准化了。1. Models统一模型接口真实项目里很少永远只用一个模型。你可能今天用 OpenAI明天评估 Anthropic、Gemini、本地模型或公司内部模型。LangChain 的模型层提供相对统一的 chat model 接口让应用逻辑和 provider 细节之间有一层缓冲。它关注的不是“替你选择最强模型”而是让你能用一致方式处理invoke一次性调用。stream流式输出。batch批量请求。tool calling让模型请求调用外部工具。structured output让模型输出符合 schema 的结构化数据。retry / timeout / provider 参数管理调用层的可靠性。这一层很基础但非常关键。没有统一模型接口你后面做 agent、RAG、多模型切换、fallback都会被 provider 差异拖住。2. Messages把上下文变成可管理对象现代 chat model 通常不是只吃一个字符串而是吃一组 messagemessages[{role:system,content:你是一个严谨的企业知识库助手。},{role:user,content:解释一下我们系统里的订单状态流转。},]消息的价值在于它把对话历史、系统指令、工具结果、模型回复都放进一个统一结构。Agent loop 的本质就是不断向 messages 里追加“观察到的东西”再让模型基于新的上下文继续决策。但是 messages 也会带来问题越跑越长、成本越来越高、旧信息干扰新判断。所以后面你会看到LangGraph 的 state、checkpoint、memory、context management 都绕不开 messages 管理。3. Tools让模型从“会说”变成“会做”工具调用是 Agent 的分水岭。没有 tools模型只能生成文本有了 tools模型可以请求执行外部动作查天气、查库存、查订单。调内部 API。搜索企业知识库。运行代码。写文件、发消息、创建工单。LangChain 中的 tool 通常由两部分组成schema工具名、描述、参数定义。function / coroutine真正执行动作的代码。一个最小工具大概长这样fromlangchain.toolsimporttooltooldefsearch_policy(query:str)-str:Search internal policy documents by query.returnmatched policy snippets...然后你可以把工具绑定给模型或者交给create_agent处理工具循环。关键点是模型并不会真的执行工具它只是产生一个 tool call 请求。工具执行、结果回填、继续推理需要框架或你自己的代码来完成。这也是 LangChain agent 抽象存在的原因。4. Structured Output别再从自然语言里硬抠 JSON很多业务不是要“看起来像答案”的文本而是要稳定结构{intent:refund_request,order_id:A1024,risk_level:medium}旧做法常常是 prompt 里写“请只返回 JSON”然后再用json.loads()硬解析。这个办法能跑 demo但生产上会遇到一堆边界多余解释、字段缺失、类型错误、枚举值不合法、模型输出多个对象。LangChain v1 的 structured output 把这件事做成正式能力。你可以给 agent 一个 schema它会把最终结构化结果放到 agent state 的structured_response里。官方文档中提到策略上可以走 provider 原生结构化输出也可以用 tool calling 模拟结构化输出当直接传 schema 类型时LangChain 会根据模型能力自动选择策略。示例frompydanticimportBaseModel,Fieldfromlangchain.agentsimportcreate_agentclassTicket(BaseModel):intent:strField(descriptionUser intent)priority:strField(descriptionlow, medium, high)summary:stragentcreate_agent(modelprovider:model-name,tools[],response_formatTicket,)resultagent.invoke({messages:[{role:user,content:客户说退款迟迟不到账情绪很激动。}]})ticketresult[structured_response]工程上要注意结构化输出不是魔法。它能显著降低解析成本但你仍然要处理 schema 校验失败、工具调用不支持、模型能力差异、字段语义不稳定等问题。5. RetrievalRAG 的“取材料”部分RAG 的核心不是“把向量库接上”而是回答一个问题模型回答前应该看哪些外部材料一个典型 RAG 流程包括文档加载与切分。embedding。写入向量库或其他检索系统。用户提问时检索相关片段。把片段塞进上下文。让模型基于材料生成答案。LangChain 在这块提供 loader、splitter、embedding、vector store、retriever 等组件。它适合快速搭建知识库问答但生产上真正难的是chunk 怎么切才不破坏语义召回不准时怎么兜底检索结果冲突时怎么处理需要元数据过滤还是混合检索答案是否必须引用来源长上下文下是否要压缩、重排、去重所以 RAG 到最后也会变成一个 workflow而不只是一个 retriever 调用。这就是 LangGraph 能接上的地方。6. Agents用create_agent组装模型、工具和循环LangChain v1 的标准 Agent 入口是create_agent。它的目标是让常见 Agent loop 变简单fromlangchain.agentsimportcreate_agent agentcreate_agent(modelprovider:model-name,tools[search_policy,create_ticket],system_prompt你是企业客服助手。必要时查询政策创建工单前要确认。)resultagent.invoke({messages:[{role:user,content:我想退货但已经超过 7 天了。}]})你不需要手写调模型。解析 tool call。执行 tool。把 tool result 放回 messages。再调模型。循环直到 final answer。create_agent帮你处理这个主循环。更重要的是它运行在 LangGraph 之上所以可以继承 durable execution、streaming、human-in-the-loop、persistence 等底层能力。7. Middleware把复杂能力放在 Agent loop 的正确位置生产 Agent 经常需要横切能力调模型前改写 prompt。工具执行前做权限判断。工具执行失败后重试。返回用户前做 PII 检测。高风险工具调用前插入人工审批。长上下文前做 summarization。根据请求动态选择模型。如果都写进业务函数系统很快会散。LangChain v1 的 middleware 把这些能力挂到 agent loop 的不同阶段让每个 concern 有自己的位置。这和 Web 框架里的 middleware 很像业务逻辑不用关心所有横切逻辑但整个请求生命周期仍然可控。LangGraph把 Agent 运行过程建模成“有状态图”如果 LangChain 的重点是组件标准化那么 LangGraph 的重点是执行结构。LangGraph 的核心问题是当一个 LLM 应用不是一次调用而是多步、有状态、会分支、会循环、会暂停、会恢复的流程时应该怎么表达和运行答案是 graph。1. State当前世界长什么样State 是图运行时的共享状态。它不是随手传来传去的 dict而是整个 workflow 的“当前快照”。例如一个企业知识库问答可以有这样的状态fromtyping_extensionsimportTypedDictclassSupportState(TypedDict):question:strintent:strretrieved_docs:list[str]draft_answer:strneeds_approval:boolfinal_answer:str每个节点读 state并返回局部更新defclassify_intent(state:SupportState):return{intent:refund_policy}注意节点不需要返回完整 state只需要返回更新的字段。2. Reducer多个更新怎么合并如果一个字段每次都覆盖默认 reducer 就够了。但如果你要累积 messages、检索结果、日志、子任务结果就需要 reducer。比如消息列表通常不是简单覆盖而是追加或按 message id 更新。LangGraph 对 messages 提供了常用 reducer例如add_messages避免每次 state update 都把历史消息覆盖掉。这点很容易被低估。复杂 Agent 的很多 bug本质不是模型答错而是 state 合并规则错了。3. Node真正干活的函数Node 是图里的工作单元。它可以是一段普通 Python 代码。一次 LLM 调用。一次工具调用。一个检索步骤。一个校验器。一个人工审批节点。一个子图。官方文档也强调Nodes 和 Edges 本质上就是函数。不要把 LangGraph 理解成“只能写 AI 节点”的框架它更像一个适合 Agent 的状态机运行时。4. Edge下一步去哪Edge 决定节点之间的流转。最简单的是固定边builder.add_edge(START,retrieve)builder.add_edge(retrieve,answer)builder.add_edge(answer,END)更有价值的是条件边defroute_after_answer(state:SupportState):ifstate[needs_approval]:returnapprovalreturnfinalbuilder.add_conditional_edges(answer,route_after_answer,{approval:approval,final:final})这就是 LangGraph 和“串几个 LLM 调用”的本质区别流程不再是死链条而是由状态驱动的执行图。5. START、END 与 compileLangGraph 用START表示图入口用END表示终点。你定义完 state、nodes、edges 后需要compile()fromlanggraph.graphimportStateGraph,START,END builderStateGraph(SupportState)builder.add_node(retrieve,retrieve)builder.add_node(answer,answer)builder.add_edge(START,retrieve)builder.add_edge(retrieve,answer)builder.add_edge(answer,END)graphbuilder.compile()compile 会做基本结构检查也是在这里配置 checkpointer、breakpoints 等运行时能力。没有 compile图不能执行。6. Persistence让长任务能恢复LangGraph 的一个核心能力是 persistence。编译图时配置 checkpointer 后LangGraph 会在执行步骤中保存 checkpoint并按 thread 组织状态。它带来的能力包括人工审批时暂停审批后继续。对话记忆随 thread 保留。出错后从最近成功步骤恢复。回看历史状态做 time travel debugging。fork 某个 checkpoint尝试另一条执行路径。生产里有一个非常重要的点thread_id 是恢复执行的指针。如果没有稳定的 thread_id系统无法知道应该从哪个状态继续。7. Interrupt真正可落地的人审很多 Agent demo 都说支持 human-in-the-loop但实际只是“程序卡在那里等用户输入”。这不等于生产级人审。LangGraph 的 interrupt 更接近可恢复的人审节点里调用interrupt()。图保存当前 state。执行暂停把审批信息返回给外部系统。人在 UI 或后台系统里批准、拒绝或修改。外部系统用Command(resume...)恢复同一个 thread。节点从 interrupt 的位置继续拿到恢复值。一个概念示例fromlanggraph.typesimportinterrupt,Commanddefapproval_node(state:SupportState):approvedinterrupt({question:是否允许发送这段客服回复,draft_answer:state[draft_answer],})return{approved:approved}# 恢复时graph.invoke(Command(resume{approved:True}),config{configurable:{thread_id:ticket-123}})工程上要注意interrupt 前后的副作用必须幂等。因为恢复时节点可能从函数开头重新执行如果你在 interrupt 前已经写数据库、发消息、扣费就必须有 idempotency key、upsert 或事务保护。8. Memory短期记忆和长期记忆不是一回事LangGraph / LangChain 语境里的 memory 至少要分两类Short-term memorythread scoped通常是当前会话里的 messages 和相关 state。它靠 checkpointer 持久化可以恢复同一个 conversation。Long-term memory跨 thread、跨会话的用户偏好、事实、经验、规则等通常按 namespace 存在 store 里。一个常见误区是把所有历史对话都塞回 prompt。这样不仅贵还会让模型被过期信息干扰。更稳的做法是当前任务需要的上下文放 state。对话窗口太长时做裁剪或摘要。真正长期有价值的信息写入长期 memory。长期 memory 要有写入策略不要让模型随便“记住一切”。Workflow 与 Agent确定路径和动态决策的差别LangGraph 官方文档里把 workflows 和 agents 做了区分Workflow路径预先设计好按某种固定或条件逻辑运行。Agent让模型动态决定步骤和工具使用。这不是谁高级谁低级的问题。生产系统里最稳的做法往往是二者混合外层用 workflow 控制边界。内层在某些节点里使用 agent 做弹性决策。高风险动作回到确定性节点校验和审批。模式一Prompt Chaining适合任务可以拆成稳定步骤的场景生成草稿。校验格式。改写风格。输出最终版本。优点是简单、可测、容易定位问题。缺点是不够灵活如果中间状态复杂链条会越来越长。模式二Routing先分类再走不同路径。例如客服系统退款问题走退款政策检索。物流问题走物流 API。投诉问题走人工工单。无关问题直接拒答。Routing 的关键是分类结果要结构化不能只靠自然语言判断。模式三Parallelization多个独立任务并行跑最后汇总。例如写一篇行业分析一个分支查市场规模。一个分支查竞品。一个分支查技术趋势。一个分支查监管风险。并行能降延迟但汇总节点要能处理冲突和空结果。模式四Orchestrator-Worker一个 orchestrator 拆任务多个 worker 执行再由 orchestrator 汇总。这适合任务规模不确定的情况比如“分析这个仓库的所有模块”。你事先不知道要拆多少子任务需要运行时决定。模式五Evaluator-Optimizer生成一个结果再让评估器检查不合格就回到优化节点。这个模式很适合代码生成。文案生成。结构化抽取。SQL 生成。报告写作。注意不要无限循环。必须设置最大轮数、停止条件和失败兜底。模式六ReAct / Tool-Calling Agent模型根据当前上下文决定是否调用工具工具结果再回到模型上下文直到模型给出最终答案。这类 agent 灵活但也更难控。生产中建议限制工具权限。限制最大步数。对工具参数做 schema 校验。高风险工具调用前做人审。对外部结果做去毒和过滤。给 trace 和 eval 留好数据。一套企业知识库 Agent 可以怎么设计假设需求是做一个企业知识库助手。它能回答制度、流程、产品问题当答案涉及退款、赔付、合同、客户承诺时需要人工审批当知识库没有依据时要拒绝编造。版本一先用 LangChain 快速跑通你可以先用 LangChain 的 agent把检索工具和工单工具接起来frompydanticimportBaseModel,Fieldfromlangchain.agentsimportcreate_agentfromlangchain.toolsimporttooltooldefsearch_kb(query:str)-str:Search approved internal knowledge base documents.returnretrieved snippets with source idstooldefcreate_review_ticket(summary:str,draft_answer:str)-str:Create a human review ticket for risky answers.returnticket-123classSupportAnswer(BaseModel):answer:strField(descriptionAnswer to user)source_ids:list[str]Field(descriptionKnowledge base source ids)needs_review:boolrisk_reason:str|NoneNoneagentcreate_agent(modelprovider:model-name,tools[search_kb,create_review_ticket],response_formatSupportAnswer,system_prompt(你是企业知识库助手。必须基于 search_kb 返回的资料回答。如果资料不足直接说明无法确认。涉及退款、赔付、合同承诺时 needs_reviewtrue。),)resultagent.invoke({messages:[{role:user,content:客户超过 7 天还能退款吗}]})print(result[structured_response])这个版本适合验证模型是否能正确调用检索工具。知识库材料是否够用。结构化输出 schema 是否合理。哪些问题会触发风险判断。版本二用 LangGraph 管住生产流程当你要上生产建议把关键路径显式建图fromtyping_extensionsimportTypedDictfromlanggraph.graphimportStateGraph,START,ENDfromlanggraph.typesimportinterrupt,CommandclassSupportState(TypedDict):question:strintent:strdocs:list[str]draft_answer:strsource_ids:list[str]risk_level:strapproved:boolfinal_answer:strdefclassify(state:SupportState):# 可用 structured output 小模型做分类return{intent:refund_policy}defretrieve(state:SupportState):# 调 retriever / hybrid search / metadata filterreturn{docs:[policy snippet...],source_ids:[refund-policy-v3],}defdraft_answer(state:SupportState):# 基于 docs 生成答案不允许脱离资料return{draft_answer:根据现行政策超过 7 天通常不支持无理由退款但可按质量问题流程处理。,risk_level:high,}defroute_review(state:SupportState):ifstate[risk_level]high:returnapprovalreturnfinalizedefapproval(state:SupportState):decisioninterrupt({question:state[question],draft_answer:state[draft_answer],source_ids:state[source_ids],})return{approved:bool(decision[approved])}deffinalize(state:SupportState):ifstate.get(risk_level)highandnotstate.get(approved):return{final_answer:这个问题需要人工确认我已为你转交处理。}return{final_answer:state[draft_answer]}builderStateGraph(SupportState)builder.add_node(classify,classify)builder.add_node(retrieve,retrieve)builder.add_node(draft_answer,draft_answer)builder.add_node(approval,approval)builder.add_node(finalize,finalize)builder.add_edge(START,classify)builder.add_edge(classify,retrieve)builder.add_edge(retrieve,draft_answer)builder.add_conditional_edges(draft_answer,route_review,{approval:approval,finalize:finalize},)builder.add_edge(approval,finalize)builder.add_edge(finalize,END)graphbuilder.compile(checkpointercheckpointer)这时系统的关键控制点都显式了分类错了看classify。检索差了看retrieve。答案幻觉看draft_answer的 prompt 和资料约束。风险漏判看risk_level。人审卡住看 checkpoint、thread_id、interrupt payload。LangChain 与 LangGraph 怎么选可以按下面的方式判断适合直接用 LangChain 的情况你要快速验证一个 Agent idea。工具数量不多流程主要是标准 tool-calling loop。不需要复杂分支和循环。不需要任务暂停后跨进程恢复。人审只是简单确认不涉及长时间等待。你更关心模型、工具、检索、结构化输出的接入速度。这时create_agent往往够用。先别过早把系统拆成复杂图。适合下沉到 LangGraph 的情况流程有明确状态机分类、检索、生成、审核、执行、回滚。需要多轮循环评估不过就重写工具失败就换路径。需要 human-in-the-loop而且审批可能跨分钟、小时甚至天。需要 checkpoint、resume、time travel debugging。需要多 Agent 协作且不同 Agent 有不同上下文和权限。需要对每一步做监控、评估和回放。错误代价高不能让模型自由决定所有步骤。这时 LangGraph 的显式图结构会更稳。一个务实策略我的建议是三步走先用 LangChain 做最小可用版本验证工具、检索、结构化输出和模型能力。把失败案例分类看看问题来自检索、工具、prompt、模型能力、状态管理还是流程控制。只把需要控制的部分下沉到 LangGraph不要为了“架构完整”把所有东西都图化。好的 Agent 系统不是越 agentic 越好而是该灵活的地方灵活该确定的地方确定。生产工程清单下面这份清单比“会不会写 demo”更重要。1. State 设计State 不要随便塞。建议把字段分成几类输入字段用户问题、上下文 ID、权限信息。中间字段intent、检索结果、草稿、工具结果。控制字段risk_level、next_action、retry_count、approved。输出字段final_answer、source_ids、audit_log。字段名要稳定类型要清楚。状态越混乱图越难调试。2. 工具权限工具不是越多越好。工具越多模型误用工具的空间越大。建议读工具和写工具分开。高风险写工具必须审批。工具参数做 schema 校验。工具内部做权限检查不要只相信模型。外部 API 的错误要结构化返回。工具结果不要直接拼进最终答案要让回答节点基于结果生成。3. 结构化输出能结构化的地方尽量结构化尤其是意图分类。路由决策。风险等级。工具参数。最终业务对象。但是不要把所有自然语言都硬塞进复杂 schema。schema 太细会增加模型失败率也会让业务迭代变慢。4. Checkpoint 与 thread_id如果你使用 interrupt、长流程、人审、恢复必须认真设计 thread_id。建议对话类用 conversation id。工单类用 ticket id。批任务用 job id。子任务用 parent id task id。不要每次随机生成新 thread_id否则恢复能力等于没有。5. 幂等性LangGraph 文档明确提醒使用 checkpointer 后节点可能在恢复时重新执行。任何副作用都要考虑幂等写数据库用 upsert 或唯一键。发消息前记录 send id。调支付、下单、退款等外部动作必须有 idempotency key。interrupt 前尽量不做不可逆副作用。这是 Agent 上生产最容易被忽视的点。6. 观测与评估没有 trace 的 Agent 很难维护。至少要能看到每次模型输入输出。tool call 参数和结果。每个节点 state update。条件边选择了哪条路。checkpoint 历史。失败和重试原因。最终答案和用户反馈。评估上不要只看“模型感觉不错”。要维护一组 regression cases典型问题。边界问题。恶意输入。检索无结果。工具超时。人审拒绝。多轮上下文干扰。7. 安全与注入风险Agent 能调用工具后安全边界会变复杂。特别是 RAG 场景文档里可能藏 prompt injection。建议检索内容视为不可信输入。系统指令和工具权限不要放在可被检索文档覆盖的位置。写工具前做人审或策略校验。对外部网页、用户上传文件、邮件内容做来源标记。最终答案引用来源避免模型把未验证信息说成事实。常见坑坑一把所有问题都做成 Agent如果任务路径稳定用 workflow 就够了。比如“抽取字段 - 校验 - 入库”不需要让模型自由决定下一步。Agent 的自由度是成本不是装饰。坑二把 LangGraph 当画流程图工具LangGraph 的价值不只是画节点和边而是 state、checkpoint、interrupt、resume、streaming、debugging 这些运行时能力。只画一个静态 DAG却不用状态和恢复能力收益会很有限。坑三没有 reducer 意识列表字段、messages、并行结果如果合并规则没设计好状态会被覆盖、重复或乱序。很多“模型突然失忆”的问题实际是 state update 写错。坑四人审没有持久化如果审批只能在当前进程内等待那不是生产级 human-in-the-loop。真正的人审必须能跨请求、跨进程、跨部署恢复。坑五把长期记忆当垃圾桶长期记忆不是“什么都存”。错误记忆会长期污染系统。要定义什么值得记、何时记、谁能改、怎么忘、怎么审计。坑六只做 prompt 优化不做流程约束很多 Agent 可靠性问题不是 prompt 能解决的。该用 schema 的用 schema该用 deterministic rule 的用 rule该人审的人审该拒答的拒答。面试怎么讲如果面试官问“你了解 LangChain 和 LangGraph 吗”不要只说“LangChain 是链LangGraph 是图”。这个回答太浅。可以这样说LangChain 更偏上层应用开发提供模型、工具、检索、结构化输出、Agent loop 和 middleware。LangGraph 更偏底层执行编排把 Agent 流程建模成有状态图用 State、Node、Edge 和 Reducer 管理执行用 checkpoint、interrupt、thread_id 支持长任务、人审和恢复。现在 LangChain v1 的create_agent运行在 LangGraph 之上所以我通常先用 LangChain 快速验证模型和工具再把复杂状态、审批、分支和恢复逻辑下沉到 LangGraph。如果继续追问“为什么不用普通 Python 写 if else”可以这样答普通 Python 当然能写流程但当任务需要持久化状态、恢复执行、人工中断、time travel debugging、并行节点、可视化 trace 时手写控制流会越来越像自己造一个运行时。LangGraph 的价值就是把这些 Agent workflow 运行时能力标准化。如果问“LangGraph 最核心的抽象是什么”答State、Node、Edge、Reducer。State 是当前快照Node 执行业务逻辑并返回 state updateEdge 决定下一步Reducer 决定多个 update 怎么合并。compile 后可以加 checkpointer让状态在 super-step 边界保存。如果问“Agent 上生产最重要的注意点”答我会重点看四件事第一工具权限和结构化参数避免模型乱调用第二checkpoint 和 thread_id保证长流程能恢复第三副作用幂等避免恢复或重试导致重复写第四trace 和 eval保证每一步能回放和回归测试。总结LangChain 和 LangGraph 代表了 LLM 应用工程里的两层需求LangChain 让你更快把 AI 应用搭起来。LangGraph 让你在复杂任务里管住执行过程。前者解决“接入与组合”后者解决“状态与控制”。真正的生产系统往往两者都需要用 LangChain 接模型、工具、检索、结构化输出用 LangGraph 管分支、循环、审批、恢复、记忆和可观测。不要一上来就追求最复杂的 multi-agent 架构。先从一个能跑通的 LangChain agent 开始收集失败案例再把那些确实需要工程控制的地方放进 LangGraph。Agent 工程的成熟标志不是模型看起来多聪明而是系统知道什么时候该让模型发挥什么时候该让流程接管。