Мультиагентные системы: когда нужны несколько агентов и как проверить их работу

Мультиагентная система нужна не потому, что задача выглядит сложной, а когда работу действительно приходится делить между участниками с разными данными, инструментами, правами или правилами проверки. Если шаги заранее известны, достаточно обычного workflow. Если маршрут меняется, но контекст и полномочия остаются общими, часто справится один ИИ-агент. Несколько агентов стоит рассматривать, когда такое разделение нельзя безопасно и понятно сохранить внутри одной роли.

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

Когда одного агента или workflow достаточно

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

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

Обычного workflow достаточно, если:

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

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

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

Какие схемы взаимодействия бывают

В документации LangChain для OSS Python, проверенной 4 октября 2026 года, описаны отдельные механизмы. Названия обозначают разное поведение, поэтому их не следует использовать как синонимы.

Последовательная передача по фиксированным шагам. Если заранее известно, что после извлечения требований всегда начинается поиск фактов, а затем редакторская проверка, это может быть custom workflow. В LangChain такой процесс связывают с графом LangGraph, где узлами могут быть обычные функции, вызовы модели или агенты. Последовательность остаётся детерминированной, пока система не выбирает маршрут самостоятельно.

Handoffs. Поведение меняется на основании состояния: инструмент обновляет текущий шаг или активного участника, после чего система применяет другую конфигурацию либо направляет диалог другому агенту. Этот механизм подходит для многоэтапного разговора, в котором новое состояние сохраняется между репликами. Он не равен любой последовательной передаче файлов между ролями.

Router. Отдельный шаг классифицирует вход и отправляет его одному или нескольким специализированным агентам. Результаты затем объединяются. Маршрутизатор удобен при ясных категориях запросов или нескольких независимых направлениях поиска. В отличие от управляющего агента, он обычно выполняет классификацию, а не ведёт многошаговую работу в контексте разговора.

Subagents. Главный агент, или supervisor, вызывает подчинённых агентов как инструменты, определяет их входы и собирает результаты. Управление остаётся у главного агента. Согласно документации, подагенты по умолчанию не хранят историю прошлых вызовов, что помогает изолировать контекст, но не освобождает проектировщика от явного контракта передачи.

Custom workflow. Разработчик сам задаёт узлы, условия, циклы и параллельные ветви, сочетая фиксированную логику с агентным поведением. Это полезно, если стандартная схема не выражает необходимые правила. Однако дополнительная гибкость означает больше состояний, которые придётся проверить.

Для закупочного примера не нужен handoff с прямым диалогом каждого участника с пользователем. Достаточно последовательного workflow из трёх ролей либо главного управляющего с двумя подзадачами: собрать требования, найти основания, проверить итог. Router понадобится только тогда, когда запросы действительно разделяются по устойчивым категориям.

Как разделить роли, данные и инструменты

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

В учебной подготовке ответа по закупке роли можно разделить так:

1. Сборщик требований получает только текст запроса и правила выделения требований. Он возвращает структурированный список: идентификатор, формулировка, обязательность и критерий приёмки. Ему не нужны ключи к поисковым системам или право утверждать итоговый ответ.
2. Исследователь фактов получает список проверяемых утверждений и перечень разрешённых источников. Он возвращает карточки: идентификатор требования, утверждение, адрес источника, фрагмент-основание, дату обращения и сведения о применимости. Он не меняет исходное требование, если источник ему противоречит.
3. Редактор получает требования, карточки фактов и правило приоритета. Он отмечает принятую ссылку, причины отклонения, конфликт и итоговый статус. Редактор не должен получать секреты инструментов исследователя.
4. Оркестратор передаёт данные между ролями, считает попытки и останавливает процесс. Он не подменяет специалиста заказчика при юридической, бухгалтерской, кадровой или отраслевой оценке.

Контракт передачи можно представить компактно:

requirement: R4
claim: «Поставщик поддерживает нужный способ передачи данных»
source_id: F5
source_checked_at: «дата обращения»
applicability: «версия и платформа из источника»
decision: accepted | rejected | conflict | human_required
reason: «почему принято решение»

Это описание формата, а не готовая интеграция. В рабочем проекте поля уточняют под данные и правила заказчика.

Не передавайте всем участникам полную переписку, все документы и общий набор секретов «на всякий случай». Сборщику требований нужен исходный запрос, исследователю — проверяемые пункты, редактору — основания и правила решения. API-ключи хранят отдельно и выдают только тому компоненту, который вызывает соответствующий инструмент. Инструкция внутри найденного документа не может расширить полномочия роли.

Как собирать итог и разрешать противоречия

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

Для конфликта установите порядок приоритета до запуска:

1. Сначала проверьте, входит ли источник в согласованный официальный перечень.
2. Затем проверьте применимость к нужной версии, платформе, тарифу и правам.
3. После этого сравните дату актуальности и область утверждения.
4. Если основания равны, неполны или относятся к разным условиям, присвойте статус human_required.

Приоритет официального источника не означает, что его текст автоматически подходит к системе заказчика. Документация может описывать функцию продукта, но не подтверждает наличие нужного тарифа, прав, настроек или уже выполненной интеграции.

У процесса должны быть технические пределы:

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

