ИИ-агенты стали частью современного рабочего процесса разработки.
Они пишут код, проверяют пул-реквесты, генерируют тесты, вызывают инструменты, взаимодействуют с MCP-серверами и помогают разработчикам работать быстрее. Но за каждым полезным агентом стоит нечто столь же важное, как и сама модель: контекст, который указывает агенту, как себя вести.
Этот контекст может включать навыки, промпты, инструкции, хуки, команды, скрипты, ссылки и определения MCP-серверов.
В небольшом проекте управлять этими примитивами довольно просто. Возможно, вы единственный разработчик, работающий с репозиторием. Всё, что вы видите локально, — это и есть всё существующее. Вы знаете, какие промпты используются, какие инструкции были добавлены и какие инструменты подключены.
Но когда это становится командной работой, возникает множество вопросов:
- Как убедиться, что каждый разработчик использует одни и те же инструкции для агента?
- Как узнать, что у всех есть последняя версия общего навыка?
- Как предотвратить негласное изменение промпта, хука или навыка кем-либо?
- Как контролировать, кому разрешено публиковать, обновлять или использовать эти примитивы агентов?
- Как применять принципы управления, контроля доступа и рабочих процессов утверждения до того, как эти примитивы попадут к разработчикам и инструментам для написания кода с помощью ИИ?
И самое главное: как убедиться, что эти примитивы агентов поступают из надежного источника?
Именно здесь на сцену выходит APM — Agent Package Manager (менеджер пакетов агентов).
Что такое APM?
APM — это менеджер пакетов с открытым исходным кодом для примитивов агентов. Он переносит привычную модель управления пакетами в мир ИИ-агентов, позволяя командам определять навыки, промпты, инструкции, хуки, команды и MCP-серверы в виде версионируемых зависимостей в едином файле apm.yml.
После определения каждый разработчик может запустить apm install и получить одинаковый контекст агента в таких инструментах, как Cursor, Claude Code, GitHub Copilot, Codex, OpenCode, Gemini и Windsurf.
Рассмотрение контекста агента как пакета
Проект APM имеет простую, но мощную базовую предпосылку: относиться к примитивам агента как к пакетам. Если вы знакомы с менеджерами пакетов вроде npm, эта концепция покажется вам естественной. Вместо того чтобы вручную копировать промпты, инструкции, навыки и определения MCP-серверов между проектами, вы определяете их как зависимости.
Проект может описать необходимый ему контекст агента в единственном файле apm.yml. Затем каждый разработчик может запустить:
И получить ту же настройку агента.
Эта настройка может включать в себя:
В этом примере проект не начинает работу с пустой конфигурацией агента. В нем объявляются общие примитивы, которые команда требует использовать от каждого разработчика:
jfrog/packages-skills содержит многоразовые навыки для работы с рабочими процессами, связанными с пакетами. jfrog/pr-standards-instructions определяет, как агент должен помогать с сообщениями в пул-реквестах и стандартами проверки. jfrog/build-test-instructions предоставляет агенту ожидаемое командой поведение при сборке и тестировании. jfrog/artifactory-mcp объявляет утвержденную конфигурацию MCP-сервера, которую агент может использовать при взаимодействии с Artifactory.
Вместо того чтобы вручную копировать эти файлы между проектами, команда объявляет их один раз в apm.yml. Когда разработчик запускает apm install, APM извлекает утвержденные версии из JFrog и размещает их в нужном месте для использования выбранными инструментами кодирования с помощью ИИ.
Воспроизведение одинакового контекста агента везде
Когда разработчик запускает:
APM читает файл apm.yml проекта, разрешает объявленные зависимости примитивов агента, извлекает необходимые пакеты и записывает соответствующие ресурсы в проект в структуре, которую выбранные инструменты кодирования с помощью ИИ могут использовать.
Это означает, что навыки, промпты, инструкции, хуки, команды, скрипты и объявления MCP не копируются вручную из одного репозитория или страницы вики в другой. Они устанавливаются как версионируемые зависимости.
Это важно, потому что настройка агента становится воспроизводимой.
Первая установка разрешает точные версии пакетов и содержащиеся в них ресурсы. Эти разрешенные версии вместе с хэшами содержимого фиксируются в файле блокировки (lock file). Зафиксировав этот файл блокировки в проекте, каждый разработчик, запускающий apm install, получает одинаковый разрешенный контекст агента.
Не «примерно те же инструкции». Не «то, что было последним при копировании файла». Те же версии. Те же ресурсы. Та же настройка агента.
Поэтому, когда новый разработчик присоединяется к проекту, меняет машину или делает свежий клон, он может воссоздать ту же среду агента, которую использует остальная команда. И когда команда решает обновить общий навык или инструкцию, это обновление может происходить намеренно через рабочий процесс зависимостей и файла блокировки, а не путем копирования и вставки.
Один файл apm.yml. Один общий файл блокировки. Один согласованный контекст агента на каждой машине разработчика.
Чем может управлять APM?
APM может управлять различными типами зависимостей агентов, включая навыки, промпты, инструкции, агенты, хуки, команды и MCP-серверы. Он не ограничивается одним типом файла или конфигурации. Исходный документ включает таблицу, в которой типы примитивов разбиты по категориям и объясняется, как каждый из них вписывается в рабочий процесс агента.
Именно здесь APM становится больше, чем просто удобным инструментом. Он создает структурированный способ совместного использования, версионирования и воспроизведения примитивов, которые формируют поведение агента.
Как только что-то становится частью рабочего процесса разработки программного обеспечения, это также нуждается в управлении (governance).
Недостающий элемент: доверенный реестр
Управление примитивами агентов локально полезно, но локального управления недостаточно. Даже когда команды хранят свои навыки, промпты, инструкции, хуки и конфигурации MCP во внутренних репозиториях Git, им все равно приходится иметь дело с извлечением (checkout), обновлениями, дрейфом версий и управлением зависимостями в нескольких репозиториях.
Это может работать для небольшой команды, но быстро становится проблемой в больших масштабах. Теперь каждому проекту нужно знать, из каких репозиториев выполнять вытягивание, какую версию использовать, когда обновляться и как убедиться, что правильные файлы доступны в нужном месте для использования агентом.
И есть еще одна практическая проблема: репозитории Git не всегда могут быть доступны агентам, работающим ближе к продакшну, внутри контролируемых сред или в пределах ограниченных сетевых границ. В таких случаях полагаться на Git как на механизм доставки во время выполнения для примитивов агентов становится ненадежным.
Предприятиям нужен надежный способ публикации, использования, контроля и аудита этих пакетов с помощью правильной модели реестра. Без этого разработчики могут в конечном итоге получать инструкции для агентов, навыки, скрипты или конфигурации MCP из разрозненных репозиториев, устаревших копий или случайных мест в интернете — создавая новую проблему цепочки поставок программного обеспечения.
Навык агента — это не «просто промпт». Хук — это не «просто вспомогательный скрипт». Определение MCP-сервера — это не «просто конфигурация».
Эти примитивы определяют, что видит ИИ-агент, что ему разрешено делать и какие инструменты он может вызывать, что по сути влияет на качество, безопасность и согласованность результатов, производимых агентом.
Это означает, что ими следует управлять с той же дисциплиной, которую мы уже применяем к программным пакетам.
Поддержка пакетов APM в JFrog
JFrog теперь позволяет использовать APM с платформой JFrog с помощью нового типа репозитория Agent Packages.
Это означает, что организации могут публиковать пакеты APM и использовать их напрямую через JFrog Artifactory, вместо того чтобы полагаться на несогласованные или ненадежные источники.
Благодаря интеграции APM и JFrog команды могут:
- Публиковать пакеты APM в надежном внутреннем реестре Artifactory
- Использовать пакеты APM из этого надежного реестра
- Поддерживать единообразное поведение агентов в разных проектах и на разных машинах
- Управлять контекстом AI-агентов с помощью той же платформы, которой они уже доверяют для управления программными пакетами
Как работает JFrog для пакетов APM?
Со стороны JFrog процесс начинается с создания нового репозитория типа Agent Packages.
Затем необходимо настроить APM для работы с этим реестром, выполнив следующие команды:
Все так просто! С этого момента разработчики могут использовать APM для отправки и получения пакетов агентов в JFrog / из JFrog.
Простой пример
Представьте, что у организации есть три пакета APM:
Все три пакета уже сохранены в Artifactory.
Теперь разработчик может создать проект с файлом apm.yml, который зависит от:
В этом примере проект объявляет зависимость от jfrog/packages-skills#^1.1.0.
Этот пакет представляет собой не просто автономный пакет навыков. Он также зависит от jfrog/artifactory-instructions, который, в свою очередь, зависит от jfrog/jfrog-instructions.
Цепочка зависимостей выглядит следующим образом:
Другими словами, проект объявляет в качестве зависимости верхнего уровня только jfrog/packages-skills#^1.1.0, но этот пакет зависит от jfrog/artifactory-instructions, который затем зависит от jfrog/jfrog-instructions.
Когда разработчик запускает apm install, APM транзитивно разрешает эту цепочку зависимостей, извлекает все необходимые пакеты из JFrog и размещает нужные файлы в проекте для использования агентом.
Затем они запускают:
APM извлекает необходимые пакеты из JFrog, транзитивно разрешает зависимости и переносит нужные файлы в проект, размещая их там, где выбранные инструменты написания кода с поддержкой AI могут их использовать.
Никакого копирования и вставки. Никаких гаданий на тему «какую версию вы используете?». Никаких случайных примитивов агентов, скачанных из неизвестного источника.
Теперь каждый разработчик в команде может работать с одними и теми же утвержденными примитивами агентов и теми же версиями. Независимо от того, двое у вас разработчиков или две тысячи, результат один: все теперь действуют согласованно.
Поддержание примитивов агентов в актуальном состоянии
Как только примитивы агентов начинают управляться как пакеты, их обновление также становится привычным делом.
Чтобы получить последнюю утвержденную версию, разработчики могут запустить:
APM извлечет последние примитивы в соответствии с поведением версий, заданным в конфигурации проекта.
Это дает командам понятный рабочий процесс для развертывания лучших инструкций, обновленных навыков, новых команд или улучшенных объявлений MCP без необходимости ручного распространения.
От установки до выполнения: где на самом деле работают утвержденные агенты
Установка одних и тех же утвержденных примитивов повсеместно — это первый результат. Когда разработчик запускает apm install, эти пакеты повсеместно поступают в любой используемый им агент: GitHub Copilot в VS Code или любые другие инструменты, поддерживаемые APM. Единый источник доверия для каждого инструмента на каждой машине.
Но агенты больше не находятся исключительно внутри IDE. Они перемещаются в CI/CD и удаленные среды выполнения, такие как GitHub Agentic Workflows, действуя в репозиториях самостоятельно. Это поднимает второй вопрос: когда утвержденный пакет действительно запускается, как его изолировать (поместить в песочницу), ограничить и выделить на него бюджет?
Поскольку пакеты APM переносимы, точный пакет, находящийся в Artifactory, может работать без изменений в качестве автоматизированного агента с помощью GitHub Agentic Workflows, которые запускают AI-агентов как GitHub Actions в CI/CD. GitHub Agentic Workflows рассматривают пакеты APM как зависимости первого класса. Вы импортируете общий компонент, перечисляете утвержденные пакеты, закрепленные за определенной версией, и рабочий процесс устанавливает их в изолированный раннер. Управление ( governance) также может быть применено.
Ниже приведен пример шлюза ручного утверждения перед запуском агента и ограничения, регулирующего затраты на AI за один запуск. В этом примере автоматизация импортирует утвержденный пакет APM под названием acme/modernization-kit#v2.3. Этот пакет может содержать навыки, инструкции, промпты, хуки, команды или объявления MCP, необходимые для конкретного рабочего процесса — в данном случае инициативы по модернизации.
Важная часть заключается в том, что acme/modernization-kit#v2.3 — это не случайный скрипт или скопированный промпт. Это закрепленный пакет APM, который можно утвердить, версионировать, хранить в Artifactory и повторно использовать в контролируемых процессах автоматизации.
Поэтому, когда агент запускается, он не извлекает произвольные инструкции из локальной настройки разработчика. Он использует утвержденную версию пакета с шлюзом ручного утверждения перед выполнением и ограничением бюджета, которое ограничивает расходы на AI за один запуск.
Навыки, агенты, инструкции, хуки и объявления MCP — все это рассматривается как пакеты. Как только они упакованы таким образом, они могут проходить через те же типы элементов контроля, которым команды уже доверяют при поставке программного обеспечения: утверждение, версионирование, хранение в Artifactory, контролируемое потребление и повторяемое выполнение.
В этом и заключается главная идея: примитивы агентов не просто устанавливаются в инструменты написания кода. Они также могут стать управляемыми строительными блоками для автоматизации. Утвержденные в неактивном состоянии в Artifactory. Закрепленные по версии. Контролируемые шлюзами перед выполнением. Изолированные, учитываемые по метрикам и отслеживаемые при запуске.
Почему это важно сейчас и что будет дальше
AI-агенты уже являются активными участниками жизненного цикла разработки программного обеспечения. Но индустрия все еще учится управлять новым слоем зависимостей, на который они опираются: промптами, навыками, инструкциями, хуками, командами и серверами MCP. Это не традиционные пакеты, однако они ведут себя как зависимости: создаются, шарятся, версионируются, потребляются и обновляются в рамках проектов. Они формируют рабочие процессы разработчиков, создают риски и требуют соответствующего управления.
APM предоставляет разработчикам удобный интерфейс пакетного менеджера для примитивов агентов. JFrog предоставляет организациям общий доверенный реестр, средства контроля (governance) и элементы управления корпоративного уровня, необходимые для безопасного использования этой модели в масштабе. Вместе они позволяют управлять контекстом AI-агентов так, как современные команды разработчиков ПО уже управляют программными пакетами.
Что дальше
Управление примитивами агентов как пакетами — это первый шаг. Следующий шаг — их защита. JFrog уже работает над уровнем безопасности, который анализирует пакеты APM по мере их отправки в Artifactory. Он будет проверять навыки, промпты, инструкции, хуки, команды и определения MCP на наличие вредоносных инструкций, скрытых манипуляций, небезопасного поведения и рискованных паттернов конфигурации. Это позволит командам контролировать примитивы агентов так же, как любой другой компонент цепочки поставок ПО: публиковать их в надежном реестре, проверять перед использованием и потреблять только после прохождения средств контроля безопасности организации.
Конечная цель такова: когда разработчики и агенты извлекают примитивы агентов из Artifactory, они могут быть уверены, что эти пакеты не просто управляемы, но также проверены и безопасны в использовании.
Готовы применить это на практике?
Защитите цепочку поставок ваших AI-агентов уже сегодня. Следуйте нашему полному руководству по внедрению в документации JFrog APM, чтобы узнать, как публиковать, использовать и контролировать примитивы ваших агентов с помощью Artifactory.
