Разработка постепенно меняет привычное разделение работы между человеком и инструментами. ИИ берет на себя не отдельные операции, а последовательность действий, для которой раньше требовалось участие специалиста. Но вместе с ростом автономности меняются и требования к самой системе. Агент должен понимать контекст проекта, знать внутренние правила и иметь доступ к инструментам, с которыми работает команда, а не просто искать информацию и писать код. 

Эту тему подробно разобрали на восьмом митапе MWS для DevOps и SRE. Эксперты из MTC Web Services и Orion Soft показали разные стороны перехода к агентной разработке и поделились кейсами, как ИИ потихоньку превращается в виртуального сотрудника — агента, действующего без постоянного сопровождения человека, и что для этого приходится менять в инженерных процессах.

MWS Meetup — это регулярные технические встречи для разработчиков и инженеров, которые проходят онлайн и офлайн. На них специалисты разбирают практические задачи из разработки, инфраструктуры и облачных технологий.

Итоги предыдущего митапа о работе ИИ с корпоративными данными можно почитать в предыдущем материале.

В этом посте:

• Когда ИИ начинает работать как сотрудник

• Инструменты для агента

• ИИ упирается в контекст

• Инженер становится оркестратором

• Документация становится частью инфраструктуры агента

• Закрытый контур для ИИ

• Каждому агенту — своя задача

Когда ИИ начинает работать как сотрудник

Владимир Дробот рассказал, как его команда работает с техническими инцидентами, которые не всегда требуют глубоких инженерных знаний, но где необходим последовательный поиск информации. Специалисту приходится прочитать обращение, разобраться в проблеме, найти похожие случаи, проверить документацию, посмотреть логи или обратиться к базе данных.

Часть этой работы команда решила передать ИИ. Система индексирует корпоративную базу знаний, историю обращений и информацию из системы управления задачами. При поступлении нового запроса агент определяет тип проблемы и выбирает подходящий сценарий расследования. В зависимости от ситуации нейросеть ищет похожие инциденты, анализирует логи, обращается к базам данных или использует несколько источников.

На первых этапах результат проверяли вручную. Из рассмотренных задач около 45% агент решал полностью, еще примерно 40% давали частичное решение. В этих случаях система не закрывала инцидент целиком, но находила полезную информацию и предлагала инженеру дальнейшие действия. Около 15% результатов требовали дополнительной проверки из-за ошибок или галлюцинаций.

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

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

Получается цикл, похожий на обучение нового сотрудника. Агент получает инструкции, выполняет работу, человек проверяет результат, а полученный опыт возвращается в систему. Со временем виртуальный сотрудник лучше ориентируется в конкретной корпоративной среде.

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

Инструменты для агента

Задача системы не ограничивается обращением к языковой модели. Агенту приходится работать с несколькими источниками и инструментами. В одном сценарии достаточно найти статью в базе знаний. В другом нужно посмотреть историю инцидентов, проверить состояние сервиса или подготовить запрос к базе данных.

Здесь происходит разделение между предложением и действием. На сегодняшний день не передаем агенту право самостоятельно выполнять потенциально опасные изменения. Например, он может сформировать запрос или описать необходимые действия, но финальное решение остается за инженером. В итоге специалист получает готовое расследование расследование, которое нужно проверить, а не типовой ответ чат-бота.

По словам Владимира, такой инструмент становится виртуальным сотрудником. Агент может одновременно искать информацию в нескольких источниках, фиксировать результат работы и использовать накопленные знания в следующих задачах.

При этом виртуального сотрудника можно обучать — напрямую через повышение качества внутренней документации и детализацию описания сценариев, что напрямую сказывается на точности и скорости его работы.

ИИ упирается в контекст

Похожий вывод сделал Андрей Боровков. Его команда разрабатывает среду для управляемых агентов. Речь идет о виртуальных сотрудниках для разных ролей внутри разработки, включая продуктовых аналитиков, разработчиков и DevOps-инженеров.

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

Но на практике оказалось, что языковые модели научились очень быстро писать код, но скорость разработки продукта при этом не увеличилась пропорционально. Узким местом стала работа вокруг кода. Модель не знает историю инцидентов, внутренние ограничения, причины архитектурных решений и особенности интеграций.

В одном из случаев агент самостоятельно решил, что внутренняя kafka недоступна извне по ошибке, и попытался открыть к ней внешний доступ. В результате инженерам пришлось разбираться с последствиями. Проблема была не в способности модели писать код, а в отсутствии контекста конкретного проекта.

