1. OpenClaw 与 Ollama：本地 Agent 任务的成本账

日志摘要、JSON 清理、消息路由、Cron 报告，OpenClaw 跑的大部分请求其实都是这类 Agent 粘合任务。全走云端时，token 成本按天累计很难看；全交给本地 Ollama 时，多步骤推理又容易空谈或超时。更实用的做法是混合路由：默认 Agent 用 Ollama 免费处理高频小任务，deep-analysis 这类复杂 Agent 走云端；云端 Key 统一在 TaoToken 创建。这篇文章从 OpenClaw 连接 Ollama 的三种配置写起，接着在 OpenClaw 里增加一条 TaoToken 云端 provider，最后用四条命令完成整条混合链路的验证。

1.1 粘合任务占了大头，token 也占了大头

所谓“Agent 粘合任务”，指的不是那种需要深度思考的复杂推理，而是把各种小操作拼在一起：日志摘要、JSON 清理、消息路由、定时报告、简单脚本生成。它们的特点是一致的：单次请求 token 不多，但调用频率特别高。

以日志摘要为例，一个凌晨跑批的 Agent 可能要把几百行 error/warn 日志压缩成三条结论，每次消耗不过几千 token。但如果你在网关里长期跑着十几个这样的定时 Agent，一天下来就是成千上万次请求。云 API 的计费方式决定了“少量高频”比“大量低频”更难受，因为每一次请求都有固定开销和上下文重复计费。

把这类任务放到本地 Ollama，权重下载到磁盘后，模型完全离线运行，提示词不会离开你的网络，请求费用直接归零。这不是为了省一两块钱，而是给一套长期运行的 Agent 基础设施去掉一块持续出血的成本。

1.2 本地模型的长板与短板

本地模型在以下场景里有明显优势：执行简单工具调用（运行命令、读取文件、解析输出）、格式转换、JSON 提取和清理、日志和工单摘要、消息路由与分类、常见语言的代码生成。这些任务对推理深度要求不高，但对响应速度和成本敏感，正好卡在 Ollama 的舒适区。

短板也同样明确：冗长的多步骤推理需要多个工具调用来回规划，本地小模型很容易在中间步骤绕路；当需要“完全按照这个格式输出、不能有一丝偏差”时，本地模型经常因为模型容量或量化精度丢格式；显存不够时，大上下文窗口会直接超限；部分多语言输出质量取决于你选的具体模型和量化等级。

如果盲目录入一个 7B 模型，什么任务都丢给它，你很快会得到一堆废话式回复。这不是 OpenClaw 配置错了，而是本地模型的天然能力边界。所以结论只有一个：把 OpenAI 兼容的云端 provider 保留在同一个 OpenClaw 实例里，按任务难度分流，而不是把所有 Agent 绑死在单一模型上。

2. 准备材料：TaoToken 的 Key 与 Ollama 的硬件底线

2.1 在 TaoToken 创建云端 API Key

在 OpenClaw 里接云端模型，你需要的不是一堆厂商控制台，而是一个统一 API 入口。打开 TaoToken，注册并登录后，进入控制台创建 API Key，复制得到的一长串字符串，放在本地临时文件里备用，它就是后面配置文件里的 YOUR_API_KEY。顺手看一眼模型广场，记下你要给 deep-analysis 用的模型 ID，不要凭记忆手写。

这里有两个容易踩混的地址：打开网页、创建 Key、查看用量，用的是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ；而填进 OpenClaw 的 baseUrl 是 https://taotoken.net/api ，末尾不要加 /v1。有些工具默认会在 Base URL 后面自动拼接 /v1，如果你手工再补一个，就会变成 https://taotoken.net/api/v1，直接 404。

TaoToken 的定位是统一 API 通道：不同模型收敛到同一个 Base URL、同一个 Key，切换模型时只改模型 ID，不用在几个厂商后台来回切。Ollama 那边的 apiKey 填一个假值都没关系，但 TaoToken 这边必须填真实 Key，因为云端调用要按 Key 记账。

2.2 Ollama 硬件底线：显存优先，RAM 和存储别省

8GB 显存足够跑许多量化后的 7B 模型；16GB 到 24GB 可以比较流畅地跑 14B 到 32B 模型；到 48GB 才开始有“大模型我想怎么跑就怎么跑”的感觉。显存比 GPU 的原始速度更重要，所以预算有限时优先买显存大的卡。

RAM 和存储也经常被忽视。Ollama 会把权重映射到内存中，长上下文操作会明显吃 CPU 和内存；模型文件动辄十几 GB，用机械硬盘冷启动会让人怀疑网关是不是卡死了。另一个值得提前开的设置是 OLLAMA_FLASH_ATTENTION=1，在长上下文场景下能降低内存压力，Ollama 的官方 FAQ 里也推荐了这个环境变量。

