Память агентов

Короткая версия

В 2026 полезно различать четыре типа памяти:

• Working memory: текущий диалог, tool results, промежуточный state.
• Semantic memory: факты, предпочтения, знания о пользователе и мире.
• Episodic memory: прошлые шаги, ошибки, решения и outcome'ы.
• Procedural memory: устойчивые правила поведения, prompt policies, playbooks.

Соответствие со старой схемой:

• краткосрочная память ≈ working memory;
• долгосрочная память распадается на semantic + episodic + иногда procedural.

Чем отличается conversation state от semantic memory?

1. Working memory: что агент знает прямо сейчас

Working memory — это ближайший к inference слой:

• текущие сообщения;
• активные tool results;
• краткое summary длинной сессии;
• pending plans;
• thread-specific state.

Это современная версия того, что раньше часто называли просто “краткосрочной памятью”.

Важно понимать две вещи:

1. Working memory ограничена context window
   Даже если окно у современных моделей уже измеряется сотнями тысяч токенов и иногда доходит до 1M+, оно всё равно остаётся ограниченным ресурсом.
2. Provider-managed state не отменяет budget management
   OpenAI Responses API и Conversations API умеют вести conversation state, но это не освобождает от необходимости следить за ростом контекста, summary, retrieval quality и token economics.

Anthropic в docs прямо называет context window “working memory” модели и отдельно подчёркивает, что для длинных разговоров нужен осознанный token management, а не надежда на бесконечную память.

2. Semantic memory: факты и знания

Semantic memory — это долговечные факты:

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

Обычно semantic memory хранится во внешнем store:

• vector DB;
• SQL/kv store;
• document store;
• framework-native memory store.

Ключевая идея: semantic memory должна быть retrieved selectively, а не blindly appended to prompt.

Иначе вы быстро получаете три проблемы:

• noise in context;
• stale facts;
• prompt bloat.

3. Episodic memory: прошлые кейсы и outcome'ы

Episodic memory — это не просто “история чата”, а память о прошлых действиях:

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

Этот слой особенно полезен для:

• coding agents;
• research agents;
• customer-support workflow;
• backoffice automation;
• QA и повторяемых операционных задач.

Именно episodic memory помогает агенту не только помнить факты, но и учиться на паттернах действий.

4. Procedural memory: правила поведения

Procedural memory — это самый недооценённый слой.

Сюда относятся:

• устойчивые style/policy rules;
• playbooks;
• prompt instructions, которые надо улучшать со временем;
• learned operating preferences команды.

LangMem в 2026 прямо выделяет такой слой как отдельный класс памяти. Это полезная рамка, потому что многие команды ошибочно складывают policy-знания либо в system prompt, либо в semantic memory, хотя по смыслу это не “факт о пользователе”, а правило поведения агента.

Примеры procedural memory:

• “всегда проверяй наличие approval перед refund”;
• “ответы для этого клиента должны быть краткими и табличными”;
• “при CSV с cp1251 сначала пробуй fallback encoding strategy”.

5. Conversation state != durable memory

У OpenAI сейчас есть явный conversation state слой через Responses API и Conversations API. Это удобно для multi-turn flows, но важно не перепутать его с durable memory.

Разница такая:

Если у вас есть только conversation state, агент будет помнить недавний разговор, но:

• не построит персонализацию между потоками;
• не будет учиться на прошлых ошибках;
• не сохранит domain facts в управляемом виде;
• не сможет cleanly забывать или обновлять отдельные типы памяти.

6. Hot path vs background memory writes

Один из главных practical shifts в 2026 — memory formation делают не только “в горячем пути”.

LangMem прямо разделяет два режима:

Hot path

Агент сохраняет память прямо во время ответа.

Плюсы:

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

Минусы:

• добавляет latency;
• смешивает основную задачу с memory bookkeeping;
• хуже контролируется при высоком traffic.

Background formation

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

Плюсы:

• не тормозит user response;
• лучше подходит для consolidation и deduplication;
• удобнее для batch reflection.

Минусы:

• обновления не мгновенные;
• сложнее orchestration.

Для production это обычно лучший паттерн:

• критичные факты пишутся inline;
• всё остальное консолидируется в background.

7. Что реально ломает memory systems

Самые частые проблемы не в том, что “модель плохо помнит”, а в архитектуре:

• агент пишет слишком много мусора в store;
• не различает facts, episodes и rules;
• не умеет обновлять и удалять устаревшее;
• не фильтрует retrieval по namespace и metadata;
• тянет в prompt всё подряд;
• не делает forget / delete path для privacy и compliance.

8. Как проектировать memory layer без хаоса

Практический порядок:

9. Когда памяти слишком много

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

Memory hurts, если:

• retrieval приносит нерелевантные факты;
• old summaries подменяют исходную правду;
• агент начинает blindly trust stored memory;
• procedural memory конфликтует с текущей policy;
• store переполнен низкосигнальными записями.

Это особенно важно в long-running agents: через месяц без hygiene у вас будет не “умный агент”, а агент с неуправляемой свалкой прошлых следов.

Working memory через Responses API

Для текущего thread state OpenAI удобно использовать chaining через previous_response_id или Conversations API, а не вручную тащить каждый предыдущий turn в новый запрос.

from openai import OpenAI

client = OpenAI()

response_1 = client.responses.create(
    model="gpt-5.4",
    input="Пользователь готовит запуск продукта Альфа в апреле. Запомни это в рамках текущего диалога.",
)

response_2 = client.responses.create(
    model="gpt-5.4",
    previous_response_id=response_1.id,
    input="Сделай план на следующую неделю с учётом этого контекста.",
)

print(response_2.output_text)

Это удобно для thread continuity, но само по себе ещё не создаёт durable semantic memory между независимыми потоками.

Semantic memory: храните факты отдельно от thread state

from dataclasses import dataclass
from datetime import datetime


@dataclass
class MemoryRecord:
    namespace: tuple[str, ...]
    kind: str
    content: str
    source: str
    created_at: str


def to_semantic_record(user_id: str, fact: str) -> MemoryRecord:
    return MemoryRecord(
        namespace=("users", user_id, "semantic"),
        kind="fact",
        content=fact,
        source="conversation",
        created_at=datetime.utcnow().isoformat(),
    )

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

• namespace по пользователю / команде / приложению;
• metadata про источник и свежесть;
• отдельные правила dedupe и update;
• retrieval только по релевантному scope.

Episodic memory: логируйте outcome, а не только сырой trace

def make_episode(task: str, actions: list[dict], result: str, success: bool):
    return {
        "task": task,
        "actions": actions,
        "result": result,
        "success": success,
        "lessons": summarize_lessons(actions, result, success),
    }


def summarize_lessons(actions, result, success):
    if success:
        return ["Текущая стратегия сработала"]
    return ["Нужен fallback: после CSV parse failure пробовать alternate encoding"]

Если хранить только raw trace, retrieval будет шумным. Для episodic memory почти всегда нужен компактный lesson/outcome слой.

Background memory formation

Inline extraction полезна не всегда. Часто лучше асинхронно прогонять completed sessions через memory writer:

def memory_pipeline(conversation: list[dict]):
    facts = extract_semantic_facts(conversation)
    episodes = extract_episode_summary(conversation)
    rules = extract_procedural_updates(conversation)

    upsert_semantic(facts)
    upsert_episode(episodes)
    update_procedural_memory(rules)

Такой подход ближе к тому, как memory systems сегодня реально строят в LangGraph / LangMem style workflows.

У нас support-агент. Что хранить как semantic memory, а что как episodic?

Проверьте себя