Урок 12.1. Как думать о памяти агента

Цель лекции

Собрать весь гайд в простую mental model, которую можно применить к любому агентскому продукту.

Ожидаемый результат

Читатель уходит с цельной архитектурной рамкой AI Agent Memory: память как pipeline, где каждая запись имеет тип, источник, scope, время жизни, уровень доверия, policy и путь удаления.

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

После всех модулей легко запомнить много отдельных деталей:

semantic memory;
episodic memory;
procedural memory;
RAG;
vector search;
graph memory;
memory poisoning;
shared memory;
metrics;
tools.

Но при проектировании агента нужен не список терминов, а способ мышления.

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

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

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

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

Не думайте о memory как о базе данных.

Думайте о ней как о цепочке решений:

observe -> decide what to remember -> store -> retrieve -> assemble context -> act -> evaluate -> update/forget

Каждый шаг может улучшить агента или усилить ошибку.

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

Термин	Роль в финальной модели
`Memory pipeline`	Полный путь от наблюдения до использования и обновления памяти.
`Memory record`	Отдельная единица памяти с content, type, scope, source, time, policy.
`Memory type`	Working, episodic, semantic, procedural, reflection, world/RAG, shared.
`Scope`	Где memory применима: user, project, tenant, session, role, task.
`Policy`	Правила чтения, записи, удаления, доступа и безопасности.
`Freshness`	Актуальность записи.
`Trust level`	Насколько надежен источник memory.
`Context assembly`	Выбор того, что попадет в prompt.
`Evaluation`	Метрики и тесты, показывающие, помогает ли память.
`User control`	Возможность видеть, исправлять, удалять и отключать память.

Итоговая схема memory pipeline

flowchart TD A[Input / event / tool result] --> B[Capture] B --> C[Classify memory type] C --> D[Apply write policy] D --> E[Store with metadata] E --> F[Index / summarize / link] Q[New task] --> R[Retrieve candidates] R --> S[Filter by scope + permissions] S --> T[Rerank by relevance + freshness + trust] T --> U[Context assembly] U --> V[Agent response / action] V --> W[Observe outcome] W --> X[Evaluate] X --> Y[Update / consolidate / decay / delete] Y --> E

Эта схема показывает главный вывод курса: memory quality рождается не в одном компоненте. Ошибиться можно на capture, policy, storage, retrieval, context assembly, action или lifecycle.

Память - это pipeline, а не база данных

Database отвечает на вопрос:

Где хранить?

Memory pipeline отвечает на вопросы:

Что хранить?
Почему хранить?
Как долго хранить?
Кому показывать?
Когда использовать?
Как обновлять?
Как забывать?
Как проверять?

Поэтому нельзя сказать "мы добавили vector DB, значит у нас есть память". Есть только один слой storage/indexing. Остальные decisions остаются.

Каждая memory record должна иметь metadata

Минимальная запись:

content: "User prefers concise final reports after code edits."
type: semantic/preference
scope: project
source: explicit_user_instruction
created_at: 2026-08-08
confidence: high
trust_level: user_explicit
ttl: none
policy: user_visible_editable

Без metadata память становится неуправляемой.

Нужны:

type;
scope;
source;
timestamp;
confidence;
trust;
owner;
permissions;
lifecycle;
deletion status;
provenance.

Content без metadata - это просто текст. Memory record - это текст плюс правила использования.

Тип памяти определяет поведение

Тип памяти	Что хранит	Главный риск
Working memory	Текущий task/context	Переполнение context window
Episodic memory	События и опыт	Слишком много noise
Semantic memory	Факты и preferences	Неверное обобщение
Procedural memory	Workflows and rules	Закрепление плохой привычки
Reflection memory	Выводы из опыта	Overfitting to past mistakes
World/RAG memory	External knowledge	Stale or unauthorized sources
Shared memory	Coordination state	Leakage, conflicts, race conditions

Когда вы проектируете память, сначала определите тип. Потом выбирайте storage, retrieval и policy.

Источник определяет доверие

Не все sources равны.

