OpenClawのコンテキスト管理は、トークン消費が多く、アーキテクチャに欠陥があると批判されている。

Redditユーザーが、OpenClawのアーキテクチャ、特にそのコンテキスト管理手法を詳細に批判する投稿を行いました。この投稿では、フレームワークがLLMのコンテキストウィンドウを「埋立地」として扱う、怠惰で全か無かのコンテキストダンプによって、状態を非効率に処理していると主張しています。

OpenClawのコンテキスト処理方法

情報源によると、OpenClawには適切な状態管理と一時的な状態の分離が欠けています。エージェントがステップを実行するたびに、新しいアクションは無条件にグローバル履歴に追加されます。3ターン以内に、プロンプトは以下の要素で膨れ上がります：

• グローバルシステムプロンプト
• ユーザーの長期的なメモリファイル全体
• 利用可能なすべてのツールのリスト
• 最後のコマンドの生の出力
• 以前のすべてのアクション

小型モデルにおける問題点

この投稿では、FlashやMiniなどのより高速で安価なモデルでOpenClawを実行した際に起こることを説明しています：

• 小型モデルは、5万トークンを超える古いターミナル出力、ツールログ、グローバルペルソナプロンプトに溺れると「真ん中で迷子」症候群に陥る
• これらのモデルは文字通り元の目的を忘れてしまう
• タスクが既に完了したと幻覚を起こすか
• まったく同じ引数でまったく同じツールを呼び出す無限ループに閉じ込められる

Claude Opusへの依存

この批判は、OpenClawの最先端モデルへの依存にも及びます：

• OpenClawはエージェントが「非常に有能」だと主張するが、この能力はClaude Opusのような巨大な最先端モデルに頼ることで得られている
• Claude Opusは8万トークンの「ゴミの山」を見つめ、7万9500トークンの役に立たない歴史的な膨張を無視して、次のステップを推測することができる
• これにより、フレームワークがうまく構築されているという幻想が生まれるが、実際にはOpusがアーキテクチャの無能さを隠している
• ユーザーは、設計の悪いコンテキストの「見栄えの良いゴミフィルター」として最先端のLLMを機能させるために、OpusクラスのAPI価格を支払うことになる

アーキテクチャに関する提言

この投稿では、力技よりも優れたエンジニアリングを主張しています：

• 単純な多段階のブラウザーやターミナルタスクに、1兆パラメータのモデルは必要ない
• 正しく設計されていれば、ループはモデルに環境を観察させ、今まさに見る必要があるものだけを、それ以外は絶対に与えないように強制すべきだ
• このアプローチにより、より安価で高速なモデルを使用して、計算量のほんの一部で同じ成功率を達成できる可能性がある