openclaw 6.6 修复 DeepSeek 定时 Wiki 编译问题

背景链接到标题

我在一台个人服务器上运行 OpenClaw，并使用 Memory Wiki 功能把本地知识库编译成可检索的结构化内容。这个编译动作原本由一个每天定时执行的 cron job 完成，任务内容很简单：触发 /wiki-compile。

这类任务长期运行正常。后来默认模型切换到 DeepSeek 后，定时任务开始失败，表面错误是：

LLM request failed.

一开始这个错误很容易被误判成 DeepSeek 接口不稳定。但后续排查发现，问题并不是 DeepSeek 全局不可用，也不是 Wiki 编译工具本身坏了，而是 OpenClaw 旧版本中 cron isolated agent 运行路径的 timeout 传递问题。

现象链接到标题

失败任务的形态大致如下：

payload.kind = agentTurn
message = /wiki-compile
model = deepseek/deepseek-v4-flash
sessionTarget = isolated

失败时的日志特征很稳定：

LLM request failed.
Request was aborted
This operation was aborted
stalled_agent_run
active_work_without_progress
activeWorkKind=model_call
lastProgress=model_call:stream_progress

更关键的是，失败发生在第一轮模型调用阶段：

还没有任何 tool call
usage 记录为 0
Wiki 编译命令本身尚未开始执行
表面上是 LLM request failed，本质上是模型流式响应被中断

这说明问题不在 Wiki 工具链，而在 cron 调用模型的运行路径上。

排查过程链接到标题

1. 先排除 Wiki 工具链问题链接到标题

我把 Wiki 编译拆成确定性的命令链执行：

openclaw wiki bridge import --json
openclaw wiki compile --json
openclaw wiki lint --json

命令链可以正常完成，并返回类似结果：

Daily Wiki Compile OK: pages=118, errors=0, warnings=70, report=.../lint.md

这证明 Wiki bridge、compile、lint 本身都是正常的。

2. 再排除 DeepSeek 全局不可用链接到标题

随后手动调用同一个模型执行 /wiki-compile，也能成功。

进一步测试后发现：

场景	结果
手动 agent 执行 `/wiki-compile`	成功
手动 agent 执行完整 cron 包装 prompt	成功
CLI `cron run --wait`	曾成功
scheduler 到点自动触发 isolated cron	失败

这组对比很关键：DeepSeek 不是完全不可用，Wiki 编译也不是完全不可用，问题集中在 scheduler 自动触发的 isolated cron agentTurn 路径。

3. 复现 scheduler 自动失败链接到标题

为了确认不是偶发错误，我临时创建了一个到点自动触发的测试任务，保持和原失败路径一致：

kind: agentTurn
message: /wiki-compile
model: deepseek/deepseek-v4-flash
thinking: off
sessionTarget: isolated

旧版本下，scheduler 到点自动触发后再次失败，耗时约数分钟，最终被判定为 stalled session，并中断模型请求。

失败特征和原始问题一致：

lastRunStatus = error
lastError = LLM request failed.
lastDeliveryStatus = not-delivered

至此可以确认：这不是偶发网络抖动，而是可复现的 cron 运行路径问题。

定位上游 issue 链接到标题

继续查 OpenClaw 上游 issue，发现一个高度匹配的问题：

[Bug]: cron jobs fails with "LLM request failed"

该 issue 的描述与本次现象非常接近：

cron job 中 DeepSeek 经常失败
手动聊天调用不报错
流式响应中途卡住
最终表现为 timeout 或 LLM request failed

上游对根因的说明是：cron 的显式 job timeout 没有被正确传递到 shared embedded-agent runner，导致它被 runner 内部的隐式 LLM idle limit 覆盖。结果就是：长一点的流式响应在 isolated cron 路径中被错误中断。

这正好解释了前面的所有现象：

为什么手动 agent 可以成功
为什么 Wiki 工具链可以成功
为什么只有 scheduler 自动 cron 更容易失败
为什么错误发生在模型调用阶段，而不是 tool call 阶段

修复方案链接到标题

方案一：把确定性任务改成 command cron 链接到标题

Wiki 编译本质上是确定性任务，不需要 LLM 参与。因此我先把生产任务改成 command payload：

set -e
openclaw wiki bridge import --json
openclaw wiki compile --json
openclaw wiki lint --json

这个方案有两个好处：

不再依赖模型是否稳定
编译结果更可预测，失败边界更清楚

验证结果：

Daily Wiki Compile OK: pages=118, errors=0, warnings=70

生产任务目前继续保留这种方式，因为它更适合 Wiki 编译这种纯工程动作。

方案二：升级 OpenClaw 到 6.6 链接到标题

根据官方 Updating 文档，推荐使用 openclaw update，因为它会识别安装方式、执行包更新、同步插件、重启 gateway，并运行 doctor 检查。

实际升级前先 dry-run：

openclaw update --tag 2026.6.6 --dry-run --json

dry-run 显示升级计划：

currentVersion: 2026.6.5
targetVersion: 2026.6.6
actions:
  - Run global package manager update
  - Run plugin update sync after core update
  - Restart gateway service and run doctor checks

随后执行升级：

openclaw update --tag 2026.6.6 --yes --json

升级结果：

before.version = 2026.6.5
after.version  = 2026.6.6

然后按官方文档执行验证：

openclaw --version
curl -fsS http://localhost:18789/readyz
openclaw gateway status --deep --json
openclaw doctor --lint --json

关键结果：

OpenClaw 2026.6.6
gateway ready = true
rpc ok = true
plugin version drift = none

升级后复测 DeepSeek cron 链接到标题

为了验证旧问题是否真的修复，我没有只依赖手动运行，而是重新创建了一个和旧问题一致的 scheduler 自动触发任务：

name: wiki-compile-deepseek-test
schedule: 13:15
payload.kind: agentTurn
message: /wiki-compile
model: deepseek/deepseek-v4-flash
thinking: off
sessionTarget: isolated
timeoutSeconds: 900

到点后自动触发成功：

lastRunStatus: ok
lastDurationMs: 15581
lastDeliveryStatus: delivered

这说明 OpenClaw 6.6 后，同样的 DeepSeek isolated cron agentTurn 路径已经可以正常完成。

最终状态链接到标题

当前保留两类任务：

生产用 Wiki 编译任务：每天早上运行，使用 command cron
临时验证任务：使用 DeepSeek agentTurn cron，到点自动触发验证修复结果

生产任务继续使用 command cron，是因为 Wiki 编译本来就是确定性工程任务，不需要让 LLM 参与调度。DeepSeek cron agentTurn 的验证成功，只说明旧问题已由版本升级修复。

经验总结链接到标题

这次排查的关键不是“换模型”或“加 fallback”，而是把现象拆开验证：

工具链是否正常
模型是否全局不可用
手动路径和 scheduler 路径是否一致
错误发生在模型调用前、调用中，还是 tool call 后
上游是否已有匹配 issue 和修复版本

最终结论是：

根因不是 DeepSeek 本身
根因不是 Wiki compile 工具
根因是旧版 OpenClaw cron isolated agentTurn 的 timeout 传递问题
升级到 OpenClaw 6.6 后，DeepSeek 定时 Wiki 编译路径恢复正常
对于确定性任务，command cron 仍然是更稳妥的长期方案

背景 链接到标题

现象 链接到标题

排查过程 链接到标题

1. 先排除 Wiki 工具链问题 链接到标题

2. 再排除 DeepSeek 全局不可用 链接到标题

3. 复现 scheduler 自动失败 链接到标题