1. openclaw 对接 ollama 本地模型为什么 Key 总是配不干净openclaw 是一个把本地模型、云端模型统一编排成 Agent 工作流的工具ollama 则是本地跑开源模型最省心的方案。把这两者接起来理论上就是让 openclaw 把请求发到http://localhost:11434但真正动手时很多人卡在同一个地方Key 和 provider 配置散落在好几个文件里改了一处另一处没同步最后报No API key found for provider ollama或者模型名对不上。这个场景的典型痛点是三件事。第一openclaw 的config.toml、auth-profiles.json、Web 端 Raw 视图三处都可能存 provider 信息谁覆盖谁不明确。第二ollama 本地服务其实不需要真实 Key但 openclaw 的 provider 校验逻辑要求一个占位凭证缺了就报错。第三如果你同时还在用云端模型多个 Key 分散管理切换时容易串味。我试过把本地模型和云端模型混在一个配置里结果 ollama 的 baseUrl 被云端 provider 的默认值覆盖排查了半天。后来用 TaoToken 做统一 Key 入口把云端那部分收敛掉本地 ollama 只保留一个干净的 provider 块问题就清晰多了。这篇就按「先统一 Key 管理再写 openclaw 配置最后 curl 验证」的顺序给你一套一次配好、稳定调用的路径。适合谁看已经在本地跑起 ollama、想让 openclaw 调用本地模型做 Agent 或编码辅助的人以及手上有多套模型 Key、想统一收口的人。2. TaoToken 前置把统一 Key 和本地模型入口先理清TaoToken 在这里的角色是「统一 Key 管理 云端模型接入入口」。本地 ollama 模型本身不走网络但 openclaw 的 provider 体系里云端模型和本地模型共用一套配置结构所以把云端那部分的 Key 统一到 TaoToken能避免多工具 Key 分散导致的配置冲突。你需要先拿到一个 TaoToken 的 API Key。进入控制台创建即可控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteAPI Key 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite创建后复制 Key形如sk-xxxx。这个 Key 用于 openclaw 里云端 provider 的认证本地 ollama provider 不需要它但两者放在同一个config.toml里时结构要写对否则 openclaw 会拿云端 Key 去校验本地 provider。TaoToken 的 API 基址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为 baseUrl 使用。如果你要接 Claude 系列模型做编码可以走 Coding PlanCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite接入文档在这里配置字段含义可以对照查接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite注意本地 ollama 的 baseUrl 是http://localhost:11434/v1和 TaoToken 的https://taotoken.net/api是两个独立 provider不要混在同一个块里。3. openclaw 侧 config.toml 骨架与 TaoToken 统一 Key 配置片段openclaw 的配置文件通常在用户目录下的.clawdbot或项目根目录具体路径取决于你的安装方式。下面是一个可直接套用的config.toml骨架包含 ollama 本地 provider 和 TaoToken 云端 provider 两块。# openclaw config.toml 骨架 # 本地 ollama provider [models.providers.ollama] baseUrl http://localhost:11434/v1 api openai-completions apiKey ollama-local-placeholder # TaoToken 统一云端 provider [models.providers.taotoken] baseUrl https://taotoken.net/api api openai-completions apiKey sk-你的TaoTokenKey # 默认主模型指向本地 ollama [agents.defaults.model] primary ollama/qwen3-coder:latest几个关键点解释一下。api openai-completions表示用 OpenAI 兼容的 completions 协议ollama 和 TaoToken 都支持这个协议所以两边可以共用同一套调用逻辑。apiKey对 ollama 来说只是占位写什么都行但不能省略否则 openclaw 的 provider 校验会报No API key found。主模型primary的格式是provider/模型名这里写ollama/qwen3-coder:latest前提是你已经用ollama pull qwen3-coder拉过这个模型。如果你本地是llama3.2:latest就改成ollama/llama3.2:latest。除了config.tomlopenclaw 还有一个认证文件需要检查路径类似~/.clawdbot/agents/main/agent/auth-profiles.json。内容保持极简即可{ version: 1, profiles: { ollama:default: { type: none, provider: ollama } }, lastGood: { ollama: ollama:default } }type设为none表示本地 provider 不需要真实认证。如果你之前配过云端 provider这里可能残留了旧条目导致 openclaw 优先读到了错误的认证配置把多余的删掉只留 ollama 这条。改完两个文件后重启 openclaw 服务。如果你是用ollama launch openclaw启动的先在终端按CtrlC停掉再重新执行ollama launch openclaw这个命令会自动把 openclaw 的后端指向 ollama 并启动网关。如果网关已在运行它会自动重载配置但手动改过文件后建议还是完整重启一次避免缓存。4. 验证请求curl 测本地模型连通性 openclaw 内调用配置写完别急着开 Web 界面先用 curl 确认 ollama 本身是通的。这一步能帮你把「ollama 服务问题」和「openclaw 配置问题」分开。curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer ollama-local-placeholder \ -d { model: qwen3-coder:latest, messages: [ {role: user, content: 用一句话说明什么是本地模型} ] }如果返回里有choices字段和模型输出内容说明 ollama 服务和模型都正常。如果返回model not found说明模型名写错了或者没拉取用ollama list核对一下。接着验证 TaoToken 云端 provider 是否通curl https://taotoken.net/api/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoTokenKey \ -d { model: claude-3-5-sonnet, messages: [ {role: user, content: ping} ] }两边都通之后打开 openclaw 的 Web 界面默认地址是http://127.0.0.1:18789。在对话框里发一条消息如果主模型指向的是ollama/qwen3-coder:latest请求会走本地如果你想临时切到云端可以在 Settings 里改primary为taotoken/claude-3-5-sonnet。提示如果 Web 界面打不开检查是否启用了访问令牌有些版本需要把 token 附加到 URL 后面形如http://127.0.0.1:18789/?tokenxxx。5. 本篇常见错排查No API key、模型名不匹配、baseUrl 覆盖报错一No API key found for provider ollama这是最高频的问题。原因通常是config.toml里 ollama provider 块缺了apiKey字段或者auth-profiles.json里没有对应的ollama:default条目。解决方法是两处都补上ollama 的 apiKey 写占位符即可auth-profiles 里type设为none。报错二模型名不匹配返回model not foundopenclaw 里primary写的模型名必须和ollama list输出的完全一致包括 tag。比如qwen3-coder:latest不能简写成qwen3-coder。另外注意 provider 前缀ollama/qwen3-coder:latest和qwen3-coder:latest在 openclaw 里含义不同前者明确指定走 ollama provider。报错三baseUrl 被云端 provider 覆盖如果你在config.toml里先写了 TaoToken 的 provider再写 ollama 的某些版本的 openclaw 会按顺序合并导致 ollama 的 baseUrl 被覆盖成https://taotoken.net/api。解决方法是把 ollama provider 块放在前面或者显式给每个 provider 加独立的命名空间不要共用顶层字段。报错四改了配置但没生效openclaw 有配置缓存改完config.toml和auth-profiles.json后必须重启服务。用ollama launch openclaw启动的先CtrlC再重新执行。如果重启后还是旧行为检查是否有多个配置文件路径比如项目根目录和用户目录各有一份openclaw 可能读的是另一份。报错五curl 通但 openclaw 内调用失败这种情况通常是 openclaw 的 provider 校验逻辑比 curl 更严格比如要求api字段必须是特定值。确认api openai-completions拼写正确不要写成openai-completion或openai_completions。6. 一次配置稳定调用的收尾建议把本地 ollama 和 TaoToken 云端 provider 分开写、分开验证是这套配置能稳定的核心。本地模型负责离线、低延迟的场景云端模型负责需要大上下文或更强推理的场景两者通过 openclaw 的primary字段切换互不干扰。如果你后续要长期跑编码 Agent建议把云端那部分统一走 TaoToken 的 Coding PlanKey 只维护一份本地 ollama 的占位 Key 固定不变。这样无论你加多少本地模型配置结构都不用动只改模型名就行。验证模型对话效果可以直接在模型对话页测试模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite需要新建或轮换 Key 时走 API Keys 页面接入字段有疑问查接入文档。配置过程中如果遇到 provider 校验相关的报错优先回看第 5 节的排查清单大部分问题都出在apiKey缺失和模型名不匹配这两处。
