88 % пилотов не доходят до продакшена: Wood Mackenzie заменила три агентных стека одной платформой APEX

Разрыв между прототипом и продакшеном

Рабочий прототип агента собирается за один день, а основная работа начинается при выводе в продакшен: как только агент обслуживает больше одного пользователя, появляется новый слой инженерии и становится критично понимать, делает ли агент правильные вещи на реальном трафике. Конкурентность, изоляция сессий, идентичность, постоянное состояние, масштабирование и guardrails — слои, которые большинство команд пересобирает с нуля, тогда как стандартизованная платформа даёт воспроизводимый подход.

Разрыв измеряется цифрами: отраслевые опросы к началу 2026 года показывают почти всеобщий интерес к экспериментам с ИИ, но лишь около четверти организаций довели агентов до продакшена хотя бы в одной функции, а внутри Wood Mackenzie 88 % ИИ-пилотов не доходят до широкого развёртывания.

Причины, по публикации, в основном архитектурные: Forrester относит провалы агентов преимущественно к неоднозначности, рассогласованию и непредсказуемому поведению систем, а самый часто называемый единичный блокер — оценка качества и наблюдаемость, потому что команды не могут заранее надёжно определить, когда недетерминированный агент ошибётся. Следом идут управление и идентичность: значительная доля руководителей сообщала, что не смогла бы немедленно остановить неисправного агента. В основе — дублирование: каждая команда заново реализует аутентификацию, guardrails, память и трассировку и жёстко фиксирует модель, из-за чего смена провайдера означает переписывание кода.

Почему AgentCore: пять критериев

Перед APEX три приложения — Woody, Lens AI и ST Trading App — шли к собственному агентному стеку: каждое подняло бы свой runtime, свою идентичность, свою наблюдаемость и свою жёстко зашитую модель, и инфраструктурный налог был бы уплачен трижды. Платформу выбирали по требованиям продакшена — модель хостинга, модель стоимости, независимость от модели, масштабируемость, управление и корпоративная поддержка.

AgentCore даёт управляемую платформу вместо библиотеки, которую пришлось бы эксплуатировать самим, работает с любым открытым фреймворком, включая Strands Agents, LangGraph, LangChain, LlamaIndex, CrewAI, Google ADK и OpenAI Agents SDK, и с любой моделью — независимо от того, работает она на Amazon Bedrock или нет, а также поддерживает Model Context Protocol (MCP) и протокол Agent-to-Agent (A2A).

Первые три решающих свойства названы так: управляемая инфраструктура без кластера в эксплуатации, где AWS берёт на себя масштабирование, патчи и доступность, а на общей доступности (GA) в октябре 2025 года все сервисы получили поддержку Amazon Virtual Private Cloud (VPC), AWS PrivateLink, AWS CloudFormation и тегирования ресурсов. Независимость от модели означает, что Claude, GPT-4.1, Amazon Nova, Mistral и Llama доступны через одну платформу, поэтому команда может планировать одной моделью и исполнять другой или уйти с модели, получившей регрессию, не теряя контекст диалога и не трогая бизнес-логику. Автоматическое масштабирование — это AgentCore runtime, который идёт от нуля до тысяч одновременных вызовов агентов без планирования ёмкости, с полной изоляцией сессий и окнами исполнения до 8 часов.

Четвёртое — нативные guardrails и идентичность: фильтрация контента, обнаружение персональных данных и применение политик стали управляемыми возможностями, а Policy в Amazon Bedrock AgentCore интегрируется с Gateway, перехватывает каждый вызов инструмента в реальном времени и превращает правила на естественном языке в Cedar — открытый язык политик AWS. Пятое — корпоративная поддержка AWS Enterprise Support с доступом 24/7 и техническим аккаунт-менеджером.

Оплата устроена за потребление, без предоплат и минимальных платежей: каждый сервис биллингуется отдельно, поэтому можно взять одну возможность вроде AgentCore memory, не мигрируя всего агента, а runtime считает по активному потреблению CPU и памяти за секунду, причём при ожидании ввода-вывода расходы CPU не начисляются. Для агентных нагрузок это существенно: они обычно проводят 30–70 % времени в ожидании ответов модели, вызовов инструментов или запросов к базе, и при предзарезервированных вычислениях за это простаивающее время пришлось бы платить.

Слои APEX: от фронтенда до наблюдаемости

APEX организована слоями: конечные пользователи работают с Woody, Lens AI и ST Trading App, а те обращаются к фронтенду APEX, который позволяет добавлять агентные возможности в интерфейс без пересборки подключения к бэкенду. Рядом идут две инфраструктурные дорожки: WM IaC Framework на AWS Cloud Development Kit (AWS CDK) и GitHub провижинит платформенные ресурсы с guardrails, описанными кодом, а слой MCP связывает платформу с внешними системами по стандартному протоколу.

