Docker и CNCF: делаем то, что может делать агент, таким же переносимым, как и сам агент
Десять лет назад индустрия программного обеспечения столкнулась с выбором. Каждый вендор мог поставлять собственный формат образов и собственную среду выполнения, а разработчики должны были сделать выбор. Либо индустрия могла прийти к соглашению об одном артефакте. Второй вариант победил. Docker передал свой формат образов и среду выполнения Runc в Linux Foundation, и вокруг них сформировалась организация Open Container Initiative (OCI). Сегодня образ Docker, собранный где угодно, может запускаться где угодно. Этот формат является основой экосистемы облачных технологий и де-факто стандартом.
Теперь мы видим, как аналогичная проблема формируется вокруг агентов. Нет общего формата для того, что агенту разрешено делать. Мы предлагаем аналогичное решение: один артефакт, созданный на базе OCI и управляемый открыто.
Та же проблема, но для агентов
Контейнеры создавались для неизменяемого программного обеспечения. Образ — это и есть приложение. Если вы хотите изменить его, вы пересобираете его, и оно ведет себя одинаково везде. Именно поэтому образ контейнера описывает, как ПО собрано, и ничего не говорит о том, что оно может делать после запуска. Для веб-сервиса этого было достаточно. Он получал сеть и порт, и этого хватало.
Агенты по определению изменчивы. Claude Code и Codex устанавливают пакеты, вызывают API и используют учетные данные от вашего имени. Они меняют среду, в которой выполняются, и сами решают, что делать дальше. Поэтому каждая команда пишет свои собственные правила для того, к чему агент может получить доступ: сетевое правило здесь, токен там, монтирование тома для выполнения задачи. Эти правила хранятся в истории оболочки, на дашбордах и в чьей-то памяти. Через несколько месяцев никто не может ответить на простой вопрос: что этому агенту разрешено делать?
Сегодня каждая команда решает эту задачу самостоятельно, и каждый поставщик сред выполнения может предложить свой собственный способ ее решения. Именно такую фрагментацию была призвана предотвратить OCI.
Что мы анонсируем
Kit — не новшество. Наборы Kit уже были частью Docker Sandboxes как способ упаковать агента, его инструменты и то, к чему он может получать доступ, в нечто, чем команда может поделиться. Новым является сам артефакт. Теперь Kit — это обычный образ OCI, а описывающий его формат является открытым.
Сегодня на конференции WeAreDevelopers мы анонсировали спецификацию Docker Sandbox Kit Spec, выпущенную с открытым исходным кодом под лицензией Apache 2.0. Набор Kit объединяет в одном образе три вещи: агента, его инструменты и типизированный список всего, к чему он запрашивает доступ (например, хосты, учетные данные и томовые хранилища). Поскольку этот список является частью образа, фиксация версии образа жестко связывает агента и его запросы.
Kit — это не новый тип артефакта и не форк какой-либо спецификации OCI. Он использует точку расширения, уже определенную в OCI. Он собирается, отправляется, скачивается, подписывается и сканируется точно так же, как любой запускаемый вами сегодня образ, потому что им он и является.
Сегодня мы передаем эту спецификацию в CNCF под их нейтральным управлением, точно так же, как мы это сделали, когда формат образов перешел в OCI.
Почему это важно
Внедрение ничего не стоит. Поскольку Kit является образом OCI, с ним работает каждый используемый вами реестр, сканер и инструмент подписи. Не нужно развертывать ничего нового.
Ответ путешествует вместе с агентом. Поскольку запросы находятся внутри образа, на вопрос «что разрешено этому агенту?» есть единственный ответ. Коллега может вытянуть его. Проверяющий может сравнить изменения (diff). Совместимая среда выполнения может обеспечить их соблюдение. Когда новая версия запрашивает больше прав, изменение отображается в виде добавленных строк, которые кто-то может отклонить.
Экосистема, а не просто формат
Docker всегда придерживался философии «экосистема прежде всего». Dockerfile имел значение, потому что его мог написать любой, любой реестр мог сохранить результат, а любая среда выполнения могла запустить его. Наборы Kit следуют тому же подходу, и мы создавали их не в одиночку.
Мы работали с AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, Snyk и другими компаниями над созданием наборов Kit для их инструментов. Здесь представлены облачные платформы, средства наблюдаемости, безопасность, управление артефактами, контент и фреймворки для агентов. Наборы Kit, представленные нами сегодня во время основного доклада на WeAreDevelopers, являются результатом всей этой работы, и они лишь первые из многих.
MCP предоставил агентам стандартный способ взаимодействия с инструментом. Наборы Kit предоставляют экосистеме стандартный способ публикации всей структуры целиком: агента, его инструментов и того, к чему он запрашивает доступ, в виде одного образа, который может загрузить любой желающий. Именно это превращает формат в цепочку поставок. Например, поставщик базы данных может опубликовать Kit, который подключает любого агента к его сервису с рекомендуемыми правами доступа. Разработчик агента публикует собственный Kit, поэтому список запросов исходит от людей, создавших агента. Команда платформы публикует Kit для всей компании, и каждый инженер начинает работу с одной отправной точки.
Ничего из этого не произойдет, если формат принадлежит одному вендору. Стандарт для определения того, что разрешено агенту, теряет большую часть своей ценности, если он принадлежит тому, кто продает вам среду выполнения. Docker Sandboxes — первая среда выполнения, которая это обеспечивает. Она не должна быть единственной, и под управлением CNCF она такой не останется.
Контейнеры сделали ПО переносимым. Наборы Kit делают переносимыми полномочия: набор привилегий, которые вы осознанно передаете агенту, путешествует вместе с ним в том же образе и означает одно и то же везде, где его открывает совместимая среда выполнения.
«Стандарты позволяют экосистеме развиваться быстро и без фрагментации, и немногие компании понимают это лучше, чем Docker. Предоставляя Sandbox Kits в виде стандартных образов OCI, Docker дает индустрии открытый и повторяемый способ упаковки ИИ-агента, его инструментов и средств защиты в виде единого артефакта. OCI — это фундамент, на котором построена экосистема облачных технологий, поэтому стандарт для агентов на базе OCI охватывает всю экосистему сразу. CNCF приветствует это и рада сотрудничать с Docker и сообществом для обеспечения его широкого внедрения».
Крис Анисьчик (Chris Aniszczyk)
Технический директор (CTO) в CNCF
Создайте свой Kit
Если вы создаете инструменты, которые используют агенты, опубликуйте для них Kit. Если вы запускаете агентов, возьмите за основу готовый набор и поделитесь им со своей командой. Спецификация, страницы возможностей и подробный обзор реального набора Kit находятся по адресу docker/sandbox-kit-spec. Если вы столкнулись с Kit, который не можете описать, или правилом, которое среда выполнения не может реализовать, откройте тикет (issue). Каждый опубликованный Kit и каждый созданный тикет — это шаги, из которых строится стандарт.
