把 Cloud Ollama 接进 OpenClaw：通过 One API 单源打通全流程
把 Cloud Ollama 接进 OpenClaw：通过 One API 单源打通全流程
前几天我在 OpenClaw 上折腾模型源，目标很简单：只用 One API 一个网关，不要散落一堆直连 provider。但过程中遇到一个典型问题——”Cloud Ollama 用不了”。这篇文章记录我是怎么定位、修复并验证的，希望对同样用 One API 做 LLM 网关的同学有帮助。
一、背景与目标
我的架构是这样的：
- One API：跑在 Docker 里（端口 3000），作为统一的 OpenAI 兼容网关，后端挂各家的渠道。
- OpenClaw：客户端，只配置一个 provider 指向 One API。
OpenClaw 侧配置形如：
{
"models": {
"providers": {
"one-api": {
"baseUrl": "http://<one-api-host>:3000/v1",
"api": "openai-completions"
}
}
}
}目标：所有模型（包括 Ollama Cloud 上的 gpt-oss、gemma 等）都通过 One API 走，客户端无需感知。
二、症状：Cloud Ollama “不工作”
表现有两个层面：
- 直连失败：任何
ollama-cloud/...调用都报model_not_found，提示需要设置OLLAMA_API_KEY。 - 流式失败：模型列表里能看到 gpt-oss:20b 等，但一带上流式就报
bad_response_status_code，非流式却正常。
三、定位：关键在 One API 的渠道配置
排查后发现两个真相：
真相 1：Ollama Cloud 其实已经配在 One API 里了。直接查 One API 的 sqlite 数据库（channels 表），能看到一条渠道：
name = 'Ollama Cloud'
models = 'gpt-oss:20b,gpt-oss:120b,gemma4:31b'
type = 1 (OpenAI 兼容)
base_url = 'https://ollama.com'
status = 1 (启用)也就是说，Cloud Ollama 是通过 One API 的 OpenAI 兼容渠道接入的，根本不是 OpenClaw 直连。所以 OpenClaw 侧那个”直连 Ollama Cloud”的插件纯属多余。
真相 2：流式报错来自上游。用 curl 直测 One API：
curl http://<host>:3000/v1/chat/completions \
-H "Authorization: Bearer $KEY" \
-d '{"model":"gpt-oss:20b","messages":[{"role":"user","content":"hi"}],"stream":true}'HTTP 状态返回 200，但 body 里是错误对象；非流式则完全正常返回。这是 OpenAI 兼容网关在”流式 + 工具调用”下的典型兼容性问题——上游渠道对 stream 的处理有缺陷。
四、修复：两步搞定
第一步：确认 Cloud Ollama 渠道在 One API 中启用且模型列全。如果 /v1/models 里看不到，多半是 token 的模型白名单（model_limits）限制，或渠道 status 不是 1。
第二步：对不支持的模型关闭流式。这是最关键的 workaround。在 OpenClaw 的模型配置里给这些模型加参数：
{
"agents": {
"defaults": {
"models": {
"one-api/gpt-oss:20b": {
"alias": "gpt-oss-20b",
"params": { "streaming": false }
}
}
}
}
}OpenClaw 支持在单个模型条目上通过 params.streaming 覆盖流式行为（默认 true；对 Ollama 类渠道默认建议关闭以规避已知问题）。设置后，请求改走非流式通道，稳定返回。
五、顺手清理的隐患
修复过程中还发现一个被忽略的问题：死 fallback 会拖慢一切。原本的 fallback 链里混着两个上游已挂的模型（NVIDIA NIM 渠道异常，返回 401/超时/403）。主模型一旦失败，会先在这些死模型上各卡满超时才轮到一个能用的。
清理要点：
- fallback 链只保留实测可用的模型；
- 同步更新
modelPolicy.allow与方法白名单； - 重点：检查子 agent、图片模型（mediaModels）等一切引用模型的地方——删一个模型可能连带搞挂好几个子 agent；
- 移除多余的直连 provider 插件（本案例是 ollama 插件及其 web 工具）。
六、验证清单
openclaw models list：只列出实际可用模型，Auth 列正常；- 非流式调用主模型：HTTP 200，正常返回内容；
- 流式调用主模型：确认
delta正常吐出（本案例主模型流式健康）； - 对关闭流式的模型再测一次：非流式稳定返回；
- JSON/schema 校验通过，doctor 无新增错误。
七、结论
“Cloud Ollama 用不了”这个问题的真相是：它本来就该通过 One API 走，而不是直连。真正要解决的是两点——确认 One API 里 Ollama Cloud 渠道配置正确，以及对流式有缺陷的模型用 params.streaming:false 兜底。再加上一次”死 fallback”清理，整个链路就清爽了。
如果你也在用 One API + OpenClaw 的组合，建议优先用兼容性更好的模型做主力，把有流式问题的模型显式降级为非流式，并定期体检 fallback 链——省下的都是等待时间。