Почему монолит тяжело расширять
Вспомним агента-монолита из урока про разделение ответственности. Каждая новая способность добавляется внутрь него: ещё один инструмент в общий список, ещё абзац в системный промпт, ещё ветка в логике. И вот в чём беда — все эти части связаны: новый инструмент конкурирует со старыми за внимание модели, новая инструкция в промпте меняет поведение в уже работавших сценариях.
В результате стоимость каждого следующего изменения растёт: чем больше агент умеет, тем рискованнее его трогать. Добавил поддержку нового формата — поехала классификация в другом месте. Это та же «комбинаторная связность», что губит большие монолиты в обычном коде: количество взаимодействий между частями растёт быстрее, чем сами части.
Масштабируемость архитектуры определяется не тем, сколько в ней частей, а тем, насколько сильно они связаны. Слабо связанные части можно добавлять и менять по отдельности; сильно связанные тянут друг друга. Мультиагентность — это способ держать связность низкой: каждый агент изолирован за своим контрактом.
Рост = добавить агента, а не переписать
В мультиагентной системе новая способность оформляется как новый специализированный агент. Он подключается к системе через те же механизмы, что и остальные (координатор, контракты, реестр), и не требует правок в существующих агентах. Старые роли о новичке даже не знают — за маршрутизацию отвечает координатор.
Это open/closed принцип из инженерии в действии: система открыта для расширения (легко добавить агента) и закрыта для изменения (старые трогать не надо). Добавление translator не требует переписывать researcher — они связаны только через координатора и контракты, а не напрямую.
Что делает рост дешёвым
«Добавить агента легко» — не магия, а следствие трёх вещей, которые мы уже встречали в этом и прошлых модулях:
Высшая форма масштабируемости — когда агент публикует свои способности, а система подхватывает его автоматически, без правок кода маршрутизации. Это идея Agent Cards и Skills (раздел про протоколы взаимодействия): агент описывает «я умею переводить на FR/DE», координатор находит его по запросу. Так команда расширяется почти как плагинами.
Два измерения масштабирования
«Масштабируемость» в мультиагентах означает рост сразу в двух направлениях — их полезно различать:
Функциональный рост опирается на специализацию и контракты (этот урок). Рост по нагрузке — на параллелизм из прошлого урока: запустить N копий «обработчика» на N элементов. Хорошая мультиагентная архитектура растёт в обоих измерениях независимо.
Пример: пайплайн, который дорос
Начали с трёх агентов: researcher → analyst → writer. Дальше требования прибавлялись — и каждый раз это был добавленный агент, а не переписанный пайплайн:
v1: researcher → analyst → writer v2: + fact_checker (требование: проверять факты) v3: + translator (требование: выпускать на 3 языках) v4: + compliance (требование: проверка на регламент) каждый «+» = новый агент по существующим контрактам, старые роли НЕ менялись
Сравни с монолитом: там v2–v4 означали бы всё новые куски промпта и инструменты в одном агенте, с риском регрессий на каждом шаге. В команде каждое расширение локально: добавили fact_checker между analyst и writer — остальные даже не заметили.
Пределы масштабирования
Линейно добавлять агентов можно не бесконечно — у роста есть своя цена:
- Координация растёт нелинейно. Чем больше агентов, тем сложнее координатору правильно маршрутизировать и тем больше «болтовни» между ролями. В какой-то момент управляющий сам становится узким местом — тогда вводят иерархию (команды команд, супервайзер над супервайзерами).
- Пересечение ролей. При росте легко завести двух агентов с похожими способностями — координатор начнёт путаться, кому отдать задачу. Чем больше команда, тем строже нужны границы (урок про разделение ответственности).
- Стоимость и задержка. Каждый агент — это вызовы LLM. Больше агентов в цепочке — выше суммарная цена и latency.
- Наблюдаемость. Отлаживать систему из 20 агентов труднее, чем из 3, — растёт важность трейсинга (модуль 03).
Лёгкость добавления агентов — это про дешёвый рост, когда он нужен, а не про повод плодить роли. Каждый агент оправдан, только если приносит отдельную способность. Когда координация начинает стоить дороже самой работы — пора либо вводить иерархию, либо сливать роли. Где проходит эта граница и когда мультиагенты вообще избыточны — тема следующего урока.
Типичные ошибки
Дописывать новый инструмент и инструкции в работающий агент — путь монолита: растёт связность и риск регрессий. Новая способность → новый агент.
Если агенты вызывают друг друга напрямую по именам, добавить нового — значит переписать связи. Маршрутизацию держи в координаторе, связь — через контракты/способности.
Плоская команда из 20 агентов перегружает координатора. На определённом размере переходи к иерархии, а не наращивай плоский список.
Добавлять агентов «на всякий случай» — лишняя стоимость и сложность. Каждый новый агент должен закрывать реальную отдельную способность.
Шпаргалка
ИДЕЯ: новая способность = новый АГЕНТ, а не правка старых
open/closed: открыто для расширения, закрыто для изменения
МОНОЛИТ vs КОМАНДА (при росте):
монолит — каждое расширение внутрь → растёт связность, риск регрессий
команда — новый агент по контракту → старые не трогаем
ЧТО ДЕЛАЕТ РОСТ ДЕШЁВЫМ:
• чёткие контракты (вход/выход) — новичок встаёт по интерфейсу
• координатор отделён — учим его про роль, не правим остальных
• самоописание способностей (Agent Cards / Skills) — авто-подхват
ДВА ИЗМЕРЕНИЯ:
по способностям (функционально) → новый ВИД агента
по нагрузке (количественно) → РЕПЛИКИ + параллелизм
ПРЕДЕЛЫ:
• координация растёт нелинейно → иерархия (команды команд)
• пересечение ролей → строже границы
• стоимость/latency/наблюдаемость растут с числом агентов
ПРАВИЛО: дешёвый рост КОГДА НУЖНО, а не повод плодить агентов
Практическое задание
Проверь архитектуру на масштабируемость (упражнение на дизайн):
Задание: вырасти систему без переписывания
- Возьми пайплайн из 3 агентов (например,
researcher → analyst → writerс контрактами из урока про специализацию). - Поступило требование: добавить проверку фактов. Опиши, как ввести
fact_checker, не меняя существующих агентов. Куда он встанет, какой у него контракт, что узнаёт координатор? - Ещё требование: выпускать результат на трёх языках. Реши, это рост «по способностям» (новый агент-переводчик) или «по нагрузке» (реплики). Обоснуй.
- Сравни с монолитом: что пришлось бы изменить в одном агенте для тех же двух требований и какие регрессии это грозит вызвать.
- Найди в своей выросшей системе момент, когда координатору становится тяжело. Как ввести иерархию (под-команду со своим супервайзером)?
- Со звёздочкой: опиши «самоописание»: как агент мог бы публиковать свои способности, чтобы координатор подхватывал его автоматически (намёк на Agent Cards / Skills).
Что дальше
Мы разобрали четыре причины за мультиагенты: специализация, параллелизм, взаимная критика и масштабируемость. Честный разговор требует и обратной стороны — следующий урок про то, когда мультиагенты только мешают.