17 июля InfoQ рассказал о новом техническом разборе CNCF: фонд считает, что агентный ИИ не требует отдельной «магической» платформы, а вполне укладывается в уже зрелый стек cloud-native. Для русскоязычной IT-аудитории это важный сигнал: если компания уже живет на Kubernetes, Kafka, GitOps и нормальной наблюдаемости, входной билет в продакшен для автономных агентов может оказаться не таким экзотическим и дорогим, как любят обещать продавцы очередного AI-first всего.
Суть позиции CNCF довольно приземленная и потому полезная. Авторы анализа предлагают не смотреть на агентные системы как на принципиально новый класс инфраструктуры. По их логике, это все те же распределенные системы, только с дополнительным слоем рассуждений, вызовов инструментов и принятия решений. А раз так, то и проблемы знакомые: как выдавать сервисам идентичности, как оркестрировать долгие процессы, как хранить и передавать состояние, как отслеживать ошибки, как восстанавливаться после сбоев и кто потом ответит за странное действие агента в 03:17 утра. CNCF говорит прямо: последние десять лет cloud-native-сообщество как раз и решало эти задачи.
В качестве опорных технологий в материале названы Kubernetes, OpenTelemetry, Dapr, SPIFFE, Falco, Kafka и GitOps. Набор показательный. Kubernetes отвечает за оркестрацию и устойчивость исполнения, OpenTelemetry — за наблюдаемость, SPIFFE и SPIRE — за проверяемую идентичность нагрузок, Falco — за контроль runtime-угроз, Kafka — за событийное взаимодействие и буферизацию, GitOps — за управляемость изменений и воспроизводимость. Это не попытка прикрутить LLM к старому миру на изоленту, а скорее признание неприятного факта: чем умнее и самостоятельнее становятся агенты, тем скучнее и важнее становится базовая инженерия. Модели могут быть впечатляющими, но продакшен обычно ломается не на красивом демо, а на таймаутах, правах доступа, рассинхроне состояний и отсутствии трассировки.
Почему CNCF делает ставку на знакомый стек
В центре анализа — опыт создания многоагентной платформы кибербезопасности на Kubernetes. По описанию, это система для обнаружения и реакции на runtime-угрозы, где отдельные компоненты выполняют специализированные роли и координируются как часть общей архитектуры. Важный акцент: агенты здесь не заменяют традиционные средства безопасности и не пытаются играть в серебряную пулю. Они надстраиваются над уже существующей cloud-native-базой и добавляют уровень интеллектуального принятия решений. Для корпоративного рынка это, пожалуй, самая здравая часть всей истории. Бизнесу обычно не нужен «агентный ИИ» как красивый ярлык. Ему нужен способ встроить новые функции в уже работающую систему без полной замены платформы, процессов и команды.
Этот тезис особенно важен на фоне того, как быстро рынок уехал от экспериментальных AI-ассистентов к разговорам об автономных агентах, которые умеют вызывать инструменты, работать друг с другом и принимать операционные решения. На слайдах все выглядит бодро, но реальность быстро возвращает в мир ограничений. Если агент выполняется часами или днями, обращается к внешним сервисам, дергает API, переключается между задачами и передает эстафету другим агентам, он начинает вести себя как вполне взрослый распределенный ворклоад. Значит, ему нужны те же свойства, что и любому серьезному сервису: отказоустойчивость, предсказуемая оркестрация, контроль зависимостей, унифицированная политика безопасности и нормальная эксплуатация в hybrid- и multi-cloud-среде. Здесь Kubernetes для CNCF выглядит не модным выбором, а скучным и логичным.
Отдельный блок в разборе посвящен наблюдаемости, и тут авторы попадают в нерв проблемы. Обычное приложение трудно дебажить, когда оно падает под нагрузкой. Агент еще хуже: он принимает вероятностные решения, меняет поведение в зависимости от контекста, вызывает внешние инструменты и может делегировать часть работы другим агентам. Простых метрик вроде latency, throughput и error rate уже недостаточно. В продакшене нужно понимать не только то, что агент сделал, но и почему он так сделал, какие инструменты вызвал, в каком контексте работал и как его решение повлияло на остальную систему. Поэтому OpenTelemetry в такой архитектуре становится не nice to have для красивого дашборда, а основой расследования инцидентов и аудита действий. Для разработчиков это означает дополнительную работу на этапе проектирования: если трассировка цепочки рассуждений и вызовов не встроена сразу, потом ее не получится быстро дорисовать поверх хаоса.
Безопасность и управление выходят на первый план
Еще одна сильная линия в материале — безопасность. Чем больше полномочий получают агенты, тем хуже работает привычная модель «ну это же просто сервисный аккаунт». Если агент имеет доступ к чувствительным API, бизнес-процессам и инфраструктуре, нужна криптографически проверяемая идентичность нагрузки, понятный контур полномочий и история исполнения, которой можно доверять. Именно поэтому CNCF ссылается на SPIFFE и SPIRE, а также отмечает более широкий сдвиг в отрасли: системы ИИ должны уметь доказывать не только то, какое решение было принято, но и кем именно, на каком основании и не была ли история выполнения подменена по дороге. В этот же контекст в источнике помещены Verifiable Execution в Dapr 1.18 и инициатива Akrites под эгидой Linux Foundation. Сигнал понятен: доверие к агентам все меньше связано с качеством презентации и все больше — с проверяемостью исполнения.
Для российских команд это чтение полезно еще и потому, что оно слегка остужает рынок. В последние два года разговор об ИИ часто сводился к моделям: у кого контекст длиннее, у кого лучше reasoning, у кого ниже цена токена. CNCF смещает фокус туда, где обычно болит у реальных команд: эксплуатация, безопасность, наблюдаемость и управление изменениями. Для CTO и платформенных инженеров вывод прагматичный. Если в компании уже есть зрелая cloud-native-практика, то путь к агентным сценариям скорее проходит через донастройку существующего стека, чем через закупку отдельной «AI-инфраструктуры». Для продуктовых команд это тоже неприятно, но честно: ограничителем становится не интеллект модели как таковой, а способность системы надежно жить в продакшене и не устраивать сюрпризы соседним сервисам.
Главный вопрос теперь не в том, появятся ли у компаний агенты, а в том, кто быстрее научится обращаться с ними как с полноценными распределенными системами, а не как с красивым плагином к чату. Если подход CNCF приживется, рынок агентных платформ будет все меньше походить на гонку за самым умным промптом и все больше — на старую добрую дисциплину platform engineering, только с куда более неприятной ценой ошибок.