Что помнит ИИ-агент: контекст, состояние и память

ИИ-агент «помнит» информацию не в одном месте. Во время текущего вызова языковая модель использует только данные, доступные в её контексте. Прогресс задачи, история сессии, постоянная память и рабочие файлы могут храниться отдельно — в состоянии приложения, базе данных, checkpoints или другом внешнем хранилище. Чтобы сохранённая информация снова повлияла на ответ или действие, система должна сделать её доступной модели.

Поэтому фраза «агент помнит» удобна для разговора, но технически скрывает несколько разных механизмов.

Контекст ≠ состояние ≠ память ≠ параметры модели.

Что на самом деле помнит ИИ-агент

Память ИИ-агента — не отдельная «область памяти» внутри большой языковой модели и не один файл, в который складывается всё, что происходило раньше.

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

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

Одна часть информации может находиться в текущем контексте модели. Другая — в состоянии выполняемой задачи. История разговора может храниться в рамках конкретной сессии. Отдельные факты — переживать её завершение. Большие результаты вроде таблиц, PDF или кода могут существовать как самостоятельные рабочие объекты.

Слово «память» в таком случае становится общим термином для механизмов, которые обеспечивают информационную непрерывность работы агента.

Сохранение данных и их доступность для модели при этом остаются разными вещами. Запись может находиться в базе или файле, не участвуя в текущем model call. Поэтому вопрос «что помнит ИИ-агент?» правильнее раскладывать на четыре части: что модель видит сейчас, какое состояние хранит приложение, что переживает завершение сессии и какие из сохранённых данных будут снова включены в работу.

Контекст модели: что ИИ видит прямо сейчас

Контекст модели — информация, доступная языковой модели во время конкретного вызова.

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

Именно этим набором информации LLM располагает в момент, когда формирует ответ или выбирает следующее действие.

Приложение при этом может хранить значительно больше данных, чем получает один model call.

task_id = 842
current_step = 4
completed_steps = 1, 2, 3
customer_id = 519
status = waiting_for_confirmation
last_tool_result = success
pending_action = send_report

Для следующего шага модели не обязательно видеть весь объект. Система может передать только: «Клиент подтвердил предыдущий этап. Следующий шаг — подготовить отчёт, но не отправлять его без дополнительного подтверждения».

Полный state сохранился, а в model context попало его полезное для текущего решения представление.

Что может попасть в текущий контекст

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

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

Сборка контекста может быть детерминированной частью приложения. Например, система программно добавляет перед каждым model call текущий статус задачи, ID рабочего объекта и действующее ограничение. В других случаях модель может вызвать инструмент или механизм retrieval и получить дополнительные данные уже в процессе работы.

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

Контекст отвечает на довольно узкий вопрос: какая информация доступна модели для текущего решения?

Именно поэтому то, что агент видит в конкретном вызове, не нужно смешивать со всем объёмом данных, которыми располагает система.

Почему контекстное окно не равно памяти

Контекстное окно определяет объём информации, который модель может учитывать в текущем контексте.

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

Но увеличить context window — не значит создать долговременную память.

Контекстное окно решает проблему текущей ёмкости, а память — проблему сохранения и повторного использования информации.

Если модель сегодня получила большой документ, длинный context window может позволить работать с большей его частью. После завершения сессии документ не становится постоянной памятью автоматически. Чтобы использовать его завтра, системе всё равно придётся сохранить файл или нужные сведения и снова сделать их доступными.

Большое окно также не решает вопрос отбора.

Capacity ≠ selection policy.

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

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

Поэтому стратегия «если помещается — передадим всё» способна увеличить объём контекста, но не качество памяти.

Состояние задачи: где хранится текущий прогресс

Состояние задачи (Task State) — структурированная информация о ходе выполнения.

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

task_id
current_step
completed_steps
results
errors
pending_actions
status

Такое состояние может существовать независимо от текущего контекста модели.

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

Особенно полезно различать authoritative state и его текстовое представление для модели.

approval_required = true

Этот структурированный флаг может быть источником истины, даже если старая summary сформулирована менее точно: «Задачу почти можно запускать».

