ИИ в техподдержке для разработчиков: от чат-ботов к агентам, которые чинят билды

Ещё пару лет назад «ИИ в поддержке» означало чат-бота с кнопками, который многих раздражал. Сейчас картина изменилась радикально. В 2026 году службы поддержки разработчиков строят не одного умного бота, а комбинацию агентов: одни копают логи и код, другие готовят контекст для инженера, третьи – по команде человека – открывают Pull Request с фиксом.

Главный сдвиг: агенты, которые действуют

Раньше ИИ «отвечал на вопросы». Теперь ИИ выполняет действия: диагностирует инциденты, перезапускает pods, правит конфигурацию, открывает Pull Request.

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

Как устроены современные агенты поддержки

Многоуровневая архитектура: оркестратор + специализированные агенты

Главный архитектурный паттерн, который повторяется в кейсах разных компаний – разделение на оркестратор и агентов-исполнителей.

Оркестратор понимает запрос, разбивает его на шаги и раздаёт подзадачи. Каждый агент получает только нужные инструменты (доступ к GitLab, Kubernetes, логам, базе данных) и жёсткие лимиты: по токенам, по времени, по количеству вызовов инструментов.

Если дать одной модели триста инструментов и десять правил, она начнёт путаться даже на простых вопросах. Контекст забивается, внимание ^[1] плывёт. Разделение позволяет держать оркестратор с «чистой головой», а агентам – фокусироваться на конкретной подзадаче.

Кейс 1. Electrolux и диагностика transit gateway

Electrolux построили мультиагентную систему для поддержки разработчиков и инфраструктурных операций. Один из самых показательных примеров – troubleshooting-агент для диагностики проблем с transit gateway.

Сценарий: инженер спрашивает, всё ли в порядке с конфигурацией. Агент проверяет и говорит: да, всё настроено правильно. Тогда инженер намеренно ломает соединение – выключает dev-окружение – и задаёт тот же вопрос. Агент точно определяет проблему: в security groups нет правила, разрешающего трафик из CIDR-range другого окружения.

 

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

Кейс 2. Life360 и один оркестратор вместо зоопарка ботов

Life360 (88 миллионов пользователей) столкнулись с классической проблемой: сначала были боты под каждую задачу, и сотрудники не знали, кого звать. Потом попробовали одного «всё умеющего» агента – он стал медленным и поверхностным. Люди вернулись к тому, чтобы писать в IT напрямую.

Решение: оркестратор Mimir, названный в честь скандинавского бога мудрости. Сотрудник пишет @Mimir в Slack – оркестратор сам решает, какому субагенту передать запрос: ITSM, Jira, Confluence, управление Slack, кодинг.

Отдельно строится Crash Agent: он должен идентифицировать падение приложения, найти путь в коде, предложить патч и открыть Pull Request для ревью инженером.

Момент, когда агент прошёл весь путь и открыл Pull Request в репозитории показал, что можно реально закрыть петлю, и это настоящая ценность.

От read-only к действиям: агент, который чинит билды

Отдельная категория кейсов – когда агенту дают «руки» поэтапно.

В серии статей на Хабре «Эй, агент, исправь мой билд» автор описывает эволюцию ^[2] системы: сначала агенты были строго read-only. Они смотрели в логи, метрики и код, писали отчёты – но ничего не меняли. Потом появилась фаза исполнения.

Ключевое решение: фазу определяет не модель, а код. Первое сообщение в треде уходит в анализ. Если для исправления нужны изменения, задача переводится в статус verdict_ready, и система ждёт человека. Инженер читает отчёт и отвечает «сделай» – только тогда запускается executor-workflow, который вносит изменения и открывает Pull Request.

«LLM предлагает категорию, но суффикс _execute вычисляется кодом из статуса. Галлюцинация модели не может ни запустить исполнение раньше времени, ни вернуть задачу с готовым вердиктом обратно в анализ».

Ни одна задача не доходит до исполнения без явного ответа инженера в треде. Это «дешёвый, но принципиальный предохранитель».

От RAG к автономному расследованию: кейс MTS Web Services

