Мультиагентные системы простыми словами

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

Что такое мультиагентная система

Начнём с базы. AI-агент — это модель, которая получает цель, сама выбирает инструменты, вызывает их и корректирует план по результатам. Мультиагентная система — это несколько таких агентов, между которыми распределена работа, плюс правила, по которым они обмениваются задачами и результатами.

Ключевое слово здесь — распределена. Мультиагент — это не «одна модель, которую попросили сыграть три роли по очереди». Каждый агент в такой системе обычно имеет:

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

Последний пункт — главная техническая причина, по которой мультиагенты вообще существуют. Контекстное окно конечно, и агент, который прочитал сорок страниц логов, дальше работает хуже: важное тонет в шуме. Отправить чтение логов в отдельный процесс и вернуть в основной диалог три строчки вывода — это не про «интеллект», это про экономику контекста.

Зачем разбивать работу между агентами

Причин обычно четыре, и полезно понимать, какая из них работает именно в вашем случае.

1. Изоляция контекста. Побочная работа — поиск по кодовой базе, разбор выгрузки, чтение документации — съедает окно, но её результат нужен в сжатом виде. Отдельный агент выступает умным фильтром: перелопачивает много, возвращает мало.

2. Специализация. Промпт, заточенный под одну задачу, почти всегда работает лучше универсального. Агенту-ревьюеру можно дать жёсткий чек-лист, агенту-редактору — правила стиля, и они не будут мешать друг другу в одном раздутом промпте.

3. Параллельность. Пять независимых направлений поиска можно вести одновременно, а не по очереди. В инженерном разборе своей исследовательской системы Anthropic отмечает, что параллельные вызовы инструментов сокращали время выполнения сложных запросов почти на порядок.

4. Права доступа. Разделение на агентов — естественная граница безопасности: агент, который ходит в интернет, не имеет права писать в продовую базу. Это прямое продолжение принципов из заметки о безопасности AI-агентов.

Основные архитектуры

Названия у разных фреймворков отличаются, но сводится всё к нескольким схемам.

Оркестратор и исполнители

Самая распространённая схема (её называют orchestrator-workers или supervisor). Главный агент разбирает запрос, составляет план, порождает специализированных исполнителей под каждый подвопрос и собирает их ответы в итоговый результат. Исполнители друг с другом не разговаривают — вся координация идёт через центр.

Именно так устроена исследовательская система Anthropic: ведущий агент планирует, субагенты параллельно копают каждый свою ветку. По внутренним замерам компании такая связка обошла одиночного агента на той же топовой модели на 90,2% на исследовательских задачах — то есть на классе задач, где ценность именно в широте охвата.

Субагент как инструмент

Вариант той же идеи, но реализованный проще: субагент подключается к главному агенту как обычный инструмент. Модель «вызывает» его так же, как вызвала бы поиск или калькулятор, — механика ровно та же, что описана в заметке про tool calling. Управление после вызова возвращается наверх.

Передача управления (handoff)

Здесь агент не вызывает помощника, а отдаёт ему диалог целиком. В OpenAI Agents SDK передача реализована как обычный инструмент с говорящим именем вида transfer_to_refund_agent: модель выбирает его из списка так же, как любой другой. Типичная схема — triage-агент, который классифицирует обращение и переводит его на профильного: возвраты, биллинг, техподдержка. Важная деталь реализации: входные проверки (guardrails) применяются только к первому агенту в цепочке, а выходные — только к тому, кто формирует финальный ответ.

Сеть и иерархия

В «сети» (её ещё называют роем) каждый агент может передать управление любому другому — максимальная гибкость и максимальная непредсказуемость. В иерархии оркестраторы вкладываются друг в друга: главный координирует руководителей направлений, те — своих исполнителей. Обе схемы имеют смысл только тогда, когда вы уже упёрлись в потолок простой схемы с одним центром.

Как это выглядит на практике

