Практика. Координатор и передача управления¶

1. Почему этот выбор вообще важен¶

Как только команда доходит до многоагентной темы, почти сразу появляется соблазн сделать "красивую" схему:

• один агент планирует;
• другой ищет;
• третий пишет;
• четвертый проверяет;
• и все это выглядит очень впечатляюще на диаграмме.

Проблема в том, что между красивой диаграммой и устойчивой системой лежит большая разница.

На практике один из самых полезных вопросов звучит так:

Нам здесь нужен паттерн координатора или передача управления?

Это не эстетический вопрос. Это вопрос:

• кто держит глобальный контекст;
• где живет ответственность за следующий шаг;
• как ограничивать радиус поражения;
• как потом расследовать сбои.

Практический гайд OpenAI полезен здесь тем, что рекомендует не романтизировать многоагентность по умолчанию, а сначала понять, где на самом деле живет координация и где должна жить ответственность.¹

2. Что такое паттерн координатора¶

manager pattern означает, что у тебя есть один центральный координатор, который:

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

Это похоже на модель "менеджер вызывает специалистов как инструменты".

Плюсы паттерна координатора:

• единая точка контроля;
• проще держать глобальную политику;
• удобнее вести журнал аудита;
• легче ограничивать бюджет и максимальное число шагов.

Минусы:

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

3. Что такое передача управления¶

handoff pattern означает, что текущий агент может передать управление другому агенту, и тот уже временно становится "главным" для своей части задачи.

Это ближе к модели "задача переходит к следующему ответственному".

Плюсы передачи управления:

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

Минусы:

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

4. Самый полезный практический принцип¶

Если коротко, то:

• паттерн координатора лучше, когда тебе нужен единый координационный центр;
• передача управления лучше, когда задача естественно переходит между разными ролями или доменами.

То есть вопрос не "что современнее", а "где у нас должна жить ответственность".

5. Когда паттерн координатора почти всегда уместен¶

Паттерн координатора обычно хорошо работает, если:

• задача короткая или средняя по длине;
• нужен единый контроль бюджета;
• инструменты и политика почти одинаковы для всех подзадач;
• команда хочет максимальную объяснимость;
• есть один основной владелец рантайма.

Типичные примеры:

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

Здесь паттерн координатора часто оказывается самым скучным и самым правильным решением.

6. Когда передача управления лучше¶

Передача управления обычно выигрывает, если:

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

Типичные примеры:

• квалификация продажи -> агент решения -> агент юридической проверки;
• прием инцидента -> расследование безопасности -> координатор устранения;
• онбординг, где этапы принадлежат разным бизнес-подразделениям.

Тут передача управления часто естественнее, чем центральный координатор, который делает вид, что одинаково хорошо понимает все.

7. Частые ошибки¶

У обеих схем есть типовые режимы отказа.

У паттерна координатора:

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

У передач управления:

• теряются ограничения и намерение при передаче;
• следующий агент получает слишком мало или слишком много состояния;
• неясно, кто отвечает за итоговый результат;
• трасса становится рваной и трудной для чтения.

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

8. Простая таблица решений¶

Ниже хороший стартовый ориентир.

Эта таблица не заменяет дизайн, но очень хорошо снимает часть лишней романтики.

9. Как не ошибиться слишком рано¶

Самая здоровая стратегия обычно выглядит так:

1. сначала одноагентный цикл;
2. потом паттерн координатора, если нужна координация нескольких специализированных путей;
3. и только потом передача управления, если уже видны реальные границы доменов.

Это не догма. Но это хорошая защита от преждевременной сложности.

10. Кодовый эскиз: паттерн координатора¶

def run_manager(task: str, specialists: dict[str, callable]) -> dict:
    plan = ["research", "draft", "review"]
    results: dict[str, dict] = {}

    for step in plan:
        worker = specialists[step]
        results[step] = worker(task=task, prior_results=results)

    return {"status": "success", "results": results}

Здесь координатор не "умничает" бесконечно. Он держит план, вызывает специалистов и собирает результат.

11. Кодовый эскиз: передача управления¶

def handoff(state: dict, next_agent: callable) -> dict:
    transfer_packet = {
        "goal": state["goal"],
        "constraints": state["constraints"],
        "relevant_context": state["relevant_context"],
    }
    return next_agent(transfer_packet)

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

12. Что особенно важно для безопасности¶

Если ты используешь паттерн координатора, проверь:

• не получает ли координатор слишком широкие права;
• не обходит ли он границу подтверждения "от имени всех";
• не становится ли он точкой, через которую утекут все контексты арендаторов.

Если ты используешь передачу управления, проверь:

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

То есть безопасность здесь не "поверх оркестрации". Она часть самой семантики оркестрации.

13. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

• Кто владеет глобальной целью запуска?
• Кто отвечает за итоговый результат?
• Где живет контроль бюджета?
• Где живут условия остановки?
• Можно ли из трасс понять, кто кому передал задачу и почему?
• Не слишком ли рано ты ушел в передачи управления, когда паттерн координатора был бы проще?
• Не стал ли координатор центральным монстром, который делает все сразу?

Если ответы мутные, значит схема пока архитектурно не дозрела.

14. Что делать дальше¶

• Практика. Инструкции, сценарии и шаблоны запросов
• Глава 2. Референсная архитектура безопасного агента
• Часть IV. Инструменты и выполнение
• Источники