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).

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

Status bar — проекция state, а не его копия

Модели не обязательно передавать весь канонический объект в удобной для хранилища форме. Agent Status Bar строит из него короткое производное представление для текущей точки решения: активная фаза, остаток бюджета, открытые подцели, проверенные runtime-предупреждения. Эта проекция может быть человекочитаемой и стоять у хвоста контекста, но не получает права обратной записи. При расхождении пересобирается status bar; канонический state по нему не «исправляется».

Различие важно и для аудита: state отвечает, что система считает истиной; сохранённый status bar — что именно увидела модель. Первый нужен для продолжения, второй — для расследования ошибочного решения.

Ролей у артефакта больше двух

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

Правило, которое из этого следует, формулируется наоборот привычному: меньше владельцев факта, а не меньше сигналов. Сокращать надо число мест, откуда факт берут как истину, а не число сохраняемых артефактов — сигналы дёшевы и нужны при разборе.

Второе правило закрывает главную ошибку: производное объясняет решение, но никогда не переопределяет свой источник. Рейтинг, сводка и отчёт пересобираются из канонического состояния; если они разошлись с ним, неверны они, а не оно. То же и с аудиторским снимком — он говорит, что агент видел, а не что было правдой.

Практическая проверка разложения — таблица «на какой вопрос где смотрят», где у каждого вопроса ровно одно каноническое место: что сделано, что измерено, что опубликовано, что сохранено надолго, что запланировано дальше, состоялось ли закрытие (Batch Close Protocol). Вопрос, у которого таких мест два, и есть будущее расхождение.

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

• Релевантность обнаруживается задним числом. Если важное наблюдение не попало в 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 — родственная сила и тот же риск преждевременной схемы
• Batch Close Protocol — где каноническое состояние обновляется и чем закрепляется факт завершения
• Agent Status Bar — ограниченная runtime-проекция state в контекст модели