То же самое со статусом оплаты, ID заказа, дедлайном или подтверждением пользователя. Текст внутри context помогает модели рассуждать, но критичные операционные значения лучше не превращать только в свободный пересказ.

State хранит состояние работы системы. Context предоставляет модели нужное представление этой работы.

Состояние сессии и история диалога

Состояние сессии (Session State) относится к конкретному разговору, thread или запуску агента.

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

История диалога при этом уже по смыслу: это последовательность сообщений и событий. Session State может включать историю, но не обязан сводиться только к ней.

Приложение может хранить историю текущего диалога или историю переписки в session storage и использовать её при продолжении этой же линии работы.

Пользователь
├── Session A: подготовка договора
├── Session B: аналитический отчёт
└── Persistent user data

Поэтому session-level history и user-level memory не следует автоматически смешивать.

Фраза «агент сохраняет контекст между сессиями» удобна, но технически упрощает процесс. Обычно сохраняется не прежнее context window как единый объект, а история, state или другие данные, из которых при следующем запуске можно собрать новый контекст.

Новая сессия получает нужную непрерывность без обязательного восстановления всего предыдущего model context.

Долговременная память ИИ-агента: что сохраняется между сессиями

Долговременная, или постоянная, память (Persistent / Long-term Memory) предназначена для данных, которые должны переживать текущую сессию.

В русскоязычных материалах тот же слой нередко называют долгосрочной памятью ИИ-агента. Конкретная терминология зависит от платформы и framework, поэтому эти формулировки не стоит воспринимать как единый отраслевой стандарт.

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

Данные могут храниться в базе, memory store, файлах или другом persistent storage.

Но хорошая долговременная память требует не только политики чтения, но и политики записи.

Не каждое сообщение пользователя заслуживает сохранения между сессиями.

Фраза «Сегодня сделай таблицу вертикальной» может относиться только к текущей задаче. А правило «Во всех отчётах этого проекта используй такую структуру» уже потенциально относится к проектной памяти.

Если сохранять всё подряд, persistent memory быстро превращается в накопитель случайных, противоречивых и устаревающих наблюдений.

• что можно записывать;
• когда запись обновляется или заменяется;
• когда она перестаёт быть актуальной;
• когда её нужно удалить.

Такой подход требует не только сохранять данные, но и проверять, остаются ли они актуальными.

Запись в постоянной памяти также не означает, что модель теперь знает её всегда. В новом запуске система должна определить scope, актуальность, права доступа и релевантность записи, прежде чем сделать её частью model context.

Кратковременная и долговременная память — полезное, но грубое деление

Популярное разделение на кратковременную и долговременную память удобно для первого объяснения, но слишком грубо для архитектуры.

Нельзя универсально считать context window кратковременной памятью, а vector database — долговременной.

В разных системах short-term memory может включать историю thread или session state, а постоянные данные способны храниться в обычной БД, файлах или другом storage.

Для технического разбора точнее разделять контекст модели, состояние задачи, состояние сессии и persistent memory.

Состояние, память или файл: где хранить разные данные

Рабочие артефакты (Working Artifacts) особенно важны в длинных задачах.

Если агент создал большой отчёт, таблицу или программный код, нет необходимости постоянно копировать весь объект в state или context. Файл можно сохранить отдельно и вернуть модели целиком или частично, когда он потребуется.

report_status = draft

report.xlsx

Это разные сущности. Первая описывает состояние работы. Вторая является самим рабочим объектом.

Как сохранённая информация снова попадает в контекст

Информация, лежащая во внешнем хранилище, становится полезной модели только после того, как система выбрала её и сделала доступной в текущем model context.

ВНЕШНЕЕ ХРАНИЛИЩЕ
        ↓
ВЫБОР ДОПУСТИМЫХ И РЕЛЕВАНТНЫХ ДАННЫХ
        ↓
СБОРКА КОНТЕКСТА
        ↓
ЯЗЫКОВАЯ МОДЕЛЬ

В конкретной реализации проверка прав может происходить на разных этапах — до чтения данных, во время запроса к storage или после получения кандидатов. Схема показывает логику, а не обязательный порядок API-вызовов.

