TL;DR
Fork-and-flush (форкни и сбрось) — приём для долгих задач, где агент сам ставит эксперименты и получает числовой скор. Периодически вы копируете рабочую папку агента в несколько веток (по умолчанию 4). В каждую ветку идёт новый агент с чистой историей чата, но со всеми накопленными файлами. Ветки работают короткий отрезок. Дальше вы продолжаете только с веткой, набравшей лучший скор, а остальные выбрасываете.
Боль знакома тем, кто запускал агента «на ночь». Один и тот же агент на одной и той же задаче в разных запусках застревает на разных уровнях: один упёрся на 68 баллах, другой дошёл до 100. Добавленные часы работы разрыв не закрывают. Агент выбирает подход в начале и дальше только шлифует его. Авторы назвали такие подходы «ямами идей» (idea basins). Ещё важнее то, что накопленная история чата тянет агента обратно в ту же яму, даже если её периодически сжимать.
Метод чинит это двумя ходами. Fork даёт несколько попыток из одной точки и выбирает победителя по скору. Flush убирает из контекста старые рассуждения, а файлы оставляет. Вместе, при том же бюджете, это дало +66% к обычному одиночному запуску и +44% к «4 независимым запускам, берём лучший».
Схема метода
СТАРТ: 4 агента с пустой папки, короткий отрезок каждому → лучший становится «лидером»
ЛИДЕР: работает один, обычным образом, пока не потрачено ~33% общего бюджета
ФОРК: копия папки лидера ×4 + ЧИСТЫЙ чат у каждой копии (flush)
ОТРЕЗОК: каждая ветка работает фиксированный бюджет (~6% от общего)
ВЫБОР: лучший скор → новый лидер, остальные 3 удалить
ПОВТОР: то же самое на ~66% бюджета
ФИНАЛ: лидер дорабатывает остаток; результат = лучший скор за всю историю
Бюджет в экспериментах: - 3 раунда по 4 ветки, примерно 24% бюджета на раунд; - примерно 72% бюджета уходит на ветвления, примерно 28% на серийную работу лидера; - каждый раунд запускается по расписанию, а не по сигналу «застрял».
Пример применения
Задача: Владелец магазина на Ozon и Wildberries просит агента (Claude Code) ускорить скрипт пересчёта остатков и цен. Сейчас он гоняет 500 тысяч строк выгрузки за 14 минут. Есть автоматическая метрика: время прогона, плюс тесты, которые проверяют корректность итоговой таблицы. Агент уже полдня выжимает скорость, застрял на микрооптимизациях pandas (с 14 до 11 минут) и ходит кругами.
Промпт (одинаковый для каждой из 4 веток, каждая в новой сессии на своей копии папки через git worktree):
Ты продолжаешь оптимизацию скрипта пересчёта остатков. Предыдущих рассуждений у тебя нет — только файлы в папке.
Что есть в папке:
- recalc.py — текущая лучшая версия
- NOTES.md — журнал: что пробовали и какие были результаты
- benchmark.sh — запускает прогон на 500 000 строк и выводит время в секундах
- tests/ — тесты корректности; без их прохождения скор не засчитывается
Текущий лучший результат: 660 секунд.
Цель: сократить время. Ограничение: тесты должны проходить.
Правила:
1. Сначала прочитай NOTES.md и recalc.py.
2. Не ограничивайся мелкими правками текущего подхода. Если считаешь, что нужна другая архитектура (другая библиотека, другая структура данных, другой алгоритм), — пробуй её.
3. После каждого изменения запускай benchmark.sh и tests/. Записывай в NOTES.md результат: что сделал и сколько секунд.
4. Остановись, когда потратишь свой лимит: {лимит — например, 25 запусков benchmark.sh или 1,5 часа}.
5. В конце выведи: лучшее время, что именно дало выигрыш.
Результат: Вы получите 4 параллельные попытки на одной базе. Три из них, вероятно, продолжат шлифовать то же самое. Одна может уйти в другой подход, например в перенос расчёта в SQL или в векторизацию. Вы сравниваете время по benchmark.sh, выбираете ветку с лучшим результатом, остальные удаляете. Дальше эта ветка становится основной, и через несколько часов работы цикл можно повторить.
Почему это работает
Слабость модели. Длинный чат подталкивает агента к продолжению уже выбранной линии. Он видит свои прошлые рассуждения, находит в них логику и идёт по той же колее. Сжатие истории не помогает: яма остаётся, потому что сжатая версия тоже несёт прежнюю идею.
Сильная сторона. Агент хорошо работает с файлами. Из папки, журнала и кода он быстро восстанавливает картину и может продолжить с чистого листа без потери результата. Плюс у разных запусков из одной точки результаты сильно различаются, и разброс можно использовать.
Как метод это использует. Flush сбрасывает инерцию, потому что файлы остаются, а старые рассуждения уходят. Fork превращает разброс в выбор: вы запускаете несколько вариантов и берёте победителя по числу. Нужны оба хода. По ablation (исследованию с отключением частей метода): - только flush: 0,55 против 0,45 у одиночного запуска; - только fork: 0,57; - вместе: 0,71.
Fork чуть сильнее flush, но по отдельности они не дают полного эффекта.
Рычаги управления: - K (число веток) → больше веток даёт больше шансов на прыжок в новую яму, но стоит дороже. В исследовании K=4. - Бюджет отрезка ветки → в статье ~6% от общего. Слишком короткий не успеет показать, куда ведёт подход. Слишком длинный съест бюджет. - Моменты форка → в статье на 33% и 66% бюджета, жёстко по расписанию. Авторы специально отказались от «форкаем, когда застрял»: такое определение ненадёжно. - Что хранить в папке → журнал NOTES.md в моём шаблоне нужен, чтобы свежий агент не повторял уже провалившиеся идеи. В статье отдельно не проверялось.
Шаблон промпта
В статье нет готового текста промпта: все условия использовали один и тот же промпт задачи и короткий промпт продолжения. Ниже шаблон под обычный чат с агентом. Структура метода сохранена: чистый чат, общие файлы, фиксированный бюджет, выбор по метрике.
Промпт для каждой ветки (новый чат, копия папки):
Ты продолжаешь работу над задачей: {задача}.
Истории предыдущих чатов у тебя нет — только файлы в рабочей папке.
Файлы:
- {главный_файл} — текущая лучшая версия
- {журнал} — что пробовали и с каким результатом
- {команда_оценки} — запускает проверку и выводит скор
Текущий лучший скор: {скор}.
Цель: {максимизировать/минимизировать} {метрика}.
Обязательное условие: {проверка_корректности}.
Правила:
1. Прочитай журнал и главный файл.
2. Не ограничивайся мелкими правками. Если видишь принципиально другой подход — попробуй его.
3. После каждого изменения запускай оценку и записывай в журнал результат.
4. Останови работу, когда израсходуешь лимит: {лимит}.
5. В конце выведи лучший скор и что его дало.
План процесса (держи у себя):
Общий бюджет: {B}
Раунд 0: {K} веток с пустой папки по ~{6% от B} → лучшая = лидер
Лидер работает один до ~33% B
Форк-1: {K} копий папки лидера, чистый чат, по ~{6% от B} → лучшая = лидер
Лидер работает один до ~66% B
Форк-2: то же самое
Финал: лидер доводит остаток
Что подставлять:
- {задача}, {метрика} — задача с автоматическим числовым скором;
- {команда_оценки} — скрипт или тест, который выдаёт число без участия человека;
- {K} — число веток, 4 по умолчанию;
- {лимит} — число прогонов оценки, часы или деньги.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Fork-and-Flush. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про метрику, команду оценки, бюджет и условия корректности. Без числовой метрики нечем выбирать победителя ветки, а без лимита ветки не будут равными по ресурсам. Она соберёт промпт ветки и расписание форков под вашу задачу и инструмент.
Ограничения
⚠️ Нужна автоматическая метрика: весь метод держится на выборе лучшей ветки по скору. Для текстов, стратегии и дизайна, где оценка субъективная, без хорошего судьи он не работает. Статья этого не проверяла.
⚠️ Дорого: при том же бюджете вы получаете более широкий поиск, а не бесплатный выигрыш. В экспериментах один запуск стоил от 60 до 1000 долларов в токенах и шёл от часов до нескольких дней.
⚠️ Не на всех задачах выигрывает: на двух из тринадцати fork-and-flush не был лучшим по среднему. В одной задаче обычный запуск был сильнее, в другой его опередил лучший из четырёх. На части задач разброс между запусками почти нулевой, там метод ничего не добавит.
⚠️ Разброс есть не везде: по гипотезе авторов, он максимален на границе возможностей модели. Слишком лёгкая задача решается одинаково, слишком сложная проваливается одинаково. Проверка гипотезы на задаче MAX-3-SAT с открытыми моделями в предоставленном тексте оборвана, итог не виден.
⚠️ Одна среда: все эксперименты шли на одном агентном инструменте (GitHub Copilot CLI) и моделях одного семейства. Перенос на Claude Code и Cursor логичен, но в статье не проверен.
⚠️ Расписание не настраивали: 33%/66% и K=4 выбраны фиксированно. Оптимальные значения для вашей задачи неизвестны.
Как исследовали
Сначала команда Microsoft Research просто запустила 8 независимых агентов на одной олимпиадной задаче по оптимизации (p171). Агенты стартовали с одной точки и работали на одной модели. Итоговые скоры разошлись от 68 до 100, и добавленные вычисления разрыв не закрыли. Чтобы понять причину, авторы попросили LLM сравнивать решения тройками: «какое из двух ближе по подходу к опорному?». Из этих сравнений построили двумерную карту. На ней решения каждого запуска держались кучками, то есть теми самыми «ямами».
Затем проверили метод на 13 долгих задачах: упаковка полимино, расписания, криптоанализ, оценка источника загрязнения грунтовых вод, оптимизация ядра под VLIW-процессор, сжатие классификатора CIFAR. Прогоны шли до 107 часов. Сравнивали с двумя базовыми вариантами при одинаковом бюджете: один длинный запуск и «4 независимых запуска, берём лучший». Результат по нормализованному среднему: 0,78 против 0,47 и 0,54. Среднее fork-and-flush (0,78) даже превзошло лучшие результаты обычного запуска (0,75). Разброс между запусками в среднем тоже уменьшился.
Ablation показал, что вклад вносят обе части: flush даёт 0,55, fork даёт 0,57 (обычный запуск — 0,45), вместе выходит 0,71. Карта «ям» показала механику: на задаче полимино три ветки после форка остались в старой яме, а одна прыгнула на 43 условные единицы (обычный шаг — меньше 5) в новую область и дала лучший скор. Для практика отсюда следует: не надо ждать, пока агент «сам придумает новый подход», достаточно дать ему несколько свежих стартов из общей базы и выбрать по числу.
Адаптации и экстраполяции
🔧 Техника: только flush — дешёвая версия. Если нет денег на 4 параллельные ветки, оставьте только сброс контекста: закройте чат, откройте новый на тех же файлах и дайте промпт продолжения из шаблона. В ablation это дало 0,55 против 0,45. Это слабее полного метода, но почти бесплатно.
🔧 Техника: добавить журнал неудач → меньше повторов. В шаблоне свежий агент читает NOTES.md с историей проб. Это моё дополнение: чистый чат плюс журнал, чтобы не повторять уже проваленные идеи. Работает ли оно лучше голого flush, в статье не проверено.
Экстраполяция (не из статьи): тот же принцип для задач с числовой оценкой вне кода, например A/B-тест заголовков. Параллельные чаты генерируют варианты из общего брифа, судья или реальная метрика выбирает победителя, дальше следующий раунд идёт с чистым чатом от победителя. Всё это моя гипотеза без проверки.
Ресурсы
- Работа: Fork-and-Flush: Escaping Idea Basins in Autoresearch Agents
- Авторы: Ziyang Cai, Christos Ziakas, Vasilis Kontonis, Tim Pearce, Siddhartha Sen, Akshay Krishnamurthy, Shivam Garg, Dimitris Papailiopoulos (Microsoft Research)
- Упомянутые источники: autoresearch loop (Karpathy, 2026), Frontier-CS (Mang et al., 2026), EdgeBench (Zhu et al., 2026), best-of-N (Snell et al., 2024), Anthropic VLIW take-home