本地模型跑起来了，但想让智能体真正调用它，卡点通常不在模型本身，而在「谁去连谁」：Ollama 是推理服务，OpenClaw 是消费方，中间隔着地址、模型名和工具权限三件事。这篇按「先跑通一次对话、再放开工具调用」的顺序给一份配置清单，并说明什么机器、什么场景下不该走这条路。
本地模型跑起来了，但想让智能体真正调用它，卡点通常不在模型本身，而在「谁去连谁」：Ollama 是推理服务，OpenClaw 是消费方，中间隔着地址、模型名和工具权限三件事。这篇按「先跑通一次对话、再放开工具调用」的顺序给一份配置清单，并说明什么机器、什么场景下不该走这条路。
建议把它当成分层调试：先让模型侧独立可用，再让智能体侧独立跑起来，最后才把两者接上。任何一步没验证就往下走，出问题时你会同时怀疑三个地方，排查成本翻倍。下面每一节都只改动一个变量，改完立刻复验。
先分清谁负责什么，别一上来就改配置
Ollama 只干一件事：把模型加载起来，并通过本地接口把推理能力暴露出去。它不做任务编排、不记得你的目标、也不持有任何工具权限。真正发起任务、决定什么时候调哪个工具、把结果拼起来的那一方，是 OpenClaw。把这两个角色的边界认清，你就知道配置改动该落在哪一侧。
- Ollama
- 推理服务端，负责加载模型并对本地暴露接口，不关心任务是什么
- OpenClaw
- 智能体侧，负责理解任务、选择工具、发起调用，是主动连接的一方
- 接口地址
- OpenClaw 用来找到 Ollama 的入口，写错或监听范围不对就是连不上
- 模型名
- 请求里带的模型标识，必须和本地已拉取的名字完全一致
- 配置前先确认模型能单独对话成功，这一步绕过智能体，直接测推理服务
- 再确认 OpenClaw 在不接本地模型的条件下能正常起来，确认它自身没有环境问题
- 不适用的情况：如果只是想找个对话框聊天，直接接现成的对话前端就够了，套一层智能体只是多一层出错面
- 把「模型不通」和「智能体不通」当成两个独立故障来验证，这是后面所有排查的前提
配置顺序：地址、模型名、上下文，一条条对
配置项看着多，其实有固定顺序。顺序错了，报错信息会互相掩盖。按地址、模型名、上下文预算三步走，每一步改完只做一次最简单轮对话复验，能通再进入下一步。下面这张表把每步的改动点和典型现象对应起来。
| 配置项 | 改什么 | 填错时的典型现象 |
|---|---|---|
| 接口地址 | 监听范围与访问地址要匹配 OpenClaw 所在环境 | 连接被拒绝，而不是模型侧报错 |
| 模型名 | 与本地已拉取的名字逐字符对齐 | 报错常常伪装成服务不可用 |
| 上下文预算 | 往下压一档，再逐步加回 | 任务中途截断或直接失败 |
| 超时 | 按本地首字延迟放宽，别用接口模型的默认值 | 长任务被提前判定为失败 |
- 先定接口地址确认 Ollama 的监听范围是否覆盖 OpenClaw 所在环境；不同机或跑在容器里时，回环地址是访问不到的，放开到可被访问的范围后再测一次连通性。
- 再定模型名把 OpenClaw 侧填的模型标识和本地已拉取的名字逐字符核对，大小写和标签后缀都算数；改完发一条单轮请求验证。
- 最后调上下文与超时本地模型的上下文占用和首字延迟都比接口模型高，先把预算压小、超时放宽，跑通后再往上加，每次只加一档。
- 固化配置确认能用之后把参数写进配置文件而不是留在临时会话里，避免下次重启后现象复现却找不到原因。
有一点要提醒：本地推理本来就慢，慢和不通是两回事。很多被当成配置错误的场景，其实只是模型在小机器上冷启动。判断方法在最后一节。
机器和模型怎么搭才不白折腾
小主机这类设备（含 Mac mini 这类）的优势是静默、低功耗、可以常开，适合当家庭或小团队的常驻智能体后端。短板也明确：显存与内存是一体的，模型一大就挤占系统，整机响应变慢，连带智能体本身也变得迟钝。
选型不要凭感觉。模型规模要和可用显存或统一内存对齐，具体能跑到哪一档，去 /models/deploy 按你的机器规格算一遍再决定。同一台机器上既跑模型又跑智能体时，常驻加载和按需加载的取舍也要提前想清楚。
- 常驻加载：响应快，但内存一直被占着，适合每天都会用到的场景
- 按需加载：省资源，但每次任务都有一段冷启动等待，适合低频使用
- 需要多人同时用，或任务里频繁长文档解析时，小主机会成为瓶颈
- 这类需求更适合租卡或按量接口，判断边界可以参考 /self-host 里的方法
- 别在同一台机器上同时压满模型和智能体，留出系统余量比追求大模型更实用
放开工具调用前先收口权限
本地部署不等于自动安全。智能体默认可能带文件读写、命令执行、网络访问这类能力，一旦放开，它能碰到的范围就由你配的权限决定，而不是由「跑在自己机器上」这件事决定。放开之前先把范围收口。
| 能力 | 建议做法 | 原因 |
|---|---|---|
| 文件读取 | 限制在必要目录 | 覆盖大多数查询类需求，够用 |
| 文件写入 | 与读取目录分开配置 | 写坏东西的代价远高于读不到 |
| 命令执行 | 默认关闭，按任务临时开 | 不可逆操作风险最高 |
| 网络访问 | 按需放行特定目标 | 避免任务跑偏到无关请求 |
还有一点常被忽略：本地接口一旦放开到局域网可访问，同网段的其他设备就能直接调用你的模型。是否接受这一点要先想清楚，再去 /safety 对照合规与风险口径。任务跑完回看日志，确认它调用了哪些工具、访问了哪些路径，比事后猜可靠得多。
权限按「最小够用」给，需要再加；默认全开之后再收，通常已经出过事了。
连不上时的排查顺序
连不上不要乱改配置，按固定顺序往下走，每一步都缩小怀疑范围。下面五步覆盖了绝大多数本地智能体对接问题。
- 测服务本身绕过 OpenClaw，直接对本地接口发一次最简请求，确认模型侧没问题；接口地址与调用方式可对照 /official-api 里各家接口的通用形态理解。
- 测网络可达性从 OpenClaw 所在环境去访问模型地址，区分「本机能通、跨环境不通」这类情况，多半是监听地址或防火墙。
- 核对模型名与上下文参数确认名字逐字符一致，上下文预算没有超出模型实际承受范围。
- 看智能体自身日志检查超时设置与依赖是否齐全，这一步排的是智能体侧的问题，不是模型侧。
- 量一次延迟基线用 /tools/speed-test 测一次，把「慢」和「不通」分开——很多被当成故障的现象，其实是本地推理本来就慢。
- 先怀疑配置，再怀疑网络，最后才怀疑硬件
- 每改一个变量就复验一次，别一次改三处
- 把能通的最小请求保留下来，作为后续对比基准
- 报错文本要原样看，别用自己的理解替换掉
常见问题
Ollama 和 OpenClaw 是必须一起装吗？
不是。Ollama 是可替换的推理后端，你可以换成别的本地推理服务；OpenClaw 是可替换的智能体侧。两者只是通过接口对接，哪一端都能单独替换，配置时也建议分开验证，别把两个问题混在一起排查。
Mac mini 这类小主机适合当常驻智能体后端吗？
适合单人、低频、常开的场景，胜在安静省电、随时可用。不适合多人并发或频繁处理长文档的任务，这类负载会明显拖慢整机。具体能带多大的模型，按你的机器规格去 /models/deploy 算一遍比听结论靠谱。
配置好了但智能体总是超时，先改哪里？
先量延迟，再动参数。用 /tools/speed-test 测一次基线，确认本地推理本身的出字速度；如果慢是常态，就把智能体侧的超时和单次上下文预算往下压，减少一次任务里的工具往返次数，而不是一味调大超时。
