LangChain 技术博客：从 LLM 调用到 Agent 与 RAG-酒店常州论坛

LangChain 技术博客：从 LLM 调用到 Agent 与 RAG

本文介绍 LangChain 的基本思想、核心组件，以及如何使用 LangChain 构建 LLM 应用、Agent 和 RAG 知识库系统。

1. 什么是 LangChain？

随着 ChatGPT、Claude、Gemini 等大语言模型的发展，调用一个 LLM 已经非常简单。

例如：

response=model.invoke("请介绍一下 Transformer")

但真正开发一个 AI 应用时，我们通常还需要：

Prompt 管理
多轮上下文
外部工具调用
数据库查询
文档检索
RAG 知识库
Agent 决策
工作流编排
日志追踪与评估

如果全部自己实现，代码会迅速变得复杂。

LangChain 的作用就是给这些能力提供一套统一的开发框架。

可以简单理解为：

LLM │ ├── Prompt ├── Tools ├── Retriever ├── Memory / Context ├── Agent │ └── Application

LangChain 并不是一个大模型，而是连接LLM、数据、工具和应用逻辑的开发框架。

2. LangChain 的整体技术栈

现在可以把 LangChain 生态理解成三个主要部分：

LangChain │ ┌───────────┼───────────┐ │ │ │ Model Agent RAG │ │ │ └─────── LangGraph ─────┘ │ LangSmith

其中：

LangChain

负责提供模型、Tool、Agent、Retriever 等高级开发接口。

LangGraph

负责复杂 Agent 的状态管理和工作流编排。

LangSmith

负责运行追踪、调试、评估和可观测性。

对于普通项目，可以先使用 LangChain。

如果业务流程逐渐复杂，例如：

问题 ↓ 判断问题类型 ↓ 搜索知识库 ↓ 判断结果是否足够 ├── 是 → 生成答案 └── 否 → Web Search ↓ 再次生成

这种具有状态、分支和循环的流程，更适合使用 LangGraph。

3. 安装 LangChain

推荐创建独立 Python 环境。

python-mvenv .venv

Linux/macOS：

source.venv/bin/activate

Windows：

.venv\Scripts\activate

安装 LangChain：

pipinstall-Ulangchain

如果使用 OpenAI 模型：

pipinstall-U"langchain[openai]"

或者：

pipinstall-Ulangchain-openai

建议把 API Key 放到环境变量中，而不是直接写在代码里。

例如.env：

OPENAI_API_KEY=your_api_key

安装：

pipinstallpython-dotenv

然后读取：

fromdotenvimportload_dotenv load_dotenv()

4. LangChain 中最核心的组件：Model

LangChain 对不同模型提供了相对统一的接口。

例如：

fromlangchain.chat_modelsimportinit_chat_model model=init_chat_model("openai:gpt-5.5")

然后调用：

response=model.invoke("什么是 Transformer？")print(response.content)

核心逻辑非常简单：

User Input ↓ LangChain ↓ LLM ↓ AIMessage

LangChain 的优势在于，当项目需要切换不同模型提供商时，上层业务代码通常不需要进行大规模修改。

例如模型可以来自：

OpenAI Anthropic Google Gemini Azure OpenAI AWS Bedrock HuggingFace Ollama ...

这也是 LangChain 很重要的设计思想：

让应用依赖统一的 Model Interface，而不是直接依赖某一家模型厂商。

5. Prompt：控制模型行为

实际项目中，我们通常不会直接把用户问题扔给模型，而是需要 System Prompt。

例如：

messages=[{"role":"system","content":"你是一名 Python 技术专家，请使用简洁准确的语言回答问题。"},{"role":"user","content":"Python 的装饰器是什么？"}]response=model.invoke(messages)print(response.content)

这里实际上形成：

System Prompt + User Prompt ↓ LLM ↓ Response

System Prompt 决定了模型：

