从 Chain 到 Graph：为什么线性流程不够用了
上一篇文章里，我们讨论了 LangGraph 和 LangChain 的区别。
一个重要结论是：
LangChain 更偏组件组合，LangGraph 更偏有状态流程编排。
但这个结论背后还有一个更基础的问题：
为什么线性 Chain 不够用了？
如果一个 AI 应用可以按照固定步骤执行，Chain 已经很清楚。
可是当应用开始变成 Agent Workflow，流程往往不再是一条直线，而是会出现分支、循环、重试、中断和恢复。
这篇文章就讨论：
从 Chain 到 Graph，本质上是在解决什么工程问题？
Chain 的优势很明显
Chain 并不是落后的东西。
在很多场景里，线性流程非常好。
比如：
输入文章 ↓ 生成摘要 ↓ 改写标题 ↓ 输出结果或者一个简单 RAG：
用户问题 ↓ 检索文档 ↓ 拼接上下文 ↓ 模型生成答案这种流程的特点是：
步骤固定 方向明确 输入输出清楚 没有复杂分支 没有循环判断Chain 的价值在于简洁。
每一步都知道下一步是什么。
调试起来也比较容易。
如果任务本身就是线性的，就应该优先用简单方式。
问题出在真实流程不是总是线性的
真实 Agent 任务经常会出现这样的情况：
用户输入一个问题后，系统不能马上确定该怎么处理。
比如：
用户问的问题是否需要检索？ 检索结果是否足够？ 是否需要调用工具？ 工具调用是否成功？ 结果是否需要人工确认？ 用户是否还需要补充信息？这些判断会让流程变成多条路径。
举个例子：
用户问题 ↓ 判断问题类型 ├─ 普通问题：直接回答 ├─ 知识问题：走 RAG ├─ 数据问题：调用数据库工具 └─ 高风险问题：转人工确认这已经不是一条线。
如果继续用 Chain 表达，就会出现大量 if else 嵌套。
流程会越来越难读。
分支是 Chain 变复杂的第一步
一旦出现分支，线性流程就开始变得不自然。
比如客服 Agent：
用户输入 ↓ 判断意图 ├─ 查询订单 ├─ 修改地址 ├─ 售后退款 └─ 普通咨询每个分支后面可能又有自己的流程。
查询订单需要调用订单系统。
修改地址需要检查订单状态。
售后退款需要判断是否满足规则。
普通咨询可能需要检索知识库。
如果用一条 Chain 表达，流程会变成：
先判断 再写很多条件 每个条件里再写更多步骤代码能跑，但结构不清楚。
Graph 的方式是把每个分支变成明确节点和边。
这样流程本身就是结构化的。
循环是更大的挑战
Agent 里经常会有循环。
比如：
检索资料 ↓ 判断资料是否足够 ├─ 不足：改写问题后继续检索 └─ 足够：生成答案或者：
调用工具 ↓ 判断工具结果是否可用 ├─ 失败：重试或换工具 └─ 成功：进入下一步循环不是坏事。
很多 Agent 能力都依赖循环。
但循环必须有边界。
比如：
最多检索 3 次 最多调用工具 5 次 超时后走兜底 连续失败后转人工如果用普通 Chain 表达循环，代码会很容易散落在各处。
Graph 可以把循环关系显式画出来。
更重要的是，循环条件可以基于 State 判断。
State 是从 Chain 到 Graph 的关键
线性 Chain 里，状态通常只是前一步输出传给后一步。
但 Agent Workflow 里，状态更复杂。
它可能包括：
用户原始问题 历史消息 当前任务类型 检索结果 工具调用结果 失败次数 当前步骤 是否需要人工确认 最终答案每个节点都可能读取或更新 State。
流程下一步也要根据 State 判断。
比如：
如果 retrieval_results 为空，进入 query_rewrite 节点。 如果 tool_error_count 大于 3，进入 fallback 节点。 如果 risk_level 为 high，进入 human_review 节点。这就是 Graph 更适合的原因。
它不是只连接函数。
它是围绕状态变化组织流程。
Graph 让流程显式化
很多 Agent Demo 的问题是：
看起来很智能，但过程很黑盒。
你只看到最终结果，却不知道中间发生了什么。
Graph 的价值之一，就是把过程显式化。
比如一个分析 Agent 可以拆成：
receive_input ↓ classify_task ↓ retrieve_context ↓ analyze ↓ validate ↓ generate_answer如果分析结果不通过校验，可以回到检索节点。
如果问题不清楚，可以进入 ask_user 节点。
如果风险过高，可以进入 human_review 节点。
这些路径都可以清楚表达。
当系统出问题时，你也能知道问题发生在哪个节点。
什么时候 Chain 仍然够用？
不要因为学习 LangGraph，就否定 Chain。
如果任务符合下面特点，Chain 仍然很好：
步骤固定 分支很少 没有循环 状态简单 不需要暂停恢复 不需要复杂工具协作比如：
文本摘要 标题生成 格式转换 简单分类 简单 RAG 固定报告生成这些任务用 Graph 也能做。
但不一定值得。
工程上不是越复杂越好。
应该让工具复杂度匹配问题复杂度。
什么时候应该考虑 Graph？
如果你的 AI 应用已经出现这些信号，就可以考虑 Graph：
if else 越来越多 流程路径越来越难描述 需要根据中间结果决定下一步 工具调用失败要重试 流程可能回到前面步骤 需要等待人工输入 需要保存执行进度 需要记录每一步状态这些都说明应用已经不只是一个 Chain。
它更像一个状态机。
而 LangGraph 正是用图结构来表达这种状态机式的 Agent Workflow。
一个常见演进过程
很多项目不是一开始就需要 LangGraph。
它往往是这样演进的：
第一阶段：
单次 LLM 调用第二阶段：
Prompt + Retriever + LLM第三阶段：
加入问题改写、Rerank、格式化输出第四阶段：
加入工具调用、失败重试、人工确认第五阶段：
流程变成有状态 Agent Workflow到第五阶段时，Graph 的价值就会变得明显。
它能让系统不至于变成一堆难以维护的流程代码。
Graph 不是视觉化，而是结构化
很多人听到图结构，会先想到可视化流程图。
但 LangGraph 的关键不是画得好不好看。
而是流程被结构化了。
也就是说：
有哪些节点 节点之间怎么连接 状态怎么变化 条件怎么判断 哪里可以循环 哪里必须结束这些信息在代码结构里是明确的。
这对团队协作非常重要。
一个复杂 Agent 项目，如果所有流程都藏在 Prompt 或零散 if else 里，新人很难接手。
如果流程以图结构组织，理解成本会低很多。
常见误区
第一个误区，是觉得 Chain 已经过时。
Chain 没过时，它适合线性任务。
第二个误区，是觉得 Graph 一定更高级。
Graph 更适合复杂流程，但简单任务用它反而可能更重。
第三个误区，是把循环交给模型自由决定。
循环必须有最大次数、超时和兜底。
第四个误区，是忽略状态设计。
Graph 的复杂度往往不是节点，而是 State。
第五个误区，是只关注正常路径。
真实系统还要设计失败路径、异常路径和人工介入路径。
总结
从 Chain 到 Graph，本质上不是工具升级，而是应用复杂度升级。
Chain 适合固定线性流程。
Graph 适合有状态、有分支、有循环、有恢复需求的 Agent Workflow。
当 AI 应用开始需要根据中间结果决定下一步时，线性流程就会变得吃力。
LangGraph 的价值，是把这些复杂路径显式组织起来，让 Agent 流程更可控、更可维护、更容易排查问题。
下一篇文章，可以继续深入 LangGraph 里最重要的概念：
State。
因为很多人一开始关注节点怎么写，但真正决定图能否长期维护的，往往是 State 怎么设计。