十、LangGraph能力详解（1）LangGraph介绍及核心概念

正式进入LangGraph

1. LangGraph 是什么？

1.1 认识智能服务（Agent Server）

学习过 LangChain，我们已经知道 AI 世界是如何初步搭建的。实际我们已经用过：

• ChatGPT 原生模型：对话式 AI，一问一答

• DeepSeek 客户端：类似的对话助手

• 一些 AI 工具：比如 AI 画画、AI 写文章等

在 LangChain 篇章中，我们接入 LLM 构建的 AI 系统有以下特点：

• 单次对话，"记不住"太多上下文

• 主要是问答模式

• 相对简单的任务

什么是 Agent Server？它是更聪明的 AI 助手 想象一个虚拟的"小助手"，它不仅能回答问题，还能：

• 记住和你聊过的所有事情

• 执行一连串任务（比如：查天气 → 推荐穿搭 → 提醒带伞）

• 中途可以等你给出反馈

• 运行很长时间不会"忘记"

Agent Server 例子：

分镜 1：我说 "帮我规划周末旅行"，Agent Server 界面显示回应。

分镜 2：Agent Server 第一步 "查天气"，屏幕 显示天气预报界面

分镜 3：Agent Server 第二步 "找景点"，屏幕 展示景点列表和图片。

分镜 4：Agent Server 第三步 "订酒店"，屏幕 显示酒店预订页面。

分镜 5：Agent Server 第四步 "规划路线"，屏 幕呈现地图路线图。

分镜 6：Agent Server 第五步 "打包建议"，屏 幕列出物品清单。

1.2 构建 Agent Server 时遇到的四大难题

难题	描述	就像·比喻
状态丢失	AI 处理长任务时容易"忘记"前面步骤	写长文章时电脑突然关机
难以调试	不知道 AI 为什么做出某个决定	黑盒子，看不到内部
无法干预	不能中途给 AI 指导	自动驾驶不能接管
部署困难	复杂 Agent Server 难以上线运行	手工制作 vs 工厂生产

1.3 解决方案：LangGraph -- Agent Server 的"操作系统"

LangGraph 是一个强大且灵活的"Agent Server 操作系统内核"。 它不关心我们具体用什么模型或 提示词，而是**为我们解决构建复杂、可靠、可交互的 Agent Server 时所面临的状态管理、流程编排、 持久化和人工监督等底层工程难题。**如果我们需要构建超越简单问答的、具备复杂逻辑和长期记忆的 AI 应用，LangGraph 就是为此设计的工具。

如果把 Agent Server 比作一个公司，那么：

• AI 模型 = 员工（干活的人）

• 工具 = 办公设备（电脑、电话）

• LangGraph = 项目经理 + 流程系统

简单来说，LangGraph 是一个专门用于构建和管理 Agent Server 的底层框架。

1.3.1 LangGraph 的三大超能力

1.3.1.1 记忆大师

# 传统AI：每次对话都是新的开始
AI回答("你好") → "你好！"
AI回答("我叫小明") → "很高兴认识你！"
AI回答("我叫什么？") → "我不知道你的名字"
# LangGraph Agent Server：记住一切
Agent Server("你好") → "你好！"
Agent Server("我叫小明") → "你好小明！"
Agent Server("我叫什么？") → "你叫小明！

无论过了多久，会话了多少次，LangGraph 都可以记住！

1.3.1.3 容错卫士

LangGraph 还提供了以下关键基础设施，保障 Agent Server 的执行过程：

• 持久执行：构建能从故障中恢复、长时间运行的 Agent Server。

• 人工介入：允许在流程中随时检查和修改 Agent Server 状态。

• 强大的调试能力：与 LangSmith 集成，提供可视化追踪和深度洞察。

• 生产就绪的部署：为有状态、长时工作流提供可扩展的部署方案。

1.3.2 LangGraph 在现实中的应用

LangGraph 为生产级代理提供支持，受到 LinkedIn、Uber、Klarna、GitLab 等公司的信赖。

公司	相关产品/服务	主要功能/定位	核心技术/备注
LinkedIn	LinkedIn AI 代理（如 LinkedIn Coach）	提供个性化工作推荐、人脉拓展、职业发展建议等	目前主要在探索和测试阶段，旨在提升平台互动体验
Uber	Uber AI Solutions（智能体解决方案）	为企业提供构建自主、目标驱动的多智能体 AI 系统的框架、工具和数据服务	强调其智能体 AI 可协调处理复杂任务，是其主要技术方向
Klarna	1. AI 支付与购物助手 2. Agentic Product Protocol	1. 处理支付、退款等客服任务，已进行数百万次对话 2. 一个让 AI 智能体能发现和比较线上产品的开放数据协议	其 AI 助手明确由 LangGraph 构建，是智能体技术在生产环境中的典型应用案例
GitLab	1. GitLab Duo 2. CodeRider	一套覆盖软件开发生命周期（需求、编码、测试、部署等）的 AI 助手套件	其中 CodeRider 是一款深度集成 GitLab 的 AI 编程工具，基于 LangGraph 开发

