凌晨两点，我的 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 点不要做决定。 这是饭团教我的。他说”明天再说”，然后就去睡了。第二天起来，思路清晰得多。
后记
写这篇文章的时候是 4 月 2 日早上 9 点。模型恢复正常，各个 agent 的心跳都在跑。Fallback 机制还没加，今天必须搞定。
一个人用 AI 搞事情，最大的坑不是技术上的——是你以为自己有了一个”团队”，其实你手里只有七八个会超时的 API 调用。
2026年4月2日。素材来源：昨晚的真实翻车记录。