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

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

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

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

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

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

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

Вы упаковаете агент в виде образа контейнера и отправляете его в Реестр контейнеров Azure. При развертывании служба агента извлекает образ, подготавливает вычисления, назначает выделенную Microsoft Entra ID (удостоверение агента) и предоставляет выделенную конечную точку. Во время выполнения код агента обрабатывает запросы от клиентов и может вызывать модели Foundry, инструменты Toolbox и подчиненные службы Azure, используя удостоверение агента. Платформа обрабатывает масштабирование, сохраняемость состояния сеанса, наблюдаемость и управление жизненным циклом.

Важно

При использовании размещенных агентов с другими Microsoft продуктами и службами необходимо ознакомиться со всей соответствующей документацией по таким продуктам и службам, а также понять связанные риски и рекомендации по соответствию требованиям. Если вы используете облачные агенты с любыми сторонними серверами, агентами, кодом или моделями, которые не являются моделями Azure Direct ("Сторонние системы"), это делается на ваш собственный риск. Сторонние системы — это не Microsoft продукты в соответствии с условиями Microsoft продукта и регулируются собственными условиями лицензии сторонних производителей. Вы несете ответственность за любое использование и связанные расходы. Просмотрите все данные, к которым предоставлен доступ, и полученные из сторонних систем. Имейте в виду практики третьих сторон по обработке, совместному использованию, хранению и расположению данных. Вы несете ответственность за управление тем, будут ли потоки ваших данных выходить за пределы границ соблюдения соответствия и географических границ вашей организации в Azure и любые связанные с этим последствия. Microsoft не несет ответственности за вас или других в отношении использования сторонних систем, и вы несете ответственность за реализацию собственных ответственных мер по устранению рисков ИИ, таких как метапроимпты, фильтры содержимого или другие системы безопасности.

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

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

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

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

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

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

Протоколы: ответы и вызовы

Контейнеры, размещенные для агентов, предоставляют один или оба из двух протоколов. Каждый протокол предоставляется упрощенной библиотекой, которая обрабатывает HTTP-сервер, проверки работоспособности и интеграцию OpenTelemetry.

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

Сценарий Протокол Почему
Беседный чат-бот или помощник Ответы Платформа управляет журналом бесед, событиями потоковой передачи и жизненным циклом сеансов— используйте любой пакет SDK, совместимый с OpenAI, в качестве клиента.
Многоэтапный Q&A с помощью RAG или инструментов Ответы Встроенная обработка потоков идентификатора беседы и обработки результатов инструментов.
Фоновая и асинхронная обработка Ответы фон: true с опросом, управляемым платформой, и отмена— не требуется пользовательского кода.
Агент, опубликованный в Teams или M365 Ответы + Активность Протокол Responses управляет логикой агента; Протокол действий обрабатывает интеграцию канала Teams.
Приемник вебхука (GitHub, Stripe, Jira и т. д.) Вызовы Внешняя система отправляет формат собственной нагрузки, который нельзя изменить, чтобы он соответствовал пути /responses.
Неконверсационная обработка (классификация, извлечение, пакет) Вызовы Входные данные структурированы, а не сообщение чата. Произвольный JSON на входе, произвольный JSON на выходе.
Пользовательский потоковый протокол передачи данных (AG-UI и т. д.) Вызовы AG-UI и другие протоколы пользовательского интерфейса агента не совместимы с OpenAI— вам нужен необработанный элемент управления SSE.
Мост протокола (GitHub Copilot, собственные системы) Вызовы Вызывающий объект имеет собственный протокол, который не сопоставляется с /responses.

Совет

Не уверен? Начните с Ответы. Вы всегда можете добавить конечную точку вызовов позже— размещенный агент может поддерживать оба протокола одновременно.

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

