OpenClawでどうしてこんなことが起きて、どうやって直せるのでしょうか... 私のボットは大量の繰り返しツール結果を次々と出し続け、重いエグゼクティブ作業をこなし、DMがいる共有セッションでデバッグループに陥り、10分間もスタックしてしまい、タイムアウトするかゲートウェイがクラッシュして再起動します。 これにより、メッセージのドロップ、ボットの応答なし、OOMが1時間に何度もクラッシュします。 ボットに委任しても、サブエージェントの結果はコンテキストウィンドウにダンプされます。 コーデックスに調査してもらったところ、以下のことが分かりました: • 56のツール結果≥150,000文字がすでに現在のセッション履歴に組み込まれています • プライマリモデルパス(Codex/OpenAI Oauth)では剪定が機能しません • 大規模なツールダンプを文脈に取り込むためのランタイム強制がない ・セッションメンテナンスは損傷の後片付けを担当しますが、それを防ぐわけではありません デフォルトのOpenClawの挙動が20万文字のキャラクターツール結果を文字起こしに流し込むべきではないと思います。 私の特定の環境では、セーフガードを無効にするか、ツール結果の切り捨てをスキップしているのかもしれません... ロスレスクローを使っているので、さらに悪化させてしまいます: 81MBのセッションファイル、31.6MBはツールの結果テキスト😬です 5万キャラ以上のツール結果が169件あります。1つは285kキャラ(sessions_listから)です。 ツールの結果をコンテキストメッセージから切り取る剪定ロジックもあります。 buildContextPruningFactory しかし、モデルは「キャッシュTTL」である必要があります。 対象となる提供者は以下の通りです: 人間的 ムーンショット ザイ 私の場合、ボットはAnthropic以外のプロバイダーではプルーニングコードが有効化されないと言います。 私はopenai-codex 5.3をよく使っているので、プルーニング設定中コードは存在しますが、静かに起動しません。 OpenAI Responses APIはサーバー側のコンパクト化を使い、OpenClawは直接的なOpenAIモデルに対してこれを自動で有効化するため、OpenAIは自社側でコンパクト化を処理します。 でも私はopenai-codex/*を使っていて、openai/*ではありません。Codex OAuthパスは別のランタイム(どうやらpi-ai)を経由しており、Responses APIではありません。 つまり: • Anthropicのみ>キャッシュ-ttlの剪定 • OpenAIサーバーサイドのコンパクト化>OpenAI APIのみ直接対応 • LCM/ロスレスクロー>は古いツールの結果を剪定しないと私の知る限り 私のボットはopenai-codexレーンにはどちらの剪定パスも入らないと主張しています。 そのため、緊急切断機能のtruncateOversizedToolResultsInSessionに過度に依存しすぎて、最後の手段として過剰に回復し、予防的な剪定や安全対策もないボットが残っています。 LCM/ロスレスクローは独自のツール結果管理を持たないため、巨大なトランスクリプトを引き継ぎ、DAGノードの要約に余計な作業をしなければなりません。 セッションの維持はなく、長時間のセッションなので、時間経過でトランスクリプトに制限が出ることはありません。その結果、以下の結果が続きます。 4,707件のツール結果が81MBのファイルに無限に溜まっており、実際にそれらをクリーンアップする実行時のメカニズムはありません。 ボットがデバッグを始めると、greppingや大量のテキストをメインセッションに押し込み始め、そのループに陥って死んでしまい、また同じことを繰り返しなければならず、問題が悪化します。 この問題にどう対処すればいいのか分からず、何層にも及んでいます。

@quinnzeda でも君の言う通りかもしれない...ただ、試す前に1週間休む必要があるかもしれません。