Источник	Пример trust behavior
Current user instruction	Высокий приоритет для текущей задачи.
Official policy document	Высокий, если актуален и доступен.
Current repository files	Высокий для фактов о коде.
Past conversation	Полезно, но требует scope and freshness.
Retrieved web/doc snippet	Требует provenance and grounding.
Model inference	Низкое доверие без подтверждения.
Tool log	Полезно, но нужно фильтровать secrets.
Other agent memory	Требует role, trust and conflict rules.

Многие memory failures возникают, когда агент доверяет слабому source как сильному.

Scope предотвращает overuse

Scope отвечает на вопрос:

Где эта память применима?

Примеры:

current turn;
current session;
task;
project;
repository;
user global;
organization;
tenant;
role;
document.

Пример scope bug:

User:
"Для этого письма сделай тон максимально официальный."

Bad memory:
"User prefers very formal tone."

Better:
scope = current_email

Правильный scope часто важнее сложного retrieval.

Retrieval - это выбор рабочего контекста

Retrieval не должен доставать "все похожее". Он должен доставать то, что полезно сейчас.

Хороший retrieval учитывает:

relevance;
scope;
permissions;
freshness;
source trust;
conflict;
context budget;
current user instruction;
task type.

Плохой retrieval может навредить даже при хорошей модели:

Wrong memory in context -> plausible wrong answer

Поэтому retrieval quality нужно оценивать отдельно от final answer.

Context assembly решает, что модель увидит

Даже если retrieval нашел правильные records, context assembly может:

вставить слишком много;
поставить важное ниже шума;
потерять source;
смешать conflicting facts;
нарушить priority of instructions;
переполнить context window;
включить sensitive data.

Практическое правило:

Memory in storage does not matter until it is selected, filtered and placed into context.

Context assembly - это место, где memory становится рабочим знанием модели.

Устаревание, конфликты, замена и удаление

Память не статична.

Система должна уметь:

помечать stale records;
снижать вес старой памяти;
подтверждать сомнительные факты;
хранить valid_from/valid_until;
разрешать conflicts;
заменять старые facts;
удалять records;
удалять derived records;
обновлять summaries and indexes.

Пример:

Old:
"Project uses Jest."

New:
"Project migrated to Vitest."

Expected:
- old record becomes stale
- new record becomes active
- retrieval prefers Vitest
- historical question can still answer "Jest was used before migration"

Deletion - не кнопка в UI, а lifecycle operation across stores, indexes, summaries and caches.

Видимость и управляемость памяти

Пользователь должен иметь возможность:

увидеть memory;
понять, почему она используется;
исправить ее;
удалить ее;
ограничить scope;
отключить memory для задачи;
запретить сохранение certain data.

Это особенно важно для:

personal assistants;
enterprise agents;
support agents;
shared memory;
sensitive domains.

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

Безопасность как часть memory design

Security не добавляется после retrieval.

Она должна быть встроена в:

capture;
extraction;
write policy;
storage;
indexes;
retrieval filters;
context assembly;
tool use;
summaries;
logs;
deletion;
evaluation.

Ключевые угрозы:

memory poisoning;
prompt injection stored as memory;
cross-tenant leakage;
secret storage;
stale policy use;
hidden sensitive inference;
unsafe shared memory.

Если память persistent, ошибка тоже persistent. Поэтому безопасность памяти важнее, чем безопасность одного ответа.

Почему хорошая память повышает автономность

Хорошая память позволяет агенту:

продолжать задачи между сессиями;
не задавать повторные вопросы;
учитывать preferences;
использовать прошлый опыт;
работать с большими knowledge bases;
координировать агентов;
улучшать workflows;
объяснять decisions through provenance.

Но плохая память усиливает ошибки:

старый факт применяется снова и снова;
poisoned memory влияет на будущие tasks;
scope bug распространяется по продукту;
wrong summary заменяет source;
unauthorized data попадает в prompt.

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

10 принципов проектирования памяти

Проектируйте memory как pipeline, а не как storage.
Каждая memory record должна иметь type, source, scope and time.
Текущая явная инструкция пользователя имеет высокий приоритет.
Source of truth должен побеждать старую memory.
Retrieval должен быть permission-aware and freshness-aware.
Context assembly должен быть отдельным design step.
Не превращайте temporary context в permanent profile.
User control обязателен для персональной и чувствительной памяти.
Deletion должна проходить через stores, indexes, summaries and caches.
Оценивайте memory отдельными metrics, tests and traces.

