OpenClaw 3.2 升级到 3.8 后，我终于不再手改 JSON 了

今天我做了一件看似很小、实际上很关键的事：把 OpenClaw 从 3.2 升级到了 3.8。

表面上，这只是一次常规升级；但真正让我有感触的，不是版本号本身，而是我终于把这套 AI 工具链，从“能用就行”的临时拼装，推进到了“可维护、可排障、可重建”的状态。

这件事，值得记一笔。

一、问题不是升级，而是升级后暴露出的“系统债”

升级本身并不复杂。真正麻烦的是：版本一升，旧问题就全浮出来了。

• 以前遗留的 provider 还在不在？
• 旧 OAuth 凭证是不是已经失效？
• fallback list 的顺序有没有变？
• 哪些模型是真正在用，哪些只是历史残留？
• 现在到底该用 onboard、configure，还是 models 子命令？

如果这些问题全靠肉眼读 JSON 配置文件，很快就会进入一种熟悉的混乱状态：

看似什么都能改，实际上越改越不确定。

这也是很多 AI 工具链最容易出现的问题——不是不能跑，而是一旦环境变复杂，就没人能清楚解释“当前系统到底在怎么工作”。

二、这次最重要的收获：别再手改 JSON 了

以前遇到模型配置问题，我第一反应经常是去翻配置文件。

这种方式短期很爽，因为快；但长期看，它的问题也很明显：

1. 你改的是“结果”，不是“接口”
2. 你不知道有没有别的地方同步依赖这份配置
3. 一旦版本升级，配置结构可能变化，手改就容易埋雷
4. 最致命的是：过几天你自己都不记得当时为什么这么改

这次升级到 3.8 后，我明显感觉到 OpenClaw 在模型管理这块已经成熟很多了。像下面这些操作，都可以直接通过 CLI 完成：

• 查看默认模型
• 查看 fallback 顺序
• 清空并重建 fallback list
• 查看 auth 状态
• 判断哪些 provider 是 OAuth，哪些是 API key

这意味着一件事：

配置管理开始从“手撕文件”回归到“命令式维护”。

这不是形式主义，而是工程习惯的升级。

三、真正棘手的，不是模型，而是认证链路

这次最有代表性的坑，是 OpenAI Codex OAuth 登录时报了一个错误：

unsupported_country_region_territory

这类问题最容易误判成“OpenClaw 出 bug 了”。但实际上，它更像是 provider 侧的区域风控问题，不是本地配置语法错误。

这件事提醒我：在今天这种多模型、多 provider 的 AI 工作流里，模型能力已经不是唯一变量，认证链路本身就是系统的一部分。

你以为自己在选模型，实际上你还在同时处理：

• OAuth 是否有效
• token 是否过期
• provider 是否限地区
• 当前网络出口是否被风控
• fallback 是否会悄悄切到另一条线路

也就是说，AI 工作流的稳定性，不再只是“模型强不强”，而是：

模型 × 认证 × 网络 × 配置管理 的乘积。

只要其中一个环节掉链子，体验就会大打折扣。

四、fallback 机制，才是真正的生产力保险丝

这次我重新整理了 fallback list，最后留下了 4 个主要备选：

1. google/gemini-3.1-pro-preview-customtools
2. custom-jp-duckcoding-com/claude-opus-4-6
3. minimax-cn/MiniMax-M2.5
4. qwen-portal/coder-model

这里要特别说明一下，第二个模型名字非常具有迷惑性。

custom-jp-duckcoding-com/claude-opus-4-6 表面上看像是 Claude Opus 4.6，但它其实并不是 Anthropic 官方直连模型，而是一个中转站封装出来的兼容接口。更准确地说，它背后走的是一种超低倍率（大约 0.1x 成本）的 Codex 转 Claude Code 路线，实际底层模型口径更接近 GPT-5.4。

这件事本身也很能说明今天 AI 工具链的一个现实：

你看到的模型名，不一定就是你真正调用到的模型。

很多时候，provider 名称、路由层、中转站包装名、实际底层模型，根本不是一回事。如果不把这层关系理清楚，所谓“多模型管理”其实只是管理了一堆幻觉标签。

但反过来说，这也正是 fallback 的意义所在。它不是为了让界面更热闹，而是为了让你的工作流在真实世界里有冗余、有弹性。

以前我会更关注“哪个模型最强”；现在越来越觉得，对于真实工作场景来说，更重要的问题其实是：

• 当主模型抽风时，谁能无缝顶上？
• 当某个 provider 出现认证问题时，系统会不会直接瘫痪？
• 当我精力很差、时间很紧时，工具链能不能稳定地给我结果？

强模型像主力球员，fallback 像替补席。没有替补，再强的主力也撑不起一个赛季。

五、AI 工具链的真正分水岭：从“玩具”到“系统”

这次升级给我最大的感受是：

很多人用 AI 工具，还停留在“单次调用”的思维里。问一个问题，回一个答案，模型好就行。

但一旦你开始把 AI 用到真实工作流——写作、科研、排障、项目推进——你就会发现，真正重要的不是单次回答的惊艳，而是整个系统的：

• 可用性
• 稳定性
• 可迁移性
• 可恢复性
• 可维护性

说得更直白一点：

AI 不再只是一个聊天对象，而是在逐渐变成你的工作操作系统。

而操作系统这种东西，最怕的从来不是“偶尔慢一点”，而是“出了问题你根本不知道该从哪儿查”。

六、这件小事背后的一个更大判断

今天这次升级之后，我反而更确定了一件事：

未来真正有价值的，不是谁知道更多 prompt 技巧，而是谁能把 AI 工具链组织成一个稳定、低摩擦、可复用的工作系统。

因为模型会继续变，供应商会继续变，价格会继续变，登录策略也会继续变。但如果你的工作流设计得足够清晰，你就不会每次都从零开始重建。

这也是我今天这次折腾的真正意义。

不是为了“升级到 3.8”本身，而是为了让我的 AI 系统，少一点临时性，多一点工程感。

结语

这次从 OpenClaw 3.2 到 3.8，看起来像一次普通升级，实际上更像一次整理内务。

它让我再次确认了一件事：

真正拖慢人的，往往不是模型不够强，而是工具链不够稳。

比起继续手改 JSON、临时补漏洞，我更愿意把这些基础设施一步步理顺。因为只有这样，AI 才不会只是一个偶尔惊艳的玩具，而会真正变成长期可靠的生产力伙伴。