全栈开发指南

Appearance

为什么需要工作流编排？ ​

想象一下，你要做一个智能客服系统。最简单的做法是：用户提问 → 调用大模型 → 返回答案。但在真实业务中，事情远没那么简单：

  • 需要先判断用户意图（是退货、查询订单还是闲聊？）
  • 可能要从数据库查询用户信息
  • 如果需要退货，要调用订单系统的API
  • 遇到复杂问题可能需要多次调用大模型
  • 某些步骤需要人工审核
  • 出错需要重试机制

这就是工作流编排的价值所在——把多个步骤组织成一个可管理、可调试、可扩展的流程。

从有向无环图说起 ​

传统的工作流通常采用DAG（有向无环图）结构。你可以把它想象成一条单行道，节点A到节点B到节点C，方向固定，不能走回头路，更不能形成环路。

shell
传统DAG工作流示意
用户输入 → 意图识别 → 调用API → 生成回复 → 输出结果

这种结构简单清晰，但面对复杂的AI应用场景时，局限性就暴露出来了。

为什么要引入循环和状态？ ​

真实的人机对话天然就是循环的，比如：

Python
用户：我想买一件羽绒服
AI：您需要什么颜色的？
用户：黑色
AI：什么尺码？
用户：XL
AI：为您推荐以下商品...

这里AI需要记住之前对话的所有信息（颜色、尺码等），并在多轮对话中不断更新状态。传统的DAG无法优雅地处理这种场景，这正是LangGraph要解决的问题。

LangGraph是什么 ​

官方定义解读 ​

LangGraph是LangChain生态中专门用于构建有状态、多角色、循环工作流的图基（Graph-based）编排框架。它的核心理念是：将复杂的AI应用建模为由节点和边组成的图结构，其中节点代表处理步骤，边代表控制流与数据流。

用一句话概括：LangGraph = 图结构 + 状态管理 + 循环能力 + 大模型集成

通俗类比：智能工厂流水线 ​

把LangGraph想象成一座高度智能化的工厂流水线：

  • 节点：每个工作站（质检、加工、包装等）
  • 边：工作站之间的传送带
  • 状态：记录每个产品当前加工进度、参数、质量数据的信息卡
  • 条件边：根据质检结果决定产品是进入下一环节还是返工
  • 循环：不合格产品可以送回维修工位

传统流水线只能单向流动，而LangGraph可以让产品在工位间灵活流转，甚至形成反馈闭环。

LangGraph的历史渊源 ​

LangGraph由LangChain团队开发，于2023年底首次发布。它的诞生背景是：

  1. LangChain的局限性：原生的Chain和LCEL（LangChain Expression Language）虽然强大，但主要面向线性流程
  2. Agent需求的爆发：ReAct Agent、Plan-and-Execute Agent等复杂架构需要循环和状态控制
  3. 借鉴经典思想：从Google的Pregel图计算模型和Actor模型中汲取灵感

技术栈定位 ​

LangGraph在整个技术栈中的位置可以这样理解：

Python
应用层：你的业务代码
    ↓
编排层：LangGraph（本课程核心）
    ↓
组件层：LangChain（提示词模板、工具调用、输出解析器等）
    ↓
模型层：OpenAI、Claude、通义千问、文心一言等大模型
    ↓
基础设施层：向量数据库、Redis、PostgreSQL等

和LangChain/普通工作流区别 ​

这是很多人最困惑的地方，我们来彻底理清楚。

LangGraph vs LangChain：不是替代，是增强 ​

LangChain的核心定位：提供构建AI应用的基础组件（组件化思维）

  • 提示词模板（PromptTemplate）
  • 模型抽象（ChatModel）
  • 工具调用（Tools）
  • 输出解析器（OutputParser）
  • 简单的链式组合（LCEL）

LangGraph的核心定位：提供复杂的流程控制能力（图编排思维）

  • 状态管理和传递
  • 循环和分支控制
  • 人机交互（Human-in-the-Loop）
  • 持久化和时间旅行

协同使用的最佳实践：

Python
# LangChain提供组件
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

# LangGraph负责编排
from langgraph.graph import StateGraph, Message

# 典型组合：LangChain组件作为节点，LangGraph负责流程
model = ChatOpenAI(model="gpt-4")
@tool
def search(query: str) -> str:
    """搜索工具"""
    return f"搜索结果: {query}"

# 在LangGraph节点中调用LangChain组件
def call_model(state):
    response = model.invoke(state["messages"])
    return {"messages": state["messages"] + [response]}

LangGraph vs 普通工作流（如Prefect、Airflow） ​

传统工作流引擎主要用于数据处理ETL、任务调度，特点是：

  • 步骤通常是确定性的（没有LLM的不确定性）
  • 循环需求少（更多是批处理）
  • 状态管理简单（主要是任务依赖）

