ИИ-агенты после запуска: как я учу операторов не тонуть в поддержке
Через пару недель после запуска раздался звонок: «Опять пропустил заявку от постоянного контрагента». Разобрались за час — виноват забытый шаблон промпта из эксперимента. Только разбирались мы, а не оператор. И это была ошибка.
Так появился мой внутренний курс по управлению ИИ-агентами. Не для инженеров, а для человека, который каждый день будет смотреть логи, править поведение, отключать функции и объяснять коллегам, почему сегодня всё тормозит. Без такого курса через месяц внедрение превращается в бесконечную поддержку, а через квартал — в тихую смерть проекта.
Почему после разработки начинается самое интересное
В 2026 году собрать агента стало проще: MCP уже в релиз-кандидате, LangGraph кэширует узлы, а новые модели сильно подешевели. Два человека за месяц — и рабочий агент готов.
А вот сделать так, чтобы он приносил пользу через полгода, — совсем другая история. Здесь нужна дисциплина эксплуатации, только теперь она называется «управление агентом». Оператор не будет лезть в Grafana или писать SQL. Ему нужен свой инструмент и свой язык.
Пять реальных поломок, на которых я учу
Курс построен на ситуациях, которые повторяются у почти всех заказчиков. Вот пять примеров, которые разбираем в первую встречу.
Агент вдруг стал отвечать хуже. В девяти случаях из десяти это не модель сломалась. Кто-то добавил в базу документ, который противоречит старому регламенту. Оператор должен быстро открыть карточку ответа, увидеть источники и понять, где возник конфликт.
Клиент жалуется, что агент нахамил. Реальный ответ и то, что увидел клиент, могут отличаться. Учу доставать диалог по traceparent, проверять версию промпта и отвечать клиенту по делу.
«Хотим, чтобы теперь умел вот это». Раньше это была неделя в бэклоге. Сейчас, если архитектура нормальная, часто хватает правки шаблона. Оператор учится редактировать, тестировать на снапшотах и раскатывать через A/B.
Агент начал жечь бюджет. Раз в квартал случается токен-инцидент. Показываю, как быстро читать разрез по стоимости и ставить временное ограничение, пока инженеры разбираются.
Нужно срочно всё выключить. У каждого агента есть kill switch — большая красная кнопка, которая переводит его в режим «оставьте заявку». Оператор должен знать, где она, и не бояться нажимать.
Что я оставляю в панели оператора
Первую версию сделал технически красивой и совершенно нечитаемой: p99, векторные дистанции, графы. Инженеру приятно, оператору бесполезно.
Переделал. Осталось четыре экрана:
- «Что сейчас происходит» — активные диалоги, скорость ответов простыми словами, состояние источников.
- «Поиск диалога» — по клиенту, номеру заявки или фразе. Всё видно сразу, без терминальных логов.
- «Редактор поведения» — промпты и правила. Можно поменять, протестировать и опубликовать.
- «Здоровье и деньги» — расход, аномалии и тот самый kill switch.
Всё остальное — метрики LLM-судей, latency по хопам — остаётся у инженеров.
Почему роль оператора стала важнее кода
Агент теперь не проект, а продукт, который живёт годами и меняется каждую неделю. Новые фреймворки это уже учитывают: Tasks в MCP, out-of-band governance в Redpanda. Всё это про людей, которые управляют бизнесом, а не только про код.
Правильный оператор экономит проекту больше, чем удачно выбранная модель. Он ловит регресс промпта до того, как о нём узнает клиент, и видит рост стоимости на второй день.
Что я понял за полгода ведения курса
- Обучение занимает меньше времени, чем кажется: три встречи по полтора часа плюс пара часов практики.
- Без назначенного оператора я больше не сдаю проекты. Раньше соглашался — потом три месяца бесплатной поддержки.
- Панель управления важнее модели. Заменить модель можно за два дня, а исправить сломанную операционную практику — за полгода.
Последний вопрос, который я задаю заказчикам: «У вас уже есть человек на стороне бизнеса, который через месяц сам разберётся, почему агент ответил именно так?» Если нет — начинать рано. Сначала оператор, потом код.