Ответы Вызов
Оптимально для Большинство агентов — это платформа, которая управляет историей переписки, жизненным циклом потоковой передачи и фоновым выполнением Агенты, которым требуется полное управление HTTP, настраиваемые полезные нагрузки или длительные асинхронные рабочие процессы
Полезная нагрузка Контракт OpenAI-совместимых /responses Произвольный JSON через /invocations — вы определяете схему
Клиентский пакет SDK Любой пакет SDK, совместимый с OpenAI (Python, JS, C#), работает из коробки. Пользовательский клиент — вы определяете контракт
Журнал сеансов Управляемое платформой с помощью идентификатора беседы Вы управляете сеансами (в памяти, Cosmos DB и т. д.)
Поток Платформенно управляемый поток событий ответа с событиями жизненного цикла Необработанный SSE— вы форматируйте и записываете события напрямую
Фоновый режим / долговременное выполнение Встроенная (фон: true + управляемый платформой опрос) Отслеживание задач вручную и пользовательские конечные точки опроса

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

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

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

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

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

  • Ответы: {project_endpoint}/agents/{name}/endpoint/protocols/openai/v1/responses
  • Вызовы: {project_endpoint}/агенты/{name}/endpoint/protocols/вызовы

Какие конечные точки считаются активными, зависит от протоколов, указанных в определении версии агента (устанавливается в agent.yaml при использовании azd или через container_protocol_versions при использовании SDK).

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

Идентичность Объем Цель
Microsoft Entra ID (удостоверение агента, для каждого агента) Создается автоматически в момент развертывания Идентификационные данные контейнера агента аутентифицируются во время выполнения. Используется для вызова модели, доступа к инструментам и подчиненных служб Azure.
Project управляемая идентичность (на уровне проекта) Назначено системой в проекте Foundry Используется платформой для операций инфраструктуры (например, считыватель репозитория реестра контейнеров). Не идентичность среды выполнения агента.

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

При интеграции с помощью каналов Microsoft 365 (например, Teams) размещенные агенты также могут работать с удостоверением пользователя от имени другого лица (OBO). Microsoft Entra ID агента может обменять токен пользователя для вызова нижестоящих служб от имени пользователя, в соответствии с политиками арендатора. Дополнительные сведения см. в разделе "Приложения агента " и концепции удостоверений агента.

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

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

Сеансов

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

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

Разговоры

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

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

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

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

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

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

Государства Что происходит
Активный Процесс вычисления выполняется. Запросы направляются в него. доступны $HOME и содержимое /files.
Простой Нет запросов в течение 15 минут. Вычислительные ресурсы выведены из эксплуатации. Сохраняется состояние сеанса ($HOME, /files).
Возобновил Один и тот же идентификатор сеанса снова используется. Платформа подготавливает новые вычислительные ресурсы и восстанавливает сохраненное состояние.

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

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

Важно

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

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

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

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

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

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

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

Размещенные агенты получают доступ к средствам, управляемым Foundry (интерпретатор кода, веб-поиск, Поиск с использованием ИИ Azure, OpenAPI, пользовательские подключения MCP, A2A) через конечную точку Toolbox MCP подготовленную в проекте Foundry. Код агента подключается к этой конечной точке с помощью стандартных клиентских библиотек MCP— платформа не внедряет средства автоматически. Дополнительные сведения см. в наборе инструментов на основе намерений в Foundry. Мы рекомендуем клиентам использовать инструментарий в Foundry для подключения инструментов в размещенном агенте с консолидированной поддержкой проверки подлинности через сквозную проверку OAuth, идентификация агента, на основе ключей доступа и другие способы.

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

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

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

Размещенные песочницы агента поддерживают выделение ЦП и памяти в диапазоне от 0,25 виртуальных ЦП / 0,5 ГиБ до 2 виртуальных ЦП / 4 ГиБ.

Частная сеть

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

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

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

Ограничения во время предварительной версии

Ограничение Область Значение по умолчанию Регулируемый
Максимальное число активных одновременных сеансов для каждой подписки на регион 50 Да, с запросами квоты в службу поддержки Microsoft

Цены

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

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

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

  • Восточная часть США 2
  • Северная часть США
  • Центральная Швеция
  • Центральная Канада
  • Юго-Восточная Азия
  • Центральная Польша
  • Южная Африка Север
  • Центральная Корея
  • Южная Индия
  • Южная Бразилия
  • Западная часть США
  • Западная часть США 3
  • Восточная Норвегия
  • Восточная Япония
  • Центральная Франция
  • Северная Швейцария
  • Центральная Испания
  • Восточная Австралия

Примечание

Этот список будет обновлен по мере того, как становятся доступными дополнительные регионы.

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

Задача Ссылку
Создание и развертывание первого облачного агента Быстрое начало: Развертывание первого хостинг-агента
Развертывание с помощью пакета SDK для Foundry Развертывание размещенного агента с помощью пакета SDK Для Foundry
Обновление, удаление, вызов или потоковые журналы Управление размещенными агентами
Настройка трассировки и мониторинга Включение трассировки в проекте
Оценка производительности агента Оценщики агентов
Публикация в Teams, M365 или пользовательских приложениях Приложения агента
Обзор примеров кода Python примеры · примеры C#

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

  • Last updated on