第 2.8.2 节：用 State、Node 和 Edge 描述工作流骨架
本节围绕“用 State、Node 和 Edge 描述工作流骨架”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够说清 State、Node 与 Edge 的处理顺序、关键检查点和失败处理。
核心概念
读图重点：从 State 开始：Node 只完成一个可验收动作，Edge 决定下一步；遇到补信息、审批或故障时保存检查点，中断恢复后继续使用同一任务状态。
LangGraph（智能体状态图框架）
| 层级 | 解释 |
|---|
| 人话解释 | LangGraph（智能体状态图框架）是用“状态图”组织复杂 Agent（智能体）流程的框架。它让系统知道现在处于哪一步、下一步该去哪里、什么时候循环、什么时候暂停、什么时候结束。 |
| 项目位置 | 在客服工作台里，它位于 Agent 决策层和业务工具层之间，把“退款投诉处理”编排成识别意图、补信息、查订单、查政策、人工确认、创建工单、最终答复等节点。 |
| 工程动作 | 你要定义状态字段、节点职责、固定边、条件边、循环上限、人工中断点、检查点、恢复策略和节点日志。 |
| 面试说法 | LangGraph（智能体状态图框架）适合把多步骤、可恢复、可审计的 Agent 流程显式化。重点不是 API（应用程序接口），而是把业务状态迁移变成可测试的编排。 |
State（状态）
| 层级 | 解释 |
|---|
| 人话解释 | State（状态）是状态图运行时的任务快照，记录当前知道什么、缺什么、做过什么、下一步受什么约束。 |
| 项目位置 | 客服工作台的 State（状态）包含 session_id（会话编号）、task_id（任务编号）、intent（意图）、order_id（订单号）、risk_level（风险等级）、tool_results（工具结果）、approval_required（需要审批）、retry_count（重试次数）和 stop_reason（停止原因）。 |
| 工程动作 | 状态字段要服务路由和恢复。不要把全部聊天历史塞进状态，也不要缺少影响分支判断的关键字段。 |
| 面试说法 | 状态不是聊天记录，而是驱动工作流的结构化事实。状态设计越清楚，节点和条件边越容易测试。 |
Node（节点）
| 层级 | 解释 |
|---|
| 人话解释 | Node（节点）是工作流中的一个处理步骤。它读取当前状态，完成一个明确动作，然后把更新写回状态。 |
| 项目位置 | 客服流程中的节点可以是 classify_intent（识别意图）、ask_for_order_id（追问订单号）、check_order_status（查订单状态）、search_after_sales_policy（查售后政策）、prepare_ticket_draft（准备工单草稿）、human_confirm（人工确认）、create_ticket（创建工单）。 |
| 工程动作 | 每个节点要定义输入状态、输出状态、可调用工具、失败类型、日志字段和验收样例。 |
| 面试说法 | 我会按业务职责拆节点，让每个节点可测试、可复盘、可替换，而不是把所有逻辑塞进一个巨大 Agent。 |
Edge（边）
| 层级 | 解释 |
|---|
| 人话解释 | Edge（边）定义一个节点完成后流向哪里。固定边表示一定进入下一步。 |
| 项目位置 | 例如 validate_order_scope（校验订单归属）成功后一定进入 check_order_status（查订单状态），create_ticket（创建工单）成功后一定进入 final_response（最终答复）。 |
| 工程动作 | 固定边适合稳定、无争议的顺序动作。边的设计要避免绕过权限、绕过确认或绕过日志。 |
| 面试说法 | 边不是画图装饰，它表达业务顺序和执行约束。固定边适合确定流程，条件边适合分支决策。 |
Conditional Edge（条件边）
| 层级 | 解释 |
|---|
| 人话解释 | Conditional Edge（条件边）根据状态决定下一步去哪。它是状态图控制分支的关键。 |
| 项目位置 | 如果 missing_fields（缺失字段）包含 order_id（订单号），就去 ask_for_order_id（追问订单号）；如果 risk_level（风险等级）为 high（高），就去 human_confirm（人工确认）；如果 retry_count（重试次数）超过上限，就去 handoff_to_human（转人工）。 |
| 工程动作 | 条件边要写清判断依据、优先级、默认分支和异常分支。高风险分支不能只靠模型自由判断。 |
| 面试说法 | 条件边把“模型可能的下一步”收束成“系统允许的下一步”。这是 Agent 工程化的核心。 |
循环控制
| 层级 | 解释 |
|---|
| 人话解释 | 循环控制允许流程在必要时回到前一步，例如工具失败后重试、资料不足时继续追问、模型输出不合格时重新生成。 |
| 项目位置 | 查订单工具超时后，可以回到 check_order_status（查订单状态）节点重试一次；用户补充资料后，从 ask_for_order_id（追问订单号）回到 validate_order_scope（校验订单归属）。 |
| 工程动作 | 循环必须有 retry_count（重试次数）、最大次数、退出条件和兜底路径。没有上限的循环是事故。 |
| 面试说法 | 我不会让 Agent 无限自我修正。每个循环都要有计数、日志和转人工条件。 |
人工确认与中断
| 层级 | 解释 |
|---|
| 人话解释 | 人工确认是让状态图在关键节点暂停，把待执行动作交给用户、客服或审核人确认，再根据确认结果继续。 |
| 项目位置 | 创建投诉工单前，系统要展示问题摘要、关联订单、风险提示和下一步影响；用户确认后才进入 create_ticket（创建工单），拒绝则回到 revise_ticket_draft（修改工单草稿）或结束。 |
| 工程动作 | 人工确认要保存待确认内容、确认人、确认时间、确认结果和恢复入口。用户刷新页面或审核延迟时，流程不能丢。 |
| 面试说法 | 高风险动作不能只靠 Prompt（提示词）约束。我会在状态图里设置人工中断点，让系统暂停、记录、确认后再恢复。 |
检查点与恢复
| 层级 | 解释 |
|---|
| 人话解释 | 检查点是在关键步骤保存状态快照。流程中断、工具失败或人工确认等待后，可以从最近的可靠位置继续，而不是从头重跑。 |
| 项目位置 | 用户补充订单号前，状态停在 waiting_for_order_id（等待订单号）；人工审核前，状态停在 waiting_approval（等待审批）；系统重启后可以根据 task_id（任务编号）恢复。 |
| 工程动作 | 你要定义哪些节点后保存检查点、恢复时需要校验哪些字段、哪些写入动作必须幂等。 |
| 面试说法 | 恢复不是简单重试，而是基于检查点、状态日志和幂等控制继续执行，避免重复建单、重复通知和重复审批。 |
可视化编排
| 层级 | 解释 |
|---|
| 人话解释 | 可视化编排让产品、开发、测试和面试官看到流程到底有哪些路径，而不是只听你说“系统会自动处理”。 |
| 项目位置 | 客服工作台可以把退款投诉流程展示成状态图：当前节点高亮、已执行节点标记、等待确认节点展示待办、失败节点展示原因。 |
| 工程动作 | 你要确保图上的节点、代码里的节点、日志里的节点名称一致。否则可视化会变成另一份容易过期的文档。 |
| 面试说法 | 状态图可视化的价值是辅助调试、验收和沟通，不是替代权限、状态和日志。 |
本章在客服 Agent（智能体）工作台中的位置
客服工作台可以分成 8 层。本章负责复杂工作流编排层。
| 层级 | 作用 | 本章关注点 |
|---|
| 用户入口 | 接收用户问题、补充资料和确认动作 | 提供会话编号、用户身份和确认事件。 |
| 分流层 | 判断意图、风险和初始动作 | 把前面章节的问题分流和治理结果写入状态。 |
| 知识库层 | 检索售后政策、商品说明和客服规范 | 作为 search_after_sales_policy（查售后政策）节点的数据来源。 |
| 工具治理层 | 查订单、查历史工单、创建工单 | 作为状态图中的工具节点或工具调用节点。 |
| 状态与记忆层 | 保存会话状态、任务状态和必要记忆 | 承接客服任务的状态字段和状态迁移表。 |
| 复杂工作流编排层 | 用状态图组织节点、边、分支、循环和人工确认 | 本章核心。 |
| 日志审计层 | 记录节点执行、状态迁移、工具结果和人工确认 | 为恢复、质检和面试提供证据。 |
| 展示层 | 展示当前进度、待确认动作和最终结果 | 根据状态图节点展示不同界面状态。 |
一个重要判断是：LangGraph（智能体状态图框架）不应该吞掉所有业务逻辑。它负责“编排”，订单归属校验仍然在业务系统或工具治理层完成，售后政策仍然来自知识库，工单创建仍然由工单系统返回真实编号。
系统流程图
下面是客服退款投诉流程的状态图表达。
这张图有 5 个重点：
- 所有分支都由状态或业务规则驱动，不让模型自由跳过流程。
- 缺信息和人工确认都会暂停，暂停时必须保存状态。
- 工具失败不是简单报错，而是先判断能否重试，再决定是否转人工。
- 创建工单属于写入动作，必须经过确认和幂等控制。
- 最终状态不只记录回答，还要记录 stop_reason（停止原因）和路径证据。
模块拆分
客服工作台里的 LangGraph（智能体状态图框架）能力，可以拆成 9 个模块。
| 模块 | 作用 | 关键产出 |
|---|
| 状态模型模块 | 定义状态图运行需要的字段 | 运行状态字段表、字段来源、字段更新规则。 |
| 节点目录模块 | 管理所有业务节点 | 节点清单、节点职责、输入输出、失败类型。 |
| 路由规则模块 | 管理固定边和条件边 | 条件判断表、默认分支、异常分支。 |
| 工具节点适配模块 | 把查订单、查政策、创建工单接入节点 | 工具输入、工具输出、权限校验、幂等规则。 |
| 人工确认模块 | 处理暂停、待确认内容和恢复 | 确认卡片字段、确认结果、恢复入口。 |
| 检查点模块 | 保存关键步骤的状态快照 | 检查点策略、恢复策略、过期策略。 |
| 循环与重试模块 | 控制工具重试、草稿修改和补信息循环 | retry_count（重试次数）、最大次数、退出原因。 |
| 可观测性模块 | 记录节点、边、工具和状态变化 | trace_id（追踪编号）、node_run_id（节点运行编号）、状态迁移日志。 |
| 可视化与验收模块 | 给开发、测试和业务方查看流程 | 状态图、路径样例、验收清单。 |
模块拆分的目的不是让项目变复杂，而是让每个职责有边界。尤其是“路由规则”和“工具执行”要分开：条件边决定去哪，工具节点负责做事，权限和业务系统负责判断能不能做。
继续学习