Azure Functions | The .NET Blog

Устойчивые рабочие процессы в Microsoft Agent Framework: от In-Memory до Azure Functions

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

Одна из болевых точек ранних рабочих процессов ИИ-агентов: они хрупкие. Долгосрочный многошаговый рабочий процесс, привязанный к одному процессу, означает, что перезапуск процесса = потеря состояния. Для простых демо это нормально. Для производственных нагрузок — нет.

Модель программирования рабочих процессов Microsoft Agent Framework теперь поддерживает устойчивое выполнение, основанное на фреймворке Durable Task, с хостингом в Azure Functions. Вот как работает модель программирования и почему история устойчивости важна.

Основные строительные блоки

Executor’ы — это фундаментальная единица работы. Каждый типизирован — принимает определённый ввод и производит определённый вывод:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // найти заказ, вернуть его
 return new Order(Id: message.OrderId, ...);
 }
}

Рабочие процессы соединяют executor’ы в направленные графы с помощью fluent builder’а. Фреймворк берёт на себя выполнение, поток данных между шагами и распространение ошибок.

Вы можете моделировать:

Последовательные цепочки (шаг A → шаг B → шаг C)
Параллельный fan-out/fan-in (запускать агентов A, B, C параллельно, агрегировать результаты)
Условное ветвление
Одобрения с участием человека (приостановить рабочий процесс, ждать внешнего сигнала)

In-Memory-раннер для локальной разработки

Начать работу просто:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

Основной пакет включает лёгкий in-process раннер. Никаких внешних зависимостей, никакой базы данных, никаких ресурсов Azure. Отлично подходит для локальной разработки и модульного тестирования.

Добавление устойчивости с Durable Task

Когда рабочий процесс должен пережить перезапуски процесса — потому что он долгосрочный, потому что имеет шаги с участием человека, потому что распределяется на множество параллельных вызовов агентов — in-memory раннер недостаточен.

Интеграция Durable Task в MAF хранит состояние рабочего процесса в Azure Storage. Если процесс перезапускается, рабочий процесс возобновляется с того места, где остановился. Модель программирования остаётся прежней; вы просто меняете раннер.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Те же executor’ы, тот же граф рабочего процесса — основан на устойчивом состоянии.

Хостинг в Azure Functions

Третий уровень — хостинг в Azure Functions. Ваш рабочий процесс становится Function-приложением: запускайте его через HTTP-эндпоинт, а устойчивая среда выполнения управляет масштабированием, состоянием и надёжностью.

Это означает, что мультиагентный рабочий процесс с параллельными вызовами, условными ветвями и человеческими одобрениями может масштабироваться в среде serverless Functions без пользовательского управления состоянием.

Почему это важно

Комбинация значима для реальных ИИ-систем:

Параллельные вызовы агентов — одновременно распределять на несколько специализированных агентов без блокировки, агрегировать результаты когда все завершат
Долгосрочные процессы — рабочие процессы с участием человека или внешними событиями могут приостанавливаться и возобновляться на протяжении часов или дней
Масштабирование — Azure Functions масштабирует выполнение горизонтально; фреймворк Durable Task управляет координацией параллельного состояния

Если вы создаёте рабочие процессы MAF за пределами простых локальных демо, это путь к выполнению производственного качества.

Оригинальная публикация: Durable Workflows in the Microsoft Agent Framework

Перестаньте Атаковать Проблемную Зависимость: Паттерны Повторных Попыток для Azure Functions + Service Bus

Emiliano Montesdeoca — Thu, 21 May 2026 00:00:00 +0000

Вот как восстанавливаемая ошибка превращается в отказ в приложении Functions: зависимость начинает давать таймаут, каждый экземпляр Functions немедленно и бесконечно повторяет попытки, зависимость получает сотни одновременных неудавшихся запросов, и то, что началось как временный сбой, превращается в событие противодавления во всей системе.

Вы, вероятно, знаете эту историю. Azure Functions масштабируется быстро — в этом весь смысл. Но “быстро масштабировать” и “немедленно повторять” вместе могут драматически ухудшить сбои.

