openclaw 配置 本地 ollama

本地已经用 Ollama 拉好了模型，想把 OpenClaw 指过去用，结果卡在「填什么地址」「模型名写哪个」「填完连不上」这几步——这是最常见的情况。这篇不谈概念，只给一条能照着走的配置路径：先确认 Ollama 服务本身能被访问，再决定 OpenClaw 那边填什么，最后按症状定位是端口、模型名还是上下文长度的问题。

第一步：先把 Ollama 这一头弄成「别人能连」的状态

这一步的目标很朴素：让 Ollama 不再是「只有我自己这台机器上的浏览器能访问」的状态。判断标准是你换一台机器、或者从容器里发起请求，能不能拿到正常响应。拿不到，后面接 OpenClaw 时你会在「网络不通」和「配置写错」之间反复横跳，排查成本翻倍。

1. 确认服务在跑在跑 Ollama 的机器上执行进程和监听检查，看到对应进程和监听端口才算活着；命令报错或没输出就先解决启动问题，别往下走。
2. 确认监听地址重点看监听的是回环地址还是全部地址。只绑回环时，本机能用，别的机器和容器一律连不上，这是最常见的翻车点。
3. 放开到外部可达改成监听全部地址后重启服务，再从另一台机器或容器里请求一次接口；能返回模型列表或正常 JSON，才说明这一头通了。
4. 别凭记忆填地址接口默认形态、端口号、以及 /v1 与原生接口两条路子怎么写，各版本和部署方式都有差异，去站内页面核对当时的写法，别拿印象当配置。
5. 先跑通一次对话把要用的模型先拉下来，用命令行或接口直接发一条对话请求，确认能出结果。模型没跑通就接 OpenClaw，故障点会混在一起，很难分清是谁的问题。

• 先证明「服务活着」，再证明「外面能进来」，最后才证明「模型能答话」，顺序别乱
• 每一步都用一次真实请求验证，不要只看配置文件就认为成功
• 改完监听地址一定要重启服务，配置不生效时先怀疑没重启
• 把接口地址、端口、路径写法抄进一个临时笔记，后面接 OpenClaw 时直接复用，减少手抄错

第三步：连通之后先验证，再调参数

配好 openclaw 指向本地 ollama 之后，别急着改一堆参数。先拿最短的输入发一次请求，看返回长什么样。三类结果对应三条完全不同的排查线，先分清是哪一类，能省掉大半无效折腾。

1. 发一次最短请求用一句最普通的问句，别带长上下文、别带系统提示，看它能不能给出完整回答。
2. 判断属于哪一类对照上面的表。空内容和报错别混着查，前者偏配置与模板，后者偏连接与参数。
3. 再把延迟量一次链路通了之后马上测一次响应时间，记下来作为你自己的基线。以后觉得慢或快，都跟这个数比，别跟别人贴的数字比，机器不一样没有可比性。

进入调参只剩两项值得动：上下文长度和超时时间。这两项要按你本机显存和所跑模型的大小来定，没有一个通用值。可以先从偏保守的值起步，跑通了再往上加，别一上来就拉满。

• 上下文设太大：长对话里容易被截断，或者请求直接超时，表现为聊到一半突然断掉
• 上下文设太小：短问答没事，稍长一点的任务立刻报错，像是模型「记不住」前文
• 超时设太短：本地推理本来就慢，正常回答也会被当成失败
• 超时设太长：真出问题时你要等很久才拿到结果，排障效率低
• 判断标准：调完再跑一遍同样的最短请求，确认返回依然完整，再拿新延迟和基线比

先分清返回是完整、空还是报错，再动参数；延迟只跟自己上一次比。

连不上时按这个顺序查，别乱试

连不上别急着改配置，按从外到内的顺序排查，能省掉一大堆瞎试。顺序是：先确认 Ollama 服务本身能不能被访问，再看 OpenClaw 里填的地址对不对，最后才去怀疑模型名写错了。很多人一上来就翻模型名，结果折腾半天发现是服务根本没起来。

1. 第一步：直接打接口在浏览器打开本机 Ollama 的默认服务地址，或在命令行用 curl 请求它的模型列表接口。能返回列表就说明服务活着；连不上就先解决服务启动问题，别动 OpenClaw。
2. 第二步：确认网络可达范围服务只监听本机回环地址时，别的机器访问不到。如果 OpenClaw 跑在另一台机器或另一个网络命名空间里，需要让 Ollama 监听对外可访问的地址，并确认防火墙放行。
3. 第三步：核对 OpenClaw 里的地址写法注意协议、主机名、端口和结尾斜杠是否和服务实际一致。地址末尾多一个斜杠、端口写错、把 https 写成 http，都会让请求直接失败。
4. 第四步：最后才查模型名模型名要和本地实际拉取的名字完全一致，大小写和标签后缀都算。名字对不上时通常报的是找不到模型，而不是连不上，可以先按报错类型区分。

容器、WSL、远程开发这几类场景要特别当心：这些环境里的 localhost 指的是它自己，不是你的宿主机。配置里写 localhost，请求就发到了容器内部，而 Ollama 根本不在那儿，所以必然连不上。这一类问题在实际排查里占了大头，先怀疑它准没错。

• 接口通了但对话没反应，先看服务日志是不是在加载模型
• 资源不够时进程可能被系统直接杀掉，日志里会有中断痕迹
• 换一个更小的量化版本能快速验证是不是资源问题
• 确认服务是常驻运行，还是被手动启动后就关了

如果换了更小的量化版本就能正常对话，基本可以确认是资源或加载相关的问题，而不是配置错误。反过来，换了小模型还是连不上，就回到前面的地址和网络排查。具体到某个部署方式该怎么填地址，可以到站内的工具目录和指南中心翻对应的排查条目核对。