«97,5% обращений и 409 тикетов вместо 1221»: ShipStation собрала ИИ-хелпдеск Deckhand на Amazon Bedrock AgentCore

Проблема, знакомая любой ИТ-команде

Отвечать на одни и те же ИТ-вопросы и закрывать рутинные тикеты — это время, которое ИТ-команда могла бы потратить на что-то другое. За 12 месяцев до запуска сотрудники ShipStation Global открыли в канале поддержки более 1 500 тредов, и объём только рос. Ответы при этом были размазаны по разным местам: статьи Confluence, страницы интранета и PDF, поддерживаемые ИТ-командой руководства и, наконец, собственная история канала.

Масштаб задавала география: сотрудники компании работают в США, Великобритании, Испании, Польше, Австралии и на Филиппинах, поэтому больше пятой части вопросов приходило вне рабочих часов в США. «Мы создали Deckhand, потому что получить помощь должно быть так же просто, как задать вопрос в Slack», — объясняет старший директор по ИТ ShipStation Global Крис Коллинз; тикеты, по его формулировке, — признак операционного трения, а не продуктивности.

Архитектура: четыре части и ни одного своего сервера

Deckhand живёт в Slack как обычный участник: заходит в каналы, читает переписку и берёт контекст из профилей, чтобы отвечать по месту. Вся конструкция собрана на Amazon Bedrock AgentCore — платформе для сборки агентов с любым фреймворком и моделью, а AgentCore runtime хостит агента в изолированных сессиях, так что своих серверов и контейнеров команда не держит.

Компонентов четыре. Slack-сервис на FastAPI и Slack Bolt развёрнут в AWS App Runner: он принимает события, решает, нужно ли вообще отвечать, и собирает контекст из профиля — имя, почту, часовой пояс и руководителя. Агент — это Strands-агент в контейнере на AgentCore runtime, который ведёт многошаговый цикл вызова инструментов на модели Anthropic Claude в Amazon Bedrock. Инструменты и знание собраны в одну функцию AWS Lambda, выставленную как инструменты Model Context Protocol через AgentCore Gateway: классификация запросов, создание и обновление тикетов Jira и анализ изображений; рядом — база знаний Amazon Bedrock, которая индексирует Confluence, интранет, Slack и маркетинговые страницы, а хранит всё в Amazon S3. Обратная связь лежит в Amazon DynamoDB, трассировка идёт через AWS X-Ray по OpenTelemetry, логи — в Amazon CloudWatch.

Сам агент намеренно лёгкий: на открытом SDK Strands Agents он состоит из модели, набора инструментов и системного промпта, а цикл рассуждений SDK ведёт сам, позволяя модели выбирать инструмент, обрабатывать результат и повторять, пока не появится ответ. Идентификатор модели задаётся переменной окружения, так что модель можно сменить, не переписывая код приложения.

Самая ценная база знаний — история самого Slack

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

Конвейер разбора состоит из трёх шагов. Сначала скрипт выгружает всю историю канала через Slack API вместе с полными ответами в каждом треде и пишет структурный дамп с метками тредов, отметками времени и числом ответов. Затем DSPy Recursive Language Model (RLM), работающая на Claude в Amazon Bedrock, обходит эту выгрузку не как один промпт, а как доступное пространство памяти внутри песочницы Python read-eval-print loop (REPL): модель итеративно классифицирует каждый тред как решённый, нерешённый или эскалированный и отсеивает анонсы и не-вопросы, считая тред решённым только если полный рабочий рецепт виден в самом треде. На третьем шаге для каждого решённого треда RLM запускает рекурсивные вызовы суб-моделей, извлекая структурированные поля, каждое из которых проверяется по модели Pydantic — резюме проблемы, исходный вопрос, решение, признак самообслуживания, шаги, приложение, систему, текст ошибки и теги; если ответ не проходит схему, цикл ловит ошибку валидации в интерпретаторе и повторяет попытку. Результат пишется в markdown по проблемам и загружается в Amazon S3, чтобы база знаний его проиндексировала.

Как агент решает, когда молчать

ИИ-бот в общем канале проваливается социально раньше, чем технически, поэтому самая тонкая логика Deckhand — решение не отвечать. Первым действием на каждое сообщение агент определяет, анонс это, светская болтовня или разговор между людьми: в этом случае он выводит «SKIP», а Slack-сервис подавляет ответ. В тредах он отвечает только автору исходного сообщения. Если последним ответил другой человек-помощник, бот молчит, потому что разговор подхватил живой сотрудник. Наконец, если ответ начинается с упоминания конкретного человека через @, сообщение адресовано не боту.

Обратная связь и безопасность

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

Промпты дополняют поведение, но не заменяют контроль доступа, поэтому ограничения живут в коде и инфраструктуре. Создание тикета требует явного подтверждения: предложив завести тикет, Slack-сервис добавляет кнопку, а обновления принимают только валидные ключи по шаблону проекта helpdesk и отбрасывают пустые комментарии. Классификация проверяется до действий — она идёт отдельным вызовом Amazon Bedrock Converse API с валидацией через Pydantic прежде, чем что-то попадёт в Jira. Инструмент анализа изображений умеет скачивать файлы только с хоста Slack, авторизуется бот-токеном, берёт не больше пяти изображений до 5 МБ каждое и отправляет их vision-модели тоже через Converse API. Все учётные данные — токены Slack, signing secret и доступ к Jira — лежат в AWS Secrets Manager, а каждый сервис и инструмент работает под своей узкой IAM-ролью. Промпт отдельно запрещает просить пароли и коды многофакторной аутентификации и писать учётные данные в комментариях к тикетам.

Что получилось за три месяца

Deckhand запустили в апреле 2026 года: он начинал примерно с 30 сообщений в день, а к началу лета доходил до 100. За первые три месяца агент обработал 1 935 сообщений, начал 1 221 разговор и открыл 409 тикетов в Jira, отвечая на 97,5% сообщений. Треть вопросов пришла не в рабочие часы, когда в ИТ-команде никого не было, и на 94% из них Deckhand ответил — люди, которым иначе пришлось бы ждать до утра, получали ответ вечером.

Оценки росли по мере доработки: положительные отзывы поднялись с 82% в апреле до 96% в июне — после того как команда переписала системный промпт и базу знаний, исправив то, на что жаловались. Самый наглядный выигрыш — отбитые тикеты: разговор с агентом — это вопрос, который иначе стал бы тикетом Jira, и из 1 221 разговора тикетами стали только 409, остальные 812 закрылись прямо в чате. Завести тикет, а потом отработать и закрыть его — это около 30 минут, так что 812 разговоров дают примерно 406 часов за три месяца, или около 1 600 часов в год. Это время сотрудники оставили себе, а ИТ не потратила его на приём заявок.