Несколько лет назад самые мощные ИИ-инструменты в рабочем процессе разработчика помогали писать код. Сегодня они способны на гораздо большее. Все чаще ИИ-агенту поручают такие задачи, как:
Агент читает файлы, анализирует зависимости, выполняет команды, модифицирует код и взаимодействует с внешними системами. Во многих случаях он может выполнять значительные объемы инженерной работы с минимальным надзором. Этот сдвиг кажется постепенным, пока вы не осознаете кое-что важное: мы больше не делегируем предложения. Мы делегируем действия.
Интересно то, что главной проблемой все чаще становится не то, способны ли агенты выполнять эти задачи. Во многих случаях они уже способны на это. Более сложный вопрос заключается в том, доверяют ли им разработчики настолько, чтобы делегировать значимую работу. Узкое место смещается от возможностей к уверенности.
Читая недавнее анонсирующее заявление Срини Секарана о внедрении Docker AI Governance, я обратил внимание на одну фразу:
Чем больше я думал об этом, тем больше мне казалось, что это не маркетинговый слоган, а полезный способ понять, что именно меняется в разработке программного обеспечения.
От ассистентов к агентам
Последние несколько лет развития инструментов для разработчиков можно рассматривать как эволюцию. Сначала инструменты на базе ИИ помогали разработчикам, генерируя фрагменты кода и отвечая на вопросы. Затем появились вторые пилоты (copilots), помогающие разработчикам решать более крупные задачи в рамках существующих рабочих процессов. Теперь мы вступаем в эпоху агентов. В отличие от ранних инструментов, агенты не просто рекомендуют действия. Они все чаще выполняют их. Как только программное обеспечение начинает совершать действия вместо того, чтобы предлагать идеи, разговор об управлении и контроле меняется кардинально.
Небольшое наблюдение из опыта создания решений с использованием агентов
Однажды замеченная мной особенность при работе над ИИ-проектами и экспериментировании с рабочими процессами на базе агентов заключается в том, как быстро смещается граница доверия.
Когда я только начал использовать ИИ-инструменты, я в основном относился к ним как к «второй паре глаз». Я задавал вопросы по кодовой базе, проверял правильность подхода, генерировал небольшой фрагмент кода или помогал разобраться в документации. Инструменты были полезны, но они ничего не делали самостоятельно. Каждое действие по-прежнему зависело от того, что решу я. Это изменилось по мере того, как агенты для кодирования становились все более функциональными.
Задачи, которые раньше требовали копирования кода между окнами, все чаще превращались в рабочие процессы, где агент мог изучать репозиторий, изменять файлы, запускать тесты и итерировать при сбоях с минимальным надзором. Прирост производительности был неоспорим, но точно так же очевидно было и то, что агент теперь имел доступ к той же среде, учетным данным и инструментам, что и я.
Как для Docker Captain, именно это делает текущие дискуссии об управлении ИИ столь интересными для меня. Проблема не просто в том, что модели становятся более способными. А в том, что они все чаще взаимодействуют с реальными системами, а не генерируют текст изолированно.
Как только агент получает возможность выполнять действия от вашего имени, проблема заключается уже не только в возможностях. Разработчикам нужна уверенность в том, что агент будет действовать в рамках понятных границ. Управление становится важным не только потому, что оно защищает системы, но и потому, что оно помогает людям доверять используемым системам.
Почему разработчики все еще сомневаются
Большинство разработчиков беспокоятся не о том, способен ли агент генерировать код. Они беспокоятся о том, будет ли агент действовать предсказуемо, как только начнет взаимодействовать с реальными системами. Это колебание часто проистекает из того факта, что наши существующие модели доверия были разработаны с расчетом на людей-операторов, а не на автономное программное обеспечение.
Большинство средств корпоративной безопасности развивались вокруг относительно простого предположения: люди совершают действия, а системы обеспечивают контроль над этими действиями. Исходный код проходит через репозитории. Изменения проходят через конвейеры CI/CD. Рабочие нагрузки продакшена выполняются в управляемых средах. Системы идентификации определяют, кто и к чему имеет доступ. Сетевые элементы управления ограничивают места взаимодействия рабочих нагрузок. Система безопасности работает эффективно, потому что работа обычно движется через предсказуемые контрольные точки. Организации знают, где отслеживать активность, применять политики и собирать журналы аудита.
Агенты не следуют этим контрольным точкам
ИИ-агенты внедряют другую операционную модель. Агент, запущенный на машине разработчика, может проверять репозитории, выполнять команды, устанавливать пакеты, получать доступ к локальным файлам, отправлять запросы к API и взаимодействовать с внешними инструментами — и все это в рамках одной сессии. Что еще более важно, он часто делает это с теми же разрешениями, что и управляющий им человек. С точки зрения организации, значительный объем работы смещается за пределы систем, изначально предназначенных для управления ею. Ноутбук — это больше не просто место, где пишется код. Все чаще это место, где выполняются решения.
Рисунок 1. Традиционная безопасность контролирует точки проверки рабочего процесса. Управление агентами должно учитывать выполнение на этапе выполнения (runtime).
Агенту для написания кода не нужно ждать пулл-реквеста (pull request), прежде чем взаимодействовать с кодовой базой. Он может анализировать и изменять файлы задолго до того, как изменения попадут в репозиторий. Он может получать доступ к учетным данным, доступным в локальной среде. Он может подключаться к внешним службам, используя те же разрешения, которые доступны его оператору.
Рассмотрим типичный сценарий: агенту поручено выяснить, почему падает интеграционный тест. Чтобы отладить проблему, он может изучить файлы конфигурации, сгенерировать временные скрипты, установить дополнительные зависимости, выполнить диагностические команды и многократно перезапустить набор тестов до того, как результат проверит человек. Ни одно из этих действий не является необычным, но они показывают, как много активности теперь может происходить непосредственно в среде разработчика. Это не делает агентов опасными по своей сути. Это означает, что многие существующие предположения безопасности заслуживают пересмотра.
Почему защитных барьеров на основе подсказок (промптов) недостаточно
Один из распространенных ответов — полагаться на инструкции. Укажите агенту не обращаться к конфиденциальным файлам. Укажите агенту не вызывать внешние службы. Укажите агенту не совершать рискованные действия. Эти инструкции полезны, но они принципиально отличаются от принудительного исполнения. Промпт может влиять на поведение. Среда выполнения может ограничивать поведение. Это различие становится все более важным по мере того, как агенты обретают большую автономию. Традиционно безопасность была наиболее сильной, когда средства контроля находились ниже уровня приложений. Права доступа к файловой системе не предполагают ограничений; они их принудительно навязывают. Сетевые политики не спрашивают, следует ли блокировать трафик; они его блокируют. Тот же принцип применим и к ИИ-агентам. Если организация хочет быть уверенной в том, что агент может и чего не может делать, эти гарантии в конечном итоге должны существовать на том уровне, где фактически выполняются действия.
Два способа взаимодействия агентов с миром
Если упростить проблему, то большая часть активности агентов попадает в две категории. Первая — это выполнение. Агенты читают файлы, изменяют код, устанавливают программное обеспечение, выполняют команды и открывают сетевые соединения. Вторая — использование инструментов. Агенты взаимодействуют с внешними системами через API, интеграции и инструменты MCP. К ним могут относиться GitHub, Jira, облачные платформы, внутренние сервисы, коммуникационные инструменты или клиентские системы. Оба пути создают огромную ценность. Оба пути также могут создавать риски. Контроль только одного из них оставляет «слепую зону». Организация может тщательно контролировать доступ к внешним инструментам, упуская из виду то, что агент может выполнять локально. Или же она может обезопасить локальное выполнение, предоставив при этом широкий доступ к внешним системам. Эффективное управление требует прозрачности и контроля на обоих уровнях.
Проблема управления
Для многих организаций вопрос уже не в том, будут ли внедряться ИИ-агенты, а в том, как внедрять их ответственно. Это решение уже принимается инженерными командами по всему миру, поскольку рост производительности реален. Более важный вопрос заключается в том, как организации могут использовать автономность агентов, не жертвуя прозрачностью, подотчетностью и контролем. Не менее важно, чтобы разработчики были уверены в том, что они понимают эти границы. Чем проще понять, к чему агент может получить доступ, что он может выполнить и изменить, тем легче внедрять агентов в повседневные рабочие процессы. Традиционные модели безопасности строились вокруг инфраструктурных границ. Управление агентами все чаще требует границ на уровне среды выполнения.
- Где работает агент?
- К чему он может получить доступ?
- Что он может выполнить?
- Какие инструменты он может вызвать?
- Какие учетные данные он может использовать?
- И можно ли обеспечить последовательное соблюдение этих элементов контроля независимо от того, работает ли агент на ноутбуке, в CI или в промышленной среде?
Эти вопросы быстро становятся вопросами инфраструктуры, а не просто вопросами ИИ. Потому что, если ИИ-агенты становятся активными участниками доставки программного обеспечения, то среды, в которых они работают, заслуживают такого же уровня внимания, который мы исторически уделяли промышленным системам.
Ноутбук — это больше не просто место, где пишется код. Все чаще это место, где программное обеспечение начинает действовать. И именно поэтому фраза «ваш ноутбук — это новая промышленная среда» кажется не столько прогнозом, сколько описанием того, куда уже движется современная разработка. Настоящая проблема заключается не просто в предоставлении агентам большей автономии. Она заключается в создании сред, в которых разработчики чувствуют себя комфортно, используя эту автономию. Потому что будущее агентной разработки может зависеть не столько от того, на что способны агенты, сколько от того, что разработчики готовы им доверить.
Во второй части мы рассмотрим, как выглядит управление на уровне среды выполнения и почему изоляция, соблюдение политик и контролируемый доступ к инструментам становятся фундаментальными строительными блоками для агентных систем.
