TL;DR
Самоэволюционирующий агент сам переписывает свою «обвязку» (системный промпт, память, файлы навыков, код оркестрации) по итогам задач, а веса модели не трогает. Исследователи прогнали три такие схемы на потоках разнородных задач. Агент учился одному типу задач за раз и должен был не потерять уже выученное. Общий итог положительный, но небольшой, а за рост на текущей задаче агент платит потерями на остальных.
Главная боль в том, что любое правило, которое агент дописал в общий системный промпт, работает на всех задачах сразу. Агент месяц решал SQL-задачи, и в промпте появились правила вроде «всегда сначала исследуй базу, проверяй интерактивно». Когда пришли задачи, где надо спросить пользователя о недостающих данных, агент стал лезть в инструменты поиска вместо вопроса. Ни одной такой задачи он ещё не видел, а точность уже упала. Позже новые правила сжимают или затирают старые, и выученное пропадает. Подтягивать нужные заметки из внешней памяти по сходству запроса безопаснее, но и там при похожих запросах с разным нужным порядком действий достаётся чужая заметка.
Три проверенные схемы: ReasoningBank (память с поиском по сходству, достаёт одну заметку), GEPA (переписывает секцию «стратегия» в системном промпте), Meta-Harness (правит промпт, память, навыки и код, но принимает правку только если она улучшает проверку). Чем шире агент может править себя, тем быстрее учится и тем сильнее ломает остальное.
Схема метода
Это не метод для применения, а картина того, как устроены три схемы и где они ломаются.
ReasoningBank: эпизод → заметка в хранилище → при новой задаче достаём 1 самую похожую
+ локально, меньше забывает
− достаёт чужое, путает похожие запросы с разным порядком действий
GEPA: эпизоды → модель разбирает ошибки → переписывает секцию «стратегия» в общем промпте
+ быстрее всех учится
− правило действует на ВСЕ задачи, новые блоки затирают старые
Meta-Harness: кодовый агент правит промпт, память, навыки, код → принимаем правку, только если проверка выросла
+ гейт отсекает половину вредных правок
− без гейта стабильность заметно хуже
Пример применения
Метод из статьи сам по себе вам не нужен: GEPA и Meta-Harness требуют кода. Применима находка: накопленные правила в общем файле инструкций ломают соседние задачи. Ту же болезнь вы лечите руками в системном промпте, CLAUDE.md или AGENTS.md.
Задача: Вы ведёте ИИ-агента поддержки селлера на Wildberries. Полгода после каждого сбоя вы добавляли в общий промпт по правилу. Теперь там 60 пунктов. Среди них «всегда сначала ищи заказ в выгрузке, потом отвечай» и «если не хватает данных, сначала уточни у клиента». Агент всё чаще то зря ищет, то зря переспрашивает. Это тот же конфликт, что в статье: «сначала исследуй» против «сначала спроси».
Промпт:
Ты проводишь аудит файла правил для ИИ-агента поддержки селлера на Wildberries. Правила копились полгода: каждое добавляли после конкретного сбоя в одной ситуации.
<Агент>Отвечает покупателям и менеджеру по возвратам, ищет заказы в выгрузке, формирует ответы по шаблонам.
<Типы_задач>1. Возврат и брак. 2. Где мой заказ. 3. Вопрос по размеру и характеристикам. 4. Жалоба на ПВЗ. 5. Просьба об отзыве.
<Правила>[вставлен файл из 60 пунктов]
Для каждого правила: 1) определи, из какого типа задач оно родом; 2) проверь, что оно сделает на каждом из остальных типов (поможет / не повлияет / навредит); 3) если навредит — покажи пример, как агент ошибётся.
Затем найди пары правил, которые противоречат друг другу на похожих запросах.
Перепиши файл так, чтобы каждое правило было в форме «Когда {признак задачи}: делай X. В остальных случаях не применяй».
Верни: таблицу «правило → родной тип → вред для других», список конфликтов, переписанный файл и 10 тестовых запросов (по 2 на тип), на которых нужно проверить новую версию.
Результат: Модель выдаст таблицу правил с пометкой, где каждое из них может навредить. Затем список конфликтующих пар, например «всегда ищи» против «сначала спроси». Потом переписанный файл с правилами в форме «когда… делай…» и набор тестовых запросов. Конкретные выводы зависят от вашего файла.
Почему это работает
Слабость. Общий промпт читается на каждой задаче. Правило, выведенное на одном типе задач, ничего не знает о границах своей области. Модель применяет его везде, где оно хоть как-то подходит по смыслу. Так SQL-привычка «исследуй базу» вытеснила поведение «спроси пользователя».
Сильная сторона. Модель хорошо следует условным инструкциям и умеет разбирать текст на противоречия. Условие «когда X — делай Y» ограничивает область действия, а LLM можно попросить найти, где правила конфликтуют.
Как это использует аудит. Он работает как ручной аналог того, чего не хватило самоэволюции: правило получает привязку к типу задачи, а изменения проверяются на других типах. Авторы такого решения не проверяли, это вывод из их находок.
Рычаги управления: - Узкие триггеры («когда клиент просит возврат») снижают утечку правил, но повышают риск не сработать. - Больше тестовых запросов на каждый тип дают надёжнее проверку, но это больше ручной работы. - Вопрос «навредит ли правило другим типам» можно сделать обязательным шагом перед каждым добавлением нового правила.
Шаблон промпта
В статье нет готового промпта для читателя. Шаблон ниже построен на её выводах и не взят из неё.
Ты проводишь аудит файла правил для ИИ-агента. Правила копились со временем: каждое добавляли после конкретного сбоя в одной ситуации.
<Агент>{что делает агент}
<Типы_задач>{3-6 типов задач, которые ему приходят}
<Правила>{вставь файл правил}
Для каждого правила: 1) определи родной тип задач; 2) проверь, что оно сделает на каждом другом типе (поможет / не повлияет / навредит); 3) если навредит — покажи пример ошибки.
Найди пары правил, которые противоречат друг другу на похожих запросах.
Перепиши файл: каждое правило в форме «Когда {признак задачи}: делай X. В остальных случаях не применяй».
Верни: таблицу, список конфликтов, переписанный файл и {число} тестовых запросов для проверки на регрессию.
Подставьте описание агента, список типов задач (если не знаете, пусть модель предложит по файлу) и сам файл.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита файла правил для агента. Адаптируй под мою задачу: [опиши агента и вставь свои правила].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие типы задач приходят агенту и какие сбои вызвали правила. Без списка типов задач нельзя проверить, где правило «утекает» в чужую область. Она возьмёт паттерн из шаблона и адаптирует под вашу задачу.
Ограничения
⚠️ Нет проверенного решения: Авторы показывают проблему и называют направления (изоляция правок, выбор записей не только по сходству запроса). Свой способ лечения они не проверяли. Аудит выше — наша экстраполяция.
⚠️ Одна модель и малые выборки: Все эксперименты на одной модели, по 50 задач на группу. Размеры эффектов (единицы процентных пунктов) нужно читать как тенденцию.
⚠️ Автоматическая самоэволюция, не ручная: Исследовали алгоритмы, которые сами переписывают свой промпт. Как ведёт себя промпт, который правите вы, прямо не проверялось.
⚠️ Тема не везде вредит: Когда задачи различаются только темой (разные базы данных, один тип действия), самоэволюция почти ничего не дала, а в части случаев ухудшила результат.
⚠️ Нужна оговорка по тексту: Текст статьи в доступной версии обрывается в разделе 4.3. Вывод про ретрив и коллизии взят из аннотации и введения.
Как исследовали
Исследователи собрали четыре потока задач, в которых агент учится блоками по 50 задач из одной группы. Потоки отличаются типом сдвига: тема (три разные базы данных), порядок работы (спросить недостающие данные или не спрашивать), среда целиком (научные эксперименты, вызов API, SQL) и всё вместе. Агент не знает, что тема сменилась. На границах блоков сохраняли «слепок» обвязки и прогоняли его по отложенным задачам всех групп, по 8 прогонов на задачу.
Сравнивали три схемы: ReasoningBank, GEPA и Meta-Harness. Для каждой считали две величины: пластичность (насколько выучил текущий блок) и стабильность (потери на ещё не виденных группах и на уже пройденных). В среднем у GEPA самая высокая пластичность, примерно вдвое выше ReasoningBank, но и самая низкая стабильность. ReasoningBank стабильнее всех. Итоговый вывод: чем шире то, что агент может править, тем больше он учит и тем больше ломает.
Любопытные детали. Meta-Harness выглядел стабильным на двух потоках только потому, что проверочный гейт отвергал половину и больше правок, и обвязка просто замерзала. Без гейта стабильность заметно падала. Разбор эволюционировавшего промпта показал причину ухудшения. После двух SQL-блоков в него записали требования «исследуй базу и проверяй интерактивно», и до первой BFCL-задачи точность на задачах с недостающими аргументами упала на несколько пунктов. Агент стал вызывать поисковые инструменты вместо вопроса пользователю.
Адаптации и экстраполяции
💡 Адаптация: регрессионный набор для файла инструкций. Вместо «валидационного гейта» Meta-Harness заведите 10–20 тестовых запросов, по 2–4 на каждый тип задач. Перед каждым добавлением нового правила прогоняйте агента по набору целиком, а не только по той ситуации, из-за которой правило появилось. Если страдает соседний тип, правило нужно сузить до условного.
🔧 Техника: правило с триггером вместо правила без области. Было: «Всегда сначала исследуй данные». Стало: «Когда задача — SQL-запрос по неизвестной схеме: сначала исследуй таблицы. Когда в запросе не хватает данных от пользователя: не исследуй, а задай вопрос». Узкий триггер ограничивает утечку правила на чужие задачи, а явное «когда не применять» защищает от конфликта.
Ресурсы
- Are Self-Evolving Agents Continual Learners? — Xiaoyin Chen (Mila – Quebec AI Institute, Université de Montréal; работа выполнена в Google DeepMind), Yizheng Huang, Yinglun Xu, Ziyun Zhao, Emmett McQuinn, Julie Liu, Hope Yao (Google DeepMind).
- Исследуемые методы: ReasoningBank (Ouyang et al., 2025), GEPA (Agrawal et al., 2025), Meta-Harness (Lee et al., 2026).
- Бенчмарки: BIRD (text-to-SQL), BFCL (вызов API), ScienceWorld (научные эксперименты в текстовой среде).