Узнайте, как вынести память ИИ за пределы модели: внешний слой памяти для агентов, экономика забывания и проверка происхождения данных. Начните сейчас!
Большинство реализаций памяти для ИИ — это вариации одного шаблона: сохранить информацию, извлечь её позже, вставить в промпт и назвать это памятью. Это полезно, но архитектурно мало отличается от того, чтобы разложить стикеры по квартире и решить, что квартира теперь что-то помнит. Чем больше я работаю с ИИ-системами, тем сильнее убеждаюсь: память не должна принадлежать модели. Она должна принадлежать системе вокруг модели.
Модель может исчезнуть завтра, а история должна выжить. Claude сегодня пишет, GPT читает завтра, локальная модель оспаривает через неделю, а модель через полгода всё ещё понимает, почему существует странный обходной путь. Это эксперимент, который я строю: не «долговременная память» как фича ассистента, а общий внешний слой памяти для ИИ-агентов. И чем больше я работаю над этим, тем больше подозреваю, что интересная проблема — не сама память, а экономика забывания.
Современная модель знает больше языков программирования, чем я когда-либо выучу. Она знает распределённые системы, базы данных, React, Python, Rust, Kubernetes, редкие RFC и, вероятно, пятнадцать способов объяснить, почему моя архитектура излишне сложна. Но она не знает, что случилось в моём проекте во вторник. Она не знает, что мы уже пробовали очевидное решение и оно провалилось, что уродливый интерфейс существует, потому что от него зависят три репозитория, или что произвольное соглашение — результат двухчасового обсуждения, которое никто не хочет повторять.
Это различие важно, потому что такая информация не может жить в весах модели. Это не общее знание. Это история, или точнее, состояние, порождённое работой. Здесь же проявляется разница между RAG и памятью. RAG обычно извлекает информацию, которая уже существует: документацию, код, тикеты, политики, статьи, записи в БД. Память должна сохранять информацию, созданную самим процессом: почему выбрали A вместо B, почему C провалилось, почему мы терпим D, что изменилось после E, какое предположение было временным, и что команда узнала после ошибки.
Эти вещи не всегда документы. Часто это ровно та информация, которая должна была стать документацией, но не стала. Свежая ИИ-сессия расплачивается за эту недостающую историю, заново открывая её с нуля. Именно эту часть я хочу атаковать.
Прототип намеренно скучный, и это комплимент. Есть небольшой HTTP-хаб памяти, общий для команды. Воспоминания — это обычные Markdown-файлы со структурированными метаданными, разделённые на общие знания и знания о проекте. Каждая ИИ-сессия получает доступ через свой MCP-сервер и очень маленький набор инструментов: посмотреть, что есть, извлечь нужное, добавить новое.
Важна не MCP-обвязка, а граница. Модель — не хранилище памяти, клиент — не хранилище, MCP-сервер — не хранилище. Память существует независимо от всех них. Когда сессия начинается, она получает небольшой индекс, чтобы знать, какие воспоминания доступны, но полное содержимое попадает в контекст только когда агент осознанно запрашивает его.
Это различие важно, потому что плохая архитектура памяти легко превращается в очень дорогой способ выкрикивать всю историю компании в каждый промпт. Это не память, это загрязнение контекста с хорошим брендингом. Я хочу, чтобы агент знал, что прошлое существует, не втаскивая его целиком в каждое взаимодействие. Он может увидеть, что есть воспоминание о неудачной миграции, ограничении клиента или причине странного API, и затем решить, важно ли это для текущей задачи.
Так возникает экономика извлечения памяти. Индекс дёшев, детали стоят контекста, но здесь спрятано некрасивое допущение: агент должен извлечь правильное воспоминание. Сегодня прототип в основном делегирует этот выбор модели, используя описания в индексе. Это не решённая система поиска, а сознательно примитивный базовый уровень. Воспоминание, которое существует, но никогда не извлекается, функционально забыто, а извлечение нерелевантных воспоминаний — просто загрязнение контекста с дополнительными шагами. Поэтому точность и полнота поиска должны стать частью оценки, а не тихо проскользнуть в фразу «агент решает».
Внешняя память — не новая идея. MemGPT уже описывал долгоживущих агентов с иерархической памятью и виртуальным управлением контекстом, Letta развила это в платформу с сохранением состояния, а официальные примеры MCP включают сервер памяти на основе графа знаний. Мне интересен более узкий вопрос: что меняется, когда память принадлежит команде, а не ассистенту, хранится в открытом тексте и переносится между клиентами, и каждое воспоминание имеет явный статус доверия, а не считается автоматически авторитетным? Я не пытаюсь изобрести память, я ищу организационную границу, где она становится полезной инфраструктурой, а не очередной фичей ассистента.
Как только агенты могут записывать постоянную память, возникает проблема: почему следующий агент должен доверять тому, что написал предыдущий? Представьте, агент сохранил фразу «Всегда используйте Redis для этого компонента». Это было явное решение команды, вывод из текущего кода, временный обходной путь или уверенно ошибочное заключение, которое выжило в сессии? Постоянная память без происхождения опасна именно потому, что плохая информация не исчезает с разговором. Она выходит на пенсию внутри вашей инфраструктуры и бесконечно вводит в заблуждение будущих агентов.
Поэтому в этой системе воспоминание — это отчёт, а не инструкция. Непроверенное воспоминание означает: «Агент X сказал, что это правда в момент Y». Оно может быть полезным, но это слабое доказательство, и его следует сверять с кодом, планами или пользователем, прежде чем оно повлияет на важное решение. Проверенное воспоминание несёт более сильный авторитет, и если ИИ меняет его, статус проверки исчезает, пока человек не подтвердит снова. Модель не может молча переписать одобренную историю и сохранить значок одобрения.
Здесь есть очевидная ловушка: если каждое воспоминание требует одобрения человека, я просто заново построил узкое место документации на один уровень позже. Это полностью подорвало бы экономику записи, о которой я спорю. Поэтому проверка не может быть путём записи. Это механизм повышения. Агенты должны создавать воспоминания с низким доверием дёшево, и только меньшая часть, которая становится стабильным руководством для проекта, должна потреблять человеческую проверку. Работает ли такая лестница доверия — пока не доказано, но экономика хотя бы последовательна: люди курируют авторитет, а не вручную создают исторический след.
Это звучит бюрократично, пока не подумаешь о том, что значит постоянная память ИИ. Если информация переживает сессии, доверие должно переживать её тоже. Полезное воспоминание нуждается в авторе, возрасте, контексте, причине существования и связи с источником истины. Оно также должно оставаться оспариваемым. Иначе мы строим не организационное знание, а базу данных уверенных фраз, а интернет уже показал, что это не одно и то же.
Большинство демо памяти ИИ выглядят отлично, потому что длятся пятнадцать минут. Вы сохраняете, извлекаете, модель помнит, все счастливы. Оставьте ту же систему на полгода — эксперимент становится менее фотогеничным. Проекты меняются, API двигаются, люди отменяют решения, и воспоминание может оставаться идеально извлекаемым, но полностью ложным.
Поэтому хаб отслеживает возраст и помечает старые воспоминания как устаревшие. Если воспоминание утверждает что-то о коде, агент явно получает напоминание проверить эти утверждения против текущей реализации. Я сознательно не удаляю старые воспоминания автоматически, потому что возраст — не истина. Четырёхлетнее архитектурное решение может до сих пор объяснять, почему половина системы выглядит так, а воспоминание, созданное сегодня утром, уже может быть бессмыслицей. Возраст должен влиять на уверенность, а не на существование.
Это уводит дизайн от обычного менталитета кэша. Кэш спрашивает, можно ли переиспользовать значение. Память задаёт более сложный вопрос: насколько я должен верить этому сейчас? Это различие становится важным, когда в хранилище месяцы решений, принятых разными агентами при разных допущениях.
Привлекательное предложение легко увидеть. Представьте, вы присоединяетесь к проекту и спрашиваете ИИ-агента: «Почему эта система выглядит так?» Сегодня он может изучить репозиторий и объяснить, что существует. С памятью он потенциально может объяснить, почему это существует: почему отвергли провайдера, почему миграция провалилась, или почему «временный» слой совместимости уже третий год живёт.
Реальная архитектура системы лишь частично видна в коде. Остальное размазано по Slack-тредам, встречам, заброшенным веткам и одному инженеру, который говорит: «Не трогай это. Была причина». К сожалению, мы продаём лекарство от этого двадцать лет. Вики, Confluence, ADR, внутренние порталы. Каждое поколение точно спасёт нас в этот раз.
Все они упираются в одну экономическую проблему: человек, пишущий документацию, платит стоимость, а выгоду получает кто-то в будущем. ИИ-агенты могут изменить это, потому что агент уже присутствует, когда происходит работа. Он видел файлы, неудачный подход, исправление и причину изменения решения, поэтому создание компактного воспоминания имеет почти нулевую предельную стоимость.
Это гораздо интереснее, чем сказать, что ИИ умеет читать документацию. Возможность в том, что ИИ создаёт исторический след как побочный продукт работы, а не требует, чтобы люди документировали всё постфактум. Если это верно, агенты меняют экономику записи, которая убила многие предыдущие системы управления знаниями. Но «если» в этом предложении несёт серьёзную нагрузку. Я этого не доказал.
Прототип работает от начала до конца. Внешняя текстовая память может жить независимо от модели. Разные клиенты могут использовать одно хранилище. Воспоминания можно выборочно внедрять в новые сессии. Записи можно структурно валидировать, происхождение можно обеспечивать инфраструктурно, а устаревшую информацию можно показывать, а не молча доверять. Это доказывает, что субстрат жизнеспособен.
Но это не доказывает, что субстрат полезен. Это очень разные утверждения, и инженерия ИИ достаточно настрадалась от демо во вторник и объявления новой формы интеллекта в среду. Рабочий API памяти доказывает, что агент может извлечь предыдущее состояние. Утверждение, которое действительно имеет значение, — производит ли агент лучшую работу благодаря этому состоянию.
У памяти есть издержки. Она потребляет контекст, извлечение добавляет задержку, слабые воспоминания могут искажать рассуждения, а устаревшие — толкать агента к устаревшим предположениям. Идеально работающий слой памяти может стать эффективной системой импорта вчерашних ошибок в сегодняшнюю сессию. Архитектура создаёт ценность только если исследование и исправление, которых она позволяет избежать, дороже, чем накладные расходы на память.
Здесь моя гипотеза изменилась. Я думал, очевидный выигрыш — более дешёвые сессии. Агент с памятью должен тратить меньше токенов, потому что не будет заново открывать уже известные вещи. Но реальная ценность, вероятно, в другом: не в экономии токенов, а в качестве решений. Агент, который помнит контекст, принимает более обоснованные решения, чем тот, кто действует в вакууме. Это труднее измерить, но именно это делает память инфраструктурой, а не фичей.
Что делать прямо сейчас? Не стройте сразу сложную систему. Начните с простого: создайте каталог Markdown-файлов, где каждый файл — одно воспоминание с метаданными: автор, дата, статус доверия. Подключите его к вашему агенту через MCP или просто через чтение файлов. Дайте агенту инструкцию: перед началом задачи просмотреть индекс, и если есть релевантные воспоминания — прочитать их. После завершения задачи — записать краткое воспоминание о том, что было сделано и почему.
Попробуйте так поработать неделю. Посмотрите, какие воспоминания реально используются, а какие — нет. Отметьте, сколько раз агент извлёк что-то полезное. Это эксперимент, который покажет, работает ли экономика памяти в вашем контексте. Если да — расширяйте: добавляйте проверку происхождения, автоматическое устаревание, командный доступ. Если нет — вы узнаете это дёшево, не построив очередной «универсальный» инструмент.
Память — это не функция модели, это инфраструктура. Начните с малого, измеряйте, и вы поймёте, что работает именно для вас.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →