一个包名先分清

对接 Ollama 的正确依赖是 langchain-ollama，装法：uv add langchain-ollama。网上大量老教程写的是 pip install langchain-community 然后导入 from langchain_community.llms import Ollama——那条路在 LangChain 0.2 之后已标记废弃，只做兼容保留，新项目别再起这个头。版本对不上，后面所有报错都会变得莫名其妙。项目级依赖用 uv add，别用全局 pip，多项目共存时版本打架的债迟早要还。

五行跑通

from langchain_ollama import ChatOllama

llm = ChatOllama(model="deepseek-r1:7b", temperature=0.3)

print(llm.invoke("用一句话解释流式输出").content)

for chunk in llm.stream("翻译：Hello, Local LLM!"):
    print(chunk.content, end="", flush=True)

invoke 同步拿全量结果，stream 逐 chunk 吐——前端要打字机效果就用后者。

最高频的一个报错

第一跑大概率撞上这个：

ConnectionError: HTTPConnectionPool(host='localhost', port=11434): Max retries exceeded

根因不在代码，在服务：Ollama 的本地服务没起，或者模型没拉。按顺序验：

curl http://localhost:11434/api/tags     # 服务活着会返回已装模型列表
ollama list                               # 确认 deepseek-r1:7b 真的存在
ollama serve                              # 没起就手动拉起（装了桌面版一般开机自启）

api/tags 返回 JSON 才算服务正常；列表里没有目标模型就 ollama pull deepseek-r1:7b 先拉。三步做完再跑 Python，九成的连接报错到此终结。

temperature 之外，更值钱的两个参数

num_ctx：上下文窗口，默认只有 2048。 这是最隐蔽的坑——多轮对话聊着聊着模型开始"失忆"，不是模型不行，是早期消息被静默截断了。本地内存够就开大：

llm = ChatOllama(model="deepseek-r1:7b", temperature=0.3, num_ctx=8192)

keep_alive：模型驻留时间，默认 5 分钟。 超时后模型从显存卸载，下次调用要重新加载，7B 模型冷启动好几秒——这就是"为什么有时第一问特别慢"。常驻服务场景设 keep_alive=-1（永不卸载），内存紧张就保持默认。

temperature 本身没什么神秘：趋近 0 输出稳定，适合代码生成和结构化抽取；趋近 1 发散，适合文案。日常技术问答 0.2~0.4 起步即可。

多轮对话的正确姿势

传角色消息数组，框架自动拼上下文：

messages = [
    ("system", "你是一名 Python 技术助手，回答简洁。"),
    ("human", "怎么调用本地 Ollama 模型？"),
    ("ai", "用 ChatOllama 组件即可。"),
    ("human", "多轮对话怎么做？"),
]
print(llm.invoke(messages).content)

注意和 num_ctx 联动：历史越长越要留窗口余量，不然系统提示词先被截掉。

模型怎么选

7B 量级（DeepSeek R1 7B）是本地开发的主力：加载快、响应快，翻译、问答、简单代码生成都够用。百亿级模型推理能力强，但加载慢、延迟高，普通显卡跑起来卡顿明显，日常调试不值得。结论简单：先用 7B 把流程跑顺，真遇到 7B 明显办不了的任务再换大模型，别一上来就堆参数。

验收标准

一条链路验完算通关：uv add langchain-ollama 装好 → curl api/tags 服务通 → invoke 返回正常 → stream 打字机正常 → 多轮对话记住上文 → 把 num_ctx 从默认值调大后长对话不再丢上下文。五分钟能跑完，跑完这套，本地调用这条线基本不会再回头踩坑。