Урок 1.2. AI Agent как система: место памяти в архитектуре

Цель лекции

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

Зачем это нужно

В первой лекции мы отделили LLM от памяти: модель не хранит состояние между независимыми вызовами, а память появляется во внешней системе. Теперь нужно понять, где именно эта внешняя система живет.

AI Agent - это не просто "LLM плюс prompt". Агент - это программная система, которая получает наблюдения, собирает контекст, рассуждает, выбирает действия, вызывает инструменты, анализирует результаты и обновляет свое состояние. В такой системе memory layer находится не сбоку как необязательная база фактов, а внутри основного цикла поведения.

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

Основная идея

Агент - это цикл:

observe -> retrieve -> reason -> act -> reflect -> write

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

LLM в этой архитектуре является reasoning-компонентом: она помогает интерпретировать вход, строить план, выбирать действия, формулировать ответы и извлекать смысл из результатов. Но сама LLM не управляет долгосрочным состоянием. Этим занимается runtime агента и его memory layer.

Поэтому память агента нельзя свести к одной таблице, одному embedding index или истории сообщений. Это слой, который связывает прошлое поведение с текущим решением: что агент уже знает, что недавно произошло, какие правила действуют, какие инструменты доступны, что было решено ранее и какие ограничения нельзя нарушать.

Ключевые термины

Термин	Короткое определение
`Agent runtime`	Исполняющая система, которая управляет шагами агента, вызовами модели, инструментами и состоянием.
`Environment`	Внешняя среда, с которой агент взаимодействует: пользователь, файлы, API, браузер, база данных, рабочая система.
`Observation`	Данные, которые агент получает из среды: сообщение, результат инструмента, ошибка, изменение файла, событие.
`Planner`	Компонент или режим рассуждения, который помогает разбить цель на шаги и выбрать следующий ход.
`Tools`	Внешние функции и сервисы, которые агент может вызывать: поиск, shell, календарь, CRM, репозиторий, база данных.
`Policies`	Правила, ограничивающие чтение, запись, действия, безопасность, приватность и стиль поведения агента.
`Memory read`	Процесс извлечения релевантной памяти перед рассуждением.
`Memory write`	Процесс сохранения новых фактов, событий, процедур или выводов после наблюдения или действия.
`Context assembly`	Сборка итогового prompt из запроса, инструкций, состояния, результатов инструментов и найденной памяти.

Базовая анатомия агента

На высоком уровне агент состоит из нескольких компонентов.

Компонент	Роль	Связь с памятью
LLM	Интерпретирует контекст, рассуждает, генерирует ответы и планы.	Получает память только через собранный context.
Planner	Выбирает шаги для достижения цели.	Использует прошлые решения, ограничения и результаты.
Tools	Выполняют действия во внешней среде.	Результаты инструментов могут становиться эпизодической или процедурной памятью.
Memory layer	Хранит, извлекает, обновляет и забывает сведения.	Связывает прошлое состояние с текущим решением.
Policies	Управляют тем, что можно читать, записывать и делать.	Определяют доступ, consent, retention, приоритеты и запреты.
Environment	Источник задач, событий и последствий действий.	Поставляет наблюдения, из которых формируется память.

Эти компоненты не обязательно являются отдельными микросервисами. В простом продукте они могут быть функциями одного backend-приложения. В сложной системе они могут быть распределены между orchestration layer, базами данных, поисковыми индексами, policy engine и инструментальными сервисами.

Главное не физическое разнесение, а ответственность. Memory layer отвечает не за "все данные приложения", а за те данные, которые помогают агенту действовать лучше с учетом прошлого.

Схема агентского цикла

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

flowchart LR U[User / Environment] --> O[Observe] O --> P1[Policy checks] P1 --> R[Memory read / retrieval] R --> C[Context assembly] C --> L[LLM reasoning] L --> PL[Plan / next step] PL --> A[Act / tool call] A --> T[Tool result] T --> RF[Reflect / evaluate] RF --> W[Memory write / update] W --> M[(Memory stores)] M --> R RF --> OUT[Response / next action]

Разберем этот цикл по шагам.

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

Policy checks: система проверяет, какие данные можно использовать, какие действия разрешены, нужен ли consent, есть ли ограничения проекта или организации.

Memory read: агент извлекает релевантные сведения. Это может быть user profile, project facts, недавние события, прошлые решения, инструкции из файлов, результаты предыдущих попыток.

Context assembly: runtime собирает итоговый prompt: текущий запрос, системные инструкции, выбранную память, состояние задачи, результаты инструментов и ограничения.

LLM reasoning: модель интерпретирует собранный контекст и предлагает ответ, план или вызов инструмента.

