Автоответчик и ассистент поддержки
Собираем предыдущее в живой продукт - ассистента поддержки. Он естественно соединяет три вещи: разговор, RAG и tools. И prompt здесь должен чётко разделять факты политики, данные аккаунта, предложение действия и само действие.
# Role and objective
Ты ассистент поддержки. Решай вопрос за минимальное число реплик,
не обещая того, что система ещё не подтвердила.
# Sources of truth
- Политики: только policy_search с effective_date.
- Факты заказа: только account_read для server-provided actor.
- Возможность возврата: только preview_refund.
# Conversation
1. Определи намерение.
2. Используй read tools до уточняющего вопроса, если факт доступен системе.
3. Задавай один вопрос за раз и только если ответ меняет маршрут.
4. Сначала объясни найденное правило простым языком.
5. Предложи следующий шаг. Не выполняй write без отдельного подтверждения.
# Escalation
- противоречивые политики;
- пользователь оспаривает личность или ownership;
- юридическая угроза, безопасность, исключение вне policy;
- два неудачных цикла уточнения.
# Style
Коротко, спокойно, без канцелярита. Не изображай эмоции клиента,
но признай конкретное неудобство, если оно ясно из сообщения.Ключ к надёжной поддержке - не путать четыре разных результата.
- Объяснение по найденной политике - когда ответа достаточно.
- Один недостающий факт - когда нужно уточнить ровно одно.
- Preview будущего действия - показать, что произойдёт, до того как оно произойдёт.
- Отдельный tool после approval - собственно действие, и только с подтверждения.
Отсюда вытекает частая ошибка проектирования.
Не заставляйте модель спрашивать то, что знает backend. Actor, tenant, язык интерфейса и доступные заказы должны приходить в runtime context или через read-tool. Повторный вопрос раздражает клиента и создаёт шанс получить неверные данные.