Эти принципы можно применять к любому agent product.

Финальный checklist архитектора

Перед добавлением памяти к агенту пройдите checklist.

Вопрос	Проверка
Что агент должен помнить?	Перечислены memory types and examples.
Что агент не должен помнить?	Есть denylist/policy для secrets, sensitive data, temporary context.
Какой source of truth?	Определены authoritative sources.
Какой scope у records?	User/project/session/tenant/task/role явно различаются.
Как работает запись?	Есть extraction and write policy.
Как работает retrieval?	Есть filters, reranking, freshness and permissions.
Как memory попадает в prompt?	Context assembly описан отдельно.
Как решаются conflicts?	Есть rules and escalation.
Как memory устаревает?	Есть decay, TTL, stale markers or confirmation.
Как удалить memory?	Stores, indexes, summaries and caches покрыты.
Как пользователь управляет memory?	View/edit/delete/disable.
Как тестируется memory?	Golden datasets, scenario tests, adversarial tests.
Как наблюдается behavior?	Traces, logs, dashboards, audit.
Какой минимальный stack?	Не добавлена лишняя инфраструктура без требования.

Если на вопрос нет ответа, это не всегда blocker. Но это design debt, который нужно осознавать.

Как начинать просто

Для первого прототипа часто достаточно:

ясного prompt contract;
conversation buffer;
summary;
small profile;
files or SQLite;
simple retrieval;
manual deletion;
basic logs;
small eval set.

Не нужно начинать с enterprise-grade graph-vector-memory platform, если задача - локальный writing assistant.

Но даже простой старт должен иметь правильные границы:

не хранить secrets;
различать temporary and permanent;
иметь scope;
уметь удалить;
проверять current source;
логировать memory use.

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

Как расти без хаоса

Рост обычно идет так:

No memory
-> conversation buffer
-> summaries
-> user/project profile
-> retrieval over records/docs
-> policies and metadata
-> evaluation and observability
-> lifecycle and deletion
-> graph/shared/enterprise layers where needed

На каждом этапе вопрос один:

Какая новая проблема требует новой сложности?

Если ответа нет, complexity добавлена ради ощущения прогресса.

Сквозной пример

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

"Напиши следующую лекцию курса."

Хорошая memory-assisted система:

Определяет task: writing course lesson.
Retrieves lesson plan and adjacent lessons.
Retrieves project-scoped style preferences.
Checks current files as source of truth.
Uses procedural memory for lecture structure.
Applies context assembly with only relevant materials.
Writes lecture.
Checks headings and unfinished markers.
Produces concise final report.
Optionally updates episodic/procedural memory if something new was learned.

Плохая система:

Достает случайные old memories.
Игнорирует target file.
Применяет global style preference без scope.
Не проверяет output.
Записывает temporary instruction as permanent.

Обе системы "используют память". Но только первая использует ее архитектурно.

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

Ошибка 1: начинать с инструмента.

Начинайте с behavior and risks, потом выбирайте stack.

Ошибка 2: считать больше памяти лучше.

Больше памяти часто означает больше stale, noise and risk.

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

Агент должен знать, когда memory не использовать.

Ошибка 4: не проектировать deletion с первого дня.

Позже удалить derived memory намного сложнее.

Ошибка 5: не отделять evaluation от demo.

Demo показывает possibility. Tests показывают reliability.

Ошибка 6: забывать человека.

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

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

Память агента - это pipeline: capture, classify, policy, store, index, retrieve, filter, rerank, assemble context, act, evaluate, update and forget. Каждая memory record должна иметь тип, источник, scope, время, trust и lifecycle.

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

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

Почему memory лучше мыслить как pipeline, а не как database?
Какие metadata должны быть у memory record?
Почему context assembly является отдельным архитектурным шагом?
Как deletion отличается от удаления одной строки в store?
Какие из 10 принципов наиболее критичны для вашего текущего agent scenario?

Что дальше

На этом базовая рамка AI Agent Memory завершена. Дальше ее можно применять к конкретным продуктам: начинать с простого memory stack, измерять качество, добавлять policies and observability, а затем расширять архитектуру только там, где реальные сценарии требуют большей памяти, скорости, безопасности или координации.