用 LangChain 驱动本地 Ollama 模型

这两年，大模型几乎成了开发者的“标配工具”：

写代码、查资料、做总结、当智能助手。

但你有没有认真想过一个问题：

我们真的必须把所有请求都发到云端 API 吗？

随着模型体积持续下降、硬件性能快速提升，以及 Ollama 这类工具逐渐成熟，

本地运行大模型，已经从早期的“极客尝鲜”，演进为一种可以在真实项目中落地的工程方案。

这篇文章，我们就来完整走一遍：

如何使用 LangChain，基于最新 Runnable API，调用本地启动的 Ollama 模型，构建一个真正可用的本地大模型应用。

一、为什么选择 LangChain + Ollama？

先给结论：

Ollama 解决“模型怎么跑”，LangChain 解决“能力怎么用”。

这是目前本地大模型场景中，最自然、最稳定的一种组合方式。

1️⃣ Ollama：本地大模型的“Docker”

你可以把 Ollama 理解为：

专门为大模型设计的一层运行时基础设施。

它解决的问题非常聚焦：

• 统一模型的下载、管理与启动
• 对外提供标准化 HTTP API（默认端口 11434）
• 支持 LLaMA、Qwen、Mistral、DeepSeek 等主流模型
• Mac / Linux / Windows 全平台可用
• 天然适合 Docker / 私有化部署

一句话总结：

Ollama 把“跑模型”这件事，做成了基础设施能力。

2️⃣ LangChain：AI 应用的“控制中心”

如果你只是想“问一句、回一句”，直接调 Ollama API 当然也没问题。

但一旦进入真实工程场景，需求会迅速复杂化：

• Prompt 如何复用、版本化？
• 对话上下文如何管理？
• 如何组合多步推理？
• 后续怎么接 RAG、Agent、工具调用？

这些正是 LangChain 擅长的事情：

• Prompt 模板与结构化输入
• Runnable / LCEL 编排能力
• 对话历史（Memory）管理
• Tool、RAG、Agent 的统一抽象
• 可自然演进到 LangGraph

所以一个非常自然的分工是：

LangChain 负责“编排与逻辑”，Ollama 负责“模型与算力”。

二、准备工作：本地启动 Ollama 模型

1️⃣ 使用 Docker 部署 Ollama（推荐）

docker run \
-d \
--restart=always \
--name ollama \
--gpus=all \
-p 11434:11434 \
-v /home/data/ollama:/root/.ollama \
ollama/ollama

如果你对部署细节感兴趣，可以参考我之前的文章：《如何使用 Ollama 打造你的本地 AI 助手》 《为本地部署的大模型添加 API Key 认证：Nginx 实现方案》

2️⃣ 拉取并运行模型

以 qwen3:8b 为例：

ollama pull qwen3:8b

简单测试：

ollama run qwen3:8b

如果可以正常对话，说明模型已经在本地成功运行。

三、LangChain 接入本地 Ollama（OpenAI 协议）

接下来进入核心部分：

如何用 LangChain 调用本地 Ollama？

1️⃣ 安装依赖

pip install langchain langchain-openai

这里我们使用 OpenAI 兼容协议，这是目前最稳定、生态最完整的一种方式。

2️⃣ 创建 Ollama LLM（ChatOpenAI）

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    name="ollama-ai",
    model="qwen3:8b",
    base_url="http://localhost:11434/v1",
    api_key="your api key",
    temperature=0.7,
    timeout=300,
)

几个关键点说明：

• model 必须与 Ollama 中的模型名称一致
• base_url 指向 Ollama，并注意使用 /v1 后缀
• 这里使用的是 OpenAI 标准协议，不是 Ollama 私有 API

3️⃣ 最简单的一次调用

response = llm.invoke("用一句话解释什么是 LangChain")
print(response)

到这里，你已经完成了：

LangChain → 本地 Ollama → 本地大模型

这条完整调用链。

四、进阶用法：Prompt + Runnable（LCEL）

在真实项目中，几乎不会直接“裸调”模型。

1️⃣ PromptTemplate

