上篇咱们把理赔助手的骨架搭好了 —— 目录、ClaimState、三个业务规则模块、三个子图。今天这篇是下篇，也是最过瘾的部分：把所有零件用主图串起来，让它真正跑起来，还带人工审批和可视化前端。
你会看到，前面学的并行执行、Reducer、interrupt、checkpointer、流式输出，全在这个项目里齐活了。
一、主图的完整流程
主图main_graph.py是整个智能体的调度核心，流程长这样：
collect_request（收集请求） │ ├──► policy_graph（规则校验）──┐ ├──► risk_graph（风险评估）────┤ 三路并行 └──► cases_graph（案例检索）──┘ │ aggregate（汇总 + 大模型生成策略 + 判断是否审批） │ approval（需要审批？→ interrupt 暂停） │ finalize（生成最终客服话术） │ END一共六个关键节点，每个都有明确职责。下面逐个拆。
二、collect_request：初始化
第一步把前端输入的理赔数据（订单号、金额、品类、破损描述、历史理赔数据）写入状态，并加一条初始化日志。后面所有节点都基于同一份ClaimState干活。
三、三个子图并行执行
这是 LangGraph 并行能力的实战体现：collect_request之后，同时连三条边到三个子图节点，规则校验、风险评估、相似案例检索并行跑，不用等一个跑完再跑下一个。
每个子图节点内部负责：从主状态提取自己需要的子集 → 执行子图 → 把结果写回主状态。因为三个子图写的是不同字段（policy_result、risk_level、similar_cases_summary），不会冲突，连 Reducer 都不用额外配（logs字段除外，它有 Reducer 负责累积）。
四、aggregate：汇总 + 生成策略 + 判断审批
这是主图的 "大脑" 节点，干三件事：
- 汇总三方结果：把规则校验、风险等级、案例摘要拼到一起；
- 调大模型生成策略建议：用模板构造提示词，让 DeepSeek 基于规则结果、风险等级、相似案例，生成内部理赔策略和依据说明；
- 判断是否触发人工审批：根据 "风险等级是否 high" 或 "订单金额是否超过阈值"，动态决定要不要人工介入，把结果写进状态。
注意：策略生成用大模型，审批判断用确定性阈值—— 又是一次 "模型负责创造、规则负责控制" 的分工。
五、approval：interrupt 人工审批
这是 Human-in-the-Loop 的实战。如果需要审批，approval节点通过interrupt()把流程暂停，同时返回一个 payload（包含策略说明、风险等级、金额等），等前端填写审批意见后再恢复。
恢复时，approval节点根据人工决策（通过 / 修改 / 拒绝）更新状态里的最终策略字段。如果不需要审批，这个节点只追加一条日志就直接往下走，不会无意义地等待。
这里要记住第四篇讲的两个坑：① 有副作用的操作别放 interrupt 前面（节点恢复时会从头重跑）；② 别用宽泛的 try/except 把 interrupt 异常吞掉。
六、finalize：生成客服话术
最后一步，再调一次大模型，把内部策略撰写成真实客服场景下能直接发给用户的说明文字—— 从决策到用户呈现，形成闭环。这个节点不再做判断，只负责 "把内部语言翻译成用户语言"。
七、持久化：MemorySaver + thread_id
persistence.py封装了检查点，用MemorySaver保存每次节点执行后的状态快照。主图编译时绑定它，每次调用都带thread_id。这样人工审批中断、页面刷新、网络波动之后，都能用同一个thread_id从最近的检查点恢复。
学习阶段用 MemorySaver 够了，上生产换成 Postgres / Redis 就行 —— 这也是第七篇讲过的。
八、调度器 runner：把主图包成统一接口
runner.py是整个项目对外的统一入口，它和业务逻辑完全解耦，只负责调主图：
invoke_once：接受初始状态和 thread_id，触发主图从头执行（前端提交理赔请求时用）；resume_with_decision：前端提交审批意见后，把审批内容写入状态并恢复执行；- 流式接口：虽然当前主要用同步调用，但预留了流式执行能力，方便未来做进度展示。
有了调度器，前端或未来的 API 服务根本不需要知道内部有几个节点、几个子图，只管调接口就行。
九、Streamlit 前端：让客服真能用
app_streamlit.py做了一个直观的客服页面：
- 左侧结构化输入区：订单号、金额、品类、破损描述、历史理赔数据；
- 提交后生成唯一 thread_id，调调度器启动流程；
- 右侧实时展示流程日志、执行轨迹、各阶段结果（可观测性）；
- 触发人工审批时自动渲染审批表单，提交后恢复执行；
- 流程结束展示最终用户话术 + 完整状态 JSON（方便核查调试）。
前端把 LangGraph 的复杂逻辑全藏在后台，客服人员只需要填数据、看结果、做审批，不用懂任何技术。
十、五个测试场景跑一遍
项目准备了五个真实场景，覆盖所有分支：
表格
| 场景 | 输入特征 | 触发结果 |
|---|---|---|
| 1 | 普通易碎品、低风险 | 自动通过 |
| 2 | 金额较高 | 触发人工审批 → 通过 |
| 3 | 金额较高 | 触发人工审批 → 驳回（备注理由） |
| 4 | 虚拟商品 | 规则校验不通过，自动拒绝 |
| 5 | 金额小 + 风险中等 | 自动通过 |
每个场景都能在前端看到完整的执行日志和最终输出，你可以亲手验证每一条分支是否符合预期。
十一、技术栈总结与拓展方向
核心技术栈：LangGraph（图工作流引擎）+SubGraph（模块化拆分）+Interrupt/Resume（人工审批）+MemorySaver（耐久恢复）+Streamlit（可视化前端）。
未来可以拓展的方向：
- 接入真实风控模型或外部数据库，提升风险判断精度；
- 案例检索升级为向量数据库，做语义匹配；
- 接入破损照片上传 + 图像识别，提高自动化程度；
- 对接企业工单系统，把智能体输出自动写入工单；
- 扩展风控维度：商品易碎等级、商家评分、物流线路等。
老哥的收尾：到这里，一个可运行、可追踪、可恢复、可审批的企业级 Agent 原型就完整了。给你个记忆锚点：
状态是脊梁，子图是模块，并行提效率，interrupt 保安全，checkpointer 管恢复，调度器做封装，前端给人用。
这个项目里用到的每一个能力，前面七篇都讲过。现在你知道它们组合起来能干什么了 —— 剩下的，就是找一个你自己的业务场景，照着这个范式搭一个。有问题随时回来找老哥。
