«Событие и есть промпт»: AWS показала каркас ambient-агентов на Amazon Bedrock AgentCore

Что именно предложила AWS

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

Ambient-агент убирает эту паузу: файл попадает в бакет Amazon S3, и через секунды на странице Jobs появляется задача — либо уже выполняющаяся, если так настроено. Агент разбирает файл, показывает находки и запрашивает подтверждение перед следующим шагом. «Событие само является промптом», — формулирует AWS: агент реагирует на поток событий, при необходимости останавливается ради человека через инструмент ask_human и продолжает с того места, где остановился, когда человек отвечает.

Материал описывает паттерн целиком: как событие Amazon S3 или расписание превращается в задачу, которую агент исполняет в Amazon Bedrock AgentCore Runtime — с участием человека или без, и почему одного инструмента ask_human вместе с каноническим конвертом ответа хватает для всего диапазона сценариев human-in-the-loop.

Чем ambient-агент отличается от чат-агента

Чат-агент работает по схеме «запрос — ответ»: пользователь, промпт, агент, ответ, пользователь. Ambient-агент устроен иначе: событие, сигнал, агент, при необходимости взаимодействие с человеком, действие. Ключевое отличие — механизм запуска: агента активируют системные события, а не явный запрос пользователя, поэтому паттерн хорошо ложится на конвейеры обработки документов, мониторинг и алертинг, анализ по расписанию и многошаговые процессы с точками согласования.

Связка «событие → агент» описывается сигналом (signal). Когда событие происходит, платформа сама создаёт задачу для агента, а дальнейшее поведение определяется одной настройкой: при autoExecute: false — это значение по умолчанию — задача попадает на страницу Jobs в статусе idle и ждёт, пока человек её просмотрит и запустит; при autoExecute: true обработчик сигнала сразу ставит задачу в очередь, агент стартует немедленно, и человек привлекается только тогда, когда сам агент вызовет ask_human.

Из коробки образец поддерживает два источника сигналов — загрузку файлов в Amazon S3 (с фильтрами по бакету, префиксу и суффиксу) и события по расписанию, где планировщик работает по cron с минутным шагом и оперирует задачами с jobType: "scheduled". Вебхуки, события Amazon EventBridge и потоки изменений Amazon DynamoDB описаны как точки расширения: под новый тип нужно написать обработчик и добавить поле в форму на странице Signals.

Как устроен конвейер

Поток событий выглядит так: Amazon S3 отправляет уведомление s3:ObjectCreated, его принимает функция Signal Processor, которая через глобальный вторичный индекс (GSI) таблицы описаний сигналов находит подходящие сигналы для бакета и создаёт записи задач. Уровень API или планировщик ставит задачу в очередь Amazon SQS; та же функция Job Execution, что обслуживает API, вычитывает очередь через привязку к SQS, вызывает агента в Amazon Bedrock AgentCore Runtime и записывает результат вместе с запросами на участие человека обратно в Amazon DynamoDB.

Отдельно AWS оговаривает назначение Amazon SQS: очередь развязывает запрос через API Gateway и вызов агента, а очередь недоставленных сообщений (DLQ) забирает то, что обработчик не смог разобрать после заданного числа повторов. В DynamoDB лежат реестр агентов, записи задач, описания сигналов, ветки чатов, история переписки и записи идемпотентности; сообщения диалога дописываются атомарно через UpdateItem с list_append, чтобы параллельные записи не затирали друг друга.

AgentCore Runtime запускает код агента в изолированных контейнерах и рассчитан на длительные нагрузки: сессии достаточно длинные, чтобы покрыть цикл «сигнал → агент → человек». Каждый шаг агента в референсной реализации ограничен 15-минутным таймаутом AWS Lambda, чего, по оценке авторов, на практике хватает с запасом; связка с AWS Lambda для обработки событий и Amazon DynamoDB для состояния даёт полностью serverless-платформу.

Референсный агент — контейнерный агент на LangChain с четырьмя инструментами: calculator, ask_human, list_s3_files и read_s3_file, плюс обобщённый системный промпт. Это заготовка для проверки конвейера, а не решение бизнес-задачи: свой агент подключается заменой контейнера и описанием инструментов в config.yaml, без пересборки под новую конфигурацию.

Один инструмент и один конверт для взаимодействия с человеком

Взаимодействие с людьми сведено к единственному коду: инструмент ask_human возвращает не исключение — узел инструментов LangGraph перехватил бы его как наблюдение об ошибке и вернул модели, — а строку-сентинел __HUMAN_INPUT_REQUIRED__::. Оркестратор распознаёт сентинел в потоке ToolMessage после завершения графа и превращает его в прерванный ответ, так что модель сентинела вообще не видит. Данные конкретного запуска передаются не аргументами инструмента, а через ContextVar, чтобы параллельные вызовы внутри одного контейнера не смешивались.

Канонический конверт ответа содержит статус completed, interrupted или error и соответствующее поле result, question или error; идентификаторы session_id и job_id платформа прокидывает как метаданные корреляции. Прерванный ответ переводит задачу в статус interrupted и выставляет requiresAction в true, а интерфейс показывает такие задачи на вкладке Interrupted с предупреждающим индикатором — отдельной очереди на проверку нет.

На этой механике AWS различает четыре привычных сценария: Notify, когда агент просто сообщает результат, Question с уточняющим вопросом, Review, где предлагается действие и ожидается APPROVE, REJECT или MODIFY, и Error, при котором сбой фиксируется в записи задачи, а человек решает, повторять ли запуск. Это соглашения о том, как агент формулирует вопрос, а не разные режимы рантайма: на уровне платформы существует ровно один путь исполнения и ровно один конверт.

Эксплуатация, безопасность и границы применимости

Функции AWS Lambda публикуют метрики CloudWatch в пространстве имён AmbientAgents: совпадения сигналов, постановки задач в очередь, завершённые, прерванные и упавшие задачи. Вместе со штатными метриками Lambda и Amazon SQS это даёт сквозную картину цикла «сигнал → задача → агент → человек», а сигнализацию на глубину DLQ AWS советует ставить первой линией защиты от молчаливых отказов.

По безопасности перечислены принцип наименьших привилегий для ролей AWS Lambda, точечная политика bedrock-agentcore:InvokeAgentRuntime на рабочей роли, шифрование данных при хранении и в передаче, журналирование вызовов через AWS CloudTrail и применение Amazon Bedrock Guardrails к входам и выходам агента — чтобы фильтры контента, запрещённые темы и проверки контекстной обоснованности отрабатывали до того, как находки попадут на страницу Jobs или дойдут до проверяющего через ask_human. Для масштабирования предлагается зарезервированная конкурентность рабочей функции Job Execution — она задаёт предсказуемый потолок вызовов Amazon Bedrock, — переход на выделенную ёмкость DynamoDB по мере стабилизации нагрузки, а также TTL для старых переписок, жизненный цикл объектов Amazon S3 и метрические фильтры CloudWatch для учёта стоимости вызовов по агентам.

Есть и прямое указание, когда паттерн не нужен: приложения реального времени с чатом остаются за традиционным чат-агентом, простые API-сценарии «запрос — ответ» вообще не требуют агента, поскольку обычный эндпоинт работает быстрее, дешевле и предсказуемее, а полностью детерминированные процессы без рассуждений модели по-прежнему стоит собирать на AWS Step Functions.