面试官LangGraph 相比 LangChain 有什么优势♂️我LangChain 只能写线性 ChainLangGraph 才支持分支、循环和 Agent。面试官这还是早期教程里的印象。LangChain v1 的create_agent本身就是基于 LangGraph 构建的图运行时标准 Agent loop 本来就有循环和条件路由。♂️我那 LangGraph 的优势就是多了一张流程图复杂项目用它看起来更高级。面试官图不是装饰。State、节点边界、并行汇合、检查点、中断与恢复都要进入执行语义只画一张图解决不了可靠性问题。♂️我懂了只要项目要持久化、流式输出或记忆就必须抛弃 LangChain全部改成 LangGraph。面试官又把上下层说成二选一了。LangChain Agent 已经继承这些底层能力。真正需要下沉到 LangGraph 的时机是标准 Agent loop 不足以表达业务流程而不是看到某个功能名就重写项目。这道题要回答好的关键是把「功能有没有」换成「开发者需要把控制精确到哪一层」。──── 简要回答────我会先纠正一个前提LangGraph 和 LangChain 不是互斥的两套 Agent 框架。LangChain v1 提供模型、工具、中间件和预构建 Agent loopcreate_agent本身就运行在 LangGraph 上LangGraph 是更低层的编排框架与运行时让开发者直接控制 State、节点、边、路由、并行、子图、中断和恢复。因此LangGraph 的核心优势不是「LangChain 没有这些能力」而是把复杂 Agent 的运行过程变成显式、可持久化、可观察、可恢复的业务状态机。我们既可以用StateGraph声明拓扑和共享状态也可以用 Functional API 在普通 Python 控制流上增加检查点与恢复能力。当任务会持续很久、必须人工审批、要从故障点继续或者需要并行研究与多 Agent 协作时LangGraph 的优势最明显。Checkpointer 保存线程内状态快照Store 保存跨线程长期记忆interrupt()可以暂停任意业务节点时间旅行可以从旧 checkpoint 重放或分叉节点级容错则让失败路径也能被建模。如果需求只是常见的「模型选择工具 - 调用工具 - 返回模型」循环我会优先使用 LangChaincreate_agent再用 middleware 完成提示词、重试、护栏和审批等定制。只有当业务拓扑、恢复边界或多角色协作成为主要复杂度时我才直接使用 LangGraph也常把 LangChain Agent 作为图中的节点或子图复用。──── 详细解析────两者为什么不对立很多林友听到「相比」两个字就会下意识列一张功能表LangChain 有模型和工具LangGraph 有状态、循环和持久化。这个答法看似清楚实际会制造一个错误前提好像用了 LangChain 就没有 LangGraph 的运行能力。打个比方LangChain 像一辆已经装好方向盘、刹车和导航的汽车日常驾驶直接用就行LangGraph 更像开放底盘、动力分配和道路控制系统。当业务真的需要多路调度、途中停车、事故恢复和路线回放时底层控制才会成为核心价值。对应到开发中LangChain 帮我们快速获得一个常见形态的 AgentLangGraph 让我们继续向下控制完整业务流程例如任务在哪暂停、失败后从哪恢复、过程如何持续反馈给用户。截至 2026 年 7 月官方也把 LangChain 定位为高层 Agent 框架把 LangGraph 定位为低层编排框架与运行时。LangChain v1 的create_agent会构建一个基于 LangGraph 的图运行时所以两者不是互斥关系。因此后面提到的持久化、流式输出和人工介入并不是在说 LangChain Agent 无法获得这些能力。真正的优势是直接使用 LangGraph 时我们能决定这些能力放在哪个节点、围绕哪些状态生效、失败后从哪里恢复以及不同子流程如何组合。为什么要把流程与状态摊开为什么标准工具调用 Agent 一复杂就容易让人失去控制因为模型通常既在理解问题又在决定下一步做什么。流程只有两三个工具时问题不大。可一旦加入权限校验、并行取证、质量评估、人工审批和失败补偿把所有规则塞进 Prompt就等于把业务流程交给一个概率模型临场发挥。LangGraph 的核心价值是让确定性规则与模型决策各自待在合适的位置。需要模型判断的步骤交给 Agent需要严格执行的权限、金额阈值、审批顺序和结束条件写成节点与边。这样模型仍然有自主性但自主性被放在明确的护栏里。拿采购流程来说State 就像一张不断补充的申请单Node 是预算检查、合规检查等办事窗口Edge 则规定材料下一步送到哪里。这就是StateGraph最核心的三个角色。如果预算和合规检查同时往申请单里写结果谁也不能覆盖谁这时要由 Reducer 规定如何合并更新。基础流程理解以后再看两个高级原语就容易了。一个节点既要改状态又要改道时可以返回Command运行时才知道要派出多少个研究任务时可以用Send动态分发。先理解它们解决的问题比一次背下所有类名更重要。这比「多了一张流程图」多在哪里答案是图结构会直接决定执行。哪些节点能并行哪些节点必须等前置任务完成哪份状态会被保存恢复后从哪里继续都不再只是文档上的约定。这种显式状态还有一个工程上的好处我们可以把输入、输出和内部状态分开。外部请求只提交用户问题内部节点维护证据、风险分、重试次数和审批意见最后只返回对外结果。复杂流程的中间变量不必全部塞进消息历史也不必让每个节点看到所有数据。不过自由度也意味着责任。State 字段怎么设计并行写入如何合并节点边界切多细都要由开发者决定。LangGraph 不会因为用了图就自动让流程合理错误的 State 设计照样会造成状态膨胀、并发覆盖和难以维护。两种编排 API 怎么选提到 LangGraph很多人只知道StateGraph。当前官方还提供 Functional API两者共享同一套运行时能力但编程方式不同。如果流程有复杂分支、并行汇合、多 Agent 路由或者团队需要直观看清每条路径Graph API 更合适。开发者声明 State、Node 和 Edge业务拓扑非常明确Studio 里也更容易沿着节点观察状态变化。如果团队已经有一大段普通 Python 流程只是希望增加检查点、任务恢复和人工暂停Functional API 往往更省改造成本。entrypoint表示工作流入口task把有副作用或非确定性的操作变成可记录任务流程仍然可以写普通的if、for和函数调用。两者也不是二选一。外层多 Agent 调度可以使用StateGraph某个数据处理节点内部再调用 Functional API 工作流。面试时能说出这一层说明你理解的不是某套固定模板而是如何按复杂度选择表达方式。需求特征更自然的入口原因分支和循环很多需要看清完整拓扑Graph API节点、边和共享 State 显式便于可视化与评审多路并行后汇合或多 Agent 交接Graph API并发关系、Reducer 和子图边界更容易建模已有过程式代码希望少改代码Functional API保留普通 Python 控制流用装饰器增加运行时能力线性流程加少量条件和人工确认Functional API局部变量与函数作用域更自然样板代码更少不同子流程复杂度差异很大混合使用外层图负责调度内部函数工作流负责局部步骤流程跨小时后如何继续一个 Agent 运行几十秒进程挂了可以让用户重试。可如果它要运行几小时期间已经查了数据库、调用了外部服务还在等审批重新从第一步开始就不只是浪费 token还可能重复发邮件、重复创建订单。LangGraph 的 persistence 会在图执行过程中保存 checkpoint并按thread_id组织线程状态。这样一个运行可以暂停甚至服务重启后再从已保存状态恢复。官方把 durable execution 作为核心能力重点不只是「落盘」而是把任务结果、状态快照和恢复位置纳入运行时。这里要说清两个很容易混淆的概念。Checkpointer 保存某个线程的图状态快照支撑会话连续性、中断恢复和故障恢复。Store 保存图状态之外的应用数据适合跨线程使用的用户偏好、事实与共享知识。前者回答「这次任务走到哪里」后者回答「以后其他任务还要记住什么」。真实项目经常同时使用而不是二选一。但 durable execution 不是数据库开关。恢复时节点里的代码可能重新执行从旧 checkpoint 重放时后续模型调用和 API 请求也会再次发生。因此外部副作用必须有幂等保护例如使用业务幂等键、upsert、发送记录或先查后写。复杂节点还应该把非确定性操作和副作用划分成更清楚的恢复边界。换句话说LangGraph 能提供可靠执行的基础设施却不能替业务自动发明幂等语义。面试时如果只说「加 Checkpointer 就绝对不会重复执行」反而暴露了对恢复机制理解不够。人工怎样进入任意一步Agent 真正进入生产系统后完全自治往往不是终点。退款、付款、删库、发送正式邮件、发布内容等动作需要人看一眼有些流程还要等人工补充材料、修改状态甚至等待几天后再继续。LangGraph 的interrupt()可以放在节点内部任意位置。当代码触发中断时运行时保存状态并把一个可序列化的中断载荷交给外部系统。流程可以一直等待之后使用相同thread_id和Command(resume...)恢复外部输入就成为interrupt()的返回值。这比只支持「确认或取消」更灵活。审核员可以批准、拒绝也可以修改金额、补充证据或给出反馈后续路由再根据这份输入决定去哪。多级审批也可以拆成多个节点让每个角色只看到自己需要的信息。LangChain v1 已经有HumanInTheLoopMiddleware如果需求只是对若干敏感 Tool Call 做批准、编辑或拒绝它通常更省事。LangGraph 的优势出现在审批对象不是一个标准工具调用或者暂停点要嵌进更长的业务工作流时。还有一个必须主动说的坑节点恢复时会从节点开头重新执行而不是从interrupt()那一行继续跑。因此放在中断之前的副作用也要幂等interrupt()的调用顺序不要随意改变中断载荷应保持可序列化。失败后为什么不必整段重跑传统脚本失败后开发者常见的选择只有两个整段重跑或者手工改数据库再祈祷流程能继续。LangGraph 通过 checkpoint、节点边界和错误策略把失败处理变成工作流的一部分。当前官方文档把节点失败处理拆成可组合的三层Retry Policy 负责按异常类型和退避策略重试Timeout 限制单次尝试时间Error Handler 在重试耗尽后接管错误。处理函数还可以返回Command一边更新错误状态一边把流程送往降级、补偿或人工处理节点。并行节点失败时又会怎样LangGraph 会保存同一步中已经成功完成节点的结果。恢复时成功分支不必全部重跑只重试失败部分。这对并行抓取多个数据源特别有价值否则一个慢接口失败就会让其他已经成功的请求也重新付费。时间旅行处理的是另一个问题。通过状态历史找到旧 checkpoint 后可以从旧位置重新执行也可以先修改旧状态再分出另一条轨迹。它适合复现 Agent 为什么走错路、尝试不同人工决策或者修正错误的中间状态。这里也要避免夸大。Time travel 不是把程序时光倒流后原样播放录像。checkpoint 之前的节点会跳过之后的节点会重新执行因此模型输出、网络响应和外部副作用可能不同。它提供的是「可定位、可重放、可分叉」的调试基础不是自动撤销现实世界已经发生的操作。复杂任务如何并行又汇合深度研究类任务为什么适合图因为它往往不是一个 Agent 从头想到尾而是先拆主题再并行搜索多个来源随后交叉验证、合并证据、发现空白后继续补搜最后统一写报告。Graph API 支持把一个任务拆成多条并行分支再把结果汇合回来。如果任务数量在运行时才能确定可以使用Send动态创建分支。并行节点更新同一个 State 字段时需要通过 Reducer 明确合并方式不能指望最后写入者碰巧正确。子图则解决模块化问题。一个完整 LangChaincreate_agent返回的本来就是图可以作为外层StateGraph的节点或子图。不同团队也可以分别维护研究、合规、财务等子图只要约定好输入输出状态父图不必知道内部细节。子图的记忆范围需要显式选择。一次性子任务可以让每次调用都从新状态开始。确实需要连续记忆的子 Agent才让子图在同一线程的多次调用间积累状态。完全无状态的调用虽然更简单但也不能依赖中断与可靠恢复能力。不过多 Agent 不等于效果必然更好。角色越多提示词、上下文交接、错误定位和 Token 成本越高。很多交接场景使用单 Agent 加 middleware 会更简单。只有角色需要不同工具、不同状态结构、独立生命周期或者确实需要并行和跨团队维护时子图才值得引入。运行中怎样持续看见进度复杂 Agent 常常不是慢在最后回答而是慢在搜索、文件处理、子 Agent 调用和人工等待。如果前端只显示一个转圈图标用户不知道系统卡住了还是仍在工作。LangGraph 的 streaming 不只有模型 Token。它还能输出每步 State 更新、模型消息、自定义进度、checkpoint 和任务状态。产品界面可以展示「正在查询政策库」「已完成 3/5 个来源」「等待财务审批」开发者则能观察哪个节点更新了什么、哪个任务失败。这样底层事件才真正变成用户能理解的进度。LangChain Agent 因为运行在 LangGraph 上也能使用相同的底层流式能力。直接使用 LangGraph 的优势仍然是节点和业务阶段由我们定义所以流式事件可以与产品进度条、审计日志和告警规则精确对应。这种可观察性与 LangSmith tracing、Studio 配合后更有价值。开发者可以查看实际走过的节点路径、状态变更和耗时复杂流程不再只剩一长串难以还原的模型日志。状态如何走向生产部署长时间运行的 Agent 不能只靠进程内列表保存状态也不能把用户偏好和当前任务进度混进一个向量库。LangGraph 将线程内状态与跨线程长期资料分开后系统边界会清楚很多。短期记忆跟随 State 和 Checkpointer由thread_id隔离适合当前会话消息、已完成步骤和审批上下文。长期记忆进入 Store按 namespace 与 key 组织用来召回用户偏好和历史事实。生产环境还要使用数据库后端并补齐租户隔离、保留期限、删除更正与敏感信息治理。部署也要讲清边界。开源 LangGraph 是编排框架和运行时不等于购买某个托管服务。团队可以自行托管并接自己的 Checkpointer、Store 和队列也可以使用托管的 Agent Server。后者把图、持久化数据库与任务队列组合起来更适合后台运行、流式交互和有状态长任务。这套部署能力也是为什么 LangGraph 适合长任务但不要说成「用了 LangGraph 就自动高可用」。自托管时数据库、任务队列、Worker 扩缩容、重试策略、监控和数据保留都仍然是团队责任。即使使用托管平台也需要做容量评估、幂等设计和故障演练。完整流程示例假设我们要做一个采购 Agent。申请提交后要并行做预算检查和合规检查两个结果齐了才能进入人工审批审批通过才调用采购系统拒绝则结束。这个流程里模型可以帮助理解材料但顺序与权限不能交给模型自由发挥。下面用简化代码表达核心结构。示例重点是图的控制语义不包含真实模型、数据库和鉴权实现。from typing import Literal, TypedDictfrom langgraph.checkpoint.memory import InMemorySaverfrom langgraph.graph import END, START, StateGraphfrom langgraph.types import Command, interruptclass PurchaseState(TypedDict, totalFalse): # request_id 也可作为外部采购接口的幂等键 request_id: str amount: float budget_ok: bool compliance_ok: bool approved: bool result: strdef normalize_request(state: PurchaseState) - dict: # 真实项目应在这里完成字段校验和权限检查 return {amount: round(state[amount], 2)}def check_budget(state: PurchaseState) - dict: # 该节点可以替换为预算系统查询并配置重试与超时 return {budget_ok: state[amount] 100_000}def check_compliance(state: PurchaseState) - dict: # 与预算检查写入不同字段因此两个节点可以安全并行 return {compliance_ok: True}def human_review(state: PurchaseState) - dict: # 暂停流程将两项检查结果交给审核系统 review interrupt( { request_id: state[request_id], budget_ok: state[budget_ok], compliance_ok: state[compliance_ok], } ) return {approved: bool(review[approved])}def route_after_review(state: PurchaseState) - Literal[execute, reject]: # 审批结果决定后续确定性路径 return execute if state[approved] else rejectdef execute_purchase(state: PurchaseState) - dict: # 真实调用必须携带 request_id防止恢复或重试造成重复采购 return {result: f采购申请 {state[request_id]} 已执行}def reject_purchase(state: PurchaseState) - dict: # 拒绝路径不触发外部采购副作用 return {result: 采购申请未通过}builder StateGraph(PurchaseState)builder.add_node(normalize, normalize_request)builder.add_node(budget, check_budget)builder.add_node(compliance, check_compliance)builder.add_node(human_review, human_review)builder.add_node(execute, execute_purchase)builder.add_node(reject, reject_purchase)builder.add_edge(START, normalize)# 从同一节点扇出预算和合规检查进入并行分支builder.add_edge(normalize, budget)builder.add_edge(normalize, compliance)# 使用多起点边做 fan-in两项检查都完成后才进入人工审批builder.add_edge([budget, compliance], human_review)builder.add_conditional_edges(human_review, route_after_review)builder.add_edge(execute, END)builder.add_edge(reject, END)# 内存检查点仅用于示例生产环境应替换为数据库后端graph builder.compile(checkpointerInMemorySaver())# thread_id 是暂停、恢复和状态历史的定位依据config {configurable: {thread_id: purchase-2026-001}}graph.invoke( {request_id: PO-001, amount: 58_000}, configconfig,)# 审核员稍后提交结果图从同一线程的中断点恢复final_state graph.invoke( Command(resume{approved: True}), configconfig,)print(final_state[result])这段代码体现了四件事业务拓扑是显式的两项检查能并行且有明确汇合点人工审批可以跨时间暂停执行动作有业务幂等键。真正上线时还要给外部查询增加 Retry Policy 与 Timeout给执行失败设计补偿或人工接管路径并把 InMemorySaver 换成持久化实现。如果用 LangChain也不是不能实现这个系统。更自然的组合通常是用create_agent做「材料理解」或「异常解释」节点外层采购流程仍由StateGraph控制。这样高层 Agent 抽象和低层业务编排各司其职。哪些场景适合 LangGraph理解了前面的能力场景判断就不用死记。我们只要先问一句这个系统最难的是「让模型会用工具」还是「让整个任务可靠地走完一条复杂路线」如果难点只是让模型从几个工具中做选择标准 Agent 往往已经足够。可一旦业务顺序不能交给模型自由发挥问题就变了。理赔、退款、采购、合同审核和生产变更都有明确阶段、权限与审批点模型只能参与理解和判断真正的路线必须由确定性规则控制。LangGraph 的价值就是把模型能力嵌进业务流程而不是让 Prompt 充当流程引擎。路线明确以后再看它是否会跨时间运行。深度研究、报表生成、代码迁移和跨系统工单可能持续数十分钟到数天中间还要等待人或外部事件。这类任务需要 checkpoint、interrupt 和 durable execution 保住进度否则每次等待或故障都可能让流程从头再来。任务继续变复杂时单条路线还会长出并行分支。Planner 临时拆出多个研究主题各分支分别搜索、抽取与验证再用 Reducer 汇总证据多个 Agent 也可能因为拥有不同工具、状态或团队边界而组成子图。此时Send、fan-out、fan-in 和 subgraph 不是为了炫技而是在表达真实存在的并发与协作关系。最后再看团队是否需要干预中间状态。复杂 RAG 会在证据不足时改写查询并重新检索模型走错路线时也需要查看 checkpoint、修改状态后重放。只看最终答案已经无法解释问题时显式节点、状态历史和分叉能力才会真正转化为调试价值。哪些场景不必用 LangGraphLangGraph 更底层不等于更适合所有项目。一个只需要查天气、查订单、总结文档的标准工具调用 Agent使用create_agent往往更快、更短也更符合团队认知。动态提示词、模型切换、工具过滤、消息摘要、重试、护栏和敏感工具审批优先看看 LangChain middleware 能不能解决。如果流程只有固定的 Prompt、模型和解析器也不一定需要 Agent更不用为了「图」而引入 LangGraph。普通函数、LCEL 或一个队列任务可能就够了。下面这张选型表比「简单用 LangChain复杂用 LangGraph」更有操作性判断问题优先 LangChaincreate_agent考虑直接使用 LangGraph主流程是什么常见模型与工具循环多阶段业务工作流路由由谁决定大部分由模型按工具描述决定模型决策与确定性规则混合状态复杂度消息为主少量自定义字段多类业务状态、Reducer、内部通道运行时长单次交互或短任务跨小时、跨天、等待外部事件人工介入审批敏感工具调用任意阶段补充、修改、审批和改道并行结构少量并行工具调用动态 fan-out、fan-in、map-reduce角色数量单 Agent 或简单子 Agent多 Agent、子图、明确 handoff故障处理通用重试与错误包装节点级恢复、补偿、历史分叉团队成本希望快速交付少写编排代码愿意维护图、状态和恢复语义最稳妥的选型路径通常是渐进式的。先用 LangChain 搭出一个能工作的 Agent当 middleware 已经开始承担业务路由、状态字段越来越多、任务必须跨时间恢复时再把外围流程下沉到 LangGraph。已有 Agent 不必推倒重来可以直接成为图里的节点或子图。最后再提醒一个常见误区图越复杂不代表系统越智能。节点过细会增加 checkpoint、序列化和维护成本节点过粗又会降低恢复粒度。真正成熟的设计是根据副作用、重试、人工介入和可观测性来划分边界而不是追求节点数量。──── 面试总结────回答这道题时我会先把关系说准LangChain v1 的 Agent 本身构建在 LangGraph 上所以两者不是互斥框架。LangGraph 的优势不是凭空多出持久化、流式输出和人工介入而是让开发者从高层 Agent loop 下沉显式控制整个有状态业务流程。接着我会抓住三条主线。第一是控制State、节点、边和确定性规则都能进入执行拓扑。第二是可靠checkpoint、interrupt 和节点级容错让长任务可以暂停与恢复。第三是工程化流式事件、短期与长期记忆以及部署服务可以支撑有状态、长时间运行的生产系统。场景上LangGraph 更适合高风险审批、跨小时或跨天任务、并行深度研究、多 Agent 协作、自纠错 RAG 和需要精确调试的复杂工作流。它尤其适合把确定性步骤与 LLM 驱动步骤混在一张图里让模型负责需要判断的部分让业务规则负责不能出错的部分。最后给出边界标准工具调用 Agent 优先用 LangChaincreate_agent简单审批优先用 middleware。只有当业务拓扑、状态作用域、恢复边界或多角色协作成为主要复杂度时才直接使用 LangGraph。真实项目常见的成熟方案不是二选一而是让 LangChain Agent 成为 LangGraph 中可复用的节点或子图。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
