Реализация AI-агента с выполнением действий в мобильном приложении (бронирование, заказ)
Агент, который не только отвечает, но и делает — это другой уровень ответственности. Забронировать столик, оформить заказ, перевести деньги. Ошибка в таком агенте — это не «неправильный текст», это реальное действие с реальными последствиями. Именно поэтому архитектура агентов с выполнением действий принципиально отличается от информационных.
Human-in-the-loop: почему это обязательно
Ни один агент в продакшене не должен выполнять необратимые действия без явного подтверждения пользователя. Это не перестраховка — это правило. GPT-4o иногда интерпретирует «я бы хотел заказать пиццу» как прямую команду к действию, а не как выражение желания.
Правильный UX: агент собирает все параметры → показывает сводку → ждёт confirm от пользователя → выполняет. На мобильном это реализуется через специальный инструмент request_confirmation:
// Инструмент подтверждения — не выполняет действие, а запрашивает разрешение
data class ConfirmationRequest(
val action: String, // "book_restaurant"
val summary: String, // "Столик на 2 в Кафе Минск, 26 марта 19:00"
val details: Map<String, Any> // все параметры для отображения
)
// Агент вызывает этот инструмент последним перед действием
// Клиент показывает Bottom Sheet с деталями и кнопкой "Подтвердить"
Модель не должна иметь возможности «пропустить» подтверждение. В системном промпте явно прописываем: «Перед любым бронированием или заказом ОБЯЗАТЕЛЬНО вызови инструмент request_confirmation и дожидайся ответа пользователя».
Идемпотентность и защита от дублирования
Пользователь нажал «Подтвердить», соединение прервалось, приложение не знает — выполнился заказ или нет. Без идемпотентности — двойной заказ. Решение: генерируем idempotency_key (UUID) до первой отправки и передаём с каждым повтором:
// iOS — создаём ключ один раз, сохраняем до подтверждения выполнения
let idempotencyKey = UUID().uuidString
UserDefaults.standard.set(idempotencyKey, forKey: "pending_order_key")
// Передаём в заголовке или теле запроса к бэкенду
request.setValue(idempotencyKey, forHTTPHeaderField: "Idempotency-Key")
Большинство платёжных систем (Stripe, YooKassa) поддерживают Idempotency-Key нативно. Для собственного бэкенда нужно хранить ключи в Redis с TTL 24 часа и возвращать кешированный результат для повторных запросов.
Откат и обработка частичных сбоев
Сценарий: агент забронировал рейс, но отель не ответил. Нужно либо отменить рейс, либо уведомить пользователя о частичном успехе. Паттерн Saga: каждое действие имеет компенсирующее действие (отмена). Агент должен знать об этих компенсирующих действиях и уметь их вызывать.
{
"name": "cancel_flight_booking",
"description": "Отменяет ранее выполненное бронирование рейса. Используй ТОЛЬКО при явной просьбе пользователя или при сбое в последующих шагах бронирования.",
"parameters": {
"booking_id": {"type": "string", "description": "ID бронирования из результата search_flights"}
}
}
Состояние заказа и офлайн-очередь
Действие может занимать время — ответ от внешней системы бронирования иногда приходит через 3–10 секунд. На мобильном это означает индикатор прогресса с описанием текущего шага («Проверяем наличие мест...»), а не просто спиннер.
Если приложение было свёрнуто во время выполнения — используйте WorkManager на Android для фоновой задачи с статусом, или BGTaskScheduler на iOS. Пользователь должен получить push-уведомление с результатом.
Локально сохраняйте состояние агента в Room/Core Data: текущий шаг, параметры, идентификаторы бронирований. При перезапуске приложения — восстановление состояния и возможность продолжить или отменить.
Что тестировать обязательно
- Двойное нажатие «Подтвердить» (race condition)
- Таймаут внешнего API на шаге оплаты
- Отказ одного сервиса при успехе другого (частичная транзакция)
- Изменение цены или доступности между поиском и бронированием
- Попытка агента выполнить действие без подтверждения (adversarial prompts)
Этапы работы
Анализ бизнес-процессов и определение «опасных» действий → проектирование human-in-the-loop для каждого → реализация идемпотентности и компенсирующих действий → агентный цикл с управлением состоянием → UI подтверждения и прогресса → интеграционное тестирование edge-cases → нагрузочные тесты.
Сроки: агент для одного типа действия (например, только бронирование столика) — 3–4 недели. Мультидоменный агент (рейс + отель + трансфер) — 6–10 недель.