Паттерны передачи управления агентов: маршрутизация задач между агентами ИИ

Паттерны передачи управления агентов — это протоколы, по которым один агент ИИ передаёт задачу, накопленный контекст и права на выполнение другому агенту. Они определяют, какие данные пересекают границу, что отбрасывается и передаются ли учётные данные вместе с задачей. Большинство сбоев при передаче управления — это не ошибки маршрутизации, а потери контекста или утечки учётных данных, которые обнаруживаются лишь тогда, когда нижестоящий агент молча даёт сбой или скомпрометированный агент похищает чувствительные данные полезной нагрузки.

Паттерн передачи управления агентов — это паттерн проектирования программного обеспечения, который определяет, как автономный агент ИИ делегирует задачу коллеге или специализированному агенту, задавая контракт данных для передачи контекста, механизм маршрутизации для доставки задачи и гарантии изоляции, предотвращающие утечку учётных данных или контекста между агентами.

Четыре канонических паттерна передачи управления

Push-передача: вызывающий напрямую будит вызываемого

При push-передаче вызывающий агент строит полезную нагрузку с контекстом задачи и напрямую уведомляет принимающего агента — как правило, через вызов функции, отправку сообщения или вызов API, который пробуждает вызываемого. Вызывающий точно контролирует, какие данные получает вызываемый, когда их получает и какой агент обрабатывает задачу.

Push-передача — это паттерн, используемый примитивом handoff() OpenAI Agents SDK (27 133 звезды на GitHub, MIT). Вызывающий опционально может передать функцию input_filter, которая удаляет или преобразует поля контекста перед передачей. Без input_filter вызываемому передаётся полное контекстное окно, включая любое накопленное чувствительное содержимое.

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

Pull-диспетчеризация: вызываемый забирает из общей очереди

При pull-диспетчеризации вызывающий агент записывает задачу в общую очередь или входящие сообщения, не уведомляя напрямую конкретного агента. Агенты-вызываемые отслеживают очередь и забирают задачи, соответствующие их возможностям. Это позволяет распределять нагрузку по пулу воркеров и отделяет вызывающего от знания о том, какой конкретный агент выполнит работу.

Pull-диспетчеризация снижает риск раскрытия учётных данных: сообщение очереди содержит только описание задачи и указатель ключа вывода, а не полный контекст вызывающего.

Достоинства: горизонтальное масштабирование, слабая связь, естественное балансирование нагрузки.
Риски: глубина очереди под нагрузкой может расти неограниченно; гарантии порядка задач зависят от семантики очереди.

Маршрутизация через доску объявлений: изоляция контекста через указатель

При передаче управления через указатель на доску объявлений вызывающий записывает свой вывод в именованный ключ на общем постоянном хранилище, например output/researcher/task_abc123, и отправляет вызываемому только имя ключа. Вызываемый читает ключ и извлекает именно те поля, которые ему нужны. Исходные учётные данные, промежуточное содержимое черновиков и полный контекст вызывающего никогда не появляются в сообщении о передаче управления.

Функция hand_off() OpenLegion реализует этот паттерн нативно: записывает данные вывода в output/{agent_id}/{handoff_id} на доске объявлений, создаёт запись задачи во входящих получателя с указателем на этот ключ и пробуждает получателя. Учётные данные, хранящиеся в Vault, инжектируются мешем во время выполнения.

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

Потоковая передача: поэтапная передача контекста

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

Потоковая передача несёт наибольший риск раскрытия учётных данных: поток может содержать чувствительное содержимое, созданное в середине рассуждений до того, как вызывающий успел его отфильтровать.

Достоинства: наименьшая сквозная задержка, совместная работа нескольких агентов в реальном времени.
Риски: труднее всего защитить, сложнее всего наблюдать, требует от вызываемого корректной обработки частичного контекста.

Позиция OpenLegion: почему потеря контекста и утечки учётных данных — настоящие ошибки передачи управления

Большинство сбоев при передаче управления в мультиагентных системах делятся на две категории: ошибки потери контекста и ошибки утечки учётных данных. Оба вида можно предотвратить на уровне проектирования.

Цифры потери контекста: оценки сжатия контекста LLM неизменно показывают, что простое усечение на границе передачи управления снижает показатели выполнения задач при многошаговых рассуждениях по сравнению со структурированным резюмированием. Решение — не большее контекстное окно, а структурированная полезная нагрузка с явными полями для выполненной работы, оставшейся работы и ключевых находок.

Утечка учётных данных: OWASP LLM06:2025 (Раскрытие конфиденциальной информации) прямо относит похищение учётных данных через передачу сообщений между агентами к десяти главным уязвимостям LLM.

Проблема потери контекста: что теряется на границе

Коренная причина потери контекста — расхождение между тем, что знает вызывающий агент, и тем, что передаёт полезная нагрузка. Структурированные полезные нагрузки предотвращают это: вызывающий явно заполняет поля: цель задачи, выполненная работа, незавершённые подзадачи, ключевые находки и указатель ключа вывода.

