Пять паттернов координации ИИ-агентов: как собрать рабочую мультиагентную систему, а не красивую игрушку

Что нового

Anthropic систематизировала подходы к мультиагентным системам вокруг пяти конкретных паттернов координации. Это не очередная «архитектура ради архитектуры», а практическое руководство: какой тип взаимодействия агентов выбирать под задачу и когда вообще не лезть в сложные схемы.

Пять базовых паттернов:

1. Generator–Verifier — генератор + проверяющий. Для задач, где важна точность и есть чёткие критерии качества.
2. Orchestrator–Subagent — один «лид» планирует работу и дергает специализированных подагентов.
3. Agent Teams — команда долго живущих агентов, которые берут задачи из очереди и накапливают контекст.
4. Message Bus — шина сообщений: агенты общаются через publish/subscribe, как микросервисы в event-driven архитектуре.
5. Shared State — общая база/файл, куда все агенты пишут и читают, без центрального координатора.

Новое здесь — не конкретный продукт, а карта решений: по каким признакам выбирать паттерн и как эволюционировать от простого к сложному. Anthropic прямо рекомендует:

• начинать почти всегда с orchestrator–subagent;
• смотреть, где система «ломается» — по качеству, скорости, сложности маршрутизации;
• переходить к другим паттернам только под конкретную боль, а не ради модной архитектуры.

Чёткие кейсы из текста:

• Поддержка клиентов с автогенерацией писем.
• Автоматический code review.
• Массовая миграция большого монорепо.
• SOC (security operations center) с кучей алертов.
• Система исследования и синтеза знаний по сложной теме.

Цифр по скорости, стоимости токенов или бенчмаркам Anthropic не приводит — это методология проектирования, а не релиз новой модели.

Как это работает

1. Generator–Verifier

Схема:

1. Генератор получает задачу и выдаёт первый вариант ответа.
2. Верификатор проверяет его по заранее заданным критериям.
3. Если ответ ок — цикл заканчивается. Если нет — вердикт + конкретный фидбек возвращаются генератору.
4. Генератор пробует снова с учётом замечаний.
5. Цикл повторяется до успеха или до лимита итераций.

Ключевой момент: верификатор не «оценивает по ощущениям», он работает по явным правилам: чек-лист, рубрика, тесты, политика комплаенса.

Примеры, которые разбирает Anthropic:

• Поддержка: генератор пишет письмо клиенту, верификатор проверяет факты по базе знаний, тон по брендбуку и закрытие всех пунктов тикета.
• Код: один агент пишет код, другой — пишет и запускает тесты.

2. Orchestrator–Subagent

Схема:

1. Оркестратор получает задачу «сверху».
2. Решает, как её разложить на подзадачи.
3. Какие-то части делает сам, остальные отдаёт подагентам.
4. Каждый подагент работает в своём контексте, возвращает результат.
5. Оркестратор собирает всё в финальный ответ.

Пример из Anthropic — Claude Code:

• основной агент редактирует файлы, пишет код, запускает команды;
• когда нужно обойти огромный кодовый базис или параллельно проверить гипотезы, он тихо запускает подагентов;
• каждый подагент работает в отдельном контексте и возвращает сжатый вывод;
• оркестратор остаётся сфокусирован на главной задаче, пока «разведка» идёт параллельно.

3. Agent Teams

Схема:

1. Координатор поднимает несколько «постоянных» агентов-работников.
2. Есть общая очередь задач.
3. Каждый агент берёт задачу, работает над ней несколько шагов, а не один вызов, и сигнализирует о завершении.
4. После завершения он не умирает, а ждёт следующую задачу, сохраняя свой контекст и «опыт».

Отличие от orchestrator–subagent: подагент живёт ровно один вызов, а teammate — долго, через десятки задач, и накапливает знание о своём домене.

Пример: масштабная миграция кода с одного фреймворка на другой.

• Координатор раздаёт сервисы по агентам.
• Каждый агент ведёт свой сервис: меняет зависимости, переписывает код, чинит тесты, валидирует.
• В конце координатор собирает всё и гоняет интеграционные тесты по системе целиком.

4. Message Bus

Схема:

