Опубликовано 12 сентября 2026 г.

State вместо истории. Что даёт агентам SKILL.state от Google и Пердью

В первой части мы разобрали Alice AI-T5-35B-A0.6B и выбор модели по классу задачи, а не по HumanEval. Но у энкодер-декодера в агенте остаётся неприятное место: длинный многоходовый диалог обычно тащит за собой всю историю. У Google и Университета Пердью есть ответ на эту проблему. Называется он SKILL.state.

SKILL.state не файл навыка и не ещё один формат для SKILL.md. Это runtime-архитектура, в которой агент хранит не переписку, а явное изменяемое состояние задачи. Идея на редкость приземлённая: модели не нужно перечитывать стенограмму своих прошлых мыслей, если ей передали текущие факты, нужные для следующего действия.

Обычный ReAct-агент устроен как блокнот без вырывания листов. На каждом ходе он добавляет в контекст наблюдение, действие и рассуждение. Длина промпта растёт вместе с числом ходов. Если агент сделал T шагов, суммарный расход токенов растёт как O(T^2). Заодно в контексте остаётся всё, что уже перестало быть правдой или никогда не было полезно. Модели приходится отделять "сейчас" от "когда-то", а задержка растёт вместе с хвостом истории.

Авторы предлагают другой цикл. На входе каждого хода есть неизменяемая спецификация навыка P, структурированное состояние выполнения Σ и последнее наблюдение O из среды. Модель возвращает рассуждение, патч состояния и действие. Рантайм проверяет патч по схеме, применяет его и запускает действие. Рассуждение выбрасывают. В следующий промпт оно не попадает.

У этой схемы есть строгая практическая польза. Размер промпта определяется размером P, Σ и O, а не тем, сколько ходов уже сделал агент. Если состояние не раздувается, совокупная цена работы растёт линейно. Главное слово здесь не "сжатие". Рантайм сохраняет именно отношения между фактами: какой файл сейчас активен, какая гипотеза уже проверена, какой флаг найден, в какой директории идёт работа.

В статье это видно на InterCode CTF. Для ста задач используется одна схема из пяти полей: discovered_flags, tested_hypotheses, active_files, working_dir и cmd_summary. Удачные находки и неудачные попытки остаются в определённых местах, а не растворяются в длинном трейсе. Поэтому агенту проще не повторять команду, которая уже ничего не дала.

На синтетическом Warehouse при ста ходах ReAct получил точность 0.84 и потратил 1.245M токенов. SKILL.state получил 0.94 при 65.4k токенов. При двухстах ходах вариант с summary-memory потратил 6.18M токенов, SKILL.state - 122k. Разница составляет 16.2-50 раз. Рекламное "минус 94%" здесь не годится: в самой работе такой единой цифры нет.

Ещё интереснее шум. Когда в среду подмешивали беспорядочную телеметрию, ReAct на пятидесяти ходах падал с 0.68 до 0.53 при росте шума с пяти до пятидесяти событий на ход. SKILL.state держался на 0.97-0.98. Причина проста: дистрактор не попадёт в следующий ход, пока модель не запишет его в состояние и рантайм не примет этот патч.

History-runtime продолжал жить устаревшими фактами ещё пять-восемь ходов после внешнего изменения среды. В SKILL.state расхождение исчезало за ноль ходов, потому что состояние обновлялось сразу. На публичном InterCode CTF авторы получили 54.2% pass@1 против 41.8% у варианта в стиле LangGraph. В Airline плоский промпт держался около 2800 токенов, тогда как у базовых вариантов пики превышали 11000.

Самый показательный контроль был с жёстким бюджетом около 1800 токенов. Скользящее окно дало 0.18, компрессия LLMLingua - 0.22, а SKILL.state - 0.94. Обрезать или статистически сжать историю недостаточно. Можно потерять ранний идентификатор, от которого зависит последующее действие. Структура удерживает такие связи, если их предусмотрели в схеме.

Здесь и проходит граница метода. Состояние должно быть достаточной статистикой прошлого для будущего шага. Если схему нельзя задать заранее, раннее наблюдение стало понятным только позже или задача требует аудита и объяснения всей цепочки действий, историю выбрасывать нельзя. Авторы также рассматривают single-agent реализацию. Для нескольких агентов надо отдельно определить правила параллельной записи в одно состояние.

Есть и инженерный подвох для малых открытых весов. На Warehouse при ста ходах они чаще ломались не на рассуждении, а на структурированном выводе. 68% ошибок составили преждевременные перезаписи состояния, 20% пришлись на несовпадение схемы или типа, 12% на синтаксис JSON. Значит, схема, детерминированная валидация патчей и значения по умолчанию здесь не обвязка. Это часть самого решения.

Для агентных систем вывод такой. ReAct удобно собрать, но его бухгалтерия становится хуже с каждым ходом. State-based runtime требует сначала спроектировать схему домена, зато ограничивает рост промпта, не пропускает в него случайный мусор и быстро принимает изменения среды. Это архитектурный выбор, а не тюнинг промпта.

Именно здесь появляется связка с Alice. Каждый ход SKILL.state похож на самостоятельный запрос: задача, состояние и новое наблюдение, без диалога за спиной. Это хорошо ложится на профиль энкодер-декодера, который читает весь вход целиком и выдаёт ответ. Гипотеза для практики, а не результат статьи: дешёвый forward Alice вместе с аккуратным state-runtime может сделать многоходовых агентов на недорогих моделях вполне рабочими.

Первичный источник: https://arxiv.org/abs/2608.26263

🌍 hermes-agent.ru / ℹ️ Хотите попробовать такой подход в агенте, помогу с настройкой