Реализация мульти-агентной системы AI в мобильном приложении

Реализация мульти-агентной системы AI в мобильном приложении

Один агент не справляется, когда задача требует специализации. Агент-планировщик, агент-исследователь, агент-исполнитель, агент-критик — каждый делает своё, координатор сводит результаты. На мобильном это редкость в клиентской части, но как паттерн для бэкенда с мобильным UI — рабочая архитектура.

Когда нужна мульти-агентность

Один агент с 10+ инструментами деградирует: контекстное окно переполняется, модель путает, когда какой инструмент использовать. Мульти-агентная система разбивает задачу:

• Orchestrator — принимает задачу от пользователя, декомпозирует на подзадачи, делегирует специализированным агентам
• Research Agent — поиск и сбор информации (веб-поиск, RAG, база данных)
• Action Agent — выполнение действий (API-вызовы, бронирование)
• Critic Agent — проверка результатов на корректность и безопасность

Классический кейс для мобильного приложения: агент планирования поездки. Orchestrator получает «организуй командировку в Варшаву на 3 дня» → Research Agent ищет рейсы и отели → Action Agent бронирует → Critic Agent проверяет корректность дат и стоимость → Orchestrator формирует итоговый план.

Архитектурные паттерны: Supervisor vs Pipeline

Supervisor (Star topology). Центральный координатор управляет специализированными агентами. Каждый агент — отдельный LLM-инстанс со своим системным промптом. Координатор передаёт задачи и собирает результаты.

Pipeline (Sequential). Агенты выстроены в цепочку: выход одного — вход следующего. Проще отлаживать, но менее гибко.

Blackboard. Общее хранилище состояния, агенты читают и пишут в него. Подходит для асинхронной параллельной работы.

Для большинства мобильных продуктов достаточно Supervisor с 2–3 специализированными агентами на бэкенде.

Связь между агентами: что передавать

Агенты общаются через структурированные сообщения, не через необработанный текст. Вот почему это важно: если Research Agent вернёт неструктурированный текст, Action Agent может неверно интерпретировать данные. Используйте JSON-контракты:

{
  "agent": "research",
  "task_id": "trip-2024-warsaw",
  "status": "completed",
  "result": {
    "flights": [
      {"id": "LOT123", "price": 189, "departure": "2024-04-10T06:30"}
    ],
    "hotels": [
      {"id": "H456", "name": "Marriott Warsaw", "price_per_night": 95}
    ]
  }
}

Orchestrator знает контракт каждого агента и не полагается на «понимание» LLM.

Управление состоянием на мобильном клиенте

Мульти-агентный процесс может занимать 30–120 секунд. Мобильный UI должен:

1. Показывать текущего активного агента и его шаг
2. Давать возможность отменить в любой момент
3. Продолжать работу при сворачивании (push о завершении)
4. При ошибке одного агента — показать частичный результат

На Android: WorkManager для фоновой оркестрации + LiveData/StateFlow для обновления UI. На iOS: BackgroundTasks framework + Combine/AsyncStream.

WebSocket или Server-Sent Events для real-time обновлений шагов — лучше, чем long polling. Клиент подписывается на task_id и получает события:

event: agent_step
data: {"agent": "research", "step": "Ищу рейсы Минск→Варшава", "progress": 0.3}

event: agent_step
data: {"agent": "action", "step": "Бронирую рейс LOT123", "progress": 0.7}

event: task_complete
data: {"task_id": "trip-2024-warsaw", "result": {...}}

Изоляция контекста агентов

Каждый агент должен иметь свой минимальный контекст — только то, что нужно для его задачи. Не передавайте Research Agent информацию об инструментах бронирования, и наоборот. Меньше контекст — меньше «галлюцинаций», дешевле вызов.

Критически важно: Critic Agent получает только финальный результат и проверяет его по чеклисту (даты валидны, сумма соответствует выбранным опциям, нет противоречий). Это последний барьер перед показом пользователю.

Стоимость и оптимизация

Мульти-агентная система умножает количество LLM-вызовов. Для оптимизации:

• Специализированные агенты используют более дешёвые модели (GPT-4o-mini, Claude Haiku) для рутинных задач
• Orchestrator и Critic — более мощные модели (GPT-4o, Claude Sonnet)
• Кешируем результаты Research Agent при повторных схожих запросах (семантическое кеширование)

Этапы и сроки

Проектирование топологии агентов под задачу → определение контрактов обмена → реализация каждого агента и Orchestrator → интеграция серверного оркестратора → WebSocket-протокол для клиента → мобильный UI прогресса → тестирование сбоев и частичных результатов.

Мульти-агентная система из 3 агентов с мобильным UI — 6–10 недель.