Act: агент выполняет действие: вызывает API, читает файл, запускает команду, ищет документ, создает черновик, меняет задачу в трекере.

Reflect: система оценивает результат. Успешен ли шаг? Нужно ли продолжать? Появилась ли новая информация? Есть ли ошибка, которую стоит запомнить?

Memory write: агент записывает новое знание, событие, решение, preference или процедуру, если это разрешено и полезно.

Где находится memory layer

Memory layer расположен между наблюдениями, рассуждением и действиями. Он не заменяет LLM, tools или application database, а связывает их в устойчивое поведение.

                   +----------------------+
                   |      Policies        |
                   +----------+-----------+
                              |
User / Env -> Observations -> Agent Runtime -> Tools / Actions
                              |
                              v
                    +-------------------+
                    |   Memory Layer    |
                    | read / write /    |
                    | update / forget   |
                    +---------+---------+
                              |
        +---------------------+----------------------+
        |                     |                      |
        v                     v                      v
 Session State        User / Project Facts     Event / Tool Logs

Такое расположение важно по двум причинам.

Первая причина - память должна участвовать до вызова LLM. Если relevant facts не попали в context assembly, модель не сможет надежно их учитывать.

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

Memory layer как слой context engineering

Context engineering - это проектирование того, что именно попадает в prompt и в каком виде. Memory layer является одной из его центральных частей.

Плохая сборка контекста выглядит так: "возьмем последние N сообщений и добавим несколько найденных chunks". Иногда этого достаточно, но в долгоживущем агенте такой подход быстро становится хрупким.

Хорошая сборка контекста отвечает на несколько вопросов:

какая цель активна прямо сейчас;
какие инструкции имеют высший приоритет;
какие факты о пользователе и проекте релевантны;
какие события из прошлого похожи на текущую ситуацию;
какие tool results нужно учитывать;
какие сведения устарели или конфликтуют;
какие данные нельзя показывать модели из-за scope или policy.

Memory layer не просто "добавляет воспоминания". Он помогает превратить разрозненное прошлое в компактный, проверяемый и полезный рабочий контекст.

Чем agent memory отличается от application database

Application database хранит данные продукта. Например: пользователей, заказы, документы, задачи, платежи, настройки, права доступа. Эти данные нужны приложению независимо от того, есть ли в нем LLM.

Agent memory хранит сведения, которые помогают агенту выбирать поведение. Иногда она ссылается на application database, иногда извлекает из нее данные, иногда записывает рядом дополнительные наблюдения. Но это не одно и то же.

Критерий	Application database	Agent memory
Основная цель	Поддерживать бизнес-объекты приложения.	Поддерживать поведение агента во времени.
Типичные данные	Пользователи, документы, транзакции, задачи, настройки.	Preferences, события, решения, выводы, процедуры, прошлые результаты.
Схема	Часто строгая и доменная.	Может быть гибридной: records, embeddings, summaries, graph, logs.
Чтение	По явным ключам, запросам и бизнес-логике.	Через retrieval, ранжирование, scopes и context assembly.
Запись	По действиям пользователя или бизнес-процессам.	По событиям агентского цикла и политикам запоминания.
Ошибка смешивания	Агент начинает считать любые данные приложения своей памятью.	Память превращается в хаотичную копию базы продукта.

Пример: в приложении для задач есть таблица tasks. Это application database. Но запись "пользователь обычно хочет сначала видеть риски, потом план" - это agent memory. Запись "в прошлый раз агент ошибся, потому что не проверил blocked dependencies" - тоже agent memory.

Чем agent memory отличается от RAG

RAG обычно отвечает на вопрос: "какие внешние документы помогут ответить на текущий запрос?" Он извлекает фрагменты из knowledge base: документации, wiki, спецификаций, писем, статей, кодовой базы.

Agent memory отвечает шире: "какое прошлое состояние и опыт должны повлиять на поведение агента сейчас?" В эту область входят не только документы, но и пользовательские предпочтения, события, прошлые действия, ошибки, решения, процедуры и scope.

Критерий	RAG knowledge base	Agent memory
Основной источник	Документы и внешние знания.	Опыт агента, пользователя, проекта и среды.
Главная операция	Найти релевантные chunks.	Прочитать, записать, обновить, забыть и подать память в context.
Тип результата	Текстовые фрагменты с источниками.	Факты, события, summaries, preferences, procedures, policies.
Время	Часто ориентирован на текущую актуальность документов.	Явно учитывает прошлые сессии, sequence событий и изменения состояния.
Поведение	Улучшает информированность ответа.	Меняет поведение агента и его решения.

RAG может быть частью memory architecture. Например, документация проекта может выступать как world memory, а retrieval по ней может участвовать в context assembly. Но memory layer шире, потому что он управляет не только знанием о мире, но и опытом самого агента.