Два паттерна помогают. Экспоненциальная задержка и автоматический выключатель. Оба теперь нативно поддерживаются для Azure Functions, запускаемых Service Bus.

Два Паттерна, Разные Роли

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

Экспоненциальная задержка отвечает на вопрос: когда мне следует повторить попытку? Она увеличивает задержку между попытками, чтобы зависимость имела время восстановиться. На уровне сообщений, регулируя тайминг повторных попыток.

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

Вам нужны оба. Задержка управляет темпом повторных попыток на уровне сообщений. Автоматический выключатель управляет агрегированными решениями о работоспособности.

Почему Это Особенно Важно для Service Bus

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

Более безопасный дизайн:

Обнаружить временный сбой
Задержать следующую попытку с экспоненциальной задержкой
Остановить вызовы к зависимости при достижении порогового значения ошибок (цепь разомкнута)
Осторожно возобновить после периода охлаждения (зондирование цепи)
Переместить невосстанавливаемую работу в dead-letter или путь карантина

Как Выглядит Нативная Поддержка

Новая поддержка интегрируется с существующей моделью хоста Azure Functions — без дополнительных библиотек, без пользовательских реализаций. Конфигурация помещается в ваш host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

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

Поддерживаемые Языки

Это не только для .NET. Функция охватывает dotnet, JavaScript, TypeScript и Python — полный набор языков, поддерживаемых триггером Service Bus в Azure Functions.

Заключение

Паттерны повторных попыток не интересно настраивать до первого раза, когда сбой в нижестоящей системе заставляет ваши Functions усугублять проблему вместо плавного ухудшения. Настраивать их проактивно недорого. Реализовывать их во время инцидента — нет.

Оригинальная статья: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

MCP Apps получили Fluent API — Создавайте богатые UI для AI-инструментов на .NET за три шага

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

MCP-инструменты отлично подходят для наделения AI-агентов возможностями. Но что, если вашему инструменту нужно показать что-то пользователю — дашборд, форму, интерактивную визуализацию? Именно для этого и существуют MCP Apps, и теперь их стало намного проще создавать.

Лилиан Касем из команды Azure SDK представила новый Fluent API конфигурации для MCP Apps на .NET Azure Functions — это такое улучшение опыта разработчика, что невольно задаёшься вопросом, почему так просто не было всегда.

Что такое MCP Apps?

MCP Apps расширяют Model Context Protocol, позволяя инструментам нести собственные UI-представления, статические ресурсы и средства управления безопасностью. Вместо простого возврата текста ваш MCP-инструмент может отрисовывать полноценные HTML-интерфейсы — интерактивные дашборды, визуализации данных, формы конфигурации — всё это вызывается AI-агентами и отображается пользователям через MCP-клиенты.

Проблема была в том, что ручная настройка всего этого требовала глубокого знания спецификации MCP: URI ui://, специальные MIME-типы, координация метаданных между инструментами и ресурсами. Не сложно, но утомительно.

Fluent API за три шага

Шаг 1: Определите свою функцию. Стандартный MCP-инструмент Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Шаг 2: Преобразуйте его в MCP App. В стартапе вашей программы:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Шаг 3: Добавьте HTML-представление. Создайте assets/hello-app.html с нужным вам интерфейсом.

Вот и всё. Fluent API берёт на себя всю сантехнику MCP-протокола — генерирует синтетическую ресурсную функцию, устанавливает правильный MIME-тип и внедряет метаданные, связывающие ваш инструмент с его представлением.

API спроектирован отлично

Несколько вещей, которые мне особенно нравятся:

Источники представлений гибкие. Можно отдавать HTML из файлов на диске или встраивать ресурсы прямо в сборку для автономных развёртываний:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP компонуемый. Вы явно разрешаете источники, необходимые вашему приложению, следуя принципу наименьших привилегий. Вызывайте WithCsp несколько раз — источники накапливаются:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Управление видимостью. Можно сделать инструмент видимым только для LLM, только для UI хоста или для обоих. Хотите инструмент, который только отрисовывает UI и не должен вызываться моделью? Легко:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Начало работы