Retrieval здесь стоит понимать широко: запись можно найти по user_id, project_id, ключу, SQL-запросу, прочитать из state, открыть конкретный файл или найти семантически.

Retrieval ≠ обязательно vector search.

Семантический поиск — один из возможных механизмов, а не обязательное свойство памяти агента.

Сохранено ≠ извлечено ≠ разрешено ≠ передано в контекст.

RAG также может участвовать в получении внешних данных, но не является синонимом памяти. Task State, Session State и Persistent Memory могут существовать без отдельной RAG-архитектуры.

Суммаризация и сжатие: как управлять длинной историей

По мере роста сессии передавать модели всю предыдущую историю становится всё менее удобно.

Суммаризация (Summarization) позволяет заменить часть старых сообщений компактным представлением.

Например, длинная последовательность решений может быть сведена к: «пользователь выбрал вариант B; вариант A отменён; отчёт нужно подготовить до пятницы».

Такой summary легче включить в новый context.

Но суммаризация по определению теряет часть исходных деталей.

История «клиент выбрал A → отменил A → выбрал B → вариант B действует только до пятницы» может превратиться в «клиент рассматривал варианты A и B».

Для понимания общей темы этого достаточно. Для продолжения рабочего процесса — нет.

полная история
→ summary 1
→ summary 2
→ summary 3

Если новое резюме строится уже на предыдущем сокращённом представлении, потерянная деталь автоматически не возвращается.

Поэтому ID, статусы, дедлайны, разрешения и pending actions лучше хранить как структурированное состояние, а не только как текстовую summary.

Summary ≠ authoritative Task State.

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

Сжатие уменьшает объём передаваемых токенов и помогает не держать всю историю в активном контексте. При этом экономия токенов сама по себе не является гарантией, что summary сохранила все критичные данные.

Контрольные точки (Checkpoints): как агент продолжает незавершённую работу

Контрольная точка (Checkpoint) — сохранённый снимок состояния выполнения, из которого систему можно продолжить после паузы, сбоя или вмешательства человека.

Checkpoint может фиксировать значения state, позицию workflow и незавершённые действия.

Checkpoint отвечает: «Где остановилась задача?»

Persistent Memory отвечает: «Какую информацию стоит сохранить для будущего?»

Восстановление checkpoint не означает автоматического отката внешнего мира.

1. агент отправил письмо;
2. почтовый сервис подтвердил отправку;
3. workflow упал;
4. сохранённый checkpoint ещё считает send_email незавершённым;
5. выполнение восстановилось.

Если система слепо повторит pending action, письмо может уйти второй раз.

То же относится к созданию заказа, изменению записи CRM или другой операции с внешним эффектом.

Контрольная точка восстанавливает сохранённое внутреннее состояние workflow, но не возвращает внешний сервис назад во времени. После retry или recovery критичные операции полезно сверять с фактическим результатом во внешней системе.

Checkpoint поэтому не равен ни conversation history, ни долговременной памяти.

Ошибки памяти ИИ-агента: устаревшие и конфликтующие данные

Агент ошибается не только потому, что нужная информация отсутствует. Причиной может стать и сохранённое состояние, которое больше не соответствует реальности.

Устаревшая память

Раньше проект использовал API v1. Позже он перешёл на API v2. Но в persistent memory осталось:

project_api = v1

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

То же происходит со статусами клиентов, версиями документов, правилами проекта, тарифами и другими изменяемыми сведениями.

Для такой информации важен не только value. В конкретной реализации запись может дополнительно содержать:

source
updated_at
scope
version
expires_at

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

Некорректное состояние

Другая ситуация возникает, когда внутреннее представление задачи перестаёт соответствовать её фактическому состоянию.

Task State может считать операцию незавершённой, хотя внешний сервис уже её выполнил. После восстановления старой контрольной точки система может попытаться повторить действие. Две ветки workflow способны записать несовместимые значения.

Термин state corruption встречается в техническом контексте, но его не стоит представлять как единую стандартизированную категорию для всех agent frameworks.