Следующий шаг эволюции – системы, которые не просто ищут по базе знаний, а сами ведут расследование.

В кейсе MTS Web Services описан переход от классического RAG к автономному агенту. Сначала RAG-система помогала искать по Jira и Confluence, но выдавала «сырые» куски документации. Инженеру всё равно приходилось собирать картину в голове. Плюс был критический изъян: нужно было знать, что искать.

Тогда команда построила агента, который сам проводит первичное расследование:

– анализирует описание тикета;

– составляет план расследования;

– самостоятельно определяет, какие данные ему нужны;

– делает поисковые запросы в Jira и Confluence;

– агрегирует информацию из нескольких источников;

– отдаёт инженеру структурированный анализ с гипотезами.

Ключевое отличие от RAG: агент не ждёт, пока человек задаст правильный вопрос – он сам решает, что искать, исходя из контекста тикета.

Результаты после внедрения: 

– 40% тикетов – правильное решение (логика ^[3] расследования и действия совпадают с тем, как задачу решил бы инженер);

– 45% – неполное решение (полезная информация, но нужно дополнительное исследование);

– 15% – неправильное решение.

Итого: примерно в 85% тикетов система оказалась полезна хотя бы частично.

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

Coinbase: «стеклянная коробка» перед агентом

Coinbase подошли к построению ИИ-поддержки с позиции observability-first. Их принцип: «glass box before building the agent» – сначала прозрачность, потом агент.

Они развернули несколько агентов:

– Discord AI Chat – меню-ориентированный интерфейс для разработчиков;

– Slack Triage – внутренний агент, который показывает, какие сообщения из Discord требуют внимания;

– Support Engineer Assistant – ассистент внутри сервисной консоли, изначально read-only.

Отдельный акцент – на guardrails: детерминированные защиты для очевидных случаев, grounding ответов в документации, LLM-based оценка риска на лёгкой модели.

Пропавший платёж за газ: где ломается поддержка без ИИ

А теперь – история из жизни, про газ и про 98,80 рубля.

Клиент оплатил газ через личный кабинет Газпром межрегионгаз Москва. Платёж от 15.08.2026 на 98,80 руб. успешно ушёл. Деньги списались. В приложении транзакция не отображается. Долга нет. Деньги на месте. А история платежей «потеряла» август. Итоговая сумма за год не сходится ровно на 98,80 рубля.

Хронология бюрократического квеста (суть).

Шаг 1. Обращение в ООО «Газпром межрегионгаз Москва».

Текст: «В расчётах не отображается платёж от 15.08.2026. Просьба провести платёж». Приложен банковский чек по данной операции.

Ответ №1: «Денежные средства поступили, учтены. Задолженности нет».

Проблема: данные о платеже не отображаются в личном кабинете клиента.

Шаг 2. Второе обращение – со скринами.

Текст: «В платежах не отображено поступление средств. Проводки не вижу за август».

Ответ №2: «Рекомендуем обратиться в техподдержку разработчика ЛК».

 

Шаг 3. Обращение в техподдержку ЛК – по рекомендации ООО «Газпром межрегионгаз Москва».

Ответ №3: «Мы только отображаем информацию, переданную нам местным МРГ».

Классический футбол.

Итог: круг замкнулся. ООО «Газпром межрегионгаз Москва» пишет «идите к разработчикам», разработчики – «идите в ООО «Газпром межрегионгаз Москва», пусть пришлют корректные данные».

Технический анализ: где ломается система

С точки зрения ^[4] архитектуры тут два источника данных:

– Биллинг (внутренняя бухгалтерия Газпрома) – платёж есть, он учтён во «Взаиморасчётах».

– Фронтенд (ЛК/приложение) – раздел «Платежи» транзакцию не показывает.

Между ними – API-синхронизация. Скорее всего, батч. И батч за 15.08.2026 либо упал, либо не прошёл валидацию. Классическая гипотеза: транзакция есть в ledger-таблице биллинга, но отсутствует в payments_history из-за рассинхрона ключей – например, payer_id в биллинге и account_id в ЛК не совпали после миграции.

