ollama + 本地模型+openclaw（先分清 Ollama 和 Cla）

你在本地用 Ollama 跑通了模型，聊天也正常，但一换成 Claw 这类智能体工具就报错、卡住或者只会胡说。问题多半不在模型本身，而在接口格式、上下文长度、工具调用能力和权限边界这几处没对齐。这篇按排查顺序给一套可执行动作：先确认 Ollama 对外暴露的接口能被工具认出来，再按显存和任务挑量化档位，最后把读写范围收紧。给的是判断标准，不是一键脚本。

你在本地用 Ollama 把模型跑起来了，聊天也正常，但一换成 Claw 这类智能体工具就报错、卡住，或者干脆只会胡说。问题八成不在模型本身，而在接口格式、上下文长度、工具调用能力和权限边界这几处没对齐。下面按排查顺序给一套可执行动作，先确认 Ollama 对外暴露的接口能被工具认出来，再按显存和任务挑量化档位，最后把读写范围收紧。

这篇给的是判断标准，不是一键脚本。因为本地智能体的坑千变万化，给你脚本你也不会改。真正省时间的是知道「哪一步该先查、哪一步不该动」，这样出问题了能定位，而不是把模型、参数、工具配置一起乱改。

先分清 Ollama 和 Claw 类工具各管哪一段

Ollama 管的是模型加载、量化推理和本地 HTTP 接口，它不负责拆任务、记多轮上下文、调外部工具。Claw 类工具管的是规划、工具调用、文件读写和会话状态。两边靠一个接口协议对接，接口对不上就表现为「模型没反应」而不是抛异常，这是最容易误判成模型弱的地方。

Ollama

模型服务和推理层，对外暴露本地接口，不关心你的任务怎么拆

Claw 类工具

智能体层，负责规划、调工具、读写文件、维护会话状态

接口协议

两层的黏合剂，格式、路径、参数名对不上就表现为卡死或空返回

• 先在纯对话界面确认模型能正常出字，再换到智能体工具，这样能把「模型问题」和「接入问题」分开，不然两边一起改会越改越乱
• 如果工具报的是连接类错误，先怀疑服务没起或地址错；如果是工具死活不触发，先怀疑模型输出格式飘，这两类先分清楚再动手
• 只做单轮问答、不需要读文件或跑命令的场景，直接调 Ollama 的接口就够了，套一层智能体工具反而多一个故障面

接口格式对齐：工具认不认这套 API

Claw 类工具一般走 OpenAI 兼容格式，Ollama 既有原生接口也有兼容层。先确认工具配置里填的 base URL 和路径要不要带版本段，路径少一段就是 404 或一直转圈。这些细节不要靠猜，命令行先验一遍最省事。

1. 第一步：确认服务在跑直接请求一次模型列表，能返回本地实际拉下来的模型名就算通。返回空列表也要当失败处理，说明路径不对。
2. 第二步：跑一次对话补全用同样的地址请求一次补全，确认能返回内容。这一步过了，说明模型和推理没问题。
3. 第三步：再填进工具拿着验证过的地址去工具里配。跨过前两步直接配工具，出错了根本没法判断是模型、服务还是工具的问题。
4. 第四步：核对模型名工具里的模型名要跟本地实际拉下来的名字完全一致，不要用工具默认示例里的名字，这是最常见的「明明服务通却没反应」。

端点怎么拼、参数怎么映射，这类具体信息不用背，到站内 本地部署 ollama 服务的 api 地址 和 ollama 的 api 端点 两页核对一遍就行，路径和示例都有。连不上、超时、返回空这三类错误对应的排查方向不一样，先看 连接 ollama api 失败 里的分类再动手，别一上来就重装。

模型与量化档位：按显存和任务反推，不按参数大小

本地智能体比纯聊天更吃显存，因为它要保留更长的上下文，可能还要加载重排或多模态组件。同参数量下，智能体场景的可用档位通常比聊天场景低一档。挑档位的顺序是：先看显存余量，再决定量化精度，最后才在同等显存能装的模型里比能力。

• 先量显存余量，别照着模型的宣传参数直接拉，装不进去再换很浪费时间
• 一次任务要读十几个文件、来回几十轮时，上下文窗口和稳定的工具调用格式比单轮回答质量更关键
• 参数小一点但指令遵循好的模型，常常比参数大但老是格式跑偏的模型好用
• 任务很短、只做单次改写或翻译，就没必要为了智能体牺牲量化精度，按聊天档位选就行
• 显存和上下文的折算用站内 部署测算 和 几张卡够用：按模型算一遍 过一遍数字，别凭感觉

