Autoresearch

Есть задачи, где результат выражается числом: время ответа, размер бандла, доля прошедших тестов, точность разбора, стоимость прогона. Если это число выдаёт скрипт, агента не нужно вести за руку. Он сам перебирает варианты, оставляет те, что улучшили метрику, а остальные откатывает. Этот приём называют autoresearch-подходом, по репозиторию Andrej Karpathy, где он показан на задаче обучения языковой модели.

Отличие от обычной работы: ты не проверяешь каждую правку. Ты один раз задаёшь метрику и правила, а потом читаешь журнал экспериментов и итоговый дифф.

Когда подходит

• Есть одно число, которое честно отражает цель.
• Это число считает скрипт, без твоего участия.
• Один замер укладывается в минуты, а не в часы: за прогон должно уместиться много попыток.
• Область правок узкая: один файл или несколько, всё остальное неприкосновенно.

Если метрику выставляет человек («стало приятнее пользоваться»), подход не работает. Возвращайся к обычному циклу с планом и тестами, см. Подходы к разработке.

Из чего состоит

Часть	Что это
Метрика	Одно число и направление: больше лучше или меньше лучше
Скрипт оценки	Одна команда, которая печатает это число. Например ./bench.sh
Область правок	Файлы, которые агенту разрешено менять
Гейт корректности	Тесты или линтер. Падение означает откат, каким бы ни был выигрыш
Журнал	Файл, куда после каждой попытки пишется: гипотеза, что изменено, метрика, вывод

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

Цикл

1. База. Прогнать оценку несколько раз подряд без единой правки. Записать значение и разброс между прогонами.
2. Гипотеза. Одна за итерацию, из журнала видно, что уже пробовали.
3. Правка только внутри области.
4. Замер и гейт корректности.
5. Решение. Выигрыш больше разброса означает коммит. Иначе git reset --hard или откат файлов.
6. Повтор до исчерпания бюджета или до плато.

Git тут не формальность: коммит на каждый удачный шаг даёт историю экспериментов, а откат стоит одну команду.

Шум в измерениях

Метрика редко стабильна: тот же код на том же железе даёт разные числа. Если принимать любое улучшение, половина «побед» окажется шумом, и цикл будет топтаться на месте.

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

Защита метрики

Весь цикл держится на одном допущении: число растёт, значит результат становится лучше. Ломается это допущение двумя способами, и оба стоят прогона впустую.

Агент правит измеритель. Самый дешёвый способ улучшить метрику это улучшить не код, а её подсчёт. Иногда прямо (подправить формулу, ослабить проверку), иногда исподволь: зашить ответы для тех строк, что попадаются в оценке, закешировать результат, поймать исключение и вернуть удобное значение.

• Скрипт оценки, эталонные данные и тесты лежат вне области правок. Проверь это не на словах: git diff после прогона не должен их касаться, а лучше сделать так, чтобы правка вызывала откат.
• В выводе оценки печатай только итоговое число. Если видны ожидаемые ответы, они рано или поздно окажутся в коде.
• Любое падение ранее зелёного теста означает откат, каким бы большим ни был выигрыш.
• Просматривай коммиты, а не только итоговое число. Дифф на тысячу строк ради процента обычно не стоит того.

Метрика просто неверна. Она может расти, пока результат стоит на месте или ухудшается: не тот знак, усреднение по не тем строкам, обучение на тех же данных, что и проверка, замер прогретого кеша вместо холодного старта.

• Перед стартом проверь измеритель заведомо плохим изменением. Сломай что-нибудь нарочно: метрика обязана упасть. Если не упала, цикл запускать рано.
• Держи отложенную часть данных или сценариев, на которых агент не оптимизирует, и прогони их в конце. Выигрыш исчез, значит решение подогнано под выборку.
• Сверяй метрику с целью хотя бы раз в несколько итераций своими глазами. Если число выросло на треть, а поведение не изменилось, это повод разбираться с измерителем, а не радоваться.
• Всё, чего в метрике нет, агент ухудшит без колебаний. Читаемость, память, размер образа: если это важно, добавляй в проверку явно.

