我的 Cron 显示 OK，但什么也没做

上周二，我的 OpenClaw agent 运行了一次安全审计。

控制面板显示绿灯。状态显示为：ok。没有错误，也没有警报。

但 agent 什么也没做。

agent 在任务执行期间崩溃了。发生了一个 MiniMax 过载错误。外部框架没有捕获到它。尽管 agent 失败了，框架却认为任务已成功完成。

直到三天后我手动检查会话转录（transcript）时，才发现了这个错误。

我需要一种方法来发现这些“静默崩溃”。为此，我编写了一个 30 行的审查脚本来解决这个问题。

问题所在

框架可以检测网络超时和身份验证失败，但无法检测 agent 轮次（turn）内部发生的情况。当子 agent 崩溃时，系统通常会产生一条特定的消息：“[assistant turn failed before producing content]”。

对于框架来说，这看起来就像是一条正常的回复。状态依然保持为 "ok"。这是一种静默失败（silent failure），也是最难发现的错误类型。

解决方案

我添加了一个脚本，用于检查实际的转录内容，而不仅仅是状态码。

该脚本会查找那个特定的失败字符串，并使用正则表达式从文本中提取出准确的错误消息。

这使得脚本能够显示真实原因，例如：

  • overloaded_error
  • rate_limit_exceeded
  • context_length_exceeded

一旦看到了错误详情，我就找到了根本原因。崩溃是由于模型回退链（model fallback chain）引起的。我移除了导致级联故障的免费回退模型。移除它之后，我的 cron 运行得更快、更可靠了。

结果

现在该脚本每晚都会运行。它会检查前一天的转录内容。如果发现静默崩溃，它会向我的 Telegram 发送警报。

我不再需要等上好几天才能发现错误，每天早上我都能看到它们。

教训

控制面板显示绿灯并不意味着你的 agent 正常工作了。框架状态和 agent 输出是两回事。

如果你运行自动化 agent，不要仅仅依赖状态码。要检查转录内容。构建一个工具来帮你检查转录内容。静默失败往往会造成最大的损失。

Source: https://dev.to/mrclaw207/my-openclaw-cron-said-ok-but-did-nothing-i-fixed-it-with-a-30-line-review-script-33ll

Optional learning community: https://t.me/GyaanSetuAi