Бэкенд работает на AgentCore (Runtime, Identity, Gateway, Memory, Observability) и включает оркестратор, векторную базу для поиска, доступ к моделям через каталог Amazon Bedrock и Amazon Bedrock Guardrails. Идентичность и полномочия вплетены в каждый вызов агента, а не проверяются один раз на периметре, поэтому агент, действующий от имени пользователя, несёт его права через все последующие вызовы инструментов и данных; источником истины в Wood Mackenzie служит Okta.

Оркестратор маршрутизирует запрос и обращается к Woodmac Agent Registry — единому месту для обнаружения и переиспользования агентов, инструментов и навыков с встроенными управлением и согласованием, благодаря чему агент одной команды становится доступен другой без копирования кода. Внутри AgentCore runtime работает AI Agents Studio, построенная на Amazon Quick со Strands Agents, LangGraph, CrewAI, n8n, Vertex и OpenAI: каждая команда сохраняет предпочитаемый фреймворк, а runtime вызывает модели через каталог Amazon Bedrock, где агент указывает модель по имени и провайдера можно заменить без переписывания агента.

Инструменты выданы как композируемые блоки: Code Interpreter отвечает за безопасное исполнение кода, веб-инструмент на Amazon Nova Act — за действия в браузере, а доступ идёт через AgentCore Gateway, который превращает API, функции AWS Lambda и существующие MCP-серверы в совместимые с агентами инструменты и поддерживает аутентификацию через IAM, OAuth 2.1 и API-ключи. Ответы заземляются на собственных данных: для RAG используется Amazon Bedrock Knowledge Bases, а AgentCore memory даёт краткосрочный и долгосрочный контекст, чтобы диалог сохранялся между сессиями и агенты разделяли состояние.

Наблюдаемость и оценка определяют, выживет ли агент в продакшене: вывод недетерминирован, поэтому главный вопрос не «работает ли он», а «можем ли мы понять, когда он перестал работать». AgentCore Observability отдаёт телеметрию в формате, совместимом с OpenTelemetry, в Amazon CloudWatch — число сессий, задержка, длительность, расход токенов, частота ошибок — и позволяет проследить один запрос от сессии до отдельного span. AgentCore Evaluations добавляет встроенные оценки по полезности, выбору инструментов и точности плюс заказное модельное скорингование, чтобы оценивать агентов на реальном трафике.

APEX Studio и хаб-модель на AgentCore Gateway

APEX Studio — это back office над runtime: единый интерфейс, где команда собирает, разворачивает и наблюдает агентов, не касаясь инфраструктуры, а жизненный цикл покрывают шесть возможностей — Agent Builder с шаблонным созданием агента, Workflow Designer с ветвлениями, циклами и шагами с участием человека, Connector Registry для публикации совместимых с MCP коннекторов, Live Chat Testing для проверки на реальных входах до деплоя, App Deployment и Monitoring Dashboard. Под Studio лежит встроенная интеграция жизненного цикла разработки, названная vibe coding: агента можно создать на естественном языке, с автотестами, предпросмотром и развёртыванием одним кликом, поэтому путь от идеи до управляемого продакшен-агента измеряется часами.

Самую большую работу выполняет модель «хаб и спицы» на AgentCore Gateway: без неё каждый потребитель поддерживал бы отдельное подключение к каждому сервису данных, и при N потребителях и M сервисах это задача N×M, где каждое новое приложение умножает число соединений точка-точка, а каждое соединение заново реализует одни и те же сквозные задачи.

В этой модели внутренний аналитик, клиентский чатбот и торговый агент говорят с одним хабом, а gateway разветвляется к Lens Direct для аналитики и кривых, Short Term Trading для исполнения в реальном времени, Digital Content для моделирования upstream и калькуляторам P&R Dataset, так что новый потребитель или сервис — это одна новая спица, а не пересборка всей сетки. Поскольку трафик идёт через один хаб, сквозные задачи — идентичность, наблюдаемость, оценка и guardrails, навыки и инструменты, ограничение частоты запросов, защита данных и комплаенс — применяются один раз: изменение политики вступает в силу везде в момент применения на хабе, а gateway говорит на Model Context Protocol (MCP) и даёт единый интерфейс инструментов независимо от того, что стоит за каждой спицей.

Генеративный интерфейс: AG-UI, A2UI и Strands

Презентационный слой решён так же, как связность — общими протоколами: фронтенд-SDK APEX построен на двух дополняющих протоколах, а веб-компоненты и инструментарий даёт CopilotKit. AG-UI — транспорт: двустороннее событийное соединение между агентным бэкендом и приложением, несущее поток типизированных событий, от стриминга токенов до вызовов инструментов и обновлений состояния, по стандартному HTTP или Server-Sent Events.