LangGraph专门为AI Agent场景设计：

  • 支持LLM的动态决策（下一步走哪个分支可能由模型决定）
  • 原生支持循环（多轮对话、自我反思）
  • 状态持久化（保存对话历史、中间结果）
  • Human-in-the-Loop（人工介入决策）

核心对比一览表 ​

维度LangGraphLangChain原生Chain传统工作流引擎
主要用途复杂AI Workflow/Agent简单链式调用数据处理/任务调度
流程结构图（支持循环）链/有向无环图有向无环图
状态管理强大的状态持久化仅链式传递主要是任务状态
LLM集成一等公民一等公民不支持或弱支持
人工介入原生支持需额外实现部分支持
调试工具时间旅行/可视化基本日志DAG可视化
学习曲线中等低中高

为什么要同时学LangChain和LangGraph？ ​

这是一个常见的疑问。我的建议是：

  1. LangChain是基础：提示词模板、模型调用、工具定义这些基本能力是通用需求
  2. LangGraph是进阶：当你的场景需要循环、多轮对话、复杂状态管理时再用
  3. 两者是互补关系：80%的LangGraph代码其实是调用LangChain的组件

学习路径建议：先掌握LangChain核心概念 → 再用LangGraph做流程编排 → 最后深入LangGraph高级特性。

核心架构拆解 ​

让我们从架构层面理解LangGraph的四大核心模块。

模块一：状态管理（State Management） ​

State是什么？

State是贯穿整个工作流的全局数据容器，可以理解为一个JavaScript对象或Python字典，在每个节点之间传递和更新。

Python
from typing import TypedDict, List, Annotated
from operator import add

# 定义状态结构
class AgentState(TypedDict):
    messages: Annotated[List[str], add]  # 使用add reducer自动追加
    user_query: str
    intermediate_results: List[dict]
    iteration_count: int

状态更新机制（Reducers）：

  • 默认覆盖：新值直接替换旧值
  • 自定义Reducer：如add可以累加列表，max可以保留最大值
  • Annotated类型：为字段指定更新策略

状态的隔离与共享：

  • 单工作流实例中，State是全局共享的
  • 多实例之间状态完全隔离
  • 持久化时可选保存完整历史

模块二：节点系统（Node System） ​

节点的本质：节点就是普通的Python函数，接收State，返回更新后的State（或部分更新）。

Python
def node_function(state: AgentState) -> dict:
    # 读取state
    user_input = state["user_query"]
    
    # 执行具体逻辑（调用LLM、API、数据库等）
    result = do_something(user_input)
    
    # 返回需要更新的字段
    return {"intermediate_results": [result], "iteration_count": state["iteration_count"] + 1}

节点的核心特征：

  1. 无副作用设计：节点的输入只有State，输出也只通过State传递
  2. 可组合性：节点可以任意编排组合
  3. 可测试性：纯函数设计让单元测试变得简单
  4. 异步支持：节点可以是async函数

节点类型（按功能划分）：

  • 处理节点：核心业务逻辑（调用LLM、处理数据）
  • 决策节点：根据条件决定路由（通常配合条件边）
  • 工具节点：调用外部API、数据库操作
  • 人工节点：需要人工介入的节点（审批、确认）

模块三：边与路由（Edges & Routing） ​

边的类型：

  1. 普通边（Normal Edge）：固定路径，节点A执行完必然到节点B
python
graph.add_edge("node_a", "node_b")
  1. 条件边（Conditional Edge）：根据状态决定下一个节点
Python
graph.add_conditional_edges(
    "decision_node",
    lambda state: "continue" if state["quality"] > 0.8 else "rework",
    {
        "continue": "next_step",
        "rework": "start_over"
    }
)
  1. 入口边（Entry Point）：指定工作流的起始节点
python
graph.set_entry_point("start_node")
  1. 结束边：终止工作流（到达END节点）

路由策略设计模式：

  • 简单if-else路由
  • 多分支switch路由
  • 动态路由（基于LLM决策）
  • 并行路由（多个节点同时执行，需配合Send API）

模块四：持久化与检查点（Persistence & Checkpoint） ​

这是LangGraph的企业级特性，让工作流可以"暂停-恢复"。

检查点（Checkpoint）：

  • 在每个节点执行前后自动保存状态快照
  • 支持保存到内存、文件、数据库、Redis
  • 保存每次状态变更的历史记录

时间旅行（Time Travel）：

Python
# 获取历史状态
history = graph.get_state_history(config)

# 回滚到任意历史版本
graph.update_state(config, state, as_node="某个节点")

# 从历史分支继续执行
graph.invoke(None, config=历史config)

