Как работает agent handover (передача задачи другому агенту)?

Краткий тезис

Agent handover — это механизм, с помощью которого один агент (Agent A) передаёт текущую задачу другому агенту (Agent B), когда первый не может её выполнить (например, из-за нехватки инструментов, специализации или прав доступа). Handover включает формирование запроса с состоянием, маршрутизацию к подходящему агенту, передачу контекста и продолжение выполнения. Этот подход лежит в основе масштабируемых multi-agent систем, где агенты специализируются на разных доменах.

1. Термин: Agent Handover (передача задачи)

Agent handover — это процесс делегирования задачи от одного агента другому с сохранением состояния выполнения (state) и контекста диалога.

Почему это нужно:

• Один агент не может охватить все домены (графика, юриспруденция, код, аналитика).
• Некоторые задачи требуют специализированных инструментов или доступа к закрытым данным.
• Повышает robustness (отказоустойчивость) системы: при отказе одного агента другой может подхватить.
• Улучшает user experience: пользователь не замечает переключения, если handover прозрачен.

Термин «Handover» заимствован из телекоммуникаций (передача соединения от одной базовой станции к другой). В контексте AI-агентов handover — это передача «логического управления» задачей.

2. Архитектура handover: ключевые компоненты

Handover обычно реализуется через центральный Router (маршрутизатор) или Supervisor по принципу orchestrator pattern.

Пример потока:

1. Agent A получает запрос «Нарисуй диаграмму архитектуры и напиши контракт».
2. Agent A выполняет первую часть (диаграмма), но не имеет инструментов для юридического документа.
3. Agent A формирует handover request с результатами (описание диаграммы, ключевые требования) и вызывает Router.
4. Router по анализу запроса направляет задачу Agent B (legal agent).
5. Agent B получает контекст, достраивает недостающую информацию, генерирует контракт и возвращает полный ответ пользователю.

3. Типы handover: явный vs неявный, статический vs динамический

3.1 Явный handover (explicit)

Agent A сам решает, что не может выполнить задачу, и отправляет scripted-запрос к Router. Пример: «Я не могу выполнить это. Передаю задачу агенту поддержки.»
Плюсы простота, предсказуемость.
Минусы жёсткая логика, нет адаптации.

3.2 Неявный handover (implicit)

Router автоматически анализирует намерение (intent) запроса и перенаправляет, агенты не принимают решение.
Пример: Router смотрит embedding запроса → находит группу агентов → выбирает самого релевантного.
Плюсы гибкость, нет необходимости программировать условия в каждом агенте.
Минусы сложнее в реализации, возможны ошибки маршрутизации.

3.3 Статический handover (rule-based)

Router использует жёсткие правила: если запрос содержит «договор» → legal agent.
Инструменты if-else, decision tree, intent classification с помощью regex или lightweight ML-модели.

3.4 Динамический handover (LLM-based)

Router использует LLM-рассуждение (reasoning) для выбора агента.
Пример: supervisor-agent вызывает LLM с инструкцией: «Определи, какой агент подходит: графический агент (id=1), юридический (id=2), или аналитический (id=3)». LLM возвращает id или подсказку.
Плюсы адаптация к нестандартным запросам.
Минусы latency, стоимость, может be hallucinate.

4. Механизм передачи состояния (State Transfer)

Ключевая сложность handover — корректно передать состояние задачи, чтобы Agent B мог продолжить без повторов и потери данных.

Что должно быть передано:

• Исходный запрос пользователя (user utterance).
• Промежуточные результаты Agent A (например, сгенерированный код, текст, изображения).
• История диалога (полный лог сообщений).
• Контекстные данные (извлечённые сущности, настроенные параметры).
• Счётчики (количество попыток, оставшись лимит токенов).

Форматы передачи:

• JSON-структура с полями: user_query, intermediate_output, conversation_history, metadata.
• Message buffer (например, Kafka topic) для асинхронной передачи.
• Запись в state store (Redis, MongoDB) с уникальным task_id.

Пример кода (упрощённый handover request на Python):

class HandoverRequest:
    def __init__(self, agent_from: str, agent_to: str, task_id: str, 
                 user_query: str, intermediate_results: dict, history: list):
        self.agent_from = agent_from
        self.agent_to = agent_to
        self.task_id = task_id
        self.user_query = user_query
        self.intermediate_results = intermediate_results
        self.history = history

    def to_dict(self):
        return {
            "from": self.agent_from,
            "to": self.agent_to,
            "task_id": self.task_id,
            "user_query": self.user_query,
            "intermediate": self.intermediate_results,
            "history": self.history
        }

