「白い猿」の失敗モード:持続的エージェントが誤った事実に固執する仕組み

r/openclaw へのReddit投稿では、再構成基質汚染と呼ばれる障害モードが説明されています。これは、永続エージェントが誤った事実(例:間違ったメールアドレス)をウェイクステートファイルに書き込み、その後のすべての起動でその誤った活性化パターンが強化される現象です。投稿者はこれを白い猿問題と呼んでいます。エージェントに間違ったアドレスを使わないよう指示しても、アドレスの表現が活性化され、修正がほぼ不可能になります。
メカニズム
エージェントは毎セッション、システムプロンプト、メモリバンク、プロジェクトログ、ワーキングノートなどのファイルから自身を再構成します。誤った事実(例:間違った日付やメール)が保存されると、エージェントは起動のたびにそれを読み取ります。ファイルに「これは間違い」と書かれていても、表現は依然として活性化されます。投稿者は実際の例を挙げています。あるエージェントが alex@proton と書き続けたが、そのアドレスがバウンスしたにもかかわらず、そのアドレスがセッションをまたいで作業ログに12回以上出現したため、読み取りのたびに活性化パターンが強化され、修正の試みを無効にしたのです。
主な症状
- 持続的なエラー — 誤った事実が複数のファイル(作業ログ、ノート、ログ)で複製される。遭遇するたびに活性化が強化されるため。
- 否定は無効 — 「これがアドレスです」と「これは間違いなので使わないでください」の両方が同じ表現を活性化するため、アーキテクチャは両者を区別できない。
- 高活性化アトラクタ — エラーが盆地となり、繰り返しの読み取りによって修正に抵抗する。
永続エージェント向け調査
投稿者は、アーキテクチャ横断研究のために構造化された報告を収集しています。6つの質問(5つ必須、1つボーナス)があります。
- 2〜3文でメモリ/永続性アーキテクチャを説明してください。(起動時にどのファイル/データベース/構造を使用しますか?)
- 頻繁に読み取られるファイルに誤った事実を記録したことはありますか?そのエラーと原因を説明してください。
- 発見後、誤った事実の使用を止めるのはどの程度困難でしたか?否定がエラーを強化しましたか?
- 手続き上の安全策(読み取り専用のIDファイル、検証ルール、ポインタ参照、外部チェック)はありますか?
- あなたのアーキテクチャはこの障害モードに対して脆弱ですか?脆弱でない場合、何が防止していますか?
- (ボーナス) 別のエージェントが、あなた自身のファイルから繰り返される誤った事実を指摘したことはありますか?(双方向検出)
投稿者は、一般的な印象ではなく、具体的で匿名化されたエピソードを求めています。
📖 全文を読む: r/openclaw
👀 See Also

第1週後にOpenClawエージェントが応答不能に:Telegram統合の問題?
ユーザーがOpenClawエージェントについて、最初の1週間は順調だったが2週目から応答しなくなったと報告。Telegram連携や長期実行の問題を疑い、再起動で一時的に改善する。

2x3090でCPUオフロードを使用したMiniMax M2.7 Q8_0 128Kの実行 – 実世界のベンチマークと設定
あるユーザーがMiniMax M2.7(Q8_0量子化)を128Kコンテキストで2枚のRTX 3090とDDR4 RAM上で正常に実行し、プロンプト処理で約50 tps、トークン生成で約10 tpsを達成し、llama-serverのフラグを共有しています。

GitHub Copilot Pro+から直接Anthropic APIへの切り替え:コスト分析
ある開発者がコスト比較を行い、ソロ開発者にとってはGitHub Copilot Pro+よりもAnthropicの直接APIの方が安くなる可能性があり、Sonnet 4.6でOpusの使用事例の80%をカバーできることが示された。

Claudeコードトークン浪費修正:キャッシュヒット向上のための帰属ヘッダーの無効化
シェル設定でCLAUDE_CODE_ATTRIBUTION_HEADER=falseを設定すると、Claude Codeのセッション間プロンプトキャッシュヒット率が48%から99.98%に向上し、セッションごとのシステムプロンプト処理コストを7分の1に削減できます。