3. 安装 Ollama 并拉取第一批模型

3.1 macOS / Linux 安装与健康检查

macOS 用户直接 brew install ollama，然后 ollama serve &。Debian 或 Ubuntu 用户用官方安装脚本：

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama

安装后 Ollama 默认监听 11434 端口。验证是否在运行：

curl http://localhost:11434/api/tags

返回 JSON 数组说明服务已启动。如果返回空列表，说明还没有拉取任何模型，进程本身没问题。

3.2 Agent 场景下的起点模型

模型选择没有唯一的“正确答案”，但我可以提供一组在工具调用和 Agent 提示词上比较靠谱的起点：

• llama3.3：通用性好，适合日志摘要、消息路由、工单分类；
• qwen2.5-coder:32b：代码密集型任务，写脚本、分析堆栈、生成补丁；
• gpt-oss:20b：Agent 场景的不错中间值，工具调用格式比较规整；
• deepseek-r1:32b：如果你特别想要本地推理风格，但推理模型输出慢且长，适合放在 fallback 而不是默认。

拉取并做一次冒烟测试：

ollama pull gpt-oss:20b
ollama pull llama3.3
ollama run llama3.3 "Why does the sky look blue?"

能正常回答，说明 Ollama 没问题。之后 OpenClaw 出现任何异常，问题都出在配置、API 模式或工具权限上，而不是模型本身。

3.3 远程机器或 Docker 场景

Ollama 不一定要和 OpenClaw 装在同一台机器。常见做法是 OpenClaw 网关跑在一台小型常驻服务器上，Ollama 跑在局域网内的 GPU 机器上。这时只需要把后续配置里的 baseUrl 从 http://127.0.0.1:11434 改成类似 http://192.168.1.50:11434 的局域网地址。用 Docker 部署时，同样把 11434 端口映射出来，并在 OpenClaw 配置里指向宿主机的局域网 IP。需要提醒的是：局域网不等于可信网络，别把 Ollama 端口裸奔到公网，先加网络访问控制。

4. 将 OpenClaw 连接到 Ollama：三种配置与 API 模式选型

4.1 方式 A 与方式 B：快速启动和自动发现

方式 A 是 Ollama 提供的 OpenClaw 启动器：

ollama launch openclaw

如果只想生成配置但不启动网关：

ollama launch openclaw --config

这是最省事的路径，适合第一次跑通、想快速看效果的人。不过它生成的是默认配置，后续要混合云端 provider 时还是要手动改配置文件。

方式 B 是环境变量自动发现。OpenClaw 只要看到 OLLAMA_API_KEY 存在，就会启用 Ollama provider，至于值是什么，Ollama 本身不校验：

export OLLAMA_API_KEY="ollama-local"

或者用命令写入配置：

openclaw config set models.providers.ollama.apiKey "ollama-local"

然后把默认 Agent 模型指到 Ollama：

agents: {
  defaults: {
    model: {
      primary: "ollama/gpt-oss:20b"
    }
  }
}

方式 B 的好处是以后新增模型只需要 ollama pull 和 openclaw models list，模型的自动发现已经帮你处理了。

4.2 方式 C：显式 provider 配置，为混合路由留位置

方式 C 适合这些情况：Ollama 跑在别的机器上；你需要自定义上下文窗口；你希望显式声明模型而不是依赖自动发现；或者你准备增加第二个云端 provider。

models: {
  providers: {
    ollama: {
      baseUrl: "http://127.0.0.1:11434",
      apiKey: "ollama-local",
      api: "ollama",
      models: [
        {
          id: "gpt-oss:20b",
          name: "GPT-OSS 20B",
          reasoning: false,
          input: ["text"],
          cost: {
            input: 0,
            output: 0,
            cacheRead: 0,
            cacheWrite: 0
          },
          contextWindow: 65536,
          maxTokens: 65536
        }
      ]
    }
  }
}

注意这里的 cost 全部为 0，因为本地推理不产生 token 费用。contextWindow 要与 Ollama 启动参数对齐，别在配置里写 64k 实际服务端却只给 8k，否则 Agent 上下文一大就会异常。

方式 C 的代价是你会失去一部分自动发现便利：新拉取的模型不会自动出现在 OpenClaw 里，需要手动在 models 数组里补一条。但这一点完全值得，因为只有显式配置才能让你同时管理 Ollama 和 TaoToken 两个 provider。

4.3 API 模式选型：原生模式优先于 OpenAI 兼容