# Agent A формирует handover
handover = HandoverRequest(
    agent_from="graphics_agent",
    agent_to="legal_agent",
    task_id="task_42",
    user_query="Нарисуй диаграмму и напиши договор",
    intermediate_results={"diagram_svg": "...", "caption": "..."},
    history=[{"role": "user", "content": "..."}, 
             {"role": "assistant", "content": "диаграмма готова"}]
)
# Отправка через Router
response = router.route(handover.to_dict())

Восстановление состояния на стороне Agent B: Agent B получает HandoverRequest, проверяет task_id (нет ли дублирования), восстанавливает history, продолжает с user_query и использует intermediate_results для генерации финального ответа.

5. Протоколы и стандарты handover в AI-агентах

В индустрии появляются стандарты для облегчения handover между агентами разных систем:

• Agent-to-Agent (A2A) Protocol от Google (2025) — описывает как агенты обнаруживают друг друга, обмениваются capability cards и передают задачи с контекстом.
• Model Context Protocol (MCP) от Anthropic — стандарт для предоставления инструментов и ресурсов агенту; может использоваться для handover через общий контекст.
• LangGraph's handoff — встроенный механизм в LangGraph: AgentNode может сам решить, какому узлу передать управление, используя Command или Router.

Пример использования handoff в LangGraph:

from langgraph.graph import StateGraph, Command
from typing import TypedDict, Literal

class AgentState(TypedDict):
    messages: list
    next_agent: Literal["graphics", "legal", "end"]

def graphics_agent(state: AgentState) -> Command:
    # пытается выполнить задачу, но не может
    if "legal" in state["messages"][-1]["content"]:
        return Command(goto="legal", update={"next_agent": "legal"})
    # завершить
    return Command(goto="end", update={"next_agent": "end"})

def legal_agent(state: AgentState) -> Command:
    # принимает задачу, обрабатывает
    return Command(goto="end", update={"next_agent": "end"})

graph = StateGraph(AgentState)
graph.add_node("graphics", graphics_agent)
graph.add_node("legal", legal_agent)
graph.set_entry_point("graphics")

6. Проблемы и решения при handover

7. Пример из реальной архитектуры: Handover в системе "AI-помощник разработчика"

Сценарий: Пользователь пишет: «Создай микросервис на FastAPI и напиши тесты к нему».

1. Agent A (code generator) генерирует код FastAPI, но не умеет писать unit-тесты.
2. Agent A формирует handover с полем task_type = "test_writing" и generated_code = "...".
3. Router на основе поля task_type направляет задачу Agent B (test specialist).
4. Agent B получает код, генерирует тесты, возвращает пользователю единый ответ.
5. Router объединяет результаты и отправляет пользователю.

8. Инструменты для реализации handover

• LangGraph (handoff через Command, Router, Send)
• AutoGen (Microsoft) — встроенная поддержка AgentChat с handoff через AgentMessage
• CrewAI — Crew с process=Process.hierarchical или sequential, где агенты могут передавать задачи через tools и context
• Semantic Kernel (Microsoft) — плагины и FunctionHandoff
• Dify — визуальный оркестратор с node и условиями перехода

Пет-проект для закрепления

Задача: Создать двух агентов: Agent A (погода), Agent B (календарь). Если пользователь спрашивает «Какая погода в Москве?» — работает Agent A. Если «Запланируй встречу» — Agent B. Если запрос смешанный (например, «Какая погода завтра? Запланируй встречу, если дождь») — Agent A делает погоду, но не может планировать → handover Agent B.

Инструменты: Python, FastAPI (как API для агентов), LangGraph, OpenAI API, Redis (state store).

Шаги:

1. Определить два агента через StateGraph: weather_agent, calendar_agent.
2. Реализовать Router (LLM-based), который анализирует messages и решает, какому агенту передать.
3. Реализовать handover через Command(goto=...) с передачей state (результаты погоды).
4. Обработать случай, когда Agent A не может выполнить задачу (intent != "weather").
5. Добавить fallback агент, который сообщает, что не может выполнить, если ни один не подходит.

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

Связь с другими вопросами

Навигация

• Предыдущий: 592
• Следующий: 594
• Индекс: 00. Индекс разборов