Память агента как редакционный процесс: evidence → candidate → review → context

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

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

Разделите знания и память

База знаний отвечает на вопрос «что написано в канонических документах». Она индексирует документы и возвращает фрагменты со ссылками. Документация RAG подчёркивает качество источника и атрибуцию. Память отвечает на другой вопрос: «какие проверенные утверждения и решения накопились в работе». Смешивать эти контуры нельзя. Регламент должен обновляться в своём источнике, а не закрепляться случайной репликой.

Документация Einstein описывает факты как проверяемые кандидаты, которые затем продвигаются в память. Для оператора важно сохранить эту формулировку. «Агент сам становится умнее каждую ночь» звучит красиво, но скрывает review и создаёт ожидание автоматической истины. Корректнее: фоновый процесс может находить кандидатов и противоречия, а продвижение остаётся контролируемым.

Шаг 1. Evidence

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

Доказательство не равно подтверждению. Оно лишь показывает, почему кандидат появился. Реплика «мы больше не используем систему X» — evidence для кандидата, но перед продвижением нужно проверить автора, область и дату. Возможно, речь шла об одной команде или тестовом стенде.

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

Шаг 2. Candidate

Deriver превращает evidence в структурированное утверждение: субъект, отношение, значение, область, уверенность и срок устаревания. В Einstein этот процесс детерминированный и не использует LLM или внешнюю сеть. Важно не переоценивать это свойство: регулярное правило уменьшает непредсказуемость, но всё равно может неверно понять контекст. Поэтому статус остаётся candidate.

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

Шаг 3. Contradiction и consolidation

Фоновый dream-проход ищет кандидаты без evidence и противоречия: один субъект и отношение, разные значения. Он не выбирает победителя автоматически. Конфликт поднимается в review с высоким приоритетом. Это ключевая граница: консолидация организует работу, а не переписывает историю.

Противоречие может быть нормальным изменением во времени. «Дежурный — Анна» в июле и «дежурный — Максим» в августе требуют дат и области, а не удаления одного значения как ложного. Поэтому review должен уметь promote, reject и supersede. Последнее сохраняет след решения и объясняет, почему старое утверждение больше не применяется.

Шаг 4. Review

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

Установите SLA очереди только если команда действительно его обслуживает. Иначе кандидаты могут ждать — это безопаснее автопродвижения. Полезные метрики: возраст очереди, доля кандидатов без evidence, число противоречий, promote/reject по источникам, частота последующего supersede. Не гонитесь за высокой долей promotion: большой reject может означать, что фильтр кандидатов надо улучшить.

Шаг 5. Context

Только reviewed-утверждения входят в обычный контекст. Даже там они должны иметь область и свежесть. Персональный факт не становится общим. Устаревшее решение помечается или заменяется. Выдача памяти приходит как данные, а не инструкция; документация guardrails описывает data-fence и эшелонированную защиту от инъекций. Ни один слой не абсолютен, поэтому чувствительное действие всё равно требует прав и approval.

Marketplace-развёртывание Einstein использует preview_only для канонической памяти: фоновые workers пишут в sidecar и не меняют canonical Markdown. В standalone исторический reviewed_ui допускает сохранение только при явном reviewed-флаге, сессии и CSRF. В маркетинговом тексте важно не смешивать эти режимы.

Моделируемый сценарий

В разговоре появляется фраза: «Поставщика уведомляем за пять дней». Deriver создаёт кандидата и связывает его с репликой. Dream находит в памяти reviewed-факт «за десять дней». Review показывает конфликт. Владелец процесса открывает актуальный договор и решает: новая фраза ошибочна — reject; либо правило изменилось — promote новую версию и supersede старую с датой. Следующий агент получает reviewed-состояние, а не последнюю услышанную фразу.

Этот пример не доказывает, что каждый бизнес-факт будет извлечён. Паттерны ограничены, источники могут быть недоступны, а область — неясна. Критические регламенты лучше сохранять в канонической базе знаний и менять через документный процесс. Память дополняет его решениями и контекстом.

Ограничения

Einstein не является автоматическим арбитром истины. Детерминированный deriver извлекает ограниченные формы утверждений. Review требует времени и полномочий. Preview-only не переписывает канонический Markdown. Контекст зависит от области и конфигурации. Даже reviewed-факт может устареть или быть неверно подтверждён. Память не заменяет source-of-truth систему, контроль доступа и аудит.

Чек-лист

Определить, что относится к знаниям, а что к памяти.
Требовать evidence и область у значимых кандидатов.
Ограничить ingest и назначить владельцев review.
Не показывать candidate как подтверждённый факт.
Рассматривать contradiction как задачу, а не автозамену.
Использовать supersede для изменений во времени.
Проверять права на evidence и review.
Снимать возраст очереди и качество источников.
Сохранять критические регламенты в канонических системах.
Помнить, что reviewed не означает вечный.

Полезная память — это не максимальное накопление. Это минимальный набор утверждений, происхождение которых можно объяснить, область — проверить, а решение — пересмотреть. Если вы оцениваете Einstein, начните с одной категории фактов и проведите её по всему маршруту от evidence до контекста.

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