AWS présente ActorSimulator pour tester des agents AI multi-tours dans Strands Evals

AWS показала ActorSimulator — компонент Strands Evaluations SDK, который помогает тестировать AI-агентов в многоходовых разговорах с реалистично смоделированными пользователями. Вместо статичных пар «вопрос-ответ» команды получают управляемые диалоги с персонами, целями и естественными ответвлениями по ходу беседы.

Почему это сложно

Проверять агента в одном ходе сравнительно просто: есть вход, есть ответ, есть набор метрик вроде helpfulness или корректности использования инструментов. Но в реальном продукте разговор почти никогда не заканчивается одним сообщением. Пользователь уточняет запрос, меняет направление, возвращает диалог к исходной задаче или раздражается, если агент упустил важную деталь.

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

Попытка заменить это простым промптом в духе «сыграй пользователя» тоже дает слабый результат: поведение плавает от запуска к запуску, персона распадается, а сравнивать оценки между версиями становится сложно. AWS как раз предлагает более структурированный подход, где реалистичность не убивает повторяемость.

Как работает симулятор ActorSimulator строит симулированного пользователя вокруг тест-кейса.

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

AWS выделяет здесь несколько практических механизмов: Автогенерация устойчивого профиля пользователя под конкретный сценарий Отслеживание цели разговора и проверка, достигнута ли она Стоп-сигнал, если задача решена, агент зашел в тупик или исчерпан лимит ходов Структурированное объяснение, почему симулятор задал именно такой следующий вопрос * Возможность подставлять собственные профили для точечной проверки отдельных сегментов пользователей Это важно не только для красоты сценария. Если агент ответил лишь на часть запроса, симулятор продолжит именно недостающую линию, а не уйдет в случайный оффтоп. Если агент просит уточнение, ответ придет в рамках выбранной персоны.

Более того, каждый ход сопровождается структурированным reasoning: можно увидеть, что пользователь сейчас уточняет пробел, выражает непонимание или пытается вернуть разговор к цели. Для отладки такой уровень прозрачности особенно полезен.

Интеграция в пайплайн AWS показывает, что стартовать можно буквально с

нескольких строк кода через пакет `strands-agents-evals`. В примере тестируется тревел-ассистент: задается Case с пользовательским запросом, затем ActorSimulator создает многоходовой диалог, пока цель не достигнута, не станет ясно, что агент не справляется, или не упрется в `max_turns`. Получившийся transcript уже можно анализировать как полноценную многоходовую сессию для оценки, а не как набор изолированных ответов.

Для продакшн-оценки это связывается с OpenTelemetry и маппингом сессий Strands Evals. AWS предлагает собирать spans на каждом ходе, включая вызовы инструментов, обращения к модели и тайминги, а затем передавать всю траекторию в evaluators вроде HelpfulnessEvaluator и GoalSuccessRateEvaluator. Плюс можно задавать кастомные профили вручную — например, нетерпеливого эксперта или новичка — и смотреть, где агент стабильно теряется.

В рекомендациях AWS советует начинать с 3–5 ходов для простых задач и 8–10 для более длинных сценариев.

Что это значит

Рынок AI-агентов быстро уходит от демо с одним удачным ответом к системной проверке реальных пользовательских траекторий. ActorSimulator от AWS важен именно тем, что превращает многоходовые диалоги из ручной боли в часть регулярного evaluation pipeline: с понятными персонами, измеримой целью и трассировкой, по которой можно искать регрессии до выката в прод.