Соберем агента поддержки интернет-магазина
Пример выбран не случайно. Агент поддержки интернет-магазина достаточно узок, чтобы его можно было надёжно реализовать, и достаточно богат, чтобы на нём изучить RAG, персональные данные, tool calling, approvals, multi-turn state и handoff - всё, из чего состоит настоящий агент. Дальше вся книга собирает именно его.
Один типичный сценарий показывает, как части складываются вместе.
Клиент: Заказ AB-10492 пришел с поврежденной упаковкой.
Можно вернуть деньги?
Агент: policy_search("damaged package refund")
order_read("AB-10492")
refund_preview("AB-10492", "damaged_package")
Система: Показывает карточку:
Возврат 42.00 USD на исходный способ оплаты.
Preview действует 10 минут.
Клиент: Нажимает «Подтвердить возврат».
Сервер: Проверяет actor, preview, order version и idempotency.
Выполняет refund без нового model call.Обратите внимание: модель ведёт разговор и готовит расчёт, но возврат выполняет сервер после нажатия кнопки - без нового model call. Это и есть главная граница в действии.
Какие намерения агент поддерживает и чем каждое заканчивается, удобно держать в одной таблице.
Намерение · Tools · Финальный исход
- Общий вопрос о правилах -
policy_search;answerс citations - Статус конкретного заказа -
order_read;answerили уточнение - Возможный возврат -
policy_search,order_read,refund_preview;approval_required - Неясный или конфликтный случай -
handoff_prepare;handoff_required
За этими исходами стоят явные SLO, и их стоит зафиксировать до кода. SLO качества: ни одного обещания без действующего source, ownership проверяется для каждого заказа. SLO продукта: p95 успешного read-only ответа укладывается в заданный latency-бюджет. SLO риска: ни один refund commit не возникает из tool call модели. Первый и третий - про доверие, второй - про скорость.
Каркас примера ясен. Начнём наполнять его с того, откуда агент берёт факты о правилах, - с RAG, который возвращает доказательства, а не новый prompt.