1. Есть шина сообщений (message bus) и роутер.
2. Каждый агент подписывается на интересующие его типы событий (topics).
3. Агенты публикуют события (publish) на шину.
4. Роутер доставляет сообщения тем, кто на них подписан.

Никаких прямых вызовов «агент А → агент Б». Только события и подписки.

Кейс: автоматизация Security Operations Center.

• С разных систем сыпятся алерты.
• Агент триажа классифицирует их по типу и критичности.
• Сетевые инциденты летят к сетевому агенту, проблемы с учётками — к identity-агенту.
• Эти агенты могут публиковать запросы на обогащение данных, которые обрабатывает отдельный агент-контекстник.
• Всё это стекается к агенту координации реакции, который решает, что делать.

5. Shared State

Схема:

1. Есть общий persistent store: база данных, файловая система, общий документ.
2. Все агенты читают и пишут туда напрямую.
3. Координатора нет: каждый сам решает, что делать, глядя на состояние хранилища.
4. Работа стартует с инициализирующей записи (вопрос, датасет). Завершается по явному условию: дедлайн, порог сходимости, отдельный «завершающий» агент.

Кейс: система исследования сложной темы.

• Один агент копает академические статьи.
• Второй — отраслевые отчёты.
• Третий — патенты.
• Четвёртый — новости.

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

Общая база превращается в живую, постоянно пополняемую карту знаний.

Что это значит для вас

Когда вообще есть смысл в мультиагентности

Anthropic прямо говорит: многие команды выбирают сложные паттерны, потому что они звучат «умно», а не потому что нужны. Это путь к дорогой игрушке, а не к продукту.

Мультиагентная система даёт реальную пользу, когда:

• есть разные типы работы с разным контекстом (код, документация, логи, БД);
• ошибка дорогая, и нужен второй взгляд (генерация кода, юридические тексты, комплаенс);
• нагрузка легко распараллеливается (массовая миграция, обработка тысяч тикетов, поток алертов);
• workflow не фиксирован, а рождается из событий (безопасность, мониторинг, сложные пайплайны обработки данных);
• несколько агентов реально должны пользоваться находками друг друга, а не просто выдавать независимые ответы.

Если у вас одна последовательная задача без жёстких требований к надёжности, часто проще и дешевле один мощный агент (условно Claude 3.5 Sonnet или GPT-4o) + хороший промптинг.

Какой паттерн взять под конкретную задачу

1. Generator–Verifier: когда важнее качество, чем скорость

Используйте, если:

• у вас есть явные критерии: чек-лист, правила, тесты, рубрика;
• ошибка стоит дороже, чем лишняя итерация генерации;
• вы можете чётко сформулировать, что значит «правильно».

Подходит для:

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

Не подойдёт, если:

• критерии качества размазаны и субъективны («креативно», «интересно», «по вкусу CEO»);
• проверка по сути так же сложна, как генерация (например, оценка художественного стиля).

Главный риск: сделать «верификатор» без правил, который просто кивает на всё — иллюзия контроля вместо контроля.

2. Orchestrator–Subagent: универсальный стартовый вариант

Используйте, если:

• задачу легко разложить на чёткие подзадачи с понятным результатом;
• подзадачи слабо зависят друг от друга;
• вы хотите держать «картину целиком» в одном месте.

Типичные сценарии:

• автоматический code review: безопасность, покрытие тестами, стиль, архитектура — отдельные подагенты, один оркестратор собирает отчёт;
• сложные запросы к данным: один агент строит SQL, другой валидирует, третий объясняет результат;
• сложные ассистенты разработчика: основной агент пишет код, подагенты ищут по репо, анализируют логи, проверяют перф.

Минусы:

• оркестратор превращается в бутылочное горлышко: вся информация идёт через него;
• если подагент находит что-то важное для другого подагента, оркестратор должен сам догадаться, что это важно, и переслать;
• без явной параллелизации всё идёт последовательно, а вы платите за несколько агентов.

Практический совет: начинайте с этого паттерна. Когда логика маршрутизации раздуется и станет нечитаемой — это сигнал переходить к message bus или shared state.

3. Agent Teams: когда один агент — «долгоживущий специалист»