有个容易忽略的点：量化精度下降最先影响的往往不是聊天流畅度，而是格式稳定性。聊天里多错几个字你看不出来，智能体里参数解析失败一次就断链。所以拿智能体用的时候，宁可小一号模型也别把精度压太狠。至于当前各家模型的具体参数和对应硬件，站内资料库更新得快，去 模型资料库 看当时的数字，这里不写死。

工具调用能力：这是成败分界线

智能体工具依赖模型按固定格式输出「调用哪个工具、传什么参数」。有的本地模型能聊天但输出格式飘，表现就是工具永远不被触发，或者参数解析失败反复重试。这条线不过，前面调得再顺也白搭。

1. 给个极简任务只放两个工具、每个工具参数只有一两个字段，看模型能不能稳定触发，连续跑几次都要一致。
2. 稳定后加复杂度一次加一个工具或一个必填参数，每次都重新验证稳定性，一步到位上多工具必翻车。
3. 两条兜底路一是换指令遵循更强的小模型专门干调度；二是把工具描述写得更死板、参数更少。后者成本低但上限也低。

还有个本地特有的坑：会话保持跟云端不一样。进程重启、模型重载都可能丢上下文，长任务要确认工具的会话是存在磁盘还是内存里。存在内存里的，你重启一次服务，任务目标就没了，模型后面全在瞎猜。

上下文与记忆：本地智能体最容易崩的地方

智能体一轮任务会吃掉大量上下文：系统提示、工具定义、历史步骤、文件内容都算在内。聊天时够用的窗口长度，换成智能体可能几步就满了。满了之后的典型症状是模型开始忘记最早的任务目标、重复同一步操作，或者把以前的文件内容当成当前内容。

看到这三种表现先怀疑上下文，而不是急着换模型。处理顺序是：先压缩工具返回内容（只回传必要片段），再考虑缩短历史，最后才是加长窗口。加窗口直接吃显存，是最贵的一招。反过来，任务是单步、只看一个文件，就不用折腾压缩策略，加了反而让模型拿不到完整信息。

权限收敛：给智能体的手划边界

智能体能读写文件、跑命令，本地跑并不等于安全。第一步就是把工作目录限定在一个专门的沙箱目录，别让它在整个磁盘上乱翻。做完这层隔离，再谈提效。

• 限定可访问目录，工作区之外一律拒绝
• 禁用危险命令，尤其是删除和批量覆盖类操作
• 对外部网络访问单独开关，默认关，需要时再开
• 重要文件先备份或纳入版本管理，跑批前后各对一次
• 四件事做完再谈提效，顺序别颠倒

判断标准很简单：如果这个任务你不敢让它自动执行、必须每步确认，那就不适合做全自动智能体，做成人确认后再执行更现实。本地跑还有个隐性成本是跑批时的电费和机器占用，长时间挂任务前先想清楚这台机器还要不要干别的。

跑通之后怎么验证和调优

跑通一次不代表能用。准备 5 到 10 个真实任务做回归，每次都记录：能不能完成、花了几步、有没有触发工具、有没有把中间结果弄错。不要只看单次能不能跑通，智能体的问题是概率性的，跑一次成功说明不了什么。

大部分「模型不行」最后是提示和工具设计的问题。速度慢先量基线再优化，用 接口测速：先量出你的延迟基线 看瓶颈在模型推理还是在工具等待。本地输出慢的常见原因和排查顺序，参考 为什么本地部署大模型输出特别慢 里的思路，别一慢就换模型。

什么情况下别折腾本地这套

这条得说清楚，不然很多人会在不合适的场景里死磕。任务对稳定性要求高、且允许数据出内网，直接用云端接口省事得多，本地智能体的维护成本主要在模型和工具版本对不上的时候，改一处崩一处。

• 硬件余量本来就不大，又想跑大参数模型又想做智能体，通常两头都不讨好，先决定保模型能力还是保流程
• 团队里没人愿意维护本地环境（模型更新、依赖冲突、路径问题），本地部署会很快变成没人管的烂摊子
• 任务必须每步人工确认的高风险操作，全自动智能体本来就不合适
• 判断标准就一条：本地跑是为了数据不出门，还是为了控制成本。目的不同，选型完全不一样

如果是出于成本考虑，先把租卡和调用的账算清楚再决定，站内的 价格追踪 和 中转站导航 能帮你对照当时的数字，别凭一两次感觉就下结论。判断类的事没有绝对答案，什么情况下不适用，上面几段已经说清楚了。