Конвейер, fan-out, оркестратор и коллегия критиков: какой паттерн мультиагентной системы подходит для какой задачи

Что это

Инженерное руководство Anthropic по созданию агентов разграничивает workflow (workflows), в которых последовательность обращений к модели задаёт код, и агентов, которые сами определяют свои шаги, и называет пять паттернов workflow; четыре из них комбинируют несколько вызовов (пятый, маршрутизация, направляет входные данные по одному специализированному пути). Цепочка промптов (prompt chaining): конвейер, в котором каждый вызов обрабатывает результат предыдущего, а между шагами стоят программные проверки. Параллелизация — в двух вариантах: секционирование, при котором независимые подзадачи выполняются одновременно, и голосование, при котором одна и та же задача выполняется несколько раз ради разных вариантов результата. Оркестратор с воркерами: центральная модель разбивает задачу на этапы во время выполнения, делегирует их и сводит результаты воедино. Evaluator-optimizer: один вызов генерирует результат, другой в цикле его оценивает. В отдельной статье Anthropic о своей исследовательской системе описан паттерн «оркестратор-воркеры», где ведущий агент координирует субагентов, работающих параллельно и каждый со своим контекстным окном; утверждается, что такие системы особенно хорошо подходят для широких запросов (breadth-first), одновременно охватывающих несколько независимых направлений. Документация Managed Agents перечисляет три хорошо работающих паттерна: параллелизацию, специализацию (маршрутизация к агентам с промптами и инструментами, ориентированными на конкретную область) и эскалацию (обращение к более мощной модели для сложных подзадач).

Почему это важно

Каждый паттерн умножает число вызовов и расход токенов и добавляет ещё один уровень (оркестратора, агрегатора, председателя коллегии), который может ошибаться так, как не ошибается ни один отдельный воркер. Выбор схемы по структуре самой задачи гарантирует, что это умножение происходит там, где оно действительно окупается.

Как применять

• Конвейер: шаги известны заранее, и у каждого есть проверяемый промежуточный результат (извлечь, проверить, перевести). Проверки между шагами реализуются в коде.
• Fan-out через секционирование: подвопросы независимы, а их ответы объединяются простой конкатенацией или несложным правилом (один файл или один источник на воркера). Сначала зафиксируйте формат вывода, чтобы объединение было чисто механическим.
• Fan-out через голосование: правильность результата трудно проверить, но легко сравнить (классификация, разметка флагами); используйте нечётное число попыток и фиксируйте расхождения как сигнал, а не как шум.
• Оркестратор с воркерами: декомпозиция зависит от того, что будет обнаружено по ходу дела (исследование, отладка в незнакомой кодовой базе). Стоит вложиться в качество постановки задач при делегировании: упомянутая статья об исследовательской системе связывает дублирование работы и пробелы в покрытии именно со скудными формулировками задач.
• Коллегия критиков: результат должен удовлетворять нескольким разным критериям (безопасность, стиль, корректность); дайте каждому критику ровно один критерий и фиксированную рубрику оценки, а агрегирование поручите коду.
• Начинайте с одного агента и качественного промпта; добавляйте паттерн только тогда, когда на него указывает зафиксированный сбой (переполнение контекста, пропущенное покрытие, односторонняя проверка).

Подводные камни

Воркеры, которые используют общий контекст и поэтому наследуют одну и ту же ошибку. Агрегирование через ещё один вызов модели, который незаметно теряет результат одного из воркеров. Оркестраторы, которые повторно выполняют работу, уже сделанную воркерами. Учёт стоимости, при котором считается только финальный вызов.