Как работает память ИИ-агентов: создание персистентного контекста без PhD

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

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

Три уровня памяти ИИ-агентов

Представьте память агентов в виде трех слоев, от самого простого к самому мощному:

1. Рабочая память — текущее контекстное окно модели. Эфемерно по определению. Сбрасывается после каждой сессии или реплики в диалоге. 2. Структурированная память — локальные файлы или база данных SQLite, где агенты хранят и извлекают факты, журналы задач и решения. Детерминированно, дешево и быстро. 3. Семантическая память — векторное хранилище, которое позволяет агентам искать по смыслу, а не по точным ключевым словам. Более мощное, чуть сложнее в настройке.

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

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

Уровень 1: Плоскофайловая память — начните здесь

Самая простая персистентная память — это обычный текстовый файл (или Markdown) на диске, который каждый агент читает при старте сессии и дополняет в процессе работы.

Как это работает

Дайте каждому агенту файл memory.md. В начале каждой задачи вставляйте его содержимое в системный промпт. После завершения задачи предписывайте агенту дописать краткое резюме. Вот практичная структура:

# Память агента — Исследователь

## Известные факты
- Клиент Acme Corp предпочитает стиль: формальный, основанный на данных.
- Анализ конкурентов за Q3 завершён 2026-06-15. См. /projects/acme-q3/.
- Цена нашего продукта: $199 единоразово, не подписка.

## Последние задачи
- [2026-07-18] Исследование моделей ценообразования SaaS для поста в блоге.
  Ключевой вывод: средняя команда платит $40–120/мес за место.
- [2026-07-19] Составлен список ключевых слов для SEO-кластера "самостоятельно размещённый ИИ".
  42 ключевых слова экспортированы в /exports/keywords.csv.

## Рабочие инструкции
- Всегда указывайте источники с URL.
- Предпочитайте свежие данные (моложе 6 месяцев).

Преимущества

• Нулевая инфраструктура. Никакой базы данных, серверного процесса, API-вызовов. Просто файл на диске.
• Читаемо человеком. Вы можете открыть его, отредактировать и версионировать с помощью Git.
• Экономно по токенам. Хорошо структурированный 200-страничный файл Markdown занимает менее 3000 токенов — дешево вставлять в промпт.

Ограничения

• Нет поиска, кроме того, что помещается в контекстное окно.
• Файлы растут линейно. Примерно после 500 строк вам понадобится раунд суммаризации — вызов LLM, сжимающий старые записи, — или файл превысит ваш бюджет на вставку.
• Нет межагентных запросов. Каждый агент видит только свой собственный файл, если вы не построите общую индексацию вручную.

Когда переставать использовать плоские файлы

Когда вы поймаете себя на том, что вручную прореживаете записи, или когда агентам часто нужно найти конкретный факт среди сотен — это сигнал к переходу на SQLite.

Уровень 2: SQLite — структурированная, запрашиваемая память

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

Схема для памяти агентов

Вот минимальная схема, которая покрывает большинство бизнес-кейсов:

CREATE TABLE facts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    agent TEXT NOT NULL,
    category TEXT,            -- 'client', 'product', 'competitor'
    fact TEXT NOT NULL,
    source TEXT,              -- URL или путь к файлу
    confidence REAL DEFAULT 1.0,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    expires_at TIMESTAMP      -- факты, которые устаревают
);