扮演什么角色
如何组织答案
可以做什么
不可以做什么
输出什么格式

所以在实际 LLM 应用开发中：

Prompt 本质上也是程序逻辑的一部分。

6. Tool：让大模型拥有外部能力

LLM 最大的问题之一是：

它本身并不能直接操作真实世界。

例如：

查询天气 查询数据库 读取文件 调用搜索引擎 执行 Python 访问公司 API 查询订单

这些能力需要通过 Tool 实现。

例如定义一个天气工具：

defget_weather(city:str)->str:"""查询指定城市的天气。"""returnf"{city}今天晴，25°C"

然后可以创建一个 Agent：

fromlangchain.agentsimportcreate_agent agent=create_agent(model="openai:gpt-5.5",tools=[get_weather],system_prompt="你是一名智能助手，可以使用工具回答用户问题。")

调用：

result=agent.invoke({"messages":[{"role":"user","content":"杭州今天天气怎么样？"}]})print(result["messages"][-1].content)

这里的关键变化是：

普通 LLM：

Question ↓ LLM ↓ Answer

Agent：

Question ↓ LLM ↓ 需要工具吗？ / \ 否 是 │ │ 回答 调用 Tool │ Tool Result │ LLM │ Answer

也就是说：

Agent = LLM + Tools + Decision Loop

LLM 不再只是生成文字，而开始负责判断：

下一步应该做什么。

7. 什么是 Agent？

Agent 是 LangChain 最重要的应用方向之一。

普通聊天机器人是：

Input → LLM → Output

而 Agent 是：

Input ↓ Reasoning ↓ 选择 Tool ↓ 执行 Tool ↓ 读取结果 ↓ 继续判断 ↓ Final Answer

例如用户问：

帮我查询杭州天气，如果下雨就推荐三个室内景点。

Agent 可以执行：

1. 理解用户问题 2. 调用 Weather Tool 3. 获得： 杭州今天有雨 4. 判断： 满足“下雨”条件 5. 调用 Search Tool 6. 搜索： 杭州室内景点 7. 整理搜索结果 8. 返回最终答案

这已经不再是简单的“文本生成”。

而是一种：

LLM 驱动的任务执行系统

8. RAG：让大模型读取自己的知识库

LangChain 另一个非常重要的应用就是 RAG。

RAG：

Retrieval-Augmented Generation

中文通常翻译为：

检索增强生成。

它解决的是这样一个问题：

假设公司有 10000 份内部文档：

技术文档 产品说明 项目报告 合同 论文 数据库

这些数据并不存在于模型训练数据中。

如果直接问：

我们公司的 XXX 项目采用什么技术架构？

LLM 很可能不知道。

因此需要：

用户问题 ↓ 知识库检索 ↓ 找到相关文档 ↓ 文档 + 问题 ↓ LLM ↓ 答案

这就是 RAG。

9. RAG 的核心流程

一个典型 RAG 系统通常包含：

Documents ↓ Document Loader ↓ Text Splitter ↓ Chunks ↓ Embedding Model ↓ Vectors ↓ Vector Database

用户提问时：

Question ↓ Embedding ↓ Vector Search ↓ Relevant Documents ↓ Prompt ↓ LLM ↓ Answer

所以 RAG 可以分成两个阶段。

第一阶段：

Indexing

即建立知识库。

第二阶段：

Retrieval + Generation

即查询知识库并生成答案。

10. Document Loader

Document Loader 用来读取数据。

例如数据来源可能是：

PDF Word Markdown TXT Web Notion Google Drive 数据库

最终 LangChain 会尽量统一转换成：

Document

其基本结构类似：

Document(page_content="文档正文",metadata={"source":"example.pdf"})

这样无论原始文件是什么格式，后面的处理逻辑都可以保持统一。

11. Text Splitter

大模型和 Embedding 模型都不适合一次处理超长文档。

因此需要把文档切成多个 Chunk：

