· · 3 минут чтения

Где размещать AI-агентов в Azure? Практическое руководство по выбору

Azure предлагает шесть способов размещения AI-агентов — от контейнеров до полностью управляемых Foundry Hosted Agents. Вот как выбрать подходящий вариант для вашей .NET нагрузки.

azure ai agents containers microsoft-foundry cloud-native aks
Эта статья также доступна на:English, Español, Deutsch, Français, Português, Italiano, 日本語, 中文, 한국어

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

Если вы сейчас создаёте AI-агентов с .NET, вы наверняка заметили: способов разместить их в Azure очень много. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — и все звучат разумно, пока вам не нужно действительно выбрать один. Microsoft только что опубликовала полное руководство по размещению AI-агентов в Azure, и я хочу разобрать его с практической точки зрения .NET-разработчика.

Шесть вариантов с первого взгляда

ВариантЛучше всего дляВы управляете
Container AppsПолный контроль контейнеров без сложности K8sНаблюдаемость, состояние, жизненный цикл
AKSКорпоративный комплаенс, мультикластер, пользовательские сетиВсем (в этом и суть)
Azure FunctionsСобытийные краткосрочные задачи агентовПочти ничем — настоящий serverless
App ServiceПростые HTTP-агенты, предсказуемый трафикРазвёртывание, настройка масштабирования
Foundry AgentsАгенты без кода через портал/SDKПочти ничем
Foundry Hosted AgentsАгенты с пользовательским фреймворком на управляемой инфраструктуреТолько ваш код агента

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

Foundry Hosted Agents — оптимальный выбор для .NET-разработчиков агентов

Вот что привлекло моё внимание. Foundry Hosted Agents находятся точно посередине: вы получаете гибкость запуска собственного кода (Semantic Kernel, Agent Framework, LangGraph — что угодно), а платформа управляет инфраструктурой, наблюдаемостью и управлением разговорами.

Ключевой элемент — Hosting Adapter — тонкий слой абстракции, который соединяет ваш фреймворк агентов с платформой Foundry. Для Microsoft Agent Framework это выглядит так:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
    chat_client=AzureAIAgentClient(...),
    instructions="You are a helpful assistant.",
    tools=[get_local_time],
)

if __name__ == "__main__":
    from_agent_framework(agent).run()

Это вся ваша история хостинга. Адаптер обрабатывает трансляцию протоколов, стриминг через server-sent events, историю разговоров и трассировку OpenTelemetry — всё автоматически. Никакого пользовательского middleware, никакой ручной прокладки.

Развёртывание действительно простое

Я раньше развёртывал агентов в Container Apps, и это работает, но в итоге вы пишете много связующего кода для управления состоянием и наблюдаемости. С Hosted Agents и azd развёртывание — это:

# Установить расширение AI-агента
azd ext install azure.ai.agents

# Инициализировать из шаблона
azd ai agent init

# Собрать, отправить, развернуть — готово
azd up

Эта единственная команда azd up собирает ваш контейнер, отправляет его в ACR, создаёт проект Foundry, развёртывает endpoints моделей и запускает вашего агента. Пять шагов сжаты в одну команду.

Встроенное управление разговорами

Это та часть, которая экономит больше всего времени в продакшене. Вместо создания собственного хранилища состояния разговоров, Hosted Agents обрабатывают это нативно:

# Создать постоянный разговор
conversation = openai_client.conversations.create()

# Первый ход
response1 = openai_client.responses.create(
    conversation=conversation.id,
    extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
    input="Remember: my favorite number is 42.",
)

# Второй ход — контекст сохранён
response2 = openai_client.responses.create(
    conversation=conversation.id,
    extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
    input="Multiply my favorite number by 10.",
)

Никакого Redis. Никакого хранилища сессий Cosmos DB. Никакого middleware для сериализации сообщений. Платформа просто справляется.

Мой фреймворк принятия решений

Пройдя все шесть вариантов, вот моя быстрая ментальная модель:

  1. Нужен нулевой уровень инфраструктуры? → Foundry Agents (портал/SDK, без контейнеров)
  2. Есть пользовательский код агента, но нужен управляемый хостинг? → Foundry Hosted Agents
  3. Нужны событийные краткосрочные задачи агентов? → Azure Functions
  4. Нужен максимальный контроль контейнеров без K8s? → Container Apps
  5. Нужен строгий комплаенс и мультикластер? → AKS
  6. Простой HTTP-агент с предсказуемым трафиком? → App Service

Для большинства .NET-разработчиков, работающих с Semantic Kernel или Microsoft Agent Framework, Hosted Agents — вероятно правильная отправная точка. Вы получаете scale-to-zero, встроенный OpenTelemetry, управление разговорами и гибкость фреймворка — без управления Kubernetes или создания собственного стека наблюдаемости.

Подводя итог

Ландшафт хостинга агентов в Azure быстро зреет. Если вы начинаете новый проект AI-агента сегодня, я бы серьёзно рассмотрел Foundry Hosted Agents, прежде чем по привычке тянуться к Container Apps или AKS. Управляемая инфраструктура экономит реальное время, а паттерн hosting adapter позволяет сохранить ваш выбор фреймворка.

Ознакомьтесь с полным руководством Microsoft и репозиторием Foundry Samples для рабочих примеров.

Поделиться:
Просмотреть исходный код этой статьи на GitHub ↗
← Agent Skills в .NET стали по-настоящему гибкими
Azure Smart Tier вышел в GA — Автоматическая оптимизация стоимости Blob Storage без правил жизненного цикла →