Используйте, если:

• подзадачи реально независимы друг от друга;
• каждая подзадача требует длинной работы и накопления контекста;
• вы хотите, чтобы агент «учился» на серии задач внутри одной области.

Подходит для:

• постепенной миграции большого монорепо по сервисам;
• обработки большого пула схожих, но независимых задач (например, пачка юридических договоров по одной схеме);
• систем, где «агент по сервису X» должен помнить историю изменений, типичные баги, паттерны.

Проблемы:

• если работы всё-таки завязаны друг на друга, агенты не видят изменений коллег и выдают конфликтующие результаты;
• нужно аккуратно решать, когда система закончила работу: один агент справился за 2 минуты, другой копается 20;
• общий ресурс (кодовая база, БД) создаёт риск конфликтов: два агента правят один файл разными способами.

Если вам нужно, чтобы агенты делились промежуточными инсайтами, а не только финальными результатами, лучше смотреть в сторону shared state.

4. Message Bus: когда у вас «оркестр алертов» и событий

Используйте, если:

• система живёт на событиях, а не на фиксированном pipeline;
• вы планируете добавлять новые типы агентов и событий по мере роста продукта;
• вам важно разрабатывать и деплоить агентов независимо.

Подходит для:

• SOC и любых систем безопасности с потоками алертов;
• event-driven пайплайнов обработки данных;
• сложных бизнес-процессов, где шаги зависят от того, что нашёл предыдущий агент.

Минусы:

• трассировка сложнее: одно событие может породить каскад из пяти агентов, и разбираться, «что пошло не так», труднее, чем в линейном оркестраторе;
• критично качество роутинга: если роутер неправильно классифицирует или теряет события, система не падает, а тихо ничего не делает;
• LLM-роутеры дают семантическую гибкость, но добавляют свои режимы отказа.

Если вы используете события не для запуска действий, а для обмена знаниями, лучше перейти к shared state.

5. Shared State: когда агенты должны строить общее знание

Используйте, если:

• агенты должны видеть и использовать находки друг друга в реальном времени;
• вы хотите избавиться от единой точки отказа (оркестратор/роутер);
• работа похожа на коллективное исследование или совместное редактирование.

Подходит для:

• исследовательских систем и аналитики по сложным темам;
• долгоживущих ассистентов, которые накапливают базу знаний о продукте, коде, бизнесе;
• сценариев, где важно, чтобы один агент сразу подхватывал следы, которые оставил другой.

Риски:

• дублирование работы: два агента могут копать один и тот же источник;
• противоречивые ветки расследований;
• реактивные циклы: A пишет вывод, B реагирует и пишет продолжение, A отвечает на B — и так бесконечно, пока вы жжёте токены.

Нужны жёсткие условия остановки:

• лимит времени;
• критерий сходимости: N циклов без новых фактов;
• отдельный «завершающий» агент, который решает, что база уже содержит достаточный ответ.

Если забить на терминейшн, система будет либо крутиться бесконечно, либо обрываться случайно, когда чей-то контекст переполнится.

Доступность и ограничения

Речь идёт о архитектурных паттернах, а не о конкретном продукте, который нужно запускать через VPN или по подписке. Вы можете реализовать эти схемы на любых доступных вам моделях — от Claude 3.5 и GPT-4o до локальных LLM.

Главное ограничение — не география, а инженерный бюджет:

• чем сложнее паттерн, тем дороже разработка, отладка и поддержка;
• мультиагентность почти всегда увеличивает расход токенов.

Если вы работаете из России и используете публичные API Anthropic или OpenAI, да, вам придётся решать вопрос доступа (через партнёров, прокси, VPN и т.д.). Сами паттерны от этого не меняются.

Место на рынке

Anthropic не сравнивает эти паттерны с конкретными реализациями от OpenAI, Google или других игроков. Это уровень архитектуры, который вы можете применить поверх любой LLM.

Что можно сказать честно:

• OpenAI, Google, Anthropic и другие уже используют похожие схемы внутри своих продуктов (кодовые ассистенты, агенты для безопасности, аналитики).
• Многие стартапы в области «AI agents» интуитивно собирают эти же паттерны, но без чётких имен и критериев выбора.

