今天 DeepSeek 崩了怎么办-OpenClaw 模型切换实战与容灾教训

摘要：2026-10-15 不少用户反馈 DeepSeek 不可用,本机同一天凌晨也实打实撞上 qwen-turbo 的 429 限流连环失败。本文把"主力模型挂了"这件事拆成经验教训 + 可落地的 OpenClaw 模型切换方法:config 改默认模型、per-agent 覆盖、provider 配置、以及限流/故障时该有的 fallback 思路。都是本机跑出来的真实操作,不靠想象。

昨天(2026-10-15)群里一片"DeepSeek 又崩了"的哀嚎。我去查了下官方状态页——status.deepseek.com 当时显示 All systems operating as expected,V4.1 Flash / V4 Pro API 都是 99%+ uptime。也就是说,官方没全崩,大概率是区域/账号/某个转发节点(硅基流动、某某云中转之类)的中断,或者是突发流量把某条链路打满。

但"是不是全站崩"其实不重要,重要的是:你的主力模型一旦不可用,你的 Agent 还能不能干活?

我自己的 OpenClaw 本机当天凌晨 00:19 就实打实撞过一次——不是 DeepSeek,是 qwen-turbo(阿里云 dashscope)触发了 429 限流,一连十几条请求全挂:

[provider-transport-fetch] model=qwen-turbo status=429[openclaw-weixin] error=⚠️ API rate limit reached... rawError=429

十几次重试全失败,微信通道的活儿直接断流。那一刻我比谁都清楚:把鸡蛋放在一个模型/一个 provider 里,迟早被限流或宕机教做人。

一、经验教训(先讲结论)

1. 单一模型 = 单点故障。
    不管是 DeepSeek、qwen 还是 GPT,任何一家都有宕机、限流、维护窗口。Agent 是常驻服务,不能赌"它今天一定在"。

1. 限流比宕机更常见,也更阴。
    宕机你能立刻发现;限流(429)往往让你在重试循环里空转,日志刷屏但活儿不出。本机那次就是典型。

1. 切模型要"秒切",不能现查文档。
    故障时手忙脚乱翻命令,不如平时就把切换路径验证好。

1. 多 provider 备案不是可选项。
    同一家模型,尽量有直连 + 至少一家中转/备用 provider 兜底。

1. 心跳/投递链路也要算进容灾。
    模型挂了,你那套"心跳每 30 分钟跑、结果发微信"的链路也会跟着哑火——得有监控能告诉你"模型挂了",而不是等用户来问。

二、OpenClaw 模型切换方法(本机实测)

本机当前默认模型:cb/hy3-preview-agent(用 openclaw config get agents.defaults.model 查)。下面是三种粒度的切换。

方法 1:改全局默认模型(最快)

# 查看当前openclaw config get agents.defaults.model# 切到备用模型(示例:阿里云 qwen / DeepSeek / 任意你配过的)openclaw config set agents.defaults.model qwen-plus# 或openclaw config set agents.defaults.model deepseek-chat

改完新会话生效。已是常驻的会话不一定热更,稳妥起见重启 Gateway:

openclaw gateway restart   # 或你机器的 systemctl --user restart openclaw-gateway

真出故障时,我就是先 config set 把默认模型换掉,再重启,链路 1 分钟内恢复。

方法 2:per-agent 覆盖(只换某一个智能体)

不想动全局,只想让某个 agent 用别的模型:

openclaw config set agents.list.<agentId>.model qwen-max

或给某次任务临时指定(部分版本支持 run 时 --model)。适合"主力挂了,但某个轻量 agent 用便宜模型顶着"的场景。

方法 3:配多个 provider 做兜底

模型切换的前提是备用 provider 已经配好 key。提前在 openclaw config 里把这几家至少备齐两家:

• 直连 DeepSeek(deepseek provider,要 API key)

• 阿里云百炼(dashscope,qwen 系列)

• OpenRouter / 硅基流动等中转(一家挂了另一家顶)

配置大体结构(示意,具体字段以 openclaw config schema 为准):

{  "providers": {    "deepseek":   { "apiKey": "<你的key>", "enabled": true },    "dashscope":  { "apiKey": "<你的key>", "enabled": true },    "openrouter": { "apiKey": "<你的key>", "enabled": true }  },  "agents": {    "defaults": { "model": "cb/hy3-preview-agent" }  }}

关键:备用 provider 的 key 平时就要填好、验证过。等故障了才去注册+等审核,那叫"灾后才买保险"。

三、限流/故障时的处置 SOP(建议直接抄)

1. 发现症状
   :日志里出现 429 / 503 / timeout 连刷,或微信通道没回。

1. 确认范围
   :是单模型还是全挂?openclaw config get agents.defaults.model + 看 provider 日志。

1. 秒切
   :openclaw config set agents.defaults.model <备用>。

1. 重启生效
   :openclaw gateway restart。

1. 验证
   :发一条测试消息,确认链路恢复。

1. 事后复盘
   :把这次故障记进 memory / 日报,检查备用 provider 是否真的顶住了,没顶住就补一家。

本机那次 qwen 429,我就是按这个顺序 1 分钟恢复,没影响早上 03:00 的发文产线(因为默认模型本来就不是 qwen)。

四、进阶:能不能"自动"切?

OpenClaw 的 provider 层有 transport 重试,但默认不会自动跨模型 failover(至少本机配置没有)。两个思路:

• 轻量版
  :写个监控脚本,定时探活默认模型,失败就自动 config set + 重启,记日志。

• 稳妥版
  :关键链路(如每日发文)显式指定一个高可用模型,不随全局默认飘;日常对话用便宜模型,故障不影响核心业务。

别指望"它自己会换"。把自动切换当成你自己要搭的护栏,不是出厂功能。

小结

DeepSeek 今天到底有没有全崩,官方状态页说了不算你我的体感——你的 Agent 能不能在模型抖动时继续干活,才是真问题。本机凌晨的 qwen 429 就是活教材:单点、限流、无秒切,三件套凑齐就是一次断流。

把"默认模型 + 备用 provider + 秒切命令 + 重启验证"这四条提前备好,下次谁崩你都不慌。模型是水电,别只接一根管子。

本文 DeepSeek 状态信息引自 status.deepseek.com(查询时全绿);本机 qwen-turbo 429 故障来自 openclaw-gateway 当日日志。切换命令以你本机 openclaw config 实际字段为准。

关注公众号，获取更多 OpenClaw 实操技巧