Построение AI-агентов для бизнес-поддержки с помощью Amazon Bedrock AgentCore

Разработка AI-агентов для бизнес-поддержки связана с особыми задачами, с которыми сталкиваются многие организации при автоматизации рутинных HR-процессов. Компания Works Human Intelligence (WHI) разрабатывает, продает и поддерживает интегрированную HR-систему «COMPANY» для крупных японских корпораций и общественно значимых организаций.

В этом материале мы рассказываем, как AWS Generative AI Innovation Center (GenAIIC) совместно с Works Human Intelligence (WHI) построил двух AI-агентов с использованием Amazon Bedrock AgentCore. Мы разбираем возникшие сложности и решения, которые позволили сократить расходы до 97% и повысить операционную эффективность.

Пользователям HR-систем приходится реагировать на множество ситуаций, таких как организационные изменения, доработки HR-систем и обновления данных сотрудников. Для организаций, которые сталкиваются с похожими задачами в эксплуатации HR-систем, AI-агенты могут значительно снизить нагрузку и повысить производительность. Когда WHI начала создавать продукты на базе AI-агентов, возникло несколько сложностей. Чтобы решить их, мы в GenAIIC тесно работали с командой WHI, предлагая новые подходы и поддержку в создании качественного продукта. Объем этого проекта включает двух AI-агентов, предназначенных для поддержки работы операционных подразделений. Агент по согласованию компенсации за проезд обрабатывает заявки на компенсацию проезда, которые возникают, например, при переезде. Агент браузерных операций действует от имени клиента в «COMPANY». Ниже мы рассматриваем сложности и решения для этих двух агентов.

Агент по компенсации за проезд

Этот агент автоматизирует согласование заявок на компенсацию за проезд — рутинную задачу, которая возникает, например, при переводе сотрудника.

Проблема

Агент по компенсации за проезд поддерживает рутинную задачу согласования заявок на компенсацию за проезд. WHI уже вела proof of concept (PoC) с использованием LangGraph, Amazon Elastic Container Service (Amazon ECS) и AWS Fargate. Однако после выпуска Amazon Bedrock AgentCore во время разработки команда начала рассматривать миграцию. WHI хотела вместе с нами построить решение на AgentCore, которое реализовало бы AI-агента, интегрированного с «COMPANY». Кроме того, компания хотела перейти к интегрированной многoагентной среде и реализовать аутентификацию и авторизацию с использованием AWS Fargate и Amazon Cognito, которые на тот момент находились в разработке.

Обзор решения

Агент по компенсации за проезд разрабатывался на LangGraph и Amazon ECS, но у команды были опасения по поводу монолитной конфигурации, в которой все выполнялось в одной задаче Amazon ECS. Поэтому мы совместно изменили архитектуру так, чтобы субагенты запускались по отдельности на AgentCore Runtime. Поскольку требовалась поддержка multi-tenancy, мы решили управлять арендаторами с помощью Amazon DynamoDB и Amazon Cognito, чтобы сохранить для WHI гибкость при разработке и управлении системой.

Архитектура

Slack служит точкой входа для вызова агента по компенсации за проезд, поэтому система спроектирована так, чтобы при вызове сначала выполнялась аутентификация, а затем соответствующие субагенты обрабатывали запрос.

Результаты и влияние

Поскольку во время проекта AgentCore стал общедоступным сервисом (GA), мы смогли эффективно использовать его. Хотя агент по компенсации за проезд по-прежнему работает на LangGraph, мы изменили его так, чтобы субагенты запускались на отдельном Runtime. Это изменение упрощает дальнейшее расширение числа субагентов. Мы также рассматриваем возможность в будущем перевести supervisor agent, который объединяет субагентов, на Strands Agents. Кроме того, WHI раньше использовала Langfuse для проверки статуса агентов, что создавало операционные расходы, а переход на AgentCore Observability снизил эту нагрузку.

Агент браузерных операций

Этот агент использует браузер для доступа к HR-системе, проверки содержимого, выполнения операций и сбора доказательств от имени клиентов.

Проблема

Второй агент использует браузер для доступа к «COMPANY», проверки содержимого, выполнения операций и получения доказательств. Разработка велась на LangGraph и Playwright Model Context Protocol (MCP). Команда подтвердила сокращение browser operation tokens на 88% за счет следующих подходов:

