Multi-agent система: когда несколько агентов хуже одного workflow
Число агентов не определяет качество
Единые критерии: fit, TCO, контроль и восстановление
Оригинальная матрица ROUTE-6 для трёх сценариев
Выбор после пилота и проверки границ
$ choose-architecture --contract ROUTE-6
> bind: task / authority / outcome
> score: quality / speed / cost / control / recovery / upkeep
> route: workflow / one agent / multiple rolesMulti agent vs single agent — это выбор способа разделить работу, а не соревнование числа моделей. Варианты сравнимы только после фиксации задачи, полномочий, времени ответа и способа проверки результата. Часто детерминированный workflow с одним агентом на узком шаге оказывается проще нескольких агентов, которым приходится договариваться о состоянии. Ниже — авторская матрица выбора для проектирования; оценки иллюстративны и не являются измерениями клиентской системы.
Что именно сравниваем
Один агент получает цель, ограниченные инструменты и один контур состояния. Он может последовательно читать, предлагать и проверять. Multi-agent система назначает разные роли нескольким агентам: например, исследователь собирает источники, исполнитель готовит изменение, проверяющий оценивает результат. Между ролями появляются маршрутизация, передача контекста, разрешение конфликтов и восстановление после ошибки.
Третий вариант — обычный workflow: заранее заданные этапы с правилами, а модель работает только там, где нужен язык или неоднозначная классификация. Для повторяемого процесса это часто исходная точка сравнения. Число агентов само по себе не говорит о качестве ответа, безопасности или скорости.
Единые критерии оценки
Перед выбором зафиксируйте вход, выход и владельца решения. Сравните варианты по шести критериям: качество на репрезентативных задачах, задержка, стоимость владения, контроль действий, восстановление после ошибки и сложность сопровождения. Для каждого критерия задайте вес от 1 до 5 под конкретную задачу. Оценка варианта от 1 до 5 означает предполагаемую пригодность, а не внешний benchmark. Перемножьте вес и оценку; затем проверьте обязательные ограничения отдельно. Никакая сумма баллов не отменяет запрет на действие без прав.
| Критерий | Что наблюдать на пилоте | Типичный компромисс |
|---|---|---|
| Качество | полнота, источник, проверяемый результат | роли могут дать независимую проверку, но передача теряет детали |
| Скорость | время до подтверждённого ответа | параллельная работа помогает лишь независимым веткам |
| Стоимость | вызовы моделей, инструменты, журнал, поддержка | новые роли добавляют обмены и эксплуатацию |
| Контроль | кто разрешил действие и где проверены права | каждый агент расширяет поверхность полномочий |
| Восстановление | повтор, неизвестный исход, конфликт версий | распределённое состояние сложнее сверить |
| Сопровождение | версии промптов, тестов и инструментов | больше ролей требует больше контрактов |
Оригинальная матрица: три сценария
Здесь используется ROUTE-6: веса перечислены в порядке «качество / скорость / стоимость / контроль / восстановление / сопровождение». Все числа — проектные предположения для обсуждения. Их нужно заменить результатами собственного пилота, а не переносить в коммерческое обещание.
| Сценарий | Веса | Один агент | Несколько агентов | Workflow с узким AI-шагом | Первичный выбор |
|---|---|---|---|---|---|
| Ответ по внутренней инструкции | 4 / 4 / 4 / 5 / 4 / 4 | 100 | 72 | 113 | workflow |
| Исследование независимых источников | 5 / 3 / 2 / 4 / 3 / 3 | 83 | 88 | 72 | пилот нескольких ролей |
| Запись в CRM после согласования | 4 / 3 / 4 / 5 / 5 / 4 | 99 | 74 | 111 | workflow |
Числа иллюстрируют решение, а не измеренную производительность: для первого сценария, например, workflow оценивается выше благодаря фиксированному поиску и контролю доступа. Для исследования параллельные ветки могут помочь, если источники действительно независимы и проверяющий получает ссылки на первичные данные. Для CRM определяющим становится подтверждённый эффект, а не разнообразие рассуждений. Перед внедрением пересчитайте матрицу на реальных кейсах, включая ошибки и повторные вызовы.
Когда несколько агентов ухудшают результат
Если задача короткая и последовательная, координация создаёт дополнительную задержку. Если роли используют одни и те же документы, «независимая» проверка может повторить исходную ошибку. Если общий объект меняется между шагами, агент-проверяющий может одобрить устаревший черновик. При внешней записи появляется риск двойного действия после таймаута: неизвестный исход нельзя трактовать как отказ и автоматически повторять.
Разделение полезнее там, где ветки действительно независимы, есть ясный контракт передачи, а итоговый арбитр сверяет доказательства. Например, два исследовательских направления могут собирать разные первичные источники параллельно, но финальное решение должно проверять происхождение данных и противоречия. Нельзя выдавать обмен сообщениями между агентами за независимый audit.
Границы инструментов и MCP
MCP может стандартизировать подключение клиента к инструментам и ресурсам, но не выбирает архитектуру агентов и не заменяет серверную авторизацию. Каждый вызов должен проверять пользователя, tenant, целевой объект, допустимый эффект и версию инструмента. Подробнее — в материалах что такое MCP и безопасность MCP-сервера. Как оформлять саму функцию, показывает разбор tool schema.
Промпт не должен становиться единственным местом запрета. Для опасных записей нужен отдельный approval gate, idempotency key, журнал попытки и сверка с целевой системой. Если результат неизвестен, система должна остановиться для reconciliation. Эту границу подробнее разбирает модель разрешений AI-tools.
Как провести честный пилот
Соберите 20–30 типовых и крайних заданий из собственного процесса, удалив персональные данные. Для всех вариантов используйте одинаковый вход, одинаковые разрешённые источники и одну рубрику оценки. Замеряйте время до проверенного результата и полную стоимость, включая поддержку и разбор сбоев. Отдельно тестируйте пустой ответ инструмента, недоступный источник, конфликт версий, запрещённый объект и таймаут после внешней записи.
Решение принимают по ограничениям и наблюдаемым исходам пилота. Если один агент закрывает сценарий с понятной трассой, дополнительные роли требуют конкретного выигрыша. Если роли обнаруживают разные ошибки на независимых данных, проверьте, сохраняется ли эффект на новых задачах. Для составления процесса под конкретную компанию полезны prompt engineering и AI-автоматизация.
Итоговая матрица решения
Начните с workflow, когда этапы известны и действия требуют строгого контроля. Выбирайте одного агента, когда нужна гибкая работа с небольшим набором инструментов и одним владельцем состояния. Рассматривайте несколько агентов, когда есть независимые параллельные подзадачи, измеримый выигрыш и явные контракты передачи. Для выбора исполнителя и общего проекта AI в Армении используйте основной гид по AI-специалисту; эта статья помогает сформулировать архитектурные критерии, а не заменяет подбор подрядчика. Если нужен независимый разбор процесса, подготовьте краткий бриф с задачей, ограничениями и требуемым подтверждением результата.
const candidates = scoreSameFixtures(options, weights);
for (const candidate of candidates) {
if (!candidate.authorized || !candidate.recoversUnknownEffect) continue;
if (candidate.verifiedBenefit) return pilot(candidate);
}
return useSimplestPassingWorkflow();