State, context и memory: как управлять состоянием и памятью LLM-агента

16 октября 2026 · 18 минут

Как сохранять ход задачи, собирать контекст модели и переносить полезный опыт между сессиями. Подходы, инструменты и критерии проверки.

Обзор основан на первичной документации и исследовательских работах, проверенных 16 октября 2026 года. Классификация, схема и критерии выбора — инженерный синтез. Собственных сравнительных испытаний продуктов не проводилось. Основная область — приложения вокруг LLM; внутренние механизмы модели рассмотрены для разграничения понятий.

Три задачи управления

Для приложения на основе большой языковой модели (LLM) полезно проектировать три связанных механизма: состояние выполнения, сборку контекста и долговременную память. Они могут использовать одну базу данных, но требуют разных правил записи, чтения и проверки.

На узком экране таблицу можно прокрутить в сторону.

Это рабочее разграничение обязанностей, а не общепринятые непересекающиеся типы данных. В широком программном смысле память тоже является состоянием системы. LangGraph называет thread state краткосрочной памятью; Letta включает долгосрочную память в state агента. Поэтому сравнивать продукты лучше по гарантиям и поведению, чем по слову memory в названии. LangGraph persistence, Letta stateful agents.

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

Какие состояния нужно различать

В предлагаемой модели у приложения есть несколько самостоятельных объектов:

На узком экране таблицу можно прокрутить в сторону.

Срок хранения — отдельная ось. Процесс может ждать человека неделю; это всё ещё состояние процесса. Предпочтение может действовать один день; это всё ещё память о предпочтении. Аналогично область «пользователь / проект / организация», формат «текст / JSON / граф» и способ поиска не заменяют назначение записи.

Документальный ориентир: Pydantic AI отдельно описывает сохранение Conversation, checkpoints после шагов, память между диалогами и durable execution. Сохранённый диалог также содержит служебные данные, включая отложенные tool requests; один список видимых в интерфейсе реплик может быть недостаточен для продолжения. Persistence.

Следствие для архитектуры: утверждение агента «операция выполнена» должно иметь подтверждение. Текстовый план, summary разговора и запись в memory store не заменяют квитанцию внешнего сервиса или проверку артефакта.

State management: сохранение, переходы и восстановление

Для короткого чата часто достаточно сериализовать диалог. Для длительной задачи требуется явная модель переходов: например, queued → running → waiting → running → completed, с отдельными исходами ошибки и отмены. Событие меняет состояние через проверку допустимого перехода; модель может предлагать действие, а приложение проверяет его и фиксирует результат. Это рекомендуемый способ организации, а не обязательная схема конкретного SDK.

Checkpoint — сохранённый снимок, из которого можно продолжить работу. Журнал событий — последовательность произошедшего, из которой можно восстановить состояние при корректной модели событий. Durable execution добавляет правила продолжения и повторов после сбоев. Эти подходы можно сочетать; журнал не обязан быть полной реализацией event sourcing.

В LangGraph checkpointer сохраняет состояние thread, а Store обслуживает данные между threads. In-memory saver теряет содержимое при перезапуске процесса, поэтому само наличие объекта MemorySaver не доказывает устойчивость. Persistence.

У checkpoints LangGraph есть режимы exit, async и sync: запись при выходе, асинхронно во время следующего шага или до его начала. Replay от старого checkpoint повторно выполняет последующие узлы, включая вызовы модели и интерфейсов программирования приложений (API); это не отмена внешнего мира. Checkpointers.

Условный пример сбоя. Агент создал заявку во внешней системе, затем процесс завершился до записи результата. После запуска локальный state не знает, завершилась ли операция. Простое повторение может создать вторую заявку. Рекомендуемый контракт: стабильный идентификатор операции, идемпотентность на стороне получателя либо проверка результата по этому идентификатору, сохранённая квитанция и явное состояние «исход неизвестен» до сверки. Если API не даёт такого механизма, нельзя обещать отсутствие дублей одним checkpoint.

Это ограничение подтверждает Temporal: завершённые Activities не запускаются повторно при replay, но операция, не сообщившая результат серверу, может быть повторена. Поэтому Activities рекомендуют делать идемпотентными — повтор должен давать тот же внешний эффект. Activity definition.

Минимальный состав состояния для такого приложения, пример проектирования:

task_id: task-42
run_id: run-7
state_version: 12
schema_version: 1
phase: waiting_for_verification
goal_ref: task-42/spec
pending_operation:
  operation_id: task-42/create-ticket-1
  outcome: unknown
artifact_refs: []
next_action: reconcile_external_ticket

