TL;DR
Больше ролей в промпте ≠ лучший результат. Многие добавляют к запросу "ты — аналитик, ты — критик, ты — финансист" и ждут магии. Исследование проверило 6 мультиагентных систем в честных условиях — у всех одинаковые инструменты, одна модель, одни задачи. Результат: 5 из 6 проиграли одиночному агенту.
Боль конкретная: запускаешь дебаты агентов, добавляешь роли, усложняешь промпт — а результат или хуже, или такой же, но дороже в 3–4 раза по токенам. Причина — при передаче задачи между агентами контекст сжимается, часть условий теряется, и финальный ответ приходит с "дырками" в требованиях.
Но есть три рабочие зоны, где мультиагентность реально помогает. Ключ не в числе агентов, а в типе координации, который совпадает с типом ошибки задачи. Знать эту карту — значит выбирать правильную структуру и не тратить токены впустую.
Схема метода
Карта выбора структуры промпта под задачу:
ОПРЕДЕЛИ ТИП ЗАДАЧИ:
→ Есть проверяемый правильный ответ (код, математика, факт)?
СТРУКТУРА: Дебаты — несколько независимых решений + проверка
→ Нужно соблюсти список конкретных требований/инструкций?
СТРУКТУРА: Мультисудья — несколько независимых проверщиков
→ Нужен лучший из возможных вариантов (текст, идея, стратегия)?
СТРУКТУРА: Эволюция — несколько попыток с разным углом, отбор лучшей
→ Всё остальное?
СТРУКТУРА: Один хорошо настроенный агент — быстрее и точнее
ДЛЯ СЛОЖНЫХ МНОГОШАГОВЫХ ЗАДАЧ — добавь шаг:
ПОСЛЕ КАЖДОГО ЭТАПА: явно зафиксируй промежуточный результат
ПЕРЕД ФИНАЛОМ: пройди верификацию всех исходных условий
Все шаги выполняются в одном чате — разными запросами или одним структурированным промптом.
Пример применения
Задача: Ты написал оферту для B2B-клиента на интеграцию CRM. Клиент дал 7 конкретных требований: сроки, стоимость, формат оплаты, гарантии, SLA, условия расторжения, ответственность сторон. Нужно убедиться, что всё учтено.
Это задача типа "соблюсти список требований" → мультисудья.
Промпт:
Вот оферта: [текст оферты]
Вот требования клиента:
1. Срок внедрения — не более 45 дней
2. Стоимость — фиксированная, без скрытых платежей
3. Оплата — 50% предоплата, 50% после сдачи
4. Гарантия — 6 месяцев на доработки
5. SLA — ответ на критичные баги в течение 4 часов
6. Условия расторжения — возможность выхода с 14 дней уведомления
7. Ответственность — ограничена суммой договора
Проверь оферту три раза подряд как три разных проверщика:
ПРОВЕРЩИК А — юрист: ищет юридические риски и пробелы в формулировках
ПРОВЕРЩИК Б — менеджер клиента: смотрит глазами контрагента, что может не устроить
ПРОВЕРЩИК В — проектный менеджер: проверяет реализуемость каждого пункта на практике
Каждый проверщик:
- Проходит по всем 7 требованиям
- Отмечает: ✅ выполнено чётко / ⚠️ есть размытость / ❌ не отражено или противоречит
- Даёт одно главное замечание
В конце — сводный список: что исправить до отправки клиенту.
Результат: Модель пройдёт по оферте три раза с разных позиций, отметит несоответствия и противоречия, которые легко упустить с одной точки зрения. Получишь структурированный список правок с объяснением, почему каждый пункт важен. Особенно полезно, когда юрист ловит формулировки, которые менеджер принял бы как норму.
Почему это работает
LLM теряет требования при передаче. Когда в промпте три роли передают задачу друг другу, каждая "рука" пересказывает предыдущей сжатую версию. К финальному агенту доходит не всё — особенно мелкие, но критичные условия. Именно поэтому 5 из 6 мультиагентных систем в исследовании проиграли одиночному агенту: не потому что плохи, а потому что информация деградирует по цепочке.
Три рабочие зоны — три разных механизма совпадения. Дебаты работают там, где результат можно проверить объективно — несколько решений легко сравнить (код запустил / не запустил, ответ верный / нет). Мультисудья работает там, где нужно покрыть список условий — разные "глаза" замечают разные пропуски. Эволюционный перебор работает там, где нет объективного критерия, но есть разброс качества — попробовал несколько углов, выбрал лучший.
Рычаги управления:
- Число проверщиков → 2 для быстрой задачи, 3–4 для критичных документов
- Роли проверщиков → чем конкретнее (не "эксперт", а "менеджер клиента из Сбера") → острее взгляд
- Явная фиксация промежуточного результата → добавь "запиши выводы перед следующим шагом" → контекст не теряется
- Верификационный шаг в конце → "проверь, что все 7 требований отражены" → закрывает дыры финального ответа
Шаблон промпта
Шаблон — Мультисудья (для проверки соответствия требованиям):
Вот {материал для проверки}: [текст]
Вот {список требований/критериев}:
1. {требование 1}
2. {требование 2}
...N. {требование N}
Проверь {материал} как {число_судей} независимых эксперта:
СУДЬЯ 1 — {роль 1, конкретная}: {что ищет}
СУДЬЯ 2 — {роль 2, конкретная}: {что ищет}
СУДЬЯ 3 — {роль 3, конкретная}: {что ищет}
Каждый судья:
- Проходит по всем {N} требованиям
- Ставит: ✅ выполнено / ⚠️ размыто / ❌ отсутствует
- Формулирует одно главное замечание
ИТОГ: сводный список правок по приоритету.
Плейсхолдеры:
- {материал} — текст оферты, план проекта, ТЗ, статья, скрипт
- {список требований} — конкретные критерии клиента, стандарты, чеклист
- {число_судей} — 2–4, зависит от сложности задачи
- {роль 1, 2, 3} — конкретные персонажи с понятной позицией: юрист, заказчик из Газпрома, пользователь без технического бэкграунда
Шаблон — Дебаты (для верифицируемых задач: код, расчёты, факты):
Задача: {задача с проверяемым ответом}
Реши задачу тремя независимыми способами.
После каждого решения запиши промежуточный вывод.
РЕШЕНИЕ А: {подход 1 — прямой}
РЕШЕНИЕ Б: {подход 2 — альтернативный}
РЕШЕНИЕ В: {подход 3 — через проверку}
Сравни три решения.
Если все три совпадают — это финальный ответ.
Если расходятся — найди ошибку и реши ещё раз.
🚀 Быстрый старт — вставь в чат:
Вот шаблон мультисудьи для проверки документа. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит что проверяем, какие требования, какие роли судей — потому что без этого не выбрать правильные позиции для проверки. Она возьмёт паттерн и адаптирует под задачу.
Ограничения
⚠️ Деградация контекста в длинных цепочках: Чем длиннее цепочка передачи между ролями, тем выше риск потери условий. Для задач с 10+ требованиями лучше разбить на несколько отдельных проверок, чем гнать через одну длинную.
⚠️ Мультисудья не помогает при субъективных задачах: Если нет чёткого списка критериев ("напиши красиво"), разные роли дадут противоречивые мнения без возможности свести их в решение.
⚠️ Лишние роли добавляют токены, не точность: Три судьи на задачу "переведи параграф" — это перерасход без выигрыша. Метод окупается только там, где разные углы зрения реально находят разные проблемы.
⚠️ Дебаты не работают без верифицируемого критерия: Если нельзя проверить "правильно / нет", несколько решений просто дадут несколько мнений — не консенсус.
Как исследовали
Идея была простой: взяли 6 популярных мультиагентных систем — LLM-Debate, AutoGen, CAMEL, EvoAgent, Jarvis, ChatEval — и проверили их в честных условиях. Все системы работали с одной моделью (GPT-4.1), одинаковыми инструментами, одними задачами. До этого большинство сравнений были нечестными: разные модели, разные инструменты, разные форматы ответа — не удивительно, что "победители" побеждали.
Тестировали на 10 бенчмарках: математика, код, рассуждения, следование инструкциям, поиск информации. Всего — тысячи задач. Для каждой системы записывали не только правильность ответа, но и сколько токенов потратили, сколько времени заняло, что происходило внутри — какие шаги система теряла.
Любопытная находка: ChatEval справился лучше всех в задачах на следование инструкциям (IFEval), но полностью провалился на математике AIME — 3.33% против 46.67% у одиночного агента. Одна и та же система, разные задачи — диаметрально противоположные результаты. Это подтвердило гипотезу: дело не в числе агентов, а в совпадении структуры с типом задачи.
Отдельно был проведён тест системы в стиле Claude Code на сложных задачах GAIA, где нужны десятки шагов, работа с файлами, восстановление после ошибок. Там разрыв оказался огромным — плюс 42 процентных пункта на самых сложных задачах. Но исследователи честно написали: мы не знаем что именно там сработало, потому что система была "чёрным ящиком" с множеством механизмов одновременно.
Адаптации и экстраполяции
🔧 Техника: Явная фиксация состояния между шагами → предотвращение потери контекста
Один из ключевых инсайтов — сложные задачи разрушаются, когда промежуточный результат передаётся без фиксации. Контрмеры:
После каждого этапа пиши:
СОСТОЯНИЕ: [перечисли что выяснено, что решено, что ещё открыто]
ТРЕБОВАНИЯ ПОД КОНТРОЛЕМ: [пройди по исходному списку и отметь статус каждого]
Переходи к следующему шагу только после этого.
Это особенно важно для: - Многоэтапного анализа (юридический, финансовый, технический) - Переговорных сценариев с длинной историей условий - Задач типа "реши задачу в несколько этапов, не потеряй условие"
🔧 Техника: Конкретные персонажи вместо абстрактных ролей → острее критика
Вместо:
ЭКСПЕРТ 1: проверь с позиции бизнеса
Попробуй:
СУДЬЯ 1 — Михаил, директор по продажам федеральной розничной сети.
Его интересует: выполнимость обещаний, риски срыва сроков, что можно предъявить суду.
Конкретный персонаж с понятной позицией выдаёт более острую и специфичную критику, чем абстрактная роль.
Ресурсы
Do More Agents Help? Controlled and Protocol-Aligned Evaluation of LLM Agent Workflows — препринт, статус "under review"
Авторы: Yuhang Fu, Ruishan Fang, Jiaqi Shao, Huiyu Zheng, Zhengtao Zhu, Bing Luo, Tao Lin
Аффилиации: Beijing University of Posts and Telecommunications, Westlake University, Zhejiang University, Duke Kunshan University, HKUST, Zhejiang University of Technology
Ключевые отсылки из статьи: AutoGen (Wu et al., 2023), LLM-Debate (Du et al., 2023), EvoAgent (Yuan et al., 2024), CAMEL (Li et al., 2023), GAIA benchmark (Mialon et al., 2023)