Один агент или целая команда?

Что мы называем командой агентов

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

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

Как это сделано у Anthropic

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

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

По материалам: Anthropic — How we built our multi-agent research system ↗

Пример: какие заказы под угрозой

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

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

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

Три способа разделить работу

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

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

По материалам: LangChain — Workflows and agents ↗

Как понять, окупается ли сложность

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

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