Урок 2.3. Episodic Memory: память событий и опыта

Цель лекции

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

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

В предыдущей лекции мы разобрали conversation и session memory: память текущего диалога или ограниченного workflow. Она помогает не терять нить прямо сейчас. Но у долгоживущего агента есть другая потребность: помнить не только состояние текущей сессии, а конкретный опыт из прошлого.

Пользователь уже одобрял похожее решение. Агент уже запускал команду, и она падала с определенной ошибкой. Вчера API вернул rate limit. В прошлой задаче выбранный подход оказался неверным. В support ticket клиент уже присылал файл. В multi-step workflow инструмент уже был вызван, и результат изменил состояние среды.

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

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

Эпизодическая память отвечает на вопрос: "что произошло?"

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

Для агента episodic memory выполняет несколько ролей:

• восстанавливает контекст прошлой работы;
• помогает не повторять уже сделанные шаги;
• дает материал для debugging и аудита;
• поддерживает replay похожего опыта;
• позволяет превращать повторяющиеся события в semantic или procedural memory;
• повышает объяснимость: агент может показать, на каком событии основан вывод.

Главное отличие от session memory: сессия хранит временное состояние текущего взаимодействия, а episodic memory хранит конкретные события, которые могут быть полезны позже, уже за пределами этой сессии.

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

Что считается эпизодом

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

Простое событие:

2026-08-04 10:15
Actor: agent
Action: ran "npm test"
Result: failed
Error: database connection refused
Context: checkout-flow bugfix

Связанный эпизод:

User asked to fix auth test.
Agent inspected failing test.
Agent found expired-token fixture using local timezone.
Agent changed fixture to UTC.
Tests passed.

Оба варианта полезны. Атомарные события лучше для аудита и точного replay. Связанные эпизоды лучше для понимания опыта на уровне задачи.

В episodic memory обычно попадают:

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

Структура episodic record

Удобно думать об эпизодической записи как о структурированном событии.

id: evt_2026_08_04_001
timestamp: 2026-08-04T12:20:00+03:00
scope:
  user: user_123
  project: ai-agent-memory-guide
  session: sess_456
actor: agent
type: tool_result
action: read_file
object: modules/module_02/lesson_02_03_episodic_memory.md
observation: lesson file contains only a short plan
result: source plan identified
importance: medium
source: filesystem
links:
  - prior_event: evt_2026_08_04_000
  - artifact: lesson_02_03_episodic_memory.md

Это не обязательная схема базы данных. Это концептуальная структура. Реальная система может хранить события в log store, SQL, document database, event stream, object storage, vector index или комбинации.

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

Timeline и порядок событий

Для episodic memory порядок важен. Одни и те же факты могут означать разное в зависимости от последовательности.

Из такой timeline видно не просто "тесты прошли", а путь к этому результату. Это помогает:

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

Без timeline агент может помнить отдельные фрагменты, но терять причинно-следственную связь.

События пользователя, агента и инструментов

В episodic memory важно различать источники событий.

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

Эпизодическая память и tool calls

Tool-using agents особенно нуждаются в episodic memory. Вызовы инструментов являются реальными действиями в среде, а их результаты часто определяют следующий шаг.

Примеры tool events:

• агент прочитал файл;
• агент запустил тест;
• команда завершилась с кодом ошибки;
• API вернул неполный ответ;
• поиск нашел релевантный документ;
• изменение файла прошло успешно;
• попытка деплоя была отклонена policy engine.

Хранить стоит не весь необработанный вывод каждого инструмента, а полезную событийную запись:

Event:
- action: run_tests
- command: npm test -- auth/session.test.ts
- result: failed
- key_error: expected 200, received 401
- suspected_cause: expired token fixture
- artifact: full log stored separately
- importance: high

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

Importance scoring

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

Importance scoring помогает решить, какие события важны.

Оценка важности зависит от продукта. Для medical, legal, finance и enterprise-сценариев audit trail может требовать сохранять больше событий. Для легкого персонального ассистента лучше сохранять меньше, чтобы не копить лишнее.

Replay прошлого опыта

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

Пример:

Current task:
- Tests fail after dependency update.

Retrieved episode:
- In a previous task, tests failed after TypeScript update.
- Root cause: generated types were stale.
- Successful action: regenerate types, then rerun tests.
- Scope: same repository.

Такой episode не говорит автоматически "сделай то же самое". Он говорит: "проверь похожую причину, потому что в похожем контексте она уже возникала".

Replay полезен для:

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

Но replay опасен без проверки scope и актуальности. Похожий эпизод из другого проекта может быть нерелевантен. Старый workaround может быть уже запрещен. Успешное решение прошлого бага может не подходить к новой ошибке.

Debug trail и аудит

Episodic memory часто выполняет роль debug trail: журнала, по которому можно восстановить поведение агента.

Для debugging важно знать:

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

Для аудита важно дополнительно знать:

