AI-агент для оптовой компании: архитектура на реальном примере

Четыре слоя, без которых агент останется демо

Рабочий AI-агент в оптовой компании — не магия одной модели. Это связка четырёх слоёв, каждый из которых можно починить или сломать независимо от остальных.

1. Источники данных — 1С, CRM, почта, Telegram-каналы заказов, файлы Excel от дилеров.
2. Инструменты и API — REST API 1С, webhook amoCRM/Битрикс24, парсеры PDF, Telegram Bot API.
3. Оркестратор — LLM, которая понимает задачу, принимает решение и выбирает инструмент.
4. Человек-в-контуре — менеджер, который подтверждает критичные действия там, где цена ошибки высока.

Первый слой определяет успех или провал до того, как агент сгенерирует хоть одно слово. Ошибка в данных — и агент подтвердит заказ на отсутствующий товар или создаст дубль клиента. В оптовом B2B это означает срыв отгрузки и потерю дилера. Поэтому архитектура начинается не с выбора фреймворка, а с аудита того, что уже лежит в вашей учётной системе.

Слой 1: Данные до агента

Прежде чем писать первую интеграцию, проверьте три вещи.

Номенклатура без дублей. В 1С часто живут несколько записей одного товара: с пробелом, с точкой, с разной единицей измерения. Агент, обрабатывая заявку дилера от руки, выберет случайную запись — и резерв уйдёт на неверную позицию. Минимум: вычистить номенклатурный справочник и закрыть возможность создания дублей на уровне прав доступа.

История заказов доступна через API. Агент должен за секунды поднять последний заказ клиента, его типовые объёмы и цены. Если история видна только в интерфейсе 1С или Excel-выгрузке, агент не сможет проверить, не заказал ли дилер три коробки вместо обычных десяти по ошибке. Решение: REST API к 1С с методами для получения заказов контрагента за период и текущих согласованных цен.

Остатки обновляются минимум дважды в день. Большинство агентов обращаются к таблице остатков в реальном времени. Если складская система синхронизируется с 1С раз в сутки, агент пообещает товар, который уже отгружен в розницу. Интеграция через COM-соединение или прямые SQL-запросы к базе 1С — временное решение; лучше выделить слой API, который агент будет опрашивать перед каждым подтверждением позиции.

Дистрибьютор Howard Elliott перед запуском агента потратил три недели на фиксацию каталога из 20 тысяч SKU. По словам вице-президента компании, без этого агент «размножил бы ошибки быстрее, чем менеджеры вручную». Результат: время обработки заказа сократилось с 4 часов до 15 минут, а выручка через AI-канал выросла на 15% за четыре месяца.

Слой 2: Инструменты, которые агент должен вызывать без вашего участия

Когда номенклатура и остатки готовы, следующий шаг — дать агенту руки, которыми он будет действовать. Для оптовой компании минимально необходимый набор:

• Чтение заказов: IMAP-клиент для мониторинга входящих на закупочный email, парсер PDF и изображений, Telegram Bot API для приёма текстовых сообщений от дилеров.
• Работа с 1С: REST-методы для проверки остатков, поиска номенклатуры, создания черновика заказа и установки статуса.
• Связь с CRM: webhook, который по идентификатору контрагента поднимает историю коммуникаций и последние согласованные условия.
• Уведомления менеджеру: отправка сообщения в Telegram или задачу в Битрикс24 с готовым черновиком для подтверждения.

Каждый инструмент — отдельный модуль с чёткой функцией. Агент не пишет напрямую в базу 1С; он дёргает API-эндпоинты, которые возвращают статус и сообщение об ошибке. Это значит, что вы в любой момент можете ограничить права агента: разрешить создавать черновик, но запретить менять цену или подтверждать отгрузку.

Слой 3: Оркестратор — когда агент решает, а когда зовёт менеджера

Центральный компонент архитектуры — LLM, которая принимает решение о маршруте. Приходит письмо с PDF от дилера: агент распознаёт позиции, номенклатуру, количество. Дальше он выполняет цепочку проверок:

1. Найти клиента по email или названию в CRM.
2. Сопоставить каждую позицию с номенклатурным справочником 1С.
3. Запросить остатки и доступность по складам.
4. Сравнить заказ с историей клиента: нет ли аномалии, резкого падения или скачка.
5. Если все позиции доступны и цены в рамках согласованных — создать черновик заказа и направить менеджеру на подтверждение.
6. Если есть неоднозначность (например, остаток ниже запрошенного, цена не совпадает, клиент не найден) — передать задачу менеджеру с контекстом и подсвеченным отклонением.

Эта логика не пишется вручную правилами «если — то» для всех случаев. Агент получает инструкцию на естественном языке: «Ты обрабатываешь заказы дилеров, твоя задача — подготовить черновик без ошибок в номенклатуре и количестве, всё что не уверен — отправляй менеджеру». LLM сама определяет уверенность и принимает решение.

В кейсе Howard Elliott агент Ella обрабатывает заказы по факсу, PDF и email, и только 15% заказов требуют вмешательства менеджера. Остальные 85% проходят автономно, менеджер видит готовый заказ для подтверждения за 15 минут вместо 4 часов.

Слой 4: Human-in-the-loop в Telegram

Менеджер не должен заходить в дашборд агента и разбираться в логах. Он получает сообщение в привычном канале — Telegram или корпоративную почту — с карточкой заказа:

• Клиент и его последний заказ.
• Позиции: что запрошено, сколько доступно, цена.
• Предупреждения: позиция не найдена, остаток ниже запрошенного, отклонение от типового объёма.
• Кнопки: «Подтвердить», «Изменить», «Отклонить».

На подтверждение уходит 20–30 секунд. Агент после подтверждения сам переносит заказ в статус «В обработке» в 1С.

Ошибки на этом этапе возможны в двух местах: агент неверно сопоставил номенклатуру (тогда кнопка «Изменить» и корректировка менеджером) или не распознал PDF со сканированным текстом (тогда менеджер вбивает позиции вручную, но в структурированном интерфейсе). Риск ошибочной отгрузки снижается в 5–7 раз по сравнению с полностью ручным вводом, потому что 85% заказов агент уже проверил по справочникам и остаткам.

Какой процесс выбрать первым: таблица для решения

Архитектура готова адаптироваться под разные задачи. Вот четыре процесса, с которых чаще всего начинают оптовые компании, и параметры, по которым выбирают первый.

Приём заказов оказывается на первой строке не потому что это «простая задача», а потому что результат измеряется напрямую в часах и ошибках, и эффект заметен с первой недели после запуска. Это создаёт доверие команды к агенту и даёт время подготовить данные для более сложных сценариев вроде реактивации.

Данные, а не LLM — решение, которое окупается до пилота

Архитектура, описанная выше, работает при одном условии: вы подняли свои данные до уровня, когда агент может на них положиться. Каждый день, потраченный на чистку дублей и настройку API, сокращает время пилота на неделю. Большинство команд перепрыгивают этот шаг, запускают агента на грязных данных и через месяц делают вывод, что технология не готова.

В реальности технология готова. Howard Elliott получил −94% времени обработки заказа, стабильно работая с каталогом из 20 000 позиций. Российская оптовая компания с интеграцией 1С и REST API может достичь схожих пропорций — при условии, что архитектура строится от данных к действию, а не от промта к хаосу.

Выбор инструментов и LLM-фреймворков — отдельная тема. Здесь мы разобрали процесс, который определяет, будет ли ваш агент работать в бою, а не на демо. Оставшийся вопрос: сняли ли вы метрики для baseline до старта?