Короткий ответ

Самоулучшение агента — это не «он стал умнее после разговора». Надёжная схема выглядит гораздо скучнее:

baseline → гипотеза → изменение в ветке → benchmark → принять или откатить

Если нет baseline и проверяемого набора задач, агент не улучшает себя. Он просто переписывает собственную систему и сообщает, что теперь всё лучше.

Один красивый ответ ничего не доказывает

Агент может случайно хорошо решить одну задачу. Это не означает, что новая инструкция, модель или tool сделали систему лучше.

Нужно знать:

  • на каких кейсах измеряем результат;
  • что было до изменения;
  • что именно изменилось;
  • как считаем успех;
  • сколько ошибок допустимо;
  • не ухудшились ли другие сценарии.

Benchmark — это не обязательно большой научный набор. Для первой версии достаточно 10–30 типичных задач, если они честно отражают работу агента и остаются неизменными между сравнениями.

Из чего состоит минимальный benchmark

cases.jsonl
├── входная задача
├── нужный контекст
├── ожидаемая форма результата
├── допустимые варианты
└── опасные ошибки

Добавьте к каждому кейсу:

  • идентификатор;
  • уровень сложности;
  • тип ошибки, которую нужно поймать;
  • способ проверки;
  • признак, требует ли кейс человека.

Не прячьте ответы в prompt, если хотите измерять самостоятельность. И не меняйте кейсы после каждого плохого результата: иначе вы будете измерять собственную редактуру benchmark.

Безопасный цикл эксперимента

Шаг 1. Зафиксируйте baseline

Запустите текущую версию, сохраните ответы, ошибки, время, стоимость и причины остановки.

Шаг 2. Сформулируйте одну гипотезу

Например: «Если вынести длинную таблицу в reference и добавить короткий validator, агент реже пропустит обязательное поле».

Плохая гипотеза: «Сделаем всё умнее».

Шаг 3. Измените одну вещь

Ветвь нужна не ради ритуала. Она отвечает на вопрос: что именно мы сравниваем с baseline?

Шаг 4. Запустите тот же benchmark

Используйте те же кейсы и условия. Если изменились модель, лимит или набор tools, запишите это отдельно.

Шаг 5. Сравните не одну цифру

Смотрите минимум на:

  • долю правильно решённых задач;
  • критические ошибки;
  • количество попыток;
  • время и стоимость;
  • долю остановок с вопросом к человеку;
  • регрессии в старых сценариях.

Шаг 6. Примите или откатите

Изменение принимается, если заранее заданный критерий выполнен и критических регрессий нет. Иначе ветка откатывается, а причина сохраняется в журнале.

Почему rollback — часть самоулучшения

Агент, который умеет только менять систему, опасен. Агент, который умеет менять и возвращать её к последней рабочей версии, уже работает в более понятном инженерном контуре.

Минимальные границы:

  • эксперимент не пишет напрямую в production;
  • baseline хранится отдельно;
  • ветка имеет лимит времени жизни;
  • commit содержит результат проверки;
  • revert не удаляет отчёт о неудаче;
  • человек утверждает изменение, которое расширяет права агента.

Как не обмануть benchmark

Агент может начать оптимизироваться под тест:

  • запомнить конкретные формулировки;
  • подогнать ответ под ожидаемый шаблон;
  • убрать честное «не знаю» ради более высокой метрики;
  • сломать редкий, но важный сценарий;
  • научиться проходить validator, не решая задачу.

Поэтому держите несколько наборов:

train/dev — можно использовать для итераций
holdout   — не показывать агенту до проверки
red-team  — рискованные и неожиданные случаи

И добавляйте ручной просмотр части результатов. Автоматический score — сигнал, не окончательная истина.

Как трактовать чужие цифры

В исходном докладе звучит личный результат: агент якобы поднялся с 1 до 11 решённых задач из 89 за выходные автономной работы. Это интересный claim автора эксперимента, но не универсальная норма и не воспроизведённый нами benchmark.

В статье такие цифры можно приводить только с ясной маркировкой: кто получил результат, на каком наборе задач, какие были критерии и можно ли повторить эксперимент. Нельзя превращать чужой показатель в обещание читателю.

Что тестировать первым

Для первого внутреннего benchmark берите задачи, где результат можно увидеть:

  • найти нужный файл и сохранить отчёт;
  • внести изменение и пройти тест;
  • извлечь claims с указанием источников;
  • обновить skill, не затронув соседние папки;
  • остановиться при попытке опасного действия.

Не начинайте с «измерим интеллект». Начните с поведения, которое вы действительно хотите делегировать.

Что запомнить

Самоулучшение — это управляемая петля экспериментов, а не разрешение агенту переписывать себя без наблюдения.

Сначала соберите маленький benchmark. Потом разрешите одну гипотезу в отдельной ветке. Примите изменение только после сравнения и оставьте rollback обычной частью процесса.

Следующий гайд: Куратор skills: как чистить и развивать память агента.

Что читать дальше

Частые вопросы

Что главное в гайде «Как агент улучшает себя: гипотеза, benchmark и rollback»?

Самоулучшение агента начинается не с разрешения менять код, а с benchmark. Разбираем безопасный цикл: baseline, гипотеза, эксперимент, проверка и откат.

Нужно ли внедрять всё сразу?

Нет. Начните с одной проверяемой задачи, а следующий слой добавляйте после результата.

Что проверить перед запуском?

Права доступа, границы задачи, критерий готовности и возможность отката.

Источники

Редакторский статус: REVIEW. Личные цифры докладчика оставлены как claim и не должны подаваться как наш результат.