Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Долгосрочную память ИИ-агента научились сверять с рабочей средой до того, как новый опыт попадёт в общее хранилище. В препринте, который ещё не прошёл рецензирование и содержит замеры самих авторов, доля пройденных заданий CLBench выросла с 39% до 73%. Схема не требует переобучать модель: она добавляет отдельному куратору доступ только на чтение и не расширяет права агента, который выполняет пользовательскую задачу.
Как куратор проверяет память перед записью
Обычная память агента строится на завершённых траекториях: запросе, вызовах инструментов, полученных данных, ответе и итоговой оценке. Такая траектория показывает один путь через среду. Если агент выбрал неверное поле базы данных или нашёл обходной способ, куратор может сохранить ошибку как полезный опыт.
Предложенная схема разделяет выполнение задачи и ведение памяти. Пользовательскую задачу решает свежая сессия агента: она читает накопленные записи, но не может их менять. После ответа запускается отдельный куратор, который получает полную траекторию, её краткую выжимку, оценку результата и связанные записи из памяти.
Только куратор может создавать, обновлять и удалять записи. Перед изменением памяти он формулирует предполагаемое правило, а затем проверяет его через ограниченный набор инструментов рабочей среды. Инструменты разрешают читать данные, но не менять их.
Проверка отвечает на конкретный пробел в опыте. Куратор может уточнить ключ для соединения таблиц, проверить правило на другой части данных, найти актуальное имя поля после изменения схемы или воспроизвести более короткую процедуру. После этого он сохраняет правило, сужает область его применения, заменяет устаревшую запись либо отказывается от записи.
Эта работа идёт после завершения пользовательского запроса и не расходует бюджет инструментов основного агента. Будущие задачи и их ответы куратор не видит. Если среда не предоставляет безопасного интерфейса для чтения, схема возвращается к разбору одной траектории.
Проверенная память снизила повторное исследование среды
Основной прогон CLBench включал 40 последовательных вопросов на gpt-5.4 и изменение скрытой схемы базы данных в середине потока. Adapted APEX добавил 90 задач по анализу документов из нескольких общих рабочих сред. Сравнивали запуск без памяти, перенос полных прошлых траекторий, обычную индексированную память и память с проверкой среды.
CLBench требовал строгого правильного ответа, а итоговая награда дополнительно учитывала расход запросов к базе. Стоимость работы основного агента снизилась с $3.38 до $1.68. Одновременно агент реже исследовал уже известные связи и чаще проходил задания после изменения схемы.
Полный перенос предыдущих траекторий тоже помогал, но его контекст рос вместе с историей работы. Индексированная память возвращала только короткие подходящие записи, поэтому не связывала размер контекста с возрастом системы. Проверка среды дополнительно превращала расплывчатые предупреждения вроде «это вычисление неверно» в исполнимые инструкции с таблицей, ключом соединения, фильтрами и способом агрегации.
На Adapted APEX все сравнения памяти с запуском без памяти дали положительный прирост средней награды. Проверка среды показала лучшую отдачу основного агента на доллар в большинстве рабочих сред. В отдельных прогонах без изменения схемы её средняя награда также оказалась выше обычной памяти на Sonnet и Opus.
Проверяли последовательности связанных задач в производственно-подобном стенде GitHub Copilot, а не работу внутри действующей корпоративной системы. В расчёт стоимости не вошли выжимка траектории и работа куратора, поэтому снижение расходов основного агента нельзя считать готовой оценкой полной стоимости эксплуатации.
Что меняется в архитектурном плане
Работа предлагает не новую систему памяти, а дополнительный этап контроля перед записью. Модель, агент задач, поиск по памяти, формат записей и полномочия на изменение рабочей среды остаются прежними. Команда может добавить проверку к уже существующему асинхронному куратору без переобучения модели и переноса всех компонентов.
Граница полномочий получается ясной: основной агент пользуется рабочими инструментами и только читает память, а куратор меняет память и только читает рабочую среду. Его запросы проходят через те же механизмы аутентификации и аудита, что и остальные подключения платформы. Проверки не задерживают уже подготовленный пользователю ответ.
Такая схема подходит системам, где задачи повторно используют скрытую структуру среды: схему базы, расположение файлов, связи между документами или правила вызова инструментов. Здесь ошибочная запись переносится между сессиями, а проверка один раз на этапе ведения памяти может убрать повторные исследования во время следующих задач.
Планы стоит менять на уровне контура памяти, а не выбора поставщика модели. Вместо автоматической записи выводов из каждой завершённой траектории нужен этап «предложить, проверить, сохранить» с отдельной ролью и минимальными правами. При пилоте придётся считать весь контур, включая работу куратора, и заранее определить, какие источники можно безопасно открыть ему для чтения.
Если агент решает независимые задачи, не использует постоянную память или не имеет интерфейса чтения рабочей среды, работа не даёт ему нового механизма. Для долгоживущих агентов она показывает практичный способ повысить качество записей, не превращая основной агент в более привилегированный и дорогой компонент.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
