Агентный ИИ сам разбивает цель на шаги, выбирает инструменты, выполняет действия и проверяет результат. Разбираемся, чем агент отличается от чат-бота и автоматизации, как его применяют в разработке и администрировании и какие риски возникают при доступе к корпоративным системам.
- 1. Введение
- 2. Что делает систему агентом
- 3. Как устроена агентная система
- 4. Как агенты меняют разработку ПО
- 5. Как агенты меняют системное администрирование
- 6. Что происходит на уровне отрасли
- 7. Риски и ограничения
- 8. Выводы
Введение
Агентный ИИ — подход, при котором система получает цель и сама выбирает действия для её достижения.
Чат-бот обычно отвечает на вопрос и завершает работу. Агент продолжает выполнять задачу: проверяет логи, запускает диагностику, перезапускает контейнер и фиксирует результат в ITSM. Если не помогло, уточняет гипотезу и пробует другой путь.
Российские компании активно создают ИИ–агентов. По данным Yandex B2B Tech, на платформе Yandex AI Studio к августу 2026 года создано более 30 тысяч агентов, и на них приходится около 30% всего потребления платформы. Около четверти агентов используются для техподдержки, банкинга и HR-консультаций.
Опрос 52 крупных компаний, проведённый «Инфосистемы Джет» и Smart Ranking, показывает, что полуавтономных агентов пилотируют 59% организаций, а до промышленной эксплуатации довели 15%. Интерес к агентам высок, но переход от экспериментов к реальной эксплуатации пока сдерживается.
Дальше разберём, что делает систему агентом, как она работает с внешними инструментами и какие риски появляются при её использовании в корпоративной инфраструктуре.
Что делает систему агентом
Агентный ИИ (agentic AI) — подход к созданию ИИ–систем, которые самостоятельно планируют и выполняют последовательность действий для достижения цели в заданных ограничениях. ИИ–агент — система, реализующая этот подход.
Ассистент помогает пользователю решить задачу: анализирует информацию, предлагает решение или выполняет действие по запросу. Например, ИИ получил доступ к репозиторию и должен помочь исправить ошибку. Он может найти проблемный участок кода и предложить разработчику исправление. Что делать дальше, решает пользователь.
Агент в том же сценарии может изменить файл и запустить тесты. Если тесты завершились с ошибкой, он анализирует результат и выбирает следующий шаг: изменить код, выполнить дополнительную проверку или передать задачу человеку.
Получается замкнутый цикл:
выбор действия → выполнение → результат → выбор следующего действия.
Цикл продолжается, пока задача не будет выполнена или пока в работу не вмешается человек.
Такой цикл отличает агента и от сценария автоматизации (workflow). В workflow возможные действия и условия задаются заранее: он может содержать ветвления, циклы и обработку ошибок, но система действует по заложенной логике и не выбирает новый способ решения за её пределами.
Рисунок 1. Схема работы ИИ–агента (Источник: Anthropic)
Наличие ИИ не делает систему агентом. Главное — способность выбирать следующий шаг на основе полученных результатов и выполнять выбранное действие через подключённые инструменты. Степень самостоятельности может быть разной: от «только чтение» до автономного выполнения задач с подтверждением критических действий.
Таблица 1. Сравнение ассистента, автоматизации и агента
|
Критерий |
Ассистент |
Автоматизация |
Агент |
|
Как определяется следующий шаг |
По запросу пользователя |
По заранее заданным правилам |
По цели и уже полученным результатам |
|
Что происходит при ошибке |
Пользователь решает, что делать дальше |
Система реагирует так, как задано в сценарии, или останавливается |
Система анализирует результат и выбирает следующее действие |
Как устроена агентная система
Агентная система объединяет ИИ–агента, языковую модель, инструменты, внешние системы, память и механизмы контроля. Состав компонентов может различаться у разных агентных систем.
В упрощённом виде агент работает так:
- Языковая модель получает задачу и текущий контекст и предлагает следующее действие.
- Оркестратор проверяет действие по заданным правилам и ограничениям и передаёт его нужному инструменту.
- Инструмент выполняет операцию или обращается к внешней системе и возвращает результат оркестратору.
- Оркестратор добавляет результат в контекст и снова передаёт его модели, а та определяет следующий шаг.
Цикл повторяется, пока задача не будет выполнена или не потребуется участие человека.
Память хранит результаты предыдущих шагов, сведения о состоянии задачи и другие данные, которые нужны агенту для продолжения работы. Отдельного механизма памяти может не быть, тогда часть информации агент получает из текущего контекста.
Планирование помогает разбить цель на подзадачи и определить порядок их выполнения. Без этапа планирования модель может выбирать следующий шаг после каждого полученного результата.
Для контроля действий агента задают права и правила: какие действия он выполняет самостоятельно, для каких требуется подтверждение человека, а какие запрещены.
Рисунок 2. Связь модели с инструментами, памятью, источниками данных (Источник: Anthropic)
Как агенты работают с инструментами
Через инструмент агент получает данные из внешней системы или выполняет в ней разрешённую операцию. Например, он может читать файлы, обращаться к API, запускать команды, получать данные из системы мониторинга или создавать задачи в ITSM-системе.
Если агенту нужно проверить состояние сервиса, он обращается к инструменту мониторинга. Если нужно изменить конфигурацию — к инструменту управления сервисом.
Набор инструментов определяет, какие операции агент технически может выполнять. Права доступа и политики безопасности ограничивают эти возможности. Например, агенту можно разрешить читать данные через API, но запретить их изменение. Для операций в рабочей среде (production), удаления данных или административных команд можно требовать подтверждения человека.
Инструменты подключают через API и вызовы функций, командную строку, браузерные интерфейсы и специализированные протоколы. Один из таких протоколов — Model Context Protocol (MCP). Он задаёт стандартный способ подключения ИИ–приложений к инструментам и источникам данных. MCP — один из способов стандартизировать подключение инструментов и источников данных, а не обязательный компонент агентной системы.
Таблица 2. Примеры инструментов агента
|
Внешняя система |
Что агент может делать через инструмент |
|
Файловая система |
Читать, создавать и изменять файлы в разрешённых каталогах |
|
Git |
Создавать ветки, фиксировать изменения и выполнять разрешённые операции с репозиторием |
|
Командная строка |
Выполнять разрешённые команды |
|
CI/CD |
Запускать сборку и тесты, получать их результаты |
|
Система мониторинга |
Получать сведения о состоянии сервисов и инфраструктуры |
|
ITSM-система |
Создавать и обновлять задачи, обращения и инциденты |
Как агенты взаимодействуют друг с другом
Один агент может выполнить задачу целиком, но для сложных сценариев чаще используют несколько агентов, распределяя работу по специализации. Например, агент‑аналитик работает с требованиями и архитектурой, агент‑разработчик пишет код, а агент‑тестировщик запускает и проверяет тесты. У каждого — свой набор инструментов и минимально необходимые права.
Взаимодействие с агентом не всегда сводится к вызову инструмента. Инструмент выполняет операцию по вызову и возвращает результат. Агент может интерпретировать входные данные и выбирать действие в пределах своих полномочий. Поэтому обмен между агентами не всегда сводится к вызову функции. Для него нужны отдельные правила: что передаётся, в каком формате и какие действия разрешены получателю.
Агенты могут взаимодействовать несколькими способами:
Через оркестратор. Он ставит подзадачи, собирает результаты и передаёт их следующему агенту.
Через общую память. Помимо собственной памяти, у агентов может быть общее хранилище, куда пишут и откуда читают несколько агентов. Там хранятся цель, промежуточные результаты, гипотезы и ограничения. Это удобно для параллельной работы: все видят, что уже сделано, и не дублируют усилия.
Но такая схема требует жёстких правил. Если один агент записал ошибочный или вредоносный результат, другие могут на него опереться. Поэтому содержимое памяти проверяют, а права на запись ограничивают.
Напрямую (peer‑to‑peer). Агенты обмениваются структурированными сообщениями друг с другом. Например, агент-тестировщик сразу просит агента-разработчика поправить конкретный участок кода.
Схема гибче, но цепочку решений труднее отследить: не всегда понятно, кто и на каком основании принял решение. Поэтому логируют каждое сообщение, проверяют права инициатора и получателя, а объём передаваемых данных ограничивают.
Чтобы такие схемы работали между разными платформами, используют стандарты. Один из них — Agent2Agent (A2A), предложенный Google и переданный в Linux Foundation. Он описывает, как агенты разных систем находят друг друга, обмениваются задачами и результатами и обрабатывают ошибки. Как и MCP для инструментов, A2A — не обязательный компонент, а способ сделать взаимодействие предсказуемым.
В многоагентных схемах ошибка одного агента может передаться следующему. Данные, которые один агент получил из внешнего источника, для другого тоже должны считаться недоверенными. Поэтому к взаимодействию между агентами применяют те же принципы, что и к работе с инструментами: минимальные права, проверку входных и выходных данных, журналирование.
Как агенты меняют разработку ПО
При наличии разрешений агент работает с репозиторием, инструментами сборки и тестирования, закрывая многоэтапные задачи целиком.
Работа с кодом и тестами
Агент может найти ошибку, изучить контекст, внести правки, запустить тесты и доработать исправление. Он также может найти сценарии, которые не проверяются существующими тестами, добавить для них новые тесты и запустить их.
Если сборка или CI (Continuous Integration, непрерывная интеграция) завершились с ошибкой, агент анализирует журналы, находит причину и вносит изменения в код или конфигурацию. Затем повторно запускает проверку.
Например, агентный режим GigaCode от Сбера доступен в облачных сессиях GitVerse и через плагин для GigaIDE и JetBrains IDE.
В GitVerse агент получает рабочую копию репозитория в облачном окружении: анализирует код, изменяет файлы, запускает тесты и сборку, проверяет результаты. В IDE он работает с файлами открытого проекта: изучает их, вносит изменения, запускает тесты и сборку.
В облачных сессиях можно выбрать, с какими репозиториями и ветками работает агент. В IDE доступен выбор режима агента — Plan (анализ без изменений) или Agent (внесение изменений, по умолчанию с подтверждением).
Работа с изменениями и ревью
При работе с pull request (запросом на слияние изменений) агент анализирует изменения, учитывает замечания проверяющего, вносит правки и повторно запускает проверки.
В марте 2026 года GitHub сообщил, что Copilot code review выполнил более 60 млн проверок — на него приходится более одной пятой проверок кода на GitHub.
Рисунок 3. Проверка кода с помощью Copilot (Источник: GitHub)
Исследование проекта и распределение задач
Для анализа проекта агент собирает связанные файлы, зависимости и документацию, формирует план изменений и переходит к реализации.
Работу также можно распределить между несколькими специализированными агентами. Например, в системе ProAGI, разработанной в ИТМО, используются специализированные агенты: архитектор, аналитик, разработчик, тестировщик и технический консультант. Они участвуют в разных этапах разработки — от анализа задачи и проектирования до тестирования и доработки результата. Разработчики заявляют, что такой подход ускоряет разработку и снижает её стоимость в 2–10 раз.
Агенты могут участвовать в команде как полноценные исполнители. В сентябре 2026 года Яндекс запустил таких агентов в SourceCraft. Они работают под собственной учётной записью, готовят окружение, вносят изменения, запускают тесты и отправляют код на проверку, а при нехватке данных запрашивают уточнения через комментарии.
Что это меняет
Человек смещается от выполнения к постановке цели и контролю результата. Он решает, что нужно сделать, агент — как это сделать. Исследование Anthropic на основе около 400 тыс. сессий Claude Code показывает похожее распределение ролей. В среднем на пользователя приходится около 70% решений о планировании и только около 20% решений о выполнении.
При этом результат работы агента нужно проверять не только на ошибки, но и на соответствие архитектуре и требованиям проекта. В выборке из 302,6 тыс. коммитов, созданных с помощью пяти ИИ–инструментов, доля коммитов хотя бы с одной выявленной проблемой составляла от 7,5 до 14,8% в зависимости от инструмента. 22,7% проблем сохранялись в последней версии репозитория. Чаще всего это были code smells — признаки проблем в структуре и качестве кода. (89,3% всех найденных проблем).
Как агенты меняют системное администрирование
В администрировании агент объединяет данные из разных источников (метрики, логи, конфигурации, системы управления) и выполняет разрешённые операции в рамках заданных прав.
Диагностика и устранение инцидентов
При сбое сервиса причина может быть связана сразу с несколькими системами. Например, ошибка приложения сопровождается ростом задержки, изменением нагрузки на базу данных и недавним обновлением конфигурации. Чтобы найти причину, нужно сопоставить эти события.
Получив сигнал от системы мониторинга, агент собирает метрики и логи, проверяет состояние связанных ресурсов и сопоставляет события. Он может связать рост задержки со временем недавнего деплоя или всплеском нагрузки.
Агент также может проверить историю изменений конфигурации и кода. Если собранных данных недостаточно, он запрашивает дополнительные сведения и уточняет гипотезу.
Например, ИИ–агент для управления виртуализированной ИТ-инфраструктурой «Цифровой техлид» от «Базиса» анализирует логи, метрики и события и генерирует скрипты для устранения выявленных проблем. По данным компании, временные затраты на рутинные операции сократились на 20–50%, а время устранения аварий снизилось до 50%. Скорость выполнения отдельных задач выросла до 6 раз.
Когда причина известна и есть проверенный способ исправления, агент может выполнить разрешённую операцию, например перезапустить сервис или контейнер, и проверить результат. Если исправление не помогло, причина остаётся неясной или операция выходит за пределы его полномочий, агент передаёт инцидент администратору.
Результаты диагностики агент может передать в систему управления инцидентами (ITSM) и добавить в карточку обращения. Администратору не нужно переносить эти данные вручную.
Проверка и изменение конфигурации
Агент может проверять конфигурацию инфраструктуры и находить отклонения от заданных правил. Например, смотреть состояние портов, резервного копирования или других параметров. При большом количестве серверов он может выполнять такую проверку по заданному списку.
Важно разделять две операции: найти отклонение и исправить его. При доступе только на чтение агент ничего не меняет: он регулярно проверяет конфигурацию и передаёт найденные отклонения администратору. Для изменения конфигурации нужны соответствующие права или подтверждение человека.
Такой принцип используется в Azure SRE Agent — облачном сервисе Microsoft для эксплуатации и реагирования на инциденты в Azure. В нём отдельно настраиваются режим выполнения и права доступа.
В режиме Review агент запрашивает подтверждение перед действиями, которые требуют согласования. В режиме Autonomous он может выполнять разрешённые операции самостоятельно. Уровень прав определяет доступ агента к ресурсам и действиям: Reader даёт доступ только для чтения, а Privileged — права на изменение.
Microsoft рекомендует начинать работу с режима Review и переводить в автономный режим только те сценарии, в которых агент показал стабильную работу в течение 2–4 недель.
Рисунок 4. Режимы проверки и автономного выполнения в Azure SRE Agent (Источник: Microsoft)
Оптимизация ресурсов
Агент может анализировать использование вычислительных ресурсов, находить случаи простоя, сопоставлять нагрузку на виртуальные машины с их размером и временем работы, а также выявлять давно не используемые ресурсы.
Такие задачи относятся к FinOps — подходу к управлению затратами на облачные ресурсы. Агент собирает данные о нагрузке и расходах и готовит рекомендации: изменить размер виртуальной машины, скорректировать расписание или удалить неиспользуемый ресурс.
При этом агент работает с метриками и не понимает бизнес-контекст автоматически. Простаивающая машина может быть зарезервирована под будущий запуск, а ресурс с низкой нагрузкой — использоваться для тестовой среды. Поэтому решение об изменении или удалении ресурса может оставаться за человеком.
Например, в FinOps-сценарии «Клаудии» на платформе Cloud.ru Evolution агент выявляет «зомби-ресурсы» — виртуальные машины, которые были созданы, но больше не используются. Чтобы случайно не удалить важный ресурс, любые изменения (отключение машины, изменение настроек) совершаются только после явного подтверждения со стороны пользователя.
Что это меняет
При обычном администрировании специалист сам собирает информацию из мониторинга, логов, конфигураций и системы управления инцидентами. Агент объединяет эти данные и выполняет часть операций в пределах заданных прав.
Администратор меньше занимается сбором и первичным анализом информации. Он задаёт правила и ограничения для агента, контролирует его действия и разбирает случаи, которые выходят за заданные рамки.
Что происходит на уровне отрасли
В России формируются отраслевые подходы к агентной разработке. В августе 2026 года Сбер предложил создать Совет по генеративной разработке ПО при поддержке Минцифры. В сентябре в совет вошли представители 25 российских компаний. Среди направлений — стандартизация инструментов, безопасность и оценка экономического эффекта.
Параллельно Минцифры и Минпромторг готовят правила интеграции ИИ‑агентов с промышленным ПО. К 1 декабря 2026 года министерства должны представить правительству перечень открытых протоколов для взаимодействия агентов с промышленными системами.
Для компаний это значит, что при внедрении агентов нужно учитывать не только их технические возможности, но и то, к каким системам они подключены, какие права получают и насколько контролируемыми остаются их действия.
Риски и ограничения
Ошибка одного агента способна вызвать каскадные сбои, особенно в многоагентных сценариях. Неверный вывод первого агента становится входными данными для следующего, и ошибка множится.
Риски автономности
Чем больше действий агент выполняет самостоятельно, тем выше последствия ошибки. Microsoft выделяет четыре категории рисков автономных агентных систем:
- Отклонение от задачи — агент действует не в соответствии с целью пользователя.
- Отсутствие контроля — у человека нет возможности проверить, подтвердить, исправить или остановить действия агента.
- Недостаточная понятность — пользователь не видит, что агент делает, какие действия планирует и что уже выполнил.
- Отсутствие прозрачности — получатель результата не знает, что взаимодействует с ИИ или получает результат, созданный ИИ.
Риски агентных систем складываются из поведения модели и того, к каким данным и инструментам у неё есть доступ.
Риски безопасности
Среди ключевых угроз — prompt injection (в том числе косвенные атаки, когда вредоносные инструкции попадают к агенту из внешних источников) и подмена цели (goal hijacking). Такие инструкции могут находиться в письме, документе, веб–странице или файле в репозитории.
OWASP к основным рискам также относит злоупотребление инструментами и привилегиями, отравление памяти и контекста, небезопасное взаимодействие между агентами.
Согласно исследованию «Информзащиты» в 2026 году 42% организаций столкнулись с инцидентами безопасности, связанными с ИИ–агентами. Наиболее распространённые причины инцидентов:
- злоупотребление правами и выход за рамки разрешённых сценариев — 31% событий;
- промпт-инъекции и подмена инструкций — 24%;
- утечки через коннекторы и хранилища — 18%.
При этом только 5% компаний используют единую платформу для управления ИИ‑агентами. В крупных организациях доля неучтённых агентов доходит до 27%.
Риски, связанные с доступом и правами агента
Агент может получить больше прав, чем нужно для его задачи. Например, агент для диагностики инцидентов не должен без дополнительной проверки иметь возможность удалить базу данных или изменить критическую конфигурацию.
Чем шире доступ агента к системам и данным, тем больше возможных последствий ошибки или компрометации.
По данным Cloud Security Alliance, за последние 12 месяцев 65% организаций столкнулись с инцидентами, связанными с ИИ–агентами. Среди последствий респонденты назвали:
- раскрытие данных — 61%;
- операционные сбои — 43%;
- финансовые потери — 35%.
Только 21% организаций имеют формальные процессы вывода агентов из эксплуатации. Агенты, которые перестали использоваться, сохраняют права и учётные данные, создавая долгосрочный риск.
Агент может также создавать лишние расходы. Ошибка в логике, зацикливание или злоумышленное воздействие способны вызвать большое количество обращений к платным API и привести к резкому росту затрат.
Такой сценарий называют Denial of Wallet — «отказ кошелька» (исчерпание бюджета), по аналогии с отказом в обслуживании.
Ограничения
Качество работы агента напрямую зависит от данных и контекста. Расхождения в именовании одних и тех же объектов в разных системах (мониторинг, ITSM, CMDB), неполная телеметрия, устаревшая документация и ошибочные данные могут приводить к неверным выводам даже при корректно настроенных инструментах и правах.
Как с этим работать
Учитывайте всех агентов, которые работают в инфраструктуре. Фиксируйте, где они работают, какие задачи выполняют, кто за них отвечает и к каким системам имеют доступ. Отдельно проверяйте внутренние скрипты, SaaS-инструменты и среды разработки, где агенты могут появляться без отдельного процесса внедрения.
Выдавайте агенту только те права, которые необходимы для задачи. Разделяйте роли (сборщик, аналитик, исполнитель) и не давайте избыточных прав.
Считайте все внешние данные потенциально опасными. Письма, документы, веб–страницы и ответы других сервисов могут содержать скрытые инструкции. Проектируйте обработку так, чтобы агент не воспринимал такой контент как команды.
Ведите журнал действий агента: какие инструменты он вызывал, какие операции выполнял и какие изменения вносил. Такой журнал нужен для расследования инцидентов и проверки работы агента.
Внедрите процессы отключения агентов, отзыва прав и удаления учётных данных — это снижает риски от забытых агентов.
Внедряйте агента поэтапно:
- Режим только для чтения — агент собирает данные и формирует гипотезы, но не изменяет систему.
- Действия с подтверждением — агент предлагает операцию, но выполняет её только после вашего одобрения.
- Ограниченная автономность — агент самостоятельно выполняет узкий набор разрешённых и обратимых операций с чёткими условиями остановки.
Перед запуском в рабочей среде проверьте, как агент ведёт себя в типовых и непредвиденных сценариях, соблюдает ли заданные ограничения и корректно ли останавливается при неожиданных результатах.
Так область самостоятельной работы остаётся ограниченной, а критичные или необратимые операции — под вашим контролем.
Выводы
Агентный подход оправдан не для каждой задачи. Если последовательность действий заранее известна и редко меняется, обычной автоматизации может быть достаточно. Агент нужен там, где по ходу выполнения приходится выбирать следующие действия на основе полученных результатов и где эти действия можно проверить или отменить.
Чем шире доступ агента к системам и данным, тем выше цена ошибки. Поэтому автономность наращивают поэтапно.
Интерес к агентам высокий, но зрелость внедрения пока невысокая. Большинство организаций находятся на этапе пилотов, а не промышленной эксплуатации. Параллельно формируются отраслевые и регуляторные подходы — от стандартизации инструментов до правил интеграции с промышленным ПО.
