上一篇文章里我们讨论了 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 应用已经出现这些信号就可以考虑 Graphif 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 怎么设计。