Добавьте превью-пакет:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Если вы уже создаёте MCP-инструменты с Azure Functions, это просто обновление пакета. Быстрый старт MCP Apps — лучшее место для начала, если вы новичок в этой концепции.

Подводя итоги

MCP Apps — одно из самых захватывающих нововведений в пространстве AI-инструментов: инструменты, которые не просто делают что-то, но могут показывать что-то пользователям. Fluent API убирает сложность протокола и позволяет сосредоточиться на главном: логике вашего инструмента и его интерфейсе.

Прочитайте полный пост для полного справочника по API и примеров.

Подключите ваши MCP-серверы на Azure Functions к агентам Foundry — Вот как

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Вот что мне нравится в экосистеме MCP: вы создаёте сервер один раз, и он работает везде. VS Code, Visual Studio, Cursor, ChatGPT — каждый MCP-клиент может обнаруживать и использовать ваши инструменты. Теперь Microsoft добавляет ещё одного потребителя в этот список: агенты Foundry.

Лили Ма из команды Azure SDK опубликовала практическое руководство по подключению MCP-серверов на Azure Functions к агентам Microsoft Foundry. Если у вас уже есть MCP-сервер, это чистая добавленная ценность — никакой перестройки не требуется.

Почему эта комбинация имеет смысл

Azure Functions даёт вам масштабируемую инфраструктуру, встроенную аутентификацию и бессерверную тарификацию для хостинга MCP-серверов. Microsoft Foundry даёт вам AI-агентов, которые могут рассуждать, планировать и выполнять действия. Соединение этих двух означает, что ваши пользовательские инструменты — запросы к базе данных, вызовы бизнес-API, выполнение логики валидации — становятся возможностями, которые корпоративные AI-агенты могут автономно обнаруживать и использовать.

Ключевой момент: ваш MCP-сервер остаётся прежним. Вы просто добавляете Foundry как ещё одного потребителя. Те же инструменты, которые работают в вашей конфигурации VS Code, теперь обеспечивают работу AI-агента, с которым взаимодействуют ваша команда или клиенты.

Варианты аутентификации

Здесь статья действительно приносит пользу. Четыре метода аутентификации в зависимости от вашего сценария:

Метод	Сценарий
На основе ключей (по умолчанию)	Разработка или серверы без аутентификации Entra
Microsoft Entra	Продакшн с управляемыми удостоверениями
Проброс OAuth-удостоверений	Продакшн, где каждый пользователь аутентифицируется отдельно
Без аутентификации	Разработка/тестирование или только публичные данные

Для продакшна рекомендуется Microsoft Entra с идентификацией агента. Проброс OAuth-удостоверений — для случаев, когда важен контекст пользователя: агент предлагает пользователям войти, и каждый запрос несёт собственный токен пользователя.

Настройка

Общий поток:

Разверните MCP-сервер на Azure Functions — доступны примеры для .NET, Python, TypeScript и Java
Включите встроенную MCP-аутентификацию на вашем function app
Получите URL эндпоинта — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Добавьте MCP-сервер как инструмент в Foundry — перейдите к агенту в портале, добавьте новый MCP-инструмент, укажите эндпоинт и учётные данные

Затем протестируйте в песочнице Agent Builder, отправив запрос, который активирует один из ваших инструментов.

Моё мнение

История компонуемости здесь становится по-настоящему сильной. Создайте MCP-сервер один раз на .NET (или Python, TypeScript, Java), разверните на Azure Functions, и каждый MCP-совместимый клиент может его использовать — инструменты для кодирования, чат-приложения, а теперь и корпоративные AI-агенты. Это паттерн «напиши один раз, используй везде», который действительно работает.

Для .NET-разработчиков конкретно, расширение MCP для Azure Functions делает это простым. Вы определяете инструменты как Azure Functions, развёртываете — и у вас есть MCP-сервер продакшн-уровня со всей безопасностью и масштабированием, которые предоставляет Azure Functions.

Подводя итоги

Если у вас есть MCP-инструменты на Azure Functions, подключение к агентам Foundry — быстрый выигрыш: ваши пользовательские инструменты становятся корпоративными AI-возможностями с правильной аутентификацией и без изменений кода на сервере.

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