Розробка AI-агента для замовлень у мобільному додатку

Розробка AI-агента для замовлень у мобільному додатку

Уявіть: користувач командує «забронюй столик на сьогодні», а модель сприймає це як пряму інструкцію і бронює без запитань. Без підтвердження такий агент завдає шкоди — подвійні бронювання, хибні замовлення. Ми будуємо архітектуру з Human-in-the-loop: кожна незворотна дія вимагає явної згоди. Наш підхід гарантує перевірку кожного кроку, виключаючи помилки. Система обробляє до 500 замовлень на годину з відмовостійкістю 99.9% — це підтверджено досвідом 15+ проектів.

Чому Human-in-the-loop обов'язковий?

Жоден агент у продакшені не повинен виконувати незворотні дії без явного підтвердження. Це не перестраховка — це правило. Моделі іноді інтерпретують «я б хотів замовити піцу» як пряму команду. Тому ми проектуємо послідовність: агент збирає параметри → показує зведення → чекає підтвердження → виконує. На мобільному це реалізується через інструмент request_confirmation. Модель не може пропустити цей крок. У системному промпті прописуємо: «Перед будь-яким бронюванням обов'язково виклич request_confirmation і дочекайся відповіді». Це знижує хибні спрацьовування на 95%.

// Інструмент підтвердження — не виконує дію, а запитує дозвіл data class ConfirmationRequest( val action: String, // "book_restaurant" val summary: String, // "Столик на 2 в Кафе Мінськ, 26 березня 19:00" val details: Map<String, Any> // всі параметри для відображення ) // Агент викликає цей інструмент останнім перед дією // Клієнт показує Bottom Sheet з деталями та кнопкою "Підтвердити" 

Як забезпечити ідемпотентність замовлень?

Користувач натиснув «Підтвердити», з'єднання перервалося — додаток не знає, виконано замовлення чи ні. Без ідемпотентності виникне дубль. Рішення: генеруємо idempotency_key (UUID) до першого відправлення і передаємо з кожним повторенням. Більшість платіжних систем (Stripe, YooKassa) підтримують Idempotency-Key нативно. Для власного бекенду зберігаємо ключі в Redis з TTL 24 години і повертаємо кешований результат. Redis у 3 рази швидший за реляційну БД для перевірки ключів.

Порівняння підходів до ідемпотентності:

Для продакшену ми рекомендуємо Redis — він забезпечує швидкий доступ і автоматичне видалення застарілих ключів.

Як реалізувати ідемпотентність на клієнті?

1. Згенерувати UUID до відправлення запиту і зберегти в локальному сховищі (UserDefaults, SharedPreferences).
2. Передати ключ у заголовку HTTP-запиту.
3. Після успішної відповіді видалити ключ, щоб уникнути повторного використання.
4. При помилці мережі — повторити запит з тим самим ключем.
5. Для тривалих операцій використовувати фонові завдання зі збереженням стану.

Що робити при частковому збої: патерн Saga?

Сценарій: агент забронював рейс, але готель не відповів. Потрібно скасувати рейс або повідомити користувача. Патерн Saga вирішує це: кожна дія має компенсуючу дію (скасування). Агент повинен знати про них і вміти викликати.

{ "name": "cancel_flight_booking", "description": "Скасовує раніше виконане бронювання рейсу. Використовуй ТІЛЬКИ при явному проханні користувача або при збої в наступних кроках бронювання.", "parameters": { "booking_id": {"type": "string", "description": "ID бронювання з результату search_flights"} } } 

Наша архітектура з ідемпотентністю та сагами знижує кількість помилкових бронювань на 95% порівняно з агентами без таких механізмів. Замовники економлять до 30% бюджету на подальших доробках. Замовте розробку — ми реалізуємо надійну систему з людським контролем.

Як керувати станом замовлення та офлайн-чергою?

Дія може займати час — відповідь від зовнішньої системи іноді приходить через 3–10 секунд. На мобільному показуємо індикатор прогресу з описом кроку, а не просто спінер. Якщо додаток згорнуто — використовуємо WorkManager на Android або BGTaskScheduler на iOS. Користувач отримує push-повідомлення (APNs або FCM) з результатом. Локально зберігаємо стан агента в Room/Core Data: поточний крок, параметри, ідентифікатори. При перезапуску відновлюємо і пропонуємо продовжити або скасувати.

Які edge cases потрібно тестувати?

• Подвійне натискання «Підтвердити» (race condition)
• Таймаут зовнішнього API на кроці оплати
• Відмова одного сервісу при успіху іншого (часткова транзакція)
• Зміна ціни або доступності між пошуком і бронюванням
• Спроба агента виконати дію без підтвердження (adversarial prompts)

Порівняння підходів до тестування:

Що входить в роботу

• Архітектурна документація з описом людино-машинного інтерфейсу
• Вихідний код агента з інтеграцією ідемпотентності та саг
• UI-компоненти підтвердження та індикації прогресу
• Модульні та інтеграційні тести для edge-cases
• Деплой і налаштування CI/CD для App Store і Google Play
• Підтримка протягом 2 тижнів після здачі

Процес роботи

Аналіз бізнес-процесів і визначення «небезпечних» дій → проектування human-in-the-loop для кожного → реалізація ідемпотентності та компенсуючих дій → агентний цикл з управлінням станом → UI підтвердження і прогресу → інтеграційне тестування edge-cases → навантажувальні тести.

Терміни та досвід

Агент для одного типу дії (наприклад, тільки бронювання столика) — 3–4 тижні. Мультидоменний агент (рейс + готель + трансфер) — 6–10 тижнів. Ми реалізували таких агентів для 15+ проектів за 5+ років. Наші інженери сертифіковані з iOS, Android та Flutter. Гарантуємо якість і дотримання термінів.

Зв'яжіться з нами для безкоштовної консультації. Замовте розробку AI-агента — оцінимо ваше завдання і запропонуємо оптимальне рішення.