from langchain_core.prompts import PromptTemplate

prompt = PromptTemplate(
    input_variables=["question"],
    template="你是一个资深后端工程师，请用简洁、专业的语言回答：{question}",
)

2️⃣ 输出解析（StrOutputParser）

from langchain_core.output_parsers import StrOutputParser

parser = StrOutputParser()

显式的输出解析，是 LangChain 新 API 的重要特征：

• 输出类型清晰
• 便于后续切换为 JSON / Pydantic
• 更适合工程化

3️⃣ Runnable 组合（推荐写法）

chain = prompt | llm | parser

response = chain.invoke({
    "question": "为什么本地部署大模型越来越流行？"
})
print(response)

这就是 LangChain 当前主推的 LCEL（表达式）写法，

比早期的 LLMChain 更透明、也更可组合。

五、加入 Memory：真正的本地对话能力

⚠️ 一个非常重要的变化：

在新的 Runnable 体系中，

Memory 不再是 Chain 的“隐藏参数”，而是显式的状态管理。

1️⃣ 定义对话历史存储

from langchain_core.chat_history import InMemoryChatMessageHistory

store = {}

def get_session_history(session_id: str):
    if session_id not in store:
        store[session_id] = InMemoryChatMessageHistory()
    return store[session_id]

2️⃣ Prompt 显式消费 history（关键）

from langchain_core.prompts import PromptTemplate

prompt = PromptTemplate(
    input_variables=["history", "question"],
    template="""
         你是一个资深后端工程师。

         以下是之前的对话历史：
         {history}

         当前用户问题：
         {question}

         请基于上下文给出连贯、准确的回答。
    """.strip()
)

这是很多人第一次使用 RunnableWithMessageHistory 时最容易忽略的一点： 历史是否生效，取决于 Prompt 是否显式使用 {history}。

3️⃣ 构建带记忆的 Runnable

from langchain_core.runnables.history import RunnableWithMessageHistory

chain = prompt | llm | parser

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

4️⃣ 调用（带 session_id）

config = {"configurable": {"session_id": "local-chat"}}

print(chat_chain.invoke(
    {"question": "什么是 Ollama？"},
    config=config
))

print(chat_chain.invoke(
    {"question": "它和 LangChain 有什么关系？"},
    config=config
))

到这里，你已经拥有了一个：

• 支持上下文
• 完全本地
• 状态可控

的对话系统。

而且 所有数据都只存在你的本地机器上。

六、这套方案适合谁？

非常适合：

• ✅ 本地工具 / 桌面应用
• ✅ 内部知识库 / 私有 RAG
• ✅ 研发辅助工具（代码、文档、SQL）
• ✅ 对数据安全敏感的企业场景
• ✅ 学习大模型工程化的开发者

不太适合：

• ❌ 超大并发场景
• ❌ 极限性能 / 超大模型
• ❌ 面向公网的 C 端产品

七、一些来自实践的工程建议

最后分享几点真实踩坑后的经验：

1. 模型别贪大

• 7B / 8B 是当前本地部署的性价比甜点位
• Prompt 比模型更重要
• 本地模型对 Prompt 非常敏感
• LangChain 要“模块化使用”
• Prompt / LLM / Parser / Memory 明确分层
• Memory 要可演进
• InMemory → Redis → 数据库 → Checkpointer
• Ollama 非常适合私有化场景
• Docker + 内网 + 权限控制，工程成本极低

结语

过去一年，我们讨论最多的问题是：

“该用哪个云端大模型？”

而现在，越来越多开发者开始认真思考：

“哪些能力，其实可以放回本地？”

LangChain + Ollama 并不是为了“替代云”，

而是为我们提供了一个：

真正可控、可组合、可落地的本地大模型方案。

如果你正在做：

• 本地 AI 工具
• 私有化大模型
• Agent / RAG 工程实践

那么这套组合，非常值得一试。

如果你觉得这篇文章对你有帮助，欢迎 点赞 / 转发 / 收藏。

下一篇，我会继续分享 LangGraph 在本地大模型场景下的实战用法。