Разделяй роли, отслеживай вклад: архитектура подотчётных многоагентных конвейеров

Трёхэтапный конвейер с фиксацией результатов на каждом шаге:

ШАГ 1 — PLANNER (Планировщик):
Получает задачу → создаёт план решения → выводит ответ
Запись: Plan = [ответ планировщика], фиксация правильности

ШАГ 2 — EXECUTOR (Исполнитель): 
Получает задачу + план → выполняет решение → выводит ответ
Запись: Execution = [ответ исполнителя], фиксация правильности
Blame tracking: repair (исправил ошибку Planner?) или harm (испортил правильный план?)

ШАГ 3 — CRITIC (Критик):
Получает задачу + план + execution → проверяет и корректирует → выводит финальный ответ
Запись: Final = [финальный ответ], фиксация правильности
Blame tracking: repair (исправил ошибку Executor?) или harm (испортил правильное выполнение?)

Финальный ответ: берётся с последнего этапа (Critic), если он есть

Ключевое отличие от простого конвейера: Явная передача контекста на каждом шаге ("вот план, проверь его", "вот выполнение плана, исправь если нужно") + фиксация промежуточных результатов для отслеживания кто где ошибся.

Задача: Ты советник крупного российского бизнесмена, который решает выходить ли ему в новую нишу — доставка готовой еды в регионах. Нужно дать чёткую рекомендацию: входить или не входить, с обоснованием.

Промпт:

Реши эту задачу как конвейер из трёх агентов с явной передачей между этапами:

ЭТАП 1 — PLANNER (Стратег):
Проанализируй вопрос: "Стоит ли российскому бизнесмену выходить в нишу доставки готовой еды в регионах?"
Создай структурированный план анализа: какие факторы учесть (спрос, конкуренция, барьеры входа, юнит-экономика).
Выведи ТОЛЬКО: "PLAN: [структурированный список факторов для анализа]"

ЭТАП 2 — EXECUTOR (Аналитик):
На основе плана выше, проведи анализ каждого фактора для российского рынка.
Выведи ТОЛЬКО: "EXECUTION: [анализ по каждому пункту плана + предварительный вывод]"

ЭТАП 3 — CRITIC (Ревизор):
Проверь анализ выше. Есть ли пропущенные риски? Обоснованы ли выводы?
Если есть ошибки — исправь. Если всё правильно — подтверди.
Выведи ТОЛЬКО: "FINAL: [итоговая рекомендация: ВХОДИТЬ или НЕ ВХОДИТЬ + ключевое обоснование в 2-3 предложениях]"

Требование: выполни все три этапа последовательно в одном ответе.

Результат:

Модель выдаст три чётко разделённых блока:

• PLAN: Список факторов для анализа (например: спрос в регионах, плотность конкуренции, логистика, регуляторные барьеры, средний чек).
• EXECUTION: Проработка каждого фактора с данными (например: "В городах 100-500к спрос растёт на 20% в год, но Яндекс.Еда уже в 80% крупных городов...").
• FINAL: Финальная рекомендация с обоснованием (например: "НЕ ВХОДИТЬ. Рынок перенасыщен в крупных городах, а в малых юнит-экономика не сходится из-за логистики. Барьер входа 50-100 млн рублей при ROI 3-4 года.").

Если план был неполным (например, не учли сезонность) — Executor может восполнить. Если Executor ошибся в выводах — Critic исправит. Структурированная передача позволяет каждому следующему агенту проверить работу предыдущего.

Слабость LLM: Когда задача сложная и многоэтапная, модель может потерять фокус, упустить важный аспект или сделать ошибку в середине рассуждения. В монолитном промпте эта ошибка тихо распространяется дальше — модель строит выводы на неправильной основе, и итоговый ответ провален. Ещё хуже, когда несколько агентов работают цепочкой без проверки: ошибка первого агента каскадом идёт до конца, и непонятно где она возникла.

Сильная сторона LLM: Модели отлично критикуют готовый текст и находят в нём ошибки, если им явно дать задачу "проверь это". Они хороши в специализированных ролях (планирование vs выполнение vs критика) — каждая роль фокусирует модель на конкретном аспекте. Модели умеют исправлять чужую работу, если им дать контекст и попросить найти проблемы.