生产级持久化方案：

  • 使用Redis：适合高并发场景
  • 使用PostgreSQL：适合需要强一致性的事务场景
  • 自定义存储后端：实现BaseCheckpointSaver接口

适用业务场景 ​

LangGraph已经在多个领域得到验证，以下是典型的应用场景。

场景一：客服智能体 ​

业务痛点：

  • 需要多轮对话收集信息
  • 需要查询订单、物流等外部系统
  • 需要人工审核退款等敏感操作

LangGraph解决方案：

Python
开始 → 意图识别 → 
分支1（退货）：收集信息 → 查询订单 → 人工审核 → 调用退货API → 结束
分支2（查询）：查询物流 → 返回结果 → 结束
分支3（投诉）：转人工客服 → 记录投诉 → 结束

场景二：代码助手 ​

业务痛点：

  • 需要先生成代码，再执行测试
  • 测试失败需要重新生成
  • 可能需要人工审查关键代码

LangGraph解决方案：

Python
用户需求 → 生成代码 → 执行单元测试 → 
如果通过：代码审查 → 输出结果
如果失败：分析错误 → 重新生成（循环最多3次）

场景三：RAG问答系统 ​

传统RAG的局限：一次检索就生成答案，无法应对复杂问题

LangGraph增强版RAG：

Python
用户问题 → 问题重写 → 多路检索（向量+关键词+网络）→ 
结果融合 → 相关性判断 → 
如果相关：生成答案 → 检查结果 → 
如果不相关：追问用户或重新检索

场景四：多角色协作系统 ​

Python
典型架构：
用户输入 → 调度器Agent → 
分支：
- 编程任务 → 程序员Agent → 代码审查Agent →
- 写作任务 → 编辑Agent → 校对Agent →
- 数据分析 → 数据科学家Agent → 可视化Agent →
结果汇总 → 输出

场景五：数据标注与验证 ​

业务流程：

Python
待标注数据 → AI预标注 → 抽样检测 → 
如果质量达标：批量应用 → 结束
如果质量不达标：人工复审 + 模型微调 → 重新标注

竞品框架对比 ​

了解LangGraph在生态中的位置，有助于做出技术选型决策。

AutoGen（微软） ​

定位：多Agent对话框架

优势：

  • 多Agent间自然语言对话
  • 支持Agent自动组队
  • 代码执行沙箱

劣势：

  • 流程控制弱（对话即逻辑）
  • 状态管理不明确
  • 调试困难

vs LangGraph：AutoGen更简单，适合快速原型；LangGraph更强大，适合复杂工程。

LangGraph vs CrewAI ​

CrewAI定位：角色扮演Agent框架

优势：

  • 概念简单（Agent、Task、Crew）
  • 代码量少
  • 适合任务编排

劣势：

  • 灵活性不足
  • 循环支持弱
  • 状态管理简单

vs LangGraph：CrewAI适合明确分工的场景；LangGraph适合需要精细控制流的场景。

LangGraph vs Semantic Kernel（微软） ​

定位：传统工作流+AI集成

优势：

  • 企业级集成好
  • 支持C#/Python
  • 规划器（Planner）功能强

劣势：

  • 学习曲线陡
  • 社区小
  • 中文资料少

vs LangGraph：Semantic Kernel适合.NET技术栈企业；LangGraph在Python生态更有优势。

为什么选择LangGraph？ ​

  1. 背靠LangChain生态：最大的LLM应用开源社区
  2. 原生Python：Python是AI开发的第一语言
  3. 灵活性与可控性平衡：既有高级抽象，又允许底层控制
  4. 企业级特性：状态持久化、时间旅行是竞品普遍缺失的
  5. 持续迭代：LangChain团队全职维护，更新活跃

为什么要学LangGraph ​

从技术趋势看 ​

2024-2025年，AI应用开发正在经历从"单一调用"到"复杂编排"的演进：

  • 单次LLM调用 → Chain of Thought → ReAct Agent → Multi-Agent System
  • 简单问答 → RAG → GraphRAG → Self-RAG
  • 一次性生成 → 循环优化 → 决策树搜索

LangGraph正是这一演进过程中的关键基础设施。

从就业市场看 ​

头部公司招聘需求已经出现：

  • 岗位要求：熟悉LangChain/LangGraph，有Agent开发经验
  • 薪资水平：相比普通AI工程师高出30-50%
  • 稀缺性：熟练掌握LangGraph的人才目前非常稀缺

从能力提升看 ​

学习LangGraph不只是学一个框架，更是培养：

  • 系统设计思维：如何拆解复杂AI任务
  • 状态管理能力：如何处理有状态工作流
  • 工程化意识：如何编写可维护、可测试的AI代码

这些能力在任何AI工程岗位上都是通用的。