Enterprise AI-агенты: no-code внедрение Stack AI

Почему AI-агент на Stack AI не выходит из пилота

Пилот AI-агента начинается одинаково: десяток заранее отобранных вопросов, аккуратно загруженная база знаний, Stack AI уверенно отвечает — и решение выглядит готовым. В реальном процессе запрос приходит из другой системы, в другом виде и от другого пользователя, и агент отвечает уже иначе.

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

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

Третья — нет владельца изменений. Регламенты и база знаний живут своей жизнью, формулировки устаревают, а ответственного за качество ответов нет. Агент деградирует незаметно: сначала редкие неточности, потом сотрудники просто перестают им пользоваться.

Узкое место почти всегда не в модели, а в процессе вокруг неё. Поэтому внедрение AI-агента упирается в то, какие данные и доступы он получает на каждом шаге и кто отвечает за результат. Разбираем, как это закрывается на уровне архитектуры.

Что меняется после управляемого внедрения агентов

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

Доля автоответов растёт не за счёт «разрешить всё», а за счёт явного порога уверенности и правил эскалации. Мы описываем, какие типы запросов агент закрывает сам, какие отдаёт с пометкой «проверить», а какие сразу уводит на оператора — с полным контекстом диалога, чтобы тот не переспрашивал заново.

Дальше уходит класс отказов, который обычно съедает поддержку: ответы по устаревшей инструкции, потеря запроса между системами, «поплывшая» логика после правки. Набор регрессионных диалогов из реальных обращений прогоняется при каждом изменении, а предыдущая версия конфигурации откатывается одним действием.

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

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

Варианты сборки агентов на Stack AI: конструктор, код, гибрид

Режим сборки определяет не «умность» агента, а то, кто и как быстро сможет его менять после запуска. В Stack AI доступны три подхода: визуальный конструктор агентов, собственная сборка и гибрид, где каркас диалога собирается мышью, а критичные узлы дописываются инженером. Разница проявляется на сопровождении: сценарий в конструкторе правит руководитель направления, логику в коде — только разработчик.

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

Порядок работ: от аудита процессов до передачи в поддержку

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

1. Аудит процесса. Разбираем поток обращений, считаем долю повторяющихся действий, отмечаем шаги, где цена ошибки высока. На выходе — перечень операций под автоматизацию и точки, где человек остаётся обязательным.
2. Схема агента и ролей. Определяем, какие данные агент читает, к каким системам обращается и что делает при нехватке сведений. Фиксируем, где он отвечает сам, а где готовит черновик для оператора.
3. Настройка сценариев. Собираем ветки диалога и правила передачи человеку в Stack AI, подключаем базы знаний и справочники. У каждого сценария есть границы: тема, допустимые действия, условие остановки.
4. Проверка на реальных данных. Прогоняем агента на исторических обращениях, а не на придуманных примерах. Считаем долю диалогов, закрытых без оператора, и разбираем каждый ошибочный ответ.
5. Правки по результатам проверки. Уточняем формулировки, добавляем недостающие правила, убираем ветки, ведущие в тупик. Двух-трёх итераций обычно достаточно, чтобы агент перестал выдумывать и корректно передавал сложное людям.
6. Передача в эксплуатацию. Отдаём команде заказчика схему агента, описания сценариев, правила обновления базы знаний и порядок отката. Проводим обучение, чтобы правки вносились без нашего участия.

Маршрут завершается не запуском, а снятием зависимости от подрядчика: команда понимает, как менять сценарии и куда смотреть при отклонениях. Опишите свой процесс — вернёмся с оценкой и планом по этим этапам.

Конфигурации, регламенты и документация на выходе

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

• Передаваемые конфигурации — выгрузка сценариев, инструкций агента, наборов инструментов и правил маршрутизации. Разворачиваются в вашем контуре без правок «по памяти».
• Схема интеграций — источники данных, типы подключений, очереди, ограничения на частоту обращений и точки отказа с указанием, что делать при обрыве.
• Матрица доступа — роли сотрудников и сервисные учётные записи: кому чтение, кому запуск, кому правка сценария и публикация в рабочий контур.
• Регламент эксплуатации — что и с какой периодичностью проверяется, какие метрики считаются отклонением, кто реагирует на ошибки и в каком порядке.
• Документация агента — логика обработки запроса, входные и выходные данные, зависимости от внешних систем и типовые причины отказов.
• Регламент изменений и откат — как правка проходит проверку, кто согласует публикацию и за какое время выполняется возврат к предыдущей версии.
• Набор эталонных проверок — типовые запросы с ожидаемыми ответами: после каждой правки видно, не сломалось ли то, что уже работало.

Всё переданное лежит на ваших учётных записях и в вашем репозитории — работа агента не завязана на нашу команду.

Кейс: разбор заявок в поддержке — метрики до и после

Поддержка сервиса пришла к нам с потоком 6–8 тысяч обращений в месяц, и вся очередь разбиралась вручную. Оператор открывал письмо, определял тему, искал заказ в учётной системе, сверял статус и писал ответ. Типовые вопросы — где посылка, как вернуть товар, как продлить подписку — съедали больше половины рабочего времени, хотя требовали тех же действий, что и сложные разборы.

Как устроен контур агента

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

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

Метрики до и после

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

Что делать, если агент уже собран на другом конструкторе

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

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

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

Каркас поднимается на Stack AI и проверяется на контрольном наборе до переключения трафика. Затем теневой режим: часть обращений обрабатывают оба агента, ответы сравниваются, расхождения разбираются вручную. Перевод трафика — постепенный, с возможностью вернуться на прежнюю платформу, пока новая не покажет сопоставимый результат.

Технические сомнения перед стартом внедрения

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

Что делать, если для учётной системы нет готового подключения?

Подключаемся через прикладной программный интерфейс системы, вебхуки или регламентную выгрузку в промежуточное хранилище. На Stack AI сценарий собирается поверх этих источников без доработки самой учётной системы. Режим обновления выбираем по задаче — по событию или по расписанию, с журналом расхождений.

Как ограничить доступ агента к данным?

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

Кто сопровождает решение после запуска?

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

Обсудим задачу и вернёмся с оценкой и планом работ

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

• цель сценария и метрика приёмки: по какому показателю вы поймёте, что агент работает — доля обращений, закрытых без оператора, время ответа, точность разбора заявок;
• состав исходных данных: где лежат регламенты, база знаний, история переписки, кто владелец этих систем и кто выдаёт доступы;
• 10–20 реальных примеров запросов и эталонных ответов — на них видно, где решение ошибается и что придётся дообучать;
• ограничения по данным и контуру: персональные данные, требования службы безопасности, где физически может работать агент;
• роли: кто со стороны заказчика принимает результат и кто участвует в приёмке этапов;
• что уже пробовали и почему не подошло — это экономит один-два круга итераций.

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

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