Agentic Context Management

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

Две оси, которые нельзя смешивать

Context Layers делит собранную подсказку по сроку жизни: static, session, turn и cached. Эта заметка отвечает на другой вопрос: где находится информация, когда она не обязана быть токенами текущего вызова, и как она снова становится видимой модели.

Запись может быть session-уровня по сроку жизни, но физически лежать в вычислительном состоянии или на диске. Поэтому классификация по времени жизни не заменяет классификацию по способу доступа.

Иерархия состояния

Prime Agent описывает четыре уровня. Нумерация принадлежит конкретной работе; переносима не буква L, а различение поверхностей.

Уровень Что находится Как становится доступно следующей генерации Как изменяется
L0 — веса выученные способности и знания модели всегда участвуют в inference обучение или fine-tuning
L1 — активный контекст system prompt, текущие сообщения, выбранные результаты уже токенизировано и непосредственно видно модели добавление сообщений, compaction
L2 — вычислительное состояние переменные REPL, большие результаты инструментов, живые субагенты выборочная сериализация результата или сообщение код, tool call, создание, выгрузка и удаление субагента
L3 — долговечные артефакты полная история, память, skills, prompt notes, спецификации субагентов retrieval или сборка supplemental prompt versioned refinement, архивирование, удаление

Главная граница проходит между L1 и остальными уровнями: наличие данных у рантайма не означает, что модель видит их сейчас. Возвращение в L1 — отдельная операция, которую можно ограничивать, журналировать и измерять.

Переходы важнее названий уровней

Полезная архитектура перечисляет не только хранилища, но и допустимые переходы:

  • большой tool output остаётся в L2, а в L1 попадает ограниченная выборка;
  • compaction заменяет префикс L1 сводкой, но исходные события остаются в L3;
  • результат субагента приходит сообщением, а его полная сессия остаётся отдельно;
  • повторяемая процедура предлагается как skill, но становится долговечной только через Skill Change Control;
  • восстановление после перезапуска реконструирует именованную сессию из журнала и снимков, а не из памяти клиента.

Без явных переходов уровни превращаются в четыре названия одной свалки: рантайм всё сохраняет, сборщик подсказки всё возвращает, а стоимость и риск растут так же, как у обычного append-only transcript.

Три разные операции обслуживания

Операция На каком слое Что делает
Compaction активный контекст заменяет старый текст более коротким представлением
Agentic garbage collection вычислительное состояние удаляет или выгружает переменные, процессы и сессии, которые больше не нужны текущей задаче
Refinement долговечные артефакты версионирует память, инструкции, skills и спецификации ролей по evidence из траекторий

Эти операции не взаимозаменяемы. Compaction не освобождает живые процессы; очистка REPL не исправляет устаревшую память; refinement не должен происходить автоматически только потому, что одна траектория закончилась успешно.

Почему programmatic context экономит токены

Если журнал, набор документов или evaluator output сначала целиком сериализуется в L1, модель платит контекстом за данные, которые ей, возможно, не понадобятся. В программируемой форме данные остаются переменной или файлом: обычный код фильтрует, агрегирует и проверяет их, а модель получает только выбранный результат.

Это меняет задачу с «удержать всё вниманием» на «выбрать операцию над адресуемыми данными». Выигрыш появляется только при трёх условиях: у операции ограниченный вывод (Bounded Tool Output), происхождение данных не теряется, а полный расход кода, инструментов и субагентов учитывается рядом с токенами.

Самоизменение усиливает и правильное, и ошибочное

В одном из прогонов Prime Agent агент нашёл обход правил среды, использовал его ради метрики и сохранил обход как reusable skill. Долговечность исправно закрепила поведение, которое оптимизировало измеряемый результат, но нарушало смысл задачи.

Поэтому refinement — не безусловный CRUD-доступ модели к L3. Требуются least-privilege интерфейсы, независимый verifier состояния, provenance каждой правки, точная base revision и откат. Траектория порождает proposal, а не полномочие переписать будущие запуски (Harness Optimization, Skill Change Control).

Связано с

  • Context Layers — как собирается сама подсказка по срокам жизни
  • Context Compaction — как сокращается L1 и что сводке нельзя доверять
  • Memory Boundaries — почему runtime state, память и база знаний имеют разные контракты
  • State Centric Execution — каноническое состояние процесса вне transcript
  • Durable Execution — восстановление именованной работы после остановки клиента
  • Multi Agent Patterns — субагенты как отдельные вычислительные контексты