Как метод использует силу: Разбиение на роли превращает один сложный запрос в три простых. Каждый агент делает свою часть, а следующий проверяет предыдущего. Структурированная передача ("вот план, проверь его") даёт последующим агентам явную зацепку для критики. Фиксация результатов на каждом шаге позволяет отследить где именно возникла ошибка — если финальный ответ неправильный, можно увидеть был ли план изначально плох, или Executor испортил хороший план, или Critic внёс лишнее. Это превращает конвейер из чёрного ящика в отлаживаемую систему.

Рычаги управления:

• Количество этапов: Можно добавить четвёртый этап (например, Validator) для особо сложных задач или убрать Critic для простых задач — экономия токенов.
• Явность передачи: Можно делать в одном промпте (как в примере) для скорости или в разных запросах для полного контроля и отладки.
• Роли агентов: Можно задать конкретные персонажи ("ты — осторожный инвестор", "ты — агрессивный предприниматель") вместо безликих ролей — острее выполнение и разнообразнее критика.
• Условия исправления: Можно указать Critic "исправляй только если уверен на 90%", чтобы снизить harm rate (когда критик портит правильный ответ).
• Модели по ролям: Если есть доступ к нескольким моделям, можно использовать сильную (дорогую) только для Planning, а быстрые (дешёвые) для Execution и Critique — баланс точности и цены.

Вариант 1: Все три этапа в одном промпте (быстро, просто)

Реши задачу как конвейер из трёх агентов с явной передачей между этапами:

ЭТАП 1 — PLANNER (Планировщик):
{описание роли планировщика для конкретной задачи}
Выведи ТОЛЬКО: "PLAN: [твой план]"

ЭТАП 2 — EXECUTOR (Исполнитель):
На основе плана выше: {описание роли исполнителя}
Выведи ТОЛЬКО: "EXECUTION: [твоё выполнение]"

ЭТАП 3 — CRITIC (Критик):
Проверь выполнение выше: {описание роли критика}
Если есть ошибки — исправь. Если всё правильно — подтверди.
Выведи ТОЛЬКО: "FINAL: [финальный результат]"

Задача: {твоя задача}

Требование: выполни все три этапа последовательно в одном ответе.

Пояснение к плейсхолдерам:

• {описание роли планировщика} — что должен сделать планировщик (например: "создай структуру документа", "определи ключевые факторы анализа")
• {описание роли исполнителя} — что должен сделать исполнитель (например: "заполни каждую секцию", "проведи анализ по каждому фактору")
• {описание роли критика} — что должен проверить критик (например: "проверь логику и полноту", "найди ошибки в расчётах")
• {твоя задача} — конкретная задача для решения

Вариант 2: Три отдельных запроса (полный контроль, отладка)

Запрос 1 (в отдельном чате или первым в цепочке):
Ты — {роль планировщика}. 
Задача: {твоя задача}
Создай {что планировщик должен создать}.
Выведи только результат без объяснений.

---

Запрос 2 (копируешь результат из Запроса 1):
Ты — {роль исполнителя}.
Задача: {твоя задача}
Вот план: {результат от Planner}
На основе этого плана: {что исполнитель должен сделать}.
Выведи только результат.

---

Запрос 3 (копируешь результат из Запроса 2):
Ты — {роль критика}.
Задача: {твоя задача}
Вот выполнение: {результат от Executor}
Проверь его на {критерии проверки}.
Если есть ошибки — исправь и объясни что исправил.
Если всё правильно — подтверди и выведи финальный результат.

🚀 Быстрый старт — вставь в чат:

Вот шаблон Role-based pipeline с blame tracking. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить роли агентов (что должен делать Planner, Executor, Critic).

[вставить Вариант 1 или Вариант 2 выше]

LLM спросит что должен делать каждый агент в твоём контексте — потому что роли зависят от задачи (для написания текста это "структура → наполнение → редактура", для анализа это "факторы → оценка → вывод"). Она возьмёт паттерн из шаблона и адаптирует под задачу.