Для параллельной работы добавить контроль версии при записи, явного владельца изменения и правило объединения результатов. Скалярный статус нельзя бездумно объединять как список сообщений. При смене кода проверять совместимость старого состояния с новой схемой; при восстановлении — наличие файлов и актуальность внешних объектов. Перезапуск orchestration не восстанавливает автоматически диск, браузерную сессию или удалённый ресурс.

Context management: что передать модели сейчас

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

На узком экране таблицу можно прокрутить в сторону.

Текущая Claude API предлагает серверное сжатие по запросу и по порогу токенов; оба варианта на дату проверки обозначены beta. Context editing отдельно позволяет убирать выбранные старые блоки без summary. Это инструменты обслуживания контекста, их настройка сама по себе не задаёт жизненный цикл памяти приложения. Compaction overview.

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

Memory management: что переживает отдельную задачу

Полезно различать семантическую память о фактах, эпизодическую о событиях и результатах, процедурную о способах выполнения. Это функциональные аналогии, а не доказательство сходства с человеческим мозгом. Семантическая память не означает обязательный семантический поиск: факт можно найти по ключу, SQL или имени файла. Memory overview.

На узком экране таблицу можно прокрутить в сторону.

RAG (retrieval-augmented generation, генерация с поиском внешних сведений) обозначает получение внешних сведений для генерации ответа и может быть частью чтения памяти. Исходная работа объединяет параметрическую модель и внешнюю память с retriever. Lewis et al., RAG, v4. В этой схеме поиск по документации ещё не определяет, что извлекать из опыта, как разрешать противоречия и когда пересматривать вывод. Векторный индекс решает задачу поиска по близости; правила жизненного цикла данных проектируются отдельно.

Предлагаемый жизненный цикл памяти:

1. Захват: сохранить ссылку на исходное сообщение, событие или подтверждённый результат.
2. Отбор: решить, есть ли будущая польза и допустима ли запись в выбранной области.
3. Извлечение: сформулировать факт, эпизод или процедуру, сохранив условия и степень подтверждения.
4. Согласование: найти дубли и противоречия, определить замену либо оставить спор открытым.
5. Запись и индексирование: сохранить идентификатор, версию, происхождение и права.
6. Чтение: ограничить доступ, найти кандидатов, проверить применимость, собрать контекст.
7. Обновление и забывание: исправить или исключить запись, обработать зависимые сводки и индексы.
8. Оценка: проверить влияние на будущий ответ или действие, включая случаи, когда память надо проигнорировать.

Запись в основном ходе работы делает новые сведения доступными быстрее, но добавляет задержку; фоновая обработка разгружает ход работы, однако допускает отставание памяти. Это документированный компромисс. Writing memories. Для явного исправления пользователя рекомендуем сначала надёжно фиксировать само исправление; консолидацию и переиндексацию можно выполнять позже с наблюдаемым статусом.

Минимальная запись памяти, условный пример:

id: preference-17
kind: semantic
subject_id: user-example
scope: project-example
statement: "Для отчётов этого проекта использовать русский язык"
evidence_ref: conversation-4/message-8
evidence_kind: explicit_user_statement
valid_from: 2026-10-16
valid_to: null
recorded_at: 2026-10-16
status: active
supersedes: preference-9

Область здесь помогает определить применимость. Проверка доступа выполняется отдельно на уровне сервиса и хранилища: произвольный user_id из запроса не даёт права читать чужие записи. Для производной записи полезны derived_from с версиями источников; для процедуры — предусловия, отрицательный опыт и способ проверки результата. Истечение применимости и физическое удаление — разные операции.

Как связать всё в приложении

Ниже пример архитектуры приложения. Блоки обозначают обязанности; несколько блоков могут жить в одном процессе или PostgreSQL.

Условный процесс разработки поясняет разделение. State сообщает: «патч подготовлен, тесты ещё не выполнены». Контекст содержит цель, patch diff и подходящий способ запуска тестов. Память хранит: «при таких версиях зависимостей этот тест требует отдельной настройки». После запуска инструмент возвращает результат; только тогда меняется статус проверки. Успешный приём может стать кандидатом в процедурную память вместе с условиями и ссылкой на проверку.

Для следующей сессии нужно восстановить как состояние задачи, так и реальные файлы. Для новой похожей задачи переносится применимый опыт; прежний статус «тесты прошли» не переносится на новый код.

Карта реализаций на 16 октября 2026 года

Это выбор представителей разных обязанностей. Качество продуктов здесь не ранжируется; последний столбец задаёт условия проверки перед выбором. Лицензии, тарифы, регионы доступности и условия обработки данных требуют отдельного сравнения.

