夜雨聆风今天早上起来看手机，我的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 响应。
升级有风险，一把眼泪一把，分享给大家，希望有所帮助。