TL;DR
GEPA-Curator — надстройка над автоматической доработкой промпта агента. Обычно модель-«разборщик» читает провалившиеся прогоны и правит промпт. Куратор встаёт перед ней и делает две вещи. Первая: выкидывает из разбора задачи с шумным сигналом: слишком лёгкие, невыполнимые, нестабильно оцениваемые. Вторая: к каждому провалу подкладывает успешный прогон той же задачи как эталон.
Главная находка: не каждый провал агента говорит о слабом промпте. Кнопка на сайте глючит, задача поставлена криво, судья-LLM сегодня ставит «зачёт», завтра «незачёт». Разборщик этого не знает и честно «лечит» промпт. Он дописывает правила вроде «ищи обходной путь», и промпт портится. В эксперименте на смеси «исправимых» и «невыполнимых или нестабильных» задач качество упиралось в потолок. На смеси с лёгкими задачами оно доходило почти до идеала.
Куратор работает в один вызов LLM по истории каждой задачи. Он решает, брать ли задачу в разбор. Для провалов он выбирает один надёжный успех той же задачи или воздерживается, если надёжного успеха нет. Разборщик сравнивает «как сейчас провалилось» и «как раньше получилось» и не гадает.
Схема метода
ЦИКЛ (каждая итерация доработки промпта):
ШАГ 1: Куратор смотрит историю каждой задачи
(прошлые прогоны + оценки)
→ решение: брать в мини-пакет / пропустить
Пропускаем: стабильный успех, провалы из-за среды/обвязки,
противоречивые оценки похожих результатов.
Новые задачи берём в первую очередь.
ШАГ 2: Для провалов в пакете — выбор одного успешного прогона
той же задачи (самый надёжный по истории).
Нет надёжного успеха → воздержаться.
(Шаги 1–2 — один вызов куратора)
ШАГ 3: Разборщик получает провалы + эталонные успехи
→ правит промпт агента
ШАГ 4: Прогоны и оценки пишутся обратно в историю.
Пропуск временный: пропущенные задачи
пересматриваются каждую эпоху.
Это код-оркестрация: нужны окружение, прогоны, хранилище истории.
Пример применения
Метод целиком — инженерный. Читателю доступна ручная версия: разбор журнала провалов своего агента перед правкой инструкции. Это моя адаптация принципа, в статье её не проверяли.
Задача: Селлер на Ozon ведёт карточки товаров через агента в браузере. После недели работы набралось 30 неудачных прогонов. Раньше он просил модель «посмотри логи и перепиши системный промпт», и промпт распухал от странных правил. Часть провалов вообще не про промпт: - в личном кабинете в пятницу вечером падала кнопка «Сохранить»; - по одному товару категории просто не существует; - судья-LLM один и тот же результат оценил то «ок», то «не ок».
Промпт:
Ты — куратор журнала провалов агента. Агент заполняет карточки
товаров в личном кабинете Ozon Seller. Системный промпт агента
ниже, затем журнал из 30 прогонов (по каждому: задача, шаги агента,
итог, оценка судьи; для части задач есть по 2–3 прогона).
Работай в два этапа.
ЭТАП 1. Отбор задач. По каждой задаче вынеси вердикт:
- GOOD — провал вызван слабостью промпта: агент пропустил
обязательное поле, не проверил результат, выбрал не тот инструмент;
- EASY — стабильно успешна, разбирать нечего;
- IMPOSSIBLE — проваливается из-за среды или обвязки (кабинет
сбоит, нет нужного инструмента) либо сама задача некорректна;
- FLAKY — похожие результаты оцениваются по-разному.
Для каждого вердикта дай причину в одну строку со ссылкой на
конкретный шаг в журнале. Если улик мало — пиши «недостаточно данных»,
не угадывай. Вердикт временный: его пересмотрят после следующей правки.
ЭТАП 2. Эталоны. Для каждой задачи с вердиктом GOOD найди в журнале
один успешный прогон той же задачи, в успехе которого нет сомнений
(оценка согласуется с остальными записями). Если такого нет —
напиши «эталона нет» и ничего не подставляй.
ЭТАП 3. Только теперь предложи правки промпта. Опирайся только на
задачи GOOD. Для каждой правки покажи: провал → эталонный успех →
в чём разница в действиях → какая строка в промпте это исправит.
Задачи IMPOSSIBLE и FLAKY в правках не используй.
[системный промпт агента]
[журнал прогонов]
Результат: Модель сначала выдаст таблицу: задача, вердикт, причина со ссылкой на шаг. Затем для задач GOOD выберет эталонные успехи или честно напишет «эталона нет». В конце будет короткий список правок промпта, где у каждой есть цепочка «провал → эталон → разница → строка». Правил про «обходные пути при сбое кнопки» в списке быть не должно, а падающий кабинет попадёт в IMPOSSIBLE.
Почему это работает
Слабость. Разборщик получает провал и считает, что виноват промпт. Он не видит, что причина в сломанной среде, кривой задаче или шумном судье. Ему нужно объяснить провал, поэтому он добавляет правило. Плохое правило потом портит и те задачи, которые раньше проходили. Проверка «стало ли хуже на выборке» тоже шумная, и плохие правки иногда проходят.
Сильная сторона. Модель хорошо сравнивает два текста и находит, где они разошлись. Если рядом лежат провал и успех одной и той же задачи, различие в действиях видно прямо. Не нужно гадать, что исправить.
Как метод это использует. Сначала отсекаем задачи, где сигнал заведомо мусорный. Потом даём разборщику эталон, и сравнение заменяет догадку. Эталон тоже фильтруют: «успех» с сомнительной оценкой хуже, чем его отсутствие, поэтому куратор может воздержаться.
Рычаги управления: - Критерии пропуска (стабильный успех, внешние причины, противоречивые оценки). Добавь свой, например «задача зависит от данных, которые менялись». - Воздержание («эталона нет»). Не убирай: именно оно не даёт подсунуть ложный пример. - Временность вердикта. Пересматривай пропущенное после каждой правки. Раньше решённые задачи могут сломаться от новых правил, а раньше «невозможные» могут стать решаемыми. - Требование ссылок на шаги журнала. Оно не даёт модели выдумывать причины.
Шаблон промпта
Ты — куратор журнала прогонов агента. Агент делает: {что_делает_агент}.
Ниже системный промпт агента и журнал прогонов. По каждому прогону:
задача, шаги, итог, оценка ({кто_оценивал}).
ЭТАП 1. Отбор задач. Для каждой задачи вердикт:
- GOOD — провал из-за слабости промпта;
- EASY — стабильно успешна;
- IMPOSSIBLE — провал из-за среды, инструментов, обвязки
или некорректной задачи;
- FLAKY — похожие результаты оценены по-разному.
К каждому вердикту — причина в одну строку и ссылка на шаг журнала.
Улик мало — «недостаточно данных».
ЭТАП 2. Эталоны. Для каждой задачи GOOD выбери один надёжный
успешный прогон этой же задачи (оценка согласуется с остальными
записями). Надёжного нет — напиши «эталона нет».
ЭТАП 3. Правки промпта. Только по задачам GOOD. Для каждой правки:
провал → эталон → разница в действиях → строка для промпта.
IMPOSSIBLE и FLAKY не использовать. Максимум {число_правок} правок.
[системный промпт агента]
[журнал прогонов]
Что подставлять: {что_делает_агент} — одна фраза о задаче агента. {кто_оценивал} — человек, судья-LLM или автотест. {число_правок} — лимит, чтобы промпт не раздувался. Системный промпт и журнал вставь в конец.
🚀 Быстрый старт — вставь в чат:
Вот шаблон куратора журнала провалов. Адаптируй под мою задачу:
{опиши своего агента и как ты оцениваешь его работу}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что делает агент, кто и как оценивает результат, какие сбои среды бывали. Это нужно, чтобы вердикты IMPOSSIBLE и FLAKY опирались на твои реальные сбои, а не на общие догадки. Она возьмёт паттерн из шаблона и подстроит его под твоё окружение.
Ограничения
⚠️ Метод в статье — код, а не промпт: Куратор работает в цикле на тысячах прогонов (от 800 до 5000 на бенчмарк). Ручная версия выше — адаптация принципа. Её эффект в статье не измерялся.
⚠️ Нужны повторные прогоны: Куратор опирается на историю задачи: несколько прогонов, оценки, успехи. Если задача запущена один раз, отличить шум от слабости промпта сложнее.
⚠️ Куратор — тоже LLM и тоже ошибается: Диагнозы меняются от итерации к итерации. У восьми задач одновременно были вердикты «невозможна» и «нестабильна». Поэтому пропуск делают временным.
⚠️ Прирост разный: На WebArena плюс несколько пунктов к обычной доработке. Значительно больше — на AppWorld. На одном из тестов с Claude Opus 5 результат не отличался от GEPA. Часть разбросов перекрывается.
⚠️ Узкая проверка: Исполнитель во всех опытах один — gpt-oss-120b, задачи — стандартные бенчмарки, а не живые рабочие процессы. Статья на рецензии, текст в моём распоряжении обрывается на разделе 5.2.
⚠️ Редких «плохих» задач мало: Среди 1581 задач нестабильных и невозможных было около 5%. Выигрыш зависит от того, сколько мусора в твоём наборе.
Как исследовали
Исследователи взяли четыре сайта из WebArena (GitLab, магазин, админка магазина, Reddit) и три других бенчмарка: ALFWorld, AppWorld и τ-bench. Исполнителем был gpt-oss-120b. Промпт дорабатывали две модели: Gemini 3.1 Pro и Claude Opus 5. Сравнивали с GEPA (обычная доработка промпта по провалам) и ACE (накопление «плейбука» стратегий). Каждый результат усредняли по 5 запускам.
Сначала проверили саму идею. Задачи GitLab разделили на лёгкие, исправимые, невыполнимые и нестабильные. Исправимые вместе с лёгкими доходили почти до идеала (15 из 16). Исправимые в смеси с невыполнимыми или нестабильными упирались в 12 из 16: шумные задачи действительно портят промпт.
Куратор разобрал 1581 тренировочную задачу GoBrowse. Из них 95% оказались нормальными, около 1% невозможными и около 4% нестабильными. Большинство невозможных задач (две трети) упиралось в среду или обвязку агента. Нестабильные чаще всего имели дефект в самой задаче (46%).
Дальше проверили, хватит ли простой статистики: например, «задача то успешна, то нет». На смеси с нестабильными задачами такая «числовая» учебная программа дала 62,5%, хуже обычного GEPA (66,2%). Куратор, который читает следы прогонов, а не только исходы, дал 67,4%. С эталонными успехами — 70,2%. Вывод: одного «успех/провал» мало, нужно смотреть, почему результат такой.
В итоге на WebArena куратор дал в среднем 82,1% против 78,7% у GEPA (Gemini) и 84,5% против 79,5% (Opus). На AppWorld один из тестов у Gemini вырос с 27,8% до 46,2%. В абляции на GitLab каждый компонент отдельно давал около 84%, вместе 88,6%. Компоненты дополняют друг друга: один решает, какие провалы разбирать, второй — на что опереться при разборе.
Адаптации и экстраполяции
💡 Адаптация для правки CLAUDE.md / AGENTS.md: Когда агент в Cursor или Claude Code провалил задачу, не добавляй правило сразу. Сначала спроси: это слабость инструкции или сломан тест, не хватает доступа, задача поставлена неоднозначно?
Агент провалил задачу: {описание}. Лог: {лог}.
Прежде чем предлагать правку CLAUDE.md, определи причину:
(а) инструкция не покрывает ситуацию; (б) сбой среды/доступов/инструментов;
(в) задача была поставлена неоднозначно или невыполнима.
Укажи шаг лога, подтверждающий причину. Правку предлагай только для (а).
Если у этой задачи раньше был успешный прогон — сравни действия.
🔧 Техника: убрать требование ссылок на шаги → вердикты становятся голословными. Оставь требование: оно заставляет модель опираться на журнал. Эффект такой замены в статье не проверяли.
Ресурсы
- GEPA-Curator: Curated Learning for Self Improving Agents (Under Review)
- Авторы: Zack Yu, Nicholas Lee, Minjae Lee, Lakshya Agarwal, Luca Manolache, Wonjun Kang, Matei Zaharia, Michael W. Mahoney, Kurt Keutzer, Sehoon Kim, Amir Gholami
- Организации: UC Berkeley, ICSI, LBNL, Furiosa AI, KAIST
- Связанные работы: GEPA (Agrawal et al., 2026), ACE (Zhang et al., 2026), SkillOpt, Meta-Harness; бенчмарки GoBrowse / WebArena, ALFWorld, AppWorld, τ-bench