CREATE TABLE tasks (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    agent TEXT NOT NULL,
    description TEXT NOT NULL,
    result TEXT,
    status TEXT DEFAULT 'completed',
    tokens_used INTEGER,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE decisions (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    context TEXT NOT NULL,
    decision TEXT NOT NULL,
    reasoning TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Как агенты с ней взаимодействуют

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

import sqlite3

def query_memory(sql: str, db_path: str = "memory.db") -> list[dict]:
    """Выполняет запрос только для чтения к базе данных памяти агента."""
    conn = sqlite3.connect(f"file:{db_path}?mode=ro", uri=True)
    conn.row_factory = sqlite3.Row
    try:
        rows = conn.execute(sql).fetchall()
        return [dict(row) for row in rows]
    finally:
        conn.close()

def write_memory(agent: str, table: str,
                 data: dict, db_path: str = "memory.db"):
    """Вставляет запись в память после завершения задачи."""
    conn = sqlite3.connect(db_path)
    cols = ", ".join(data.keys())
    placeholders = ", ".join(["?"] * len(data))
    conn.execute(
        f"INSERT INTO {table} ({cols}) VALUES ({placeholders})",
        list(data.values())
    )
    conn.commit()
    conn.close()

Инструкция для агента включает правило вроде:

"Перед исследованием любой темы выполните запрос к таблицам facts и tasks на предмет релевантной предыдущей работы. Если нашли совпадение — сошлитесь на него. Если нет — проведите исследование и сохраните свои находки."

Преимущества

• Структурированные запросы. "Что мы узнали об Acme Corp?" превращается в SELECT * FROM facts WHERE category = 'client' AND fact LIKE '%Acme%' — мгновенно, детерминированно.
• Экономное извлечение по токенам. Вы получаете только нужные строки, а не всю историю.
• Межагентная видимость. Все агенты разделяют один файл базы данных. Кодер может запросить факты, которые исследователь сохранил вчера.
• Поддержка истечения срока. Факты о ценах или конкурентах могут автоматически истекать, сохраняя память свежей без ручной очистки.

Ограничения

• Нет семантического понимания. WHERE fact LIKE '%pricing%' не совпадёт с "стоимость подписки", если вы явно не присвоили ей тег.
• Важна схема. Плохо спроектированные схемы приводят к хрупким запросам и несогласованному вводу данных агентами.

Уровень 3: Векторные базы данных — семантическая память

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

Как это работает

1. Получите эмбеддинг для каждой записи в памяти (факт, резюме задачи, решение) с помощью локальной модели эмбеддингов. 2. Сохраните векторы в легковесной базе данных (ChromaDB, Qdrant или SQLite с sqlite-vss). 3. При запросе получите эмбеддинг вопроса агента, затем найдите ближайшие векторы — это и будут семантически релевантные воспоминания.

Практическая настройка с ChromaDB

import chromadb
from sentence_transformers import SentenceTransformer

# Маленькая, локальная модель — нулевые API-расходы
embedder = SentenceTransformer("all-MiniLM-L6-v2")

client = chromadb.PersistentClient(path="./memory_vectors")
collection = client.get_or_create_collection("agent_memory")

def store_memory(agent: str, text: str, metadata: dict = None):
    embedding = embedder.encode(text).tolist()
    collection.add(
        documents=[text],
        embeddings=[embedding],
        metadatas=[metadata or {}],
        ids=[f"{agent}_{hash(text)}"]
    )

def recall(query: str, n_results: int = 5) -> list[str]:
    query_vec = embedder.encode(query).tolist()
    results = collection.query(
        query_embeddings=[query_vec], n_results=n_results
    )
    return results["documents"][0]

Когда векторная память оправдывает себя

• Сотни сохраненных фактов. Ключевое совпадение ухудшается после примерно 100 записей; векторный поиск остается надежным на тысячах.
• Междоменный поиск. Вопрос о "предпочтениях в коммуникации с клиентом" может извлечь факт с пометкой "стиль встречи: формальный, основанный на данных" — то, что SQL LIKE пропустит.
• Суммирование прошлых диалогов. Встраивайте фрагменты старых журналов задач и извлекайте релевантные фрагменты по запросу.

Затраты и реальная проверка

Локальная модель эмбеддингов вроде all-MiniLM-L6-v2 работает на CPU с 4–8 ГБ оперативной памяти. Она обрабатывает один факт примерно за 50 миллисекунд. Вам не нужен GPU. Вам не нужен облачный API. Общий объем векторного хранилища для небольшой бизнес-команды редко превышает 100 МБ на диске.

Собираем воедино: гибридная архитектура

Лучшие самостоятельно размещенные конфигурации комбинируют уровни, а не выбирают один:

┌──────────────────────────────────────────┐
│               Задача агента              │
│                                          │
│  1. Чтение memory.md (старт сессии)      │
│  2. Запрос к SQLite (структ. факты)      │
│  3. Запрос к векторной БД (сем. поиск)   │
│  4. Выполнение задачи                    │
│  5. Запись результатов в SQLite+вектор.  │
│  6. Допись резюме в memory.md            │
└──────────────────────────────────────────┘

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

Частые ошибки и как их избежать

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

Разрешение агентам хранить всё подряд. Дайте четкие инструкции, *что* запоминать: решения, факты о клиентах, результаты задач. Не промежуточные шаги рассуждений или сырые дампы данных. Используйте поле category или importance для фильтрации шума позже.

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

Забывание срока годности. Устаревшая память хуже, чем никакой. Факт вроде "цены конкурента: $49/мес" полугодичной давности активно вводит в заблуждение. Используйте поля expires_at и периодически удаляйте старые записи из векторного хранилища.

Отсутствие цикла ручной проверки. Создайте простой чекпоинт — даже файл Markdown, который вы просматриваете еженедельно, — где агенты фиксируют решения с высокой уверенностью. Ловите галлюцинированные "факты", прежде чем они накопятся за сессии.

Краткая справка по масштабированию

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

Итог

Память ИИ-агентов — не магия, это инженерия, которую можно реализовать сегодня днем. Начните с файла Markdown на каждого агента. Перейдите на SQLite, когда файлы станут неудобными. Добавьте векторное хранилище, когда ключевой поиск перестанет находить нужное. Весь стек работает на стандартном VPS без облачных зависимостей и без регулярных API-расходов на хранение или эмбеддинги.

Агенты, которые приносят реальную бизнес-ценность, — это не те, у кого самые большие контекстные окна, а те, что помнят, чему научились вчера, и действуют на основе этого сегодня. Если вы оцениваете, как разные настройки справляются с персистентной памятью, это сравнение самостоятельно размещённых и SaaS команд агентов подробно разбирает архитектурные различия.