Cronは「OK」と言ったが、何も行わなかった
先週の火曜日、私のOpenClawエージェントがセキュリティ監査を実行しました。
ダッシュボードには緑色のライトが表示されていました。ステータスは「ok」となっており、エラーもアラートもありませんでした。
しかし、エージェントは何も行いませんでした。
タスクの途中でエージェントがクラッシュしていました。MiniMaxのオーバーロードエラーが発生していたのです。外側のフレームワークはそれを検知できませんでした。エージェントは失敗していたにもかかわらず、フレームワークは正常に完了したと判断していました。
このエラーに気づいたのは、3日後にセッションのトランスクリプトを手動で確認した時でした。
こうしたサイレント・フェイラー（静かな失敗）を見つける方法が必要でした。そこで、解決のために30行のレビュー用スクリプトを作成しました。
問題点
フレームワークはネットワークのタイムアウトや認証エラーは検知します。しかし、エージェントのターン内で何が起きているかまでは検知しません。サブエージェントがクラッシュすると、システムはしばしば特定のメッセージを出力します：「[assistant turn failed before producing content]」。
フレームワークにとって、これは通常のメッセージに見えます。ステータスは「ok」のままです。これがサイレント・フェイラーです。これは、最も発見が困難なエラーのタイプです。
解決策
ステータスコードだけでなく、実際のトランスクリプトの内容をチェックするスクリプトを追加しました。
スクリプトはその特定の失敗文字列を探します。また、正規表現を使用して、テキストから正確なエラーメッセージを抽出します。
これにより、スクリプトは以下のような真の原因を表示できるようになります：
- overloaded_error
- rate_limit_exceeded
- context_length_exceeded
エラーの詳細を確認したことで、根本原因が判明しました。クラッシュはモデルのフォールバック・チェーンによって発生していました。連鎖的な失敗を引き起こしていた無料のフォールバックモデルを削除したところ、cronの実行速度が上がり、信頼性も向上しました。
結果
現在、このスクリプトは毎晩実行されています。前日のトランスクリプトをチェックし、サイレント・フェイラーが見つかれば、私のTelegramにアラートを送信します。
もうエラーを見つけるのに何日も待つことはありません。毎朝、エラーを確認できます。
教訓
ダッシュボードが緑色だからといって、エージェントが動作したとは限りません。フレームワークのステータスとエージェントのアウトプットは別物です。
自動化されたエージェントを運用しているなら、ステータスコードだけに頼ってはいけません。トランスクリプトを確認してください。トランスクリプトを自動でチェックするツールを作りましょう。サイレント・フェイラーこそが、最も大きなダメージを与えるものなのです。
オプションの学習コミュニティ: https://t.me/GyaanSetuAi