LangChain 和 LangGraph：框架到底帮 Agent 管什么？

今天先记住

LangChain 更像一套把模型、提示词、工具、检索和输出串起来的组件库；LangGraph 更像把 Agent 运行过程画成“有状态的图”。选框架时别先问哪个更火，先问你的系统需要多少状态、分支和可恢复能力。

它在大地图里的位置

继续看 Agent 主线：

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

前面讲了 Workflow 和 Agent 的分界。今天把框架放回这张图里：框架不是替你定义目标，也不是替你判断业务边界；它主要帮你组织模型调用、工具调用、状态流转、分支路由和运行记录。

它到底是什么

LangChain 可以理解成“Agent 应用的常用零件箱”。你要接模型、封装工具、组合 prompt、做 RAG、解析结构化输出，它提供很多现成接口。

LangGraph 则更关注“流程怎么跑”。它把任务拆成节点（node）和边（edge）：某个节点负责读文件，某个节点负责让模型决策，某个节点负责执行工具；边决定下一步去哪里。和普通流程图不同，LangGraph 的重点是状态会随着节点执行持续更新，必要时还能中断、恢复、重试。

一句话区分：LangChain 管零件组合，LangGraph 管有状态编排。

为什么 Agent 里会用到它

Agent 难点不是“调用一次模型”，而是多步任务里每一步都可能改变后续路径。比如生成每日文档：主题选择依赖上一课，正文生成依赖框架，构建结果会决定是否修正文档，Git 状态会决定能不能提交。

如果这些逻辑都散在脚本里，早期能跑，但一旦分支变多，就很难回答三个问题：现在执行到哪一步？状态里有什么？失败后从哪里恢复？

LangGraph 这类图式编排的价值，就在于把这些问题显式化。节点失败不是一句“系统异常”，而是可以定位到“构建节点失败”；状态不是散落在变量里，而是被当成流程输入输出管理。

怎么判断它有没有用

如果你的任务只是“输入一段话，调用一次模型，返回一段文本”，不需要急着上 LangGraph。

如果你的任务需要多个固定步骤，但分支很少，用普通 Workflow 或脚本就够了。

如果任务里有多轮工具调用、失败恢复、人工确认、长期状态或多条分支，LangGraph 这类有状态图会更合适。

如果团队里没人能解释每个节点的输入、输出和失败处理，先别把框架堆上去；框架只会把混乱画成更复杂的图。

一个小例子

txt

Input:
生成并发布 2026-07-16 的 AI Agent Daily lesson。

Graph:
read_context 节点：读取框架和上一课标题
choose_topic 节点：判断今天讲 LangChain / LangGraph
write_lesson 节点：生成 Markdown 并写入文件
build_docs 节点：运行文档构建
fix_or_publish 路由：构建失败就回到修正节点，成功就进入提交节点

Output:
状态从“当天课程不存在”
变成“课程文件存在、构建通过、相关提交已推送”。

这个例子里，图不是为了显得高级，而是为了让每一步都有清楚的输入输出。你看一个真实系统是否靠谱，就看它能不能说清：节点拿到什么状态，产出什么状态，失败时走哪条边。

常见误区

以为用了 LangChain 就自动变成 Agent。组件库只是工具，闭环和状态设计才是 Agent 骨架。
以为 LangGraph 只适合超复杂系统。只要有可恢复状态和条件路由，小图也有价值。
以为图越细越好。节点太碎会让调试成本上升，应该按真实责任边界拆。
以为框架能替代产品边界。哪些动作允许自动执行、哪些必须确认，仍然要自己定。

今天自测

LangChain 和 LangGraph 可以分别用什么一句话解释？
一个 Agent 图里的节点，至少应该说明哪些输入和输出？
如果工具服务器不可达，系统应该继续等待、降级跳过，还是直接失败？判断依据是什么？

LangChain 和 LangGraph：框架到底帮 Agent 管什么？ ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​