LangGraph 实战笔记：用 AI 发起流程应用

📒 LangGraph 实战笔记：用 AI 发起流程应用

一句话总结：LangGraph 让 AI 从“直线思维”变成“闭环思维”，是实现复杂、可循环、人机协同工作流的首选工具。

目录

• 一、核心概念（无代码版）
• 二、LangGraph vs LangChain vs K2 三方对比
• 三、需求拆解：AI 发起考勤流程
• 四、为什么这个场景必须用 LangGraph？
• 五、关键实现要点（无代码版）
• 六、生活化类比总结
• 七、选型决策指南
• 八、总结与下一步建议

一、核心概念（无代码版）

二、LangGraph vs LangChain vs K2 三方对比

三者核心区别

LangChain 和 LangGraph 的关系

┌─────────────────────────────────────────────────────────────┐ │ │ │ LangChain LangGraph │ │ ┌─────────┐ ┌─────────────────────────┐ │ │ │ LLM │ │ ┌─────┐ ┌─────┐ │ │ │ │ 调用 │ → │ │节点 │→ │节点 │ ... │ │ │ │ 工具 │ │ └─────┘ └─────┘ │ │ │ │ 记忆 │ │ ↖ ↙ │ │ │ └─────────┘ │ 循环/条件 │ │ │ └─────────────────────────┘ │ │ │ │ 基础组件库 基于 LangChain 的编排层 │ │ (砖头、水泥) (用砖头盖成的房子) │ │ │ └─────────────────────────────────────────────────────────────┘

关键理解：

• LangGraph不是替代LangChain，而是构建在 LangChain 之上
• LangChain 提供「能力」——调用 LLM、工具、记忆
• LangGraph 提供「编排」——如何组织这些能力的执行顺序

三、需求拆解：AI 发起考勤流程

需求描述

用户说“我想发起考勤”
↓
AI 返回表单结构
↓
用户填写数据
↓
AI 校验数据 ──┬── 通过 → 发起流程
│
└── 不通过 → 返回让用户重填（可循环）

完整流程架构图

┌─────────────────────────────────────────────────────────────────┐ │ LangGraph 工作流全景图 │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 意图识别 │───→│ 生成表单 │───→│ 用户填写 │ │ │ │ Node │ │ Node │ │ (人工) │ │ │ └─────────┘ └─────────┘ └────┬────┘ │ │ │ │ │ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 发起流程 │←───│ 校验通过？│←───│ AI 校验 │ │ │ │ Node │ │ 条件 │ │ Node │ │ │ └─────────┘ └────┬────┘ └─────────┘ │ │ │ │ │ ┌─────────────┴─────────────┐ │ │ │ │ │ │ ▼ ▼ │ │ 【成功】结束 【失败】循环回去 │ │ (最多重试 3 次) │ │ │ └─────────────────────────────────────────────────────────────────┘

各节点职责说明

四、为什么这个场景必须用 LangGraph？

❌ 用 LangChain 的困境

LangChain 线性执行：

用户输入 → 识别意图 → 生成表单 → 用户填写 → 校验 → 结束 │ ▼ 校验失败？ 没法回去！ 只能重新发起整个流程

问题：

• 校验失败后无法自动循环回填写节点
• 需要自己管理状态和重试逻辑
• 代码会越来越复杂，难以维护

✅ 用 LangGraph 的优势

LangGraph 循环执行：

用户输入 → 识别意图 → 生成表单 → 用户填写 → 校验 ──┬── 通过 → 发起 │ └── 失败 → 回到填写

优势：

• ✅ 天然支持循环，校验失败自动回到填写节点
• ✅ 状态自动管理，每次循环数据不丢失
• ✅ 支持断点续传，用户可随时回来继续
• ✅ 流程可视化，调试和维护更简单

五、关键实现要点（无代码版）

🔑 1. 防止无限循环

┌─────────────────────────────────────────┐ │ 循环控制策略 │ ├─────────────────────────────────────────┤ │ 设置最大重试次数（建议 3-5 次） │ │ 超过次数 → 转人工处理 │ │ 每次循环记录重试计数 │ └─────────────────────────────────────────┘

🔑 2. 状态持久化（断点续传）

┌─────────────────────────────────────────┐ │ 状态保存机制 │ ├─────────────────────────────────────────┤ │ 每个节点执行后自动存档 │ │ 用户关闭页面后再回来，进度不丢失 │ │ 通过线程 ID 关联同一用户的会话 │ └─────────────────────────────────────────┘

🔑 3. 人机交互（等待用户填写）

┌─────────────────────────────────────────┐ │ 人工介入节点 │ ├─────────────────────────────────────────┤ │ 流程在填写节点暂停 │ │ 用户通过前端界面提交数据 │ │ 系统接收后继续执行后续节点 │ └─────────────────────────────────────────┘

🔑 4. 流式反馈（实时显示结果）

┌─────────────────────────────────────────┐ │ 实时反馈机制 │ ├─────────────────────────────────────────┤ │ 不用等全部完成才返回 │ │ 每执行一个节点就返回进度 │ │ 用户能看到校验反馈，体验更好 │ └─────────────────────────────────────────┘

六、生活化类比总结

七、选型决策指南

八、总结与下一步建议

核心收获

• LangGraph = LangChain 的能力 + 工作流的编排 + AI 的动态决策
• LangGraph 不是替代 LangChain，而是它的编排层
• 有循环需求的 AI 任务，LangGraph 是首选
• 状态管理是核心，不用自己存，框架自动处理
• 人机交互是亮点，支持中断、恢复、转人工

维度结论

下一步建议

1. 先跑通最小 Demo（识别→校验→提交）
2. 添加状态持久化（支持断点续传）
3. 对接 OA 系统 API（正式发起流程）
4. 完善前端交互（流式反馈、重试提示）

笔记整理完成 📝 概念清晰、架构完整、对比明确，可直接用于技术方案评审！