Похищение учётных данных через полезные нагрузки (OWASP LLM06:2025)

transfer_to_agent() Google ADK передаёт полный объект Session, включая историю разговора, принимающему агенту, создавая передачу контекста до 32K токенов по умолчанию. Командам необходимо проверять свои реализации передачи управления на соответствие безопасности агентов ИИ: изоляция учётных данных и защита от инъекций подсказок.

Паттерн указателя на доску объявлений как безопасный вариант по умолчанию

Паттерн указателя на доску объявлений устраняет раскрытие учётных данных на уровне протокола, а не полагается на фильтрацию на уровне приложения. Учётные данные, хранящиеся в Vault OpenLegion, никогда не инжектируются в контекст агента.

Как крупные фреймворки реализуют передачу управления

OpenAI Agents SDK: handoff() с input_filter (27 133 звезды)

openai/openai-agents-python (27 133 звезды на GitHub, лицензия MIT) реализует handoff() как push-паттерн. Параметр input_filter добавлен в v0.0.5 (март 2025) и требует явного включения.

from agents import Agent, handoff, RunContextWrapper

def strip_credentials(ctx: RunContextWrapper, input_data: ResearchInput) -> ResearchInput:
    return ResearchInput(task=input_data.task, context=input_data.context)

researcher = Agent(
    name="researcher",
    handoffs=[handoff(writer_agent, input_filter=strip_credentials)]
)

Google ADK: transfer_to_agent() и передача объекта Session (20 100 звёзд)

google/adk-python (20 100 звёзд на GitHub, Apache-2.0) реализует передачу управления через transfer_to_agent(), который передаёт полный объект Session, включая историю разговора. Принимающий агент получает всё и должен явно отбрасывать нерелевантную историю.

LangGraph: Command(goto=) с общим типизированным состоянием

LangGraph (langchain-ai/langgraph, Apache-2.0) реализует маршрутизацию агентов через Command(goto='имя_узла') с необязательными обновлениями состояния. Состояние — это типизированный словарь, общий для всех узлов графа. Модель общего состояния LangGraph не обеспечивает изоляцию учётных данных между узлами.

from langgraph.types import Command

def researcher_node(state: AgentState) -> Command:
    result = researcher.invoke(state)
    return Command(
        goto="writer",
        update={"research_output": result, "completed_steps": state["completed_steps"] + ["research"]}
    )

OpenLegion: hand_off() с указателем на доску объявлений и доставкой во входящие

Функция hand_off() OpenLegion нативно реализует передачу через указатель на доску объявлений.

hand_off(
    to="writer",
    summary="Исследование завершено: langchain-alternative, 2847 слов исходного материала",
    data='{"topic": "langchain-alternative", "sources_key": "research/langchain-alt-sources", "word_count_target": 3000}'
)

Контракты данных при передаче управления

Что включать: резюме задачи, ключ вывода, релевантная история

Хорошо спроектированная полезная нагрузка — это структурированная спецификация, а не дамп транскрипта. Включать:

Резюме задачи (до 200 слов): что вызываемый должен выполнить
Указатель ключа вывода: ключ доски объявлений, где хранится вывод вызывающего
Резюме выполненной работы: что уже сделано, изложено как факты, а не разговор
Незавершённые подзадачи: конкретные элементы, за которые отвечает вызываемый
Структурированные параметры: любые типизированные входные данные, требуемые задачей вызываемого

Что исключать: исходные учётные данные, полные контекстные окна, промежуточные черновики

Исключать из полезных нагрузок:

Ключи API, токены и учётные данные: должны инжектироваться мешем во время выполнения
Полные транскрипты разговоров: усечь до релевантных резюме
Промежуточные черновики рассуждений: цепочка мыслей вызывающего не полезна вызываемому
Данные, не требуемые ролью вызываемого: применять принцип минимальных привилегий и к контексту

Механизмы маршрутизации передачи управления

Статическая маршрутизация: жёстко закодированные идентификаторы агентов

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

Динамическая маршрутизация: специалист, выбранный LLM

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

Условная маршрутизация: эскалация на основе правил

Условная маршрутизация применяет детерминированные правила для выбора целевого агента. Более предсказуема, чем маршрутизация через LLM, но требует явного определения правил для каждого условия маршрутизации.

Обработка откатов и тайм-аутов

Каждая передача управления должна определять, что происходит, если вызываемый не отвечает в течение тайм-аута. Варианты:

Повторить с тем же вызываемым: уместно, когда сбой, вероятно, временный
Перенаправить к альтернативному агенту: уместно, когда основной вызываемый постоянно недоступен
Эскалировать оператору: уместно, когда задача требует человеческого суждения
Записать сбой на доску объявлений и продолжить: уместно, когда нижестоящая задача необязательна

Сравнение паттернов по безопасности и надёжности

