LangGraph 相比 LangChain 在多 Agent 编排中有什么优势，状态快照机制解决什么问题？｜高频面试题解析

60 秒回答模板

我会先说明 LangChain 更常被理解为 LLM 应用组件和链式调用生态，适合快速组合模型、Prompt、工具、检索和基础链路；LangGraph 的价值通常体现在把 Agent 流程显式建模成有状态的图，节点代表步骤或 Agent，边代表条件流转，状态对象贯穿整个运行过程。多 Agent 场景里，图结构更容易表达循环、分支、重试、并行、汇合和人工接管，也更容易限制每个 Agent 的职责边界。状态快照解决的是长流程可靠性问题：每一步运行后的任务状态、消息、工具结果和中间变量可以被记录下来，用于失败恢复、断点续跑、调试回放、人工审核和版本对比。选型时不能只说某个框架更强，而要看业务是否需要显式状态机、可恢复执行、复杂控制流、可观测 trace、团队维护成本和与现有代码的集成成本。

考点 抽象差异

难度 真实面经题

回答目标 讲清工程边界与实现取舍

深入解析

先从抽象层级比较

LangChain 偏向提供模型、Prompt、工具、检索和链式调用等应用组件；LangGraph 偏向把 Agent 流程建模成图和状态流转。面试回答要把比较放在编排抽象上，而不是简单说一个替代另一个。

图结构适合复杂控制流

多 Agent 流程经常有分支、循环、重试、汇总、条件跳转和人工确认。图式编排可以把每个步骤的输入输出和下一步条件显式表达出来，比隐式的函数嵌套更容易检查边界、控制循环和定位问题。

状态对象是运行主线

有状态编排会把消息、任务目标、计划、工具结果、错误、审批状态和最终输出放进统一状态对象。每个节点只读写自己负责的字段，减少多 Agent 之间靠自然语言互相传递上下文导致的信息丢失和职责混乱。

状态快照支撑恢复和审计

状态快照的核心价值是把某一步之后的运行状态保存下来。长任务失败时可以从最近稳定点恢复；人工审核时可以暂停并修改状态；调试时可以回放路径；线上问题可以根据快照定位是哪个节点、工具或条件判断出错。

多 Agent 要控制职责边界

图里每个 Agent 或节点应有明确职责、输入字段、输出字段和停止条件。否则即使用了图框架，也会变成多个 Agent 互相转发自然语言，出现重复调用、责任不清、循环跳转和状态覆盖。

选型看复杂度和成本

简单问答、固定 RAG 或单工具流程可能不需要引入复杂图编排；一旦有长流程、多角色、人工确认、失败恢复和强审计要求，显式状态图更有价值。最终还要看团队熟悉度、生态集成、部署成本和可观测性。

易错点

只背框架名字，没有解释链式组件和有状态图编排的抽象差异。
把状态快照说成普通日志，忽略恢复和人工介入价值。
认为用了图框架就天然适合多 Agent，没有定义节点职责和状态字段。
忽略循环、重试和分支的停止条件，导致编排可能失控。
不讨论引入框架的维护成本、团队学习成本和现有系统集成成本。

面试官追问

状态快照和普通日志有什么区别？

日志主要记录发生了什么，状态快照保存的是可继续执行的任务状态。快照可以支持恢复、人工修改和路径回放，普通日志通常只能排查问题。

为什么多 Agent 更需要状态管理？

多个 Agent 之间容易出现信息丢失、重复决策和职责覆盖。统一状态对象能明确每一步读写内容，减少靠自然语言转述造成的不确定性。

什么时候不用 LangGraph 这类图编排？

如果流程很短、没有循环分支、没有恢复要求，也不需要人工介入，用简单链路或普通服务编排可能更低成本。

如何防止图编排里的死循环？

给循环边设置最大迭代次数、状态变化检查、超时、错误阈值和人工接管条件，并在 trace 中记录每次跳转原因。