TL;DR
DynaDebate — метод многоагентной дискуссии, который даёт каждому агенту свой путь решения задачи. Вместо неуправляемого "пусть все подумают и обсудят", система работает в три этапа: (1) агент-генератор создаёт несколько логически разных подходов к задаче (например, "через уравнения", "через геометрию", "через перебор"), (2) каждый агент получает свой подход и решает задачу по нему, (3) агенты обсуждают не финальные ответы, а конкретные шаги в рассуждениях друг друга.
Обычные многоагентные дискуссии вырождаются в groupthink — все агенты думают одинаково и делают одинаковые ошибки. Когда запускаешь "три агента обсудите задачу", они часто выбирают один и тот же путь решения (например, все пытаются "дополнить квадрат"), делают одну и ту же ошибку на втором шаге, и дискуссия превращается в голосование 3:0 за неправильный ответ. Это происходит потому что модель обучена на одних и тех же данных — у неё есть ментальные паттерны, которые срабатывают у всех агентов одинаково. Критика тоже не работает: агенты оценивают "звучит ли ответ убедительно", а не "правильная ли логика на каждом шаге". Из-за этого даже правильный ответ одного агента тонет под давлением группы с красиво оформленной, но неверной логикой.
DynaDebate решает это через принудительную диверсификацию на старте (агент-генератор создаёт 2-3 разных подхода и распределяет их между агентами), пошаговую критику вместо оценки финала (агенты проверяют каждый шаг рассуждений на ошибки в расчётах и логике), и объективную верификацию при разногласиях (включается агент с внешними инструментами — код или поиск — который даёт фактическую проверку).
Схема метода
ЭТАП 1: Генерация путей решения
Агент-генератор → анализирует задачу → создаёт 2-3 логически разных подхода
→ распределяет подходы между агентами
ЭТАП 2: Решение + пошаговая дискуссия (2 раунда)
Раунд 1: Каждый агент решает по своему пути → детализирует каждый шаг
Раунд 2: Агенты читают чужие решения → критикуют конкретные шаги
("на шаге 3 ошибка в расчёте", "переход от шага 2 к 3 нелогичен")
ЭТАП 3: Верификация (если нет консенсуса)
Агент-верификатор → пишет код / делает поиск → даёт объективный результат
→ агенты используют его как референс
Все этапы могут выполняться в одном чате через структурированный промпт, либо через несколько последовательных запросов.
Пример применения
Задача: Оценить жизнеспособность идеи SaaS-сервиса для российского рынка — платформы автоматизации email-рассылок для малого бизнеса (конкурент Unisender/SendPulse). Нужно понять: стоит ли вкладывать 2 млн рублей в MVP.
Промпт:
Задача: оценить жизнеспособность SaaS-идеи (платформа email-рассылок для малого бизнеса, российский рынок, бюджет MVP 2 млн руб).
ШАГ 1 — ГЕНЕРАЦИЯ ПОДХОДОВ
Ты — Агент-Генератор. Предложи 3 логически разных подхода к оценке этой идеи:
- Подход 1: [один метод анализа]
- Подход 2: [другой метод анализа]
- Подход 3: [третий метод анализа]
Требования: подходы должны быть логически обоснованы и независимы друг от друга.
ШАГ 2 — РЕШЕНИЕ ПО ПУТЯМ
Создай трёх агентов. Каждый берёт один подход и оценивает идею по нему.
Детализируй каждый шаг: "Шаг 1: [действие] → [вывод]. Шаг 2: [действие] → [вывод]."
ШАГ 3 — ПОШАГОВАЯ КРИТИКА
Каждый агент читает рассуждения двух других.
Критикуй НЕ финальные выводы, а КОНКРЕТНЫЕ ШАГИ:
- "На шаге X агент Y использовал данные [источник] — они устарели/неточны"
- "Переход от шага 2 к шагу 3 содержит логический пробел: [объяснение]"
ШАГ 4 — ВЕРИФИКАЦИЯ (если нет консенсуса)
Если агенты расходятся — используй Code Interpreter для расчётов или поиск для проверки фактов.
Финал: консенсусный вывод с обоснованием.
Результат:
Модель выполнит сначала генерацию подходов (например: "финансовая модель Unit Economics", "анализ конкурентов через данные SimilarWeb", "опрос целевой аудитории через гипотезы"). Потом три агента дадут оценки по своим путям с детализацией шагов. В раунде критики они укажут на конкретные слабые места в расчётах или логике друг друга. Если выводы разойдутся (один говорит "запускать", другой "не стоит"), верификатор посчитает Unit Economics в коде или найдёт актуальные данные по конкурентам. Финальный вывод будет опираться на объективные расчёты, а не на "кто убедительнее звучит".
Почему это работает
Слабость LLM: Модель обучена на одних и тех же данных, поэтому у неё есть доминирующие паттерны мышления. Когда запускаешь несколько агентов без явных инструкций, они часто выбирают один и тот же путь решения — самый частотный в обучающих данных. Если этот путь содержит ошибку на третьем шаге, все агенты сделают эту ошибку, и дискуссия не поможет. Более того, агенты оценивают чужие ответы поверхностно — "звучит ли убедительно", "хорошо ли структурирован текст" — вместо проверки каждого шага на точность. Из-за этого правильный, но менее красиво оформленный ответ проигрывает неправильному, но убедительно звучащему.
Сильная сторона LLM: Модель хорошо следует явным структурированным инструкциям. Если дать конкретное задание "реши через метод X", она выполнит именно его, даже если это не самый частотный паттерн. Также модель способна к детальной аналитике текста — если попросить "проверь шаг 3 на ошибки в расчётах", она это сделает точнее, чем при запросе "оцени правильность ответа".
Как метод использует это: DynaDebate принудительно назначает разные пути решения через агента-генератора, который сначала создаёт несколько подходов, а потом распределяет их. Это обходит доминирующий паттерн и заставляет агентов исследовать разные части пространства решений. Пошаговая критика обходит поверхностную оценку — агенты проверяют каждый шаг на ошибки в фактах и логике, а не оценивают "общее впечатление". Верификация через внешние инструменты даёт объективный якорь, который не зависит от убедительности формулировок.
Рычаги управления:
- Количество путей решения (2-3-4) — для простых задач достаточно 2, для сложных лучше 3. Больше 4 создаёт шум.
- Количество раундов дискуссии — для сложных задач (математика, стратегия) оптимально 2 раунда. Больше снижает качество из-за раздувания контекста.
- Критерий активации верификатора — можно активировать всегда, или только при отсутствии консенсуса, или при расхождении больше чем на X%.
- Тип внешнего инструмента — код (Code Interpreter) для расчётов, поиск для фактов, API для специфичных данных.
Шаблон промпта
Задача: {описание задачи}
ЭТАП 1 — ГЕНЕРАЦИЯ ПОДХОДОВ К РЕШЕНИЮ
Ты — Агент-Генератор.
Проанализируй задачу и предложи {N} логически разных подходов к её решению.
Каждый подход должен быть:
- Логически обоснован и применим к этой задаче
- Независим от других (использует другой метод/источник данных/логическую цепочку)
Формат:
Подход 1: [название метода] — [краткое описание]
Подход 2: [название метода] — [краткое описание]
Подход {N}: [название метода] — [краткое описание]
ЭТАП 2 — РЕШЕНИЕ ПО НАЗНАЧЕННЫМ ПУТЯМ
Создай {N} агентов. Каждому назначь один подход из списка выше.
Каждый агент решает задачу строго по своему подходу.
Требование: детализируй рассуждения пошагово.
Формат:
Агент 1 (Подход: [название]):
Шаг 1: [действие] → [результат/вывод]
Шаг 2: [действие] → [результат/вывод]
...
Финальный ответ: [ответ]
ЭТАП 3 — ПОШАГОВАЯ КРИТИКА
Каждый агент читает решения других агентов.
Критикуй НЕ финальные ответы, а КОНКРЕТНЫЕ ШАГИ в рассуждениях:
- Найди ошибки в расчётах или фактах на конкретном шаге
- Найди логические пробелы в переходах между шагами
- Укажи номер шага и опиши проблему
Формат критики:
Агент X критикует Агента Y:
- Шаг {номер}: [описание ошибки или пробела в логике]
- Шаг {номер}: [описание ошибки или пробела в логике]
После критики каждый агент корректирует своё решение (если нашли ошибки).
ЭТАП 4 — ВЕРИФИКАЦИЯ (при отсутствии консенсуса)
Если агенты не пришли к согласию после критики:
Активируй Агента-Верификатора.
- Для расчётных задач: используй {инструмент_1, например Code Interpreter} для объективной проверки
- Для фактических задач: используй {инструмент_2, например поиск} для проверки данных
Результат верификации используется как референс для финального вывода.
ФИНАЛ
Консенсусный ответ с обоснованием: почему именно этот ответ, какие ключевые аргументы из дискуссии его подтверждают.
Что подставлять:
- {описание задачи} — твоя конкретная задача (математическая, аналитическая, стратегическая)
- {N} — количество подходов/агентов (оптимально 2-3)
- {инструмент_1}, {инструмент_2} — какие инструменты использовать для проверки (Code Interpreter, поиск, специфичные API)
🚀 Быстрый старт — вставь в чат:
Вот шаблон DynaDebate для многоагентной дискуссии. Адаптируй под мою задачу: [твоя задача].
Задавай уточняющие вопросы, чтобы правильно заполнить поля.
[вставить шаблон выше]
LLM спросит: сколько агентов создать, какие инструменты доступны для верификации (Code Interpreter? поиск?), нужно ли упростить для быстрого результата. Она возьмёт структуру из шаблона (генерация подходов → решение по путям → пошаговая критика → верификация) и адаптирует под твою задачу с конкретными подходами.
Ограничения
⚠️ Не для простых задач: На элементарных вопросах ("столица Франции", "2+2") весь механизм избыточен — простой промпт даст тот же результат быстрее. Метод эффективен для задач, где существует несколько логически разных путей решения.
⚠️ Эффект насыщения: Больше 3 агентов часто ухудшает результат вместо улучшения — появляется coordination overhead. В экспериментах 4 агента показывали хуже, чем 3.
⚠️ Длинный контекст: Больше 2 раундов дискуссии снижает точность на сложных задачах — контекст раздувается, модель теряет фокус. Оптимум — 2 раунда.
⚠️ Требует workflow: Нельзя просто скопировать один промпт и получить результат. Нужно либо структурировать в одном большом промпте, либо делать несколько запросов, либо настроить кастомный GPT/проект в Claude.
⚠️ Верификация не универсальна: Для субъективных задач (креатив, стиль, эмоции) внешняя верификация не работает — там нет объективной правды. Метод лучше подходит для задач с проверяемыми фактами или расчётами.
Как исследовали
Тестировали на GPT-4o-mini и Qwen3-8B (open-source модель). Конфигурация: 3 агента, 2 раунда дискуссии.
Датасеты: - Математика: GSM8K (базовая, 93-96% accuracy), MATH500 (70-84%), AIME 2024/2025 (олимпиады, 10-37%) - Широкие знания: MMLU (82-83%) - Фактическая точность: Biography (проверка биографий на галлюцинации)
Главные находки:
Диверсификация работает: Метрика "intra-diversity" (насколько семантически различаются ответы агентов) и "structural non-overlap" (насколько различаются структуры рассуждений) выросли для DynaDebate vs базовые методы. При этом точность не упала — значит, диверсификация не превратилась в шум.
Больше агентов ≠ лучше: Переход с 2 на 3 агента даёт скачок качества (например, AIME 2025: с 26.67% до 36.67%). Но 4 агента уже хуже 3 (падение до 23.33%) — появляется coordination noise.
Абляция компонентов: - Убрали генерацию путей → на AIME 2025 точность с 36.67% до 16.67% (агенты не находят входные точки в сложную задачу) - Убрали пошаговую критику → на MATH500 с 83.80% до 79.40% (ошибки в промежуточных шагах не ловятся) - Убрали верификацию → на MMLU с 83.00% до 80.00% (groupthink эффект не преодолевается)
Против кого мерились: CoT (стандартный промпт), CoT-SC (голосование), Self-Refine (итеративная коррекция), MAD (многоагентная дискуссия с ролями), SoM (Society of Mind), DMAD (дискуссия с разными стратегиями промптинга).
Где победили: На сложных математических и знаниевых задачах (MATH500, MMLU, AIME) DynaDebate лучше всех. На простых (GSM8K) все топовые методы почти одинаковы (насыщение). На Biography (фактическая точность) лучше Self-Refine, потому что он заточен под итеративную полировку текста.
Интересный вывод: Qwen3-8B с DynaDebate обогнал Self-Refine и MAD на сложных задачах, хотя это меньшая модель. Это показывает, что правильная организация процесса рассуждений может компенсировать размер модели.
Оригинал из исследования
Авторы использовали псевдокод-подобную нотацию для описания компонентов. Вот упрощённая структура (детальный псевдокод в Appendix A оригинала):
# ЭТАП 1: Dynamic Path Generation
P = PathGenerationAgent(query q)
→ возвращает список {path_1, path_2, ..., path_K}
→ требования: логическая обоснованность, взаимная независимость
Распределение путей по агентам (Round-Robin):
Agent_i получает path_((i-1 mod K) + 1)
# ЭТАП 2: Path-Guided Execution + Process-Centric Debate
Round 1:
Каждый Agent_i генерирует reasoning chain R_i,1 = {z_i[1], z_i[2], ..., z_i[L]}
где z_i[k] — атомарный шаг вывода
R_i,1 ~ π(· | q, Path(Agent_i))
Round t > 1:
Agent_i читает {R_j,t-1} для всех j ≠ i
Выполняет First-Principles Audit:
- Проверяет каждый шаг z_j[k] на intrinsic correctness (ошибки в расчётах/фактах)
- Проверяет переходы z_j[k] → z_j[k+1] на logical coherence
Генерирует обновлённое решение R_i,t на основе критики
# ЭТАП 3: Trigger-Based Verification
if Trigger(H_t): # например, консенсус не достигнут
o_t ← VerificationAgent(q, H_t)
→ генерирует команду для внешнего инструмента (Python code / Search)
→ выполняет в изолированной среде
H_t ← H_t ∪ {o_t} # добавляет результат в историю дискуссии
Агенты используют o_t как референс для следующего раунда
Ключевое отличие от других MAD-методов: - MAD (Liang et al., 2023): агенты с разными ролями (пессимист/оптимист), но без управления путями решения - SoM (Du et al., 2023): модульная структура, но агенты не критикуют шаги друг друга - DMAD (Liu et al., 2025): разные стратегии промптинга (Chain-of-Thought, Program-of-Thought), но без верификации и без пошаговой критики
Ресурсы
Работа: DynaDebate: Breaking Homogeneity in Multi-Agent Debate with Dynamic Path Generation
Авторы: Zhenghao Li, Zhi Zheng, Wei Chen (University of Science and Technology of China, State Key Laboratory of Cognitive Intelligence), Jielun Zhao (North Automatic Control Technology Institute + Shenzhen Institute for Advanced Study, UESTC), Yong Chen, Tong Xu, Enhong Chen
Важные отсылки: - MAD (Liang et al., 2023) — базовый метод многоагентной дискуссии - SoM / Society of Mind (Du et al., 2023) — модульная архитектура - DMAD (Liu et al., 2025) — дискуссия с разными стратегиями промптинга - VerifiAgent (Han et al., 2025) — идея trigger-based verification - Tree of Thoughts (Yao et al., 2023), Graph of Thoughts (Besta et al., 2024) — многопутевое рассуждение - Self-Consistency (Wang et al., 2022) — голосование по множественным путям