Что такое размещенные агенты?

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

Размещенные агенты в службе агентства Foundry решают эти проблемы для пользователей Microsoft Foundry. Размещенные агенты вызывают модели из каталога моделей Foundry для выполнения рассуждений, в то время как ваш пользовательский код отвечает за оркестрацию. С помощью этой управляемой платформы можно безопасно развертывать агенты ИИ и управлять ими в большом масштабе. Вы можете использовать пользовательский код агента или предпочтительную платформу агента с оптимизированным развертыванием и управлением.

Если вы изучаете размещённые агенты в сочетании с ИИ-агентом для программирования, Навык Microsoft Foundry поможет связать эти концепции с задачами реализации, развертывания и эксплуатации.

Когда следует использовать размещенные агенты

Выбирайте размещаемые агенты вместо агентов на основе промптов, когда вам нужно:

• Используйте свой код — применяйте любой фреймворк (Agent Framework, LangGraph, Semantic Kernel, или настраиваемый код), а не определения, зависящие исключительно от запросов.
• Используйте пользовательские протоколы — обрабатывайте вебхуки или нагрузки, не связанные с OpenAI, через протокол вызовов.
• Управление вычислительными ресурсами — укажите ЦП и память для песочницы агента.
• Выполнение рабочих нагрузок с отслеживанием состояния — сохраняйте файлы и состояние через $HOME и конечную точку /files.
• Надежно выполняйте длительные задачи — сохраняйте незавершенную работу агента при прерываниях процесса и заново воспроизводите потоковые результаты для повторно подключающихся клиентов.

Принцип работы

Вы упаковаете агент в виде образа контейнера и отправляете его в Реестр контейнеров Azure. При развертывании Agent Service загружает образ, назначает агенту выделенный идентификатор Microsoft Entra ID (идентификатор агента) и предоставляет для агента выделенную конечную точку.

Во время выполнения Agent Service выделяет вычислительные ресурсы для сеанса и направляет запросы в ваш контейнер. Код агента обрабатывает эти запросы и может вызывать модели Foundry, инструменты Toolbox и нижестоящие службы Azure, используя удостоверение агента. Платформа обрабатывает масштабирование, сохраняемость состояния сеанса, наблюдаемость и управление жизненным циклом.

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

Основные понятия

Размещенные агенты

Размещенные агенты — это контейнерные агентные ИИ-приложения, которые выполняются на сервисе Agent Service. В отличие от агентов на основе запросов, которые определяются полностью с помощью запросов и настройки инструментов на портале Foundry, размещенные агенты представляют собой собственный код, упакованный в виде образа контейнера. Вы выбираете платформу, управляете поведением среды выполнения и развертываете образ в Microsoft управляемой инфраструктурой.

Платформа автоматически управляет жизненным циклом контейнера на основе активности платформы, осуществляя подготовку ресурсов при создании версии программы и отменяя подготовку, когда превышено время ожидания простоя.

Модель изоляции

Размещенные агенты выполняются в изолированных виртуальных машинах-изоляторах на каждом сеансе. Каждый сеанс получает выделенную песочницу с постоянной файловой системой ($HOME и /files), что позволяет масштабировать до нуля, сохраняя состояние и обеспечивая предсказуемый холодный запуск. Сеансы изолированы друг от друга, и состояние автоматически восстанавливается при возобновлении сеанса после простоя.

Протоколы: ответы, вызовы и вызовы (WebSocket)

Размещенные контейнеры агентов могут предоставлять один или несколько протоколов. Каждый протокол предоставляется упрощенной библиотекой, которая обрабатывает сервер HTTP или WebSocket, проверку работоспособности и интеграцию OpenTelemetry. Протоколы Responses, Invocations и Invocations (WebSocket) доступны во всех регионах, где поддерживаются размещённые агенты.

Какой протокол следует использовать?

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

Сравнение протоколов

