OpenClawが応答しない

何もせず止まったままのOpenClawエージェントは、コストに次いで多い不満で、診断結果はほぼ必ず8つのうちのどれかです。上流では現在、約2分で診断にたどり着けるトリアージフローが提供されています。以下ではそれをわかりやすく説明し、続いてフォーラムを埋め尽くす原因と、Gatewayを誰かに代わりに運用してもらう場合に何が変わるのかを取り上げます。

最初の60秒

手順を順番に実行します：triage、status、gateway probe、gateway status、doctor、channels probe、そしてログを追います。正常な場合の結果は、到達可能、ランタイムが実行中、接続プローブがok、doctorのブロッキングエラーなし、すべてのチャネルがライブのトランスポートを報告、となります。triageコマンドは、エージェント、フォーラム、サポートにそのまま渡せる、サニタイズ済みの診断結果を書き出します。

よくある原因

• ペアリングが保留中：未知の送信者がメッセージを送り、誰もリクエストを承認していないため、設計どおりその送信者を無視しています。本番環境では、Gatewayがpairing-requiredの再接続ループにはまるという形で現れます。
• グループでのメンションゲート：メンションされるまでグループのメッセージを破棄し、そのことをログに記録します。
• 許可リストの不一致：送信者、チャネル、またはモデルがポリシーでフィルタリングされています。許可リストにないモデルを使うと、cronジョブやサブエージェントが何も言わずに失敗します。
• ツールプロファイル：minimalプロファイルはほとんど何も許可しないため、返答はしても行動はできません。
• プロバイダー：レート制限、GoogleのOAuthテスト用トークンのような期限切れの認証情報、または拒否で、ログには429や403として表示されます。
• ジョブの失敗に見える配信の失敗：作業自体は成功しているのに、Telegram側またはgateway側の401によって、cronジョブがfailedとマークされます。
• アップグレード後に無効化されたプラグインやチャネル：アシスタントは動いているのに、以前返答に使っていた入口が閉じています。
• Gateway自体：停止中、再起動中、または小さなホストでメモリ不足のために強制終了されています。

2時間、何もしないでただ止まっていた。

遅いのと止まっているのは違う

数分遅れて届く返信の原因は、たいていモデルが混雑しているか、長いコンテキストを読み直しているか、ハートビートのターンがセッションを占有しているかです。最後のものについてはOpenClawのハートビートで説明しています。それは、アイドル状態のエージェントが決して完全にはアイドルにならない理由でもあります。

マネージドホストで変わること

上の手順は、マシン上のシェルを前提としています。Dialiにはそのマシンがありません。アクティビティフィードにはプロビジョニング、アップデート、チャネルのイベントが表示され、ダッシュボードには一時停止、再起動、再インストールがあり、Gatewayはお客様に代わって監視されています。ペアリング、許可リスト、ツールプロファイルは、配管ではなくポリシーなので、引き続きお客様が設定します。その他についてはDialiのマネージドOpenClawホスティングで説明しています。

フォーラムに投稿する前に

• triageを実行し、その出力を添付します。助けてくれる人が必ず最初に求めるものです。
• 何かを再接続する前に、ペアリングとメンションゲートを確認します。
• ログで3つのシグネチャを探します：mention required、pairing request、blocked。
• 無反応ではなく遅いだけなら、まずプロバイダーとハートビートを確認します。

そして、この話に出てくるGatewayという言葉がずっとよくわからなかったなら、その説明はOpenClaw Gatewayの解説にあります。