Три роли, которые ИИ-агенты играют на платформе для разработчиков

Матар Пелеш, инженер по разработке решений компании Port, рассказывает на портале The New Stack о том, как агенты искусственного интеллекта функционируют в качестве потребителей, внутренних компонентов и управляемых ресурсов на современных платформах для разработчиков.

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

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

Роль 1: ИИ-агенты как потребители платформы

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

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

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

Что требуется от платформы? Интерфейс, ориентированный на API и MCP, управляемый контекстный слой, из которого агент считывает данные, и набор действий самообслуживания, которые он может вызывать.

Роль 2: ИИ-агенты как внутренние компоненты платформы

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

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

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

Роль 3: ИИ как ресурс со своим собственным жизненным циклом (также известно как AgenticOps)

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

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

Это создает проблему «золотого пути». «Золотой путь» — это маршрут, который по умолчанию обеспечивает команде доступ к ресурсу правильным образом, и он нужен для жизненного цикла агента: запрос, получение и регистрация, а затем публикация для следующей команды. Это также то, чем чаще всего интересуются организации: реестр агентов и навыков был востребован 47% организаций, с которыми мы общались.

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

Краткое описание трех ролей

Иногда эти три роли оказываются связанными

Интересный случай с цепочкой ролей. Инженер запрашивает агента сортировки в роли 3; тот добавляется в реестр агентов как часть рабочего процесса создания, а неделю спустя рабочий процесс инцидента вызывает его как компонент (роль 2). Когда агент запускается, он считывает данные о владельце службы и последних развертываниях из того же контекстного хранилища, реализуя роль 1. Это один и тот же агент, которого вы видите в разных ролях.

Как может выглядеть платформа, охватывающая все три роли?

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