除了表格中的概述，各公司的智能体产品在设计和应用上各有侧重：

• Klarna 是瑞典的一家金融公司，他的 AI 助手是将 LangGraph 应用于生产级业务的典范。它已 经处理了超过 250 万次对话，自动化了约 70% 的重复性客服任务，将平均问题解决时间缩短了 80%。该助手是一个多智能体系统，能自主路由请求、处理不同任务（如支付、退款等），并显 著提升了服务效率。

• GitLab 的 AI 产品线非常丰富，其 CodeRider 产品特别值得关注。它基于 LangGraph 构建，不 仅提供代码补全、解释等基础功能，更能胜任复杂任务的全流程智能开发，例如自动分解任务、 跨文件编辑代码、执行终端指令等。而 GitLab Duo 则是一个更广泛的 AI 功能套件，包含代码建 议、漏洞解释、合并请求摘要等数十种功能，旨在扮演虚拟开发团队的角色。

思考一下，我们可以构建什么？

• 个人学习助手（记住你的学习进度）

• 智能客服（处理复杂咨询）

• 数据分析助手（多步骤分析）

• 游戏 NPC（有记忆的虚拟角色）

2. LangGraph 生态系统

LangGraph 是 LangChain 产品家族的一部分。可以与 LangSmith（用于追踪、评估、监控）、 LangGraph 部署平台（用于轻松部署和扩展Agent Server）以及 LangChain（提供大量集成和组件） 结合使用，形成完整的开发、调试、部署工作流。 LangGraph 与 LangChain 顺利集成，但也可以在没有 LangChain 的情况下使用。

3. LangGraph 的核心概念

3.1 常见概念区分

3.1.1 Agent

An agent is AI-powered software that accomplishes a goal. Period." --- Dharmesh Shah, HubSpot CTO and Agents.ai co-founder

Agent是实现目标的人工智能软件--- Dharmesh Shah, HubSpot 首席技术官兼 Agents.ai 联合创始人

其核心在于：由大语言模型 (LLM) 动态控制流程走向

想象你有一个超级聪明的程序员助手, 你只需要说一句："把这个项目的单元测试覆盖率提升到 80%. " 然后他就自己去看代码、写测试、运行构建、检查结果......直到达标为止------中间不需要你插手. 这个"能独立完成任务"的程序, 就是我们说的 Agent (智能体) .

想象一个私人助理机器人：

• 你说："帮我安排下周去上海的差旅. "

• 它不会傻傻地只回复"好的", 而是会：

a. 查天气 → 决定带什么衣服

b. 查航班/高铁时间 → 比较价格

c. 预订酒店 → 发送日程到你的手机

d. 提醒你带身份证 整个过程没有固定的流程图, 它自己"想"出来的步骤------这就是典型的 Agent 行为

3.1.2 工作流

Workflow (工作流) 是一个将复杂过程分解为定义明确、顺序执行的任务流程, 并在其中自动化传递数 据与任务的状态, 用户完成特定目标. 如果说 Agent 是聪明的执行者，那 工作流就是它的行动蓝图------ 它定义了"先做什么、后做什么、在什么条件下跳转或终止"。 其核心在于：预设的、可重复的流程路径.

比如公司的报销流程

• 提交发票 → 领导审批 → 财务审核 → 财务结算 → 归档完成 或者一个自动化客服工单系统

• 用户提交问题 → 系统自动分类 → 分配给对应客服 → 客服处理 → 用户评价 → 工单关闭

这个固定路径, 整个过程沿着预设的流程运行, 就是典型的工作流行为. LangGraph 实现的就是工作流！

3.1.3 工作流和 Agent 区别

从概念上来讲, 工作流的流程固定, 步骤预设, 适合明确流程的任务. Agent 是由大模型 (LLM) 动态控制 流程走向, 灵活度高

类型	英文名	特点	适用场景
工作流	Workflow	流程固定，代码驱动，步骤预设	明确流程的任务，如客服工单处理
智能体	Agent	动态决策，LLM 控制流程走向	开放问题求解，如科研推理

Workflow 像是"炒菜机器人"------按步骤进行炒菜. 比如放油 → 炒蛋 → 加盐 → 出锅, 即使鸡蛋坏了, 也不会停下来.

Agent 像是"米其林主厨"------他会思考："今天食材新鲜吗? 客人忌口吗? 要不要换做法? "

◦ 自主决定菜单

◦ 调整火候和配料

◦ 品尝后返工改进

但无论是 Workflow 还是 Agent ，对于他们做出来的 AI 应用，在 LangChain 中，可以统称为 Agent Server！

