在经过一段时间的Agent学习后,用着用着 LangChain会发现它越来越不够用了于是我们把目光投向了 LangGraph。这篇文章就沿着这条真实的学习路线把每一站拆开聊聊。一、起点为什么我们需要 Agent 框架2023 年大家都在用 LangChain 写 Chain把 Prompt、Model、OutputParser 像链条一样串起来。这种写法在一次性问答场景下非常优雅但一旦你想让 LLM自主决定什么时候该查、查什么、查完再做什么链条就显得僵硬了。于是Agent的概念被推到了台前把决定下一步这件事本身也交给模型来完成。教程里第一个视频agent入门案例就演示了一个最小可运行的 Agent —— 用户问今天北京天气怎么样Agent 自带一个get_weather工具自己判断需要调用工具、再把结果回填、最后整理成自然语言答复。跑通这个 Demo 的那一刻你会直观感受到Agent 不是更复杂的 Chain而是把 Chain 升级成了一个会思考的执行者。二、ReAct让 Agent 边想边做紧接着就是react模式。ReAct 全称是Reason Act它给 Agent 提供了一套非常优雅的循环模板Thought我现在该做什么Action调用哪个工具、传什么参数Observation工具返回了什么Thought基于这个结果下一步又是什么……Final Answer可以收尾给出用户答案。这个循环看起来简单但意义重大——它把模型的内心戏显式化、可审计。我们能看到模型在哪一步犹豫、在哪一步抓狂。生产环境里这套循环几乎是所有高质量 Agent 的标配。三、Checkpointer把半截对话从内存救出来Agent 跑起来后很快会遇到一个现实问题会话断了一半怎么办比如用户问了三轮第四轮调用工具超时或者多 Agent 协作时子 Agent 跑了一个小时还没结束。重启之后前面所有的 Thought / Action / Observation 全部丢失等于白干。Checkpointer机制就是为此而生。它把 Agent 的每一步状态——包括消息历史、中间变量、当前节点——序列化落盘一般是数据库或文件。一旦进程崩溃重启时只要从最近的 checkpoint 读回来就能无缝续跑。一句话总结Checkpoint 不是优化是 Agent 工程化的入场券。四、结构化输出让 Agent 走出自然语言泥潭接下来是结构化输出。LLM 最擅长说人话但生产系统最讨厌人话——后端只认 JSON、数据库只认字段、风控系统只认枚举。教程里花了不少篇幅演示 Pydantic with_structured_output的组合把 Agent 的最终回答强制约束到一个 schema 里这一步看似只是格式转换但它直接决定了 Agent 能不能真正嵌入业务系统。没有结构化输出Agent 就只能当玩具。五、中间件横切关注点的优雅解法教程单独拎了两个视频讲中间件可见份量。中间件本质上是 Agent 系统里的AOP——日志、监控、重试、限流、鉴权这些哪都要写、但又不属于核心业务的逻辑被抽到一层独立的处理链里。在 LangChain 的 Chain 里这些往往要靠装饰器 全局变量 各种 Callback才能勉强拼凑而 LangGraph 引入中间件后每个节点都可以挂载若干中间件逻辑清晰得像 Kubernetes 的 Sidecar这套机制给我们带来的最大价值是核心业务代码可以保持纯粹所有运维属性的脏活都被中间件收编。六、转折点LangChain 的三个真问题视频清单里专门有一节叫langchain的缺点和langgraph的引入这一节我个人认为是整个教程的题眼。它直白地列出 LangChain 在工程化阶段暴露出来的三个核心问题1. 控制流不灵活。Chain 抽象本质是 DAG有向无环图一旦你真的需要循环条件分支人机协同这种有状态流LangChain 写起来非常别扭。2. 状态管理薄。没有内置的 State / Checkpoint / Time Travel开发者往往要自己在外部维护一套 Memory逻辑到处都是。3. 可观测性差。Chain 一旦编排复杂调用栈就是黑盒出现为什么这次没走这条分支这种问题只能靠 print。而LangGraph用一套全新思路回应了这些问题用图Graph来描述 Agent而不是用链Chain。七、LangGraph 入门图就是 Agent 的超能力langgrph的入门案例注意原视频标题里的小拼写错误 演示了 LangGraph 的最小骨架看着是不是比写一个 Chain 还简单但别被表面迷惑——StateGraph 的强大之处在于下面这些能力节点可以是任意函数同步、异步、工具调用、子 Agent边可以是条件边add_conditional_edges实现真正的 if/else 控制流原生 Checkpointer 支持time-travel 一行配置就能开每个节点都可以挂中间件横切关注点不再污染业务代码可视化导出的图结构可以直接丢进 Mermaid / 各种可视化工具到这里你会发现LangGraph 不是要取代 LangChain而是要把 Agent 这件事做到工程级。八、写在最后如果你刚刚接触 Agent 开发建议就按这条顺序刷入门 → ReAct → 结构化输出 → 中间件 → Checkpointer → LangChain 缺点反思 → LangGraph 入门。这条路线已经在实战中被证明是最不容易走弯路的。工具永远在变但让 Agent 真正能干活这件事的标准没变。希望这条路径对你也有用。相关参考LangChain 官方文档https://python.langchain.comLangGraph 官方文档https://langchain-ai.github.io/langgraph/ReAct 原始论文ReAct: Synergizing Reasoning and Acting in Language Models如果你也在写 Agent欢迎在评论区交流你的踩坑路线 day16-从 LangChain 到 LangGraph
在经过一段时间的Agent学习后,用着用着 LangChain会发现它越来越不够用了于是我们把目光投向了 LangGraph。这篇文章就沿着这条真实的学习路线把每一站拆开聊聊。一、起点为什么我们需要 Agent 框架2023 年大家都在用 LangChain 写 Chain把 Prompt、Model、OutputParser 像链条一样串起来。这种写法在一次性问答场景下非常优雅但一旦你想让 LLM自主决定什么时候该查、查什么、查完再做什么链条就显得僵硬了。于是Agent的概念被推到了台前把决定下一步这件事本身也交给模型来完成。教程里第一个视频agent入门案例就演示了一个最小可运行的 Agent —— 用户问今天北京天气怎么样Agent 自带一个get_weather工具自己判断需要调用工具、再把结果回填、最后整理成自然语言答复。跑通这个 Demo 的那一刻你会直观感受到Agent 不是更复杂的 Chain而是把 Chain 升级成了一个会思考的执行者。二、ReAct让 Agent 边想边做紧接着就是react模式。ReAct 全称是Reason Act它给 Agent 提供了一套非常优雅的循环模板Thought我现在该做什么Action调用哪个工具、传什么参数Observation工具返回了什么Thought基于这个结果下一步又是什么……Final Answer可以收尾给出用户答案。这个循环看起来简单但意义重大——它把模型的内心戏显式化、可审计。我们能看到模型在哪一步犹豫、在哪一步抓狂。生产环境里这套循环几乎是所有高质量 Agent 的标配。三、Checkpointer把半截对话从内存救出来Agent 跑起来后很快会遇到一个现实问题会话断了一半怎么办比如用户问了三轮第四轮调用工具超时或者多 Agent 协作时子 Agent 跑了一个小时还没结束。重启之后前面所有的 Thought / Action / Observation 全部丢失等于白干。Checkpointer机制就是为此而生。它把 Agent 的每一步状态——包括消息历史、中间变量、当前节点——序列化落盘一般是数据库或文件。一旦进程崩溃重启时只要从最近的 checkpoint 读回来就能无缝续跑。一句话总结Checkpoint 不是优化是 Agent 工程化的入场券。四、结构化输出让 Agent 走出自然语言泥潭接下来是结构化输出。LLM 最擅长说人话但生产系统最讨厌人话——后端只认 JSON、数据库只认字段、风控系统只认枚举。教程里花了不少篇幅演示 Pydantic with_structured_output的组合把 Agent 的最终回答强制约束到一个 schema 里这一步看似只是格式转换但它直接决定了 Agent 能不能真正嵌入业务系统。没有结构化输出Agent 就只能当玩具。五、中间件横切关注点的优雅解法教程单独拎了两个视频讲中间件可见份量。中间件本质上是 Agent 系统里的AOP——日志、监控、重试、限流、鉴权这些哪都要写、但又不属于核心业务的逻辑被抽到一层独立的处理链里。在 LangChain 的 Chain 里这些往往要靠装饰器 全局变量 各种 Callback才能勉强拼凑而 LangGraph 引入中间件后每个节点都可以挂载若干中间件逻辑清晰得像 Kubernetes 的 Sidecar这套机制给我们带来的最大价值是核心业务代码可以保持纯粹所有运维属性的脏活都被中间件收编。六、转折点LangChain 的三个真问题视频清单里专门有一节叫langchain的缺点和langgraph的引入这一节我个人认为是整个教程的题眼。它直白地列出 LangChain 在工程化阶段暴露出来的三个核心问题1. 控制流不灵活。Chain 抽象本质是 DAG有向无环图一旦你真的需要循环条件分支人机协同这种有状态流LangChain 写起来非常别扭。2. 状态管理薄。没有内置的 State / Checkpoint / Time Travel开发者往往要自己在外部维护一套 Memory逻辑到处都是。3. 可观测性差。Chain 一旦编排复杂调用栈就是黑盒出现为什么这次没走这条分支这种问题只能靠 print。而LangGraph用一套全新思路回应了这些问题用图Graph来描述 Agent而不是用链Chain。七、LangGraph 入门图就是 Agent 的超能力langgrph的入门案例注意原视频标题里的小拼写错误 演示了 LangGraph 的最小骨架看着是不是比写一个 Chain 还简单但别被表面迷惑——StateGraph 的强大之处在于下面这些能力节点可以是任意函数同步、异步、工具调用、子 Agent边可以是条件边add_conditional_edges实现真正的 if/else 控制流原生 Checkpointer 支持time-travel 一行配置就能开每个节点都可以挂中间件横切关注点不再污染业务代码可视化导出的图结构可以直接丢进 Mermaid / 各种可视化工具到这里你会发现LangGraph 不是要取代 LangChain而是要把 Agent 这件事做到工程级。八、写在最后如果你刚刚接触 Agent 开发建议就按这条顺序刷入门 → ReAct → 结构化输出 → 中间件 → Checkpointer → LangChain 缺点反思 → LangGraph 入门。这条路线已经在实战中被证明是最不容易走弯路的。工具永远在变但让 Agent 真正能干活这件事的标准没变。希望这条路径对你也有用。相关参考LangChain 官方文档https://python.langchain.comLangGraph 官方文档https://langchain-ai.github.io/langgraph/ReAct 原始论文ReAct: Synergizing Reasoning and Acting in Language Models如果你也在写 Agent欢迎在评论区交流你的踩坑路线