很多人第一次接触 LangChain，是从一句 openai.ChatCompletion.create() 开始的。几十行代码，传一段 prompt，拿回一段回答，跑通了，于是觉得「LLM 应用也就这样，哪需要什么框架」。
这个判断会在你做出第一个真正能用的功能时被打破。当你想让模型调用工具、记住上文、先检索再回答、失败自动重试、排查为什么这次答错了——你会发现，每多一个要求，裸调 API 的代码就膨胀一截，而且这些代码和你真正要解决的业务问题毫无关系。
理解 LangChain，要先跳出「它是个封装 OpenAI 的库」这个认知。它真正要做的事，和在 Spring 里写 Controller、在 Express 里写路由、在 RabbitMQ 里做异步解耦是同一类——把重复的工程问题固化成稳定的抽象，让你专注业务。只是这次，被处理的对象从「HTTP 请求」换成了「LLM 调用」。
这一篇是整个「图解 LangChain」系列的起点。我先把「裸调 API 为什么不够」拆开，再立起框架的三根价值轴。这是后面 41 篇的地基坐标。
先看清裸调 API 长什么样
为了不空谈，先看一段最小可用的裸调代码（以 OpenAI 风格接口为例）：
from openai import OpenAI
client = OpenAI()
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "用一句话解释什么是消息队列"}],
)
print(resp.choices[0].message.content)
它能跑，而且很干净。问题不在「能不能跑」，而在这段代码假设了一个理想世界：模型永远在线、一次就答对、不需要上下文、结果直接给用户、出错也不用管。
真实的 LLM 应用几乎不存在这种理想场景。下面是一个「客服问答」功能会很快长出的需求，我把它们和裸调代码的缺口对应起来：
| 真实需求 | 裸调 API 要你自己造什么 |
|---|---|
| 模型答错时要重试 / 换个模型兜底 | 重试循环、超时、fallback 链 |
| 让模型查知识库再回答（RAG） | 文档加载、切分、向量检索、拼接 prompt |
| 让模型调工具（查订单、发通知） | 工具定义、解析模型要调哪个工具、执行、回灌 |
| 记住前面聊过什么 | 历史消息的存储、裁剪、注入 |
| 排查「这次为什么答成这样」 | 调用链埋点、输入输出留痕 |
| 换一家模型厂商 | 改调用方式、改消息格式、改 tool 格式 |
这张表的右列，每一项都是和你的业务无关、但每个 LLM 应用都要写一遍的工程代码。它们会以 if/else、辅助函数、全局变量的形式散落在你的项目里，最后谁也说不清整个调用链长什么样。
这就是框架要解决的问题——不是帮你调接口，而是把这些重复的工程问题收进稳定的抽象里。
三根价值轴：框架到底提供了什么
如果非要像讲消息队列那样，给 LLM 应用框架也立几根「价值轴」，我会立这三根：组件复用、流程编排、可观测治理。它们覆盖了几乎所有「裸调做不好、框架做得稳」的痛点。
轴一：组件复用——把异构的东西统一成一种积木
LLM 应用里有大量异构组件：prompt 模板、不同厂商的模型、输出解析器、向量库、检索器、工具……它们各自的接口、参数、行为都不一样。
LangChain 的做法是给它们定义一个统一协议——Runnable。一个组件只要实现 invoke（输入→输出）等几个标准方法，就算「合格积木」。这样带来的直接收益是：你可以用同一种方式组合任何组件，换模型不用改链路，换向量库不用改业务代码。
这根轴解决的是「异构组件的标准化」，类比到后端，就像所有存储都实现一个 Repository 接口、所有消息源都实现一个 Source 接口。
轴二：流程编排——把直线调用变成可控的流程
裸调 API 是一条直线：prompt → model → 返回。但真实的 LLM 应用是有流程的：要先检索、要判断要不要调工具、调完工具要回到模型、要循环到给出最终答案、中途还要能暂停等人审批。
把这些流程手写出来，很快就会陷入 if/else 地狱。LangChain 用两种粒度处理编排：简单的链用 LCEL（管道符 | 串联）；复杂的、有循环有状态的流程用 LangGraph（状态机/图）。后者是 v1.0 之后整个框架的引擎，也是这个系列后半段的重心。
这根轴解决的是「流程的可控与可演进」——让「LLM 怎么一步步完成任务」从散落的代码变成一张看得见、改得动、跑得稳的图。
轴三：可观测治理——让黑盒调用变得可调试、可评估
LLM 调用天然是黑盒：同样的输入可能给出不同的输出，模型为什么这么答，你光看代码是看不出来的。这意味着 LLM 应用比传统应用更需要可观测性——每一次调用、每一次工具执行、每一步中间状态，都得留痕、可回看、可对比。
LangChain 把这一层交给 LangSmith：它记录每一次 run 的分层调用链（trace），支持用数据集做评估，甚至能回放某一次 run来调试（replay）。对 agent 这种「有状态、长链路、不确定」的程序，这套东西不是锦上添花，是生产必需。
这根轴解决的是「黑盒行为的可治理」——没有它，你的 LLM 应用永远停在「能 demo」，到不了「敢上线」。
三根轴，一个共同的结构
把三根轴放在一起看，会发现它们对应的是 LLM 应用工程化的三个递进层次：
- 组件复用解决「单点怎么标准化」——先把积木做规整；
- 流程编排解决「积木怎么连成系统」——再把积木搭成有控制力的流程；
- 可观测治理解决「系统跑起来怎么管」——最后让这个系统可调试、可演进、可上线。
这三层是有先后顺序的：没有标准化的组件，编排就无从谈起；没有可控的流程，治理也没有抓手。LangChain 的 v1.0 架构，正是沿着这三层重新组织的。
那「Agent」「RAG」算什么
你可能注意到，前面通篇没怎么提 LangChain 最常被讨论的两个词——Agent 和 RAG。这是有意的。
很多人把 LangChain 等同于「做 Agent 的框架」或「做 RAG 的库」，这是从功能角度看的。但从框架角度，Agent 和 RAG 不是框架本身，而是跑在框架上的两类典型应用：
- RAG（检索增强生成）= 用「组件复用 + 流程编排」搭出的「检索→拼接→生成」流水线
- Agent（智能体）= 用「流程编排 + 可观测治理」搭出的「思考→调工具→再思考」的循环系统
框架提供积木和编排能力，RAG 和 Agent 是你用这些积木搭出来的成品。这个区分很重要：它意味着学 LangChain 不是学「怎么做一个 Agent」，而是学一套可搭出 RAG、Agent 以及更多应用的通用工程能力。这也是为什么这个系列会先花力气讲 Runnable、LCEL、LangGraph 这些「底层积木」，而不是一上来就教你 demo。
该不该引入框架：一个诚实的判断
和任何框架一样，LangChain 不是免费的。它带来收益，也带来成本，我把它讲清楚，不替你做决定：
收益：
- 省掉每个 LLM 应用都要重写的工程样板
- 组件可替换（换模型、换向量库改动极小）
- 流程可视化、可调试、可评估
- 生态成熟，RAG/Agent/工具调用有现成方案
成本：
- 一层抽象带来学习成本（Runnable、LCEL、middleware 都要理解）
- 概念体系要花时间吃透（这是本系列想帮你建立的东西）
- 对「就调一次模型、拿个回答」的极简场景，是过度设计
所以一个诚实的判断是：当你的 LLM 应用开始出现「重试、工具、记忆、检索、多步流程、需要排查」中的任意两个，就值得引入框架。反过来，如果只是「写个脚本调一次 API 打印结果」，裸调就够，别给自己加复杂度。
收束：先立坐标，再谈积木
这一篇没有讲 LangChain 的任何一行代码，而是先把「为什么需要 LLM 应用框架」的坐标立起来。三根轴回答了这个问题：
- 组件复用——为什么不能让每个组件各写各的
- 流程编排——为什么不能只靠直线调用
- 可观测治理——为什么不能让 LLM 调用是黑盒
带着这套坐标，下一篇会落到一个更具体的问题：LangChain 在 v1.0 到底分了几层、各管什么——把 core、LangGraph、langchain 这三块的关系讲清，让你看清哪一层该关心什么、哪一层不该操心。这是后面所有章节的地图。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
