Microsoft Teams Blog articles на русском
Подписаться
Следующее поколение агентов с Azure и Microsoft Foundry
В статье обсуждаются разработки HelpDesk Copilot, службы поддержки Contoso IT, которая использует агент Microsoft Foundry для сортировки запросов сотрудников и предоставления ответов, основанных на базе знаний IT. Система предназначена для передачи запросов людям через реальный канал, когда этого требует политика. Архитектура состоит из трех Azure Container Apps, одного Foundry Prompt Agent и конвейера обработки заявок на основе событий. Агент имеет три возможности: поиск файлов, создание заявки и получение статуса заявки, которые используются для ответов на вопросы сотрудников и эскалации проблем при необходимости.Система построена на Azure Container Apps, полностью развернута с помощью Terraform и не содержит ключей API, при этом каждый вызов службы к службе использует Microsoft Entra ID и управляемые удостоверения. Аутентификация по локальному ключу для учетной записи Foundry полностью отключена. Архитектура спроектирована как событийно-ориентированная: API публикует события заявок в тему Service Bus, которые затем доставляются рабочему процессу через подписку Dapr. Рабочий процесс обновляет заявку в Table Storage и отправляет полезную нагрузку в поток Power Automate HTTP, который отправляет Adaptive Card в канал Teams IT-отдела.Система спроектирована как идемпотентная, с идентификатором заявки, определяемым детерминированно из идентификатора беседы и темы, что гарантирует, что повторные вызовы инструмента создания заявки для одной и той же проблемы в одной и той же беседе сводятся к одному и тому же идентификатору вместо создания дубликата. Система также использует конечную согласованность, при этом строка заявки может отсутствовать в течение нескольких секунд, пока рабочий процесс пробуждается с помощью KEDA. Архитектура спроектирована как масштабируемая, с возможностью добавления новых подписок на тему Service Bus без изменения API.Модель удостоверений спроектирована для использования Entra ID через DefaultAzureCredential, при этом каждое приложение использует управляемое удостоверение, назначенное пользователем. API, рабочий процесс и интерфейс имеют свои собственные удостоверения: API имеет доступ к AcrPull, агенту Foundry, читателю данных таблицы хранилища, пользователю секретов Key Vault и отправителю Service Bus. Рабочий процесс имеет доступ к AcrPull, участнику данных таблицы хранилища, пользователю секретов Key Vault и получателю Service Bus, в то время как интерфейс имеет доступ только к AcrPull.В статье также обсуждается использование Terraform для развертывания ресурсов Azure, при этом автор отмечает, что очевидные на вид ресурсы не всегда являются правильными. Автору пришлось использовать azurerm_cognitive_account для развертывания службы Foundry Agent, а не azapi. В заключение статьи отмечается, что система спроектирована как безопасная, масштабируемая и событийно-ориентированная, с акцентом на использование управляемых удостоверений и Entra ID для аутентификации вызовов служб к службам.