去年12月，OpenClaw的GitHub issue区突然涌入47条"Gateway崩溃"报告。用户们把76B5208这个数字当成错误代码全网搜索，却没人发现它只是版本号——2026.1.30的十六进制写法。
真正的凶手藏在配置文件的第7行。OpenClaw内置的"Ollama"提供程序被设计成只认本地服务器，一旦指向云端URL，就会触发本地专属的模型发现机制，直接把Gateway服务干崩。
本地思维写死的云端适配
OpenClaw的架构假设很直白：Ollama等于本机127.0.0.1。这个设计在2024年完全合理，当时Ollama Cloud还没上线。但当Ollama今年1月开放云端API后，大量用户开始把baseUrl改成https://ollama.com/v1，然后看着Gateway反复重启。
崩溃日志里藏着一个有趣的细节：OpenClaw试图执行ollama list命令来枚举模型，这个命令在云端环境里根本不存在。
开发者社区花了三周才摸清楚门道。解决方案出人意料地简单——不用Ollama提供程序，改用openai-completions类型。这相当于告诉OpenClaw："别搞特殊待遇，把Ollama Cloud当成普通OpenAI兼容API处理。"
配置文件的关键段落长这样：
「models.providers里把api字段设为openai-completions，baseUrl指向https://ollama.com/v1，然后直接列模型ID。不需要任何本地发现逻辑。」
三个被误读的"故障信号"
第一个陷阱是76B5208。这个数字出现在日志里时，用户本能地以为是错误码，实际上它只代表你跑的是2026年1月30日版本。如果看到这个数字，程序反而是正常的。
第二个陷阱是"Invalid Input"报错。这个模糊提示的真正含义是：api字段填错了。只要不是openai-completions，就会触发这个错误。但OpenClaw的日志没有告诉你该填什么，只告诉你填错了。
第三个陷阱更隐蔽。即使配置改对了，Gateway可能还在用旧的缓存状态运行。这时候需要执行openclaw gateway stop再openclaw gateway restart，相当于给服务一个冷启动。
云端模型的实际表现
目前Ollama Cloud支持的三个主力模型在OpenClaw里的配置参数已经明确：Kimi K2.5、MiniMax M2.5、GLM-5，上下文窗口都是128K，最大输出token 4096。这个规格和官方文档一致，没有缩水。
但有个细节需要注意。模型ID必须带:cloud后缀，比如kimi-k2.5:cloud。这个命名规范是Ollama Cloud的区分标识，去掉后缀会导致路由失败。
启动对话时建议加上--session-id参数。OpenClaw的会话管理依赖这个标识来决定消息往哪发，没有它可能出现"消息已发送但无响应"的幽灵状态。
完整的配置结构比想象中更深层。除了models.providers，还需要在agents.defaults里指定primary模型，格式是ollama-cloud/前缀加上模型ID。很多人只改了上半部分，漏了下半部分，结果Agent调用的还是本地默认配置。
一个值得玩味的对比：同样是用Ollama Cloud，通过OpenAI SDK直接调用只需要baseUrl和apiKey两行代码。OpenClaw的多层抽象在这里成了负担——它想帮你管理模型发现、会话状态、Agent路由，但这些"帮助"在云端场景里全是阻碍。
这大概是2024年设计的工具在2025年云端原生环境里的典型困境。本地优先的架构假设遇到API优先的新现实，补丁式的兼容方案总比重构来得快。
现在你的OpenClaw能连上Ollama Cloud了，但有个问题：当所有模型都变成云端API调用，OpenClaw引以为傲的"本地AI工作流"还剩下多少独特价值？
热门跟贴