上一篇：RAG 详解：让模型学会“查资料”

一、从 LangChain 说起：它已经很好了，但还不够

在前几篇中，我已经用 LangChain 搭建过一些 AI 应用，比如：

• 对话机器人
• RAG 问答系统
• 简单工具调用

---

这些系统有一个共同特点：

本质是“单轮 or 短链路”的 AI 应用

也就是说，它们通常是这样的结构：

	用户输入 → LLM → 输出结果

或者稍微复杂一点：

	用户输入 → 检索知识库 → LLM → 输出

这种单链路、短记忆的模式，就像你雇了一个智商很高但患有严重失忆症且只能单线程工作的实习生。

---

这类应用的核心问题在于：

1. 上下文能力有限（记忆弱）

LangChain 默认是“短期记忆”：

每次调用基本是独立的
长任务容易“忘记之前干了啥”

---

举个例子：

你：我叫小明
AI：好的小明
你：我叫什么？
AI：？？？

本质原因：没有长期状态管理机制

---

2. 只能做“简单流程”，不适合复杂任务

LangChain 更擅长：

• 一问一答
• 单链路推理
• 简单工具调用

---

但如果是这种任务：

帮我规划一次旅行（查天气 → 找景点 → 订酒店 → 规划路线）

就会出现问题：

• 步骤多
• 有依赖关系
• 需要中间状态

LangChain 很难优雅表达这种“多步骤流程”

---

3. Agent 不可控（黑盒）

LangChain 也支持 Agent，但问题是：

• 决策过程不透明
• 很难 debug
• 不知道为什么调用某个工具

就像一个“黑盒 AI”

---

4. 难以工程化（上线困难）

如果你想做一个真正的系统，比如：

• 7×24 AI 客服
• 自动数据分析助手
• 多步骤自动化流程

你会遇到：

• 状态丢失
• 无法恢复执行
• 无法中途干预
• 部署复杂

---

这些问题我们可以总结为四类：

• 状态丢失 没有长期记忆
• 难以调试 黑盒
• 无法干预 不可控
• 部署困难 不工程化

---

二、一个更高级的形态：Agent Server

为了解决这些问题，我们需要一个更强的概念：

Agent Server（智能体服务）

它不再是一个简单的 AI，而是：

一个可以“长期运行 + 多步骤执行 + 可交互”的 AI 系统

我们可以举个例子：
LangChain 时代的应用像
是街边的拍立得快照——拍完即走，两不相欠

而 Agent Server 更像
是正在拍摄一部电影——有场记板（记录状态）、有剧本分镜（多步骤）、导演随时能喊“卡！重来一条”（可干预）

---

Agent Server 能做什么？

可以把它想象成一个“真正的 AI 助手”：

• 记住你所有历史
• 自动执行多个步骤
• 可以暂停，等你反馈
• 能持续运行（不是一次性）

比如：

你跟AI说：
我想去南京，帮我规划周末旅行（这里有DeepSeek举例）

---

它会自动：

1. 查天气
   

2. 找景点

3.住宿

4. 规划路线
   

5. 给出打包建议
   

这已经不是“问答”，而是“执行任务”

---

三、核心分歧：Workflow vs Agent

在构建 Agent Server 时，有两种思路：

1. Workflow（工作流）

特点：

• 流程固定
• 代码驱动
• 可预测

---

比如：

提交申请 → 审批 → 审核 → 结束

本质：流程驱动

2. Agent（智能体）

特点：

• LLM 决策
• 动态规划步骤
• 灵活但不可控

---

举个例子：

AI自己决定：
先查天气？还是先订酒店？

本质：模型驱动

一句话总结：
类型 核心
Workflow 固定流程
Agent 动态决策

有个很形象的比喻：

Workflow = 炒菜机器人（按步骤）
Agent = 米其林大厨（自己判断）

---

总结：

维度	Workflow（工作流）	Agent（智能体）
核心驱动力	预设规则、流程图	LLM 大脑动态决策
类比	🥘 炒菜机器人（按菜谱按钮）	👨‍🍳 米其林大厨（凭经验发挥）
优点	稳定、可预测、易审计	智能、灵活、能处理意外情况
缺点	死板，遇变则堵	偶尔抽风，可能陷入死循环

