Q47 · LangGraph 解决了什么问题？和 LangChain 的区别是什么？

客户提交一张客服工单：“我买的路由器昨天维修回来，今天又无法联网，能直接换新吗？”助手需要查维修记录、查当前换新政策，再整理出答复。有时政策检索第一次没有找到“维修后再次故障”这一条例外，需要换搜索词补查；有时资料足够，但换新申请必须等员工审核；员工可能第二天才处理，期间服务还可能重启。

如果只是“收到问题 → 调模型 → 回答”，这些暂停、补查和继续执行都无从安放。LangGraph 解决的是多步骤任务的执行控制问题：当前知道哪些事实、下一步去哪、遇到缺资料或工具失败怎样走、需要人工时怎样停、过一会怎样继续。LangChain 提供的是较高层的模型、工具、消息等组件，以及现成可用的 Agent 入口。 当前 LangChain 的 Agent 本身就构建在 LangGraph 之上，因此不是“LangChain 只会线性链、LangGraph 才能调用工具”。官方对两者的定位正是：LangChain 提供可配置的 Agent 与集成，LangGraph 提供更底层的编排运行时。LangChain 总览 · LangGraph 总览

这道题和 Q8 的 LangGraph 入门主题相近。这里着重回答遇到什么工程问题才需要自己设计图、何时用现成 Agent 就够、两者怎样配合。先用同一张工单把这些判断说清楚。

术语和工单里的名字

词或名字	先用日常话理解	路由器工单中的对应物
大语言模型 / LLM	能理解问题和生成文字的模型；不自动掌握这家店的真实记录	读懂“维修后又坏了”的含义，撰写答复
LangChain	构建模型应用的组件和较高层 Agent 入口	接模型、接维修查询与政策检索工具
create_agent	当前 LangChain 中创建现成 Agent 的入口之一	给模型两只读工具，让它按需要调用
Agent 循环	模型看当前信息、提出工具请求、应用执行后把结果给模型，直到回答或停止	查维修记录、查政策、再回答
LangGraph	可显式定义状态、执行步骤与分支的编排运行时	把核验、补查、人工审核、继续执行写成流程
Graph / 图	由步骤和步骤间的连接组成的路线图	工单从“查记录”走到“查政策”或“人工复核”
State / 状态	一笔任务到目前为止保存的结构化事实与进度	工单号、维修记录、候选政策、补查次数、员工结论
Node / 节点	图中的一个处理步骤，接收当前状态并返回更新	lookup_repair 查询维修记录
Edge / 边	节点执行完以后去往哪一步的连接	“查到现行政策”去起草；没查到去补查
条件分支	根据状态选择不同的边	没有例外条款就补查，超过上限就转人工
回环	流程走回先前步骤再次尝试，但必须有停止条件	最多补查两次政策
检查点 / Checkpointer	把当前状态与执行进度保存下来，方便稍后继续	员工审核前保存已查到的资料
thread_id	用来找回同一条图执行线的标识	工单 W204 的这次审核会话
中断 / interrupt	在流程中暂停，等待外部输入	员工选择“批准换新 / 需要更多证据”
幂等	同一业务动作重复请求时不会重复产生结果	服务重试后不重复创建两张换新单
ticket_id	工单编号，本文用 W204	W204
lookup_count	已补查政策的次数	初查失败后为 1，再查一次后为 2

本文工单、维修记录和政策均为虚构教学数据。假设工单 W204 的路由器确实在 9 月 24 日维修返回，9 月 25 日再次无法联网；现行政策 P3 写着“同一故障维修后再次发生，可申请人工核验换新，是否换新以检测与订单条件为准”。因此助手可以建议进入人工核验，不能直接保证换新，更不能自己执行换新。这里不讨论现实商家的具体售后条款。

先看 LangChain 的现成 Agent 能做什么

