AI-агенты стали неотъемлемой частью современного процесса разработки.
Они пишут код, проверяют pull-реквесты, генерируют тесты, вызывают инструменты, взаимодействуют с MCP-серверами и помогают разработчикам работать быстрее. Но за каждым полезным агентом стоит нечто столь же важное, как и сама модель: контекст, который определяет поведение агента.
Этот контекст может включать навыки, промпты, инструкции, хуки, команды, скрипты, ссылки и определения MCP-серверов.
В небольшом проекте управлять этими примитивами довольно просто. Возможно, вы единственный разработчик, работающий над репозиторием. То, что вы видите локально, — это всё, что существует. Вы знаете, какие промпты используются, какие инструкции были добавлены и какие инструменты подключены.
Но когда это становится командной работой, возникает множество вопросов:
- Как убедиться, что каждый разработчик использует одни и те же инструкции для агента?
- Как узнать, что у всех установлена последняя версия общего навыка?
- Как предотвратить негласное изменение промпта, хука или навыка кем-либо из участников?
- Как контролировать, кто имеет право публиковать, обновлять или использовать эти примитивы агентов?
- Как применять управление, контроль доступа и рабочие процессы утверждения до того, как эти примитивы попадут к разработчикам и инструментам AI-кодинга?
И самое главное: как убедиться, что эти примитивы агентов поступают из надежного источника?
Именно здесь на помощь приходит APM — Agent Package Manager (менеджер пакетов агентов).
Что такое APM?
APM — это менеджер пакетов с открытым исходным кодом для примитивов агентов. Он привносит привычную модель управления пакетами в мир AI-агентов, позволяя командам определять навыки, промпты, инструкции, хуки, команды и 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 определяет, как агент должен помогать с сообщениями в pull-реквестах и стандартами проверки. jfrog/build-test-instructions предоставляет агенту ожидаемое командой поведение при сборке и тестировании. jfrog/artifactory-mcp объявляет утвержденную конфигурацию MCP-сервера, которую агент может использовать при взаимодействии с Artifactory.
Вместо того чтобы копировать эти файлы вручную между проектами, команда объявляет их один раз в apm.yml. Когда разработчик запускает apm install, APM извлекает утвержденные версии из JFrog и размещает их в нужном месте для использования выбранными инструментами AI-кодинга.
Воспроизведение одного и того же контекста агента везде
Когда разработчик запускает:
APM считывает файл apm.yml проекта, разрешает объявленные зависимости примитивов агента, извлекает необходимые пакеты и записывает соответствующие ресурсы в проект в структуре, которую могут использовать выбранные инструменты AI-кодинга.
Это означает, что навыки, промпты, инструкции, хуки, команды, скрипты и декларации MCP не копируются вручную из одного репозитория или страницы вики в другой. Они устанавливаются как версионируемые зависимости.
Это важно, потому что настройка агента становится воспроизводимой.
Первая установка разрешает точные версии пакетов и содержащиеся в них ресурсы. Эти разрешенные версии вместе с хешами содержимого фиксируются в lock-файле. Добавляя этот lock-файл в проект, каждый разработчик, запускающий apm install, получает один и тот же разрешенный контекст агента.
Не «примерно те же инструкции». Не «то, что было последним на момент копирования файла». Те же версии. Те же ресурсы. Та же настройка агента.
Поэтому, когда новый разработчик присоединяется к проекту, меняет компьютер или делает свежий клон, он может воссоздать ту же среду агента, которую использует остальная часть команды. И когда команда решает обновить общий навык или инструкцию, это обновление может произойти осознанно через рабочий процесс с зависимостями и lock-файлом, а не через копирование и вставку.
Один файл apm.yml. Один общий lock-файл. Один согласованный контекст агента на каждой машине разработчика.
Чем может управлять APM?
APM может управлять различными типами зависимостей агентов, включая навыки, промпты, инструкции, агентов, хуки, команды и MCP-серверы. Он не ограничивается одним типом файла или конфигурации. Исходный документ содержит таблицу, в которой примитивные типы разбиты по категориям и объясняется, как каждый из них вписывается в рабочий процесс агента.
Здесь APM становится чем-то большим, чем просто удобный инструмент. Он создает структурированный способ обмена, версионирования и воспроизведения примитивов, которые формируют поведение агента.
Как только что-то становится частью рабочего процесса разработки программного обеспечения, это также требует управления.
Недостающее звено: доверенный реестр
Управление примитивами агентов локально полезно, но локального управления недостаточно. Даже когда команды хранят свои навыки, промпты, инструкции, хуки и конфигурации MCP во внутренних Git-репозиториях, им все равно приходится иметь дело с проверкой, обновлениями, расхождением версий и управлением зависимостями в нескольких репозиториях.
Это может работать для небольшой команды, но быстро становится болезненным при масштабировании. Теперь каждый проект должен знать, из каких репозиториев выполнять извлечение, какую версию использовать, когда обновлять и как убедиться, что нужные файлы доступны в нужном месте для использования агентом.
И есть еще одна практическая проблема: Git-репозитории не всегда могут быть доступны агентам, работающим ближе к производственной среде, внутри контролируемых сред или в пределах ограниченных сетевых границ. В таких случаях полагаться на Git как на механизм распространения примитивов агентов во время выполнения становится ненадежно.
Предприятиям нужен надежный способ публикации, потребления, контроля и аудита этих пакетов через надлежащую модель реестра. Без этого разработчики могут в конечном итоге извлекать инструкции агентов, навыки, скрипты или конфигурации MCP из разрозненных репозиториев, устаревших копий или случайных мест в интернете — создавая новую проблему цепочки поставок программного обеспечения.
Навык агента — это не «просто промпт». Хук — это не «просто вспомогательный скрипт». Определение MCP-сервера — это не «просто конфигурация».
Эти примитивы формируют то, что видит AI-агент, что ему разрешено делать и какие инструменты он может вызывать — по сути, влияя на качество, безопасность и согласованность результата, который производит агент.
Это означает, что ими следует управлять с той же дисциплиной, которую мы уже применяем к программным пакетам.
Поддержка пакетов APM в JFrog
JFrog теперь позволяет использовать APM с платформой JFrog через новый тип репозитория Agent Packages.
Это означает, что организации могут публиковать и использовать пакеты APM напрямую через JFrog Artifactory, вместо того чтобы полагаться на нескоординированные или ненадежные источники.
Благодаря интеграции APM и JFrog команды могут:
- Публиковать пакеты APM во внутреннем доверенном реестре Artifactory
- Использовать пакеты APM из этого доверенного реестра
- Делиться одобренными примитивами агентов между командами
- Поддерживать согласованное поведение агентов в разных проектах и на разных машинах
- Управлять контекстом AI-агентов с помощью той же платформы, которой они уже доверяют для управления программными пакетами
Как работает JFrog для пакетов APM?
Со стороны JFrog процесс начинается с создания нового репозитория типа Agent Packages.
Затем необходимо настроить APM для работы с этим реестром, выполнив следующие команды:
Все очень просто! С этого момента разработчики могут использовать APM для отправки и получения пакетов агентов в 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 предоставляет организациям общий доверенный реестр, управление и контроль корпоративного уровня, необходимые для безопасного использования этой модели в масштабе. Вместе они позволяют управлять контекстом AI-агентов так же, как современные команды разработчиков уже управляют программными пакетами.
Что дальше
Управление примитивами агентов как пакетами — это первый шаг. Следующий шаг — их защита. JFrog уже работает над уровнем безопасности, который анализирует пакеты APM по мере их отправки в Artifactory. Он будет проверять навыки, промпты, инструкции, хуки, команды и определения MCP на наличие вредоносных инструкций, скрытых манипуляций, небезопасного поведения и рискованных шаблонов конфигурации. Это позволит командам контролировать примитивы агентов, как и любой другой компонент цепочки поставок программного обеспечения: публиковать в доверенном реестре, проверять перед использованием и потреблять только после прохождения контроля безопасности организации.
Конечная цель такова: когда разработчики и агенты извлекают примитивы агентов из Artifactory, они могут быть уверены, что эти пакеты не просто управляются, но и проверены и безопасны для использования.
Готовы применить это на практике?
Обеспечьте безопасность цепочки поставок ваших ИИ-агентов уже сегодня. Ознакомьтесь с нашим полным руководством по внедрению в документации JFrog APM, чтобы узнать, как публиковать, использовать и контролировать примитивы ваших агентов с помощью Artifactory.
