State Centric Execution

Суть

Обычный агентный цикл на каждом шаге дописывает наблюдение, действие и рассуждение в историю сообщений, а затем снова передаёт её модели целиком. Вход шага растёт вместе с траекторией, и модель каждый раз заново реконструирует из прозы, где находится процесс.

State-centric цикл передаёт модели только три части:

неизменная процедура P + текущее состояние S_t + последнее наблюдение O_t
                              ↓
               рассуждение + patch ΔS_t + действие A_t

Рантайм валидирует ΔS_t, сливает его с состоянием и исполняет действие. Предыдущее рассуждение не входит в следующий prompt. Поэтому хранить state и работать только по state — разные свойства: checkpointer может исправно сохранять поле messages, которое растёт без ограничения и целиком отправляется модели (Durable Execution).

Контракт состояния

Рабочее состояние проектируется на домен, а не на отдельную задачу, и содержит ровно то, что влияет на следующий ход: достигнутые подцели, проверенные гипотезы, активные артефакты, текущую позицию, краткий результат последнего действия. Хорошее поле отвечает на вопрос «изменит ли это следующий выбор?»; если нет — ему место в журнале или внешнем артефакте.

Три обязательных свойства:

• достаточность — после удаления transcript следующий шаг остаётся корректным;
• ограниченность — размер каждого поля имеет потолок или политику вытеснения;
• проверяемость — схема и межполевые инварианты проверяются кодом до коммита.

Фиксированная JSON Schema сама по себе не даёт ограниченности. Массив tested_hypotheses и строка summary могут расти бесконечно внутри неизменной схемы. Поэтому заявленное O(1) на шаг верно только при инварианте |P| + |S_t| + |O_t| ≤ C; без него паттерн лишь убирает автоматическое накопление transcript.

Patch предлагает модель, коммитом владеет рантайм

Модель возвращает не новый state целиком, а дельту. Это снижает риск случайно переписать уже проверенные поля, но не снимает его: patch может удалить важный факт, нарушить переход состояния или быть синтаксически валидным и логически неверным.

Путь записи поэтому транзакционный:

1. разобрать patch по строгой схеме;
2. применить его к копии текущего состояния;
3. проверить межполевые и переходные инварианты;
4. при ошибке отклонить весь patch и вернуть модели адресный сигнал;
5. только после проверки атомарно записать новую версию и исполнить действие.

Проверять надо не только новое значение, но и разрешённость перехода: например, завершённая подцель не возвращается в pending без отдельного события, а подтверждение не исчезает до истечения срока. Это обычный Validation Loops, применённый не к финальному ответу, а к управляющему состоянию.

История удаляется из prompt, а не из системы

Отказ от transcript как рабочей памяти не означает отказ от наблюдаемости. Для аудита и отладки отдельно сохраняются версии состояния, принятые и отклонённые patch, действия, результаты инструментов и идентификаторы модели. Модель получает только актуальный срез; оператор сохраняет траекторию (Agent Audit Log).

Так разводятся две задачи:

Где паттерн не работает

• Релевантность обнаруживается задним числом. Если важное наблюдение не попало в state, следующий шаг его уже не увидит.
• Сама траектория является предметом задачи. Аудит, объяснение причины, provenance и часть отладки требуют истории, а не только текущего среза.
• Нет устойчивой доменной схемы. Для открытого исследования заранее неизвестно, какие признаки станут достаточными; слишком ранняя схема обрезает правильный путь (Schema Guided Reasoning).
• Несколько писателей. Одновременные patch требуют версий, детектора конфликтов и определённой семантики слияния; статья SKILL.state это не проверяет.

Практический компромисс — не заставлять один механизм играть все роли: канонический state для управления, bounded working notes для ещё не классифицированных наблюдений, внешние артефакты для объёмных данных и append-only trace для истории.

Что показала SKILL.state

Авторы сравнили цикл с полным prompt-history, rolling summary, stateful LangGraph-style baseline и вариантами с одинаковым токен-бюджетом. На InterCode CTF SKILL.state получил 54,2% против 46,4% у сильнейшего baseline; на синтетической задаче Warehouse при горизонте 100 шагов — 0,94 результата при примерно 65 тысячах суммарных входных токенов против 0,91 и примерно 1,06 миллиона у stateful baseline.

Эти числа показывают направление, но не становятся нормативами: препринт опубликован в августе 2026 года, независимой репликации пока нет, а часть экспериментов синтетическая. Особенно важна собственная диагностика авторов на меньшей модели: 68% ошибок обновления state были преждевременным удалением или перезаписью информации. Это подтверждает необходимость внешнего валидатора, а не надёжность модели как владельца состояния.

Связано с

• Context Compaction — чинит уже накопившуюся историю; state-centric цикл предотвращает её накопление в prompt
• Context Layers — state как отдельный канонический слой, а не архив session-сообщений
• Durable Execution — отвечает, переживёт ли state рестарт; здесь вопрос, что из него видит модель
• Validation Loops — проверка patch и допустимости перехода до коммита
• Agent Audit Log — transcript остаётся вне prompt как доказательная траектория
• Schema Guided Reasoning — родственная сила и тот же риск преждевременной схемы