Как проектируем коллектив узких ИИ-агентов

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

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

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

Инструкции дополняются примерами правильных и неправильных передач. Формат контекста должен быть машинно проверяемым: идентификатор клиента, цель запроса, известные параметры, неизвестные параметры, найденные основания и вопросы для человека. Тогда следующий участник получает не длинный пересказ диалога, а рабочую карточку с понятными границами уверенности.

Подбор промышленного продукта нельзя строить на общей памяти модели. Нужны источники, за которые отвечает бизнес: каталог, технические паспорта, сертификаты, правила совместимости, ограничения поставки и дата актуальности. Если подходящей записи нет, агент должен сказать, что оснований недостаточно. Это полезнее, чем похожее название без подтверждённого применения.

Доступ к инструментам ограничивается ролью. Агент общения не получает право менять заказ. Продуктовый агент не публикует новую номенклатуру. Проверка может вернуть «нужна проверка специалиста» вместе с причиной. Человек видит использованные источники и может продолжить работу в CRM или другом рабочем контуре, не восстанавливая контекст по журналу переписки.

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

Такой формат делает автоматизацию измеримой. Можно увидеть, на каком шаге чаще всего не хватает данных, какие документы вызывают сомнения и где люди исправляют результат агента. ИИ не заменяет процесс управления знаниями; он показывает, насколько этот процесс определён и доступен для конкретной операции.

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

Здесь нет обещания обучить веса модели или получить сто процентов точности. Есть инженерная работа: ограничить задачу, дать агенту нужные права, задать формат результата, проверить ошибки и оставить человеку понятный выход. Для бизнеса это означает начать с одного сценария — например, технического подбора или квалификации заявки — и расширять его только после наблюдаемого качества.

На практике это длительное доведение: после первых проверок появляются новые формулировки клиентов, редкие комбинации параметров и исключения из коммерческой политики. Их не прячут в бесконечную инструкцию. Команда добавляет пример в набор сценариев, уточняет источник или ограничение, повторяет прогон и смотрит, стало ли поведение предсказуемее. Так качество растёт за счёт инженерного цикла, а не за счёт громкого обещания.

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

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