openclaw 本地 ollama config

你已经在本地拉起了 ollama，也想让 openclaw 走本地模型，但打开配置文件一看全是陌生字段，不知道哪一行对应模型、哪一行对应地址和上下文长度，改完还不生效。这篇按「先认字段、再调参数、最后排查」的顺序讲，只给你判断标准和可执行的改法，不讲榜单也不劝你怎么选模型；具体版本、价格、跑分这类会变的数字，一律让你去站内对应页面看当时的数。

本地 ollama 起来之后，很多人卡在 openclaw 的配置文件上：打开一看，地址、端口、模型名、上下文长度、温度全挤在一起，不知道哪行管什么，改完重启还不生效。这篇不讲模型怎么选、也不讲谁家便宜，只按「先认字段、再调参数、最后排查」的顺序，把这个配置文件拆成你能直接动手改的东西。参数能改成多少、模型标识长什么样这类会变的数字，都到站内对应页面核对你当下的情况。

先想清楚一件事：这个配置文件本质只在回答三个问题——请求发到哪、用哪个模型、这次请求怎么跑。其他字段基本都是围绕这三件事的补充。所以别一行行往下读，先归类，再动手，出错时也能快速缩小范围。

先认清配置文件里到底有哪几类字段

拿到配置文件先别改，用十几分钟把字段分个类。连接类管请求往哪发，模型类管用哪个模型和怎么生成，运行类管这个进程自己怎么活。分好类之后你会发现，多数报错其实只落在某一类里，排查范围一下小了一半。

连接类字段

服务地址、端口、协议等，决定请求发到哪一层；本机直连和容器内互访填的地址不一样，先确认 openclaw 自己跑在哪一层再填。

模型类字段

模型名或标签、上下文长度、温度、输出上限等，决定用哪个模型、怎么生成。

运行类字段

并发、超时、缓存与日志路径，决定这个客户端进程自己怎么跑，跟模型本身没关系。

三组里最容易错的是模型名。这里要填的是你本地模型清单里的那个名字，不是你印象里某个官网的模型名，两者经常长得像但拼写不一样。入手方式是直接从本地模型列表里复制粘贴，不要手打。命名规则和常见写法可以到 /models 对照着看。

连接地址也容易踩坑。openclaw 和本地服务在同一台机器上直连，和 openclaw 跑在容器里再去访问宿主机，用的地址完全是两回事。先把这个前提定下来，再决定端口那行写什么，否则你怎么改都是连不上。

• 先通读一遍，只做标注，不修改任何值
• 把每个字段归到连接、模型、运行三类里，拿不准的先放着
• 模型名一律从本地模型列表复制，不凭记忆手输
• 确认 openclaw 自己跑在本机还是容器里，再决定地址怎么写
• 把当前这份配置备份一份，改坏了能马上退回来

参数调整顺序：先跑通再调质量，别一上来就拉满

配置调参最常见的坏习惯，是第一次就同时改地址、改模型、改温度、改上下文长度，然后发现不生效，完全不知道是哪一处的问题。正确顺序是分层来：先把链路跑通，再谈质量，最后才谈细节手感。

1. 第一轮：只保证能通采样类参数全部保持默认，模型名、地址、端口填成当前最可能对的一组，发一次最简单的请求。只要有一次正常返回，就说明链路是通的，后面所有调整都建立在这个基础上。
2. 第二轮：调上下文长度上下文长度和本地显存是此消彼长的关系，开太大可能直接爆显存或者明显变慢。从小往大逐步加，每加一档就发一次稍长的请求，观察是不是开始掉速、截断或者报内存相关错误。
3. 第三轮：才碰温度和输出上限抽取、归纳这类任务和创意写作要的取值方向不一样，没有万能值。一次只改一个字段，改完记下前后差异，别三个字段一起动，否则你分不清是哪个起了作用。

如果你不确定某个参数在别的项目里是什么含义，别按记忆填，先去 /ai-dict 把名词看懂再动。参数名字像不代表语义一样，尤其是不同客户端对同一个名字的解释经常有偏差。

改完怎么确认生效：三条验证动作

改完保存、重启，并不等于新配置已经在起作用。很多人是「以为生效了」，实际上请求走了别的地方。下面三个动作按顺序做，基本能确认这次改动到底有没有落到实际上。

固定问题这一点很多人忽略：每次都问同一句话，你才有可比的基准。今天问天气、明天问代码，风格和速度都没法横向比，验证就变成了感觉。响应延迟可以到 /tools/speed-test 量一次做基线，之后每次改配置都拿同一个基线对照。

• 保存配置后完整重启客户端，别只刷新页面
• 本地服务日志窗口保持打开，改完立刻发请求看有没有进来
• 同一问题、同一长度，前后各测一次延迟做对比
• 确认没有回落到其它通道：日志里只有本地这一条记录才算数
• 把这次改动的字段和现象记一行，下次出问题能往前翻

不生效的排查顺序：从外到内一层层收

配置不生效时，大多数人第一反应是怀疑配置格式写错了，然后反复检查缩进和引号。实际上顺序反了。应该从最外层往里收：服务在不在、地址通不通、模型名对不对、参数会不会超限。一层确认完再进下一层，比一上来钻进格式里快得多。

1. 确认服务在不在本地服务有没有真的起来，是不是只监听在回环地址上。只监听回环的话，别的机器或容器根本连不到。绑定地址这类名词先去 /ai-dict/category/infra 看懂再查。
2. 确认地址通不通跨机器、跨容器最常见的失败点是监听范围和防火墙。先用最直接的方式从 openclaw 所在那一层去连一下，连不通报错就是网络层，别继续往下改模型参数。
3. 确认模型名对不对典型表现是请求有响应但内容不对，或者直接报找不到模型。回去本地模型列表复制一遍名字，注意标签后缀，别用记忆里的名字。
4. 确认参数会不会超限链路都通了但请求失败或中断，多半是上下文长度、输出上限这类值超出了本地服务能承受的范围。回调到小一档再试，逐步往回收。

还有一类失败不是配置问题，而是链路本身走了别的地方。排查时顺手确认一下有没有出现回落：日志里只有你以为的那一条记录，才说明配置真的生效了。如果配置里同时存在多条可用通道，优先级和回落规则要看清楚，不然你改的那条可能根本没被用上。

最后提醒一句：这套字段名和默认值会随版本变化，别把今天记住的写法当成永远正确的。真正要记住的是判断顺序——服务、地址、模型、参数，以及验证动作——固定问题、看日志、测延迟。