今天这次排障，对我来说不是”某个模型坏了”这么简单，而是一次很典型的生产环境误操作 + 升级后链路异常 + 排障路径不断修正的复盘案例。

最后结果是：机器人恢复了，飞书能正常回复了，Memory Wiki 和 Dreaming 也基本挂上了。但过程里我犯了不少低级错误，也暴露出我在 AI Agent 运维上的几个盲点。

这篇文章不讲理论，只讲今天真实踩过的坑。

一、事情是怎么开始失控的

我的 OpenClaw 原本是能跑的，后面我做了升级，接着就开始出现异常：

  • 飞书能收到消息，但机器人不回复
  • 有时候报 incomplete turn detected
  • 有时候 queuedFinal=false, replies=0
  • 有时候看起来像模型切换成功了，但实际没有任何输出
  • 后面还夹杂着 Dreaming、wiki、bridge、session 等多个因素，导致我一开始判断方向越来越乱

最开始我以为是：

  • Dreaming 配置有问题
  • bridge / wiki 插件冲突
  • Codex 没额度
  • MiniMax 坏了
  • OpenRouter 坏了
  • session 污染了

但最后发现，这些都只是表象的一部分。

二、我今天犯的几个核心错误

1. 直接在”正在使用的机器人”上升级

这是我今天最大的错误。

我把升级操作直接做在正在对外服务的机器人上，没有先做一轮最小验证，没有灰度，没有回滚预案。结果一升级，飞书回复链路就异常了。

正确做法应该是：

  • 升级前先备份配置
  • 升级后只做最小测试：
    • /new
    • 你好
    • 一个简单问答
  • 确认没问题再继续用

我今天的问题，本质上不是”模型不行”，而是我把升级当成了无风险操作。

2. 把”模型问题”误判成”系统全坏了”

今天中途我一度把问题理解成：

  • OpenClaw 坏了
  • 飞书坏了
  • gateway 坏了
  • session 机制坏了

但后面一层层查下来，其实不是。

最后确认的状态是：

  • 飞书通道是正常的
  • gateway 是正常的
  • session 也能正常创建
  • Memory Wiki 也落地了
  • Dreaming 其实也挂上任务了

真正异常的是模型调用链路，而且还是升级后触发的链路异常，不是整个系统崩掉。

这说明我一开始把故障范围想得太大，导致排障路线变得越来越复杂。

3. 过早怀疑 Dreaming / Wiki / Bridge

因为今天刚好又在折腾 Dreaming、Memory Wiki、bridge 这些东西，所以我很自然地把锅甩给了这些插件。

但后来事实证明：

  • Memory Wiki 已经装好了
  • reports 目录存在
  • .dreams 目录存在
  • Memory Dreaming Promotion 任务存在
  • lastRunStatus: ok

也就是说，这些功能不是这次”机器人不回复”的主因。

我今天的另一个错误，就是把”最近改过的东西”自动当成”故障源”。这很常见，但不一定对。

4. 没有第一时间去看最关键的 session 文件

今天真正把问题定性的，不是表面的错误提示，而是 session 文件里的这类内容：

"role":"assistant",
"content":[],
"usage":{"input":0,"output":0,"totalTokens":0}

这说明什么？

说明不是飞书消息发不出去，而是模型层根本没产出正文。

也就是说：

  • 不是”回复被吞了”
  • 不是”session 没建立”
  • 而是”模型返回了空响应”

这是整个排障过程中最关键的证据。

如果我一开始就先看 session 文件，排障路径会短很多。

5. 对 fallback 过于乐观

理论上，fallback 是兜底的。

但今天我遇到的问题是：

  • MiniMax 一度过载/超时
  • 切到 OpenRouter free 后，又出现空响应
  • fallback 没有兜住，反而制造了”消息到了但没回”的假象

这让我意识到一件事：

不是所有 fallback 都算合格 fallback。

一个真正合格的 fallback，至少要满足：

  • 明确报错
  • 或稳定返回

而不是”看起来切换成功，其实没有正文输出”。

今天的 openrouter/free，就属于这种”表面可用，实际不适合作为自动兜底”的典型案例。

6. 在排障过程中暴露了 token

这个也是很现实的问题。

今天为了排障，我贴了不少日志和配置。过程中 gateway token 实际上暴露过一次，后面才去做了重置。

这说明我在排障时还缺少一个安全意识：

  • 日志可以贴
  • 配置可以贴
  • 但任何 auth token、API key、gateway token 都必须默认当成敏感信息处理

哪怕只是一次临时排障，也应该在结束后立刻轮换。

7. 没把”生产稳定”和”实验测试”分开

今天还有一个很大的问题，就是我把下面这些动作混在了一起：

  • 升级 OpenClaw
  • 测试不同模型
  • 改 fallback
  • 开 Dreaming
  • 装 Memory Wiki
  • 调飞书回复
  • 查 session 问题

这些事如果分开做，其实每件都可控。

但一旦混在同一天、同一台生产机器人上做，问题就会呈指数级变复杂。

这次最深的教训之一就是：生产机器人只做稳定动作，实验动作单独验证。

三、今天最后是怎么恢复的

最后真正把系统拉回来的，不是”修好所有功能”，而是做了两件正确的事：

  1. 先停止折腾 OpenRouter free

    事实证明，这条链路在我当时的环境里不可靠，会返回空响应。

  2. 把主模型固定回 MiniMax-M2.7，然后不再继续折腾 fallback

恢复后的状态变成：

  • 主模型：MiniMax-M2.7
  • fallback：空
  • 飞书机器人恢复正常回复
  • /new 正常
  • 你好 正常
  • token 已重置
  • Dreaming 任务已存在
  • wiki 已落地

也就是说，最终恢复不是靠”全修好”，而是靠先回到一个最小稳定状态。

四、我今天真正学到的东西

第一，AI Agent 不是”装好就完了”

它不是一个单纯的软件，而是一条链路系统，里面有：

  • 渠道层（飞书）
  • 网关层（gateway）
  • session 层
  • provider 层
  • model 路由层
  • plugin 层
  • 定时任务层

任何一层出问题，表面现象都可能很像。

第二，不要迷信 fallback

fallback 不是配上就安全，必须经过真实验证。

第三，日志不如 session 文件有用

如果是”收到消息但没回复”，最该看的往往不是表面报错，而是 session 最终有没有 assistant 正文。

第四，升级前一定要做最小验证

这个真的不能省。

第五，先恢复服务，再追根究底

如果机器人已经在生产中，就先把它拉回稳定状态，再去研究到底是哪个 provider、哪个版本、哪个路由的问题。

五、我给自己定下的后续规则

以后我再碰 OpenClaw / AI Agent 这类系统，先按下面这套来：

  • 生产机器人不上来就升级
  • 升级前先备份配置
  • 升级后先跑最小验证
  • fallback 不用泛路由模型，优先用明确模型 ID
  • 出现”没回复”先看 session 文件
  • 配置和日志发出来前先检查 token
  • 生产链路和实验链路分开

六、结语

今天这次排障，表面看是”机器人不回了”，但本质上是一次很典型的运维问题：

不是某一个点坏了，而是我在一个正在服务的系统上，同时做了太多变化。

最后系统恢复了，这当然是好事。

但比恢复更重要的是，我终于更清楚地知道：

以后该怎么不把它再弄坏一次。