⚠️ Overhead: Три последовательных шага — это 3-10x больше токенов и времени чем один запрос. Для простых задач ("столица Франции") это избыточно и дорого.

⚠️ Критик может навредить: В исследовании зафиксированы случаи harm — когда Критик портит правильный ответ Исполнителя (harm rate до 1.9% у некоторых моделей). Строгий критик не всегда прав. Решение: можно дать инструкцию "исправляй только если уверен" или "объясни почему считаешь это ошибкой".

⚠️ Не для всех задач: Метод эффективен для многоэтапных задач с чёткой структурой (анализ, написание документа, решение задачи с подзадачами). Для творческих задач без правильного ответа (придумать название бренда, написать стихотворение) разделение на роли может убить спонтанность.

⚠️ Требует дисциплины: В варианте с тремя отдельными запросами нужно вручную копировать результаты между чатами. Ошибка в копировании = сломанная цепочка. В варианте с одним промптом проще, но меньше контроля.

Команда взяла три топовые модели (GPT-4o, Claude Sonnet 4, Gemini 2.5 Pro) и прогнала их через три бенчмарка: PythonIO (задачи на код и алгоритмы), LogiQA (формальная логика), AGIEval (задачи уровня экзаменов типа ЕГЭ или SAT). Всего протестировали 673 задачи в формате multiple choice.

Сравнивали три режима:

1. Монолитная модель — одна модель решает задачу от начала до конца.
2. Простой конвейер — три агента передают друг другу результат без структуры ("вот задача" → "вот моя попытка" → "вот моя попытка").
3. Подотчётный конвейер — три агента с явной передачей и фиксацией результата на каждом шаге.

Для каждой конфигурации (AAA, BBB, CCC, ABC, CBA и т.д. — всего 8 комбинаций моделей) измеряли:

• Точность финального ответа
• Стоимость (в долларах за все токены)
• Latency (время ответа в секундах)
• Blame attribution: на каждой задаче отслеживали правильный ли ответ на каждом этапе, кто внёс ошибку, кто исправил (repair), кто испортил (harm).

Самое интересное — роль планировщика критична. Gemini как планировщик ошибается в 7.35% случаев на AgiEval, Claude в 13.43%, GPT-4o в 40.49%. Это огромная разница! Планировщик задаёт основу — если план плох, дальше всё сыпется. А вот в роли исполнителя Claude — король исправления: repair rate 10.01% (исправляет каждую десятую ошибку планировщика), в то время как Gemini только 1.27%.

Почему результаты получились именно такими? Структурированная передача между агентами заставляет каждый следующий этап явно проверить предыдущий. В простом конвейере агенты просто продолжают работу, не критикуя. В подотчётном — явная инструкция "проверь это" включает механизм критики. На PythonIO это дало взрывной рост: конфигурация BBB подскочила с 61% до 97% точности — Claude научился исправлять свои же ошибки, когда структура конвейера это разрешила.

Что удивило: Гетерогенные конвейеры (разные модели в разных ролях) часто лучше гомогенных (одна модель во всех трёх ролях). CBA (Gemini → Claude → GPT-4o) на LogiQA точнее чем CCC, но дешевле. Это означает что специализация работает — не обязательно везде ставить самую сильную модель, можно оптимизировать под роль.

Инсайт для практики: Если у тебя есть доступ к нескольким моделям (ChatGPT + Claude), можешь использовать сильную модель только для планирования (самый критичный этап), а более дешёвую для выполнения и критики. Это даст баланс точности и цены. Если только одна модель — используй роль критика с осторожностью: иногда он исправляет, иногда портит.

Исследователи использовали формализованный алгоритм blame attribution (Algorithm 1 в статье):

