本文来自《AI 应用开发课程》月份 1 课程文档，已整理为网站文章版本。
学习目标
学完本节后，你应当能够：
- 理解 LangChain 和 LangGraph 的关注点差异。
- 明白为什么月份 1 只学 LangChain 核心抽象。
- 避免把框架当成黑盒魔法。
前置知识
- 已完成普通 API 调用、Tool Calling 和 FastAPI 基础
1. 两者分别解决什么问题
LangChain
更关注组件抽象与链路组合，例如：
- Prompt 模板
- 模型调用封装
- 输出解析
- Tool 抽象
- Runnable 组合
LangGraph
更关注有状态工作流编排，例如：
- 多节点流程
- 分支和回路
- 中断与恢复
- 审批与人机协作
2. 为什么月份 1 不直接上 LangGraph
因为你当前还在补：
- Python 工程化
- LLM API 基础
- 工具调用闭环
- FastAPI 服务化
如果此时直接跳进 LangGraph，很容易变成：
- 只会套教程
- 不清楚底层消息怎么流动
- 不清楚工具调用是模型做了什么、程序做了什么
3. 月份 1 学 LangChain 的真正目标
不是“会用更多框架代码”，而是理解这些抽象：
PromptTemplateRunnable- LCEL
OutputParserTool
你要能回答：
- 它帮我省了什么？
- 它抽象掉了什么？
- 它隐藏了什么？
4. 一个工程视角类比
- 纯 API 调用像你手写所有 HTTP 与数据流
- LangChain 像一组可组合积木
- LangGraph 像把这些积木放进状态机或工作流图里
如果积木都没看明白，直接看工作流图通常只会更糊。
5. 实操任务
- 回顾你自己写过的普通 API 调用链
- 标出其中可抽象的部分：prompt、model、parser、tool
- 再进入后面 3 节 LangChain 课程
6. 自测题
- LangChain 和 LangGraph 分别偏向哪一层？
- 为什么月份 1 强调先掌握组件，再掌握编排？
- 为什么框架不能代替你理解底层数据流？
7. 验收标准
- 你能不用框架术语，用自己的话解释两者差异
- 你能说明为什么你的项目当前更需要 LangChain 而不是 LangGraph
8. 本章与前文关系
这一章放在 FastAPI 之后，不是偶然安排。
因为如果你在没搞清楚：
- 模型调用链路
- Tool Calling 边界
- 服务层分层
之前就学 LangChain，往往会发生一件事：
- 你只记住了框架名字
- 却不知道它到底抽象了什么
所以本章的任务是把前面的纯手写实现，和 LangChain / LangGraph 的抽象层级对齐。
9. 本章在研发助手项目中的位置
研发助手项目在月份 1 阶段，不需要 LangGraph 这种更偏工作流图和状态编排的层。它当前更需要的是：
- 更清晰的 Prompt 组织
- 更清晰的模型与解析器组合
- 更清晰的 Tool 抽象映射
这些恰好就是 LangChain 更适合解决的问题。
10. 一个更工程化的映射表
| 你已经手写过的东西 | LangChain 中的近似对应 |
|---|---|
| 手写 Prompt 字符串 | PromptTemplate |
LLMClient.generate() | Chat Model 封装 |
| 手写解析逻辑 | OutputParser |
| 手写执行链 | Runnable / LCEL |
| 工具定义与适配 | Tool |
| 多步骤工作流 | 更接近 LangGraph |
这个映射表是月份 1 理解框架的关键。只要你能把手写实现和框架组件对应起来，框架就不会神秘。
11. 为什么此时不直接跳去 LangGraph
因为 LangGraph 更像在回答：
- 这个系统有几个状态节点
- 每个节点之间怎么流转
- 哪些节点可中断、可恢复
而月份 1 当前真正要打稳的是：
- 一个节点里发生了什么
- Prompt、Model、Parser、Tool 如何在一条链中协作
如果组件层还没学明白，直接看状态图通常只会更混乱。
12. 错误示例 vs 正确示例
错误示例：把框架理解成“少写代码的捷径”
这会导致你一旦离开框架就不会解释问题。
正确示例：把框架理解成“对你已经理解的链路做统一抽象”
这会让你在使用 LangChain 时更有判断力：
- 什么该交给框架
- 什么该保留为你自己的业务边界
13. 本章完成后你应该具备的能力
完成本章后，你应当做到：
- 能说清 LangChain 偏组件，LangGraph 偏工作流。
- 能把自己之前写过的纯 API 逻辑映射到 LangChain 概念。
- 能解释为什么月份 1 先学 LangChain 更合理。
14. 从本章过渡到下一章的桥接说明
接下来进入 02-PromptTemplate-Runnable-LCEL.md。
这会把前面“抽象层级的认识”真正落成代码：你将看到 Prompt、模型和解析器如何通过 LCEL 组合成一条清晰链路，并和手写实现做一一对照。
15. 一种非常容易踩的学习顺序错误
不少人学习框架时喜欢直接跳到最炫的部分，例如：
- 多工具 Agent
- 工作流图
- 复杂记忆
- 多节点状态编排
这在演示层面看起来很吸引人，但对月份 1 来说几乎一定会带来副作用：
- 你会依赖框架现成模式
- 你会忽略输入输出结构本身
- 你会把“会搭流程”误判成“懂系统设计”
所以本章想帮你建立一个更稳的判断标准：
先看组件是否理解，再看编排是否必要。
16. 为什么 LangChain 更适合月份 1 的“抽象训练”
月份 1 当前最需要的是把一条链看清楚。以“需求总结 -> 模型生成 -> 结果解析”为例，你真正需要训练的是：
- Prompt 是如何组织的
- 模型是如何接收输入的
- 结果是如何被程序消费的
LangChain 擅长把这些组件拆得足够清晰：
- Prompt
- Model
- Parser
- Tool
而 LangGraph 更适合在你已经知道这些组件内部是什么之后，再去管理“组件之间如何形成状态图”。
17. 如果你现在硬上 LangGraph，会缺什么
你很可能缺的是下面这些能力：
- 看见一条节点边时，不知道节点内部到底做了什么
- 看见工具节点时，不知道工具调用闭环细节
- 看见消息状态时，不知道历史消息怎么组织
- 看见输出节点时，不知道结果解析怎么落地
所以不是 LangGraph 太难，而是月份 1 当前的地基还应该先铺在 LangChain 这层。
18. 一个工程判断题
如果你面对一个月份 1 场景，应该先问自己：
问题一：我需要的是“组件清晰”，还是“流程复杂”
如果主要问题是“Prompt、Model、Parser 这条链要更清晰”，优先 LangChain。
问题二：我当前有多状态节点、多分支、多次中断吗
如果没有，不要为了“技术先进感”强行引入 LangGraph。
问题三：离开框架后，我还能解释这条链吗
如果不能，说明你当前更需要回到基础抽象层。