В чём проблема: данные есть, а решения нет
Менеджер по цепочке поставок тратит 45-60 минут каждое утро, чтобы собрать картину дня из пяти систем: ERP с исключениями по остаткам, инструмент мониторинга с алертами, система закупок с альтернативными поставщиками, почта и отдельный трекер задач. По ходу больше дюжины переключений контекста, и ни одно из них не добавляет информации к самой задаче. AWS формулирует это состояние так: цепочки поставок богаты данными и бедны инсайтами. Дефицита данных нет, есть дистанция между данными и человеком, который принимает решение.
Паттерн AWS сокращает эту дистанцию двумя продуктами. Amazon Bedrock AgentCore публикует корпоративные MCP-серверы (ERP, мониторинг, закупки, почта) как управляемый слой инструментов. Amazon Quick превращает этот слой в один диалоговый вход для бизнес-пользователей. Ответы приходят из живых систем учёта и обоснованных документов, а каждое изменение ждёт подтверждения названного человека.
Сравнение простое: тот же утренний цикл в диалоговом режиме укладывается в три промпта в одном инструменте и занимает минуты. В примере AWS они выглядят так: «Есть ли критичные сбои по SKU с наибольшей выручкой?», «Оцени остановку TechComp и выпусти экстренный RFQ по одобренным альтернативам», «Выглядит нормально, отправляй».
Что такое Amazon Quick и Bedrock AgentCore и как они делят роли
AgentCore отвечает за слой инструментов и логику их вызова. Quick отвечает за диалог: пользователь формулирует вопрос на естественном языке, видит ответ, подтверждает действия. AWS Agent Registry держит каталог MCP-серверов и делает их обнаруживаемыми, чтобы Quick подключал их без ручной сборки интеграций.
Разница видна на моменте подключения. Администратор включает интеграцию с реестром, и четыре бизнес-MCP-сервера появляются в Quick как карточки коннекторов с уже заполненными данными подключения, URL вводить руками не нужно (пример AWS). Оркестрационный агент подключается отдельным MCP-коннектором и координирует вызовы инструментов между собой.
Вторая часть контракта важнее первой: ответ строится на записях из систем учёта и на документах, которые можно проверить, а не на памяти модели. Отсюда и ограничение: качество ответа упирается в качество данных в ERP и в качество описания инструментов.
Почему MCP, а не кастомные интеграции под каждый сервис
MCP задаёт способ упаковки корпоративной системы в инструменты, которые вызывает оркестрация. Один MCP-сервер переиспользуется разными агентами и интерфейсами: сервер для ERP не нужно переписывать под каждый новый сценарий или новый чат-клиент. Для цепочки поставок это даёт четыре независимых сервера вместо одной монолитной интеграции, и каждый обновляется отдельно.
Детали спецификации протокола и требования к реализации серверов сверяйте с официальной документацией MCP и AWS: разобранный пример показывает рабочий сценарий, а не полное описание протокола. Про управление жизненным циклом агентов, MCP и skills в каталоге есть отдельный разбор: AWS Agent Registry как корпоративный каталог.
Архитектура решения: Runtime, Gateway, Identity, Policy
Паттерн опирается на четыре компонента AgentCore. Runtime исполняет агентов и инструменты, Gateway служит точкой подключения MCP-серверов, Identity отвечает за идентификацию пользователей и сервисов, Policy задаёт правила доступа и допустимых действий. В доступном фрагменте публикации AWS эти компоненты не разобраны по отдельности, поэтому конкретные лимиты, схемы аутентификации и синтаксис политик сверяйте с документацией Amazon Bedrock AgentCore, а не с этим текстом.
Публикация в AWS Agent Registry связывает архитектуру с интерфейсом: сервер, появившийся в реестре, становится обнаруживаемым для Quick и превращается в карточку коннектора. Похожая конструкция разобрана в материале про Connected Analytics от AvioBook на AgentCore, где MCP-инструменты живут в Gateway, а изоляция данных идёт через JWT и Cognito.
Как запрос проходит от Quick до ERP: пошагово
- Пользователь пишет запрос в Quick: «Check active supply disruptions».
- Quick маршрутизирует его через AgentCore к нужному MCP-серверу, а не обращается к ERP напрямую.
- Disruption Alerts MCP вызывает инструмент assess_disruption_impact и возвращает три сбоя с указанием серьёзности, региона и количества SKU (описание шага у AWS).
- Ответ приходит с привязкой к источнику: видно, из какой системы взяты цифры.
У каждого MCP-сервера своя зона ответственности. ERP отдаёт остатки и исключения по инвентарю, мониторинг отдаёт алерты, закупки отвечают за альтернативных поставщиков и выпуск RFQ, почта поставляет сигналы о проблемах и служит каналом коммуникации. Такое деление упрощает отладку: сломанный ответ локализуется на одном сервере.
Безопасность и human-in-the-loop: почему человек подтверждает каждое изменение
Принцип паттерна сформулирован прямо: каждое изменение ждёт подтверждения названного человека. Чтение и анализ идут без остановок, запись в корпоративную систему требует явного согласия. Это делает агентные действия аудируемыми: в логе остаётся, кто именно подтвердил выпуск RFQ и на каких данных строился расчёт.
Разграничение доступа опирается на Identity и Policy: бизнес-пользователь видит и запускает только разрешённые ему инструменты, а действия с финансовыми последствиями требуют отдельного подтверждения. Конкретную матрицу ролей в доступном фрагменте AWS не приводит, её проектируют под свои системы и организационную структуру. Родственная логика, где ИИ предлагает, человек утверждает, а детерминированный исполнитель применяет только допущенные действия, разобрана в методологии Agent-Ops 0.4.0.
Что именно подтверждает человек и в какой момент
В сквозном сценарии ключевая точка подтверждения одна и она же финальная: перед выпуском экстренного RFQ. Менеджер видит проект запроса, список альтернативных поставщиков и обоснование, после чего отправляет его. Любые изменения в системах после этого шага проходят тот же барьер.
Эффект двойной. Агент не может самовольно разослать запросы поставщикам. Скорость на этапе анализа при этом не страдает: чтение, сравнение и расчёты идут без пауз на согласование. Плата за это - дополнительный клик в момент изменения, и в сценариях с высокой частотой мелких правок он заметен.
Сквозной сценарий: от сбоя поставок до экстренного RFQ в одной беседе
Пять шагов сценария проходят в одной беседе Amazon Quick, без переключения между пятью системами. Важная оговорка: в доступном фрагменте публикации AWS детально раскрыт только шаг обнаружения сбоя. Остальные шаги ниже описаны на уровне логики паттерна, конкретные инструменты, названия полей и параметры сверяйте с репозиторием примера.
Шаги 1-2: обнаружение сбоя и оценка риска
Запрос «Check active supply disruptions» вызывает assess_disruption_impact и возвращает три сбоя с серьёзностью, регионом и количеством затронутых SKU. Дальше начинается оценка риска: какие позиции из списка критичны, сколько запаса на складе, какие заказы уже в пути. Источник этих данных - ERP, и ответ ссылается на живые записи.
Границы доверия понятные. Если в ERP остатки ведутся с задержкой или исключения по инвентарю не помечены, оценка риска будет аккуратной по форме и неверной по сути. Пример вопроса, который требует кросс-системного ответа: какие SKU с наибольшей выручкой попадают под текущее закрытие порта и во сколько это обойдётся.
Шаги 3-5: альтернативы, проверка и выпуск RFQ
Система закупок отдаёт список одобренных альтернативных поставщиков с условиями. Почта используется дважды: как источник сигналов о сбоях и как канал, по которому уходит запрос. Финальный шаг - экстренный RFQ, который не отправляется без подтверждения названного человека.
Логика Policy на этом шаге простая: действие с внешним эффектом требует явного разрешения. Сравните с чтением данных, где достаточно прав на просмотр. Такое разделение позволяет открыть доступ к анализу широкому кругу сотрудников, а запись оставить узкой роли.
Автоматический мониторинг: по расписанию и по входящей почте через Activity Feed
Разовый сценарий превращается в фоновый процесс двумя триггерами. Первый - расписание: агент периодически проверяет активные сбои и исключения по инвентарю и готовит сводку. Второй - входящая почта: письмо о проблеме от поставщика или логиста становится задачей для агента, который сам поднимает связанные данные из ERP и закупок.
Результаты обеих проверок собираются в Activity Feed, ленте активности Quick. Там видно, что агент проверил, что нашёл и какие действия предложил. Для менеджера это способ начать день с готового списка, а не со сбора данных по пяти окнам.
Автоматизация касается чтения и анализа. Изменения по-прежнему проходят через подтверждение человека, поэтому фоновая проверка не превращается в фоновые закупки. Частоту проверок, лимиты и точный набор поддерживаемых триггеров в доступном фрагменте AWS не приводит: эти параметры нужно уточнять по документации продукта перед настройкой.
Как развернуть open-source пример: пошаговая инструкция
Пример AWS выложен для самостоятельного развёртывания. Команды, версии зависимостей и параметры стенда берите из официального репозитория и документации AWS: ниже последовательность шагов на уровне логики, без выдуманных команд.
- Подготовить окружение AWS: аккаунт, права, регион, где будут работать агенты и MCP-серверы.
- Развернуть четыре MCP-сервера: ERP, мониторинг, закупки, почта. Каждый получает описание инструментов, по которому оркестрация понимает, что и когда вызывать.
- Опубликовать серверы в AWS Agent Registry, чтобы они стали обнаруживаемыми для Quick.
- Настроить AgentCore: Runtime для исполнения, Gateway для подключения серверов, Identity для идентификации, Policy для правил доступа.
- Подключить оркестрационный агент отдельным MCP-коннектором.
- Включить в Quick интеграцию с реестром и проверить, что карточки коннекторов появились с предзаполненными данными подключения.
Похожая по духу практика с другим сценарием разобрана в руководстве про автоматизацию обработки RFI-опросников на Amazon Quick Automate: чтение файлов из S3, логика промптом и честный список неизвестных лимитов.
Что проверить после развёртывания
- MCP-серверы видны в Quick как коннекторы, URL вручную не вводился.
- Тестовый запрос «Check active supply disruptions» возвращает данные из Disruption Alerts MCP, а не общий ответ модели.
- Разграничение по ролям работает: пользователь без прав не видит и не запускает запрещённые инструменты.
- Изменение без подтверждения не проходит: попытка отправить RFQ упирается в шаг согласования.
- В Activity Feed появляются результаты автоматических проверок.
Диалоговый подход против традиционного BI: что дополняет, а что заменяет
Разговор о замене дашбордов появляется каждый раз, когда выходит очередной ассистент. В разобранном паттерне речь о другом: диалоговый слой закрывает путь от вопроса к действию, а BI закрывает обзор и стандартизированную отчётность. Это оценка на основе сценария AWS, независимых замеров эффекта в публикации нет.
| Критерий | Quick + AgentCore | Дашборд / BI |
|---|---|---|
| Тип вопроса | Конкретный, с продолжением в действие | Обзорный, повторяющийся |
| Время до ответа | Три промпта, минуты | Зависит от готовности отчёта |
| Действие | Выпуск RFQ в той же беседе, с подтверждением | Обычно вне инструмента |
| Сравнение периодов и срезы | Возможно, но это не основной сценарий | Сильная сторона |
| Воспроизводимость | Зависит от формулировки и данных | Фиксированные метрики |
Практический вывод: 45-60 минут и дюжина переключений контекста против трёх промптов выигрывают там, где решение нужно сейчас и требует действия. Ежемесячный отчёт по оборачиваемости склада удобнее смотреть в дашборде, где метрика определена один раз и считается одинаково для всех.
Ограничения и риски: что важно знать до запуска
- Качество ответов зависит от данных. Остатки в ERP с задержкой или неразмеченные исключения дают уверенный и неверный ответ.
- MCP-серверы нужно разрабатывать и поддерживать. Это код, который живёт вместе с изменениями в корпоративных системах.
- Реестр и интеграция требуют административной настройки: без включённой интеграции карточки коннекторов не появятся сами.
- Human-in-the-loop снижает скорость изменений. Для массовых мелких правок барьер подтверждения может стать узким местом.
- Governance и разграничение доступа требуют продуманной Policy. Ошибка в правилах дороже, чем ошибка в промпте.
- Паттерн описан AWS на одном домене, цепочке поставок. Перенос на финансы, HR или поддержку потребует других инструментов и других проверок.
- Независимой проверки и количественных замеров эффекта в публикации нет: сравнение 45-60 минут с «минутами» взято из материала AWS.
Отдельно про зрелость: реестр и связка с Quick описаны на конкретном примере, а не как универсальный продукт с гарантированным поведением в любом окружении. Перед пилотом стоит проверить, какие компоненты AgentCore доступны в вашем регионе и как они соотносятся с требованиями комплаенса.
Кому подходит этот паттерн и с чего начать
Паттерн окупается там, где есть несколько корпоративных систем, решения принимаются вручную и время до ответа критично: цепочка поставок, операционная поддержка, закупки, логистика. Командам без инфраструктуры AWS и без ресурсов на MCP-серверы старт обойдётся дороже, чем дашборд с ручной выгрузкой.
Минимальный путь выглядит так:
- Выбрать один узкий сценарий, например мониторинг сбоев поставок.
- Обернуть одну систему в MCP-сервер с двумя-тремя инструментами.
- Опубликовать сервер в AWS Agent Registry и подключить к Quick через интеграцию.
- Проверить на тестовом запросе, что ответ приходит из системы, а не из памяти модели.
- Добавить шаг подтверждения для любого действия с внешним эффектом.
- Расширять набор серверов только после того, как первый сценарий стабильно работает.
Развёрнутый пример AWS даёт пройти весь путь целиком, включая реестр, оркестрационный агент и подтверждение RFQ. Начинать с четырёх MCP-серверов сразу не нужно: отладка одного инструмента занимает меньше времени, чем разбор, почему четыре молчат одновременно.