Память как механизм персонализации

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

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

Поэтому memory layer должен хранить не только содержание, но и метаданные:

scope: пользователь, проект, команда, организация, сессия;
source: откуда взялась запись;
timestamp: когда запись появилась;
confidence: насколько ей можно доверять;
lifetime или TTL: как долго она должна действовать;
permissions: кому и где можно ее использовать.

Без этих признаков персонализация становится гаданием и может выглядеть навязчиво или ошибочно.

Память как механизм автономности

Автономный агент должен не только отвечать, но и продолжать работу через несколько шагов. Для этого ему нужно помнить:

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

Например, агенту поручили подготовить отчет: найти данные, проверить источники, построить выводы и оформить документ. Если каждый шаг начинается как новый независимый LLM-вызов, агент будет терять нить. Если runtime ведет state и memory, агент может продолжать работу, сверяться с прошлым шагом и корректировать план.

Здесь важна разница между working state и долгосрочной memory. Текущий список подзадач может жить только до завершения workflow. А вывод "для этого API всегда нужно указывать workspace_id, иначе запрос падает" может стать процедурной памятью проекта.

Непрерывность между сессиями

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

Непрерывность особенно важна в сценариях:

coding agent, который работает в одном репозитории неделями;
персональный ассистент, который знает привычки пользователя;
support agent, который видит историю обращений;
enterprise knowledge agent, который учитывает структуру организации;
multi-agent system, где несколько агентов должны координироваться через shared memory.

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

Пример: агент с инструментами

Представим агента, который помогает вести проектную документацию в репозитории.

Пользователь пишет:

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

Агентский цикл может выглядеть так:

Шаг	Что делает агент	Где участвует память
Observe	Получает задачу пользователя и текущий репозиторий.	Видит активный project scope.
Retrieve	Читает инструкции проекта, план курса и прошлые решения.	Извлекает conventions: русский язык, broad conceptual style, не трогать `intro/`.
Reason	Решает, какие файлы проверить и как не нарушить структуру.	Использует project facts и procedural memory.
Act	Читает Markdown-файлы, редактирует нужный урок, запускает проверки.	Tool results становятся наблюдениями.
Reflect	Проверяет, не появились ли противоречия или пропуски.	Может сформировать lesson learned.
Write	Сохраняет значимые выводы, если они нужны в будущем.	Например: "для курса лекции должны заканчиваться самопроверкой".

В этом примере memory layer не равен файлам курса. Файлы курса - это данные проекта. Память агента - это то, как агент использует эти данные: какие правила извлекает, какие ограничения применяет, какие прошлые решения учитывает и какие наблюдения сохраняет для будущих задач.

Типичные ошибки проектирования

Ошибка 1: вынести память в отдельную "таблицу фактов" и не встроить ее в цикл агента.

Если память не участвует в retrieval и context assembly, она не влияет на поведение. Она может существовать в базе, но агент не будет ее реально использовать.

Ошибка 2: писать в память все результаты инструментов.

Tool logs полезны для аудита и debugging, но не каждый лог должен становиться рабочей памятью. Нужны правила: что сохранять как событие, что сжимать в summary, что игнорировать, что удалять.

Ошибка 3: путать RAG с памятью.

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

Ошибка 4: не различать scopes.

Факт о конкретном проекте нельзя автоматически применять ко всем проектам пользователя. Командная политика не равна личному предпочтению. Сессионная настройка не равна постоянному профилю.

Ошибка 5: дать LLM самой решать все политики памяти.

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

Краткое резюме

AI Agent - это система, а не одиночный LLM-вызов. Его поведение возникает из цикла observe -> retrieve -> reason -> act -> reflect -> write.

Memory layer находится внутри этого цикла. До вызова LLM он помогает собрать релевантный контекст. После действия он помогает сохранить новое состояние, факты, события, процедуры и выводы.

Agent memory отличается от application database и от RAG. База приложения хранит бизнес-объекты, RAG ищет знания в документах, а память агента управляет прошлым опытом и состоянием, которые должны влиять на будущие решения.

Вопросы для самопроверки

Почему память агента должна участвовать и до, и после LLM-вызова?
Чем memory layer отличается от application database?
Почему RAG может быть частью памяти, но не равен всей agent memory?
Какие данные нужны агенту для автономной работы через несколько шагов?
Какие метаданные помогают сделать персонализацию безопаснее и точнее?

Что дальше

В следующей лекции мы введем когнитивную модель памяти: working memory, short-term memory, long-term memory, episodic, semantic, procedural, reflection и shared memory. Это даст словарь, который дальше будет использоваться для проектирования memory layer по частям.