Это важное отличие виртуального сотрудника от обычного ИИ-помощника. Помощнику можно дать короткий запрос и проверить ответ. Сотрудник должен понимать среду, в которой работает. Чем больше ему разрешено делать самостоятельно, тем важнее качество контекста.

Инженер становится оркестратором

Может сложиться впечатление, что инженер становится ненужным, но это не так. Его работа смещается на другой уровень.

В MWS агент не пытается просто прочитать запрос и выдать длинный список замечаний. Вместо этого он строит карту рисков и показывает специалисту места, на которые действительно стоит обратить внимание. Это могут быть архитектурные противоречия, взаимоблокировки, состояния гонки или эксплуатационные риски.

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

В одном случае агент предложил решение, которое инженер после возвращения оценил выше собственного первоначального варианта. Поэтому теперь такой анализ нужно сделать регулярным.

Помимо этого у инженеров появляются новые навыки. Специалисту приходится проектировать взаимодействие людей, агентов и корпоративных знаний. Инженер становится оркестратором процесса.

При этом техническая экспертиза остается необходимой. Сотрудник обязан быстро проверить результат модели, и если решение результат действий агента нельзя объяснить, то это приведет к инциденту.

Документация становится частью инфраструктуры агента

Если агент должен принимать решения внутри проекта, ему необходимо знать историю этих решений. Поэтому документация перестает быть вторичным описанием системы.

В команде Андрея для каждого проекта стараются фиксировать архитектуру, доменную область, инструкции, API, плейбуки и другие инженерные артефакты. Есть общий репозиторий навыков, которым пользуются и агенты, и разработчики.

При каждом изменении документация должна обновляться вместе с кодом. Отдельный агент проверяет связанные материалы и ищет несоответствия. Если изменился один микросервис, но связанная часть документации осталась прежней, система может это обнаружить.

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

Важен и принцип единого контекста. Документация для людей и агентов не должна расходиться. Если человек знает одно, а виртуальный сотрудник получает другую версию правил, их решения начнут различаться.

Эксперт считает, что из-за этого меняется представление о ценности кода. Значительную его часть ИИ уже способен генерировать самостоятельно. Гораздо сложнее воспроизвести доменную экспертизу компании, историю архитектурных решений и накопленный контекст.

Закрытый контур для ИИ

Доклад Никиты Ефимова, DevOps-инженера в Orion Soft, был посвящен другой задаче — управлению операторами в закрытом сегменте. Но его пример хорошо показывает ту же логику автоматизации.

Оператор берет на себя жизненный цикл сложного приложения. Когда таких операторов становится много, возникает следующая проблема — нужно управлять уже не самими приложениями, а множеством операторов. В Orion Soft для этого используют отдельный оператор-менеджер. Он позволяет централизованно устанавливать компоненты, управлять их версиями и обновлениями.

Здесь работает тот же принцип, что и в агентных системах. Автоматизация становится полезной, когда за отдельной операцией появляется слой управления. Пользователю не нужно вручную контролировать каждый шаг. Система знает, какие компоненты связаны между собой, какие версии совместимы и в каком порядке их нужно обновлять.

В случае с агентами таким слоем становится среда управления виртуальными сотрудниками. Помощник может запускаться в ответ на событие. Например, после перевода задачи в статус «анализ» ее автоматически получает агент-аналитик. Конкретная команда может создавать собственного агента под свои задачи и подключать необходимые инструменты.

Агент становится частью процесса, а не отдельным сервисом, который сотрудник каждый раз запускает вручную.

Каждому агенту — своя задача

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

Так что лучше начинать с небольших рутинных операций. Если агент надежно справляется с одной задачей, область его ответственности можно расширять. Полученные во время работы знания стоит возвращать в систему, чтобы они использовались при следующих задачах.

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

Пока что в России виртуальные сотрудники официально не закреплены, но на Западе они уже получают должности и цифровые бейджи. Задача, которая сейчас стоит перед МWS, — перенести этот подход на отечественную почву и показать, как агенты могут работать в российских реалиях.

Выводы

Опыт MWS и Orion Soft показывает, что переход к виртуальным сотрудникам требует серьезной перестройки процессов. Агенту нужны доступ к инструментам, актуальная документация, накопленный контекст и ограничения на действия.

Человек при этом остается в процессе. Он определяет правила, проверяет результаты и принимает решения там, где ошибка слишком дорога. Рутинные операции постепенно передаются агентам.

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