只给 Agent “查维修记录”和“查政策”两只读工具，并说明何时使用，模型就可以在典型的工具调用循环中提出请求。比如模型看到 W204 问题，先要求查维修记录；应用执行工具后把真实结果回给模型；模型据此再要求查换新政策；结果足够就写出答复。LangChain 当前官方文档把 create_agent 定位为“从模型、工具、提示词和中间件组成可配置 Agent”的入口，并明确说其 Agent 建在 LangGraph 之上。LangChain 总览

这意味着 LangChain 的现成 Agent 也能循环，也能根据工具结果决定下一步。不能在面试里说“LangChain = 固定链，LangGraph = 会循环的 Agent”。“Chain”作为把步骤串起来的广义叫法、LCEL 管道、当前 create_agent 的工具循环，分别是不同层面的东西；Q46专门解释 Chain 与 LCEL。若业务只是“查两种资料、给有依据的回答”，一个预制 Agent 加必要的工具权限与停止约束，往往已能完成。LangChain 的模型与工具集成也可以直接拿到自定义 LangGraph 节点中使用。

那现成 Agent 的不足在哪里？不是它完全做不到复杂事，而是当产品要求明确指定每一步何时做、哪一步必须人工审核、哪些状态要保存、失败后回到哪里时，若都塞进一个长提示词或外层零散的 if，规则会分散、难以排查。W204 的业务规定“换新建议必须人工审核，员工签字前不得创建换新单”，这就是应用级的强制流程边界，适合显式表达。可以继续使用 LangChain 的模型与工具，但用 LangGraph 来掌控整条任务线路。LangGraph 总览说它允许把确定性的程序步骤和由模型作出的灵活决定混在同一张图里。

图左边是现成 Agent 的模型—工具循环，不是单向流水线；右边是开发者在业务流程里明确设计的两条去向，并用书签表示保存进度。图没有画订单权限、检索版本和写操作审批，正文后面补上这些边界。

W204 为什么会需要显式的图

先列出这条工单要守的产品规则，再决定节点，不要一上来给每个函数起英文名字。假设规则是：只有订单本人可咨询；维修记录必须来自订单系统；现行政策中要找到“维修后再次故障”的完整条件；最多检索两次；证据不足时转人工；证据充分也要先由员工审核换新建议，员工批准后业务系统才可能执行换新。

把业务动作按顺序摊开：

1. 核实身份与工单。 程序确认当前用户有权查看 W204，并读取订单、维修记录。这个权限判断不能让模型凭聊天文字猜。
2. 查现行政策。 按商品、地区、日期限制资料范围，检索“维修后再次故障”条款，保存来源和版本。
3. 判断证据是否完整。 如果只搜到普通保修条款，仍缺换新例外，就改写查询补查；若已经补查到上限，结束自动判断并交人工。
4. 起草建议。 只有订单事实和完整政策都在手，才让模型写“可申请人工核验”的建议，附可回查依据。
5. 暂停等员工。 员工看见订单和政策，选择批准继续、拒绝或要求补充资料。流程在等待时保存状态，而不是占着一个 HTTP 请求一直等。
6. 按审核结果走。 拒绝则答复理由；批准后由业务系统再次核验和执行必要操作。生成建议不等于已创建换新单。

第 3 步出现“补查或转人工”的条件分支；第 5 步需要暂停与继续。这就是比简单工具循环更有价值的控制点。图可以表达成“核实 → 查政策 → 判断”，从判断处指向“补查”“起草”或“转人工”；起草后进入“等待审批”，审批之后再决定结束或执行。LangGraph 的 Thinking in LangGraph建议先画业务步骤、判断每步所需数据，再设计状态和节点；本文沿同样顺序解释。

状态、节点、边是怎样配合的

在 W204 流程里，状态是一张属于这条工单的工作记录，例如：

{
  "ticket_id": "W204",
  "repair_record": null,
  "policy_evidence": [],
  "lookup_count": 0,
  "draft_reply": null,
  "review_decision": null
}