完整论文 ↓ Chunk 1 Chunk 2 Chunk 3 Chunk 4 ...

例如：

chunk_size = 1000 chunk_overlap = 200

意味着每个文本块大约 1000 个字符，相邻 Chunk 保留部分重叠。

为什么需要 overlap？

因为一句完整语义可能刚好出现在两个 Chunk 的边界。

例如：

Chunk 1： Transformer 使用 Self-Attention 机制， 它能够计算不同 token ... Chunk 2： ...之间的关系，因此能够有效处理 长距离依赖问题。

如果完全没有 overlap，语义就可能被截断。

12. Embedding

Embedding 是 RAG 的核心技术之一。

Embedding 模型会把文本：

LangChain 是一个 LLM 应用开发框架

转换成向量：

[0.12, -0.31, 0.77, ..., 0.18]

如果两个文本语义相似：

LangChain 是什么？ LangChain 有什么作用？

对应的向量在高维空间中通常也会比较接近。

因此可以通过计算：

Cosine Similarity

或者其他距离指标寻找相似文本。

整个过程可以表示为：

Text ↓ Embedding Model ↓ Vector

用户问题同样执行：

Question ↓ Embedding ↓ Query Vector

然后：

Query Vector ↓ Vector Database ↓ Top-K Similar Documents

13. Vector Store

Embedding 生成的向量通常需要存储到向量数据库。

常见选择包括：

FAISS Chroma Milvus Qdrant Pinecone Weaviate Elasticsearch

例如：

Document ↓ Embedding ↓ Vector ↓ Vector Store

查询：

Question ↓ Embedding ↓ Vector Search ↓ Top-K Documents

对于本地小型 Demo，可以使用：

FAISS Chroma

对于大规模生产环境，可以考虑：

Milvus Qdrant Pinecone Elasticsearch

具体选择应根据：

数据规模 查询性能 部署方式 过滤需求 成本 高可用需求

决定。

14. Retriever

Retriever 是 LangChain 对“检索能力”的抽象。

输入：

query

输出：

List[Document]

例如：

docs=retriever.invoke("Transformer 为什么使用 Self-Attention？")fordocindocs:print(doc.page_content)

Retriever 后面并不一定只能连接向量数据库。

也可以连接：

Vector Database BM25 Elasticsearch SQL Web Search Knowledge Graph Hybrid Search

因此可以把 Retriever 理解为：

给定一个问题，负责寻找相关上下文。

15. 一个完整 RAG 系统的架构

典型 RAG：

┌──────────────┐ │ User │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ Question │ └──────┬───────┘ │ ▼ ┌───────────────┐ │ Retriever │ └───────┬───────┘ │ ▼ ┌─────────────────┐ │ Vector Database │ └────────┬────────┘ │ Relevant Docs │ ▼ ┌──────────────┐ │ Prompt │ │ │ │ Question │ │ Context │ └──────┬───────┘ │ ▼ ┌───────┐ │ LLM │ └───┬───┘ │ ▼ Answer

这也是目前企业知识库问答系统中非常常见的架构。

16. 2-Step RAG 与 Agentic RAG

传统 RAG 通常是：

Question ↓ Retrieve ↓ Generate

可以称为：

2-Step RAG

它的特点是流程固定、容易调试、延迟容易控制。

但现在越来越多系统开始采用：

Agentic RAG

即由 Agent 判断：

要不要检索？ 检索哪个知识库？ 检索几次？ 当前结果够不够？ 是否需要重新搜索？ 是否需要调用 Web Search？

例如：

User Question ↓ Agent ↓ 问题是否需要知识库？ / \ 不需要 需要 │ │ 回答 Retriever │ 信息是否充分？ / \ 是 否 │ │ LLM Web Search │ LLM

这类系统的灵活性更高，但复杂度和运行成本也会增加。

17. LangGraph 与 LangChain 的关系

随着 Agent 复杂度增加，仅靠：