Фоновый режим и отказоустойчивое выполнение решают различные проблемы. Фоновый режим позволяет продолжить работу после возврата инициируемого запроса. Устойчивое выполнение сохраняет работу после остановки процесса размещения. Сведения о модели восстановления и зонах ответственности приложения см. в разделе Отказоустойчивость для длительно выполняющихся размещённых агентов.

Дополнительные протоколы

Размещенные агенты также поддерживают протокол Activity для Microsoft Teams и интеграции каналов Microsoft 365. При использовании протокола Responses для логики агента и публикации в каналах Microsoft 365, таких как Teams, платформа автоматически связывает Responses с протоколом Activity для доставки через каналы — дополнительной настройки не требуется. Протокол A2A поддерживает делегирование агента к агенту. Поддерживаемые протоколы можно объединить в одном агенте.

Удостоверение агента и конечная точка

Каждый размещённый агент, развернутый в проекте Foundry, получает свой собственный выделенный Microsoft Entra ID (удостоверение агента) и выделенную конечную точку — оба создаются автоматически при развертывании. Вам не нужно настраивать управляемые удостоверения или маршрутизацию вручную.

Конечная точка доступна сразу после развертывания. Публикация не требуется для программного доступа:

• Ответы: {project_endpoint}/agents/{name}/endpoint/protocols/openai/responses
• Вызовы: {project_endpoint}/агенты/{name}/endpoint/protocols/вызовы
• Вызовы (WebSocket): wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
• A2A (предварительная версия): {project_endpoint}/agents/{name}/endpoint/protocols/a2a

Какие конечные точки активны, зависят от протоколов, объявленных в определении версии агента. Задайте это определение в службе azure.ai.agent в azure.yaml при использовании azd или через protocol_versions при использовании SDK.

Участвуют две идентификации:

Идентификатор агента по умолчанию может получать доступ к инференсу модели через конечную точку проекта и хранилище сеансов. Для внешних ресурсов (например, вашего собственного хранилища Azure) назначьте роли RBAC вручную для Microsoft Entra ID агента. Дополнительные сведения см. в разделе "Доступ к агенту за пределами по умолчанию".

При интеграции через каналы Microsoft 365 (например, Teams) размещённые агенты могут работать в двух режимах идентификации в зависимости от способа их вызова:

• Сценарии, вызываемые пользователем (интерактивные): если маркер пользователя присутствует, платформа поддерживает потоки OAuth 2.0 On-Behalf-Of (OBO). В этом случае агент может вызывать нижестоящие службы от имени пользователя, используя делегированные разрешения пользователя, в соответствии с политиками клиента Microsoft Entra ID.

• Автономные или фоновые сценарии: если токен пользователя недоступен, агент аутентифицируется с использованием собственного удостоверения в Microsoft Entra ID (удостоверения агента), как правило, через управляемую идентичность, для доступа к нижележащим службам.

В обоих случаях агент сохраняет свой выделенный Microsoft Entra ID для проверки подлинности, авторизации и аудита. Дополнительные сведения см. в разделе "Приложения агента " и концепции удостоверений агента.

Сеансы и беседы

Размещенные агенты используют сеансы и диалоги для управления состоянием. Как они работают, зависят от протокола.

Сеансов

Идентификатор сеанса определяет логический сеанс с сохраненным состоянием, включая $HOME и файлы, отправленные через конечную точку /files. Платформа предоставляет вычислительные ресурсы по запросу и восстанавливает сохранённое состояние на них.

• Сохраняемость состояния: содержимое $HOME и /files сохраняется между интерактивными сессиями и в периодах простоя. Когда вычислительная система находится в состоянии неактивности и возвращается к работе (на новой или существующей инфраструктуре), состояние сеанса автоматически восстанавливается.
• Изоляция: каждый сеанс изолирован от других сеансов.
• Автоматический жизненный цикл: сеансы создаются при первом использовании. Платформа автоматически управляет выделением и освобождением вычислительных мощностей.
• Время существования сеанса: вы можете настроить время ожидания простоя для каждой версии агента от 5 до 60 минут с 15-минутным значением по умолчанию. Если запрос не поступает в это окно, платформа отменяет вычисление и сохраняет состояние сеанса. Платформа окончательно удаляет сеанс через 30 дней бездействия.
• API управления сеансами: вывод списка сеансов, завершение сеансов и отправка или скачивание файлов на сеанс.

