AI-агенты для кросс-бордер e-commerce: поддержка, закупки, реклама, заказы и послепродажа

Кросс-бордер-командам редко не хватает доступа к ChatGPT — чаще боль от пяти полуавтоматизированных линий: копипаст в helpdesk, закупки в таблицах, реклама с ручным ROAS, склад выгружает ERP, послепродажа скачет между почтой и тикетами маркетплейса. Собрать это в AI Agents в одну аудируемую цепочку — три опоры: единая шина событий, доменные агенты с явными правами на инструменты и человеческие одобрения (возвраты, цены, снятие с витрины, крупный бюджет).

Ниже путь от нуля до продакшена: архитектура и контракты данных, пять агентов (поддержка, закупки, реклама, заказы, послепродажа), оркестрация, наблюдаемость, комплаенс. Примеры: Shopify + Amazon Seller + Meta/Google Ads; свой стек — webhooks, очереди, любой LLM API. Для gateway 24/7 запускайте оркестрацию на Cloud Mac в фиксированном регионе (cron, локальные скрипты), бизнес-API остаются официальными.

Архитектура: шина, оркестратор, инструменты

Не запихивайте все API в одного «супер-агента». Живучая схема — тонкая оркестрация, толстые инструменты:

• Шина событий: Kafka, Redis Streams, SQS или Postgres outbox. Вход нормализовать в JSON Schema: order.created, ticket.opened, ads.campaign.overspend.
• Оркестратор: маршрутизация по типу события к worker-агентам; автомат состояний заказа (ждём ответ → ждём отгрузку → исключение → закрыт).
• Доменные агенты: только инструменты своего домена (поддержка читает KB, заказы — WMS); общий read-only профиль клиента.
• Очередь одобрений: возвраты, цены, delist, бюджет > порога в pending_approvals; карточки Slack/Feishu до выполнения.

Данные и секреты: единый источник правды

Неверные ответы агента — почти всегда разъехавшиеся данные. До запуска выровнять:

1. Мастер товаров: SKU, варианты, таможня, эмбарго — ERP/PIM главный; админка магазина только read-sync.
2. Статус заказа: ID маркетплейса ↔ внутренний order_id ↔ трек в таблице маппинга; агенты ходят только через неё.
3. Лента клиента: почта, onsite-чат, WhatsApp, сообщения маркетплейса под одним customer_id.
4. Секреты: Shopify Admin API, Amazon SP-API, Meta Marketing API в Vault/KMS; короткие токены в рантайме — не в промпте.

Агент поддержки: каналы, интенты, БЗ, эскалация

Вход: webhooks Gorgias, Zendesk, Shopify Inbox, Amazon Buyer-Seller Messaging. Инструменты: KB политик (срок возврата, гарантия), трекинг, заметки тикета. Правила:

• Интенты: трекинг / недостача / качество / отмена / угроза отзывом — whitelist действий на интент.
• Версионированная RAG-KB: при смене политики bump версии, старые треды не смешивать.
• Низкая уверенность или жёсткий тон → escalate_to_human с уже загруженными фактами заказа.

Язык ответа — язык витрины покупателя; одна структура интентов на все языки, не агент на язык.

Агент закупок: сигналы, скоринг, пул людей

Агент закупок не «утверждает карточки» — он сжимает информацию в карту решения: тренд, цена конкурента, маржа, комплаенс.

• Сигналы: тренды маркетплейса, оценки продаж, библиотека объявлений, простой поиск патентов/ТМ (финал у юристов).
• Скоринг: правила + LLM-резюме; score, risks[], suggested_moq.
• Пул людей: score > порога → доска «закупкомитет»; агент пишет сравнительные таблицы, PO не создаёт.

Рекламный агент: креатив, ставки, предохранители

Реклама сжигает бюджет быстрее всего. Права: много читать, мало писать:

• Мониторинг read-only: почасовой spend, CTR, ROAS кампаний; всплески → ads.anomaly.
• Режим рекомендаций: карты «урезать бюджет / сменить креатив / расширить аудиторию» — по умолчанию без авто-бюджета.
• Авто (опционально): только при ROAS > цели и spend < дневного лимита ±5%; повышения — с одобрением.
• Тексты отдельно: три набора headline + primary text; человек выбирает перед загрузкой в Meta/Google.

Агент заказов: фулфилмент, исключения, сверка

Слушает order.paid, inventory.low, shipment.exception:

1. Проверка адреса (индекс, доплаты удалённых зон), чёрные списки, дубликаты.
2. Маршрутизация склада по остатку, SLA, входящей логистике; out-of-stock — сплит или поддержка уведомляет покупателя.
3. Запись трека в витрину и маркетплейс; исключения открывают подготовительный тикет AS.
4. Конец дня: расчёт маркетплейса ↔ платёжный шлюз ↔ дебиторка ERP; алерт при расхождении > порога.

Послепродажный агент: RMA, возвраты, споры

Общая лента с поддержкой, но инструменты чувствительнее:

• RMA: окно возврата, вскрытие, кросс-бордер возврат — предложение approve_rma, исполнение после одобрения.
• Возвраты: частичный / полный / доставка в таблице политик; агент только предлагает суммы.
• Споры площадки: Amazon A-to-z, PayPal — пакет доказательств (доставка, чат, скрины политик); подаёт человек.

Оркестрация: n8n, свой FSM, фреймворки агентов

Рекомендация: неделя 1 n8n «новый тикет → заказ → черновик»; недели 2–3 автомат заказа в коде; неделя 4 read-only мониторинг рекламы.

Наблюдаемость, стоимость, базовая безопасность

• Трейсинг: на каждый вызов trace_id, модель, токены, инструмент, было ли одобрение.
• Replay: хранить входные события + структурированный вывод для споров «по политике».
• Стоимость: малая модель для классификации поддержки, большая — для черновиков; дайджесты закупок/рекламы пакетами.
• Комплаенс: минимизация GDPR/ПДн; запрет накрутки отзывов и ранжирования — whitelist действий читаем юристами.

План на четыре недели

1. Неделя 1: схемы событий + маппинги; поддержка read-only + черновики (отправляет человек).
2. Неделя 2: авто-маршрут склада + запись трека; исключения → подготовка AS.
3. Неделя 3: дайджест закупок + алерты рекламы; одобрения в Slack/Feishu.
4. Неделя 4: предложения RMA + алерты сверки; сквозной trace и недельный ROAS/CSAT.

FAQ

Структурированный FAQ — в JSON-LD страницы. Кратко: один агент на всё?, общая поддержка Shopify/Amazon?, полный автобюджет рекламы?, prompt injection, где крутить workers.