Использование меньшей модели в качестве гигиенического слоя во время выполнения повышает надежность агента OpenClaw.

Проблема: Неряшливые ответы ухудшают работу долго работающих агентов

При локальном запуске OpenClaw на Mac Studio M4 (36 ГБ) с Qwen 3.5 27B (4-бит, oMLX) в качестве домашнего агента модель не теряла способностей со временем — она становилась неряшливой. Конкретные проблемы включали:

• Утечки вызовов инструментов в виде сырого текста вместо структурированного использования инструментов
• Просачивание мыслей планирования в финальные ответы
• Повторение результатов инструментов и текста политики обратно пользователю
• Некорректные выходные данные, отравляющие контекст и вызывающие деградацию с каждым последующим ходом

Основная проблема заключалась не в возможностях, а в гигиене времени выполнения: модель знала, что делать, но не справлялась с правильным поведением в среде выполнения OpenClaw.

Решение: Четырехуровневая архитектура для гигиены времени выполнения

Разработчик реализовал четырехуровневый подход, который оказался эффективнее простого использования большей модели:

• Суммаризация: Сжатие контекста через lossless-claw (на основе DAG, freshTailCount=12, contextThreshold=0.60). Это дало самое значительное улучшение.
• Шериф: Проверки по регулярным выражениям и эвристикам, которые отлавливают некорректные ответы до их попадания в OpenClaw. Это предотвращает превращение утекшей разметки инструментов, болтовни планировщика и сырого JSON в устойчивый контекст.
• Судья: Меньшая, более дешевая модель, которая классифицирует пограничные выходные данные как «валидный финальный ответ» или «мусор». Эта модель не для интеллекта, а для гигиены времени выполнения — это иммунная система, а не второй мозг. Она также обрабатывает всю суммаризацию для lossless-claw.
• Оземпик (внутреннее название): Агрессивная очистка памяти, которая гарантирует, что модель в будущих ходах перечитывает только запросы пользователя, финальные ответы и сжатые факты, полученные от инструментов — а не болтовню планировщика, сырой JSON инструментов, артефакты повторных попыток или внутренний диалог о политике.

Почему это лучше, чем использовать большую модель

Одна модель должна одновременно решать задачи, поддерживать форматирование, управлять связностью контекста, избегать самоотравления собственными выходами и восстанавливаться после плохих выходных данных — что особенно сложно при локальных уровнях квантования. Разделение обязанностей, когда основная модель выполняет работу, а меньшая модель поддерживает гигиену времени выполнения, оказалось эффективнее, чем добавление большего количества параметров.

Результат: Устойчивая работа без сбросов

Этот подход позволил перейти от необходимости сбросов /new каждые 20-30 минут к устойчивой работе в одной сессии на Mac Studio M4 с 36 ГБ ОЗУ, полностью локально, без вызовов API.