1. 为什么本地模型跑 Agent 任务和聊天完全是两码事很多人第一次把 OpenClaw 接到 Ollama 上用的还是平时聊天顺手的那几个模型结果发现 Agent 跑两步就卡住要么工具调用格式解析失败要么模型在思考环节绕圈子要么干脆把 JSON 参数写成一坨自然语言。这不是 OpenClaw 的问题也不是 Ollama 的问题而是聊天模型和 Agent 模型的能力侧重点根本不同。聊天场景下模型只需要把话说通顺、把知识答对输出是给人看的。Agent 场景下模型的输出是给程序解析的——它必须稳定地吐出结构化的工具调用请求必须理解多轮工具返回结果并决定下一步必须在长上下文里记住自己已经做过什么、还差什么。这两件事对模型的要求差异极大。我拿一个真实例子说明。同样一句帮我查一下北京今天的天气如果下雨就提醒我带伞聊天模型会直接编一段天气描述给你而 Agent 模型需要先输出一个get_weather(city北京)的工具调用等工具返回结果后再判断是否要触发remind动作。中间任何一步格式错了整条链路就断了。所以选本地模型跑 OpenClaw核心看三个指标工具调用Tool Calling的格式稳定性能不能稳定输出符合 schema 的 JSON而不是时好时坏。多步推理的收敛性给它一个需要 3 到 5 步才能完成的任务它会不会中途忘记目标或者陷入循环。上下文窗口与指令遵循Agent 的 system prompt 通常很长工具定义也占大量 token模型得在长上下文里依然听话。下面这张表是我实测下来不同参数量级模型在 Agent 任务上的大致表现分档先给个整体印象参数量级工具调用稳定性多步推理适合场景3B 以下差格式经常崩基本不可用只适合纯文本补全7B-9B中等简单单步工具可用弱2 步以上易乱轻量单工具 Agent14B-32B良好多工具切换稳定中等3-5 步可收敛主力 Agent 任务70B 及以上优秀强复杂多步 Agent这个分档不是绝对的后面会讲为什么有些 7B 模型能吊打某些 14B 模型——训练时有没有专门做工具调用微调比参数量更重要。2. 2026 年值得放进 OpenClaw 的本地模型清单这一节直接给结论每个模型我都会说清楚它的定位、实测表现和适用边界。所有模型都可以通过 Ollama 直接拉取命令我会一并给出。2.1 Qwen3 系列目前 Agent 任务的第一梯队Qwen3 系列在 2026 年依然是本地 Agent 任务最稳的选择尤其是它的 instruct 版本对工具调用做了专门优化。我实测下来Qwen3-32B 在 OpenClaw 里跑多工具任务连续 20 轮工具调用没有出现一次格式错误这个稳定性在本地模型里相当罕见。ollama pull qwen3:32b ollama pull qwen3:14b ollama pull qwen3:8b选型建议很直接显存 24G 以上直接上qwen3:32b这是目前本地 Agent 的甜点型号。显存 12G-16G用qwen3:14b工具调用能力保留得不错多步推理稍弱但够用。显存 8G 以下qwen3:8b是底线再小就别指望跑 Agent 了。Qwen3 有个细节要注意它默认会输出思考过程thinking在 OpenClaw 里如果不关掉思考内容会混进工具调用解析里导致失败。需要在模型配置里显式关闭 thinking 模式或者用它的 non-thinking 变体。2.2 DeepSeek 系列推理强但工具调用要调教DeepSeek 的蒸馏版本在推理能力上很能打尤其是数学和逻辑链条长的任务。但它的原生工具调用格式和 OpenClaw 默认的解析器不完全兼容需要做一层适配。ollama pull deepseek-r1:14b ollama pull deepseek-r1:32b我在 OpenClaw 里接 DeepSeek 时踩过的坑它倾向于把工具调用写在思考过程里而不是输出成独立的 tool_calls 字段。解决办法是在 system prompt 里强制要求工具调用必须通过 function call 机制输出不要写在正文里并且把tool_choice设成required而不是auto。DeepSeek 适合什么场景适合那种需要模型先想清楚再动手的复杂任务比如多条件筛选、需要计算中间结果的 Agent。纯工具调用密集但推理简单的任务用 Qwen3 更省心。2.3 Llama 3.3 系列生态最广但 Agent 能力中规中矩Llama 3.3 的优势是生态成熟、各种量化版本齐全、社区支持好。但纯从 Agent 任务角度看它的工具调用稳定性不如 Qwen3多步推理也不如 DeepSeek。ollama pull llama3.3:70b ollama pull llama3.1:8b70B 版本在显存够的情况下表现不错但 70B 对大多数本地部署来说门槛太高。8B 版本适合做轻量单工具 Agent比如只做文件读写或者只做网页抓取这种单一职责的任务。我的建议是如果你已经在用 Llama 生态继续用没问题如果是新搭 OpenClaw优先考虑 Qwen3。2.4 Mistral 与 MixtralMoE 架构的性价比之选Mixtral 的 MoE 架构让它在推理时只激活部分参数所以 8x7B 的模型实际推理成本接近 13B 左右但能力接近更大的模型。这对显存有限但又想要较强能力的场景很友好。ollama pull mixtral:8x7b ollama pull mistral:7bMixtral 在工具调用上表现中等偏上格式基本稳定但偶尔会在复杂 schema 上出错。适合中等复杂度的 Agent 任务。2.5 专用小模型Phi 与 Gemma 的定位Phi 和 Gemma 系列主打小体积但在 Agent 任务上我不太推荐作为主力。它们的工具调用能力在 2026 年虽然有进步但和 Qwen3 同参数量级比还是有差距。ollama pull phi4:14b ollama pull gemma3:12b如果只是做非常简单的单步工具调用比如读一个文件然后返回内容这些小模型也能凑合。但一旦涉及多工具、多步骤就容易出问题。2.6 一张表看清各模型定位模型推荐型号工具调用多步推理显存门槛最佳场景Qwen332b/14b/8b优秀良好8G-24G通用 Agent 主力DeepSeekr1:32b/14b中等需适配优秀12G-24G推理密集型 AgentLlama 3.370b/8b中等中等8G-48G生态兼容场景Mixtral8x7b中等偏上中等16G性价比 MoEPhi/Gemma14b/12b中等弱8G-12G轻量单工具3. 在 OpenClaw 里接 Ollama 的完整配置链路模型选好了接下来是怎么把它接进 OpenClaw。这一步的坑比选模型还多我按实际操作顺序拆开讲。3.1 Ollama 服务端的几个关键设置默认安装的 Ollama 只监听本地回环地址OpenClaw 如果跑在容器里或者另一台机器上就连不上。需要改环境变量# Linux/macOS export OLLAMA_HOST0.0.0.0:11434 export OLLAMA_KEEP_ALIVE24h export OLLAMA_NUM_PARALLEL2OLLAMA_KEEP_ALIVE这个参数特别重要。默认情况下 Ollama 加载的模型 5 分钟不用就卸载了Agent 任务经常有间隔一卸载再加载就要等十几秒。设成 24h 让模型常驻显存响应速度会稳定很多。OLLAMA_NUM_PARALLEL控制并发请求数。OpenClaw 如果同时发起多个工具调用这个值太小会排队。但也不能设太大否则显存爆掉。一般设成 2 到 4 比较稳妥。3.2 OpenClaw 侧的模型配置OpenClaw 的模型配置通常在一个 YAML 或 JSON 文件里核心是告诉它 Ollama 的地址、模型名和工具调用格式。一个典型的配置片段长这样model: provider: ollama base_url: http://127.0.0.1:11434 name: qwen3:32b context_window: 32768 tool_calling: enabled: true format: openai parallel: true generation: temperature: 0.1 top_p: 0.9 max_tokens: 4096几个参数的解释temperature 设 0.1Agent 任务要的是稳定不是创意。温度高了工具调用格式容易飘。context_window 要和模型实际能力对齐Qwen3-32B 支持 32K但如果你显存紧张可以降到 16K代价是长任务容易丢上下文。tool_calling.format 选 openaiOllama 现在兼容 OpenAI 的工具调用格式OpenClaw 大多也按这个格式解析对齐了最省事。3.3 工具调用格式不匹配的排查方法最常见的故障是模型明明输出了工具调用但 OpenClaw 说没有检测到工具调用。这通常是格式解析问题。排查步骤先看原始输出在 OpenClaw 里开 debug 日志把模型的原始返回打出来。看它是输出了tool_calls字段还是把调用写在了content里。确认 Ollama 版本老版本 Ollama 对工具调用的支持不完整升级到最新版。检查 system prompt有些模型需要明确的指令才会走 function call 通道prompt 里要写清楚。用 curl 直接测绕过 OpenClaw直接给 Ollama 发一个带 tools 定义的请求看返回格式。curl http://127.0.0.1:11434/api/chat -d { model: qwen3:32b, messages: [{role: user, content: 北京天气怎么样}], tools: [{ type: function, function: { name: get_weather, parameters: {type: object, properties: {city: {type: string}}} } }], stream: false }如果这个 curl 返回的message里有tool_calls说明模型和服务端都没问题问题在 OpenClaw 的解析层。如果没有那就是模型或 Ollama 版本的问题。3.4 显存不够时的量化选择本地部署绕不开显存问题。Ollama 默认拉的是 Q4_K_M 量化这个量化在 Agent 任务上表现还不错但如果你显存实在紧张可以选更激进的量化ollama pull qwen3:32b-q4_K_M # 默认约 20G 显存 ollama pull qwen3:32b-q3_K_M # 更省约 16G能力略降我的经验是量化到 Q4 是 Agent 任务的底线再往下Q3、Q2工具调用格式会明显不稳定得不偿失。宁可换小一号的模型也别用过低量化的同款模型。4. 实测中那些文档不会告诉你的坑这一节是我踩过的坑合集每一条都是真金白银换来的。4.1 思考模式是 Agent 任务的头号杀手Qwen3 和 DeepSeek 这类带思考模式的模型默认会先输出一大段思考内容再给结果。在聊天场景这是优点在 Agent 场景这是灾难——思考内容里的 JSON 片段会被解析器误抓导致工具调用参数错乱。解决办法有两个在 prompt 里明确关闭加一句不要输出思考过程直接给出工具调用。用 API 参数关闭Ollama 支持在请求里传think: false具体字段名看版本。我实测下来prompt 方式不是 100% 可靠模型有时候还是会忍不住思考。最稳的是 API 参数 prompt 双保险。4.2 上下文窗口设太大反而变慢很多人觉得上下文窗口越大越好直接拉满 128K。结果发现响应慢得离谱而且长上下文里模型反而更容易迷失。原因是上下文窗口越大KV cache 占的显存越多推理时注意力计算量也越大。对于 Agent 任务大部分场景 16K 到 32K 完全够用。设太大不仅慢还可能因为显存不足触发换页性能断崖式下跌。我的建议从 16K 起步不够再加。加的时候观察响应延迟一旦明显变慢就说明到瓶颈了。4.3 工具定义太多会稀释模型注意力OpenClaw 里如果注册了几十个工具全部塞进 system prompt模型的选择准确率会下降。这不是模型不行是信息过载。实际做法是按任务动态加载工具。比如当前任务是文件操作就只挂载文件相关的 3 到 5 个工具其他工具不放进上下文。OpenClaw 一般支持工具分组或者按需加载用起来。如果框架不支持动态加载那就手动精简工具描述把不常用的工具合并或者去掉。4.4 温度设 0 不一定最好理论上温度设 0 最稳定但实测下来某些模型在温度 0 时会陷入重复循环——反复输出同一个工具调用。这是因为贪心解码在遇到平局时会固定选同一个 token。我的经验值是0.1 到 0.2既保持稳定又避免死循环。如果发现模型开始重复先把温度往上调一点试试。4.5 模型加载慢和下载慢是两回事热词里有人问ollama 下载慢这通常是网络问题和模型本身无关。但模型加载慢是另一回事——那是从磁盘读进显存的时间。32B 的 Q4 模型加载一次大概要 10 到 30 秒取决于磁盘速度。解决办法就是前面说的OLLAMA_KEEP_ALIVE让模型常驻避免反复加载。如果显存够可以同时常驻多个模型OpenClaw 切换时就不用等。5. 不同硬件档位的推荐组合选模型最终要落到你的硬件上。我按常见档位给几套组合。5.1 消费级显卡 8G 显存这个档位选择有限qwen3:8b是首选。如果任务偏推理可以试deepseek-r1:8b但工具调用稳定性会差一些。配置要点上下文窗口设 8K并发设 1温度 0.1。别开太多工具控制在 5 个以内。5.2 消费级显卡 12G-16G 显存甜点档位。qwen3:14b是主力工具调用和多步推理都能打。如果偏推理任务deepseek-r1:14b也可以。配置要点上下文 16K并发 2可以挂载 10 个左右的工具。5.3 消费级显卡 24G 显存qwen3:32b直接上这是目前本地 Agent 的最优解。上下文可以开到 32K并发 2 到 3。如果显存还有余量可以同时常驻一个 8B 的小模型做简单任务大模型留给复杂任务OpenClaw 按任务复杂度路由。5.4 多卡或专业卡 48G 以上可以上llama3.3:70b或者qwen3:32b的高精度版本。这个档位基本不用纠结能力都够。配置要点上下文可以开到 64K 甚至更高并发 4。但要注意上下文越大延迟越高Agent 任务对延迟敏感别盲目拉满。5.5 一张表总结硬件与模型匹配显存推荐模型上下文并发工具数上限8Gqwen3:8b8K1512G-16Gqwen3:14b16K21024Gqwen3:32b32K2-32048Gqwen3:32b 高精度 / llama3.3:70b64K4不限6. 让 Agent 跑得更稳的几个调优技巧模型和硬件定了之后还有一些调优空间能让同样的配置跑出更好的效果。6.1 system prompt 的写法直接影响工具调用成功率Agent 的 system prompt 不是随便写写。我总结了几条工具调用指令要放在最前面不要埋在长 prompt 中间模型对开头的注意力最强。明确输出格式写清楚工具调用必须通过 function call 输出不要在正文里描述。给一两个示例few-shot 对工具调用格式的稳定性提升很明显尤其是小模型。限制思考长度如果模型必须思考加一句思考不超过 50 字。6.2 工具返回结果要精简工具返回的内容会进上下文如果返回一大坨原始数据会挤占上下文还干扰模型判断。做法是在工具层做预处理只返回模型需要的关键字段。比如查天气的工具返回{temp: 25, rain: false}就够了不用把整个天气 API 的响应塞进去。6.3 失败重试要带上下文Agent 任务失败时直接重试往往还是失败。更好的做法是把失败原因和上一次的输出一起塞回给模型让它知道哪里错了。比如工具调用参数格式错了重试时告诉它上次输出不是合法 JSON请重新输出。这样模型有机会自我修正。6.4 监控工具调用成功率跑一段时间后统计一下工具调用的成功率。如果低于 90%说明模型或者配置有问题需要调。这个指标比感觉还行靠谱得多。OpenClaw 一般有日志可以写个脚本统计tool_calls解析成功和失败的比例。低于 90% 就考虑换模型或者调 prompt。7. 关于模型迭代和长期维护的一点个人看法本地模型迭代很快2026 年好用的模型可能半年后就有更好的替代。我的做法是不追新但保持关注。具体来说主力模型选定后除非遇到明显的能力瓶颈否则不轻易换。因为换模型意味着重新调 prompt、重新测工具调用稳定性成本不低。但每隔一两个月会拿新出的模型跑一遍标准测试集看看有没有明显提升。另外模型配置要版本化。把 OpenClaw 的模型配置、prompt、工具定义都放进版本控制换模型时能快速回滚。我吃过这个亏——调了半天发现还不如原来的配置结果原来的配置没存只能重来。最后说个实际体会本地跑 Agent稳定性比能力上限更重要。一个 14B 但工具调用 100% 稳定的模型比一个 32B 但时不时格式崩的模型好用得多。选型时别只看 benchmark 分数一定要拿自己的实际任务跑一遍看它在你的场景里稳不稳。