Разговоры

Идентификатор беседы — это устойчивая запись истории разговора (сообщения, вызовы инструментов и ответы), хранящаяся в Foundry.

• Сохраняемость. Журнал бесед хранится в Foundry и сохраняется независимо от состояния вычислений.
• Доступ между каналами: пользователи могут получить доступ к той же беседе с игровой площадки, API, Teams или других опубликованных каналов.

Как сеансы и обсуждения работают с каждым протоколом

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

Протокол вызовов: идентификатор сеанса является основной концепцией. Клиент непосредственно управляет идентификатором сеанса для поддержания состояния взаимодействия. Клиент может передать содержимое через конечную точку /files с помощью идентификатора сеанса, чтобы сделать его доступным для сеанса. Платформа не управляет историей общения. Вы управляете состоянием в своем коде.

Жизненный цикл вычислений сеанса

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

Безопасность и обработка данных

Относитесь к размещённому агенту как к продукционному коду приложения.

• Не помещайте секреты в образы контейнеров или переменные среды. Используйте управляемые удостоверения и подключения и храните секреты в управляемом хранилище секретов. Инструкции см. в разделе Настройка подключения Key Vault.
• Будьте осторожны с средствами и серверами без Microsoft. Если агент вызывает средства, поддерживаемые не службы Майкрософт, некоторые данные могут передаваться в эти службы. Просмотрите политики совместного использования данных, хранения и расположения для любой службы, отличной от Microsoft, к которой вы подключаетесь.

Сведения о платформе

Управление версиями

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

Конечная точка агента обслуживает одну версию одновременно и направляет 100% трафика в ту версию. Разделение трафика между версиями не поддерживается.

Переменные среды — это основной механизм передачи конфигурации в контейнер во время выполнения (например, конечной точки проекта, имени развертывания модели и пользовательских параметров). Они задаются для каждой версии и неизменяемы после создания версии.

Наблюдаемость

Размещенные агенты обеспечивают встроенную наблюдаемость. Платформа автоматически внедряет строку подключения для Application Insights в контейнер агента с помощью переменных среды. Агенты, использующие библиотеки протоколов, по умолчанию генерируют трассировки OpenTelemetry, которые отображаются в связанном ресурсе Application Insights в разделе "Поиск транзакций" или "Производительность".

Инструкции по настройке и анализу см. в разделе "Включить трассировку" в проекте.

Набор инструментов в Foundry

Размещённые агенты имеют полный доступ к инструментам, управляемым Foundry, включая интерпретатор кода, веб-поиск (с Grounding with Bing Custom Search), Поиск с использованием ИИ Azure, OpenAPI, MCP, A2A, навыки и многое другое. Вы подключаете эти средства через конечную точку MCP Toolbox, развернутую в вашем проекте Foundry, а не добавляя их напрямую в определение агента. Инструментарий обеспечивает единую аутентификацию для сквозной передачи идентификационных данных OAuth, идентификации агента, аутентификации на основе ключей и других методов. Если вы используете Microsoft Agent Framework, подключайтесь через FoundryToolbox в Python или AddFoundryToolboxes в .NET вместо универсального клиента MCP. Другие среды выполнения подключаются с помощью стандартных клиентских библиотек MCP. Дополнительные сведения см. в наборе инструментов на основе намерений в Foundry.

Поддержка языка

Размещенные агенты поддерживают Python и C#. Вы можете использовать любую платформу агента— библиотеки протоколов не зависят от платформы. Примеры с помощью Microsoft Agent Framework, LangGraph и пользовательского кода см. в репозитории foundry-samples.

Размеры песочницы

