AWS опубликовала техническое руководство по подключению агентов Amazon Bedrock AgentCore к базам знаний, размещенным в других аккаунтах AWS. Решение позволяет генерировать ответы на естественном языке по данным в Amazon Redshift Serverless, не копируя исходные данные в аккаунт агента. Это актуально для компаний с многоаккаунтной архитектурой, где важно сохранять границы между рабочими нагрузками и данными.
Amazon Bedrock AgentCore — это платформа для создания, подключения и оптимизации агентов ИИ с поддержкой любых фреймворков и моделей. Базы знаний Amazon Bedrock Knowledge Bases реализуют механизм Retrieval Augmented Generation (RAG), который позволяет модели отвечать на вопросы, опираясь на внешние источники данных. В данном случае источником выступает Amazon Redshift Serverless — бессерверное хранилище данных, которое может находиться в отдельном аккаунте.
| Критерий | Кодовая Strands-архитектура | Декларативный AgentCore harness |
|---|---|---|
| Лучшее соответствие | Команды, которым нужна кастомизация оркестрации, хуки, промежуточное ПО, ретраи, инструментирование, контроль над инструментами и стримингом | Команды, чей сценарий укладывается в управляемый подход с меньшим объемом кода |
Основная сложность заключается в том, что политики ресурсов Amazon Bedrock Knowledge Bases поддерживают операции Retrieve и GetDocumentContent для кросс-аккаунтного доступа, но не поддерживают RetrieveAndGenerate. Последняя операция возвращает готовый ответ, сгенерированный моделью, и именно она нужна для решения. Чтобы обойти это ограничение, инструмент агента принимает узконаправленную IAM-роль в аккаунте базы знаний через AWS Security Token Service (STS) перед вызовом API.
Кросс-аккаунтный доступ реализован через IAM-роль и AWS STS, без копирования данных.
В руководстве описаны два варианта реализации. Первый — кодовая Strands-архитектура, где агент работает на AgentCore runtime, а инструмент запускается в локальном подпроцессе Model Context Protocol (MCP). Второй — декларативный AgentCore harness, где инструмент вызывается через AWS Lambda и AgentCore Gateway. Оба варианта используют одинаковую границу доступа к данным, но различаются тем, кто владеет циклом оркестрации и как размещается инструмент.
Поток запроса выглядит так: пользователь задает вопрос через Streamlit UI или API AgentCore, модель Amazon Nova Pro решает вызвать инструмент query_knowledge_base, инструмент принимает роль bedrock_kb_access_role в аккаунте базы знаний через STS, вызывает RetrieveAndGenerate с моделью Claude Haiku 4.5, и ответ возвращается пользователю. База знаний преобразует вопрос в структурированный запрос к Amazon Redshift Serverless.
AWS рекомендует выбирать наиболее простой достаточный паттерн. Если приложению нужен только поиск по данным, можно использовать нативный кросс-аккаунтный Retrieve с политикой ресурсов. Если каждый запрос требует один детерминированный ответ, и не нужны выбор инструментов, многошаговые рассуждения или диалоговое состояние, можно вызывать RetrieveAndGenerate напрямую из приложения или Lambda-функции. Агент нужен, когда модель должна сама решать, когда и как обращаться к базе знаний более широкого диалога.
Выбор между вариантами AgentCore зависит от того, насколько команда хочет кастомизировать оркестрацию. Кодовая Strands-архитектура подходит командам, которым нужны собственные хуки, промежуточное ПО, ретраи, инструментирование и прямой контроль над инструментами и стримингом. Декларативный harness — для команд, которые предпочитают управляемый подход с меньшим объемом кода.
Примеры кода и процедуры развертывания доступны в GitHub-репозитории, ссылка на который приведена в руководстве. Материал будет полезен архитекторам и разработчикам, работающим с многоаккаунтными средами AWS и строящим агентные решения на базе Amazon Bedrock.
