TL;DR
Maestro — схема, в которой исполнители не просто сообщают «не получилось», а возвращают диагноз: что пробовали, почему не вышло, чего не хватает, где причина — локально или в общем плане. Один координатор видит все диагнозы сразу, помнит историю попыток и выбирает реакцию: повторить с подсказкой, добавить недостающий факт, исправить ложное утверждение или выбросить целую ветку плана и перепланировать.
Главная находка: когда подзадача не поддаётся, причин может быть три. Исполнителю не хватило подсказки, сама подзадача сформулирована неверно, или ошибочен план выше. Обычные системы реагируют на любой провал одинаково: дробят застрявший кусок на ещё более мелкие. В итоге бюджет уходит на детализацию заведомо тупикового направления, а общая картина остаётся прежней. Провал приходит как голый факт, и по нему причину не различить. Никто не сопоставляет, что одни и те же три соседние задачи упали из-за одного и того же недостающего факта.
Метод даёт обратную связь о причинах провала и одного «взгляда сверху». Координатор может удалить ветку плана, а не только достраивать его. Результат: на сложной математике система решает заметно больше задач, чем обычный кодинг-агент на той же модели. Принцип переносится и на любую работу агента с объективной проверкой (тесты, компиляция).
Схема метода
ШАГ 1: Исполнители атакуют открытые подзадачи параллельно
→ успех: результат | провал: ДИАГНОЗ (что пробовал, почему не вышло,
чего не хватает, локальная проблема или проблема плана)
ШАГ 2: Долгие исполнители шлют промежуточные отчёты → координатор видит прогресс
и может перенаправить до провала
ШАГ 3: Координатор читает все отчёты + историю → выбирает реакцию:
• повтор с подсказкой / предупреждением
• добавить общий недостающий факт
• исправить ложное утверждение
• отозвать ветку плана (готовые куски сохранить)
• запустить «исследователей» искать другой план
• объявить цель ложной (только с проверенным контрпримером)
ШАГ 4: Все решения и их основания записываются → прозрачный журнал поиска
Исходная система — программа на коде с очередью событий. В чате и в агентных инструментах повторяется логика ролей и формат отчётов.
Пример применения
Сильная зона метода: сложная задача из многих частей, где есть объективная проверка (тесты, компиляция, сверка с контрактом). Слабая зона: субъективные критерии вроде «красиво» или «убедительно».
Задача: Вы ведёте разработку с Claude Code. Нужно перевести интернет-магазин на новую версию API ЮKassa. Затронуто 14 модулей: платежи, возвраты, чеки по 54-ФЗ, вебхуки. Субагенты берутся за модули и регулярно упираются в тупик. Обычная реакция «разбей на подзадачи ещё мельче» уже дала 40 мелких задач, а тесты по возвратам всё равно красные.
Промпт (системная инструкция основному агенту):
Ты — КООРДИНАТОР миграции платёжной интеграции ЮKassa (API v3 → новая версия).
Ты не пишешь код сам. Ты раздаёшь модули субагентам и принимаешь решения по их отчётам.
Каждый субагент при ПРОВАЛЕ возвращает не «не вышло», а:
1. Что пробовал (список подходов) и почему каждый не сработал.
2. Каких фактов/функций/данных не хватило, чтобы закрыть задачу.
3. Где причина: ЛОКАЛЬНО (мелкая недостача) или В ПЛАНЕ (подход упирается в барьер).
4. Если считает, что тест или требование неверны — воспроизводимый пример (запрос/ответ/лог).
После каждого отчёта сравни его со ВСЕМИ предыдущими и ищи паттерны:
- Несколько модулей упали из-за одного недостающего факта → добавь его один раз как общий модуль.
- Один и тот же «самый сложный кусок» возникает после каждого дробления → проблема выше. Не дроби дальше, пересмотри план.
- Подзадача упирается в барьер при разумном подходе → сначала повтори с подсказкой от соседнего решённого модуля. Дроби только если повтор не помог.
- Подозрение, что тест или требование неверны → запроси воспроизводимое подтверждение. Без него это не считается.
Если ветка плана оказалась ошибочной — ОТОЗВИ её целиком, но сохрани уже зелёные модули.
Если идей нет — запусти исследователя БЕЗ твоей подсказки, чтобы не сузить поиск.
После каждого решения записывай: что решил, на основании каких отчётов, что отозвано, что сохранено.
Критерий завершения: все тесты зелёные и контракты API соблюдены.
Результат: Координатор будет вести журнал решений: «модули возвратов и чеков упали из-за одного недостающего поля, добавляю общий хелпер», «ветка X отозвана, зелёные модули сохранены». Субагенты возвращают структурированные диагнозы, а не «ошибка». Вместо бесконечного дробления вы увидите смену плана, когда диагнозы указывают на проблему выше.
Почему это работает
Слабость: провал сам по себе почти ничего не сообщает. «Задача не решена» одинаково выглядит и при нехватке подсказки, и при неверной формулировке, и при тупиковом плане. Реагируя на всё одним правилом («раздроби»), система закрепляет ошибку и тратит бюджет.
Сильная сторона LLM: модель хорошо объясняет, что пробовала и где упёрлась, если её об этом попросить. Она также умеет находить закономерности в нескольких текстовых отчётах («три ветки упали по одной причине»). Нужно лишь собрать эти отчёты в одном месте.
Как метод это использует: формат диагноза превращает провал в данные. Единый координатор с историей сопоставляет эти данные и решает на нужном уровне: подсказка исполнителю, правка факта или смена плана. Дополнительное преимущество: проверяемое заявление «цель ложна» принимается только с доказательством, поэтому система не бросает решаемую задачу из-за слабого прогона.
Рычаги управления: - Поля диагноза → добавь «что мешало больше всего» или «что бы ты сделал при бюджете ×2». Отчёты станут богаче. - Правила координатора → замени паттерны под свою область. В разработке это «один и тот же тест падает у разных модулей», в аналитике — «две гипотезы упираются в одни и те же отсутствующие данные». - Исследователь без подсказки → не давай ему свою догадку, иначе он будет искать только в её направлении. - Порог дробления → «не дроби после одного провала», чтобы не раздувать план зря.
Шаблон промпта
Полные промпты Maestro лежат в Приложении E статьи, в предоставленном фрагменте их нет. Ниже шаблон, реконструированный по описанию ролей и логики координатора и исполнителей. Он сохраняет структуру: отчёт-диагноз, паттерны, виды реакций, журнал.
Ты — КООРДИНАТОР задачи: {общая_цель}.
Ты не выполняешь подзадачи сам. Ты раздаёшь их исполнителям и решаешь, что делать дальше, по их отчётам.
Единый список подзадач и план: {где_лежит_план}.
Статус каждой: открыта / решена / отозвана. Решённые подзадачи — факты, их не пересматривай без причины.
Исполнитель при успехе возвращает результат.
При провале возвращает ДИАГНОЗ:
1. Подходы, которые пробовал, и почему каждый не сработал.
2. Чего не хватает, чтобы закрыть подзадачу (факт, данные, доступ).
3. Причина: ЛОКАЛЬНАЯ или В ПЛАНЕ (подход упирается в барьер).
4. Если считает, что подзадача или требование ошибочны — проверяемое подтверждение: {формат_подтверждения}.
Если работает долго — присылает промежуточный отчёт: что сделано, что осталось, застрял ли.
На каждый отчёт:
1. Сопоставь с ВСЕМИ прошлыми отчётами и ищи паттерны:
- несколько подзадач упали из-за одного недостающего факта → добавь его ОДИН раз как общий
- дробление одной подзадачи дважды вернуло тот же трудный кусок → проблема выше, пересмотри план
- исполнитель ушёл на неперспективный путь или повторяет уже сделанное → перенаправь
2. Выбери реакцию из списка (или другую, если нужно):
a) повтор с подсказкой или предупреждением о прошлой ошибке
b) повтор с большим бюджетом, если подход выглядит верным
c) разбиение на подзадачи — только если повтор не помог
d) добавить общий факт
e) исправить ложное утверждение
f) ОТОЗВАТЬ ветку плана целиком, сохранив решённое
g) запустить исследователя для поиска другого плана (без твоих подсказок)
3. Заявление «это невозможно / ложно» принимай только с проверяемым подтверждением. Без него считай не подтверждённым и продолжай работу.
Для каждого решения записывай: решение, отчёты-основания, что отозвано, что сохранено.
Завершай, когда {критерий_готовности}. Если цель оказалась неверной, верни подтверждённое опровержение.
Что подставлять: {общая_цель} — что строите или решаете. {где_лежит_план} — файл или раздел чата. {формат_подтверждения} — воспроизводимый пример: лог, тест, контрпример. {критерий_готовности} — объективная проверка: тесты зелёные, сверка с контрактом.
🚀 Быстрый старт — вставь в чат:
Вот шаблон координатора по схеме Maestro. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, чем проверяется готовность (тесты, контракт, чек-лист), на какие части делится задача и что считается подтверждением, что требование ошибочно. Эти вопросы нужны, потому что координатор принимает решения по объективным основаниям, и без них он не отличит «не получилось» от «невозможно».
Ограничения
⚠️ Нужна объективная проверка: метод построен на том, что Lean однозначно говорит «доказано» или «не доказано». Там, где критерий успеха субъективен (стиль, убедительность, креатив), координатору не на что опереться, и решения будут догадками.
⚠️ Инженерная часть оригинала: исходная система — программа с очередью событий, параллельными сессиями и общим рабочим пространством, без раундов и таймаутов. В чате вы получите только логику ролей и формат отчётов. Параллельность и автоматический запуск воркеров потребуют агентного инструмента с субагентами или автоматизации.
⚠️ Нишевый домен исследования: проверено на формальных доказательствах и верифицированном коде (Lean). Перенос на обычную разработку и аналитику — разумная экстраполяция, но авторы его не тестировали.
⚠️ Цена: постоянный координатор и параллельные исполнители с длинным контекстом расходуют много токенов. Для простых задач это избыточно.
⚠️ Один прогон на задачу: результаты получены в одном запуске на задачу, без усреднения.
⚠️ Не все ключевые элементы изолированно проверены: в доступной части видно сравнение всей системы с обычным агентом. Вклад отдельных элементов (диагнозы, отзыв веток, плановый судья) по этому фрагменту оценить нельзя.
Как исследовали
Идея была простой: взять тот же набор моделей и сравнить, что они решают как обычный кодинг-агент (Claude Code или Codex с доступом к Lean) и что они решают внутри Maestro. Тестировали четыре современные модели на десяти бенчмарках: семь по математике (олимпиады IMO 2026, PutnamBench, Lean-IMO-Bench, свежие теоремы из статей arXiv) и три по верификации ПО. Веб-доступ отключили, чтобы решение не могло быть просто скопировано из литературы.
Результат: Maestro превосходит обычного агента на всех бенчмарках, которые тот ещё не решил полностью, и разрыв растёт с ростом сложности. На исследовательских теоремах arXivLean (июнь 2026) с Claude Opus 5 система доказала 34 из 48 против 19 у нативного агента. На PutnamBench получилось 669 из 672 против 597 у лучшей опубликованной системы, на Lean-IMO-Bench 59 из 60 против 42 у LEAP.
Что здесь поучительно: выигрыш растёт именно там, где нужна смена направления, а не дополнительное дробление. Простые бенчмарки обычный агент уже решает, и разницы нет. Для практики вывод такой: диагноз причины провала плюс решение «сверху» ценнее, чем больше попыток на том же плане. Отдельно авторы показывают, что отзыв уже доказанных лемм в одном из кейсов решил исход. Системы, которые только наращивают план, на такое неспособны.
Адаптации и экстраполяции
🔧 Техника: добавить «судью плана» → отсеивать декомпозиции, которые просто перекладывают проблему
В Maestro есть судья, который проверяет план разбиения. Главный вопрос: действительно ли план делит сложность? Если рядом с рутинными боковыми подзадачами стоит один потомок, такой же трудный, как родитель, план отклоняют. Добавь в промпт координатора:
Прежде чем принять план разбиения, проверь: делит ли он реальную сложность?
Если среди подзадач остаётся одна, такая же трудная, как исходная, а остальные рутинные —
отклони план и сообщи, что препятствие выше этой задачи.
🔧 Техника: исследователь без подсказки → не сужать поиск
Когда у тебя нет своей версии, запускай исследователя только с общим планом, без «я подозреваю, что причина в X». Иначе он будет искать вокруг твоей догадки.
Экстраполяция (аналитика, не из статьи): тот же паттерн можно применить к аналитической работе, где есть проверяемые критерии (сходимость цифр, сверка с источником). Агенты-аналитики при тупике возвращают диагноз: «гипотеза X не подтвердилась, потому что нет данных по региону Y, проблема локальная». Координатор видит, что три гипотезы упираются в одни и те же отсутствующие данные, и запрашивает их один раз вместо трёх попыток обойти.
Ресурсы
- Работа: Maestro: Agentic Formal Proof Development by Coordination (Preprint)
- Авторы: Haoyu Li (University of Illinois Urbana-Champaign), Zeren Shui, Yuhao Zhang, Ferhat Erata, Murali Krishna Ramanathan, Hao Zhou (AWS AI Labs), Benjamin Mikek (Georgia Institute of Technology)
- Упомянутые системы: Hilbert, LEAP, Goedel-Architect (рекурсивные доказыватели), Claude Code, Codex
- Бенчмарки: PutnamBench, Lean-IMO-Bench, arXivLean, FormalQualBench, FATE-X, NTP4VC, Verina, AlgoVeri
- Полные промпты воркеров и координатора — в Приложении E статьи (в предоставленном фрагменте их нет); система заявлена как open source