LangChain Learning Path

LangGraph vs 普通链式调用 ​

先给结论 ​

只要你的流程还是单向、固定、几步就能讲清楚，继续用普通链式调用。
当流程开始出现分支、循环、状态累积、失败重试或人工介入时，再考虑 LangGraph。

LangGraph 不是“更高级的链”，而是处理复杂流程组织问题的工具。

一句话区分 ​

  • 普通链式调用适合线性任务
  • LangGraph 适合有状态、可分支、可恢复的工作流

快速对比 ​

维度普通链式调用LangGraph
流程结构线性图结构
状态表达隐含在调用过程里显式状态对象
分支与重试可以做，但会逐渐变乱天然更适合表达
调试视角看单条链路看节点、状态和转移
适合阶段早期原型、固定任务多路径、长流程、需要恢复的系统

什么时候继续坚持普通链 ​

  • 用户请求类型比较单一
  • 整个过程可以稳定描述成 3 到 5 步
  • 失败处理很简单，不需要复杂回退

比如:

  • 主题输入后生成学习摘要
  • 问题输入后检索资料再回答
  • 把固定的结构化结果渲染成页面模块

这些任务即使很重要，也不代表必须引入图结构。

什么信号说明该升级到 LangGraph ​

  • 你开始写很多 if/else 决定下一步
  • 某一步失败后，需要根据情况重试或走兜底逻辑
  • 流程依赖多个中间结果，而且后面步骤要读这些状态
  • 你需要看见系统究竟走了哪条路径

如果这些信号已经出现，继续硬撑在线性链里，维护成本通常只会越来越高。

结合 AI 学习助手主线来看 ​

适合普通链的阶段 ​

  • V1 学习计划生成
  • 基础 RAG 问答
  • 固定格式的结构化输出

更适合 LangGraph 的阶段 ​

  • 先判断问题类型，再决定走目录查询、RAG 还是工具调用
  • 检索失败后进入兜底或澄清路径
  • 需要记录节点执行历史，便于调试和观测

这正是第 8 章引入 LangGraph 的原因: 不是为了换一种写法，而是因为系统复杂度已经超过普通链最舒服的区间。

常见误判 ​

误判 1：流程一复杂就必须上 LangGraph ​

不一定。
如果复杂度还可以通过少量稳定链和外层普通代码管理，就不必过早引入图。

误判 2：LangGraph 会让结果更聪明 ​

不会直接让模型更聪明。
它改善的是流程可控性、状态可见性和复杂逻辑组织方式。

误判 3：普通链没法做条件判断 ​

当然可以做，只是当判断越来越多时，可读性和可维护性会明显下降。

一个实用决策法 ​

如果你现在还能把系统画成一条箭头:

输入 -> 处理 -> 输出

那就继续用链。
如果你已经不得不画成:

输入 -> 分类 -> 路由 -> 执行 -> 失败重试/澄清 -> 汇总

那就是 LangGraph 更合适的信号。

对应回看章节 ​