ИИ-агент Deckhand, которого инженеры компании ShipStation собрали на платформе AgentCore в сервисе Amazon Bedrock для внутренней техподдержки в мессенджере Slack, за три месяца работы снял с очереди 812 типовых обращений, однако громкие 97,5% в шапке отчёта означают долю сообщений с ответом бота, а не долю реально устранённых поломок. В официальном разборе в блоге AWS от 13 октября 2026 года первое же предложение обещает, что помощник «решает 97,5% входящих вопросов». Если же заглянуть в итоговую сводку и подпись на графике результатов в том же материале, формулировка меняется: там указано, что бот просто ответил на 97,5% обращений в активных каналах, причём 409 из 1221 диалога всё равно закончились созданием обычной заявки для живых специалистов в Jira.
Почему очередь к техподдержке росла при готовых инструкциях
Ситуация, с которой столкнулась распределённая команда ShipStation до апреля 2026 года, знакома почти любой компании с несколькими офисами. За двенадцать месяцев сотрудники открыли в общем канале техподдержки больше 1500 веток обсуждений, и поток продолжал расти. Люди работали в США, Великобритании, Испании, Польше, Австралии и на Филиппинах, поэтому свыше пятой части всех вопросов падало в канал вне рабочих часов американской смены. Человек упирался в настройку почты или просил доступ вечером по своему времени, а дежурный администратор добирался до сообщения только утром.
Самое обидное для инженеров поддержки заключалось в том, что ответы на большинство этих вопросов давно существовали. Они лежали в базе Confluence, на страницах и в документах PDF внутреннего портала, в памятках ИТ-отдела и в старых ветках самого мессенджера. Но когда у сотрудника посреди рабочего дня слетает подпись в почте или не открывается сервис, он не идёт проверять четыре разных хранилища, а пишет в общий канал. Старший директор по ИТ в компании Крис Коллинз сформулировал эту проблему коротко: бесконечные тикеты показывают трение внутри процессов, а не продуктивность отдела.
Как устроен Deckhand и откуда он берёт проверенные ответы
Чтобы не держать собственные серверы, команда разделила сборку на простые узлы. Входящие события принимает веб-сервис на FastAPI и Slack Bolt в облаке App Runner, сразу подтягивая из профиля автора имя, почту, часовой пояс и руководителя. Сам агент на фреймворке Strands работает в контейнере AgentCore и вызывает модель Claude в Amazon Bedrock с температурой 0.3, чтобы ответы держались ближе к инструкциям, а имя модели задаётся переменной окружения.
База знаний объединила статьи Confluence, файлы внутреннего портала и архив прошлых обсуждений канала. Старую переписку выгрузили через интерфейс Slack и очистили рекурсивным модулем RLM в библиотеке DSPy, который смотрит длинный текст частями через среду Python и вложенные вызовы. В базу брали только ветки с полным рабочим решением: скрипт извлекал суть вопроса, ошибку и шаги, проверял поля схемой Pydantic и сохранял чистые карточки.
Если вы присматриваетесь к тому, как устроены такие рабочие агенты без рекламной мишуры, загляните в телеграм-канал maya_pro — там мы разбираем реальные схемы автоматизации и их слабые места.
Зачем агенту жёсткий запрет вмешиваться в чужой разговор
Внутренние боты обычно раздражают коллектив тем, что влезают в каждую реплику и плодят лишние тикеты. В Deckhand эту проблему закрыли правилами в коде сервиса, а прикладные действия — классификацию, запись в Jira и чтение картинок — вынесли в одну функцию Lambda через шлюз AgentCore Gateway по протоколу MCP (стандарту вызова внешних программ по строгим полям):
- Фильтр шума и живых инженеров: если сообщение в канале — объявление или разговор коллег, классификатор возвращает SKIP, и бот молчит. В ветке он отвечает только автору вопроса, замолкает после реплики сотрудника ИТ и пропускает сообщения с упоминанием человека через символ @.
- Заявка только по кнопке и защита секретов: агент не заводит тикет сам — сервис показывает кнопку согласия, после чего поля проверяются через Pydantic и уходят в Jira. Скриншоты качаются только с сервера Slack (до пяти файлов по 5 МБ), ключи лежат в хранилище секретов, а инструкция запрещает просить пароли и коды двухфакторного входа.
Где в отчёте на 97,5% расходятся ответы и реальная экономия
С апреля по июнь 2026 года нагрузка выросла с 30 до почти 100 сообщений в день: всего 1935 сообщений и 1221 диалог с агентом. Треть вопросов пришла вне смены ИТ, и на 94% из них бот ответил. Кнопки оценки под ответами (жалобы уходили в базу DynamoDB с коротким пояснением) помогли доработать промпт и статьи, подняв долю положительных оценок с 82% до 96%.
Однако к расчёту выгоды стоит относиться осторожно — на это указывает и разбор Models at Work. Из 1221 разговора 409 стали заявками Jira, а 812 остались в канале. Авторы умножают 812 диалогов на 30 минут (своя оценка полного цикла заявки) и заявляют об экономии 406 часов за квартал, или около 1600 часов в год. Но у этой арифметики три слабых места: во-первых, 97,5% — это лишь доля сообщений с ответом бота, тогда как треть диалогов всё равно ушла живым инженерам, а 96% одобрения посчитаны только по нажавшим кнопку оценки; во-вторых, далеко не каждый быстрый вопрос в мессенджере без бота превратился бы в получасовой тикет; в-третьих, это самоотчёт в блоге поставщика без внешнего аудита, открытого кода и счёта за вызовы Claude, контейнеры AgentCore и облачное хранилище.
В итоге самая практичная находка в истории с Deckhand — вовсе не рекламные проценты в заголовке отчёта, а способ подготовить базу знаний из старых решённых веток и жёстко запретить боту спамить в общих обсуждениях или плодить заявки без подтверждения человека. А когда у вас на работе возникает типовой вопрос к техподдержке или бухгалтерии, вам удобнее сразу получить проверенную выжимку из инструкции с кнопкой вызова специалиста или проще сразу писать живому человеку?