这是“程序跑起来但回复为空”最常见的原因。Ollama 提供两套 API：原生 /api/chat 和 OpenAI 兼容 /v1。OpenClaw 也分两套 provider 模式：api: "ollama" 和 api: "openai-completions"。

如果 Ollama 就在你本地，优先用原生模式：

api: "ollama"
baseUrl: "http://127.0.0.1:11434"

只有当你需要对接一个只提供 OpenAI 兼容端点的服务（比如后面要加的云端 provider）时，才用：

api: "openai-completions"
baseUrl: "http://127.0.0.1:11434/v1"

OpenClaw 自己还有一个 openai-responses 模式，专门用于 OpenAI 新版的 Responses API。这三者非常容易被混淆。在 Ollama 场景里，如果 OpenAI 兼容模式返回空响应或解析错误，切回原生模式通常立刻恢复正常。

5. deep-analysis 走云端：OpenClaw 的 TaoToken provider 配置

5.1 在 providers 里加入 taotoken 条目

如果你已经用方式 B 跑通了 Ollama 自动发现，要接云端时建议切到方式 C 的显式配置。把第 2 章创建的那把 Key 填进 taotoken provider：

models: {
  providers: {
    ollama: {
      baseUrl: "http://127.0.0.1:11434",
      apiKey: "ollama-local",
      api: "ollama"
    },
    taotoken: {
      baseUrl: "https://taotoken.net/api",
      apiKey: "YOUR_API_KEY",
      api: "openai-completions"
    }
  }
}

YOUR_API_KEY 替换成你在 TaoToken 控制台复制出来的真实 Key。Ollama 那边可以用 ollama-local 这种假值占位，TaoToken 这边不行，云端调用要靠它鉴权。

模型 ID 先写 YOUR_MODEL_ID 占位，实际配置时去 TaoToken 模型广场复制你要用的那个模型 ID。不要凭记忆填过时的模型名，模型广场显示什么 ID 就填什么 ID。还有一个细节：https://taotoken.net/api 这个 Base URL 不要加 /v1，也不要因为看到其他工具的教程就手滑在后面补 ?utm_source=... 这类参数，API 地址是工具用的，不是给人点的。

5.2 按 Agent 覆盖与 fallback 链实现混合路由

OpenClaw 支持按 Agent 覆盖模型，也支持在一条链里设置多个 fallback。两种写法可以组合使用。

先看按 Agent 覆盖：默认所有 Agent 走本地 Ollama，只有 deep-analysis 这类复杂 Agent 走 TaoToken 云端。

agents: {
  defaults: {
    model: {
      primary: "ollama/gpt-oss:20b"
    }
  },
  overrides: {
    "deep-analysis": {
      model: {
        primary: "taotoken/YOUR_MODEL_ID"
      }
    }
  }
}

再看 fallback 链：保持日常免费运行，同时给本地模型一个云端逃生舱，避免某个 Agent 因为本地模型能力不足而整体卡死。

agents: {
  defaults: {
    model: {
      primary: "ollama/llama3.3",
      fallbacks: ["ollama/qwen2.5-coder:32b", "taotoken/YOUR_MODEL_ID"]
    }
  }
}

两条链路的核心思路一致：本地模型处理 80% 的高频低价任务，云端模型兜底 20% 的高难度推理和长输出。TaoToken 在这里扮演的不是“某个单一模型”，而是一条统一的云端通道，你可以按任务随时切换模型 ID，不需要为每个云厂商重新配一遍 OpenClaw provider。

6. 上下文、工具权限与输出冗长：本地模型的调优三件事

6.1 上下文长度：64k 是参考线，不是所有模型的默认值

Agent 的系统提示、技能、记忆、聊天记录、工具输出都会占用同一个上下文窗口。上下文太小，Agent 会忘事，工具调用可能突然断裂。Ollama 官方建议 Agent 任务至少 64k token，但这个数字不是让你对所有模型无条件生效。8GB 显存跑 7B 模型时，64k 上下文很可能直接超限；16GB 以上跑 20B 才比较可行。

你可以通过环境变量在服务端控制上下文长度：

OLLAMA_CONTEXT_LENGTH=32768
OLLAMA_FLASH_ATTENTION=1

不要盲目把上下文调到最大。显存占用和性能代价是肉眼可见的，浅显的原则是：日常高频 Agent 用小窗口，deep-analysis 这类重任务才用大窗口。

6.2 工具权限：能读能写能执行，但边界要清楚

本地模型对工具和权限的理解比较字面化。如果 OpenClaw 的工具权限收得太紧，模型会反复描述“我想做什么”而不是直接调用工具。一个相对宽松但可用的示例：

tools: {
  profile: "coding",
  allow: ["read", "write", "edit", "exec"],
  exec: {
    host: "gateway",
    ask: "on",
    security: "default"
  }
}