For each task:
 1. Planner generates answer P
 2. Executor receives (task, P) → generates answer E
 3. Critic receives (task, P, E) → generates answer C
 
 Final answer selection:
 - If C exists → Final = C
 - Else if E exists → Final = E 
 - Else → Final = P
 
 Blame tracking:
 - planner_error: P ≠ ground_truth
 - executor_repair: (P ≠ ground_truth) AND (E = ground_truth)
 - executor_harm: (P = ground_truth) AND (E ≠ ground_truth)
 - critic_repair: (E ≠ ground_truth) AND (C = ground_truth)
 - critic_harm: (E = ground_truth) AND (C ≠ ground_truth)
 
 Error origin:
 - If Final = ground_truth → origin = NONE
 - Else if (E = ground_truth) AND (C ≠ ground_truth) → origin = CRITIC
 - Else if (P = ground_truth) AND (E ≠ ground_truth) → origin = EXECUTOR
 - Else → origin = PLANNER

Контекст: Это формальная логика отслеживания вклада каждого агента. На каждом этапе сравнивается ответ с ground truth (правильным ответом из бенчмарка), и отмечается исправил ли агент ошибку предыдущего (repair) или испортил правильный ответ (harm). Это позволяет построить полную картину где возникла ошибка и как она распространялась по конвейеру.

💡 Адаптация для письма: Используй метод для написания длинных текстов (статья, пост, документ).

ЭТАП 1 — PLANNER (Структуратор):
Задача: {тема статьи}
Создай структуру: заголовки, основные тезисы каждой секции, логику подачи.
Выведи ТОЛЬКО: "PLAN: [структура с пунктами]"

ЭТАП 2 — EXECUTOR (Автор):
На основе структуры выше, напиши полный текст статьи.
Выведи ТОЛЬКО: "EXECUTION: [черновик статьи]"

ЭТАП 3 — CRITIC (Редактор):
Проверь текст: логика, читаемость, ошибки, повторы.
Исправь если нужно.
Выведи ТОЛЬКО: "FINAL: [финальная версия]"

Требование: выполни все три этапа последовательно.

🔧 Техника: Убрать "ТОЛЬКО" → видеть рассуждения

Если хочешь видеть как модель думает на каждом этапе, убери ограничение "Выведи ТОЛЬКО":

ЭТАП 1 — PLANNER (Структуратор):
Создай структуру: заголовки, основные тезисы.
Выведи PLAN и объясни логику построения.

ЭТАП 2 — EXECUTOR (Автор):
Напиши текст. Объясни почему выбрал такую подачу.
Выведи EXECUTION с комментариями.

ЭТАП 3 — CRITIC (Редактор):
Проверь текст. Объясни что исправил и почему.
Выведи FINAL с отчётом об изменениях.

Это даст прозрачность — увидишь где модель сомневалась, что исправляла, какие решения принимала.

🔧 Техника: Конкретные персонажи → острее критика

Вместо безликих "Planner, Executor, Critic" дай агентам характер:

ЭТАП 1 — Осторожный инвестор (консервативный взгляд):
Проанализируй бизнес-идею: {идея}.
Выдели все риски и слабые места.
Выведи: "RISKS: [список рисков]"

ЭТАП 2 — Агрессивный предприниматель (оптимистичный взгляд):
Вот риски: {из этапа 1}
Предложи как их обойти или минимизировать.
Выведи: "OPPORTUNITIES: [как использовать ситуацию]"

ЭТАП 3 — Опытный ментор (взвешенный вывод):
Вот риски и возможности. Дай финальную рекомендацию: входить или нет.
Выведи: "FINAL: [рекомендация + обоснование]"

Конкретные архетипы заостряют фокус каждой роли — критик становится жёстче, оптимист — смелее, финальный судья — объективнее.

Traceability and Accountability in Role-Specialized Multi-Agent LLM Pipelines

Исследование проводилось в сотрудничестве с zuvu.ai (промышленный партнер, разрабатывает AI-инструменты).

Датасет и детали эксперимента доступны: https://sites.google.com/view/mas-gain2025/home

Ключевые отсылки из исследования:

• ChatDev (C. Qian et al., 2023) — симуляция виртуальной софтверной компании с ролями CEO, программист, тестировщик
• MetaGPT (S. Hong et al., 2024) — агенты как менеджеры продукта и архитекторы
• Self-Refine (A. Madaan et al., 2023) — итеративное улучшение через self-feedback
• Self-Debug (X. Chen et al., 2023) — агент анализирует и исправляет баги в коде