Измерение	Push-передача	Pull-диспетчеризация	Маршрутизация через доску	Потоковая передача
Механизм маршрутизации	Прямой вызов пробуждения вызываемого	Общая очередь/получение из входящих	Запись ключа+наблюдение вызываемого	Поэтапный поток токенов
Изоляция контекста	Вызывающий контролирует нагрузку; input_filter обязателен	Только сообщение очереди	Наивысшая: вызываемый читает только именованный ключ	Наименьшая: полный контекст пересекает границу
Риск раскрытия учётных данных	Средний: зависит от включения input_filter	Низкий: очередь содержит только указатель на задачу	Очень низкий: учётные данные никогда не в нагрузке	Высокий: поток может содержать чувствительный контекст
Наблюдаемость	Одно событие трассировки на передачу	Глубина очереди+события получения	История версий ключа+события входящих	Требуется трассировка на уровне токенов
Задержка	Наименьшая	Низкая (накладные расходы чтения очереди)	Низкая (накладные расходы чтения доски)	Наименьшая сквозная (потоковая)
Оптимально для	Тесно связанного делегирования специалисту	Пулов воркеров с балансировкой нагрузки	Асинхронных развязанных конвейеров	Совместной работы в реальном времени

Часто задаваемые вопросы

Что такое паттерн передачи управления агентов?

Паттерн передачи управления агентов — это протокол передачи задачи от одного агента ИИ другому, определяющий, какие данные контекста пересекают границу, как уведомляется принимающий агент и какие гарантии изоляции предотвращают утечки учётных данных или памяти. Четыре канонических паттерна: push-передача, pull-диспетчеризация, маршрутизация через указатель на доску объявлений и потоковая передача — каждый с различными компромиссами в области безопасности, задержки и наблюдаемости.

Как OpenAI Agents SDK реализует передачу управления?

OpenAI Agents SDK (27 133 звезды на GitHub, MIT) реализует handoff() как push-паттерн. Вызывающий агент вызывает handoff() с целевым агентом и необязательной функцией input_filter, которая удаляет поля из контекста перед передачей. Параметр input_filter добавлен в v0.0.5 (март 2025) и требует явного включения; без него полное контекстное окно передаётся вызываемому.

Как Google ADK реализует передачу управления агентов?

Google ADK (20 100 звёзд на GitHub, Apache-2.0) использует transfer_to_agent(), который передаёт полный объект Session, включая историю разговора, принимающему агенту. По умолчанию создаётся передача контекста до 32K токенов. Принимающий агент получает полную историю и должен явно отбросить нерелевантный предыдущий контекст.

Что такое паттерн передачи через указатель на доску объявлений и почему он безопаснее?

При передаче через указатель на доску объявлений вызывающий записывает вывод в именованный ключ общего хранилища (например, output/agent-id/task-id), затем отправляет вызываемому только указатель на ключ, а не сами данные. Вызываемый читает только нужные ему поля. Учётные данные никогда не появляются в сообщении о передаче, что устраняет вектор похищения OWASP LLM06:2025. Функция hand_off() OpenLegion реализует этот паттерн нативно.

Какие риски безопасности существуют при передаче управления агентов?

Основной риск — похищение учётных данных: фреймворки, включающие переменные среды, токены носителя или ключи API в объект контекста, передаваемый при передаче управления, раскрывают их принимающему агенту, который может быть скомпрометирован. OWASP LLM06:2025 определяет это как уязвимость в топ-10 LLM. Вторичный риск — отравление контекста.

Как обрабатывать сбои передачи управления и тайм-ауты?

Надёжные конвейеры передачи управления определяют тайм-аут и резервный путь: повтор с тем же вызываемым, перенаправление к альтернативному специалисту, эскалация оператору-человеку или запись сбоя на доску объявлений. Вызывающий агент должен отслеживать идентификаторы передачи и отслеживать события завершения задач.

Какие данные включать в полезную нагрузку передачи управления?

Включать: краткое резюме задачи (до 200 слов), указатель на ключ выходных данных в общем хранилище, факты о выполненной работе, незавершённые подзадачи и структурированные параметры, требуемые ролью вызываемого. Исключать: исходные учётные данные API, полные транскрипты разговоров, промежуточные черновики рассуждений и любые данные, не требуемые ролью вызываемого.

Безопасная передача управления агентов в OpenLegion

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

Передача управления через указатель на доску объявлений в OpenLegion решает обе проблемы на уровне протокола. hand_off() записывает вывод в именованный ключ, доставляет только указатель во входящие получателя и использует инъекцию учётных данных через прокси Vault. Получатель читает с доски объявлений ровно то, что ему нужно, не более.

Для уровня мониторинга, который выявляет сбои, пропущенные протоколом передачи, см. наблюдаемость агентов: трассировка передач управления между этапами конвейера. Для уровня фреймворка, который определяет выбор паттерна, см. сравнение фреймворков агентов ИИ для производственных развёртываний.

Создать безопасные мультиагентные конвейеры на OpenLegion →