Размещенные изолированные среды агента поддерживают следующие сочетания процессора и памяти:

Хранилище сеансов

Каждый сеанс имеет постоянный $HOME. Платформа сохраняет свое содержимое после освобождения вычислительных ресурсов по истечении настроенного тайм-аута простоя. Платформа восстанавливает содержимое при возобновлении сеанса, поэтому файлы, записанные в $HOME, сохраняются в периоды простоя. Платформа записывает файлы, загруженные через эндпоинт /files, в $HOME, где они используют одно и то же хранилище. Каждый сеанс имеет общий лимит дискового пространства до 20 ГиБ при 1 vCPU и выше, который пропорционально уменьшается для меньших уровней CPU. Платформа резервирует около 20% этого бюджета для использования системы, и она не отображается или недоступна агенту. Оставшаяся часть распределяется между образом вашего контейнера, $HOME, и любыми другими доступными для записи расположениями в контейнере.

Масштабирование и подбор оптимального размера

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

Время ожидания простоя может составлять от 5 до 60 минут и по умолчанию — 15 минут. Платформа окончательно удаляет сеанс через 30 дней бездействия. Не нужно настраивать количество реплик и задавать размер резервного пула.

Так как каждый сеанс выполняется в собственной песочнице, значения ЦП и памяти, заданные в версии агента, описывают один сеанс, а не агрегированный объем агента. Стоимость рассчитывается исходя из потребления процессорных ресурсов и памяти во всех активных сеансах, поэтому избыточное выделение ресурсов увеличивает затраты пропорционально числу одновременно активных сеансов.

Для правильного размера запустите представительную рабочую нагрузку и проверьте использование ресурсов в связанном ресурсе Application Insights:

1. Откройте ресурс App Insights в портале Azure и выберите Исследование>Производительность.
2. Просмотрите ЦП, доступную память, частоту запросов и среднюю длительность запроса в течение проверенного диапазона времени.

Сравните наблюдаемые пики с выделенными ЦП и памятью. Если устойчивые пиковые значения превышают примерно 70% выделенного объёма ресурсов, увеличьте объём ресурсов для следующей версии агента; если пики остаются значительно ниже этого уровня, уменьшите его, чтобы снизить затраты. Всегда повторно тестировать после изменения, так как каждая новая версия неизменяема.

Частная сеть

Размещенные агенты поддерживают развертывание в ресурсах Foundry, изолированных от сети, и могут использовать предоставленные клиентом Azure Virtual Network для исходящего трафика. Это позволяет агентам в развертываниях Foundry, изолированных от сети, получать доступ к частным ресурсам, таким как базы данных или внутренние API. Дополнительные сведения см. в разделе "Настройка виртуальных сетей".

Ограничения, цены и доступность

Цены

Выставление счетов за управляемую среду выполнения размещения основано на потреблении ресурсов ЦП и памяти в ходе активных сеансов. Сведения о текущих ставках см. на странице цен на Foundry.

Доступность региона

Размещенные агенты в настоящее время доступны в следующих регионах:

• Восточная Австралия
• Южная Бразилия
• Центральная Канада
• Canada East
• Central US
• East US
• Восточная часть США 2
• Центральная Франция
• Западно-Центральная Германия
• Italy North
• Восточная Япония
• Japan West
• Центральная Корея
• Северная часть США
• Восточная Норвегия
• Центральная Польша
• Южная Африка Север
• Южно-Центральный регион США
• Южная Индия
• Юго-Восточная Азия
• Центральная Испания
• Центральная Швеция
• Северная Швейцария
• Switzerland West
• UAE North
• UK South
• UK West
• Центрально-западная часть США
• West Europe
• Западная часть США
• Западная часть США 3

Дальнейшие действия

Связанное содержимое

• Компоненты среды выполнения агента
• Жизненный цикл разработки агента
• концепции идентификации Agent в Microsoft Foundry
• Что такое Toolbox в Foundry?
• Реестр контейнеров Azure документация