Как запускать

Два способа, отличаются тем, кто держит правила цикла.

В сессии. Формулируешь правила в запросе, ставишь условие остановки через /goal и наблюдаешь. Быстро начать, но правила соблюдает сам агент.

Скриптом снаружи. Каждая итерация это отдельный запуск waibee run, а решение «оставить или откатить» принимает скрипт. Агент физически не может обойти правило.

noise=0.004                       # разброс базы, замерен заранее
best=$(./bench.sh)                # больше лучше

for i in $(seq 1 30); do
  waibee run "прочитай experiments.md, предложи одну ещё не проверенную гипотезу,
    измени только src/parser.rs, прогони ./bench.sh и допиши строку в experiments.md"

  score=$(./bench.sh)
  if awk "BEGIN{exit !($score > $best + $noise)}" && cargo test -q; then
    best=$score
    git commit -qam "exp $i: $score"
  else
    git checkout -- src/parser.rs
  fi
done

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

Что так оптимизируют

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

Ловушки

• Метрика мимо цели. Ускорили эндпоинт, потеряв корректность в редком случае, которого нет в наборе.
• Шум принят за улучшение. База замерена один раз, порог не задан.
• Дорогая оценка. Замер по десять минут означает единицы попыток за прогон, цикл не окупается.
• Прогон без присмотра до конца. Загляни в журнал после первых пяти экспериментов: там сразу видно, чинит агент задачу или подбирается к измерителю.

Откуда это пошло

Подход популяризировал Andrej Karpathy в репозитории karpathy/autoresearch. Там агент ищет способы быстрее обучить небольшую языковую модель, и вся конструкция держится на трёх файлах:

Файл	Роль
train.py	Единственный файл, который агент правит: модель, оптимизатор, цикл обучения
prepare.py	Подготовка данных и оценка. Агент его не трогает
program.md	Инструкции агенту: что пробовать, чего избегать. Этот файл ведёт человек

Каждый прогон обучения занимает ровно пять минут по часам, независимо от железа. Отсюда два следствия: эксперименты сравнимы между собой, что бы агент ни поменял (размер модели, батч, архитектуру), и за ночь их набирается около сотни, примерно двенадцать в час. Обратная сторона: результаты с разного железа между собой уже не сравнить.

Метрика одна: val_bpb, бит на байт на отложенной выборке, меньше лучше. Она не зависит от размера словаря, поэтому архитектуры сравниваются честно.

Главная мысль там не про обучение моделей: код правит агент, а ты правишь program.md. Направление, список проверенных тупиков и приоритеты гипотез это теперь твой рабочий файл.

Три решения оттуда переносятся на любую задачу: один файл под правки, фиксированная стоимость замера и метрика, устойчивая к тому, что агент будет менять. Исходный репозиторий требует NVIDIA GPU, для остальных платформ в его README перечислены форки (macOS, MLX, Windows, AMD).

Готовые реализации

На основе исходного шаблона сделаны навыки и плагины, которые переносят цикл на произвольную задачу. Заметный пример: autoresearch-claude-code. Все правила выше там уже зашиты, плюс то, что своим скриптом писать долго:

• простой контракт метрики: скрипт печатает в stdout строку METRIC name=число, остальной вывод игнорируется;
• бюджет числами: предел прогонов, предел секунд, целевое значение метрики;
• дерево экспериментов со ссылкой на родителя, чтобы возвращаться из тупика, а не идти жадно вперёд.

Такие наборы в формате Claude Code, поэтому ставятся в Waibee Code как обычные навыки и плагины.

Осторожно

Часть реализаций удерживает цикл хуком на событии Stop: он не даёт агенту завершить ход, пока не исчерпан бюджет. В Waibee Code это не сработает: хук на Stop запускается уже после того, как ход завершён, и его вывод не читается. Ход меняют только UserPromptSubmit и PreToolUse, см. Хуки. Держи цикл через /goal или внешним скриптом, всё остальное из такого набора работает как есть.

Начинать проще со своего скрипта: цикл выше умещается в десяток строк bash, а правила важнее реализации.