ticket_id 是工单号；repair_record 放核验过的维修记录，null 表示尚未查到；policy_evidence 是有版本和来源的政策片段列表；lookup_count 统计政策检索次数；draft_reply 放待审核的答复草稿；review_decision 放员工的处理结果。它们是示意字段，并非 LangGraph 内置固定名字。跨多节点要继续用到的事实适合放在 State；只在某个函数内部计算、可随时重算的临时值则未必需要保存。官方图设计指南也主张保存原始事实，在节点内按需形成提示词，而不是把一整段格式化 Prompt 当成唯一状态。Thinking in LangGraph

每个 Node 读取状态、完成一个明确动作，再返回它负责更新的字段。例如业务动作“查维修记录”可以命名为 lookup_repair：输入状态里的 ticket_id=W204，由应用查订单系统，返回 repair_record={returned_at: 2026-09-24, issue: 无法联网}。lookup_repair 这个英文名字只是给“查维修记录”起的函数名；它不是模型自动执行的神奇命令。下一个“查政策”节点读到维修事实后，才能组成具体查询，并把结果填入 policy_evidence。

Edge 决定节点结束后的去向。固定边“查维修记录 → 查政策”每次都走；条件边读取 policy_evidence 与 lookup_count：证据完整去起草，尚可补查就回到检索，超过上限去人工。边和条件不是权限检查的替身：即使状态写了 review_decision=approved，真正执行换新时也要由业务系统验证员工身份、订单资格和审批记录。LangGraph 用来表达与运行流程，业务真相仍来自业务系统。

沿一条失败路径看看状态为什么重要。第一次查政策只找到了“普通保修 12 个月”，没有“维修后再次故障”条款，于是状态从 lookup_count=0 变成 1，policy_evidence 记录了该候选和来源，但标记“还不足以判断换新”。条件边再去查一次；第二次找到了 P3 的例外，lookup_count=2，证据完整，才进入起草。若第二次仍没找到，不再回环，停止并转人工。这比让模型无上限地反复说“再查一遍”可控。

人工等待和恢复为什么需要运行时支持

员工可能几个小时后才审核 W204。普通函数若在 await 或 HTTP 请求中一直等待，会占用资源，服务重启也可能丢掉进度。LangGraph 可在合适节点触发中断，把当前图的状态与位置经 Checkpointer 保存；外部输入到来时用同一条执行线的 thread_id 找回任务并继续。官方文档把持久化、人工参与和长时运行列为 LangGraph 的核心能力。LangGraph overview · Persistence

这里有三个容易说错的地方：

• 要配置保存方式。 不是只要安装 LangGraph，任务就自动跨进程持久化。演示用内存保存器适合本地学习；要在服务重启后恢复，必须使用可靠的持久化保存器，并安排状态里敏感订单资料的访问控制与保留期。
• 恢复不等于从某行代码无副作用地继续。 图的执行可能从节点边界或中断点所在节点重新运行相应代码；若在中断前就发起换新申请，重跑有重复副作用风险。应把“等待审批”和“真正写入”拆成步骤，对写操作使用稳定的业务幂等标识，并在恢复时核查已完成的外部结果。检查点保存流程位置，幂等保护业务结果，两者不能互代。
• thread_id 不是登录凭证。 它帮助定位某条执行线，不能因为用户猜到或提交了 W204 的 thread_id 就允许读取其状态。恢复入口仍要鉴权，确认当前员工有权审阅这笔工单。

如果只是回答一次常见问题，不需要人等候、不需要跨进程恢复，直接上显式图和持久化数据库会增加维护工作。是否使用这些能力，应从任务的实际分支、时长和审计要求出发，而不是因为图看起来更“高级”。

两者按同一问题比较