• Удаление из цикла агента прошлых ненужных частей (истории диалога между AI и Playwright MCP).
• Удаление ненужных для браузерных операций частей из возвращаемых значений Playwright MCP.
• Использование prompt caching для части TOOL.

Однако из-за зависимости от проприетарной реализации команда столкнулась с трудностями, включая сложность миграции на Strands Agents. Кроме того, они рассматривали способы дальнейшего сокращения числа токенов. Именно в этот момент GenAIIC начала сотрудничество с WHI.

Обзор решения

Мы построили агента на Strands Agents. После тестирования нескольких инструментов для браузерных операций и подтверждения успешной обработки мы сосредоточились на сокращении числа используемых токенов. Рабочий процесс начинается с поиска оптимального шаблона операции в базе знаний по инструкциям пользователя. Затем он заменяет заполнители в полученном шаблоне информацией из другой базы знаний, чтобы создать инструкцию по выполнению операции. После этого агент действует в браузере на основе этой инструкции, чтобы проверить текущую информацию. На основе полученных данных, например CSV, он создает предложение по изменению и показывает его пользователю. Наконец, после подтверждения пользователя агент снова управляет браузером на основе предложения по изменению и вносит правки. Хотя определен базовый workflow, агент может гибко обрабатывать случаи, когда входных данных недостаточно, или когда выполняются только отдельные части задачи, опираясь на собственное автономное решение.

Архитектура

Доступ к «COMPANY» со стороны агента ограничен по IP-адресу. Чтобы решить эту проблему, мы разместили AgentCore Runtime внутри виртуального частного облака (VPC) и настроили доступ через фиксированный IP-адрес с использованием NAT gateway. Мы также создали базу знаний для хранения шаблонов операций и вспомогательной информации, необходимой для подготовки процедур. Для хранения краткосрочной информации мы использовали бакет Amazon Simple Storage Service (Amazon S3).

Результаты и влияние

Агент браузерных операций был построен на Strands Agents. Мы протестировали инструменты браузерных операций, включая browser-use, Playwright и fast playwright, и подтвердили, что fast playwright потребляет меньше всего токенов. Кроме того, благодаря совместной работе над улучшениями, такими как использование Amazon Bedrock prompt caching и изменение системных prompt, нам удалось сократить стоимость одного процесса до 97%. Основные меры по улучшению были следующими:

• Использование prompt caching для сообщений пользователя: включили функцию prompt caching в Amazon Bedrock ($14.5 -> $2.1).
• Оптимизация поведения агента: улучшили prompts субагента, чтобы сократить ненужные операции ($2.1 -> $1.0).
• Смена моделей: заменили Claude Sonnet 4.5 на Haiku 4.5 ($1.0 -> $0.4).

Благодаря этим улучшениям мы оптимизировали затраты и при этом успешно обрабатывали более сложные задачи. Среди них — сценарии, где выполняется несколько изменений подряд, или сценарии, в которых агент задает человеку вопросы, когда инструкции сформулированы неоднозначно.

Заключение

В ходе нашего сотрудничества мы успешно перенесли инфраструктуру выполнения AI-агента на AgentCore Runtime и теперь можем отслеживать операционный статус с помощью AgentCore Observability. Сотрудники WHI отметили, что использование AgentCore существенно упростило разработку, поскольку проверка логов теперь выполняется через managed service. Кроме того, переход на Strands Agents для Browser Agent позволил реализовать гибко работающего агента с минимальным объемом реализации. В этом материале мы показали, как построение AI-агентов может поддерживать рутинные задачи. Совместная работа позволила WHI сосредоточиться на разработке бизнес-логики. AgentCore включает Runtime, который служит основой выполнения, и другие возможности, поэтому мы рассматриваем дальнейшее использование с WHI. Кроме того, поведение и стоимость AI-агентов меняются в зависимости от используемой модели. В рамках этого проекта мы подтвердили, что процессы работают как ожидается. Мы планируем и дальше оценивать модели и оптимизировать затраты.

Чтобы увидеть, как Amazon Bedrock AgentCore упрощает разработку AI-агентов, посетите наше руководство по началу работы или практическую лабораторную работу. Если вы хотите автоматизировать рутинные задачи, построить многoагентные workflow или оптимизировать стоимость моделей с помощью таких функций, как prompt caching, у AWS есть инструменты для поддержки этих сценариев.

Материал — перевод статьи с английского.

Оригинал: Building AI agents for business support using Amazon Bedrock AgentCore