Поделиться через

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

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

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

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

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

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

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

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

Это важно

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

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

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

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

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

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

Размещенные контейнеры агентов открывают доступ к одному или обоим из двух протоколов. Каждый протокол предоставляется упрощенной библиотекой, которая обрабатывает 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 для ответов Произвольный JSON через интерфейс /invocations — вы определяете схему
Клиентский пакет SDK Любой SDK, совместимый с OpenAI (Python, JS, C#), сразу готов к использованию. Кастомизированный клиент — вы определяете договор
Журнал сеансов Управление платформой через идентификатор беседы Вы управляете сеансами (в памяти, Cosmos DB и т. д.)
Streaming Управляемый платформой ResponseEventStream с событиями жизненного цикла Необработанный SSE— вы форматируйте и записываете события напрямую
Фоновый / длительно работающий процесс Встроенная (фоновый режим: true + опрос, управляемый платформой) Отслеживание задач вручную и пользовательские конечные точки опроса

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

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

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

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

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

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

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

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

Identity Scope Purpose
Удостоверение личности агента Entra (каждого агента) Создается автоматически во время развертывания Идентификационные данные контейнера агента аутентифицируются в момент выполнения. Используется для вызова модели, доступа к инструментам и подчиненных служб Azure.
Управляемое удостоверение проекта (на уровне проекта) Назначаемое системой в проекте Foundry Используется платформой для операций инфраструктуры (например, средство чтения репозитория реестра контейнеров в реестре контейнеров). Не идентификатор среды выполнения агента.

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

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

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

Сеансы

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

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

Беседы

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

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

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

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

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

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

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

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

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

Это важно

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

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

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

Versioning

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

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

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

Размещенные агенты получают доступ к средствам, управляемым Foundry (интерпретатор кода, веб-поиск, поиск Azure AI, OpenAPI, пользовательские подключения MCP, A2A) через точку доступа MCP Toolbox, подготовленную в вашем проекте Foundry. Код агента подключается к этой конечной точке с помощью стандартных клиентских библиотек MCP— платформа не внедряет средства автоматически. Дополнительные сведения см. в разделе «Curate — набор инструментов на основе намерений в Foundry».

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

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

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

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

Частная сеть

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

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

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

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

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

Pricing

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

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

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

  • Australia East
  • Центральная Канада
  • северо-центральная часть США
  • Центральная Швеция

Замечание

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

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

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

Связанный контент

  • Last updated on