Самый доступный пример мультиагентности «из коробки» — субагенты в Claude Code. Описание агента лежит обычным Markdown-файлом в .claude/agents/ внутри проекта (или в ~/.claude/agents/ для личных), а в YAML-шапке задаются name, description — по нему главный агент решает, кому делегировать, — а также опциональные tools, disallowedTools и model.

Принципиальный момент: субагент стартует с чистым контекстом. Ему передаются системный промпт из его же файла, формулировка задачи и файлы правил проекта, но не история вашего основного диалога. Отсюда простое следствие — задачу субагенту надо ставить самодостаточно, как незнакомому подрядчику, а не намёком «сделай как мы обсуждали выше». Рядом стоит посмотреть, чем субагенты отличаются от скиллов: скилл — это знание, которое подгружается в текущего агента, субагент — отдельный исполнитель со своим окном.

Сколько это стоит

Здесь начинается неприятная часть. Агентные сценарии сами по себе жадные до токенов: по оценке Anthropic, агент расходует примерно вчетверо больше токенов, чем обычный чат, а мультиагентная система — примерно в пятнадцать раз больше. Причём расход токенов объясняет около 80% разброса в качестве результата: мультиагент выигрывает во многом просто потому, что «думает» намного дольше и больше.

Из этого следуют два практических вывода. Первый: мультиагент экономически оправдан там, где ценность ответа высока, а задача хорошо распараллеливается, — исследование, широкий обзор источников, аудит большого объёма материала. Для линейных задач с жёсткой последовательностью шагов пятнадцатикратный расход не окупается ничем. Второй: прежде чем строить систему из пяти агентов, стоит выжать очевидное из одного — экономию на токенах и лимитах и аккуратную работу с памятью агента.

Где мультиагенты ломаются

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

Типовые грабли, о которых стоит знать заранее:

• Переусердствовавший оркестратор. В ранних версиях системы Anthropic ведущий агент порождал до пятидесяти субагентов на простой вопрос. Масштаб усилий нужно задавать явно: «простой вопрос — один агент и несколько вызовов инструментов, сложный — больше».
• Дублирование работы. Без чётких границ два исполнителя ищут одно и то же и возвращают почти одинаковые ответы, за которые вы платите дважды.
• Каскад ошибок. Мелкая неточность на раннем шаге не отсеивается, а тиражируется всеми, кто на неё опирался.
• Отладка. Агент принимает решения динамически, поэтому воспроизвести падение бывает невозможно. Трассировка всех вызовов — не роскошь, а условие эксплуатации.

Когда мультиагент не нужен

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

Общая рекомендация Anthropic в этом вопросе консервативна: начинать с самого простого решения и усложнять, только когда простое явно не справляется. Часто одного вызова модели с хорошим промптом и подтянутыми документами достаточно.

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

С чего начать

1. Сначала один агент. Доведите одиночного агента до потолка — на нём же вы поймёте, где реально упираетесь: в контекст, в скорость или в качество промпта. Если этого этапа ещё не было, начните с гайда как написать своего AI-агента.
2. Выделите одну подзадачу. Обычно первый кандидат — «прочитать много, вернуть мало»: поиск, разбор выгрузки, сбор фактуры.
3. Опишите задание как для подрядчика. Цель, формат вывода, границы, что делать не надо. Расплывчатое задание — главная причина, по которой субагенты возвращают мусор.
4. Ограничьте права. Только те инструменты, которые нужны роли, — см. чек-лист по безопасности MCP-серверов, если агенты ходят во внешние системы.
5. Заведите оценку. Не нужен большой бенчмарк: Anthropic советует стартовать примерно с двадцати реальных запросов и рубрики, по которой отдельная модель-судья оценивает точность фактов, полноту и качество источников. Живая ручная проверка при этом остаётся обязательной — именно она ловит перекосы вроде склонности агента предпочитать SEO-статьи первоисточникам.

Вывод

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