标签 OpenAI 协议 下的文章

这两年,大模型几乎成了开发者的“标配工具”:
写代码、查资料、做总结、当智能助手。

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

我们真的必须把所有请求都发到云端 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 是当前本地部署的性价比甜点位
  2. Prompt 比模型更重要

    • 本地模型对 Prompt 非常敏感
  3. LangChain 要“模块化使用”

    • Prompt / LLM / Parser / Memory 明确分层
  4. Memory 要可演进

    • InMemory → Redis → 数据库 → Checkpointer
  5. Ollama 非常适合私有化场景

    • Docker + 内网 + 权限控制,工程成本极低

结语

过去一年,我们讨论最多的问题是:

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

而现在,越来越多开发者开始认真思考:

“哪些能力,其实可以放回本地?”

LangChain + Ollama 并不是为了“替代云”,
而是为我们提供了一个:

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

如果你正在做:

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

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


如果你觉得这篇文章对你有帮助,欢迎 点赞 / 转发 / 收藏
下一篇,我会继续分享 LangGraph 在本地大模型场景下的实战用法

这又是一个重复造轮子系列,目的是解决一些公益站不支持 CC、模型不支持工具调用的问题,该项目可以让不支持工具调用的模型获得工具调用的能力
在佬友项目B4U2CC:让 B4U 支持 Claude Code+思考的基础上进行大量的迭代更新,

  • 支持了多组配置,可以配置多个站点,使用渠道+模型名称的形式进行分流
  • 支持的密钥透传
  • 支持使用 firecrawl 来模拟官方 api 才有的的 web searchweb fetch 功能 (目前仅 Preview 分支,测试镜像 ghcr.io/passerby1011/cc-proxy:preview
  • 在 b4u2cc 的基础上改用了 @curaalizm 佬友项目的随机字符标识 感觉更稳定? 好像?
  • 增加了远端 pg 数据库存储配置(hugging face 部署,冲!!!)
  • 增加了工具内部重试 (测试 ing)
  • 增加了 web 管理界面 (/admin),配置更方便
┌─────────────┐
│ Claude Code │ ──① Claude API 请求──▶
└─────────────┘    (包含 tools 定义)

┌──────────────────────────────────────┐
│           cc-proxy 代理层             │
│                                      │
│  ② 提示词注入 (prompt_inject.ts)       │
│     • 工具定义 → XML 格式提示词         │
│     • 注入到 system prompt            │
│     • 生成唯一分隔符                   │
│                                      │
│  ③ 协议转换 (map_claude_to_openai.ts) │
│     • Claude Messages API            │
│       → OpenAI Chat Completions      │
│     • 保持流式兼容                     │
│                                      │
│  ④ 上游转发 (upstream.ts)             │
│     • 支持 OpenAI 协议                │
│     • 支持 Anthropic 协议             │
│     • SSE 流式处理                    │
└──────────────────────────────────────┘
                    │
                    ▼
         ┌──────────────────┐
         │   上游 AI 服务    │ ──⑤ 返回 XML 格式的工具调用──▶
         │ (GPT-4/Claude等)  │
         └──────────────────┘

┌──────────────────────────────────────┐
│           cc-proxy 代理层             │
│                                      │
│  ⑥ 智能解析 (parser.ts)               │
│     • 识别 XML 工具调用块              │
│     • 识别 <thinking> 块              │
│     • 提取工具名称和参数                │
│                                      │
│  ⑦ 标准化输出 (claude_writer.ts)       │
│     • 生成标准 Claude SSE 事件         │
│     • tool_use 消息块                 │
│     • thinking 消息块                 │
└──────────────────────────────────────┘
                    │
                    ▼
         ┌─────────────┐
         │ Claude Code │ ◀── 标准 Claude API 响应
         └─────────────┘
Tip

使用 firecrawl 来模拟官方 api 才有的的 web searchweb fetch,这个思路可以引入到哪些能力更健全逆向模型上,更好的支持 cc
这个项目所有的工具调用都是用提示词来实现的,感觉还是太勉强

测试截图,模型来自 elysiver 的 claude-4.5-sonnet
吐槽:这数据从哪来的,编的和真一样


致谢:

Danger

部署者能看到您的部分聊天上下文推荐自行部署以保证数据安全

Tip

可能有非常多的 bug,代码都来自 claude,anthropic 公司对此负全责,有问题也可以找它修改


📌 转载信息
原作者:
passerby
转载时间:
2026/1/10 19:22:01