前言
当下大模型应用开发早已不是简单调用一次LLM API、写一段Prompt就能交付。 当我们要做知识库问答、工具调用Agent、多轮对话、自主迭代推理的智能体时，会遇到一连串现实难题：如何统一对接不同厂商大模型？怎么把文档检索、工具调用、提示词组装起来？Agent需要循环试错时流程该怎么编排？上线后模型幻觉、链路报错该怎么定位与评估？
LangChain、LangGraph、LangSmith这套生态，就是为了解决LLM工程化落地而生。很多初次接触的开发者都会产生疑问：三者到底各自承担什么职责？什么时候该用谁？是不是开发项目必须同时引入这三个库？
本文会从开发痛点出发，逐个拆解三个工具的能力边界，讲清楚它们如何协同构建完整的大模型应用开发闭环，同时纠正行业里流传很广的认知误区。
一、LLM应用开发：远不止调用一次大模型API
很多新手入门大模型开发，以为整个流程就是：调用大模型接口，传入Prompt，拿到返回结果，任务就完成了。 但一旦落地到真实业务场景，就会发现大量额外工作： 需要解析文档、构建知识库，实现RAG检索；需要赋予大模型调用外部工具的能力；要保存多轮对话上下文；复杂智能体需要反复思考、调用工具、迭代修正；服务异常中断时希望保留现场、断点续跑；上线之后还要观测每一步链路，定位幻觉与错误，持续评估应用质量。
原生大模型API只负责生成文本，上述这些工程化能力都需要我们手动编写大量重复代码。而LangChain生态，就是把这些通用能力封装成一套可复用的工具集。
二、LangChain：LLM应用的零件工具箱
LangChain本质是开源大模型应用开发组件框架。 你可以把它理解成宜家的零件仓库：模型封装、提示词模板、文档检索、工具封装、链路编排等高频能力，全部封装成独立组件。开发者不用重复造轮子，按需挑选组件快速组装原型。
它包含六大核心组件：
- Models：统一封装各大厂商大模型，更换底层模型几乎不用改动业务代码；
- Prompts：管理提示词模板，支持少样本示例，方便Prompt复用；
- Retrievers：对接向量数据库，实现知识库检索，支撑RAG场景；
- Tools：封装外部工具能力，允许大模型调用搜索、数据库查询等外部能力；
- Memory：对话记忆组件。⚠️注意：该组件属于旧版遗留组件，LangChain v0.2之后官方标记为legacy，新版项目推荐使用LangGraph的Checkpointer做状态持久化，不推荐新项目直接使用Memory；
- Chains / LCEL：链路表达式语言，用来把上面各类组件串联，构建固定顺序的业务流程。
LCEL的能力边界：线性任务够用，复杂循环场景受限
LCEL是LangChain的链式编排语法，非常适合线性、单向、一次性执行的任务。比如简单文档摘要、基础RAG问答、文本信息抽取，用LCEL开发原型效率极高。
这里要纠正一个高频误区：LCEL不是完全不能做分支，它提供RunnableBranch可以实现简单if-else分支判断。 但LCEL存在底层短板，下面这些场景仅靠LCEL很难实现：
- 需要循环迭代：思考→调用工具→拿到结果再次思考的Agent自迭代流程；
- 缺少全局可变共享状态，组件之间无法统一读写同一份状态数据；
- 不支持断点续跑，程序崩溃之后无法从上次执行现场恢复；
- 无法支持人工中途介入审核（人机协同）；
- 不适合多智能体协作、超长会话等复杂场景。
当业务出现上面需求，单纯的流水线式编排就不再够用，这时我们就需要LangGraph。
三、LangGraph：面向Agent的状态机编排引擎
普通流水线的执行顺序是写死的，一步接一步单向执行。但Agent智能体的特点是：每一步输出，会动态决定下一步该干什么，甚至需要循环重试。这种动态流转的业务，需要状态机来实现，也就是LangGraph的核心价值。
LangGraph由三个基础核心模块构成：State、Node、Edge
- State（全局状态）：共享的数据仓库。对话历史、工具返回结果、中间推理内容全部保存在这里，所有节点都可以读取、修改这份状态；
- Node（节点）：最小执行单元。节点可以调用LLM、执行外部工具，也可以执行自定义业务代码；节点执行完成后，更新全局State；
- Edge（边）：定义流程跳转规则。其中条件边是实现循环、动态分支的关键，可以根据当前State里的数据，动态判断下一步去往哪个节点。
举一个典型例子：自动写代码Agent。 一个节点负责生成代码，下一个节点运行测试；根据测试结果这个状态，条件边进行判断：如果测试失败，循环回到代码生成节点，重新修改代码；测试通过，才输出最终代码结果。整个流程不是预先写死，由每一步运行结果动态决定走向。
基于这套状态机模型，LangGraph带来四大核心能力：
- 循环工作流：支持经典的“思考-工具调用-再思考”Agent迭代模式；
- 状态持久化Checkpointer：实现断点续跑。服务崩溃重启之后，可以恢复到之前的执行现场；还支持“时间旅行”，回溯查看每一步历史状态；
- 人机协同Human-in-the-loop：流程运行到关键节点时可以暂停，交给人工审核修改，确认后再继续自动执行；
- 多智能体协作：多个Agent作为图中不同节点，共享状态，分工协作完成复杂任务。
一句话总结LangGraph的定位：它可以把确定性业务代码、大模型自主决策逻辑，统一放在同一张状态图中管理。
注意：LangGraph并不是用来完全替代LangChain，二者是互补关系。新版LangChain内置Agent底层，本身就是基于LangGraph实现。
四、LangSmith：LLM应用的示波器与评测平台
当我们完成组件组装、流程编排之后，会遇到LLM开发独有的痛点：大模型应用是黑盒。 线上输出结果出错，很难快速定位根因：是检索出来的文档不对？Prompt设计有缺陷？还是大模型本身产生幻觉？单纯靠日志很难排查。LangSmith就是解决这个问题的平台。
核心误区澄清：LangSmith框架无关，并非只能搭配LangChain/LangGraph。原生OpenAI接口、手写Agent、CrewAI等任意LLM应用，都可以埋点接入追踪，LangChain只是自带开箱即用的埋点能力。LangSmith本身不会运行你的Agent业务代码，它只负责观测、记录、评估应用的执行全过程。
LangSmith四大核心功能：
- Tracing 链路追踪：完整记录每一步的输入输出、耗时、Token消耗。线上问题可以直接定位到链路中出错的具体环节；
- Evaluation 评估：维护测试数据集，支持自动打分、人工打分。修改Prompt或图逻辑后，在同一套测试集上回归测试，检验效果是否退化；
- Prompt管理：提示词版本管控，支持在线编辑、团队协作，不用硬编码在代码中，支持灰度切换不同Prompt版本；
- 监控与反馈：仪表盘可视化延迟、成本、错误率；收集用户的正向/负向评价，把线上真实坏案例回收，补充到测试数据集。
五、三者协同：LLM应用完整开发闭环
在真实项目开发中，LangChain、LangGraph、LangSmith共同组成一套完整迭代闭环：
- 组装组件：使用LangChain的模型、检索器、工具等组件，搭建基础能力；
- 编排流程：简单线性任务直接使用LCEL；需要循环、动态决策的复杂Agent，采用LangGraph做状态图编排；
- 调试评估：接入LangSmith开启链路追踪，跑测试集做回归评估，验证改动效果；
- 上线与持续迭代：上线后依靠LangSmith持续监控。线上收集到的负面案例，回流到测试集，反向优化Prompt或者LangGraph流程，反复迭代优化。
简单记住三者分工：
LangChain造零件，LangGraph编排复杂流程，LangSmith负责质量观测，驱动迭代优化。
六、选型指南：什么时候用，什么时候不用
| 工具 | 适用场景 | 不推荐场景 |
|---|---|---|
| LangChain（LCEL） | 简单RAG、固定流程任务、快速原型开发 | 需要循环迭代、断点续跑、人工审核的复杂Agent |
| LangGraph | 循环Agent、多智能体、长会话、人机审核 | 简单线性任务，引入会增加额外复杂度，杀鸡用牛刀 |
| LangSmith | 开发调试、版本评估、线上监控 | 仅本地一次性Demo、不需要长期迭代评估的极简原型 |
两个最常见误区再次强调： ❌ 误区一：LangGraph可以完全替代LangChain。二者互补，新版LangChain Agent底层就是LangGraph； ❌ 误区二：LangSmith只能配合LangChain。框架无关，任何LLM代码都可以埋点接入。
七、总结
LangChain、LangGraph、LangSmith共同构成LLM工程化开发的完整生态，但三者并不是捆绑强制使用。
- LangChain提供开箱即用的各类开发组件，快速搭建基础LLM应用；
- LangGraph以状态机为核心，解决Agent循环推理、动态流程编排的难题；
- LangSmith解决大模型黑盒问题，提供链路追踪、评测、监控能力，保障上线质量。
做项目要按需选型：简单RAG问答，只用LangChain就足够；如果要开发生产级、具备自主迭代能力的复杂Agent，三者配合，才能搭建稳定、可调试、可持续迭代的大模型应用。
本文源自技术宣讲分享，适合入门开发者快速建立对LangChain生态的全局认知。