Чем полезен подход Anthropic:

• даёт общий словарь для разговоров между продактом, ML и бэкендом: вместо «давайте сделаем рой агентов» можно сказать «нам нужен message bus, потому что workflow событийный»;
• помогает не прыгать сразу в сложные фреймворки, а осознанно стартовать с orchestrator–subagent и уже потом добавлять shared state или message bus.

Если вы сравниваете не модели, а именно архитектурные подходы, здесь нет «быстрее/дешевле GPT-4o на X%». Это метод проектирования, который можно реализовать поверх любого стека — от Serverless-функций до Kubernetes и локальных LLM.

Как запустить (концептуально)

В исходном материале нет кода, но из описаний можно вывести базовые схемы реализации.

Пример: простой Generator–Verifier

function generate_with_verification(task, max_iters=3):
  criteria = load_verification_criteria(task)

  for i in range(max_iters):
    draft = generator_llm(task)
    verdict, feedback = verifier_llm(draft, criteria)

    if verdict == "accept":
      return draft

    task = update_task_with_feedback(task, feedback)

  return draft  // лучший из вариантов, но с пометкой, что верификация не прошла

Ключевой момент — criteria. Без него верификатор превращается в ещё один генератор.

Пример: Orchestrator–Subagent для code review

function review_pr(pr):
  security_report = security_agent(pr)
  tests_report    = tests_agent(pr)
  style_report    = style_agent(pr)
  arch_report     = architecture_agent(pr)

  final_review = orchestrator_llm({
    "security": security_report,
    "tests": tests_report,
    "style": style_report,
    "architecture": arch_report
  })

  return final_review

Здесь оркестратор — это LLM, которая видит все частные отчёты и пишет финальный комментарий.

Пример: Agent Teams с очередью

queue = TaskQueue()

workers = [AgentWorker(id=i) for i in range(N)]

class AgentWorker:
  def __init__(self, id):
    self.id = id
    self.memory = {}

  def run(self):
    while True:
      task = queue.pop()
      if not task:
        sleep(1)
        continue

      result = self.solve(task)
      report_completion(task, result)

  def solve(self, task):
    // здесь многократные вызовы LLM с учётом self.memory
    ...

Контекст (self.memory) живёт столько, сколько живёт агент.

Пример: Message Bus

class MessageBus:
  def __init__(self):
    self.subscribers = {}  // topic -> list of handlers

  def subscribe(self, topic, handler):
    self.subscribers.setdefault(topic, []).append(handler)

  def publish(self, topic, event):
    for handler in self.subscribers.get(topic, []):
      handler(event)

Агенты реализуют handler(event) и внутри уже вызывают LLM.

Пример: Shared State

class SharedStore:
  def __init__(self):
    self.records = []

  def read(self, filter=None):
    // вернуть релевантные записи
    ...

  def write(self, record):
    self.records.append(record)

store = SharedStore()

class ResearchAgent:
  def run(self):
    while not termination_condition(store):
      context = store.read(filter=self.interest)
      findings = self.investigate(context)
      store.write(findings)

Терминация — отдельная логика: дедлайны, сходимость, «главный» агент.

Итог: с чего начать команде

Если вы строите продукт с ИИ-агентами:

1. Начните с orchestrator–subagent. Это покрывает максимум сценариев с минимальной сложностью.
2. Если критична надёжность ответа — добавьте generator–verifier вокруг ключевых шагов.
3. Если у вас длинные независимые задачи — перейдите к agent teams.
4. Если workflow превращается в паутину if/else — вынесите маршрутизацию в message bus.
5. Если агенты должны совместно строить базу знаний — добавьте shared state.

Главная мысль Anthropic: не оптимизируйте под красивую диаграмму. Оптимизируйте под контекст, ошибки и стоимость поддержки вашей системы.

---

Читайте также

• Stash: открытый «мозг» для любых ИИ‑агентов вместо блокнотной памяти ChatGPT и Claude
• TIPSv2: Google улучшила понимание картинок по подписи до отдельных патчей
• Как подключить свой AI‑агент к Microsoft 365 Copilot и сохранить полный контроль