ask: "on" 意思是每次执行命令前问你一次，避免模型自作主张。如果你确认机器专用于 OpenClaw、通信通道可控，再考虑把 ask 改成 off。需要特别说明的是：OpenClaw 的 exec 只作用于网关沙箱能访问的资源和权限范围，它不能也不应该直接连接你的生产库或生产机器。涉及诊断 SQL 这类操作，正确做法是让人在本地或 SQL*Plus 里执行，再把结果贴回对话，让 Agent 分析，而不是让 Agent 拿着生产连接串去执行。

6.3 SOUL.md 与 Modelfile：把“空谈”改成“干完再说”

本地模型最常见的毛病是过度解释，明明一步能完成的事，先输出一大段计划和免责声明。在 OpenClaw 的 SOUL.md 里加一段简洁规则：

## Brevity rules
Be concise.
Do not dump skill documentation.
Do not print raw JSON responses.
Do not explain what you will do in detail.
When a task succeeds, confirm in one short sentence.

如果某个模型特别喜欢描述工具而不是调用工具，还可以用 Ollama 的 Modelfile 做针对性的系统提示：

FROM qwen2.5-coder:32b
SYSTEM """
You are a helpful assistant with access to tools.
Tool behavior:
- Use available tools when needed without asking for permission
- Do not describe the tool call in advance
- Summarize results instead of outputting raw JSON
- If required input is missing ask a direct question
Keep answers short unless the user asks for deep detail.
"""

构建自定义模型：

ollama create qwen-agentic -f qwen-agentic.Modelfile

一个关键警告：除非你完全理解 Ollama 的工具调用模板格式，否则不要随意覆盖它。一旦破坏了工具格式，OpenClaw 会表现为“模型回复一切正常但工具全部失效”，这时候大多数人会误以为是 OpenClaw 坏了。

7. 故障排查与最终核查清单

7.1 空响应、模型不可见、工具不执行：对症下药

第一类：OpenClaw 能连到 Ollama，但响应为空。优先检查 API 模式。如果你用的是 OpenAI 兼容模式，先切回 api: "ollama" 原生模式，确认基础聊天正常，再测试工具调用。Ollama 原生模式是最稳的路径。

第二类：提示“未检测到模型”。确认 Ollama 正在运行，确认 provider 的 apiKey 字段存在。Ollama 不校验 Key 的真假，但 OpenClaw 要求这个字段必须存在。而 TaoToken 那边的 401 错误就完全是另一回事：那是 Key 本身无效或已过期，需要回控制台重新创建。

第三类：openclaw models list 里看不到某个模型。先用 ollama list 确认模型已经拉到本地。如果 Ollama 有但 OpenClaw 没有，多半是你用了显式 provider 配置却忘了在 models 数组里补上模型条目。这也解释了为什么方式 C 的配置要手写模型列表。

第四类：模型只“谈论工具”却不真正动手。打开工具权限配置，检查 allow 列表是否包含需要的权限，再把 ask 调到你能接受的级别。配合第 6 章的 SOUL.md 和 Modelfile 一起调，通常能解决。

第五类：网关持续请求审批，即使你已经取消了几次。这通常是安全策略与会话状态叠加导致的，重启网关一般能清掉。如果反复出现，再回头和工具权限配置逐项核对。

7.2 四条命令跑通混合链路，并且去 TaoToken 看用量

所有配置改完后，按下面的顺序做一次完整核查：

curl http://localhost:11434/api/tags
ollama pull llama3.3
openclaw models list
openclaw gateway start

前两条确认 Ollama 服务正常、至少有一个可用的本地模型。第三条确认 OpenClaw 能同时看到 ollama/gpt-oss:20b 之类的本地模型和 taotoken/YOUR_MODEL_ID 之类的云端模型。第四条把网关启动起来。

启动后在聊天或 TUI 里依次验证：

• 问“现在几点”，默认 Agent 应该走本地 Ollama 的工具调用拿到时间；
• 问“列出当前目录中的文件”，确认 exec 工具链路可用；
• 贴一段 JSON 让它总结，确认本地模型的格式转换能力；
• 切到 deep-analysis 或指定 taotoken/YOUR_MODEL_ID 再发一个复杂任务，让请求经过云端。

最后一步，回到 TaoToken 控制台看一眼刚才那次 cloud 调用是否产生了用量记录。有记录，说明本地免费链路和云端付费链路同时跑通，你的 OpenClaw 已经不是“某个模型的客户端”，而是一套本地优先、云端兜底的混合 Agent 路由。以后再有新 Agent 进来，只需要判断它属于“高频小任务”还是“深度推理”，然后分配 provider 就够了。