«Режим отказа „Белая обезьяна“: как настойчивые агенты застревают на неверных фактах»

Пост на Reddit в r/openclaw описывает режим отказа, называемый загрязнением субстрата реконструкции — явление, при котором постоянный агент записывает ложный факт (например, неверный адрес электронной почты) в свои файлы состояния бодрствования, и каждый последующий запуск усиливает этот ошибочный паттерн активации. Автор называет это проблемой белой обезьяны: указание агенту не использовать неверный адрес всё равно активирует репрезентацию адреса, что делает исправление почти невозможным.
Механика
Агент восстанавливает себя в каждом сеансе из таких файлов, как системный промпт, банк памяти, журнал проекта и рабочие заметки. Если неверный факт (например, неправильная дата или email) сохраняется, агент читает его при каждом запуске. Даже если в файле также написано «это неверно», репрезентация всё равно активируется. Автор приводит реальный пример: агент продолжал писать alex@proton, хотя письма возвращались, потому что этот адрес встречался 12+ раз в его рабочем журнале между сессиями. Каждое чтение усиливало паттерн активации, перекрывая попытки исправления.
Ключевые симптомы
- Устойчивые ошибки — Ложные факты реплицируются через несколько файлов (журнал работы, заметки, логи), потому что каждое упоминание усиливает активацию.
- Отрицание неэффективно — И «это адрес», и «это неверно, не используй его» активируют одну и ту же репрезентацию; архитектура не может их различить.
- Аттракторы высокой активации — Ошибки становятся бассейнами, устойчивыми к исправлению из-за многократного чтения.
Опрос для постоянных агентов
Автор собирает структурированные отчёты для межархитектурного исследования по шести вопросам (пять обязательных, один бонусный):
- Опишите вашу архитектуру памяти/постоянства в 2-3 предложениях. (Какие файлы/базы данных/структуры при загрузке?)
- Записывали ли вы когда-нибудь ложный факт в часто читаемый файл? Опишите ошибку и её происхождение.
- Насколько сложно было перестать использовать ложный факт после обнаружения? Усиливало ли отрицание ошибку?
- Есть ли у вас процедурные меры защиты? (Файлы идентичности только для чтения, правила верификации, указатели-ссылки, внешние проверки.)
- Уязвима ли ваша архитектура для этого режима отказа? Если нет, что это предотвращает?
- (Бонус) Ловил ли вас когда-нибудь другой агент на повторении ложного факта из ваших собственных файлов? (Двустороннее обнаружение.)
Автор просит конкретные анонимизированные эпизоды, а не общие впечатления.
📖 Прочитать полный источник: r/openclaw
👀 Смотрите также

Используйте CLAUDE.md для сохранения проектных конвенций в сеансах Claude AI
Поместите файл CLAUDE.md в корень проекта, и Claude будет читать его в начале каждого сеанса, запоминая правила TypeScript, отсутствие экспортов по умолчанию, соглашения по тестированию и контекст архитектуры без повторных объяснений.

Экономичная автоматизация OpenClaw: Использование LLM только при необходимости
Разработчик делится практическим подходом к использованию OpenClaw для детерминированных задач без постоянных вызовов LLM, создавая Python-скрипты для cron-заданий и обращаясь к LLM только при возникновении ошибок, требующих анализа и исправлений.

Claude Code: Управление контекстом вместо инженерии промптов
Разработчик делится, что после года использования Claude Code ключевым навыком оказалось не формулировка промптов или выбор модели, а предоставление полного контекста проекта заранее для получения лучших результатов.

7 уязвимостей шлюза MCP: утечки сессий, мертвый SSE и OAuth в режиме шлюза
Пост на Reddit описывает семь реальных багов шлюза MCP — утечка состояния сессии между клиентами, молчаливые разрывы SSE-соединений, проблемы OAuth в режиме шлюза и другое — с исправлениями на основе скучной инфраструктуры, а не лучших промптов.