# Когда одного агента мало Экспресс-курс о мультиагентных системах — когда разбить работу на специализированных агентов под управлением оркестратора и когда это хуже одного агента. 19 понятий — Specialization, Orchestrator, Worker Agent, Handoff, Context Isolation, Sequential, Parallel, Hierarchical, Compounding Error, Coordination Overhead и другие — у каждого английское название, схема, карточка и пример. В конце — шпаргалка по всем понятиям на одной странице. - **Author:** Фёдор Чищин - **Level:** intermediate - **Reading time:** ~35 минут чтения - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/ru/learn/multi-agent-express --- ## 1. Зачем разбивать на многих Прежде чем связывать агентов вместе, пойми, какую проблему это решает. У мультиагентных систем есть конкретная причина существовать — а тянуться к ним без этой причины и есть то, как они идут не так. ### Карта: 19 понятий в семи группах > Карта метро: сначала видишь линии целиком, потом едешь по станциям. Курс идёт по семи группам. Сначала — **зачем вообще разбивать** работу на агентов и чем за это платишь. Потом — три роли системы: **оркестратор**, что делит и собирает, **воркеры**, что делают узкую работу, и **передачи** между ними. Дальше — три **формы** связи агентов, три **режима сбоя**, которые мультиагентность умножает, и в конце — **практика**: когда разбивать, а когда нет. _Diagram: Семь групп понятий — по ним идут главы 1–7._ ### Как читать каждое понятие > Паспорт: одинаковые поля у всех, поэтому их легко сравнивать. У каждого понятия дальше одно и то же: **английское название** (запомни его — так это называют в документации и статьях), образ из жизни, **схема** и **карточка** с полями вроде _проблема_, _идея_, _пример_, _цена_ и _связи_. Главная мысль курса: **больше агентов умножают и способности, и способы сломаться** — поэтому разбивают только тогда, когда одного правда мало. ### Specialization — один агент, что делает всё, не делает хорошо ничего > Один работник, которому велели быть архитектором, сантехником, электриком и инспектором, — против маленькой бригады специалистов, где каждый делает одно как надо. Это понятие **Specialization** — специализация. У одного агента со слишком широкой задачей — все инструменты, все виды работы, один гигантский промпт — слишком много способов ошибиться на каждом шаге. Чем больше работа, тем ниже его надёжность. Если разбить работу на **специализированных агентов** (specialized agents), у каждого из которых узкая задача, вся система может стать способнее и надёжнее — так же, как бригада специалистов обходит одного перегруженного универсала. Специализация — главная причина, по которой мультиагентность вообще существует. _Diagram: Слева один агент на все работы — много мест для ошибки. Справа бригада: каждый делает одно._ #### Specialization (специализация агентов) - **Проблема:** Один агент с широким мандатом — все инструменты, один огромный промпт — часто ошибается. - **Идея:** Разбить работу на узких агентов, каждый делает одно хорошо. - **Пример:** Вместо одного «агента на всё» — исследователь, программист, проверяющий факты и форматировщик. - **Цена:** Появляется **координация** — кто-то должен делить работу и собирать итог. - **Связи:** Причина брать **Orchestrator** и **Worker Agent**; цена описана в **Coordination Cost**. ### Context & Tool Overload — контекст и инструменты перегружают одного агента > Один стол, заваленный каждым документом и каждым инструментом для десяти разных работ, — работник тратит больше сил на разбор бардака, чем на саму работу. Два конкретных предела выталкивают за рамки одного агента — это **Context & Tool Overload**, перегрузка контекстом и инструментами. Первый: **окно контекста** (context window) одного агента заполняется всем для каждой части задачи, а переполненный контекст снижает качество (это проблема из курса об инженерии контекста). Второй: агент, у которого _все_ инструменты, каждый ход выбирает из гигантского меню — и чем оно длиннее, тем хуже выбирает. Разбиение даёт каждому агенту нести только тот контекст и те инструменты, что нужны его узкой работе, — чисто, сфокусированно, надёжно. _Diagram: Один агент: окно забито всем подряд, меню из двенадцати инструментов. После разбиения у каждого маленькое окно и три инструмента._ #### Context & Tool Overload (перегрузка контекстом и инструментами) - **Что это:** Два предела одного агента: переполненное окно контекста и слишком длинное меню инструментов. - **Почему важно:** Переполненный контекст снижает качество, а длинное меню ухудшает выбор инструмента на каждом ходу. - **Пример:** Агент поддержки держит в окне и биллинг, и техдоки, и историю, а инструментов у него два десятка. - **Подвох:** Сначала стоит попробовать сузить инструменты и почистить контекст одного агента — иногда этого хватает. - **Связи:** Лечится через **Context Isolation** и узких **Worker Agent**. ### Coordination Cost — специализация это выигрыш, координация это цена > Эстафетная команда быстрее одного бегуна, который бежит все четыре этапа, — но только потому, что передачи отрепетированы; упущенная палочка проигрывает гонку. Выигрыш мультиагентности — специализация: узкие агенты, каждый делает одно хорошо. Цена — **Coordination Cost**, стоимость координации: теперь кто-то должен разбить работу, распределить её, передавать контекст между агентами и собирать результаты. И сама эта координация — источник сложности и сбоев. Вся дисциплина в том, чтобы поймать выигрыш специализации и не дать цене координации его съесть. Если выигрыш не перевешивает цену, верным ответом был один агент. _Diagram: Весы: мультиагентность окупается, только когда выигрыш специализации тяжелее цены координации._ #### Coordination Cost (цена координации) - **Что это:** Всё, что нужно, чтобы агенты работали вместе: разбить, распределить, передать, собрать. - **Почему важно:** Координация сама по себе — источник сложности и сбоев. - **Пример:** Эстафета быстрее одного бегуна только при отрепетированных передачах палочки. - **Подвох:** Не перевешивает выигрыш — значит, мультиагентность сделала систему хуже, а не лучше. - **Связи:** Подробно раскрывается в **Coordination Overhead** и **Compounding Error**. > **Вопрос рамки:** «Это правда слишком много для одного агента — слишком много инструментов, навыков или контекста, — так что специализация поможет больше, чем стоит координация?» > Один агент, что делает всё, не делает хорошо ничего — слишком много контекста, слишком много инструментов. Много специализированных агентов могут быть способнее, но цена — координация, и она должна окупаться. ## 2. Паттерн оркестратора У самой частой формы мультиагентной системы в центре стоит координатор. Понять оркестратор — значит понять бо́льшую часть того, как эти системы устроены. ### Orchestrator — координатор, что распределяет работу > Генподрядчик на стройке: он не кладёт кирпичи и не собирает щиток — он разбивает проект на работы и отдаёт каждую нужному специалисту. Это паттерн **Orchestrator** — оркестратор, или координатор. Это главный агент: он берёт общую цель, **разбивает её на подзадачи** (decomposition) и **отправляет** каждую нужному специализированному агенту (routing). Специализированную работу он сам не делает — его работа в том, чтобы делить и направлять. Это та же идея **plan-and-execute** из курса об агентах, только масштабированная: один способный агент планирует и делегирует, а сфокусированные воркеры выполняют куски. _Diagram: Оркестратор делит цель на подзадачи и отдаёт каждую своему воркеру. Сам он работу специалистов не делает._ #### Orchestrator (оркестратор, координатор, orchestrator–worker) - **Проблема:** Большую цель с разными навыками нельзя просто отдать одному узкому агенту. - **Идея:** Главный агент разбивает цель на подзадачи и направляет каждую нужному воркеру. - **Пример:** Исследовательский оркестратор раздаёт подтемы нескольким агентам-исследователям. - **Цена:** Ещё один агент и ещё один слой, где может что-то сломаться. - **Когда брать:** Работа правда распадается на куски, которым нужны разные навыки или инструменты. - **Связи:** Масштабированный **plan-and-execute**; управляет **Worker Agent** через **Handoff**; собирает итог через **Assembly**. ### Assembly — оркестратор собирает результаты воркеров > Редактор заказывает разделы разным авторам, потом сводит их в одну цельную статью — куски возвращаются, и кто-то делает из них целое. Вторая работа оркестратора — **Assembly**, сборка (её ещё называют синтезом). Оркестратор собирает то, что вернули воркеры, и объединяет в один связный результат. Исследовательский оркестратор может раздать подтемы нескольким агентам, а потом свести их находки в один ответ. Этот шаг «собрать и объединить» — то место, где отдельные потоки работы становятся одним выводом. Делать его хорошо — **разрешать противоречия, выкидывать дубли** — так же важно, как правильно разбить работу. _Diagram: Находки трёх воркеров сходятся в оркестраторе: он снимает противоречия, выкидывает дубли и выдаёт один ответ._ #### Assembly (сборка, синтез результатов) - **Что это:** Шаг, где оркестратор собирает ответы воркеров в один результат. - **Почему важно:** Без хорошей сборки получится не ответ, а куча кусков, которые спорят друг с другом. - **Пример:** Три агента исследовали три подтемы; оркестратор пишет один отчёт без повторов. - **Подвох:** Сборку считают мелочью — а противоречия и дубли всплывают именно в ней. - **Связи:** Вторая половина работы **Orchestrator**; финальный шаг паттерна **Parallel**. ### Coordination Layer — слой координации и есть настоящая архитектура > Оркестр — это не куча блестящих солистов, а дирижёр и партитура, которые решают, кто играет когда. Координация и есть музыка. В мультиагентной системе ценность и сложность переезжают в **Coordination Layer** — слой координации: кто запускается когда, с каким входом и как результаты объединяются. Внимание достаётся отдельным агентам, но работает ли система, решает оркестрация вокруг них — **маршрутизация, передача контекста, обработка ошибок**. Как и с одиночными агентами, модель — лёгкая часть; надёжность выигрывается или теряется в структуре вокруг неё. _Diagram: Над агентами лежит слой координации: маршрутизация, передача контекста, сборка, обработка ошибок. Он и решает, работает ли система._ #### Coordination Layer (слой координации, оркестрация) - **Что это:** Код и правила вокруг агентов: кто запускается когда, с каким входом, как сводятся результаты. - **Почему важно:** Работает ли система, решается здесь, а не в отдельных агентах. - **Пример:** Отличные агенты, но воркер получает не тот вход, — и вся система выдаёт мусор. - **Подвох:** Полировать промпты агентов и оставлять координацию «как получится». - **Связи:** Включает **Orchestrator**, **Handoff** и **Assembly**; его отлаживают через **Multi-agent Tracing**. > **Вопрос оркестратора:** «Есть ли ясный координатор, который разбивает цель, отдаёт каждый кусок нужному агенту и собирает результаты, — или координация происходит случайно?» > Оркестратор разбивает цель, отдаёт каждую подзадачу специализированному воркеру и собирает их результаты. Настоящая архитектура — слой координации, а не отдельные агенты. ## 3. Специализированные воркеры Агенты, которыми управляет оркестратор, полезнее всего, когда каждый узок. Держать воркеров сфокусированными — вот что делает всю систему надёжной и тестируемой. ### Worker Agent — у каждого воркера одна ясная работа > Кухня, где у каждой задачи своя станция: один повар на соусах, один на гриле, один на подаче — каждый мастер своей узкой роли, а не середнячок во всех. **Worker Agent** — агент-воркер — это специализированный агент с узкой, чётко определённой работой: искать в документах, писать код, проверять факты, форматировать вывод. Раз задача маленькая, то и **промпт сфокусирован**, и **инструментов мало**, и поведение предсказуемо. Оркестратор вручает ему ясную подзадачу — он делает одну эту вещь и возвращает результат. Узкие воркеры — строительные блоки системы: каждый достаточно прост, чтобы сделать его правильно и ему доверять. _Diagram: Воркер: на входе подзадача от оркестратора, внутри — сфокусированный промпт и пара инструментов, на выходе — результат._ #### Worker Agent (агент-воркер, специалист) - **Что это:** Агент с одной узкой работой, коротким промптом и немногими инструментами. - **Как работает:** Получает ясную подзадачу от оркестратора, делает её и возвращает результат. - **Пример:** Агент поиска по документам, агент-программист, агент проверки фактов, агент-форматировщик. - **Подвох:** Воркер постепенно обрастает «ещё парой инструментов» и снова становится универсалом. - **Связи:** Им управляет **Orchestrator**; его проверяют **Per-agent Evals**; держится принципа **Depth over Breadth**. ### Per-agent Evals — узкого агента легче тестировать и ему доверять > Работу одного специалиста можно проверить досконально, потому что она маленькая и чётко определена, — куда проще, чем аудировать универсала, который делает всего понемногу. Узкого агента куда легче оценить, отладить и ему доверять, чем расползшегося. С одной ясной работой ему можно написать **эвалы** (evals) — это практика **Per-agent Evals**, тесты на каждого агента отдельно. Ты видишь, где именно он ошибается, и чинишь его изолированно — тот же аргумент надёжности из курса об агентах, применённый к каждому куску. Мультиагентная система надёжна, только если надёжен каждый её воркер по отдельности, а этого куда проще добиться, когда каждый делает одну чётко очерченную вещь. _Diagram: У каждого воркера свои эвалы. Упал один — видно, какой именно, и его чинят отдельно, не трогая остальных._ #### Per-agent Evals (эвалы на каждого агента) - **Что это:** Отдельный набор тестов на каждого воркера, а не только на всю систему. - **Как делать:** Для каждой узкой работы — свои примеры «вход → ожидаемый выход» и проверка результата. - **Пример:** Эвалы агента проверки фактов падают — чинят его промпт, остальные агенты не трогаются. - **Подвох:** Тестировать только итог всей системы: при сбое непонятно, какой агент виноват. - **Связи:** Работает, только если **Worker Agent** узок; дополняет **Multi-agent Tracing**. ### Depth over Breadth — глубина в одной работе лучше широты во многих > Хирург, который делает одну операцию тысячи раз, надёжнее универсала, который берётся за неё изредка, — фокус даёт надёжность, которую широта дать не может. Через всё это проходит принцип **Depth over Breadth** — глубина важнее широты: сфокусированный агент, делающий одно снова и снова, надёжнее широкого, который делает многое изредка. Поэтому и декомпозируют — не ради большего числа агентов, а чтобы каждый был достаточно узким, чтобы по-настоящему хорошо делать свой кусок. Если работа воркера всё ещё слишком широка, чтобы быть надёжной, ответ обычно — **разбить её дальше**, а не навалить больше инструментов. #### Depth over Breadth (глубина важнее широты) - **Что это:** Узкий агент, делающий одно, надёжнее широкого, делающего многое. - **Почему важно:** Это и есть смысл декомпозиции — не число агентов, а их узость. - **Пример:** Агент «исследуй и напиши отчёт» ошибается — делим на «исследуй» и «напиши». - **Подвох:** Лечить ненадёжного воркера новыми инструментами — это делает его шире, а не лучше. - **Связи:** Основа **Specialization** и **Worker Agent**. > **Вопрос воркера:** «Работа каждого агента достаточно узка, чтобы я мог протестировать его и доверять ему отдельно, — или какой-то воркер всё ещё делает слишком много, чтобы быть надёжным?» > Агенты-воркеры — узкие специалисты: одна ясная работа, сфокусированный промпт, мало инструментов, — поэтому каждого можно протестировать и ему доверять. Глубина в одной работе лучше широты во многих. ## 4. Передачи и контекст Агенты хороши ровно настолько, насколько хорошо то, что они передают друг другу. Как работа и контекст движутся между ними — чисто или неряшливо — решает, останется ли система связной или скатится в шум. ### Handoff — передача работы между агентами > Эстафетный бегун передаёт палочку: передача — это отдельный навык, и гонку выигрывает чистая передача, а не только быстрые бегуны. **Handoff** — передача — это момент, когда один агент передаёт работу другому: оркестратор воркеру или один агент сразу следующему. Передаётся **подзадача и контекст**, нужный, чтобы её сделать. На передачах случается много мультиагентных сбоев: если принимающий агент не получил нужного или получил мутную версию, его вывод будет неверным, каким бы хорошим ни был сам агент. Передача — полноценная часть дизайна, а не мелочь. _Diagram: Передача несёт подзадачу и контекст от агента A к агенту B. Мутная передача — неверный результат, даже у сильного B._ #### Handoff (передача работы между агентами) - **Что это:** Момент, когда работа и контекст переходят от одного агента к другому. - **Как работает:** Оркестратор → воркер или агент → следующий агент: подзадача плюс нужный для неё контекст. - **Пример:** Агент-исследователь передаёт агенту-писателю найденные факты и задание «напиши раздел». - **Подвох:** Отличный агент с плохим входом выдаёт плохой результат — винят агента, а виновата передача. - **Связи:** Делать как **Clean Handoff**; даёт **Context Isolation**; каждая передача — шаг в **Compounding Error**. ### Clean Handoff — передавай чистый, структурированный контекст, а не всё > Хороший брифинг даёт следующему человеку ровно то, что нужно для его задачи, — а не полный транскрипт всех прошлых разговоров, через который надо продираться. Соблазн — передать каждому агенту всю историю на данный момент. Но это воссоздаёт проблему переполненного контекста внутри каждого агента. Лучше практика **Clean Handoff** — чистая передача: дай принимающему агенту **сфокусированную, структурированную сводку** только того, что ему нужно, — относящиеся к делу факты и конкретную задачу, а не сырой поток всего подряд. Так контекст каждого агента остаётся компактным и сфокусированным — а ради этого разбиение и затевалось. _Diagram: Сверху: агенту B вываливают всю историю — он снова перегружен. Снизу: короткая сводка из фактов и задачи — контекст B чистый._ #### Clean Handoff (чистая передача, брифинг) - **Проблема:** Передача всей истории перегружает контекст следующего агента. - **Идея:** Передавать короткую структурированную сводку: нужные факты + конкретную задачу. - **Пример:** Вместо 40 ходов переписки — «факты: …; задача: напиши раздел о ценах, до 300 слов». - **Цена:** Кто-то должен решить, что важно, — можно случайно выкинуть нужное. - **Когда брать:** На каждой передаче, по умолчанию. - **Связи:** Правильный способ делать **Handoff**; именно он даёт **Context Isolation**. ### Context Isolation — у каждого агента свой чистый контекст > Отдельные рабочие комнаты, в каждой — только материалы для работы этой комнаты, поэтому никого не отвлекает и не путает бардак всех остальных задач. Настоящая польза мультиагентности — **Context Isolation**, изоляция контекста: каждый агент работает в своём чистом контексте и видит только то, что нужно его работе, а не накопленный бардак всей системы. Это одна из причин, почему разбиение может повысить надёжность: оно не даёт накопиться **гниению контекста** (context rot), как в одном долгоиграющем агенте. Но эту пользу ты получаешь, только если передачи дисциплинированы. Передай всё всем — и ты заново построил проблему одного перегруженного агента, только с лишними шагами. _Diagram: Три комнаты: в каждой агент видит только свою задачу и свои материалы. Отдай всё всем — и снова получишь одного перегруженного агента._ #### Context Isolation (изоляция контекста) - **Что это:** Каждый агент работает в своём чистом окне, где только его задача. - **Почему важно:** Нет гниения контекста, которое копится в одном долгоиграющем агенте. - **Пример:** Агент ревью видит только черновик и критерии, а не логи поиска и черновые попытки кода. - **Подвох:** Работает только при чистых передачах; «всё всем» её разрушает. - **Связи:** Ответ на **Context & Tool Overload**; держится на **Clean Handoff**. > **Вопрос передачи:** «На каждой передаче я даю чистую, сфокусированную сводку только того, что нужно следующему агенту, — или вываливаю всю историю и заново создаю проблему перегруженного контекста?» > Передачи переносят работу между агентами, и именно на них мультиагентность часто ломается. Передавай чистую, структурированную сводку только нужного, чтобы каждый агент сохранял сфокусированный контекст, ради которого и делили. ## 5. Последовательный, параллельный, иерархический Мультиагентные системы связывают в несколько повторяющихся форм. Знать три главные — и когда какая подходит — значит знать бо́льшую часть того, как устроить координацию. ### Sequential — конвейер этапов > Сборочная линия: каждая станция делает свою часть и передаёт изделие следующей, в фиксированном порядке, пока оно не выйдет готовым в конце. Паттерн **Sequential** — последовательный — выстраивает агентов в фиксированном порядке: вывод агента A кормит агента B, вывод B кормит агента C. Агент-черновик, потом агент-редактор, потом агент-фактчекер. Это самая простая и самая предсказуемая мультиагентная форма — идеальна, когда у работы есть естественные этапы, которые должны идти по порядку. По сути это **конвейер специалистов** (pipeline), и когда шаги фиксированы, он надёжнее цикла, который каждый раз заново решает порядок. _Diagram: Последовательный конвейер: черновик → редактура → проверка фактов. Порядок всегда один и тот же._ #### Sequential (последовательный, конвейер, pipeline) - **Проблема:** У работы есть этапы, которые должны идти строго по порядку. - **Идея:** Цепочка агентов: вывод одного — вход следующего. - **Пример:** Агент-черновик → агент-редактор → агент-фактчекер. - **Цена:** Медленнее параллельного; ошибка раннего этапа уходит дальше по цепочке. - **Когда брать:** Шаги фиксированы и зависят друг от друга. Самая простая форма. - **Связи:** Как **Pipe-and-Filter** из архитектурных паттернов; каждый стык — **Handoff**. ### Parallel — разойтись веером и собрать > Отправить один исследовательский вопрос нескольким ассистентам сразу, а потом собрать все их находки вместе — многие работают одновременно, результаты сводят в конце. Паттерн **Parallel** — параллельный — запускает несколько агентов одновременно на независимых кусках и потом собирает их результаты: сначала **fan-out** (раздать веером), затем **gather** (собрать). Исследовать пять подтем, обработать много элементов, получить несколько независимых мнений — всё это быстрее делать параллельно, чем по очереди. Оркестратор делит работу, воркеры бегут одновременно, результаты объединяются. Параллельный хорош, когда куски не зависят друг от друга и важна скорость. _Diagram: Fan-out: оркестратор раздаёт пять подтем, воркеры работают одновременно. Gather: результаты сводятся в один._ #### Parallel (параллельный, fan-out / gather) - **Проблема:** Много независимых кусков, и делать их по очереди слишком долго. - **Идея:** Раздать куски нескольким агентам сразу, потом собрать результаты. - **Пример:** Исследовать пять подтем параллельно и свести находки в один отчёт. - **Цена:** Больше вызовов модели за раз; сборка должна разрешать противоречия между результатами. - **Когда брать:** Куски не зависят друг от друга и важна скорость. - **Связи:** Последний шаг — **Assembly**; раздаёт и собирает **Orchestrator**. ### Hierarchical — оркестраторы оркестраторов > Оргструктура компании: руководитель управляет тимлидами, а каждый тимлид — своими людьми; координация вложена слоями для работы, которая слишком велика для одного уровня. Паттерн **Hierarchical** — иерархический — вкладывает координацию слоями: верхний оркестратор делегирует **суб-оркестраторам** (sub-orchestrators), а каждый из них управляет своими воркерами. Так решают по-настоящему большие и сложные задачи — разбивая их слоями, как это делает организация. Это самая мощная форма и самая сложная: больше координации, больше мест для сбоя. Поэтому тянись к ней, только когда задача правда настолько велика, что нужна вложенная декомпозиция. Большинству систем хватает последовательного или параллельного; иерархия — для немногих, кому не хватает. _Diagram: Верхний оркестратор управляет суб-оркестраторами, а те — своими воркерами. Три слоя координации._ #### Hierarchical (иерархический, вложенные оркестраторы) - **Проблема:** Задача так велика, что один оркестратор не может её разбить и удержать. - **Идея:** Верхний оркестратор делегирует суб-оркестраторам, у тех — свои воркеры. - **Пример:** Большое исследование: верхний агент делит на направления, у каждого направления свой координатор и свои исследователи. - **Цена:** Самая сложная форма: больше координации, больше мест для сбоя. - **Когда брать:** Только когда задача правда требует вложенной декомпозиции. Редко. - **Связи:** **Orchestrator**, вложенный в себя; внутри слоёв — **Sequential** или **Parallel**. > **Вопрос паттерна:** «Эта работа — фиксированный конвейер (sequential), независимые куски сразу (parallel) или вложенные слои координации (hierarchical)? И беру ли я самую простую форму, которая подходит?» > Sequential выстраивает агентов в фиксированный конвейер; parallel раздаёт независимую работу веером и собирает; hierarchical вкладывает оркестраторов для больших задач. Бери самую простую форму, которая правда нужна работе. ## 6. Умноженные режимы сбоя Мультиагентность соблазнительна, и её часто берут там, где не надо. Больше агентов не просто добавляют способности — они умножают способы, которыми система ломается. Игнорировать это — и есть то, как такие системы тихо падают. ### Compounding Error — больше шагов накапливают больше ошибок > Длинная эстафета с большим числом передач чаще роняет палочку — каждая лишняя передача это ещё одно место, где может провалиться весь забег. Это понятие **Compounding Error** — накапливающаяся ошибка. Один агент и так на длинной цепочке успешен лишь в части случаев (проблема надёжности из курса об агентах), а мультиагентность делает цепочку длиннее: больше агентов, больше передач, больше шагов — и каждый может ошибиться и передать ошибку дальше. **Надёжность перемножается вдоль цепочки**, поэтому добавление агентов может _понизить_ общую успешность, если каждый кусок и каждая передача не прочны. Больше агентов — это больше поверхности для накапливающегося сбоя, а не автоматически больше способностей. _Diagram: Условный пример: если каждый шаг успешен в 95% случаев, то цепочка из 10 шагов — лишь примерно в 60%._ #### Compounding Error (накапливающаяся ошибка) - **Что это:** Шансы на успех перемножаются по шагам, и длинная цепочка проваливается чаще. - **Почему важно:** Каждый новый агент и каждая передача — ещё один множитель меньше единицы. - **Пример:** 95% на шаг — это около 86% на трёх шагах и около 60% на десяти. - **Подвох:** Думать, что больше агентов — это всегда больше способностей. - **Связи:** Растёт с каждым **Handoff**; поэтому **Sequential** держат коротким, а **Hierarchical** берут редко. ### Coordination Overhead — у координации свои накладные расходы > Совещание, чтобы скоординировать пять команд, может стоить больше самой работы, — после какой-то точки координирование перевешивает делание. **Coordination Overhead** — накладные расходы координации. Каждый агент — это свои вызовы модели, своя задержка, своя стоимость, а оркестрация добавляет сверху ещё: **маршрутизацию, передачи, сборку, повторы**. Мультиагентная система может быть куда медленнее и дороже одного агента для той же задачи — и иногда ничуть не лучше. Если выигрыш специализации не перевешивает явно эту добавленную стоимость и задержку, лучшим инженерным выбором был более простой одиночный агент. _Diagram: Та же работа, но у мультиагентной версии сверху маршрутизация, передачи, сборка и повторы — больше задержки и денег._ #### Coordination Overhead (накладные расходы координации) - **Что это:** Лишние вызовы модели, задержка и деньги на маршрутизацию, передачи, сборку и повторы. - **Почему важно:** Система может стать медленнее и дороже одного агента — и не стать лучше. - **Пример:** Простой вопрос гоняют через оркестратор и трёх воркеров вместо одного вызова. - **Подвох:** Не мерить стоимость и задержку до и после разбиения. - **Связи:** Конкретная форма **Coordination Cost**; довод за **Single Agent by Default**. ### Multi-agent Tracing — мультиагентную систему труднее отследить и отладить > Отследить одну посылку легко; проследить сбой через сеть складов, грузовиков и передач — совсем другая и куда более трудная работа. Когда в мультиагентной системе что-то идёт не так, найти _где_ — куда труднее, чем в одном агенте: сбой мог случиться в любом воркере, в любой передаче или в самой оркестрации. Поэтому **наблюдаемость** (observability) становится обязательной — практика **Multi-agent Tracing**: трассировать запрос через всех агентов и **логировать каждую передачу**. Эта стоимость отладки — реальная часть цены. Систему, которую нельзя отследить, нельзя надёжно починить, а мультиагентность делает трассировку по-настоящему сложнее. _Diagram: Трасса одного запроса: оркестратор, передачи, агенты, сборка. Видно, что сломался именно агент кода._ #### Multi-agent Tracing (трассировка через агентов, observability) - **Что это:** Запись пути одного запроса через всех агентов и все передачи. - **Как делать:** Общий ID запроса, лог каждой передачи (что отдали, что получили), время и стоимость каждого шага. - **Пример:** Ответ неверный — по трассе видно, что агент кода получил неполный контекст на передаче. - **Подвох:** Без трассы сбой «где-то в системе» — и починить его наугад почти невозможно. - **Связи:** Отладка **Coordination Layer**; вместе с **Per-agent Evals** показывает, кто виноват. > **Вопрос стоимости:** «Выигрыш специализации здесь явно перевешивает умноженную цену — больше шагов с накапливающейся ошибкой, больше задержки и трат, труднее трассировка, — или я добавляю агентов по привычке?» > Больше агентов умножают режимы сбоя: больше шагов, где копится ошибка, реальные накладные расходы координации и куда более трудная трассировка. Мультиагентность «по привычке» понижает надёжность, а не повышает. ## 7. Применять хорошо Мультиагентность — мощный инструмент для правильной задачи и дорогая ошибка для неправильной. Применять её хорошо — это в основном сдержанность: разбивать, только когда один агент правда не справляется. ### Single Agent by Default — разбивай, только когда один агент правда не справляется > Ты не созываешь комитет, чтобы ответить на простой вопрос, — команду зовут, только когда работа правда слишком велика для одного толкового человека. Принцип **Single Agent by Default** — по умолчанию один агент. Дефолтом должен быть **один агент**, а к мультиагентности тянутся, только когда он правда не справляется: слишком много разных навыков, слишком много инструментов, слишком много контекста, чтобы удержать его связно. Если один хорошо построенный агент может это сделать, мультиагентная версия просто добавляет стоимость, задержку и режимы сбоя без выигрыша. Вопрос никогда не «могу ли я это разбить?» — разбить можно почти что угодно, — а «один агент здесь правда не дотягивает?». _Diagram: Сначала — один агент. Не справляется — сузь инструменты и почисти контекст. Только если и это не помогло — мультиагентность._ #### Single Agent by Default (по умолчанию — один агент) - **Что это:** Начинать с одного агента и разбивать, только когда он правда не тянет. - **Почему важно:** Лишние агенты добавляют стоимость, задержку и режимы сбоя без выигрыша. - **Пример:** Агент путается в 20 инструментах — сначала оставь ему 5 нужных, и только потом думай о разбиении. - **Подвох:** Спрашивать «можно ли разбить?» — можно почти всё. - **Связи:** Противовес **Coordination Overhead** и **Compounding Error**; выход к **Orchestrator** — только когда правда нужно. ### Держи каждого агента узким и каждую передачу чистой > У хорошо слаженной бригады чётко определены роли и отрепетированы передачи — надёжной её делает структура, а не героизм. Когда всё же идёшь в мультиагентность, две дисциплины заставляют её работать: держи каждого воркера **узким** (одна ясная работа, мало инструментов, тестируется отдельно) и каждую передачу **чистой** (сфокусированная сводка только нужного, а не вся история). Большинство мультиагентных сбоев сводятся к воркеру, который слишком широк, или к передаче, которая слишком мутна. Сделай эти две вещи правильно, добавь ясный оркестратор и самый простой подходящий паттерн — и система остаётся надёжной, когда растёт. #### Прежде чем идти в мультиагентность - **Может ли один агент на деле это сделать** — или он правда ломается под нагрузкой? - **Есть ли ясный оркестратор**, который разбивает, распределяет и собирает? - **Узок ли каждый воркер** — одна работа, мало инструментов, тестируется отдельно? - **Чисты ли передачи** — сфокусированная сводка, а не вся история целиком? - **Какой паттерн подходит** — последовательный, параллельный или иерархический — и самый ли он простой из рабочих? - **Перевешивает ли выигрыш цену** — больше шагов, задержки, трат и труднее трассировка? #### Признаки, что ты оркеструешь хорошо - Ты берёшь мультиагентность, **только когда один агент правда не справляется**. - Ясный **оркестратор** разбивает, распределяет и собирает работу. - Каждый **воркер узок** — его можно протестировать и ему можно доверять отдельно. - **Передачи чистые**: передают сфокусированный контекст и держат окно каждого агента компактным. - Ты берёшь **самый простой паттерн**, что подходит, и можешь **отследить** сбой через агентов. ### Как всё связано > Схема метро целиком: теперь видно, где линии пересекаются. Начинаешь с **одного агента**. Не справляется — появляется **оркестратор**: он выбирает **паттерн** (sequential, parallel или hierarchical) и раздаёт работу **узким воркерам** через **чистые передачи**, а потом собирает результаты. Каждый агент и каждая передача добавляют **накладные расходы** и **накапливающуюся ошибку** — если выигрыш меньше цены, возвращайся к одному агенту. А **трассировка** показывает, где именно всё сломалось. _Diagram: Цепочка понятий курса: от одного агента к оркестратору, паттерну, передачам и воркерам — и цена, которая тянет обратно к одному агенту._ ## Шпаргалка: все 19 понятий ### Зачем разбивать - **Specialization** (специализация): Узкие агенты, каждый делает одно хорошо, — главная причина мультиагентности. - **Context & Tool Overload** (перегрузка контекстом и инструментами): Окно одного агента переполнено, меню инструментов слишком длинное. - **Coordination Cost** (цена координации): Разбить, распределить, передать, собрать — это стоит и должно окупаться. ### Оркестратор - **Orchestrator** (оркестратор, координатор): Главный агент делит цель на подзадачи и отдаёт их воркерам. - **Assembly** (сборка, синтез): Собрать ответы воркеров в один результат: снять противоречия, убрать дубли. - **Coordination Layer** (слой координации): Кто запускается когда, с каким входом и как сводятся результаты — настоящая архитектура. ### Воркеры - **Worker Agent** (агент-воркер): Одна узкая работа, короткий промпт, мало инструментов. - **Per-agent Evals** (эвалы на каждого агента): Тесты на каждого воркера отдельно — видно, кто ошибся, чинишь изолированно. - **Depth over Breadth** (глубина важнее широты): Слишком широкий воркер — дели дальше, а не добавляй инструменты. ### Передачи - **Handoff** (передача): Момент, когда подзадача и контекст переходят от агента к агенту. - **Clean Handoff** (чистая передача): Короткая сводка: нужные факты + задача, а не вся история. - **Context Isolation** (изоляция контекста): У каждого агента своё чистое окно — без гниения контекста. ### Паттерны - **Sequential** (последовательный, конвейер): A → B → C в фиксированном порядке. Самый простой и предсказуемый. - **Parallel** (fan-out / gather): Независимые куски одновременно, потом сбор. Ради скорости. - **Hierarchical** (иерархический): Оркестраторы оркестраторов. Самый мощный и самый сложный — редко. ### Режимы сбоя - **Compounding Error** (накапливающаяся ошибка): Успех перемножается по шагам: больше агентов — длиннее цепочка — чаще провал. - **Coordination Overhead** (накладные расходы): Маршрутизация, передачи, сборка, повторы — больше задержки и денег. - **Multi-agent Tracing** (трассировка через агентов): Логировать каждую передачу, чтобы найти, где именно сломалось. ### Практика - **Single Agent by Default** (по умолчанию — один агент): Разбивай, только когда один хорошо построенный агент правда не справляется. > Мультиагентность — это осознанный выбор: разбивай, только когда один агент правда не справляется, дай системе ясный оркестратор, держи каждого воркера узким и каждую передачу чистой и бери самый простой паттерн — потому что каждый добавленный агент умножает и стоимость, и режимы сбоя. Конец экспресс-курса · 7 глав · 19 понятий Дальше — практика: возьми задачу, которую тянет разбить на агентов, и сначала попробуй заставить её сделать одного хорошо построенного агента — сузь ему инструменты, почисти контекст. Если он правда не справляется, разбей: ясный оркестратор, два-три узких воркера, чистые передачи, самый простой подходящий паттерн. Потом проследи один прогон от начала до конца и посмотри, где на самом деле оседают стоимость и ошибки. Дисциплина щёлкает в тот момент, когда ты чувствуешь, сколько стоит координация, и бережёшь её для случаев, где специализация правда окупается. Но держи одну мысль выше остальных: больше агентов умножают и способности, и режимы сбоя. Разбивай, только когда одного агента мало, — а когда разбиваешь, вся игра в структуре вокруг них.