Продажи через AI-агента

Если в группе есть товары и хотя бы один из них видим агенту, агент автоматически получает commerce-tools — никакой настройки на стороне агента не требуется. Тот же агент при наличии услуг получает booking-tools, оба набора работают вместе.

LLM-tools

search_products

Поиск по каталогу с фильтрами.

search_products({
  query?: string,
  categorySlug?: string,
  tags?: string[],         // AND-match
  priceMin?: number,       // ₽
  priceMax?: number,       // ₽
  inStock?: boolean,
  sortBy?: 'relevance' | 'price_asc' | 'price_desc' | 'newest',
  limit?: number           // default 20, max 50
})

Поиск идёт по pg_trgm (тот же индекс, что в UI). Видны только товары, доступные этому конкретному агенту в его группе (product_agent_visibility).

В ответе агент получает:

• Оптовые тиры цен (priceTiers) — агент понимает, что минимальный заказ 5 шт или что от 20 шт дешевле.
• Ограничения количества (minQuantity, maxQuantity, quantityStep).
• Метку ПО ЗАЯВКЕ для inquiry-товаров — агент знает, что оплату выставлять не нужно.

create_order

Создание заказа прямо из чата.

create_order({
  items: [{ productId: string, variantId?: string, quantity: number }],
  customerEmail?: string,
  customerPhone?: string,
  customerName?: string,
  notes?: string
})

Если в истории сессии уже есть email клиента, агент берёт его из истории — не обязательно спрашивать заново. Оплата создаётся автоматически. Заказ привязывается к группе, агенту, сессии и лиду CRM (если есть).

Сервер при создании применяет оптовые тиры и скидки от суммы — клиентским данным не доверяет.

get_order

Самообслуживание «где мой заказ»:

get_order()  // без параметров

Возвращает заказы, оформленные в этой же переписке (по sessionId): статус, позиции, сумма, ссылка на оплату для pending_payment. Чужие заказы недоступны — без поиска по email. Тумблер orderLookupEnabled, по умолчанию включён.

Режим продавца

Тумблер salesPushEnabled (вкладка «Продажи» в настройках агента). По умолчанию включён.

Включён: агент проактивно ведёт клиента к покупке — отрабатывает возражения, предлагает конкретный следующий шаг, один чёткий CTA. Без выдуманных скидок и «осталось 2 штуки» — только реальные данные из каталога.

Выключен: агент работает в справочном режиме — отвечает на вопросы, не дожимает к заказу. Подходит для поддержки или информационных ботов.

Маркеры в ответах

Агент вставляет маркеры в текст ответа — сервер парсит их и заменяет на UI-компоненты:

Системный промпт агента объясняет, когда какой маркер ставить. Дополняется автоматически — прописывать это в свой промпт не нужно.

Товары «по заявке» в чате

Если salesMode='inquiry', агент ведёт другой флоу — не создаёт заказ и не выставляет ссылку на оплату:

1. Агент сообщает клиенту цену с учётом выбранного количества и оптовых тиров.
2. Собирает контакты (имя, телефон или email, пожелания).
3. Информирует, что менеджер свяжется для уточнения деталей.
4. На стороне сервера лид с полным снапшотом (товар, количество, сумма) попадает в CRM.

Попытка создать заказ через create_order для inquiry-товара вернёт ошибку inquiry_only — агент получает человекочитаемое пояснение.

Защита от вранья (phantom-claim guard)

LLM иногда «убеждена», что вызвала инструмент, хотя на деле нет. Например, написала «Готово, оплачивайте!», но create_order не вызывала. Это вранье клиенту.

Framix решает в два шага:

1. Phantom-claim guard. Если в ответе есть фраза вида «заказ оформлен / готов к оплате», а в сессии не было успешного create_order или маркера [[pay:...]] — сервер подменяет ответ на стандартный текст-извинение.
2. Auto-recover. Если агент поставил [[pay:<orderId>]], но забыл вызвать create_order — сервер пытается восстановить вызов сам (распарсить намерение из истории + дёрнуть create_order с нужными параметрами). Если получилось — клиент не замечает.

Где в кабинете настраивается

/account/agents/[id] → блок «Продажи»:

• Какой merchant_account обслуживает оплаты в чате этого агента.
• Тумблер «Режим продавца» (salesPushEnabled).
• Тумблер «Показывать мои заказы» (orderLookupEnabled).
• Дополнительные подсказки в системный промпт.

Видимость товаров управляется через product_agent_visibility в карточке товара.

Как это выглядит в чате

Клиент: есть лёгкие куртки на весну до 8 тыс?

Агент: Нашёл три варианта в вашем бюджете: [[products:p1,p2,p3]]

(UI рисует карусель из 3 карточек)

Клиент: второй, размер M

Агент: Хорошо, оформляю. На какой email прислать подтверждение?

Клиент: kolya@example.com

Агент: Заказ оформлен на 5 990 ₽. Оплатите по кнопке ниже: [[pay:ord_abc123]]

Под сообщением — кнопка «💳 Оплатить». Клиент жмёт, открывается embedded-чекаут YooKassa прямо в чат-виджете или в /checkout/[token].

После оплаты — webhook, заказ → paid, агент в той же сессии отправляет благодарность и [[my-orders]].

В Telegram/VK

• Карусель [[products:...]] → нумерованная inline-клавиатура (Telegram не умеет горизонтальный скролл).
• Кнопка [[pay:...]] → обычная ссылка (embedded в Telegram невозможно).
• Маркер [[my-orders]] → ссылка на /my с одноразовым кодом.

Биллинг

Расход токенов любого LLM-вызова (включая вызовы commerce-tools) → ai_token_usage → списывается с баланса owner'а, как обычные диалоги. Платформенная комиссия за сами заказы — отдельно (см. Мерчанты).

Связанные разделы

• Создание агента
• Товары и каталог
• Мерчанты и платежи
• Чекаут
• Единый клиент группы