В учебной схеме участвуют три роли. Каждая получает один первоначальный запуск и не более одного повтора: 3 × (1 + 1) = 6 выполнений ролей. После шестого выполнения оркестратор завершает процесс. Неразрешённый конфликт не запускает новый круг, а получает статус «нужен человек».

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

Учебное сравнение одного и нескольких агентов

Ниже — синтетический пример, а не клиентский кейс, файл или результат внедрения Switch On AI. Он нужен, чтобы сравнить архитектуры на одинаковых входах.

Закупочный запрос содержит шесть требований R1–R6. На вход поиска поданы девять карточек фактов F1–F9:

• F1, F2, F4, F5 и F6 подтверждают требования R1–R5 — по одной карточке на требование;
• F3 и F7 относятся к требованию R6, но дают несовместимые ответы;
• F8 повторяет уже подтверждённое основание, а F9 не относится ни к одному требованию; их нельзя засчитывать как отдельное подтверждение;
• редактор применяет заранее заданное правило приоритета к конфликту F3/F7: принимает одну карточку и получает шесть оснований для R1–R6 либо передаёт нерешённый конфликт человеку.

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

Вариант с одним агентом

Один агент выделяет требования, ищет карточки и составляет итог. Ему доступен весь контекст и оба инструмента: чтение входа и поиск фактов. Такой вариант проще передавать и наблюдать, но одна роль одновременно формулирует утверждения и проверяет собственный выбор. Чтобы снизить риск, итог всё равно проходит по детерминированной рубрике: у каждого требования должна быть принятая ссылка, а конфликт нельзя скрывать.

Вариант с несколькими ролями

Сборщик возвращает R1–R6, исследователь — карточки F1–F9, редактор сопоставляет их и отдельно рассматривает конфликт F3/F7. Роли получают только нужные поля. Оркестратор проверяет формат передачи и лимит завершения.

Разделение облегчает независимую проверку и изоляцию доступов, но добавляет вызовы и риск потерять поле при передаче. Поэтому количество агентов нельзя использовать как показатель качества.

Критерии правильности

Покрытие требований считаем одинаково:

покрытие = число требований с принятой ссылкой / 6 × 100%.

Если закрыты все шесть требований, учебный расчёт равен 6 / 6 × 100% = 100%. Если конфликт оставил одно требование без принятого основания, получаем 5 / 6 × 100% = 83,3%. Это арифметика синтетических данных, а не измеренная точность системы.

Точность отбора считаем так:

точность отбора = число принятых релевантных карточек / число всех принятых карточек × 100%.

Если система приняла шесть релевантных карточек и одну нерелевантную, результат равен 6 / 7 × 100% = 85,7%. Нужный итог учебного примера — шесть требований с шестью принятыми релевантными ссылками, при этом отклонённые карточки и причина разрешения конфликта остаются в журнале.

Условные затраты

Чтобы не придумывать цены, зададим синтетическую шкалу: один модельный вызов стоит 3 учебные единицы, один вызов инструмента — 1 единицу.

• Один агент: один модельный и два инструментальных вызова — 1 × 3 + 2 × 1 = 5 единиц.
• Три специализированные роли: три модельных и шесть инструментальных вызовов — 3 × 3 + 6 × 1 = 15 единиц.

Эти числа показывают только устройство выбранной схемы. Они не измеряют скорость, денежную стоимость, качество или эффект проекта. В реальном пилоте нужно фиксировать фактические вызовы, токены, повторы и тарифы используемых сервисов.

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

Как выбрать инструменты и собрать минимальный процесс

Соберите минимальный процесс в шесть шагов.

1. Опишите роли. Для каждой укажите одно решение, которое она принимает, и действия, которые ей запрещены.
2. Закрепите контракт передачи. Определите обязательные поля, статусы ошибок и владельца каждого результата.
3. Выберите необходимые инструменты. Для учебного примера достаточно чтения входа, обращения к разрешённым источникам и сохранения журнала. Не подключайте отдельную технологию только ради слова «мультиагентная».
4. Настройте журнал. Сохраняйте вход, результат, источник, решение, ошибку, число попыток и причину остановки. Секреты в журнал не копируют.
5. Выполните один учебный прогон. Используйте синтетические R1–R6 и F1–F9, а не рабочие секреты или документы клиента.
6. Проверьте результат по рубрике. Посчитайте покрытие, точность отбора, число вызовов, повторы и конфликты. После этого решайте, нужна ли более сложная архитектура.

Готовый framework уместен, если проекту нужны встроенные механизмы управления состоянием, вызова подагентов, параллельных ветвей или изоляции контекста. Существующий workflow удобнее, если компания уже умеет выполнять шаги, вести журнал, повторять сбои и передавать исключения человеку без автономного управляющего.

Сравнивайте варианты по функциям, а не по известности названия:

Предоставленная документация подтверждает описанные архитектурные механизмы LangChain для OSS Python, но не доказывает совместимость с системой конкретного заказчика. Версию пакета, модель, доступные API, тарифы, права и требования к размещению проверяют отдельно перед проектированием.

Как провести пилот и обсудить архитектуру

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

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

Во время проверки фиксируйте:

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

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

Switch On AI может разобрать одну операцию, определить входы, границы полномочий и критерии приёмки, а затем согласовать прототип ИИ-помощника, бота или интеграции. Конкретные подключения, API и права проверяются до разработки. Прототип не равен полноценному внедрению и не подтверждает работу во всех условиях.

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