Все уроки · 44
Мультиагентные системы
Когда одного агента мало: изоляция контекста, специализация, параллельная работа, шаблон «оркестратор — исполнители» и подводные камни, о которых никто не предупреждает.
Зачем делить одного агента на нескольких?
Представьте одного сильного специалиста, который делает весь проект в одиночку: исследует рынок, пишет тексты, проверяет цифры, рисует слайды. Возможно — но медленно, а к шестому часу он держит в голове столько, что детали начинают ускользать. Команда из четырёх специалистов работает быстрее, и каждый остаётся собранным на своём участке. Цена — координация: кому-то нужно раздавать работу и сшивать результаты.
У агентов та же проблема. У одного агента одно окно контекста — текст, который он видит одновременно, его рабочая память, — и один характер. Это становится ограничением в трёх случаях:
- Изоляция контекста. Один агент, изучающий двадцать источников, заполнит своё окно контекста шумом. К моменту, когда он пишет отчёт, полезные факты оказываются разбавлены десятью тысячами токенов нерелевантных результатов поиска. А каждый исполнитель (worker) читает только свои источники и возвращает лишь то, что важно.
- Специализация. Промпт, который делает агента дотошным ревьюером кода, одновременно делает его худшим исследователем информации в интернете. Разделение ролей позволяет каждому агенту получить сфокусированные инструкции и только нужные ему инструменты — по той же причине, по которой в команде есть и дизайнер, и бухгалтер.
- Параллельная работа. Если один агент обрабатывает десять документов последовательно, на их краткий пересказ уходит в десять раз больше времени, чем на один. Независимые подзадачи можно выполнять одновременно, в отдельных контекстах — так же, как четыре человека могут прочитать по одной главе.
Подвох в том, что мультиагентные системы умножают всё, включая затраты, задержку и число мест, где что-то может пойти не так. Больше агентов — это больше рук, но и больше координации. Начинайте с одного агента; разделяйте, когда столкнётесь с одной из перечисленных выше проблем.
Шаблон «оркестратор — исполнители»
Самая распространённая структура — начальник и команда. Продолжая аналогию: руководитель проекта сам не пишет ни строчки текста, но решает, кто что делает, и собирает результат:
- Оркестратор получает цель, разбивает её на подзадачи и решает, кто что делает.
- Исполнители получают каждый по одной сфокусированной подзадаче, выполняют её в собственном чистом контексте со своими инструментами и возвращают результат.
- Оркестратор собирает результаты, замечает пробелы, при необходимости поручает доработки и составляет итоговый ответ.
Пользователь просит отчёт о рынке электросамокатов в Европе.
Заметьте, благодаря чему это сработало: каждый исполнитель вернул краткое резюме, а не сырую стенограмму. Контекст оркестратора остаётся небольшим — в этом и весь смысл шаблона.
Как агенты общаются друг с другом
Под капотом никакой тайны нет: передача между агентами — это просто вызов
инструмента, который запускает цикл другого агента. У оркестратора есть
инструмент вроде assign_task(worker="pricing", task="..."); ваш код поднимает
исполнителя, прогоняет его цикл и возвращает его финальное сообщение как результат
инструмента.
При проектировании нужно решить три вопроса:
- Что передаётся между ними. Обычно хватает описания задачи на входе и итогового отчёта на выходе. Если передавать между агентами целые стенограммы, возвращается проблема шума, от которой вы пытались уйти.
- Кто что видит. Исполнитель получает задачу и только те файлы или данные, которые ему нужны. Минимум входных данных — меньше отвлекающих факторов и ниже затраты на токены.
- Кто главный. В иерархических схемах решает оркестратор, а исполнители выполняют. В схемах-«пайплайнах» агенты передают результат по фиксированной цепочке: автор, затем ревьюер, затем редактор. Фиксированные пайплайны менее гибки, зато проще в отладке.
Затраты и подводные камни
- Распространение ошибок. Если исполнитель возвращает неверный факт, оркестратор обычно не может это заметить — он уверенно сводит всё воедино. Ошибка на втором шаге тихо отравляет пятый. Меры: агенты-проверяющие, которые сверяют утверждения; структурированные схемы вывода; требование к исполнителям ссылаться на источники.
- Отлаживать труднее. Стенограмма одного агента была историей, которую можно прочитать. Десять агентов порождают паутину переплетённых циклов. Трассировка из урока SDK и фреймворки для агентов перестаёт быть необязательной — это единственный способ увидеть, что произошло.
- Затраты умножаются. Каждый исполнитель стартует со своим контекстом и своими вызовами модели; оркестратор перечитывает всё. Задача, которая обходится в один доллар для одного агента, может обойтись в пять долларов для команды из пяти.
- Накладные расходы на координацию. Агенты могут дублировать работу друг друга, ждать друг друга или спорить. Каждое сообщение между ними тратится на координацию вместо задачи.
Когда добавлять агента
Добавляйте агента только тогда, когда можете назвать проблему, которую он решает: переполняющееся окно контекста, конфликт ролей в промпте или подзадачи, которые можно выполнять параллельно. Если назвать проблему не получается, один агент с хорошим промптом и хорошими инструментами почти всегда дешевле, быстрее и проще в отладке.
Проверьте себя
Что из этого — веская причина разделить одного агента на нескольких?
Что должен возвращать оркестратору агент-исполнитель?
Какова главная скрытая цена мультиагентной системы?
Куда идти дальше
Теперь вы можете проектировать системы, где несколько агентов делят работу под началом оркестратора, — и знаете, когда этого делать не нужно. Если что-то из этого показалось абстрактным, перечитайте два предыдущих урока: что такое AI-агент и SDK и фреймворки для агентов, откуда обычно и берётся обвязка для этого шаблона.