Для операций с внешним эффектом особенно важно не считать внутреннюю запись окончательным доказательством результата. После retry, recovery или восстановления checkpoint критичное состояние полезно подтверждать фактическим ответом или текущим состоянием внешней системы.

Кому принадлежит память и кто имеет к ней доступ

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

Запись может относиться к текущей сессии, конкретному пользователю, проекту, workspace или более широкой рабочей среде.

Это её scope.

/customer-A/contracts/contract.pdf

Файл может существовать в общем storage, пока текущий агент работает с Customer B. Сам факт существования файла не означает, что его нужно извлечь или включить в новый контекст.

При этом scope и права доступа — не одно и то же.

Scope определяет, к какой области относится информация.

Authorization определяет, имеет ли конкретный пользователь или процесс право получить её сейчас.

scope = project_A

Даже правильный scope не гарантирует, что любой участник Project A должен иметь доступ к конкретной записи.

Для персональных данных и проектной информации особенно важны scope и контроль доступа. Поэтому архитектура памяти должна учитывать и область принадлежности данных, и фактическое разрешение на их использование.

Здесь memory architecture уже соприкасается с безопасностью ИИ-систем. Threat models, memory poisoning, prompt injection и data exfiltration требуют отдельного разбора и выходят за границы этой статьи.

Память ≠ история чата ≠ RAG ≠ знания модели

База знаний и память агента — не одно и то же. База знаний обычно выступает внешним корпусом предметной информации, тогда как memory layer помогает сохранять непрерывность конкретного пользователя, проекта или работы агента. В отдельных архитектурах эти слои могут использовать общее хранилище или общий retrieval-механизм.

Если система запомнила «пользователь предпочитает отчёты в XLSX», языковая модель от этого не дообучилась и её параметры не изменились.

Запись существует во внешнем по отношению к LLM слое. Чтобы использовать её позже, приложение должно снова получить данные и сделать их доступными модели.

Memory ≠ Model Weights.

RAG и база знаний могут участвовать в информационной архитектуре агента, но не определяют память целиком.

Главный вывод

ИИ-агент не хранит всю информацию «в голове».

Модель работает с текущим контекстом. Приложение поддерживает структурированное состояние выполнения. Сессия сохраняет текущую линию взаимодействия. Постоянная память переносит выбранные сведения между сессиями. Файлы и другие рабочие артефакты могут жить отдельно.

Когда информация снова нужна, система выбирает подходящие данные, учитывает их актуальность и права доступа и формирует новый model context.

Хорошая память — это управляемая система хранения, актуализации, извлечения и доступа к информации.

FAQ

Что такое память ИИ-агента?

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

Почему ИИ-агент забывает информацию?

Информация могла выпасть из текущего контекста, не быть сохранена, не быть извлечена при следующем запуске, оказаться вне разрешённого scope или потерять детали после суммаризации. Такое «забывание» не означает, что модель потеряла знания, полученные при обучении.

Сохраняется ли контекст между сессиями?

Не обязательно. Обычно система сохраняет историю, state или другие данные, а при следующем запуске собирает из них новый контекст. Само context window предыдущего model call не нужно считать долговременной памятью.

История чата — это память ИИ-агента?

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

Можно ли перенести память ИИ-агента в другой сервис?

Иногда — частично. Это зависит от того, где находятся данные: в истории сессии, state, базе, файлах, persistent memory или конфигурации приложения. Простая выгрузка чатов поэтому не всегда переносит всю рабочую память системы.

RAG — это память ИИ-агента?

Нет. RAG — способ получить информацию из внешнего источника и добавить её в текущий контекст. Retrieval может использоваться внутри memory architecture, но память агента включает также state, session data, persistent storage и другие механизмы.

Память агента меняет знания языковой модели?

Нет, если речь идёт о persistent memory во внешнем хранилище. Запись факта в БД или memory store не меняет параметры модели. Для повторного использования этот факт нужно снова сделать доступным LLM.

Может ли ИИ-агент иметь долговременную память без векторной базы?

Да. Долговременные данные могут храниться в обычной базе, файлах, key-value storage или другом persistent storage. Векторный поиск полезен для некоторых сценариев semantic retrieval, но не является обязательным условием памяти агента.