TL;DR
DuoDiscover — система из нескольких кодинг-агентов (Claude Code внутри), которая оптимизирует код, когда один честный замер занимает часы. Вместо того чтобы гонять полный тест после каждой правки, агент сам выбирает небольшой кусок кода и пишет для него «линейку» (yardstick) — быстрый скрипт на секунды, который ранжирует правки. Правки агент проверяет линейкой, а полным тестом лишь подтверждает лучшие. Периодически система проверяет, не врёт ли линейка: совпадает ли её порядок правок с порядком настоящего теста.
Главная находка: узкое место — не умение агента писать код, а цена проверки. Если полный замер идёт 85 минут, обычный агент за 20 часов успевает около дюжины проверок. Он топчется на двух-четырёх местах кода и тратит почти все проверки на сомнительные правки. Вторая беда — агент, который долго работает против быстрой метрики, начинает подгонять правки под саму метрику, а не под реальную цель. Линейка перестаёт отражать реальность, а счёт растёт.
Метод решает обе проблемы тремя ходами. Первый: агент вместе выбирает цель и строит под неё быструю проверку. Второй: каждая линейка регулярно сверяется с настоящим тестом по порядку, и расходящаяся линейка выбрасывается. Третий: лёгкий координатор раз в какое-то время читает сводки агентов, останавливает застрявших, запускает новых и сообщает работающим, что нашли остальные.
Схема метода
ВНУТРИ ОДНОГО АГЕНТА
ШАГ 1: Профилирование → выбор цели (кусок кода) + оценка доли цели в общем результате (w)
ШАГ 2: Построение линейки: быстрый скрипт → (балл, флаг корректности)
БЫСТРЫЙ ЦИКЛ (секунды): правка → балл линейки → улучшилось? оставить : откатить
МЕДЛЕННЫЙ ЦИКЛ (часы): лучшая правка → настоящий тест → принять только если подтвердилось
ПРОВЕРКА ЧЕСТНОСТИ: после каждого настоящего теста сверить порядок линейки и порядка настоящих
замеров (корреляция ≥ 0,5) → валидна / сброшена (перестроить или сменить цель)
КООРДИНАТОР (раз в N минут, читает краткие сводки всех агентов)
• terminate — остановить тех, кто не движется
• spawn — запустить нового: с нуля / с лучшим подтверждённым состоянием / «склеить» подтверждённые правки нескольких агентов
• brief — коротко сообщить работающим, что нашли остальные
Оригинал — многоагентный запуск на коде. Но сам паттерн «дешёвая проверка → дорогое подтверждение → сверка» можно выразить инструкцией одному агенту (см. шаблон ниже).
Пример применения
Задача: Вы ведёте магазин на маркетплейсе. Ночной скрипт пересчёта остатков и цен на Python/pandas идёт 90 минут на полных данных. Нужно ускорить его вдвое, не сломав выгрузку. Разработчика нет, зато есть Claude Code. Если просто сказать «ускорь скрипт», агент сделает пару правок, запустит полный прогон на 90 минут и будет ждать результат.
Промпт:
Ты оптимизируешь скрипт recalc_stocks.py. Полный прогон (python run_full.py)
занимает 90 минут и проверяет корректность по контрольной сумме выгрузки.
Запускать его можно не чаще 8 раз за всю сессию.
Работай по схеме «линейка + подтверждение»:
1. Профилируй скрипт. Выбери 2–3 цели (функции или блоки). Для каждой запиши
w — грубую долю общего времени, за которую она отвечает. Если цель
даже при бесконечном ускорении не даст выигрыша больше чем 1/(1−w) —
выбирай другую.
2. Для каждой цели напиши линейку — скрипт до 1 минуты, который замеряет
только эту часть на урезанных данных (например, 5 000 строк вместо 2 млн)
и возвращает: время и флаг «результат совпал с эталоном».
3. Быстрый цикл: правка → линейка → если быстрее и корректно, оставь;
иначе откати.
4. Медленный цикл: когда накопились хорошие правки, запусти полный прогон.
Принимай правку, только если полный прогон подтвердил выигрыш и
корректность.
5. Проверка линейки: после каждого полного прогона сравни, в каком порядке
линейка и полный прогон расставляют версии кода. Если порядок не совпал
(например, линейка говорит «версия B быстрее A», а полный прогон — наоборот),
объяви линейку недействительной: перестрой её на других данных или смени цель.
6. Веди таблицу: версия | балл линейки | время полного прогона | линейка валидна?
Результат: Агент сначала покажет профиль и выберет несколько целей с оценкой доли каждой. Затем напишет быстрые скрипты замера и начнёт серию мелких правок, которые проверяет за секунды. В полный прогон уйдут только лучшие правки. В итоге вы получите таблицу версий с отметкой, где линейка совпала с реальностью, а где её пришлось перестраивать. Количество дорогих запусков будет заметно меньше, чем в обычной сессии.
Почему это работает
Слабость: агент, у которого проверка стоит 85 минут, вынужден угадывать. Он тратит запуск на правку, в успехе которой не уверен, поэтому пробует мало и топчется на одних и тех же местах. Если же дать ему быструю метрику, он начнёт оптимизировать саму метрику, а не результат: счёт растёт, реальность — нет.
Сильная сторона: модель хорошо умеет писать небольшие вспомогательные скрипты, профилировать и быстро перебирать мелкие правки. Это и есть быстрый цикл: сотни проб вместо десятков. Модель также способна сама сказать, какая часть кода «весит» больше, и оценить потолок выигрыша по закону Амдала.
Как метод связывает это: дешёвая линейка превращает угадывание в перебор, а сверка порядка с настоящим тестом ловит момент, когда перебор уходит в сторону. Важно, что линейка не обязана совпадать с настоящим замером по величине, только по порядку: «A лучше B». Для выбора, какие правки тащить в дорогой тест, этого достаточно.
Рычаги управления: - Бюджет полных запусков («не больше 8») → увеличь, если проверка дешёвая; уменьши, если дорогая. Агент начнёт строже отбирать, что отправлять. - Порог корреляции или правило «порядок совпал» → строже для критичных систем, мягче для разведки. - Число целей (2–3) → больше целей даёт шире поиск, но требует больше линеек. - Роль координатора → если запускаете несколько агентов вручную, задайте ему три действия: остановить, запустить новый, передать находки. - Правило «принимать только подтверждённое» → не снимай, это единственный страж от подгонки под линейку.
Шаблон промпта
Оригинальные промпты авторов в доступной части статьи не приведены. Шаблон ниже собран по описанной в статье механике: два цикла, линейка, проверка порядка, координатор.
Ты — инженер по оптимизации. Твоя цель: улучшить {метрика} в {проект},
не нарушив {условие_корректности}.
Полный замер: {команда_полного_замера}, занимает {время_замера}.
Лимит полных замеров на сессию: {число_замеров}.
1. Профилирование: найди {число_целей} кандидатов-целей (участки кода).
Для каждой запиши w — долю общего результата, за которую она отвечает,
и потолок выигрыша 1/(1−w).
2. Линейка для каждой цели: скрипт быстрее полного замера минимум
в {во_сколько_раз} раз. Возвращает: score и correct (да/нет).
Важен не абсолютный балл, а порядок версий.
Пока есть идеи:
правка → запусти линейку → если score лучше И correct = да: оставь,
иначе откати.
Когда накопилось {число_правок} улучшений на линейке:
запусти полный замер на лучшей версии.
Принимай правку ТОЛЬКО если полный замер подтвердил выигрыш и корректность.
После каждого полного замера сравни порядок версий по линейке и по полному замеру.
Учитывай только пары, где разница в полном замере больше шума ({уровень_шума}).
Если порядок совпадает хуже, чем в {порог_совпадения} пар,
объяви линейку недействительной: перестрой её или смени цель.
После каждого шага веди таблицу:
версия | цель | балл линейки | результат полного замера | линейка валидна?
Что подставлять: {метрика} — время, память, стоимость запроса; {условие_корректности} — тесты, контрольная сумма, сравнение выгрузки; {число_целей} — 2–3; {во_сколько_раз} — хотя бы в 10 раз; {порог_совпадения} — например, «70 % пар» (в оригинале это ранговая корреляция Кендалла ≥ 0,5; в чате проще считать долю совпавших пар).
Для нескольких агентов добавьте второй промпт — координатор:
Раз в {период} читай краткие сводки всех агентов.
Действия:
terminate — останови агента без прогресса.
spawn — запусти нового: (а) с нуля на непокрытой цели,
(б) от лучшего подтверждённого состояния,
(в) «склей» подтверждённые правки нескольких агентов,
оставив каждую, только если полный замер её подтвердил.
brief — коротко сообщи работающим, что нашли остальные.
Сам правки не делай — только координируй.
🚀 Быстрый старт — вставь в чат:
Вот шаблон «линейка + подтверждение» (DuoDiscover). Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что именно вы оптимизируете, как проверяется корректность, сколько занимает полный замер и сколько запусков вы готовы потратить — без этого нельзя задать бюджет и придумать быструю линейку. Она возьмёт структуру из шаблона и соберёт готовый промпт под вашу задачу.
Ограничения
⚠️ Нужна измеримая цель: метод работает, где есть числовая метрика и автоматическая проверка корректности (время, память, тесты). Для текстов, дизайна или «качества ответа» без чёткого замера линейку построить нечем.
⚠️ Одиночные прогоны: основные результаты получены в одном запуске, разброс между запусками авторы показывают отдельно только на части задач. Точные цифры выигрыша не стоит переносить на свой проект.
⚠️ Полная система требует инфраструктуры: координатор и несколько агентов на отдельных копиях кода, часы работы, общий бюджет замеров. В чате и в одиночной сессии Claude Code воспроизводится только паттерн, а не вся система.
⚠️ Линейка может врать: агент, которого долго гонят по быстрой метрике, подгоняет правки под неё. Пока тест на совпадение порядка не пройден, нельзя считать результат реальным. В одном из примеров линейка была валидной, потом на другой нагрузке порядок развернулся, и её пришлось перестраивать.
⚠️ Нет смысла, когда проверка дешёвая: если полный замер идёт секунды, линейка только усложняет работу.
⚠️ Выигрыш ограничен долей цели: если выбранный участок отвечает за 20 % результата, больше чем в 1,25 раза он не даст. Нужно сразу просить оценку доли.
Как исследовали
Команда Google и UC Berkeley взяла задачи, где проверка дорогая: два репозиторных бенчмарка (FormulaCode, SWE-fficiency), четыре набора GPU/TPU-ядер и реальные системы: vLLM, SQLite, zstd, движок FreeToken. Отдельно проверили задачу проектирования процессора, где один замер занимал до 28 часов. Все методы получали одинаковое время (обычно 8 часов) и четыре агента на Claude Code. Против DuoDiscover выставили чистый Claude Code, эволюционный OpenEvolve и специализированные системы. Ради честности в отчёт брали не лучший результат за сессию, а медиану нескольких перепроверок финальной версии, а версии, не прошедшие проверку корректности, считали провалом.
Результаты: на SWE-fficiency среднее ускорение 15,0× против 12,8× у Claude Code и 6,9× у экспертов-людей. На vLLM — 1,92× против 1,07×: обычные агенты вообще не улучшили две из четырёх метрик. Логика видна в статистике: на SWE-fficiency Claude Code сосредоточился на 2–4 целях и потратил около 72 дорогих проверок ради 6 подтверждённых улучшений. DuoDiscover выбрал около 9 целей, на линейках проверил 358 кандидатов, отправил в настоящий тест только 59 и получил около 12 подтверждённых улучшений. Для задачи про префетчер процессора система дала 1,65× от прироста предыдущего лучшего решения за 16,7 дня вместо 40+. Удивительно, что выигрыш дал не «умнее агент», а изменённая экономика проверок.
Адаптации и экстраполяции
🔧 Техника: упрощённая проверка вместо ранговой корреляции → применимо в чате.
Замените «корреляция Кендалла ≥ 0,5» на: «Если из каждых 5 пар версий линейка и полный замер расходятся в порядке в 2 и более, линейка недействительна». Агенту проще считать, вам проще проверять. Это упрощение, в статье используется именно ранговая корреляция.
🔧 Техника: добавить колонку «разница шума» в таблицу.
Попросите агента записывать, насколько прогон шумит (повторить один и тот же замер дважды). В оригинале пары с разницей меньше шума в проверку не берутся: нельзя требовать от линейки различать то, что не различает и настоящий тест.
Экстраполяция: тот же принцип для проверки текстов и промптов (в статье такого нет — это перенос идеи):
Я улучшаю промпт для классификации обращений в поддержку. Полная оценка —
1 500 обращений вручную размеченных, прогон дорогой.
Построй «линейку»: набор из 30 обращений, на которых быстро видно
разницу между версиями промпта. Работай так: меняй промпт → проверяй на
30 → только лучшие версии прогоняй на полных 1 500. После каждого полного
прогона сравни порядок версий на 30 и на 1 500. Если порядок разошёлся,
пересобери набор из 30 (возьми другие примеры) и сообщи мне об этом.
Здесь «линейка» — маленькая выборка, а «настоящий тест» — большая. Метод тот же, но проверено это только на коде.
Ресурсы
- DuoDiscover: Scaling Autonomous Discovery Beyond the Evaluation Bottleneck — Shubham Agarwal, Akshat Gupta, Mike Heddes и др.; Google, UC Berkeley, Stanford (Nanyun Peng, Chun-Liang Li — co-last authors). 2026.
- Сопутствующие работы из статьи: AlphaEvolve (Novikov et al., 2025), ArchAgent v2 (Gonzalez et al., 2026), PerfAgent (Deng et al., 2026), OpenEvolve (Sharma, 2025).
- Бенчмарки: SWE-fficiency, FormulaCode, SOL-ExecBench, JAXBench, TPU-Inference, DPC4 (соревнование по префетчерам).