LangChain + DeepSeek 实战拆解：从 LCEL 到智能体，如何真正“做出”一个可控 AI 系统？

霍格沃兹_测试
7 阅读4分钟

大模型很强。

但如果你只是：

llm.invoke("帮我写点东西")

那你做的不是系统，只是调用接口。

真正的工程问题是：

  • 多步骤推理怎么组织？
  • 外部数据怎么接入？
  • 工具怎么安全调用？
  • 对话怎么长期记忆？
  • 结果怎么结构化输出？

这才是 LangChain 解决的问题。

目录

  1. LangChain 到底解决什么问题？
  2. 环境搭建：DeepSeek + LiteLLM
  3. LCEL 新范式：Prompt | LLM | Parser
  4. 流式输出如何实现？
  5. RAG：检索链路如何接入？
  6. 记忆机制的新写法
  7. Agent 与工具调用
  8. 一个完整对话系统示例
  9. LangChain 在工程里的真实价值

一、LangChain 到底解决什么问题？

单独的 LLM 像一个聪明的大脑。

但它没有：

  • 手（不能执行函数）
  • 眼睛（不能实时查资料）
  • 记忆库（上下文有限）
  • 任务调度系统（不会组织复杂流程）

LangChain 的本质，是一套可组合的 LLM 编排框架。

它不增强模型能力，它增强：

  • 可控性
  • 可组合性
  • 可扩展性
  • 工程稳定性

二、环境搭建：DeepSeek + LiteLLM

安装：

pip install langchain langchain-openai langchain-community python-dotenv -i https://mirrors.aliyun.com/pypi/simple/
pip install -U litellm

.env 文件：

DEEPSEEK_API_KEY=sk-xxx
DEEPSEEK_BASE_URL=https://api.deepseek.com
DEEPSEEK_MODEL=deepseek-chat

初始化模型：

from langchain_openai import ChatOpenAI
import os

llm = ChatOpenAI(
    model=os.getenv("DEEPSEEK_MODEL"),
    openai_api_key=os.getenv("DEEPSEEK_API_KEY"),
    openai_api_base=os.getenv("DEEPSEEK_BASE_URL"),
    temperature=0.7
)

这里有个工程重点：

LangChain 不直接适配所有模型，它通过 LiteLLM 做统一接口抽象。

这一步是“工程层”的关键。

三、LCEL：Prompt | LLM | Parser

旧版 LLMChain 已经被弃用。

现在的标准写法是 LCEL（LangChain Expression Language）。

核心结构：

Prompt → Model → OutputParser

代码示例：

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一位技术专家，用通俗语言解释概念。"),
    ("user", "{concept}")
])

chain = prompt | llm | StrOutputParser()

result = chain.invoke({"concept": "量子纠缠"})
print(result)

为什么必须要 Parser？

因为：

模型输出是 Message 对象 工程系统需要字符串或结构化 JSON

没有 Parser，工程不可控。

四、流式输出（Streaming）

真实应用里，你不可能等 10 秒再一次性输出。

只需要把 .invoke() 换成 .stream()：

for chunk in chain.stream({"concept": "递归神经网络"}):
    print(chunk, end="", flush=True)

流式输出是：

  • 聊天机器人
  • WebSocket 应用
  • 实时界面

的基础能力。

五、RAG：检索增强生成

LangChain 把 RAG 拆成清晰的流水线：

文档加载 → 文本切片 → 向量化 → 向量存储 → 检索器

示意结构：

DocumentLoader
     ↓
TextSplitter
     ↓
Embeddings
     ↓
VectorStore
     ↓
Retriever
     ↓
LLM

关键点在于：

Retriever 现在是一个“可嵌入链的组件”。

不只是数据库查询，而是可参与推理流程。

六、记忆机制的新写法

旧版 ConversationBufferMemory 已经不推荐。

现在的写法是：

  • ChatMessageHistory
  • RunnableWithMessageHistory

记忆不再是链的属性。

而是一个独立的存储系统，通过 session_id 区分用户。

核心代码：

with_message_history = RunnableWithMessageHistory(
    chain,
    get_session_history,
    input_messages_key="question",
    history_messages_key="history",
)

这意味着：

记忆可以持久化到 Redis / PostgreSQL。

工程级对话系统必须这样做。

七、Agent 与工具调用

智能体的本质是：

  1. LLM 判断是否需要调用工具
  2. 调用工具
  3. 观察结果
  4. 再决定下一步

创建工具：

from langchain.agents import create_tool_calling_agent

agent = create_tool_calling_agent(llm, tools, prompt)

核心机制是：

模型 → 决策 → Tool Call → 观察 → 最终回答

LangChain 现在推荐用 LangGraph 构建复杂 Agent。

因为多步骤推理本质是“状态机”。

八、一个完整的对话系统示例

带记忆的聊天机器人核心结构：

prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一个乐于助人的 AI 助手。"),
    MessagesPlaceholder(variable_name="history"),
    ("human", "{question}")
])

chain = prompt | llm

然后通过 RunnableWithMessageHistory 管理会话。

结果就是：

AI 记得你叫小明。

这不是魔法，是工程结构。

九、LangChain 在工程里的真实价值

很多人误解 LangChain 是“封装模型”。

其实它解决的是：

  • 多步骤流程编排
  • 工具安全调用
  • RAG 标准化接入
  • 会话管理
  • 可测试结构

它让你从：

“写 Prompt 的人”

变成：

“设计 AI 系统架构的人”

这才是核心。

结尾

LangChain 不是模型。

它是 LLM 应用的“操作系统”。

当你真正用 LCEL 构建：

Prompt → 检索 → 工具 → 记忆 → 输出

你会发现，大模型只是其中一层。

真正决定系统稳定性的，是结构。

而结构，才是工程能力的分水岭。

avatar
文章
阅读
粉丝