LangChain学习背景

1.1. LangChain是什么

LangChain是LLM应用复杂之后的一套工程化框架

当LLM逐渐开始应用的发现：LLM应用不是一次API调用，而是一条由模型、prompt、工具、数据、记忆、流程控制、观测评估组成的链路

LangChain所做的事情就是在LLM原始能力和真实应用工程之间，把LLM应用开发中反复出现的的工程步骤，抽象成可复用、可组合、可观测的组件

1.2. LangChain为什么会出现

LangChain 出现之前，开发者当然也能做 LLM 应用。最简单的方式就是直接调用模型 API，把用户输入发给模型，再把模型输出展示出来。

但当应用从简单问答走向真实业务后，问题变复杂了。一个知识库问答机器人不仅要调用模型，还要读取文档、切分文档、做向量检索、把相关内容塞进 prompt、控制模型基于资料回答、解析输出、记录日志、评估效果。一个 AI 助手不仅要聊天，还可能要查数据库、调用 API、使用工具、保存上下文、处理中断和恢复。

这些能力在 LangChain 之前大多靠开发者自己写胶水代码。每个项目都重复写 prompt 模板、工具调用协议、RAG 流程、输出解析、上下文管理和调试日志。LangChain 的价值，就是把这些反复出现的模式抽象成组件，让开发者能更系统地组合它们。

后来随着 agent 和复杂工作流变多，线性的 Chain 不够用了，于是 LangGraph 负责状态、分支、循环、持久化和人类介入。应用要上线后，又需要观察每一步发生了什么、评估改动有没有变好，于是 LangSmith 负责 tracing、debug 和 evaluation。

所以 LangChain 的背景不是"模型 API 太难调"，而是"LLM 应用工程化太容易重复造轮子"。

1.3. 从LLM应用的演进过程看LangChain

1.3.1. 起点：LLM单次调用很简单

最早的使用方式是：用户输入 -> 调用模型 -> 模型返回结果

这个阶段不需要LangChain，直接用模型 SDK 就够

1.3.2. 变化：LLM开始进入真实应用

当LLM进入真实应用，需要的不只是回答，而是要接入 文档、数据库、工具、API、历史对话、业务流程、调试评估

于是LLM从"聊天模型"变成了应用里的"推理组件"

1.3.3. 问题：开发者反复写胶水代码

在LangChain之前，很多能力都要自己写

复制代码

Prompt模版
模型调用封装
RAG流程
工具调用协议
输出解析
记忆管理
日志调试
效果评估

这些代码重复、脆弱、难以维护

1.3.4. 回应：LangChain把重复模式组件化

LangChain的核心价值是：把 prompt、model、retriever、tool、parsere、memory、agent等能力抽象成可复用、可组合的组件

它解决的不是"模型不会回答"，而是"LLM应用工程链路太复杂"

1.3.5. 演化：LangChain生态继续分工

伴随着复杂度提高，生态进一步拆分

LangChain: 常用组件、集成、基础agent抽象

LangGraph: 复杂流程、状态、循环、分支、恢复

LangSmith: 追踪、调试、评估、监控

复制代码

LLM 能力增强
  ↓
开发者不再满足于单次问答
  ↓
开始把 LLM 接入文档、工具、数据库、业务流程
  ↓
每个项目都重复写 prompt、检索、工具调用、解析、记忆、日志等胶水代码
  ↓
LangChain 出现：把这些重复工程模式组件化
  ↓
复杂 agent 继续发展
  ↓
LangGraph 处理状态与流程编排
  ↓
生产化需求增强
  ↓
LangSmith 处理观测、调试、评估

1.4. 从旧方案看LangChain的对比

LangChain的每一个抽象，几乎都来自一个真实项目里会反复出现的麻烦

真实需求	LangChain之前	LangChain
调用不同模型	分别写不同SDK调用代码	Chat Model/Model Intergration
管理提示词	手动写字符串模版	Prompt Template
控制输出格式	让模型"请输出JSON"，再手动解析	Output Parser/ Structured Output
接入私有文档	自己写读取、切块、向量化、检索	Loader / Splitter / Embedding / Vector Store / Retriever
做知识库问答	自己拼 RAG 全流程	Retrieval Chain / RAG patterns
调用外部API	自定义工具协议和解析逻辑	Tool / Tool Calling
让模型自主决策	手写循环和条件判断	Agent / LangGraph
管理多轮状态	手动保存历史消息	Memory / State / Checkpoint
调试链路	打印 prompt、结果和日志	Tracing / LangSmith
评估效果	人工看答案或写临时脚本	Evaluation / LangSmith

1.5. 判断是否需要使用LangChain

LangChain 不是越早用越好，而是在复杂度到达某个点后才明显有收益

复制代码

简单调用：直接 SDK
标准 RAG / 工具 / agent 原型：LangChain 很有帮助
复杂长流程 / 状态机 / 可恢复 agent：考虑 LangGraph
生产调试和评估：考虑 LangSmith
关键业务链路：理解框架后再决定保留多少抽象

举例1: 用户输入一段产品介绍，系统帮他改写成小红书风格文案

逻辑抽象

rust 复制代码

用户输入 -> Prompt -> Model -> 输出

结论：一次性API调用，链路短，SDK就够了

举例2: 用户问公司报销制度，系统要基于公司内部文档回答，并注明依据。如果资料不足，要提示联系 HR。

逻辑抽象

复制代码

用户问题
  ↓
加载公司制度文档
  ↓
文档切块
  ↓
向量化
  ↓
检索相关片段
  ↓
组织 prompt
  ↓
模型基于资料回答
  ↓
返回答案和依据

结论：LangChain，标准LangChain链路

举例3: 用户说：帮我查一下这个客户的最近订单，如果超过 30 天没购买，生成一封召回邮件草稿。

逻辑抽象

复制代码

用户目标
  ↓
模型理解任务
  ↓
调用客户查询工具
  ↓
调用订单查询工具
  ↓
判断是否超过 30 天
  ↓
生成邮件草稿

结论：LangChain，需要使用到 Agent/Tool

1.6. LangChain常见背景问题自测

为什么说 LangChain 不是为了解决"调用模型"这个问题？
在 LangChain 之前，开发者做 RAG 通常要自己写哪些步骤？
为什么工具调用会让 LLM 应用变复杂？
Chain 思维为什么在复杂 agent 场景里不够用？
LangChain、LangGraph、LangSmith 分别是为了解决哪类问题？
什么场景下不需要 LangChain，直接调用模型 SDK 更合适？
为什么说 LLM 应用的难点在"工程链路"，而不是单次生成？
为什么有人说 LangChain 过度封装？
RAG 为什么会成为 LangChain 的典型应用场景？
为什么直接调用模型 API 不等于构建 LLM 应用？
LangChain 为什么不是为了让模型更聪明？
为什么 LLM 应用会产生大量胶水代码？
没有 LangChain 时，多轮对话和状态管理为什么容易失控？

1.7. 总结

这一章分别介绍了 LangChain什么出现，解决了什么问题，LangChain出现之前是怎么做的，它的边界在哪里，以及生态演化史什么样的。

LLM应用从单次调用走向复杂工程链路的时候，出现了LangChain

LangChain解决了LLM工程中重复的 prompt、RAG、tool、memory、parser、trace胶水代码

在LangChain出现之前，开发者需要自己封装、自己拼接、自己解析、自己调试

在面对简单的LLM调用任务的时候，可以直接使用SDK，复杂流程才能体现LangChain的价值

LangChain的生态演化路径如下：LangChain → LangGraph → LangSmith