同一 W204 工单的关注点	LangChain 现成 Agent	自行设计 LangGraph 图
起点	用模型、工具和提示词快速建立工具调用循环	先定状态、节点、边，再把模型和工具放入节点
谁安排下一步	现成 Agent 循环可让模型依据工具结果选下一工具，也可叠加中间件和约束	开发者可把强制步骤与模型决策明确分开，写出具体分支和回环
接工具与模型	提供统一抽象和多家模型、工具集成	可继续使用 LangChain 组件，也可用自己的函数或其他 SDK
暂停与恢复	当前 LangChain Agent 建在 LangGraph 上，可利用其底层能力；需按用法配置	可以直接在自定义位置设置中断、检查点和恢复路径
工程成本	通常更快启动，路径定制受预制抽象与配置方式影响	需要自己设计状态、分支、错误处理和测试，控制更细
本例何时用	只需查记录、查政策、按证据回答，现成循环足够时	必须显式补查上限、员工审批、跨日恢复和独立写入步骤时

表里最重要的关系是：它们经常一起用。 LangChain Agent 建在 LangGraph 之上；LangGraph 本身也可以独立使用，不被迫使用 LangChain 的模型封装。两者不是“同一层的两个竞品 API”。LangSmith 另负责追踪、评测和调试，不要把它误称为 LangGraph 的另一个名字。LangGraph 总览中的生态分层

选型还可加一层“只用普通程序”的基线：若 W204 的路线完全固定，程序写“查订单→查政策→人工处理”就能满足，未必需要模型自主选路。若问题类型多、模型要依据运行结果选择工具，先试现成 Agent；若业务要求几个强制审批分支、等待与恢复，再考虑显式 LangGraph。核心不是框架名称，而是谁控制下一步，哪些状态需跨步骤保存，哪些边界必须由业务程序保证。

实际上线时怎样验证

用同一组工单做端到端测试，不能只看到“最终答得像人”就结束。正常样本包含维修记录存在、P3 例外条款已找到、员工批准或拒绝两条路径；失败样本包含订单不属于当前用户、政策初查未命中、两次补查仍不足、检索服务超时、员工迟迟未回复、服务在等待时重启、写入返回超时但业务系统可能已创建换新单。分别检查节点是否收到正确数据、条件边是否走对、次数是否停止、恢复是否回到 W204、是否出现重复业务操作。

记录一次执行的 ticket_id、thread_id、节点进入/离开、工具请求与结果、状态中的必要字段、人工决定与最终动作，才可能定位“哪一步出了错”。但维修记录、客户信息不应无限制地复制进所有日志；状态存储和执行轨迹也要有权限与保留策略。LangGraph 的图能让执行轨迹显式可见，不会自动保证政策判断正确或权限安全；这些仍要靠业务校验和测试。

面试时怎样回答

可以这样说：“LangChain 更偏应用组件和现成 Agent 入口，提供模型、工具、消息等抽象；当前它的 create_agent 已经基于 LangGraph，所以 LangChain Agent 也能循环调用工具。LangGraph 是更底层的状态化编排运行时，让我把状态、处理节点和条件路线显式写出来，并在需要时接入检查点、人工中断和恢复。比如路由器维修后再次故障的工单，简单查记录与政策后答复，用现成 Agent 就够；如果政策不足要限次补查，换新建议必须等员工审核，服务重启后还要从审核点继续，我会考虑自定义图。图的检查点只解决流程恢复，订单权限、政策版本和换新动作的幂等仍由业务系统保障。”

若面试官问“LangGraph 能不用 LangChain 吗？”，可以答能；官方把它作为可独立使用的低层编排框架，只是常借 LangChain 组件接模型和工具。问“LangChain 是固定链，LangGraph 才是 Agent 吗？”，答不对；当前 LangChain 的现成 Agent 已是会调用工具的循环，并建在 LangGraph 上。问“有 Checkpointer 就能安全重试换新吗？”，也不行；写操作需业务系统识别同一请求、防重和核对外部结果，避免恢复时重复执行。

资料来源

• LangChain 官方：LangChain overview
• LangChain 官方：LangGraph overview
• LangChain 官方：Thinking in LangGraph
• LangChain 官方：LangGraph persistence