Реалізація мульти-агентної системи 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 тижнів.