企业官网建设流程全解析

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 任务上的大致表现分档，先给个整体印象：

这个分档不是绝对的，后面会讲为什么有些 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:8b

70B 版本在显存够的情况下表现不错，但 70B 对大多数本地部署来说门槛太高。8B 版本适合做轻量单工具 Agent，比如只做文件读写或者只做网页抓取这种单一职责的任务。

我的建议是：如果你已经在用 Llama 生态，继续用没问题；如果是新搭 OpenClaw，优先考虑 Qwen3。

2.4 Mistral 与 Mixtral：MoE 架构的性价比之选

Mixtral 的 MoE 架构让它在推理时只激活部分参数，所以 8x7B 的模型实际推理成本接近 13B 左右，但能力接近更大的模型。这对显存有限但又想要较强能力的场景很友好。

ollama pull mixtral:8x7b ollama pull mistral:7b

Mixtral 在工具调用上表现中等偏上，格式基本稳定，但偶尔会在复杂 schema 上出错。适合中等复杂度的 Agent 任务。

2.5 专用小模型：Phi 与 Gemma 的定位

Phi 和 Gemma 系列主打小体积，但在 Agent 任务上我不太推荐作为主力。它们的工具调用能力在 2026 年虽然有进步，但和 Qwen3 同参数量级比还是有差距。

ollama pull phi4:14b ollama pull gemma3:12b

如果只是做非常简单的单步工具调用，比如"读一个文件然后返回内容"，这些小模型也能凑合。但一旦涉及多工具、多步骤，就容易出问题。

2.6 一张表看清各模型定位

3. 在 OpenClaw 里接 Ollama 的完整配置链路

模型选好了，接下来是怎么把它接进 OpenClaw。这一步的坑比选模型还多，我按实际操作顺序拆开讲。

3.1 Ollama 服务端的几个关键设置

默认安装的 Ollama 只监听本地回环地址，OpenClaw 如果跑在容器里或者另一台机器上就连不上。需要改环境变量：

# Linux/macOS export OLLAMA_HOST=0.0.0.0:11434 export OLLAMA_KEEP_ALIVE=24h export OLLAMA_NUM_PARALLEL=2

OLLAMA_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.1：Agent 任务要的是稳定，不是创意。温度高了工具调用格式容易飘。
• context_window 要和模型实际能力对齐：Qwen3-32B 支持 32K，但如果你显存紧张，可以降到 16K，代价是长任务容易丢上下文。
• tool_calling.format 选 openai：Ollama 现在兼容 OpenAI 的工具调用格式，OpenClaw 大多也按这个格式解析，对齐了最省事。

3.3 工具调用格式不匹配的排查方法

最常见的故障是：模型明明输出了工具调用，但 OpenClaw 说"没有检测到工具调用"。这通常是格式解析问题。排查步骤：

1. 先看原始输出：在 OpenClaw 里开 debug 日志，把模型的原始返回打出来。看它是输出了tool_calls字段，还是把调用写在了content里。
2. 确认 Ollama 版本：老版本 Ollama 对工具调用的支持不完整，升级到最新版。
3. 检查 system prompt：有些模型需要明确的指令才会走 function call 通道，prompt 里要写清楚。
4. 用 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 一张表总结硬件与模型匹配

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 分数，一定要拿自己的实际任务跑一遍，看它在你的场景里稳不稳。