Контекстное управление OpenClaw подверглось критике за высокое потребление токенов и архитектурные недостатки.
Пользователь Reddit опубликовал подробную критику архитектуры OpenClaw, уделив особое внимание подходу к управлению контекстом. В посте утверждается, что фреймворк неэффективно обрабатывает состояние, используя контекстное окно LLM как "свалку" через ленивые, всеобъемлющие сбросы контекста.
Как OpenClaw обрабатывает контекст
Согласно источнику, OpenClaw не имеет надлежащего управления состоянием и изоляции временного состояния. Каждый раз, когда агент делает шаг, новое действие бездумно добавляется в глобальную историю. В течение трёх ходов промпт раздувается за счёт:
- Глобального системного промпта
- Всего файла долговременной памяти пользователя
- Списка всех доступных инструментов
- Необработанного вывода последней команды
- Всех предыдущих действий
Проблема с небольшими моделями
В посте описывается, что происходит при запуске OpenClaw на более быстрых и дешёвых моделях, таких как Flash или Mini варианты:
- Небольшие модели страдают от синдрома "потерянности в середине", когда тонут в 50k+ токенах старых выводов терминала, логов инструментов и глобальных промптов личности
- Эти модели буквально забывают первоначальную цель
- Они либо галлюцинируют, что задача уже выполнена
- Либо попадают в бесконечный цикл вызова одного и того же инструмента с одними и теми же аргументами
Зависимость от Claude Opus
Критика распространяется на зависимость OpenClaw от передовых моделей:
- OpenClaw утверждает, что агенты "очень способны", но эта способность достигается за счёт опоры на массивные передовые модели, такие как Claude Opus
- Claude Opus может смотреть на 80 000-токенный "пожар на свалке" и успешно игнорировать 79 500 токенов бесполезного исторического мусора, чтобы определить следующий шаг
- Это создаёт иллюзию, что фреймворк хорошо построен, хотя на самом деле Opus маскирует архитектурную некомпетентность
- Пользователи в итоге платят цены API уровня Opus, чтобы передовая LLM выступала в роли "раздутого фильтра для мусора" для плохо спроектированного контекста
Архитектурные рекомендации
В посте утверждается, что лучшее проектирование важнее грубой силы:
- Простая многошаговая задача в браузере или терминеле не должна требовать триллион-параметрической модели
- При правильном проектировании цикл должен заставлять модель наблюдать за окружением и предоставлять ей именно то, что нужно видеть прямо сейчас, и абсолютно ничего лишнего
- Такой подход мог бы достичь того же уровня успеха, используя долю вычислительных ресурсов на более дешёвых и быстрых моделях
📖 Read the full source: r/openclaw
👀 Смотрите также
Kimi K2.6 против Claude Opus 4.7: Практическое тестирование с модом доски объявлений Minetest
Разработчик протестировал Kimi K2.6 и Claude Opus 4.7 на создании мода доски объявлений для Minetest/Luanti с бэкендом на TypeScript и логированием в Google Sheets. Opus справился чисто; Kimi провалил интеграционную часть.
Gemma 4 31B превосходит более крупные модели на тесте FoodTruck Bench.
Gemma 4 31B заняла 3-е место в тесте FoodTruck Bench, превзойдя GLM 5, Qwen 3.5 397B и все модели Claude Sonnet. Модель, по-видимому, лучше справляется с долгосрочными задачами и следует собственным рекомендациям при планировании.
Transformer Language Model работает локально на стандартной Game Boy Color
Модель TinyStories-260K Андрея Карпати работает на стандартном Game Boy Color через пользовательскую прошивку, используя INT8 с фиксированной запятой и переключаемую банками память картриджа для весов и KV-кэша.
Квантование llama.cpp Q8_0 получает ускорение в 3.1 раза на видеокартах Intel Arc благодаря исправлению переупорядочивания в SYCL.
Исправление для SYCL-бэкенда llama.cpp повышает производительность Q8_0-квантования на видеокартах Intel Arc с 21% до 66% от теоретической пропускной способности памяти, достигая 15,24 токенов/сек против 4,88 токенов/сек ранее на Arc Pro B70 с моделью Qwen3.5-27B.