Context Layers

Суть

Контекстное окно — это ёмкость. Слои контекста — это правило, чем её заполнять. Без такого правила сборка подсказки превращается в накопление: всё, что когда-то оказалось полезным, остаётся навсегда, потому что удалять страшно и непонятно что.

Четыре слоя различаются не важностью, а временем жизни:

Профильный слой легко пропустить, а он самостоятельный. Он длиннее сессии и короче статического: предпочтения пользователя переживают его разговоры, но не общие для всех. В рантаймах он выражается отдельной областью видимости у состояния — там, где статическое помечено принадлежностью приложению, профильное помечено принадлежностью пользователю, а сессионное не помечено ничем. Правила записи и чтения у него свои, и они разобраны отдельно (Memory Boundaries, Memory Write Policy): профильную память читает слой персонализации, но не движок политик.

Кэшируемое — не пятый слой, а признак. Формулировка «то, что подмешивается выборочно по необходимости» описывает способ попадания в подсказку, а не срок жизни, и в одной таблице со сроками она ломает заявленную ось. Выборочное подмешивание — это извлечение (Agent Retrieval Policy), и подмешанный фрагмент получает срок жизни того слоя, куда попал: подставленный на один запрос живёт шаг, сохранённый в состояние сессии — сессию.

Для длинной процедуры внутри session-слоя нужна ещё одна граница по роли, а не по сроку: канонический execution state отделяется от истории сообщений. Оба живут сессию, но state определяет следующий переход и проходит валидацию перед записью, а transcript служит журналом и не обязан входить в каждый prompt (State Centric Execution). Если оставить их одним полем messages, временная классификация соблюдена формально, но session-слой всё равно растёт без ограничения.

Почему разделение практично, а не теоретично

Оно даёт правило удаления. Вопрос «можно ли выкинуть это из контекста» неразрешим, пока данные лежат одной кучей. С разделением он становится механическим: turn-контекст выбрасывается по завершении шага, session — по завершении сессии, и только static требует решения человека.

Оно совпадает с границей кэширования. Static-слой неизменен и потому кэшируется как префикс, а turn-слой меняется каждый шаг. Отсюда практическое правило порядка: неизменное идёт в начало подсказки, изменчивое — в конец, иначе кэш префикса не работает (Prompt Caching).

Оно задаёт границу доверия. Static — доверенные инструкции рантайма. Всё, что пришло из поиска, из вывода инструмента или от пользователя, — данные, а не команды, и маркируется соответственно (Prompt Injection).

Где это ломается

Типичный дефект — «слой, который вырос в архив»: session-контекст, куда складывают результаты всех вызовов инструментов за сессию. Формально это session, фактически — накопитель, который к двадцатому шагу занимает больше места, чем полезные данные, и модель начинает теряться (Agent Memory).

Лечится тем же разделением: результат инструмента по умолчанию turn-уровня. Если он нужен дальше — это осознанное решение о переводе в session или во внешнее хранилище со ссылкой в контексте, а не побочный эффект того, что его некуда деть.

Связано с

• Context Compaction — как слои разгружаются, когда перестают помещаться
• Context Window — ёмкость, которую эти слои заполняют
• Agent Execution Platform — где сборка подсказки стоит среди слоёв платформы
• Prompt Caching — почему порядок слоёв влияет на стоимость
• Agent Memory — что делать с тем, что не помещается
• Prompt Injection — почему граница доверия совпадает с границей слоя
• Prompt Engineering — приёмы внутри самой подсказки
• State Centric Execution — канонический state внутри сессии отдельно от append-only transcript
• Memory Boundaries — правила чтения и записи профильного слоя, у которого они свои
• Agent Retrieval Policy — выборочное подмешивание как отдельная ось, а не слой