• кто был actor;
• какие permissions действовали;
• какие данные использовались;
• какие policy checks прошли или не прошли;
• какие artifacts были созданы;
• можно ли воспроизвести цепочку событий.

Episodic memory не обязана раскрывать скрытые рассуждения модели. Для аудита обычно нужны наблюдения, действия, результаты, источники и решения, а не приватный chain-of-thought.

Episodic-to-semantic distillation

Эпизоды могут становиться источником устойчивых фактов. Этот процесс можно назвать episodic-to-semantic distillation.

Например:

Episode 1:
- Auth test failed because token fixture used local timezone.

Episode 2:
- Another auth test failed after fixture copied same pattern.

Distilled semantic memory:
- Project fact: auth token fixtures should use UTC timestamps.

Distilled procedural memory:
- When auth tests fail around expiration, check timezone conversion first.

Важно: не каждый эпизод должен становиться фактом. Один случай может быть случайностью. Для distillation нужны повторяемость, подтверждение, источник, scope и уверенность.

Чем episodic memory отличается от semantic memory

Следующая лекция будет посвящена semantic memory, поэтому сейчас важно провести границу.

Episodic memory может быть сырьем для semantic memory, но не должна сразу заменяться ею. Иногда важна именно история: кто что сделал, когда и почему.

Схема жизненного пути эпизода

Эпизодическая запись проходит несколько этапов: наблюдение, запись, оценка важности, хранение, извлечение и возможное обобщение.

Эта схема показывает, что episodic memory - не просто "лог всего". Хорошая система решает, какие события сохранять, как долго, где искать и когда превращать опыт в более устойчивое знание.

Мини-кейс: агент помнит прошлую ошибку

Представим coding agent. Неделю назад он выполнял задачу:

Task: fix failing payment tests.
Event: agent ran tests.
Result: tests failed with "DATABASE_URL is not set".
Resolution: user explained that integration tests require local database.
Outcome: agent started database and tests passed.
Importance: high
Scope: repository billing-service

Сегодня пользователь пишет:

Проверь, почему снова падают payment tests.

Агент извлекает прошлый эпизод:

Relevant past episode:
- In billing-service, payment integration tests previously failed
  because local database was not running.
- Starting the local database resolved the failure.
- Source: task from last week, confirmed by user.

Это не означает, что причина точно та же. Но episode помогает выбрать разумный первый шаг: проверить окружение и наличие DATABASE_URL, прежде чем глубоко анализировать код.

Хороший ответ агента может быть:

Сначала проверю окружение: в прошлой похожей задаче payment tests
падали из-за не поднятой локальной базы. Если окружение в порядке,
перейду к анализу конкретного failing test.

Так episodic memory улучшает поведение без магии: прошлое событие становится рабочей гипотезой, но не подменяет проверку.

Что хранить, а что не хранить

Хранить как episodic memory стоит:

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

Не стоит сохранять надолго:

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

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

Типичные ошибки

Ошибка 1: хранить все события одинаково.

Если каждый шаг имеет одинаковый приоритет, важные эпизоды тонут в шуме. Нужны importance scoring, TTL, фильтры и summaries.

Ошибка 2: путать событие с фактом.

"Вчера API вернул 500" - это эпизод. "API всегда нестабилен" - обобщение, которое требует дополнительных подтверждений.

Ошибка 3: терять timestamp и scope.

Эпизод без времени и области применимости трудно правильно использовать. Старое событие из другого проекта может привести к неверному действию.

Ошибка 4: сохранять tool output как инструкцию.

Вывод инструмента - это наблюдение, а не команда агенту. Его нужно хранить с явным source и типом.

Ошибка 5: использовать replay без проверки.

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

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

Episodic memory может содержать много следов поведения пользователя. Для нее особенно важны consent, retention, access control и delete mechanisms.

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

Episodic memory - это память событий и опыта. Она отвечает на вопрос "что произошло?" и хранит действия, наблюдения, tool calls, ошибки, решения, результаты и timeline.

Она полезна для восстановления контекста, debugging, replay прошлого опыта, аудита и превращения повторяющихся событий в semantic или procedural memory.

Эпизодическую память нельзя заменить user profile или semantic facts. Иногда важен не только вывод, но и путь: кто что сделал, когда, при каких условиях и чем это закончилось.

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

1. Чем episodic memory отличается от session memory?
2. Какие поля полезно хранить в episodic record?
3. Почему timestamp и scope важны для replay прошлого опыта?
4. В чем разница между событием "тест упал из-за timezone" и semantic fact о проекте?
5. Какие риски возникают, если сохранять все tool outputs без фильтрации?

Что дальше

В следующей лекции мы разберем Semantic Memory: слой устойчивых фактов, сущностей, предпочтений и доменных знаний. Там мы посмотрим, как из отдельных эпизодов и наблюдений появляются факты, почему им нужны source, confidence и staleness, и как агент обновляет память при противоречиях.