Следствие: сумма платежей за год в приложении ≠ фактической сумме. Это ошибка ^[5] целостности данных.

Бизнес-боль: пользователь теряет доверие к сервису. Если система теряет один платёж, она может потерять и другой. Или задвоить начисление.

Как здесь мог бы помочь ИИ

Уровень 1: Триаж с доступом к данным.

Первая линия поддержки читает шаблоны и не видит всей картины. Агент с доступом к обоим API мог бы сам сверять: sum(payments_billing) vs sum(payments_app) за период. Если расхождение – сразу создаёт тикет в разработку с готовым диффом и ID инцидента. Не «передайте в техподдержку», а «инцидент зафиксирован, ожидаемое время реакции ^[6] – 4 часа».

Уровень 2: Ночной reconciliation-агент.

Баг обнаружил пользователь, а не система. Агент в фоне каждую ночь сверяет два источника. Нашёл расхождение на 98,80 – проактивно пишет пользователю: «Обнаружено расхождение в отображении платежа от 15.08.2026. Уже исправляем. Приносим извинения». Это то, чего не хватает в 99% финансовых сервисов.

Уровень 3: Агент, который не футболит.

Проблема пинг-понга не в том, что люди плохие. А в том, что у первой линии нет доступа к API обеих систем. Агент с доступом к обоим API формирует один корректный запрос и закрывает петлю. Человек остаётся в петле – но как утверждающий, а не как передающий.

Почему это не серебряная пуля

– Агент не должен иметь права менять данные в биллинге. Только предлагать фикс и открывать тикет.

– Ложные срабатывания. Если сверка идёт по кривым ключам, агент будет находить «расхождения» там, где их нет. Нужен ручной аудит первых 100 срабатываний.

– Проблема доверия к данным. Если биллинг и ЛК показывают разное, непонятно, какому источнику верить. Это вопрос не к ИИ, а к архитектуре. ИИ лишь подсвечивает проблему, но не решает её.

Дисклеймер: это мой личный опыт ^[7] взаимодействия с сервисом. Я не сотрудник компании и не имею доступа к их внутренним системам. Все технические гипотезы – мои предположения, основанные на публично доступных данных и поведении ^[8] интерфейса.

Что не работает и как это признают

Electrolux признаёт, что Infra Assistant может работать до нескольких минут в зависимости от сложности задачи. Для срочных вопросов это делает его неприменимым. Они измеряют end-to-end производительность, но не могут оценить вклад каждого агента отдельно. Это затрудняет поиск слабых звеньев.

В кейсе MTS 15% ответов – неправильные. В кейсе с «ИИ как штатный инженер» был случай, когда модель уверенно «решила» проблему, изменив схему таблицы, что сломало дашборд для 800 пользователей. После этого добавили слой симуляции: каждый SQL-запрос сначала исполняется в тестовой БД.

Практические выводы

Если вы думаете о внедрении ИИ-агентов в поддержку разработчиков, вот что показывают кейсы:

1. Оркестратор + специализированные агенты – не «один бот на всё». Дайте каждому агенту только нужные инструменты и жёсткие лимиты.

2. Человек в петле – не опция, а необходимость. Все production-системы требуют явного подтверждения перед действиями.

3. Состояние – в базе, не в модели. Фазу выполнения определяет код на основе статуса в БД, а не «решение» LLM.

4. Observability с первого дня. Coinbase строит «glass box» до агента. Electrolux использует трассировку Bedrock для понимания, как система декомпозирует задачи.

5. Оценивайте честно. Шкала от 1 до 5, где 5 – «полностью решил, как senior-инженер», помогает понять реальную ценность. В Electrolux такие «пятёрки» считают настоящим расширением возможностей команды.

6. Сверка данных между системами должна быть автоматической. История с пропавшим платежом за газ – не про газ. Она про то, что целостность данных нельзя оставлять на пользователя. Если биллинг и фронтенд расходятся, это должна ловить система, а не клиент.

 

Какие ИИ-инструменты вы используете в поддержке? Сталкивались с агентами, которые «уверенно» ломали прод? Или с поддержкой, которая «футболит» вас между отделами? Делитесь в комментариях.