第 2.8.1 节：理解 LangGraph 如何用状态图编排 Agent
先从整体看LangGraph，梳理组成模块和各自职责。完成本节后，你应该能够画出 LangGraph 的组成模块、数据/状态流、责任边界和上下游依赖。
本章要解决什么问题
前面章节已经讲了 RAG（检索增强生成）、Tool Calling（工具调用）和 MCP（模型上下文协议）的边界：Agent（智能体）如何查知识库、查订单、创建工单，以及工具如何被发现、筛选和审计。到这里，读者会遇到第三个真实工程断层：客服任务的状态迁移表写清楚了，但系统怎么稳定地按照这张表运行？
客服场景里，一个用户说“我要退款，你们客服一直没人理我”，流程不是一次模型回答就结束。系统可能要经历：
- 判断用户意图和风险。
- 发现缺订单号，暂停并追问。
- 用户补充订单号后，从断点继续。
- 查订单状态。
- 查售后政策。
- 判断是否需要人工审批。
- 让用户确认工单草稿。
- 创建工单。
- 工具失败时重试，重试失败后转人工。
- 每一步都留下状态、日志和可复盘原因。
如果这些逻辑都散落在一堆 if/else（条件判断）里，项目初期看似能跑，后期会很快失控：新增一个分支会影响旧流程，重试逻辑和人工确认混在一起，工具失败后不知道回到哪里，前端也不知道当前应该展示“等待用户补充信息”“等待人工审批”还是“工单创建成功”。
LangGraph（智能体状态图框架）要解决的不是“让模型更聪明”，而是：把多步骤 Agent 流程显式建模成状态图，让状态、节点、边、条件分支、循环、人工确认、恢复和可视化编排都能被设计、测试和复盘。
本章通过状态图、节点设计与执行路径，讲清：
- 为什么客服任务的状态迁移表需要进一步变成状态图。
- LangGraph（智能体状态图框架）中的 State（状态）、Node（节点）、Edge（边）、Conditional Edge（条件边）分别解决什么问题。
- 如何在客服工作台里设计查资料、查订单、创建工单、人工确认和恢复流程。
- 如何用字段契约、权限、状态日志和验收样例替代“看起来能跑”的口头说明。
- 什么时候不适合使用 LangGraph（智能体状态图框架），避免为了框架而框架。
- 面试时如何把 LangGraph（智能体状态图框架）讲成工程编排能力，而不是只背 API（应用程序接口）名称。
学习目标
学完本章后，读者应该能做到：
- 用人话解释 LangGraph（智能体状态图框架）解决什么问题。
- 把退款投诉状态迁移表转换成状态图。
- 区分 State（状态）、Node（节点）、Edge（边）、Conditional Edge（条件边）、循环、人工中断和检查点。
- 判断客服流程中哪些步骤应该设计成节点，哪些判断应该设计成条件边。
- 为“退款投诉处理”设计一条可暂停、可恢复、可转人工的状态图。
- 设计状态图运行所需的字段契约，而不是只画流程图。
- 说明节点日志、状态迁移日志、工具日志和人工确认日志分别记录什么。
- 设计失败兜底：工具超时、节点输出无效、循环失控、人工超时、恢复失败时怎么办。
- 说清 LangGraph（智能体状态图框架）和 Tool Calling、RAG、MCP、多智能体的关系。
- 回答面试官关于状态图、条件分支、恢复、人工确认、可观测性和过度设计的追问。
贯穿业务场景
继续使用本书第一批核心章的贯穿项目：企业客服知识库与工单 Agent 工作台。
这一章聚焦一个典型任务：用户发起退款投诉。它会同时涉及知识库、订单系统、售后政策、工单系统和人工客服。
| 业务阶段 | 用户或系统行为 | 状态字段 | 本章状态图表达 |
|---|---|---|---|
| 新任务进入 | 用户说“我要退款，你们客服没人理我” | intent（意图）为 refund_request（退款请求），risk_level（风险等级）为 high（高） | 进入 classify_intent（识别意图）节点。 |
| 信息不足 | 没有订单号 | missing_fields（缺失字段）包含 order_id（订单号） | 条件边流向 ask_for_order_id（追问订单号）节点，并暂停。 |
| 用户补充 | 用户提供订单号 | current_step（当前步骤）变为 ready_to_check_order（可查订单） | 从检查点恢复，进入 validate_order_scope（校验订单归属）节点。 |
| 读取业务状态 | 系统查订单 | used_tools（已用工具）记录 get_order_status（查订单状态） | 进入 check_order_status（查订单状态）节点。 |
| 查询政策 | 订单已发货，需要判断售后规则 | tool_results（工具结果）记录订单摘要 | 条件边流向 search_after_sales_policy（查售后政策）节点。 |
| 风险判断 | 政策要求人工审核 | approval_required（需要审批）为 true | 条件边流向 prepare_ticket_draft（准备工单草稿）和 human_confirm（人工确认）节点。 |
| 写入动作 | 用户确认工单摘要 | user_confirmation（用户确认）为 approved（已同意） | 进入 create_ticket（创建工单）节点。 |
| 完成或转人工 | 工单创建成功，或失败转人工 | stop_reason（停止原因）为 completed（已完成）或 handoff（转人工） | 流向 final_response（最终答复）或 handoff_to_human（转人工）节点。 |
这张表说明：状态迁移表解决“状态要记录什么”，本章解决“状态如何驱动下一步”。LangGraph（智能体状态图框架）不是替代状态设计，而是把状态设计变成可运行、可暂停、可恢复、可观测的工作流。
新手为什么会卡住
很多新手看到 LangGraph（智能体状态图框架）时，会把它当成“又一个 Agent 框架”。真正做项目时，他们通常卡在以下位置。
| 误解 | 项目后果 | 正确理解 |
|---|---|---|
| LangGraph（智能体状态图框架）就是画流程图 | 只画了图，运行时状态、恢复和日志仍然混乱 | 状态图既要表达流程，也要承载状态更新、条件路由、暂停恢复和执行记录。 |
| 有了 Agent 循环就不需要状态图 | 模型反复调用工具，停止条件不清楚 | Agent 循环适合开放探索，状态图适合有业务阶段、审批和验收路径的流程。 |
| 节点越细越专业 | 节点爆炸，维护成本高 | 节点应该按可测试的业务动作拆分，不按每个小变量拆分。 |
| 条件边交给模型判断就行 | 高风险退款、投诉和越权查询可能被错误推进 | 条件边要优先依赖结构化状态和业务规则，模型判断只能作为输入之一。 |
| 人工确认就是发一句“请确认” | 用户刷新页面或审核人晚点处理时流程丢失 | 人工确认需要暂停、保存状态、展示待确认内容、恢复执行。 |
| 恢复就是重新跑一遍 | 重复查订单、重复建工单、重复发通知 | 恢复应该从检查点继续，并依赖幂等和状态日志。 |
| 可视化只是好看 | 出问题只能看日志文本，很难解释路径 | 状态图可视化能帮助产品、开发、测试和面试官理解每条路径。 |
本章会用客服工作台把这些误解拆开。读者不需要先记住某个框架语法，只需要先学会如何把业务流程建模成状态图。