Оркестрация: координатор–субагент (hub-and-spoke), пайплайны

Зачем дробить на несколько агентов

Один агент с десятком инструментов и огромным системным промптом быстро деградирует: он путается в ролях, забивает контекст и хуже выбирает действия. Решение — разделение ответственности: вместо одного «универсала» собрать несколько узких агентов, каждый со своим промптом, своим набором инструментов и своей зоной компетенции.

Это та же идея, что и в коде: маленькие модули с чёткими интерфейсами надёжнее одного гигантского. У узкого субагента короче промпт, меньше инструментов — значит, выше точность и ниже стоимость отдельного шага. Но за разбиение приходится платить координацией: кто-то должен решать, кого и когда звать.

Hub-and-spoke: координатор и субагенты

Самый распространённый паттерн — координатор–субагент (hub-and-spoke, «звезда»). В центре — агент-координатор (orchestrator): он видит задачу целиком, разбивает её и поручает части специализированным субагентам, а затем собирает их результаты в общий ответ. Субагенты не общаются между собой напрямую — всё идёт через координатора (отсюда «звезда»).

Технически субагент удобно представить координатору как инструмент: «вызови research_agent с подзадачей X». Тогда координатор — это обычный агентный цикл из Модуля 1, просто его «инструменты» — это запуски других агентов. Плюсы: понятный контроль, изоляция контекста (каждый субагент получает только нужное). Минус: координатор — узкое место и точка отказа.

Пайплайны и выбор топологии

Не всё требует динамического координатора. Если шаги известны и идут по порядку — это пайплайн (prompt chaining): выход одного агента/шага становится входом следующего (черновик → редактура → проверка фактов). Маршрут фиксирован в коде, между шагами удобно ставить программные проверки (gate). Это надёжнее и дешевле динамической оркестрации (подробнее — урок 3.2).

Как выбрать топологию? Простое правило: берите минимально сложную, которая решает задачу. - Один агент — пока хватает. - Пайплайн — когда шаги предсказуемы и последовательны. - Hub-and-spoke — когда состав подзадач определяется на лету.

Мультиагентность мощна, но добавляет задержку, стоимость и точки отказа. Не вводите координатора там, где достаточно цепочки.

Субагент как инструмент координатора (hub-and-spoke)

// Субагент — это функция «вход-задача → строковый результат».
type SubAgent func(task string) (string, error)

// Координатор знает субагентов по имени и зовёт их как инструменты.
func dispatchSub(subs map[string]SubAgent, name, argsJSON string) string {
    sub, ok := subs[name]
    if !ok {
        return "нет такого субагента: " + name
    }
    var a struct{ Task string }
    if err := json.Unmarshal([]byte(argsJSON), &a); err != nil {
        return "ошибка аргументов: " + err.Error()
    }
    res, err := sub(a.Task) // каждый субагент — свой промпт и свои инструменты
    if err != nil {
        return "субагент " + name + " вернул ошибку: " + err.Error()
    }
    return res
}

// Координатор — обычный агентный цикл (Модуль 1), где "инструменты" — субагенты:
//   research_agent(task), writer_agent(task), critic_agent(task) ...

Anti-patterns

Анти-паттерн	Почему плохо	Как правильно
Один агент на всё с 20 инструментами	Путается в ролях, забивает контекст, ошибается	Узкие субагенты с чётким разделением ответственности
Вводить координатора, где хватит пайплайна	Лишняя задержка, стоимость, точки отказа	Минимально сложная топология: один агент → пайплайн → hub-and-spoke
Субагенты ходят друг к другу напрямую	Хаос связей, трудно отлаживать	Hub-and-spoke: всё через координатора
Координатор передаёт субагенту всю историю	Раздувает контекст, теряется фокус	Передавать только подзадачу и нужный минимум контекста

Практическое задание

Возьмите задачу из 2–3 разнородных частей (например, «найди факты → напиши черновик → проверь»).
Опишите для координатора каждого субагента как инструмент name(task) с понятным описанием.
Реализуйте субагентов как отдельные агентные циклы со своими промптами и инструментами.
Передавайте субагенту только подзадачу, а не всю историю координатора.
Сравните: решилась бы эта задача проще пайплайном без координатора? Обоснуйте выбор топологии.

Проверка знаний

Что характерно для топологии hub-and-spoke?

A Все агенты общаются каждый с каждым напрямую
B Центральный координатор раздаёт подзадачи субагентам и собирает результаты; субагенты не связаны напрямую
C Это один агент без подзадач
D Агенты выстроены в строгую неизменную цепочку

Как удобнее всего представить субагента координатору?

A Как инструмент: координатор «вызывает» субагента с подзадачей и получает результат
B Копировать код субагента в промпт координатора
C Через общую глобальную переменную
D Никак — субагенты должны работать сами по себе

Задача состоит из фиксированной последовательности: перевести текст → проверить терминологию → отформатировать. Состав шагов не меняется.

Какая топология уместнее?