A2UI — полезная нагрузка: декларативная спецификация генеративного интерфейса, происходящая от Google, с помощью которой агент возвращает интерфейс как JSON-описание компонентов, а не текст или исполняемый код; клиент рендерит компоненты из каталога доверенных нативных виджетов, что сохраняет стиль принимающего приложения и исключает произвольное исполнение кода. Коротко: A2UI описывает, что агент хочет показать, AG-UI это доставляет, клиент это рендерит.

Сами агенты — это агенты Strands в AgentCore runtime, а Strands интегрируется с AG-UI напрямую, давая три возможности, которые переиспользуют Woody, Lens AI и ST Trading App: стриминговый чат, генеративный интерфейс на основе инструментов и разделяемое состояние. Во втором случае клиент сопоставляет вызов инструмента с отрендеренным компонентом, поэтому результат исполнения в реальном времени из Short Term Trading возвращается живым виджетом, а не стеной текста.

Пример — Synapse AI, генеративный ассистент внутри Lens: на дашборде Power Summary пользователь спрашивает обычным языком, у каких стран больше всего возобновляемых мощностей, и агент вызывает инструмент extractWidgetConfig, который читает конфигурацию и данные ранжирующих виджетов уже открытого дашборда, после чего возвращает таблицу солнечных и ветровых мощностей по странам прямо в диалоге. В Woody тот же протокол несёт длинный сценарий: аналитик одной инструкцией просит изучить влияние конфликта вокруг Ирана на цены на нефть по веб-источникам и данным Lens Direct, построить графики и собрать презентацию, и агент последовательно использует веб-поиск, MCP-сервер Lens Direct, диаграммы Vega-Lite и генератор PowerPoint, выдавая четыре интерактивных графика и презентацию из 15 слайдов.

Отдельный сценарий Woody показывает человека в контуре на операциях с высокими ставками: агент работает с веткой модели внутреннего спроса на газ в GitHub и останавливается на явном контрольном шаге, сообщая, что файл GUIDANCE.md требует проверки, и перечисляя точные правки, нужные в train.py или inference.py до запуска обучения, — и не продолжает, пока аналитик не подтвердит.

Одна платформа и шесть принципов

Lens и Woody работают на одной инфраструктуре: Woody обслуживает внутренних пользователей, Synapse в Lens — внешних, а MCP-коннекторы открывают данные партнёрским системам, и во всех случаях это один AgentCore runtime, один gateway, один каталог моделей, одна наблюдаемость и одни guardrails. Отличаются не стек, а контроль доступа на хабе: идентичность передаётся через каждый вызов агента, поэтому одни и те же полномочия определяют, что может обучать внутренний аналитик, что может запрашивать внешний потребитель и к чему имеет доступ MCP-клиент партнёра.

Платформу держат шесть принципов: композируемые строительные блоки, «раскрутка маховика», при которой решение задачи для одной команды становится общим для всех, как вышло с доступом к инструментам с учётом идентичности для Lens AI, унаследованным приложением ST Trading App, абстрагирование недифференцированной тяжёлой работы, централизованной в платформе, компонентизация ради переиспользования через golden paths и переиспользуемые SDK, разделённая эволюция с отделением платформенного кода от бизнес-логики и накопление ценности, при котором каждая подключившаяся команда делает следующую быстрее.

Что дальше: мультиагентные системы

Одиночный агент — начало, а не пункт назначения: направление на 2026 год — мультиагентные системы, где агенты разных команд, а в перспективе и организаций, координируются для работы, недоступной одному агенту. Переход держится на двух открытых протоколах: MCP — вертикальный уровень связи агента с инструментами и данными, уже стандартизованный шлюзом, а Agent-to-Agent (A2A) — горизонтальный уровень, позволяющий агентам обнаруживать друг друга и делегировать задачи; A2A перешёл под управление Linux Foundation при широкой поддержке вендоров, а AgentCore runtime уже поддерживает A2A.

Из уже построенного следуют три расширения: агент-агентные рабочие процессы между собственными доменами, управляемое внешнее сотрудничество через тот же MCP-endpoint под действующими полномочиями и аудитом и более глубокая автономия с контролем, где AgentCore Evaluations на живом трафике сочетаются с Policy на каждом вызове инструмента.

Вывод в публикации сформулирован без прикрас: большинство агентных программ останавливается не из-за недостаточной модели, а из-за отсутствия инфраструктуры вокруг неё — общего runtime, согласованной оценки, управляемой идентичности и продублированной обвязки, которую пересобирают под каждый сценарий.