Команда Nitric из пяти инженеров прежде поднимала дежурного специалиста три-четыре раза в неделю. Этот опыт заставил компанию отказаться от идеи одного универсального помощника и перейти к подходу, где специализированные ИИ-агенты получают чётко ограниченные роли. Для российских DevOps- и SRE-команд это знакомый сюжет: автоматизация полезна ровно до тех пор, пока не начинает создавать ночные инциденты быстрее, чем их успевают разбирать люди.
О смене подхода сообщает The New Stack. В опубликованном материале Nitric описывает проблему небольшой инженерной команды: попытка поручить одному агенту слишком много действий привела к частым эскалациям к on-call-инженеру. Доступный фрагмент публикации не раскрывает конкретный стек, модель или набор интеграций, поэтому делать из этого историю об очередном «готовом рецепте» было бы преждевременно. Но исходная метрика достаточно красноречива: для команды из пяти человек несколько ночных или внеплановых пробуждений еженедельно — это уже не шероховатость пилота, а заметная операционная нагрузка.
Главная идея здесь не в том, что ИИ-агентам нельзя доверять. Скорее, Nitric указывает на слабое место универсального агента: он одновременно получает широкий контекст, доступ к нескольким системам и право самостоятельно выбирать следующий шаг. Чем больше таких степеней свободы, тем сложнее предсказать поведение в нештатной ситуации. Агент может неверно интерпретировать симптом, выбрать не тот инструмент, запустить лишнее действие или просто передать человеку задачу без достаточной диагностики. В результате автоматизация не сокращает количество ручной работы, а меняет её форму: инженер вместо выполнения рутинной операции расследует последствия неудачной автономности.
Для DevOps это особенно чувствительная зона. В обычном приложении ошибка помощника может означать неудачный черновик текста или неверно заполненное поле. В эксплуатационном контуре цена действия выше: затронуты развёртывания, конфигурация, секреты, доступы, мониторинг и рабочие нагрузки. Даже если агент не имеет прямого права менять инфраструктуру, он способен создать шум — открыть ложную тревогу, неверно классифицировать инцидент или отправить специалиста искать проблему не там. Ночью такие ошибки обходятся дороже, чем днём: контекста меньше, времени на проверку тоже.
Подход со специализированными ИИ-агентами предлагает дробить работу не по принципу «одна модель на всё», а по границам ответственности. Один агент может собирать контекст инцидента, другой — сопоставлять сигналы мониторинга, третий — готовить безопасный план действий, а человек или отдельный контур подтверждения решает, можно ли выполнять изменение. Это не отменяет сложность системы: появляется маршрутизация задач, контроль передачи контекста и необходимость наблюдать уже за несколькими агентами. Зато ограничивается радиус ошибки. Если агент отвечает только за анализ логов, его неверный вывод не должен сам по себе менять конфигурацию кластера.
На практике такая декомпозиция требует дисциплины, которой часто не хватает на этапе эксперимента с генеративным ИИ. Команде нужно заранее определить: какие действия агент вправе выполнять сам; какие требуют подтверждения; какие данные он видит; как фиксируются его решения; кто отвечает за откат. Полезно разделять режимы «прочитать», «предложить» и «изменить» — и не выдавать последний доступ только потому, что первые два сценария сработали на демо. Отдельный вопрос — качество контекста. Агент, которому передали устаревшую документацию, неполные логи или неописанные исключения, будет уверенно действовать на плохих вводных.
В этой логике протоколы подключения моделей к инструментам, включая Model Context Protocol, становятся не просто удобным способом дать ассистенту доступ к сервисам. Они превращаются в часть модели безопасности и эксплуатации: важно не только подключить инструмент, но и описать допустимые операции, параметры, журналирование и границы полномочий. Для IT-директора это означает, что внедрение агентов нельзя оценивать лишь по числу сэкономленных часов. Нужны показатели качества: сколько ложных эскалаций возникло, сколько инцидентов агент помог закрыть без риска, сколько его рекомендаций пришлось отклонить и не увеличился ли объём дежурств.
История Nitric полезна именно своей приземлённостью. Рынок любит демонстрации агента, который «сам ведёт проект» или «сам чинит продакшен», но у небольшой команды есть более практичный критерий успеха: инженер должен реже просыпаться по тревоге, а не чаще объяснять автоматизации, что она сделала не так. Специализированные ИИ-агенты не гарантируют спокойный on-call, но дают понятную архитектурную точку для контроля риска: каждому агенту — узкая задача, ограниченный набор инструментов и проверяемый результат.
Следующий важный вопрос для отрасли — сможет ли такой подход сохранить экономию времени без превращения в дорогостоящую оркестрацию множества сервисов. Вероятно, наиболее жизнеспособными окажутся не полностью автономные «цифровые сотрудники», а небольшие агентные цепочки вокруг конкретных, повторяемых процессов: диагностики, подготовки изменений, проверки политик и разбора инцидентов. В DevOps ценность будет измеряться не степенью самостоятельности модели, а тем, насколько предсказуемо она помогает людям не разбудить друг друга среди ночи.
