OpenClawは、コンテキスト使用量を削減するためにエージェント履歴圧縮を実装しています。

コンテキスト管理の問題

Docker内でOpenClawを実行する場合、エージェントによる直接的なコード記述はコンテキストにノイズを充填します：ファイルの読み取り（5Kトークン）、編集の書き込み（500トークン）、テストの実行（200トークン）、スタックトレースの受信（3Kトークン）。単一のデバッグサイクルは10K-15Kトークンを消費し、そのほとんどはバグ修正後に無用となるコンソール出力とスタックトレースです。セッションごとに20-30回のデバッグサイクルがあると、コンテキストウィンドウ全体がノイズで消費されます。

ブレイン/ワーカーアーキテクチャ

解決策は責任の分離を含みます：OpenClawd（Docker内）は計画立案、作業のサブタスクへの分解、委任、調整を行うブレインとして機能します。Apple Silicon上のMLXでゼロコストで動作するQwen3.5-27Bを搭載したmacOSホスト上のローカルワーカーは、ファイルの読み取り、コードの記述、テストの実行、デバッグを行う手として機能します。これにより、ノイズの多い双方向通信はワーカーのコンテキスト内に留まり、ブレインは「タスク完了、変更されたファイルはこちら」といった最終結果のみを確認します。

圧縮戦略

ブレイン/ワーカーの分離があっても、オーケストレーターのコンテキストは依然として運用ドキュメントで充填されます：AGENTS（〜6.6Kトークン）、SOUL（〜1.5Kトークン）、LESSONS（〜10Kトークン）、計画/ウォークスルー（ディスク上で〜13Kトークン）で、作業開始前に合計20K-30Kトークンになります。セッションは100K-200Kトークンに達することがあります。

重要な洞察：完了した作業には生の詳細は不要です。サブタスクが完了すると、その生の履歴は無用の長物になります。エージェントが知る必要があるのは：タスクは何か、成功したか、どのファイルが変更されたか、エラーがあったかだけです。

実装の詳細

ステップ1: ライフサイクル境界の検出 - オーケストレーターは作業をライフサイクルを持つサブタスクに分解します：生成（エージェントがsessions_spawnまたはdelegate_taskを呼び出す）、実行（ツール呼び出し、推論）、完了（システムメッセージ「subagent 'task_name' completed」）。4パススキャナーがセッションJSONLを走査します：

• パス1: 生成イベントを検出
• パス2: 生成エラーを検出
• パス3: 完了マーカーを検出
• パス4: ライフサイクルごとのトークン数と期間を計算

これにより、完了したサブタスクに属するメッセージ範囲が特定されます。

ステップ2: 「エージェント言語」での要約（マスキング） - 要約は通常のエージェント出力のように見えるように生成され、オーケストレーターの期待するメッセージ形式（役割、コンテンツブロック、ツール呼び出し構造、親子IDチェーン）との互換性を維持します。これらのマスクされた要約が生のタスク履歴を置き換えます。

圧縮されたタスク要約の例：

── 圧縮タスク ──
origin: agent
task: MLXサーバーのアイドルタイムアウトを実装
outcome: success
result: MlxServerManagerに5分アイドルタイマーを追加。
リクエスト受信なし時、サーバーは自動アンロード。
files+: src/services/mlx_idle_monitor.py
files~: src/services/mlx_server.py, config.json
errors: none
tried_and_failed: threading.Timer — 競合状態
must_remember: MLXサーバーは明示的なワーカーリクエスト時のみ再ロード、ツール呼び出し時ではない
─────────────────

この〜100トークンの要約が5Kトークンの生のツール呼び出しと推論を置き換えます（99.2%削減）。要約は安価なLLM（Gemini Flash LiteまたはローカルMLX）によって生成され、生成失敗時のフォールバックメカニズムがあります。