OpenClaw внедряет сжатие истории агента для сокращения использования контекста.

Проблема управления контекстом

При запуске OpenClaw в Docker прямое написание кода агентом заполняет контекст шумом: чтение файлов (5 тыс. токенов), запись правок (500 токенов), запуск тестов (200 токенов) и получение трассировок стека (3 тыс. токенов). Один цикл отладки потребляет 10–15 тыс. токенов, в основном из-за вывода консоли и трассировок стека, которые становятся бесполезными после исправления ошибок. При 20–30 циклах отладки за сессию всё окно контекста заполняется шумом.

Архитектура «Мозг/Рабочий»

Решение заключается в разделении ответственности: OpenClawd (в Docker) выступает в роли мозга для планирования, разбиения работы на подзадачи, делегирования и координации. Локальный рабочий на хосте macOS, работающий на Qwen3.5-27B под управлением Apple Silicon через MLX с нулевой стоимостью, служит руками для чтения файлов, написания кода, запуска тестов и отладки. Это оставляет шумный обмен в контексте рабочего, а мозг видит только конечные результаты, например «задача выполнена, вот изменённые файлы».

Стратегия сжатия

Даже при разделении мозг/рабочий контекст оркестратора всё равно заполняется операционными документами: AGENTS (~6,6 тыс. токенов), SOUL (~1,5 тыс. токенов), LESSONS (~10 тыс. токенов) и планами/инструкциями (~13 тыс. токенов на диске), что в сумме составляет 20–30 тыс. токенов до начала любой работы. Сессии могут достигать 100–200 тыс. токенов.

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

Детали реализации

Шаг 1: Определение границ жизненного цикла — Оркестратор разбивает работу на подзадачи с жизненными циклами: Создание (агент вызывает sessions_spawn или delegate_task), Выполнение (вызовы инструментов, рассуждения) и Завершение (Системное сообщение «subagent 'task_name' completed»). 4-проходный сканер проходит по JSONL сессии:

• Проход 1: Поиск событий создания
• Проход 2: Поиск ошибок создания
• Проход 3: Поиск маркеров завершения
• Проход 4: Подсчёт токенов и длительности для каждого жизненного цикла

Это определяет диапазоны сообщений, принадлежащих завершённым подзадачам.

Шаг 2: Сводка на «языке агента» (маскирование) — Сводки генерируются так, чтобы выглядеть как обычный вывод агента, сохраняя совместимость с ожидаемым форматом сообщений оркестратора (роли, блоки содержимого, структуры вызовов инструментов, цепочки родительских и дочерних ID). Эти маскированные сводки заменяют исходную историю задач.

Пример компактной сводки задачи:

── СЖАТАЯ ЗАДАЧА ──
источник: агент
задача: Реализовать тайм-аут простоя для сервера MLX
результат: успех
итог: Добавлен 5-минутный таймер простоя в MlxServerManager.
Сервер автоматически выгружается при отсутствии запросов.
файлы+: src/services/mlx_idle_monitor.py
файлы~: src/services/mlx_server.py, config.json
ошибки: нет
попытки_и_сбои: threading.Timer — состояние гонки
необходимо_помнить: Сервер MLX должен перезагружаться только по явному запросу рабочего, а не при любом вызове инструмента
─────────────────

Эта сводка на ~100 токенов заменяет 5 тыс. токенов сырых вызовов инструментов и рассуждений (сокращение на 99,2%). Сводки генерируются дешёвой LLM (Gemini Flash Lite или локальной MLX) с механизмами отката при сбое генерации.