Сравнение четырех шаблонов многоподразделочных систем: субагенты, навыки, передача задач, маршрутизаторы.

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

Действительно ли вам нужны несколько агентов?

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

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

Подагенты: руководитель штаба

Представьте себе начальника штаба, который никогда не выполняет работу лично, но точно знает, к кому обратиться. Главный агент-контролер имеет полную картину ситуации. Когда требуется получить данные из CRM, составить электронное письмо или выполнить расчёт, он вызывает специализированного подагента, как будто это инструмент, получает результат и собирает всё воедино.

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

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

Навыки: один агент, множество ролей

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

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

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

Передача задач: эстафета

Если субагенты представляют собой параллельное делегирование обязанностей, а навыки — динамическую специализацию, то передача задач происходит последовательно, что наиболее близко к тому, как люди преодолевают сложные процессы. Пользователь обращается сначала к агенту A. Как только что-то говорится или выполняется определённое условие, управление переходит к агенту B, у которого есть собственные системные указания, инструменты и, возможно, свой стиль общения, а затем — к агенту C. Всё это время информация о состоянии дел, то есть всё, что было обсуждено и решено, передаётся вместе с каждой передачей.

Переходы определяются состоянием. Агенты не просто обмениваются сообщениями между собой; они обновляют общее состояние, и именно это состояние определяет, кто будет действовать далее. По сути, это машина состояний, в которой агенты выступают в роли состояний.

Эта структура идеально подходит для многоэтапных процессов обслуживания (сначала сортировка, затем диагностика, потом устранение проблем), для юридической работы, где проверка на наличие конфликтов должна предшествовать рассмотрению дела, а также для процессов оформления заказа, когда оплата не может начаться до подтверждения корзины. Люди забывают о том, что последовательность означает отсутствие параллелизма: если необходимо одновременно запрашивать информацию из трех баз знаний, нужно искать другие решения. Этот подход подходит только для рабочих процессов, в которых шаг B действительно не может начаться до завершения шага A. Управление состояниями также представляет сложность, и когда цепочка передачи данных нарушается, отладка становится непростой задачей, поэтому перед принятием решения следует выделить дополнительное время на использование инструментов для отслеживания и анализа.

Маршрутизатор: диспетчер воздушного движения

Концептуально это просто. Специальный механизм на входе классифицирует каждый поступающий запрос и направляет его к соответствующему специалисту или группе специалистов. Они работают параллельно, а их результаты объединяются в один ответ. Маршрутизатор не сохраняет состояние, поэтому каждый запрос обрабатывается независимо.

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

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

Выбор

Этот процесс не обязательно должен быть сложным.

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

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

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

Сначала ограничения

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

Что дальше

Рассматривайте эти четыре паттерна как основную грамматику проектирования многокомпонентных систем в настоящее время, при этом новые термины появляются очень быстро. Постоянные локальные агенты, сохраняющие память между сессиями и подключающиеся к личным файлам и приложениям, переходят от этапа исследований к реальным продуктам. Протокол Model Context Protocol, по данным на начало 2026 года имевший 97 миллионов установок, превращается в основу, позволяющую агентам от разных поставщиков взаимодействовать без необходимости в специальной интеграции. Начинают появляться сети агентов, которые динамически создают новых агентов, масштабируя свою рабочую силу в зависимости от сложности задач. Всё это поддерживается сабагентами, навыками, механизмами передачи задач и маршрутизаторами, поэтому овладение ими сейчас дает преимущество. Ориентир для принятия решения: сначала опишите конкретную проблему, назовите паттерн, который её решает, и только затем рисуйте диаграмму. Начните с простого, будьте честны относительно своих потребностей, и когда перейдете к использованию нескольких агентов, вы сразу поймете, какой путь выбрать.