На узком экране таблицу можно прокрутить в сторону.

Два уточнения, меняющих чтение старых сравнений:

• В документации Letta прежние memory blocks находятся в разделе V1 SDK (legacy). Текущая основная модель описана через MemFS. Фоновое dreaming консолидирует уроки из разговоров; это описание процесса, а не измеренное доказательство улучшения. Memory & dreaming.
• Mem0 документирует истечение записи как исключение из обычного поиска, при этом получение по ID остаётся доступным. Нельзя считать это физическим удалением. Также нельзя по старому описанию ожидать автоматического обновления при каждом add. Текущая семантика add.

Инструменты поиска по файлам подробнее разобраны в обзоре баз знаний для ИИ. Объединение нескольких продуктов оправдано только различимыми обязанностями; два memory backend без понятного владельца записи усложнят исправление и поиск истины.

Что относится к внутренней памяти модели

KV cache сохраняет вычисленные key/value-представления токенов attention, чтобы не пересчитывать их при генерации. Это вычислительный механизм; его наличие не предоставляет приложению API исправления предпочтения пользователя или статуса задачи. Hugging Face: How caching works.

Параметрическая память — знания и навыки, отражённые в параметрах модели. Дообучение меняет параметры модели или добавленные обучаемые компоненты: например, LoRA сохраняет исходные веса и обучает низкоранговые матрицы. LoRA v2. Внешняя память меняет доступные модели сведения без такого обучения. В рамках этого обзора рекомендуем сохранять часто меняющиеся и требующие точечного исправления данные во внешнем адресуемом виде. Выбор fine-tuning для устойчивого поведения требует отдельного эксперимента.

Обучаемые модули памяти — ещё одно направление. Например, Titans исследует нейронный модуль долгосрочной памяти, работающий вместе с attention. Это изменение архитектуры модели, а не замена прикладного Store или workflow engine. Здесь проверен abstract первой версии, без воспроизведения результатов. Titans v1.

Как выбирать и измерять

На узком экране таблицу можно прокрутить в сторону.

У памяти минимум три независимых места отказа: нужное не сохранено; сохранено, но не найдено; найдено, но неверно применено. Отдельно проверяется актуальность и допустимость доступа. Поэтому качество retrieval и успешность конечной задачи следует измерять отдельно.

Первичные ориентиры оценки. LongMemEval проверяет извлечение сведений, рассуждение между сессиями и во времени, обновление знаний и отказ от ответа при недостатке данных; это benchmark разговорной памяти. MemoryArena связывает опыт предыдущих действий с выполнением будущих зависимых задач. Они отвечают на разные вопросы; высокий результат первого не доказывает полезность для второго. В этом обзоре использованы abstracts и метаданные, не проведён аудит всей методики. LongMemEval v2, 04.03.2025, MemoryArena v2, 17.09.2026.

Как сравнить подходы на своей задаче:

1. База: явный state, доступные исходники и артефакты, последние сообщения и чтение источников по запросу.
2. Та же база плюс компактная капсула продолжения / summary.
3. Та же база плюс отобранная межсессионная память с происхождением.
4. Диагностический вариант: нужное свидетельство подано напрямую, чтобы отделить ошибку поиска от ошибки применения.

Модель, инструменты, права, исходные сведения и условия задач фиксируются. Если память добавляет новые сведения, это отдельный фактор, а не чистое сравнение механизмов retrieval. Подготовка памяти проводится до открытия отложенных задач. Число и разнообразие повторов выбираются под цель эксперимента; универсальный минимальный размер выборки здесь не обоснован.

На узком экране таблицу можно прокрутить в сторону.

Основные метрики: успешность задачи, ошибочное применение памяти, правильность исправлений, корректное воздержание, число дублей внешних действий, задержка и полная стоимость. Стоимость включает извлечение, индексацию, хранение, retrieval, compaction, генерацию и участие человека. Результаты по качеству и затратам показывать раздельно, вместе с разбросом повторов.

С чего начать

Выберите один сценарий, который прерывается между сессиями и повторяет знакомый класс задач. Сначала проверьте продолжение, корректность внешних эффектов и актуальность файлов. Затем сравните варианты контекста и дополнительной памяти по протоколу выше. Так выбор инструмента будет опираться на наблюдаемую потерю и результат проверки.

В подборке о памяти собраны разборы отдельных подходов: от опыта организации до уроков, процедур и обновления контекста агента.

Автор: Данил Письменный · Дата: 16 октября 2026