四、一个问题：两者都不完美

只用 Workflow：

• 太死板
• 不智能
• 遇到菜谱里没有的菜就傻眼

---

只用 Agent：

• 太不可控
• 不稳定
• 你永远不知道它下一秒会不会把盐当成糖

所以我们需要一个：

既能控制流程，又允许智能决策的系统

---

五、LangGraph：Agent Server 的“操作系统”

这就是 LangGraph 出现的原因。

LangGraph 是什么？

一句话：

LangGraph = 用来构建 Agent Server 的底层框架

更准确一点：

它是“状态 + 流程 + 控制”的统一解决方案

---

我们可以这样做一个类比：

如果把整个系统看成一个公司

公司角色	AI 系统对应物	负责做什么
一线员工	LLM（大模型）	干活、写文案、写代码、推理
办公设备	Tools（工具）	搜索引擎、计算器、数据库
项目经理 + OA系统	LangGraph	管理进度、画流程图、存档、干预

简单来说，LangGraph 是⼀个专⻔⽤于构建和管理 Agent Server 的底层框架

---

六、LangGraph 解决了什么问题？

课件总结成三大能力

1. 记忆（State）

解决： LangChain “记不住”的问题

• 所有步骤共享状态
• 可以长期保存
• 支持复杂数据结构

---

2. 流程控制（Graph）

解决：多步骤任务难以表达的问题

• 用“图”定义流程
• 支持分支 / 循环 / 条件

3. 工程能力（生产级）

解决：无法上线的问题

包括：

• 持久化执行：构建能从故障中恢复、长时间运行的 Agent Server
• 可人工介入：允许在流程中随时检查和修改 Agent Server 状态
• 可调试：与 LangSmith 集成，提供可视化追踪和深度洞察
• 可部署：为有状态、长时工作流提供可扩展的部署方案

---

七、用“快递系统”彻底理解 LangGraph

我们可以理解：
LangGraph = 一个智能快递配送系统

1. 核心概念一一对应

• State（状态） 包裹信息
• Node（节点） 快递站点
• Edge（边） 运输路线
• Graph（图） 整个物流网络

---

2. State：状态 = 包裹信息

在快递系统中，每个包裹都有一张“信息卡”：

• 包裹ID：P001
• 起点：北京
• 终点：上海
• 状态：运输中
• 历史记录：已揽收 → 已分拣 → 运输中

在 LangGraph 中：

State 就是这张“全局共享的数据结构”

特点：

• 所有节点都能访问
• 所有节点都能修改
• 在整个流程中持续存在

对应 AI 系统：

用户问题 → 思考 → 工具调用 → 再思考 → 输出

每一步都在“更新同一个 State”

---

3. Node：节点 = 快递站点

每个节点只做一件事：

• 揽收站 → 初始化信息
• 分拣中心 → 做决策
• 配送节点 → 执行运输
• 派送站 → 完成任务

在 LangGraph 中：

Node 本质就是一个函数

---

4. Edge：边 = 运输路线（流程控制核心）

快递有固定路线：

揽收 → 分拣 → 派送

但也有“分支”：

普通件 → 陆运
加急件 → 空运

---

在 LangGraph 中：

固定边：固定流程（Workflow）
条件边：动态决策（Agent）

总结：

LangGraph = Workflow + Agent 的融合

---

八、小结

LangChain 已经让我们能“用 AI 做点事情”，
但当任务变复杂，它就开始力不从心：

->记不住
->跑不长
->控不住

于是，Agent Server 这种“长期运行的 AI 系统”成为必然

---

而 LangGraph，本质上就是：

给 AI 系统补上「记忆 + 流程 + 控制」三大能力

如果说：

LangChain 是一个聪明但短期记忆的实习生
那 LangGraph 就像一个成熟的项目管理系统

它不会替你干活，但它能让一群 AI：

有序地协作、持续地执行、稳定地完成任务~