OpenClaw升级,真是一个补丁一个坑

今天早上起来看手机，我的4个定时任务都死了，报了“Request timed out before a response was generated. Please try again, or increase agents.defaults.timeoutSeconds in your config.

好吧，别慌，到公司后对话openclaw机器人，让他抓一下日志给我看，

第一步：怀疑API不稳定

timeoutSeconds设置成900，手动触发Cron任务，依然timeout，连着三次，一样的错误。

先排除API问题。

第二步：怀疑 context 膨胀

抓日志查看定时任务带入的token数，40k左右，应该不会有啥问题，顶多就是ai思考慢一些返回。

第三步：读 session 历史，记录真相

我打开了那个 9:01 的 session，想看看模型到底卡在哪了。

然后我看到了这个：

9:00:01 | Cron 触发，isolated session 启动

9:00:01 → 9:01:29 | MiniMax API 调用，88 秒后超时

继续看，

LLM idle timeout (60s): no response from model

provider: minimax

model: minimax-m2.7

不是API超时，不是context太大，而是模型在60秒内，一个字都没吐出来。也就是我的思路是对的，在任务发送给LLM之后，并没有明确是LLM超时，而是在这段时间内，它没有返回，系统认为它超时了，终止了任务。

第四步：搜 GitHub Issues，一把锁定

有了上面的思路，直接让机器人查GitHub Issues，一把锁定

isolated cron idle timeout——Issue #61118，Root Cause 写得清清楚楚：isolated cron runs inherit the embedded runner's default 60s LLM idle timeout, even when payload.timeoutSeconds is set higher.

甚至有个关联 PR #60210，已经在修，但还没合进 2026.4.5。

第五步：读源码，亲眼确认凶手

打开本地编辑器，让Claude去查源码找真凶，一把揪住了，

const DEFAULT_LLM_IDLE_TIMEOUT_MS = 60000; // 60秒，硬编码

注意：这里读的是agents.defaults.llm.idleTimeoutSeconds，不是timeoutSeconds。

timeoutSeconds: 900 控制整个run的总时间，这个是正常工作的。

但 DEFAULT_LLM_IDLE_TIMEOUT_MS 控制的是"streaming 层第一次有token返回"的等待时间——模型 60 秒没吐字，照样被杀。

好了，搞定，怎么修？

临时修复（现在就能用）：

"agents":{"defaults":{"llm":{"idleTimeoutSeconds":0}}}

0 = 禁用这个检测。

改完重启gateway，观察delivery字段，连续3次 ✅ 就稳了。

永久修复：等PR #60210合并，升级OpenClaw。

经验教训：

报错信息里的"timeout"有很多种，API超时、context超时、LLM idle timeout，完全不是一回事。

timeoutSeconds不是万能的——它管不了streaming层的第一次 token 响应。

升级有风险，一把眼泪一把，分享给大家，希望有所帮助。