3.2 工作流

3.2.1 工作流介绍

工作流具有预先确定的代码路径，并设计为按特定顺序运行。当需要设计更高复杂性的 AI 应用时，工 作流为定义明确的任务提供可预测性和一致性。

例如，现在需要研发一款主打城市通勤的 智能电动自行车 ，具有导航、社交、防盗等功能。在开始研 发前，需要进行多维度分析，如：

• 市场分析：用户关注续航里程、车身重量、防盗能力，并对"骑行社交"（组队、分享路线）有新 兴兴趣。

• 竞品分析：传统品牌车型智能化不足；互联网品牌车型续航和线下售后服务是其短板。

• 技术分析：评估更轻量化的电池材料与车身设计以提升续航和便携性，并开发基于 GPS 和移动网络 的智能防盗系统与社交功能 App 的集成。

• 最终汇总分析结果。 则我们可以将多维度分析设定为具体的流程（工作流），从而达到先分析再汇总的特定运行顺序。如 下图所示：

在 LangGraph 中，工作流基于 LLM ，以及添加到其中的各种增强功能（如工具调用、结构化输出和 短期记忆）而实现：

再次强调：LangGraph 是一个强大且灵活的**"Agent Server 操作系统内核"。** 它不关心我们具体用 什么模型或提示词，而是为我们解决构建复杂、可靠、可交互的 Agent Server 时所面临的状态管理、 流程编排、持久化和人工监督等底层工程难题。

3.2.2 理解图计算

如何实现工作流逻辑？图计算是一种用节点和边来表示复杂系统的方法。在 AI 领域，它特别适合构建 多步骤、有状态的智能工作流。 想象一个快递配送系统，下图展示了包裹从输入（揽收站）到输出（配送站）的过程

• 配送站、揽收站、分拣中心 = 节点（Node）

• 运输路线 = 边（Edge）

• 包裹信息 = 状态（State）

• 完整配送网 = 图（Graph）

3.3 实现工作流的核心概念

3.3.1 State（状态） - 快递的"包裹信息"

State 就像快递包裹上的标签，记录着包裹的当前位置、目的地、配送状态等信息。在整个配送过程 中，所有站点都能查看和更新这个信息。

状态特性：

• 共享性：所有节点（快递站点）都能读取和修改

• 持久性：在整个工作流（快递运输）执行期间持续存在

• 结构化：有明确的字段定义

from typing import TypedDict
class PackageState(TypedDict):
# 包裹基本信息
package_id: str # 包裹id
origin: str # 始发站
destination: str # 目的地
# 配送状态
status: str # "待揽收", "运输中", "派送中", "已签收"
history: list[str] # 流转历史
total_distance: int # 总里程
# 配送详情
priority: str # "普通", "加急"

所有配送站点共享的包裹信息卡就是 LangGraph 中的 State！

3.3.2 Nodes（节点） - 快递站点

节点就像快递配送网络中的各个站点，每个站点负责特定的处理步骤。例如：

揽收站：接收包裹，初始化信息 分拣中心：根据目的地分类包裹

派送站：最终配送至收件人

节点特征：

• 单一职责：每个节点只做一件事

• 输入输出：接收状态，返回状态更新

• 独立性：节点间不直接通信，通过 State 交互 代码示例（节点只不过是函数）：

def receive_package(state: PackageState):
"""揽收站"""
return {
"status": "已揽收",
"history": [f"在{state['origin']}揽收"]
}
def sort_package(state: PackageState):
"""分拣中心：根据目的地分拣"""
destination = state["destination"]
if "北京" in destination:
next_station = "北京分拣中心"
elif "上海" in destination:
next_station = "上海分拣中心"
else:
next_station = "其他地区分拣中心"
return {
"status": "已分拣",
"history": [f"分拣至{next_station}"]
}
def final_delivery(state: PackageState):
"""派送站"""
return {
"status": "已签收",
"history": [f"已送达{state['destination']}"]
}

3.3.3 Edges（边） - 快递运输路线

边定义了包裹在站点之间的流动路径，就像快递公司的运输路线图。对于路线，一般类型有：

• 开始/结束路线：流程的开始和结束点（包裹的开始站，与结束站）

• 固定路线：包裹可以从揽收站→分拣中心（所有包裹都走这条路），而不能从配送站→揽收站，而 是配送站→家。

• 条件路线：根据目的地选择不同的分拣中心

实际上在 LangGraph 中，边就定义了节点之间的连接关系，决定了工作流的执行顺序。边的类型有：

• 固定边：总是从 A 到 B

• 条件边：根据状态决定下一步

• 以及图的开始和结束点，标志了工作流的入口和出口。

因此，LangGraph 通过节点（每个处理步骤）、边（步骤之间的连接）和状态（保存执行过程），就 可以构建出一个任务工作流（图）。