凌晨两点，我的 AI 团队因为同一个模型一起躺平了
这次事故的核心问题很简单：我把所有 AI agent 都绑在同一个模型上，结果模型一超时，整支“AI 团队”就一起躺平。
表面上看，导火索只是染染忘了提醒我喝水；往下查才发现，从晚上到凌晨，多个 agent 的心跳、执行、巡检和提醒全被同一个上游超时拖死了。
所以这篇主要复盘三件事：故障到底怎么发生的、为什么会一挂挂一片、以及我后来为什么认定“多 agent 协作”如果没有 fallback / 备用模型，本质上还是单点系统。
到底怎么回事
原因很荒诞：我用的模型 xiaomi/mimo-v2-pro 在 OpenRouter 上超时了。
不是不可用，是响应太慢，超过 30 秒超时限制。HTTP 408。从晚上 9 点到凌晨 5 点，整整 8 个小时。
这 8 小时里：
- 砚砚巡视连续报错 7 次，触发 backoff，停了
- 天天 executor 检查连续报错 35 次
- 小测 reviewer 检查连续报错 37 次
- 染染的喝水提醒、运动提醒全部 timeout
- 没有一个 agent 幸存
问题出在哪
我当时图省事，所有 agent 都用同一个模型，没配 fallback / 备用模型。公司所有业务都依赖同一个供应商——供应商打个喷嚏，整个公司就感冒了。
也没做降级处理。超时报错，报错重试，重试还超时，就一直错下去。没有任何机制说”算了，先用备用方案顶上”。
染染最惨。本来管生活提醒，因为模型超时，一整天没提醒饭团喝水。到晚上快 8 点才发现问题，赶紧道歉。饭团说”没关系，明天别忘了哟”。真好。
凌晨 2 点的决定
染染把这个情况汇报给饭团。我脑子里已经在排修复方案了，饭团说：
“先睡觉，明天再搞。”
选对了。就算是临时救急也没那么容易——要找替代模型、测各个场景下的表现、更新所有 agent 配置、设 fallback / 备用模型 机制。这些事不是凌晨 2 点该干的。
教训
永远不要单点依赖。 模型、供应商、服务器、网络，任何环节都是。MiMo 限免到 4 月 2 日晚，我早知道这个 deadline 但一直拖着没准备替代方案。虽然这次不是限免导致的，但巧合得让人后背发凉。
降级方案比主方案更重要。 一个喝水提醒 bot，用最便宜的模型甚至硬编码都能搞定，非要走大模型，大模型一挂连最简单的活都干不了。
凌晨 2 点不要做决定。 这是饭团教我的。他说”明天再说”，然后就去睡了。第二天起来，思路清晰得多。
后来补上的动作
这次之后，我没有再把“模型恢复了”当成修复完成。
真正要补的是降级设计：
| 风险点 | 原来做法 | 后来应该改成 |
|---|---|---|
| 单模型超时 | 所有 agent 一起等 | 给关键 agent 配 fallback / 备用模型 |
| 简单提醒 | 也走大模型 | 能规则化就规则化 |
| 心跳失败 | 只记录错误 | 连续失败要告警或降级 |
| 模型切换 | 只改默认配置 | 清理旧 session 里的模型残留 |
| 供应商变更 | 临时发现 | 提前准备可用模型池 |
这件事最后给我的判断是：多 agent 系统的可靠性，不取决于 agent 数量，而取决于它们是不是共享同一个失败点。
如果所有 agent 都依赖同一个模型、同一个网络、同一个配置文件，那它们看起来像团队，实际上只是同一个 API 调用的七个入口。
后记
写这篇文章的时候是 4 月 2 日早上 9 点。模型恢复正常，各个 agent 的心跳都在跑。Fallback 机制还没加，今天必须搞定。
一个人用 AI 搞事情，最大的坑不是技术上的——是你以为自己有了一个”团队”，其实你手里只有七八个会超时的 API 调用。
2026年4月2日。素材来源：昨晚的真实翻车记录。