Prompt + Tools

往往已经不够。

例如一个研究助手可能需要：

用户问题 ↓ Planner ↓ 搜索论文 ↓ 阅读论文 ↓ 判断证据是否充分 ↓ 不足 → 再次搜索 ↓ 整理证据 ↓ 生成报告 ↓ Fact Check ↓ Final Answer

其中包含：

状态 分支 循环 错误恢复 人工确认

这种情况下 LangGraph 更合适。

可以简单理解为：

LangChain ↓ 高级 LLM / Agent 开发接口 LangGraph ↓ 复杂 Agent Workflow 编排

LangChain 的 Agent 本身也建立在 LangGraph 提供的运行能力之上。

18. LangSmith：为什么生产环境需要可观测性？

LLM 应用与普通软件最大的区别之一是：

LLM 输出具有不确定性。

传统代码：

Input → Function → Output

通常比较容易调试。

Agent：

Input ↓ LLM ↓ Tool A ↓ LLM ↓ Tool B ↓ LLM ↓ Output

如果最终结果错误，就需要知道：

Prompt 是什么？ 模型输出了什么？ 调用了哪个 Tool？ Tool 返回了什么？ 用了多少 Token？ 耗时多少？ 哪一步出现问题？

这就是 LangSmith 的主要作用。

它可以帮助开发者观察：

Model Call Tool Call Agent State Latency Token Usage Execution Trace Evaluation Result

因此对于复杂 Agent 项目：

LangChain + LangGraph + LangSmith

通常是比较完整的一套开发链路。

19. LangChain 适合什么项目？

LangChain 比较适合以下场景。

AI 助手

ChatBot 个人助手 企业助手 客服机器人

RAG 知识库

论文知识库 企业文档问答 法律知识库 医疗文献检索 技术文档助手

Agent

Research Agent Coding Agent Data Agent SQL Agent Web Agent

工作流自动化

例如：

读取邮件 ↓ LLM 分类 ↓ 查询数据库 ↓ 生成回复 ↓ 人工审核 ↓ 发送

20. 什么情况下没必要使用 LangChain？

LangChain 并不是所有 LLM 项目的必需品。

如果你的项目只是：

用户输入 ↓ 调用一次模型 ↓ 返回结果

那么直接使用模型厂商 SDK 往往更加简单。

例如：

OpenAI SDK Anthropic SDK Google GenAI SDK

即可完成任务。

LangChain 的价值通常在系统出现以下需求之后才明显：

多个 Prompt 多个 Tool RAG Agent 多模型 状态管理 复杂工作流 Tracing Evaluation

因此不要为了使用 LangChain 而使用 LangChain。

应当根据系统复杂度决定是否引入框架。

21. 一个比较合理的学习路线

如果刚开始学习 LangChain，不建议直接上复杂 Multi-Agent。

22. 总结

LangChain 本质上解决的不是：

“怎么调用一个大模型？”

而是：

“怎么把大模型真正集成到一个软件系统中？”

一个完整的大模型应用往往可以抽象为：

User │ ▼ Prompt │ ▼ Agent ┌─────┼─────┐ │ │ │ ▼ ▼ ▼ Tools RAG APIs │ │ │ └─────┼─────┘ │ ▼ LLM │ ▼ Response

LangChain 提供模型、工具、Agent 和检索等高级抽象；

LangGraph 进一步解决复杂 Agent 的状态和工作流编排；

LangSmith 则解决调试、Tracing 和评估问题。

所以目前更准确的理解应该是：

LangChain = LLM Application Framework LangGraph = Agent Orchestration Framework LangSmith = LLM Observability & Evaluation Platform

如果只是简单调用 LLM，LangChain 并不是必需的。

但当系统逐渐演变为：

LLM + Tools + RAG + Agent + Workflow + Evaluation

LangChain 生态的价值就会逐渐体现出来。

企业官网建设流程全解析