前面 RAG 系列里我们一直在讨论一个问题AI 应用不只是把问题发给大模型然后把答案返回给用户。真正进入业务以后系统往往需要处理文档检索、工具调用、权限判断、多轮对话、失败重试、人工确认和日志追踪。这些能力叠在一起之后AI 应用就不再是一次简单调用而更像一个有状态的流程系统。这也是 LangGraph 出现的背景。很多人第一次听到 LangGraph会觉得它只是一个画流程图的工具。但更准确地说LangGraph 解决的是当 AI 应用开始出现分支、循环、状态更新和工具调用时如何把 Agent Workflow 组织成一个可控、可维护、可恢复的图结构。这篇文章作为 LangGraph 实战系列的第一篇先不急着写复杂代码而是先讲清楚一个基础问题为什么 Agent 需要图结构普通 LLM 调用解决什么问题最简单的大模型应用大致是这样用户输入 ↓ Prompt ↓ LLM ↓ 模型输出这个模式适合很多轻量任务。比如改写一句话 生成一段文案 总结一小段文本 解释一个概念 翻译一段内容它的特点是流程非常直接。输入一次模型回答一次。如果任务足够简单这种方式完全够用。但问题在于真实业务里的 AI 应用经常不是这么简单。比如用户问帮我分析这份合同有没有风险并给出修改建议。系统可能需要读取文件 解析内容 识别合同类型 提取关键条款 检索公司规则 判断风险等级 生成修改建议 必要时让人工确认这已经不是一次模型调用可以清晰表达的任务。它需要流程。Chain 适合线性流程在简单 LLM 调用之上很多人会使用 Chain。Chain 的思路是把多个步骤串起来。例如用户问题 ↓ 问题改写 ↓ 知识检索 ↓ 答案生成 ↓ 格式整理这种结构比单次调用更清晰。每一步负责一件事前一步输出给后一步。对很多固定流程来说Chain 很好用。比如文档摘要 固定格式报告生成 简单 RAG 问答 文本分类后生成回复但 Chain 有一个明显前提流程基本是确定的。也就是说系统大体知道第一步、第二步、第三步分别要做什么。可是 Agent 场景常常不是这样。Agent 为什么更复杂Agent 的核心特点是它不只是执行固定步骤而是会根据任务和中间结果决定下一步。比如一个 Agent 接到任务后可能会判断是否需要检索知识库 是否需要调用工具 工具调用失败要不要重试 检索结果是否足够回答 是否需要再次追问用户 是否需要人工确认 任务是否已经完成这些判断会带来几个结构变化。第一流程会分支。同一个输入不同状态下可能走不同路径。第二流程会循环。Agent 可能需要多次调用工具或者多次检索直到条件满足。第三流程需要保存状态。系统要知道已经做了什么、下一步要做什么、哪些工具调用过、哪些结果已经返回。第四流程需要中断和恢复。有些步骤可能等待人工确认有些步骤可能因为外部系统失败而暂停。这些能力用普通 Chain 很难优雅表达。为什么是图结构图结构可以把复杂流程拆成几个基本元素Node节点负责执行一个任务 Edge边负责连接节点 State状态负责保存流程上下文 Conditional Edge条件边负责根据状态决定下一步你可以把一个 Agent Workflow 理解成当前状态进入某个节点 节点执行任务并更新状态 系统根据状态选择下一条边 流程进入下一个节点 直到到达结束条件这种结构天然适合描述 Agent。比如一个简化的客服 Agent接收用户问题 ↓ 判断是否需要检索 ├─ 不需要直接回答 └─ 需要检索知识库 ↓ 判断结果是否足够 ├─ 足够生成答案 └─ 不足追问用户或转人工这个流程里有分支也有判断。如果后面加入工具调用、重试、人工确认图结构会更自然。LangGraph 解决的不是让模型更聪明这里有一个常见误区很多人以为用了 LangGraphAgent 就会自动变聪明。不是这样。LangGraph 不是让模型能力突然变强的魔法。它解决的是工程组织问题。更具体地说它让你可以更清楚地控制流程有哪些步骤 每个步骤做什么 状态如何传递 什么时候分支 什么时候循环 什么时候结束 失败时如何处理 人工如何介入 日志如何记录模型仍然可能犯错。工具仍然可能失败。检索仍然可能不准。但有了清晰的图结构系统至少更容易被理解、调试和维护。一个简单对比普通 LLM 调用像这样问一句 答一句Chain 像这样步骤 A ↓ 步骤 B ↓ 步骤 CLangGraph 更像这样步骤 A ↓ 判断状态 ├─ 走 B ├─ 走 C └─ 回到 A 或进入 D它不是为了让简单任务更复杂。而是为了让复杂任务不要失控。哪些场景适合 LangGraph不是所有 AI 应用都需要 LangGraph。如果你的任务只是单轮问答 简单摘要 固定格式生成 一次检索后回答普通调用或简单 Chain 可能就够了。LangGraph 更适合这些场景多步骤任务 需要工具调用 需要条件分支 需要循环重试 需要人工确认 需要保存状态 需要可恢复流程 需要多个 Agent 协作比如复杂客服流程 自动化数据分析 带审批的智能助手 Agentic RAG 多工具任务执行 多 Agent 协作系统这些场景的共同点是流程不再是简单直线而是有状态、有判断、有变化。LangGraph 的核心直觉学习 LangGraph 时可以先抓住三个词State Node EdgeState 是系统当前知道的一切。比如用户输入、消息历史、检索结果、工具结果、任务进度、错误信息。Node 是处理状态的任务单元。比如调用模型、检索知识库、执行工具、判断结果、整理输出。Edge 是流程连接关系。它决定执行完一个节点后接下来去哪里。如果再加上 Conditional Edge就可以根据 State 选择不同路径。这就是 LangGraph 的基本思路。复杂 Agent Workflow 并不是一团乱麻而是可以拆成状态 节点 连接 条件 结束为什么这对工程化重要Agent 最大的问题之一是不可控。如果所有逻辑都塞进一个 Prompt系统会很难维护。你很难知道模型为什么调用这个工具 为什么没有继续检索 为什么循环了很多次 为什么最后没有给出答案 为什么某次运行和上次不一样图结构的价值是把这些过程显式化。每个节点做什么更清楚。每次状态怎么变化更清楚。每次分支为什么发生更清楚。当系统出问题时也更容易排查。这和前面 RAG 系列里讲可观测性是同一个思路AI 应用越复杂越不能只看最终输出。你必须看到过程。常见误区第一个误区是把 LangGraph 当成流程图绘制工具。它不是只负责画图而是负责执行有状态图流程。第二个误区是把所有逻辑都拆成很多小节点。节点太碎流程会变得难读。第三个误区是以为用了图结构就一定比 Chain 好。简单任务用简单方式更合适。第四个误区是忽略 State 设计。State 设计不好图结构再清楚也会混乱。第五个误区是没有结束条件。Agent 支持循环但循环必须有边界。总结LangGraph 的核心价值不是让模型突然变聪明而是让复杂 Agent Workflow 变得更可控。当 AI 应用只需要一次调用时普通 LLM 接口就够了。当流程固定时Chain 就很自然。但当系统开始出现状态、分支、循环、工具调用、人工介入和恢复需求时图结构会更适合。LangGraph 用 State、Node、Edge 把这些复杂过程显式组织起来。这也是 Agent 从 Demo 走向工程化的重要一步。下一篇文章可以继续讨论 LangGraph 和 LangChain 的区别。因为很多人会问既然已经有 LangChain为什么还需要 LangGraph