Azure | The .NET Blog

Microsoft Foundry Апрель 2026: Foundry Local GA, GPT-5.5, CodeAct с Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Насыщенный месяц для Microsoft Foundry. Вот самые важные анонсы.

Foundry Local Стал Общедоступным

Foundry Local — кроссплатформенная локальная среда выполнения ИИ от Microsoft — переходит из предварительной версии в GA на Windows, macOS (Apple Silicon) и Linux x64. Готовая к производству локальная inference моделей с удобным для разработчиков SDK. Версия 1.1 добавляет поддержку транскрипции, embeddings и API Responses.

GPT-5.5

Последняя модель семейства GPT-5 теперь доступна в Foundry. Квота по умолчанию для подписок Tier 5 и Tier 6. Если вы работали с более ранними вариантами GPT-5, стоит оценить его для своих случаев использования.

Трассировка Agent Framework в Foundry

В этом месяце в предварительную версию выходят две функции трассировки:

Трассировка Microsoft Agent Framework — Агенты MAF теперь могут отправлять трассировки OpenTelemetry в Foundry. Отлаживайте поведение агентов, отслеживайте многошаговое выполнение, выявляйте задержки и ошибки во вызовах инструментов. Это заполняет реальный пробел: знать что именно сделал ваш агент в продакшене, не только что он вернул.

Трассировка hosted-агентов — Сессии, вызовы инструментов и шаги выполнения hosted-агентов также отображаются в трассировках Foundry. Та же история наблюдаемости распространяется на hosted-уровень.

CodeAct с Hyperlight (Alpha)

Это технически самое интересное дополнение: Agent Framework теперь может выполнять код Python внутри микро-виртуальных машин Hyperlight.

CodeAct — это паттерн, где агент генерирует и выполняет код Python как инструмент. Очевидная проблема — безопасность: вы запускаете код, сгенерированный моделью. Микро-VM Hyperlight обеспечивают изоляцию на уровне процесса с временем запуска близким к нативному, делая выполнение кода в sandbox практичным без накладных расходов полных контейнеров или VM.

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

Панель Мониторинга Агентов (Предварительная Версия)

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

Пользовательские Эвалюаторы Непрерывной Оценки (Предварительная Версия)

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

Инвентарь Агентов в Плоскости Управления

Представление Operate в Плоскости Управления Foundry теперь показывает все поддерживаемые агенты в рамках подписки: агенты Foundry, Azure SRE Agent, циклы агентов Logic Apps и зарегистрированные пользовательские агенты. Одно представление для понимания того, что развёрнуто и где.

Оригинальная публикация: What’s new in Microsoft Foundry | April 2026

Ваш Локальный Агент MAF Только Что Получил Дом в Продакшене

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Заставить агента работать локально — это весёлая часть. Сложная часть — всё, что идёт после: развернуть его без потери рассудка, управлять сессиями, настроить идентичность, подключить наблюдаемость. Обычно это означает много пользовательской инфраструктурной склейки.

Foundry Hosted Agents только что убрал большую часть этой склейки для пользователей Microsoft Agent Framework (MAF).

Что На Самом Деле Делает Foundry Hosted Agents

Когда вы развёртываете агент MAF в Foundry Hosted Agents, платформа берёт на себя удивительно длинный список вещей, которые вам иначе пришлось бы строить самостоятельно:

Масштабирование до нуля — ваш агент ничего не стоит в простое и автоматически запускается снова
Изолированные VM-сандбоксы на сессию — каждая пользовательская сессия получает собственный сандбокс с персистентностью файловой системы, которая переживает события масштабирования вниз
Встроенный Entra ID — каждый агент получает собственную идентичность для вызова моделей Foundry, Toolbox и сервисов Azure без секретов в образе
Версионированные развёртывания — каждое развёртывание является неизменяемым снимком с поддержкой blue/green и canary выкатки
Наблюдаемость без настройки — APPLICATIONINSIGHTS_CONNECTION_STRING внедряется в runtime, так что трейсы OpenTelemetry MAF автоматически попадают в App Insights

Последнее действительно приятно. Никакого дополнительного подключения, никакой дополнительной настройки. Трейсы просто появляются.

Разница в Коде Минимальна

Именно это мне нравится больше всего в этой интеграции. Вы не переписываете своего агента. Вы просто оборачиваете его:

В .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

В Python:

server = ResponsesHostServer(agent)
server.run()

Это всё. Та же логика, которую вы тестировали локально, работает в продакшене. Платформа оборачивает её инфраструктурой управления сессиями, идентичностью и масштабированием.

Два Протокола, Один Агент

Hosted Agents поддерживают два стиля эндпоинтов:

Responses (/responses) — совместим с OpenAI, управляет историей разговора и стримингом. Хороший выбор по умолчанию для чат-агентов.
Invocations (/invocations) — вы определяете схему запроса/ответа. Хорошо для неконверсационных рабочих процессов.

Если вы строите что-то похожее на разговор, начните с Responses. Если вы строите API-подобного агента, который принимает структурированный ввод и возвращает структурированный вывод, Invocations даёт вам гибкость.

Процесс Развёртывания с `azd`

Когда вы запускаете azd up с агентом MAF:

Опционально создаёт проект Foundry и развёртывает модель
Упаковывает ваш код и отправляет образ в Azure Container Registry
Подготавливает вычислительные ресурсы из образа ACR
Назначает агенту выделенный Entra ID
Открывает стабильный эндпоинт (https://{project_endpoint}/agents/{agent_name})
Обрабатывает всё остальное с этого момента

Сессии сохраняются до 30 дней. Неактивные вычислительные ресурсы деподготавливаются через 15 минут и прозрачно восстанавливаются при следующем запросе. С точки зрения агента ничего не изменилось.

Заключение

Расстояние между “работает локально” и “запускается в продакшене” исторически было долгим и болезненным для ИИ-агентов. Foundry Hosted Agents + MAF значительно сокращает этот разрыв. Если у вас уже есть локальный агент, построенный с Agent Framework, это стоит попробовать сегодня.

Команда говорит, что GA придёт скоро — сейчас это в preview. Ознакомьтесь с документацией по интеграции MAF Hosted Agent и примерами .NET для начала работы.

Оригинальная статья: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1: Транскрипция в реальном времени, Embeddings и Responses API

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

Foundry Local 1.0 доказал концепцию: запускать модели ИИ локально на Windows, macOS (Apple Silicon) и Linux x64 с дружественным для разработчиков SDK. Версия 1.1 добавляет три возможности, покрывающие множество реальных производственных сценариев.

Живая транскрипция аудио

Наиболее значимая новая функция: потоковое преобразование речи в текст в реальном времени непосредственно с микрофона. Субтитры, голосовые интерфейсы, транскрипция встреч, инструменты доступности — всё работает локально без каких-либо облачных зависимостей.

API является сессионным и передаёт результаты по мере их поступления с маркерами is_final для разграничения промежуточного и финализированного текста. Доступно для всех языковых привязок: JavaScript, C#, Python и Rust.

Загрузите потоковую речевую модель из каталога, создайте сессию с настройками аудио (частота дискретизации, каналы, язык), запустите её, отправляйте необработанные PCM-аудиочанки и потребляйте асинхронный поток результатов. В статье есть полные примеры на Python и C#.

Text Embeddings

Семантический поиск, RAG-пайплайны, кластеризация, сопоставление по схожести — всё это требует embeddings. Foundry Local 1.1 добавляет поддержку embedding-моделей, чтобы генерировать векторы локально из того же SDK без отправки данных на облачный эндпоинт.

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

Responses API

Foundry Local теперь поддерживает Responses API — структурированный интерфейс для агентных взаимодействий. Это добавляет:

Вызов инструментов — позволяет локально работающим моделям вызывать инструменты, которые вы определяете
Мультимодальный ввод vision-language — передавайте изображение + текст моделям с поддержкой зрения
Совместимость со стандартной формой API, поэтому существующие агенты, нацеленные на Responses API OpenAI, работают с локальными моделями

Улучшения размера пакета

Два изменения уменьшают размер пакета JavaScript:

Слой FFI koffi был заменён на пользовательский Node-API C аддон
Провайдер выполнения WebGPU поставляется как отдельный плагин, так что приложениям без GPU-ускорения не нужно платить за его размер

SDK для C# теперь нацелен на более низкие версии фреймворка для более широкой совместимости с .NET.

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

Три возможности вместе — транскрипция, embeddings, вызов инструментов — покрывают основные строительные блоки многих приложений ИИ. Запуск их локально означает:

Интернет не требуется
Нет платы за токены
Данные не покидают машину
Стабильная задержка независимо от сетевых условий

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

Оригинальный пост: Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell В Публичной Предварительной Версии — И В Нём Встроен MCP-Сервер

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

Если вы когда-либо вынуждены были переключаться между вкладкой портала, примером SDK и незаконченным скриптом только для ответа на один вопрос о Cosmos DB, вы уже знаете трение, которое этот проект призван устранить.

Azure Cosmos DB Shell только что вошёл в публичную предварительную версию. Это CLI с открытым исходным кодом с bash-подобным синтаксисом и — часть, которая делает это интересным — встроенным MCP-сервером.

Что Отличает Его от Других CLI Баз Данных

CLI сам по себе полезен: знакомые команды, поддержка скриптов, интеграция CI/CD. Эта часть — минимальный стандарт для инструмента базы данных, ориентированного на разработчиков.

Интересная часть — интеграция MCP-сервера. Каждая команда, которую предоставляет CLI, становится доступной как MCP-инструмент, который ваши ИИ-агенты могут вызывать. Нет пользовательского API-слоя, нет кода интеграции для написания. Ваш агент может:

Навигировать по иерархиям баз данных с помощью cd, ls, pwd
Выполнять SQL-запросы с помощью query и получать структурированные результаты
Создавать и изменять элементы с помощью create item, update, rm
Управлять базами данных и контейнерами с помощью mkdb, mkcon, rmdb, rmcon
Инспектировать текущий контекст с помощью endpoint, pwd

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

Основа с Открытым Исходным Кодом Важна

Это не управляемый сервис “чёрного ящика”. Оболочка имеет открытый исходный код, что означает:

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

Для корпоративных команд, внедряющих инструменты ИИ, “можем ли мы точно видеть, как это работает” всё реже является необязательным требованием. Открытый исходный код здесь — значимое отличие.

Три Сценария, Которые Становятся Проще

Интеллектуальный анализ данных — подключите агента к оболочке, задавайте вопросы на естественном языке, получайте структурированные результаты запросов. Агент обрабатывает построение запроса; оболочка обрабатывает выполнение.

Автономное управление данными — рабочие процессы, которым необходимо создавать, обновлять или удалять данные в Cosmos DB, могут делать это через MCP-инструменты без необходимости пользовательской интеграции.

Мониторинг и оповещения в реальном времени — агент может периодически запрашивать контейнеры, сравнивать результаты и выявлять аномалии через подходящий канал уведомлений.

Интерфейс MCP делает эти сценарии компонуемыми с любой ИИ-платформой, поддерживающей MCP — не только с инструментами Microsoft.

С Чего Начать

Оболочка находится в публичной предварительной версии. Установите её, настройте подключение к Cosmos DB и включите MCP-сервер. После этого любой совместимый с MCP хост агента может обнаружить и использовать инструменты.

Оригинальный пост: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

У Вашего ИИ-Агента Проблема с Идентификацией (И Вот Шаблон, Который Её Решает)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

Есть момент в каждом проекте ИИ-агента, который выглядит примерно так: демо работает идеально, агент интерпретирует естественный язык, вызывает нужные API, возвращает нужные данные. Затем вы начинаете думать о реальных пользователях.

Что мешает сессии агента одного пользователя видеть данные другого пользователя? Что если агент будет обманут через инъекцию промпта? Что если он вызовет инструмент неожиданным образом?

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

Новый шаблон azd от Curity и Microsoft даёт вам рабочий эталон именно для этой проблемы.

Основная Проблема: Аутентификация ≠ Авторизация

Большинство примеров агентов хорошо справляются с аутентификацией пользователей. Они плохо справляются с авторизацией. Знание кто является пользователем не говорит вам, какие данные он должен видеть.

Традиционное клиентское приложение делает предсказуемые вызовы API. ИИ-агент не является детерминированным — он интерпретирует естественный язык и решает, что вызывать. Он может быть творческим. Он также может ошибаться. И если он манипулируется через инъекцию промпта, вам нужны правила, которые не зависят от хорошего поведения ИИ.

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

Как Работает Цепочка Токенов

Шаблон использует токены доступа OAuth 2.0 с обменом токенов для сужения разрешений на каждом шаге. Токен пользователя обменивается дважды, прежде чем достигнет MCP-сервера:

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

Как выглядит токен MCP-сервера:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id встроен в токен сервером авторизации, а не передаётся как параметр, которым управляет агент. API проверяет токен, а не инструкции агента.

Это означает: даже если кто-то обманет агента, заставив его попытаться получить данные другого клиента, токен не авторизует это.

Что Развёртывает Шаблон

С несколькими командами azd вы получаете:

Бэкенд-агент на Microsoft Foundry (C#, SDK Microsoft A2A и MCP)
MCP-сервер, предоставляющий пример портфельного API
Curity Identity Server в качестве сервера авторизации, наряду с Entra ID для аутентификации
Внешние и внутренние API-шлюзы, обрабатывающие обмен токенов и журналирование аудита
Bicep для всей инфраструктуры Azure: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, хранилище

Весь шаблон поддаётся проверке и настройке.

Принцип Дизайна, Достойный Заимствования

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

Это устойчиво к творческим агентам, ошибкам и инъекции промпта теми способами, которыми «просто убедитесь, что агент не делает плохих вещей» никогда не будет.

Заключение

Шаблоны безопасности для ИИ-агентов всё ещё разрабатываются в отрасли. Этот шаблон является одной из наиболее полных эталонных реализаций, которые я видел — он охватывает фактический поток авторизации, а не только аутентификацию.

Оригинальный пост: Least privilege AI agents: A new azd template from Curity and Microsoft

Частные Endpoints, VNets, NSG — Aspire Теперь Управляет Сетью

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Я видел этот сценарий слишком много раз. Приложение готово. Демонстрация великолепна. Затем появляется чеклист безопасности: убрать хранилище из публичного интернета, запустить внутри VNet, предоставить исходящие IP для allowlist партнёра, доказать, что только правильные подсети общаются с правильными сервисами.

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

Новая поддержка корпоративных сетей Azure для Aspire решает это напрямую. Вы описываете форму сети рядом с ресурсами, которые её используют, в вашем AppHost.

Строительные блоки

Вот для чего предназначена каждая концепция сети Azure, в кратком изложении:

Функция	Используйте когда	Почему это важно
Виртуальная сеть	Вам нужно частное адресное пространство	Сетевая граница для подсетей, частных endpoints и маршрутизации
Подсеть	Вам нужно разделить рабочие нагрузки внутри VNet	Каждая часть системы получает свой собственный диапазон адресов и поверхность политики
Делегированная подсеть	Платформенный сервис (например, ACA) должен управлять подсетью	Позволяет сервису безопасно размещать управляемую инфраструктуру в вашей VNet
NAT-шлюз	Вам нужны предсказуемые исходящие публичные IP	Стабильный адрес для allowlist и аудита
Частный endpoint	Вы хотите, чтобы ресурс PaaS был доступен приватно	Помещает частный IP для этого сервиса внутри вашей VNet, убирает публичную экспозицию
NSG	Вам нужны правила трафика на уровне подсети	Явное разрешение/запрет для входящего и исходящего трафика на подсеть

Описание в AppHost

Ключевое изменение здесь состоит в том, что вы моделируете сеть вместе с ресурсами, которые её используют, а не в отдельном файле Bicep, который со временем расходится с моделью приложения.

Из AppHost вы можете:

Создавать VNet и подсети с AddVirtualNetwork() и AddSubnet()
Прикреплять NAT-шлюз к подсетям для стабильных исходящих IP
Создавать частные endpoints для хранилища, Key Vault, SQL и других PaaS-сервисов
Определять NSG с правилами входящей и исходящей безопасности
Настраивать периметры сетевой безопасности для межресурсных политик

В результате когда вы запускаете azd up, инфраструктура соответствует тому, что модель приложения говорит, что ей нужно. Не то, что говорит вручную поддерживаемый шаблон.

Почему Это Важно для Реальных Приложений

Несколько вещей, которые становятся значительно проще, как только сеть смоделирована в Aspire:

Частные endpoints для Key Vault и хранилища — вы описываете WithPrivateEndpoint() на этих ресурсах, и Aspire берёт на себя настройку DNS-зон и присоединение endpoints. Приложение никогда не меняется.

Стабильные исходящие IP — добавьте NAT-шлюз к соответствующей подсети, и каждый исходящий запрос вашего приложения проходит через известный, стабильный IP. Партнёры могут добавить его в allowlist. Аудиторы могут его отследить.

Правила NSG из кода — вместо того чтобы кликать по порталу или поддерживать фрагмент Bicep, ваши правила безопасности живут в AppHost рядом с ресурсами, которые они защищают.

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

Итог

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

Полные подробности в оригинальном посте: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Поддержка Kubernetes, журналы браузера и навык Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Пять недель — небольшой срок для релиза, но Aspire 13.3 так не ощущается. Ключевые элементы весомые: первоклассное развёртывание Kubernetes и AKS с Helm, навык онбординга с помощью агента под названием Aspireify, захват журналов браузера прямо в дашборде и структурированные результаты команд. Плюс 45 новых функций, 134 улучшения и 93 исправления ошибок.

Давайте разберём основные моменты.

Aspireify: Онбординг с помощью агента

Добавление Aspire к существующему проекту звучит просто — добавьте AppHost, готово. На практике это требует немало исследований: какие порты важны, какие переменные окружения являются реальными зависимостями, какие сервисы Docker Compose должны отображаться на интеграции Aspire.

Новый навык Aspireify даёт вашему агенту кодирования управляемый рабочий процесс именно для этого. Когда aspire init создаёт скелетный AppHost, навык Aspireify помогает агенту проверить репозиторий, понять как он уже работает и подключить AppHost так, чтобы он соответствовал приложению — а не наоборот.

Позиция по умолчанию — “минимизировать изменения в вашем коде.” Если ваше приложение уже читает DATABASE_URL, агент сопоставляет это с WithEnvironment() вместо того, чтобы просить вас переписать конфигурацию. Если порт жёстко задан, навык указывает агенту, когда его сохранить.

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

Первоклассное развёртывание Kubernetes и AKS

Это было в списке пожеланий уже давно. Aspire 13.3 поставляется с первоклассной поддержкой развёртывания Kubernetes и AKS с Helm. Теперь вы можете указывать AKS в качестве целевого объекта развёртывания прямо из инструментов Aspire.

Для команд, которые уже запускают производственные нагрузки на AKS, это закрывает значительный пробел. Ваша модель приложения Aspire теперь имеет чёткий путь от локальной разработки до Kubernetes без ручного создания Helm-чартов.

Журналы браузера в дашборде

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

Новый API WithBrowserLogs() прикрепляет отслеживаемый ресурс браузера к любому ресурсу, поддерживающему endpoint’ы. Aspire запускает Chromium с использованием приватного CDP-пайпа и передаёт журналы консоли, сетевые запросы и ошибки прямо в поток журналов ресурса:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost поддерживает то же самое:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Ошибки консоли, неудавшиеся сетевые запросы, исключения на стороне клиента — всё видно в том же дашборде, где вы уже следите за трассировками и метриками. Больше не нужно переключаться на DevTools браузера для базовых вещей.

Структурированные результаты команд

Команды ресурсов получили значительное обновление. До сих пор команды возвращали успех/неудачу. Теперь они возвращают структурированные результаты: текст, JSON или markdown, который проходит через модель, интерфейс дашборда, CLI и MCP-инструменты.

Дашборд связывает всё это с новым центром уведомлений в заголовке. Результаты команд отображаются как уведомления с временными метками с рендерингом markdown и действием “Просмотреть ответ”.

Это делает команды ресурсов по-настоящему компонуемыми. Интеграция теперь может предоставлять команду, которая возвращает значимый вывод — например, URL туннеля — вместо того, чтобы просто изменять состояние где-то.

Итог

Aspire 13.3 стоит обновления хотя бы ради поддержки Kubernetes. Журналы браузера и структурированные результаты команд — это тип улучшений качества жизни, которые быстро накапливаются в повседневном рабочем процессе разработки.

Полные заметки о выпуске: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 проходит с 11 по 15 мая 2026 года в Barbican Centre в Лондоне. Основная 3-дневная конференция — со вторника по четверг, с опциональными однодневными воркшопами в понедельник и пятницу.

С 78 сессиями и 14 воркшопами это одна из самых насыщенных конференций для разработчиков в Европе.

Темы

Архитектурное мышление
Функциональный код на C# 13
Serverless-дизайн
Семантический ИИ
Azure Kubernetes Services
Lean DevOps стратегии
Протокол контекста модели (MCP)
Агентный ИИ в .NET
Рефакторинг монолита
Быстрее программировать с LLM
Криптография в постквантовом мире
Local-First разработка

Спикеры

Программу мирового класса представляют Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm и Raju Gandhi.

Билеты и информация

98% участников SDD 2025 оценили общее впечатление как хорошее, очень хорошее или отличное.

SQL MCP Server на Azure App Service — без контейнеров

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

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

Именно поэтому это привлекло моё внимание. SQL MCP Server теперь может работать на Azure App Service — без Docker, без Kubernetes, только с тем же конфигурационным файлом Data API Builder (DAB), который открывает ваш SQL-датабаз через MCP, REST и GraphQL.

Что такое SQL MCP Server?

Кратко для тех, кто ещё не знаком. SQL MCP Server располагается между вашим AI-агентом и SQL-базой данных. Вместо того чтобы давать агенту прямой доступ к базе данных (ужасная идея), он открывает ваши таблицы и представления как уровень абстракции — сущности с определёнными правами доступа.

Построен на Data API Builder, что означает: один конфигурационный файл управляет MCP и REST и GraphQL одновременно. Ваш агент общается с MCP-эндпоинтом. Традиционное приложение общается с REST или GraphQL. Одна конфигурация, одна среда выполнения, разные интерфейсы.

Это действительно удобно. Не нужно поддерживать два отдельных API-слоя.

Проблема контейнеров (и её решение)

Изначальная модель развёртывания SQL MCP Server использовала контейнеры. Это хорошо работает во многих командах — но не во всех. Многие .NET-команды стандартизировались на Azure App Service или виртуальных машинах. Требовать контейнерный runtime только ради одного SQL-эндпоинта — это лишнее трение, которого никто не просил.

Новое руководство показывает, как обойтись без контейнера вовсе. Всё работает через команду dab start, запущенный как стандартный .NET 8 веб-процесс на App Service.

# Установка Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Инициализация конфигурации
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Добавление сущности
dab add products --source dbo.products --permissions "authenticated:*"

# Настройка провайдера аутентификации App Service
dab configure --runtime.host.authentication.provider AppService

# Запуск сервера
dab start

На этом этапе у вас есть MCP по адресу /mcp, REST и GraphQL из того же процесса — и ничего в контейнере.

Аутентификация без общих API-ключей

Это та часть, которую я ценю больше всего. При развёртывании на App Service вы настраиваете Microsoft Entra ID в качестве провайдера аутентификации. Никаких общих секретов в конфигурационных файлах, никаких API-ключей для ротации.

Строка подключения хранится в переменных среды App Service (не в dab-config.json), а MCP-эндпоинт защищён платформенной аутентификацией. Если ваши Azure-нагрузки уже используют Entra ID, интеграция происходит органично.

Для локальной разработки переключайтесь в режим Simulator и STDIO-транспорт. Возвращайтесь к режиму AppService перед развёртыванием. Чисто и явно.

Развёртывание на App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Затем разверните свой DAB-проект методом, который уже использует ваша команда. Ключевой момент: это развёртывание кода, а не контейнера.

Почему это важно для .NET-разработчиков

Если вы создаёте AI-агентов на .NET, рано или поздно им нужно будет работать с базой данных. SQL MCP Server предоставляет структурированный способ сделать это — без открытия сырых строк подключения или написания собственных API-слоёв.

Ознакомьтесь с полным руководством в оригинальной статье и примере на GitHub.

Итог

SQL MCP Server на App Service — практичный выбор для .NET-команд, которые хотят дать агентам структурированный доступ к SQL-данным без контейнерной стратегии. Попробуйте — ваши агенты оценят чистый API-интерфейс.

Устранение Рутинной Работы Миграции с Помощью Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

Removing the Monkey Work of Migration with Agentic Platform Engineering — руководство по Git-Ape (инструменту git для агентной инженерии платформ), который мигрирует реальный репозиторий AWS Terraform в Azure, фокусируясь на извлечении намерения вместо построчного преобразования.

Входные данные: contoso-migration

Источником является реальный проект Terraform (contoso-migration), который разворачивает приложение Next.js на AWS — EC2 для вычислений, ALB для балансировки нагрузки, S3 для артефактов и ключи IAM для идентификации. Стоимость: ~34 $/месяц. Цель — не воспроизвести ту же инфраструктуру в Azure; речь идёт о том, чтобы понять, что развёртывание действительно пытается сделать, и воссоздать это с помощью нативных сервисов Azure.

Шаг 1: Валидация и аутентификация

Git-Ape начинает с проверки всех необходимых инструментов CLI — az, aws, gh, jq, git — и подтверждения активных сеансов аутентификации перед тем, как что-либо трогать. Никаких частичных запусков.

Шаг 2: Извлечение намерения

Агент читает весь исходный репозиторий через API GitHub и извлекает намерение развёртывания: среда выполнения (Node.js), тип вычислений, шаблон ingress, обработка артефактов, модель идентификации, сеть и мониторинг. Это ключевой шаг — строится семантическая модель того, что делает развёртывание, а не какие ключевые слова Terraform оно использует.

Шаг 3: Сопоставление сервисов

Сервисы AWS сопоставляются с эквивалентами Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Встроенная балансировка нагрузки App Service
Роли/ключи IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Шаг 4: Агент-критик

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

Антипаттерн сборки при запуске — исходный Terraform запускал npm install && npm run build на EC2 при старте. Исправление: собирать в CI, разворачивать готовый артефакт.
Ненужный Blob Storage — S3 использовался для промежуточного хранения артефактов, что можно устранить при правильном CI/CD. Агент-критик полностью удалил его.

Шаг 5: Сгенерированный вывод

Результатом являются ~80 строк Bicep вместо оригинальных 200+ строк Terraform. Агент создал новый репозиторий GitHub с infra/main.bicep и .github/workflows/deploy.yml и удалил все файлы, специфичные для AWS.

Сравнение уровня безопасности

Миграция также принесла значительное улучшение безопасности:

AWS оригинал	Вывод Azure
Только HTTP	Только HTTPS, TLS 1.2
SSH открыт для 0.0.0.0/0	Нет SSH-экспозиции
Ключи доступа IAM	OIDC + Managed Identity
Нет мониторинга	Application Insights

Стоимость: ~13 $/месяц против первоначальных 34 $/месяц.

Чем это отличается от конвертора синтаксиса

Шаг агента-критика — вот что отличает это от механического перевода. Он обнаружил паттерны, которые работали бы на AWS, но были бы неверны на Azure — и исправил их вместо того, чтобы воспроизводить. Вывод — это не «AWS в синтаксисе Azure»; это нативное для Azure развёртывание, которое достигает той же цели более чисто.

Смотрите полное руководство для полной трассировки агента и сгенерированных файлов.

SQL Server 2025 как База Данных для Агентов: Безопасность, Бэкап и MCP в Одном Движке

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

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

Я следил за серией Polyglot Tax Адитьи Бадрамраджу с большим интересом. Часть 4 завершает серию частями, которые реально определяют, доверяли бы вы этой архитектуре в продакшне.

Одна Модель Безопасности для Всех Моделей Данных

Одна политика Row-Level Security покрывает все таблицы — реляционные, JSON, граф, векторы. Одна политика, одно доказательство для аудитора.

Единый Бэкап = Атомарное Восстановление

В полиглотном стеке point-in-time recovery через пять баз данных — это кошмар согласованности. С одной базой данных восстановление атомарно по определению.

MCP-Интеграция: Агенты Без Middleware

SQL Server 2025 напрямую поддерживает SQL MCP Server. Агенты вызывают инструменты, движок автоматически обеспечивает изоляцию тенантов и маскировку столбцов.

Оригинальный пост Адитьи Бадрамраджу: The Polyglot Tax – Part 4.

Azure MCP Server Теперь .mcpb — Установка без Какого-либо Runtime

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Знаете, что раздражало в настройке MCP-серверов? Нужен был runtime. Node.js для npm-версии, Python для pip/uvx, .NET SDK для dotnet-варианта.

Azure MCP Server только что изменил это. Теперь он доступен как .mcpb — MCP Bundle — и настройка выполняется перетаскиванием.

Что такое MCP Bundle?

Думайте о нём как о расширении VS Code (.vsix) или расширении браузера (.crx), но для MCP-серверов. Файл .mcpb — это автономный ZIP-архив с бинарным файлом сервера и всеми его зависимостями.

Как установить

1. Скачайте bundle для вашей платформы

Перейдите на страницу GitHub Releases и скачайте файл .mcpb для вашей ОС и архитектуры.

2. Установите в Claude Desktop

Самый простой способ: перетащите файл .mcpb в окно Claude Desktop на странице настроек расширений (☰ → Файл → Настройки → Расширения). Проверьте детали сервера, нажмите «Установить», подтвердите.

3. Аутентифицируйтесь в Azure

az login

Всё. Azure MCP Server использует ваши существующие учётные данные Azure.

Что можно делать

Доступ к 100+ инструментам сервисов Azure прямо из вашего ИИ-клиента:

Запрашивать и управлять Cosmos DB, Storage, Key Vault, App Service, Foundry
Генерировать команды az CLI для любых задач
Создавать шаблоны Bicep и Terraform

С чего начать

Загрузка: GitHub Releases
Репозиторий: aka.ms/azmcp
Документация: aka.ms/azmcp/docs

Смотрите полный пост.

Azure SDK Апрель 2026: AI Foundry 2.0 и Что Должны Знать .NET-Разработчики

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Ежемесячные SDK-релизы часто легко пропустить. В этом есть несколько вещей, заслуживающих внимания.

Azure.AI.Projects 2.0.0 — Ломающие Изменения, Которые Имеют Смысл

Разделение пространств имён, переименование типов, последовательное соглашение Is* для булевых свойств.

Cosmos DB Java: Критическое Исправление Безопасности (RCE)

Версия 4.79.0 исправляет уязвимость удалённого выполнения кода (CWE-502). Обновитесь немедленно.

Новые Provisioning-Библиотеки для .NET

Оригинальный пост: Azure SDK Release (April 2026).

GPT-5.5 Уже Здесь и Приходит в Azure Foundry — Что Нужно Знать .NET-разработчикам

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Microsoft только что объявила, что GPT-5.5 доступен в Microsoft Foundry. Если вы создаёте агентов на Azure, это обновление, которого вы ждали.

Эволюция GPT-5

GPT-5: объединил рассуждение и скорость в единую систему
GPT-5.4: более мощное многошаговое рассуждение, ранние агентские возможности для enterprise
GPT-5.5: более глубокое рассуждение в длинном контексте, более надёжное агентское выполнение, лучшая эффективность токенов

Что реально изменилось

Улучшенное агентное кодирование: GPT-5.5 удерживает контекст на больших кодовых базах, диагностирует архитектурные сбои и предвидит требования к тестированию. Модель рассуждает о том, на что ещё влияет исправление, прежде чем действовать.

Эффективность токенов: Выходные данные более высокого качества с меньшим количеством токенов и меньшим числом повторных попыток. Непосредственно снижает стоимость и задержку в производстве.

Цены

Модель	Входные данные ($/M токенов)	Кэшированный ввод	Выходные данные ($/M токенов)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Почему важен Foundry

Foundry Agent Service позволяет определять агентов в YAML или подключать их с Microsoft Agent Framework, GitHub Copilot SDK, LangGraph или OpenAI Agents SDK — и запускать их как изолированных хостированных агентов с постоянной файловой системой, идентичностью Microsoft Entra и тарификацией по принципу scale-to-zero.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Вы полезный помощник.", name: "МойАгент");

Смотрите полное объявление для всех подробностей.

Foundry Toolboxes: Единый эндпоинт для всех инструментов агентов

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

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

Microsoft Foundry только что выпустила Toolboxes в Public Preview — прямой ответ на эту проблему.

Что такое Toolbox?

Toolbox — это именованный, многократно используемый набор инструментов, который определяется один раз в Foundry и предоставляется через единый MCP-совместимый эндпоинт. Любая среда выполнения агента, говорящая на MCP, может его потреблять — никакой привязки к Foundry Agents.

Обещание простое: build once, consume anywhere. Определить инструменты, настроить аутентификацию централизованно (OAuth passthrough, управляемые удостоверения Entra), опубликовать эндпоинт. Каждый агент, которому нужны эти инструменты, подключается к эндпоинту и получает их все.

Четыре столпа (два доступны сегодня)

Столп	Статус	Что делает
Discover	Скоро	Находить одобренные инструменты без ручного поиска
Build	Доступен	Собирать инструменты в многократно используемый bundle
Consume	Доступен	Единый MCP-эндпоинт предоставляет все инструменты
Govern	Скоро	Централизованная аутентификация + observability для всех вызовов

Практический пример

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Поиск по документации и ответы на GitHub-issues.",
 tools=[
 {"type": "web_search", "description": "Поиск в публичной документации"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

После публикации Foundry предоставляет единый эндпоинт. Одно подключение — все инструменты.

Нет привязки к Foundry Agents

Toolboxes создаются и управляются в Foundry, но поверхность потребления — открытый протокол MCP. Их можно использовать из кастомных агентов (Microsoft Agent Framework, LangGraph), GitHub Copilot и других MCP-совместимых IDE.

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

Волна мульти-агентов добирается до продакшена. Каждый новый агент — это новая поверхность для дублированной конфигурации, устаревших учётных данных и непоследовательного поведения. Основа Build + Consume достаточна, чтобы начать централизацию. Когда придёт столп Govern, появится полностью наблюдаемый, централизованно управляемый инструментальный слой для всего парка агентов.

Итог

Пока рано — Public Preview, сначала Python SDK, Discover и Govern ещё впереди. Но модель надёжная, а MCP-нативный дизайн означает, что она работает с инструментами, которые уже строятся. Подробности в официальном анонсе.

azd + GitHub Copilot: настройка проекта с помощью ИИ и умное исправление ошибок

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Эта статья переведена автоматически. Оригинальную версию на английском можно найти здесь.

Знаком ли вам момент, когда хочешь задеплоить существующее приложение в Azure и смотришь на пустой azure.yaml, пытаясь вспомнить, какой тип хостинга выбрать для Express API — Container Apps или App Service? Этот момент станет намного короче.

Azure Developer CLI (azd) теперь интегрируется с GitHub Copilot двумя практичными способами: AI-ассистированный скаффолдинг проекта при azd init и интеллектуальное устранение ошибок при сбое деплоя. Обе функции работают полностью в терминале — именно там, где они и должны быть.

Настройка с Copilot при azd init

При запуске azd init теперь появляется опция “Set up with GitHub Copilot (Preview)”. Выберите её, и Copilot проанализирует вашу кодовую базу, чтобы сгенерировать azure.yaml, шаблоны инфраструктуры и Bicep-модули — на основе вашего реального кода.

azd init
# Выберите: "Set up with GitHub Copilot (Preview)"

Что потребуется:

azd 1.23.11 или новее — проверьте azd version или обновитесь через azd update
Активная подписка GitHub Copilot (Individual, Business или Enterprise)
GitHub CLI (gh) — azd запросит вход при необходимости

Что мне по-настоящему нравится: это работает в обоих направлениях. Строите с нуля? Copilot поможет настроить правильные сервисы Azure с самого начала. Есть существующее приложение, которое давно хотели задеплоить? Направьте на него Copilot — конфигурация будет сгенерирована без необходимости что-либо переструктурировать.

Что происходит на самом деле

Допустим, у вас есть Node.js Express API с зависимостью от PostgreSQL. Вместо того чтобы вручную выбирать между Container Apps и App Service, а затем писать Bicep с нуля, Copilot определит стек и сгенерирует:

azure.yaml с правильными настройками language, host и build
Bicep-модуль для Azure Container Apps
Bicep-модуль для Azure Database for PostgreSQL

Перед любыми изменениями выполняются предварительные проверки — убеждается в чистоте рабочей директории git, заранее запрашивает согласие на инструменты MCP-сервера. Ничего не произойдёт без вашего понимания того, что именно изменится.

Устранение ошибок с помощью Copilot

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

Без Copilot цикл выглядит так: скопировать ошибку → искать в документации → читать три нерелевантных ответа на Stack Overflow → выполнить команды az CLI → попробовать снова. С Copilot в azd этот цикл рушится. При любом сбое команды azd сразу предлагаются четыре варианта:

Explain — простое объяснение того, что пошло не так
Guidance — пошаговые инструкции по исправлению
Diagnose and Guide — полный анализ + Copilot применяет исправление (с вашего одобрения) + опциональный повтор
Skip — разобраться самостоятельно

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

Настройка поведения по умолчанию

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

azd config set copilot.errorHandling.category troubleshoot

Значения: explain, guidance, troubleshoot, fix, skip. Можно включить автоматическое исправление и повтор:

azd config set copilot.errorHandling.fix allow

Вернуться к интерактивному режиму в любой момент:

azd config unset copilot.errorHandling.category

Итоги

Запустите azd update для получения последней версии и попробуйте azd init на следующем проекте. Это именно та интеграция Copilot, которая приносит реальную ценность.

Читайте оригинальное объявление здесь.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 проходит 18 апреля 2026 года в Kinépolis Diversia в Алькобендасе, Мадрид. Это крупнейшее сообщественное Azure-мероприятие в Испании, объединяющее 38 спикеров на 3 параллельных треках: ИИ-агенты, сети Azure, Cosmos DB, Fabric, IoT, безопасность и многое другое.

Мероприятие проходит с 08:30 до 18:30 и включает в себя кейноут, кофе-брейки, обед и заключительную сессию вопросов и ответов.

Основные моменты программы

Domando Agentes de IA: управление, инструменты и API с Azure AI Foundry и Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: мультиагентные системы в действии
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Билеты

Регистрация — символическое пожертвование. Вся стоимость билета направляется в Plan International на поддержку прав детей и равенства по всему миру. Количество мест ограничено, поэтому бронируйте заранее.

Azure Tour 2026

Помимо Мадрида, Global Azure Tour 2026 также проходит в Сарагосе, Тенерифе и Севилье.

RFT в Foundry стал дешевле и умнее — Вот что изменилось

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

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

Если вы разрабатываете .NET-приложения, которые зависят от дообученных моделей, обновления Foundry этого месяца заслуживают внимания. Reinforcement Fine-Tuning стал более доступным и значительно дешевле.

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

Глобальное обучение для o4-mini

o4-mini — это основная модель для задач, требующих рассуждений, и агентных нагрузок. Главная новость: теперь вы можете запускать задачи файнтюнинга из 13+ регионов Azure с более низкими тарифами за токен по сравнению со Standard-обучением. Та же инфраструктура, то же качество, более широкий охват.

Если ваша команда распределена по разным географиям, это важно. Вы больше не привязаны к нескольким регионам для обучения.

Вот REST API вызов для запуска глобальной задачи обучения:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Флаг trainingType: globalstandard — это ключевое отличие.

Новые модельные грейдеры: семейство GPT-4.1

Грейдеры определяют сигнал вознаграждения, под который оптимизируется ваша модель. До сих пор модельные грейдеры были ограничены небольшим набором моделей. Теперь у вас есть три новых варианта: GPT-4.1, GPT-4.1-mini и GPT-4.1-nano.

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

Суть в том, что стратегия уровней практична:

GPT-4.1-nano для начальных итераций. Низкая стоимость, быстрые циклы обратной связи.
GPT-4.1-mini когда ваша рубрика оценки стабильна и нужна более высокая точность.
GPT-4.1 для продакшен-оценки или сложных рубрик, где важно каждое решение по оценке.

Вы даже можете комбинировать типы грейдеров в одной задаче RFT. Используйте string-match для измерения «правильный ответ» и модельный грейдер для оценки качества рассуждений. Честно говоря, именно эта гибкость делает его полезным для реальных нагрузок.

Подводный камень формата данных RFT

На этом многие спотыкаются. Формат данных RFT отличается от SFT. Последнее сообщение в каждой строке должно иметь роль User или Developer — не Assistant. Ожидаемый ответ помещается в ключ верхнего уровня, например reference_answer, на который грейдер ссылается напрямую.

Если вы занимались supervised fine-tuning и хотите перейти на RFT, вам нужно перестроить обучающие данные. Не пропускайте этот шаг, иначе ваши задачи будут молча завершаться с ошибкой.

Почему это важно для .NET-разработчиков

Если вы вызываете дообученные модели из .NET-приложений через Azure OpenAI SDK, более дешёвое обучение означает, что вы можете итерировать более агрессивно. Варианты модельных грейдеров означают, что вы можете файнтюнить для нюансированных задач — не только для сценариев точного совпадения. А руководство по лучшим практикам на GitHub сэкономит вам реальное время отладки.

Начните с малого. От десяти до ста примеров. Простой грейдер. Проверьте цикл. Затем масштабируйте.

Ваши AI-эксперименты в Azure сжигают деньги — Вот как это исправить

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

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

Если вы сейчас создаёте приложения на базе ИИ в Azure, вы, вероятно, заметили кое-что: ваш счёт за облако выглядит иначе, чем раньше. Не просто выше — странно. Скачкообразно. Трудно предсказать.

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

Почему AI-нагрузки — это другая история

Вот в чём дело. Традиционные .NET-нагрузки относительно предсказуемы. Вы знаете свой уровень App Service, знаете свои SQL DTU, можете довольно точно оценить ежемесячные расходы. AI-нагрузки? Не совсем.

Вы тестируете несколько моделей, чтобы понять, какая подходит. Вы поднимаете инфраструктуру с GPU для дообучения. Вы делаете API-вызовы к Azure OpenAI, где потребление токенов сильно варьируется в зависимости от длины промпта и поведения пользователей. Каждый эксперимент стоит реальных денег, и вы можете провести десятки, прежде чем найдёте правильный подход.

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

Управление vs. оптимизация — знайте разницу

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

Управление — это отслеживание и отчётность. Вы настраиваете бюджеты в Azure Cost Management, получаете оповещения, смотрите дашборды. Это базовый минимум.

Оптимизация — это когда вы действительно принимаете решения. Вам правда нужен этот уровень S3, или S1 справится с вашей нагрузкой? Та постоянно работающая вычислительная инстанция простаивает по выходным? Можно ли использовать спот-инстансы для задач обучения?

Как .NET-разработчики, мы склонны сосредотачиваться на коде и оставлять решения по инфраструктуре «команде эксплуатации». Но если вы деплоите в Azure, эти решения — тоже ваши решения.

Что действительно работает

Основываясь на статье и собственном опыте, вот что реально даёт результат:

Знайте, на что и где вы тратите. Тегируйте свои ресурсы. Серьёзно. Если вы не можете определить, какой проект или эксперимент поедает ваш бюджет, вы не сможете ничего оптимизировать. Azure Cost Management с правильным тегированием — ваш лучший друг.

Установите ограничения перед экспериментами. Используйте Azure Policy для ограничения дорогих SKU в средах dev/test. Установите лимиты расходов на ваши развёртывания Azure OpenAI. Не ждите, пока придёт счёт, чтобы обнаружить, что кто-то оставил GPU-кластер работать на выходных.

Постоянно подбирайте правильный размер. Та VM, которую вы выбрали при прототипировании? Она, вероятно, не подходит для продакшена. Azure Advisor даёт рекомендации — реально посмотрите на них. Пересматривайте ежемесячно, а не ежегодно.

Думайте о жизненном цикле. Ресурсы разработки должны выключаться. Тестовые среды не должны работать 24/7. Используйте политики автоматического выключения. Для AI-нагрузок в частности рассмотрите бессерверные варианты, где вы платите за выполнение, вместо того чтобы держать вычислительные мощности включёнными.

Измеряйте ценность, а не только стоимость. Об этом легко забыть. Модель, которая стоит дороже, но даёт значительно лучшие результаты, может быть правильным выбором. Цель — не тратить меньше всего, а тратить разумно.

Итог

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

Если вы .NET-разработчик, создающий решения на Azure, начните относиться к своему облачному счёту так же, как к своему коду — регулярно ревьюйте, рефакторите, когда становится беспорядочно, и никогда не деплойте, не понимая, во сколько это обойдётся.

Инструменты Azure MCP теперь встроены в Visual Studio 2022 — Расширение не требуется

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

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

Если вы использовали инструменты Azure MCP в Visual Studio через отдельное расширение, вы знаете этот ритуал — установить VSIX, перезапустить, надеяться, что ничего не сломается, разбираться с несовместимостью версий. Это трение осталось в прошлом.

Yun Jung Choi объявила, что инструменты Azure MCP теперь поставляются непосредственно в составе рабочей нагрузки разработки Azure в Visual Studio 2022. Без расширения. Без VSIX. Без танцев с перезапуском.

Что это означает на практике

Начиная с Visual Studio 2022 версии 17.14.30, Azure MCP Server включён в рабочую нагрузку разработки Azure. Если эта рабочая нагрузка уже установлена, достаточно включить его в GitHub Copilot Chat — и всё готово.

Более 230 инструментов для 45 сервисов Azure — доступны прямо из окна чата. Просмотр учётных записей хранилища, развёртывание приложения ASP.NET Core, диагностика проблем App Service, запросы к Log Analytics — всё это без открытия вкладки браузера.

Почему это важнее, чем кажется

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

Единый путь обновления через Visual Studio Installer
Никакого расхождения версий между расширением и IDE
Всегда актуально — MCP Server обновляется с регулярными релизами VS

Для команд, стандартизирующих на Azure, это очень важно. Устанавливаете рабочую нагрузку один раз, включаете инструменты, и они доступны в каждой сессии.

Что можно делать с помощью этих инструментов

Инструменты охватывают полный жизненный цикл разработки через Copilot Chat:

Изучать — спрашивайте о сервисах Azure, лучших практиках, архитектурных паттернах
Проектировать и разрабатывать — получайте рекомендации по сервисам, настраивайте код приложения
Развёртывать — выделяйте ресурсы и развёртывайте прямо из IDE
Устранять неполадки — запрашивайте логи, проверяйте состояние ресурсов, диагностируйте проблемы в продакшене

Быстрый пример — введите это в Copilot Chat:

List my storage accounts in my current subscription.

Copilot вызывает инструменты Azure MCP за кулисами, запрашивает ваши подписки и возвращает отформатированный список с именами, расположениями и SKU. Портал не нужен.

Как включить

Обновите Visual Studio 2022 до версии 17.14.30 или выше
Убедитесь, что установлена рабочая нагрузка Azure development
Откройте GitHub Copilot Chat
Нажмите кнопку Select tools (значок с двумя гаечными ключами)
Включите Azure MCP Server

Вот и всё. Настройка сохраняется между сессиями.

Одно замечание

Инструменты отключены по умолчанию — нужно включить их вручную. И инструменты, специфичные для VS 2026, недоступны в VS 2022. Доступность инструментов также зависит от разрешений вашей подписки Azure, как и в портале.

Общая картина

Это часть чёткого тренда: MCP становится стандартным способом предоставления облачных инструментов в IDE для разработчиков. Мы уже видели стабильный релиз Azure MCP Server 2.0 и интеграции MCP в VS Code и других редакторах. Встраивание в систему рабочих нагрузок Visual Studio — естественное развитие.

Для нас, .NET-разработчиков, которые живут в Visual Studio, это устраняет ещё одну причину переключаться на портал Azure. И честно говоря, чем меньше переключений между вкладками, тем лучше.

Aspire 13.2 получает MongoDB EF Core и Azure Data Lake — Две интеграции, которые стоит попробовать

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Aspire 13.2 вышел с двумя новыми интеграциями баз данных, которые заслуживают внимания: MongoDB Entity Framework Core и Azure Data Lake Storage. Если вы хотели использовать EF Core с MongoDB в приложении Aspire или вам нужно было подключить рабочие нагрузки Data Lake с обнаружением сервисов, этот релиз предоставляет и то, и другое.

MongoDB встречает EF Core в Aspire

Это интеграция, которая радует меня больше всего. Aspire поддерживал MongoDB уже давно, но это всегда был сырой драйвер — никакого EF Core, никакого DbContext, никаких LINQ-запросов к документам. Теперь вы получаете полноценный EF Core с MongoDB, плюс автоматические проверки работоспособности и обнаружение сервисов от Aspire.

Настройка следует типичному паттерну Aspire. В вашем AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Затем в потребляющем проекте добавьте интеграцию EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

И зарегистрируйте свой DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Дальше — стандартный EF Core. Определяйте сущности, используйте DbContext как с любым другим провайдером. Интеграция берёт на себя пул соединений, трассировки OpenTelemetry и проверки работоспособности за кулисами.

Для .NET-разработчиков, которые использовали MongoDB с сырым драйвером и вручную настраивали строки подключения, это приятное улучшение качества жизни. Вы получаете полную абстракцию EF Core, не теряя обнаружение сервисов Aspire.

Azure Data Lake Storage присоединяется

Второе крупное дополнение — интеграция Azure Data Lake Storage (ADLS). Если вы строите конвейеры данных, ETL-процессы или аналитические платформы, теперь можно подключать ресурсы Data Lake так же, как любую другую зависимость Aspire.

В AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

В потребляющем проекте:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Никакого ручного управления строками подключения, никакой охоты за учётными данными. Aspire выделяет ресурсы и внедряет их. Для тех из нас, кто строит облачно-нативные .NET-приложения, работающие как с операционными данными, так и с аналитическими нагрузками, Data Lake теперь ощущается как полноценный участник модели Aspire.

Маленькие исправления, которые важны

Помимо основных функций, есть несколько улучшений, которые стоит отметить:

Исправление строки подключения MongoDB — косая черта перед именем базы данных теперь обрабатывается корректно. Если у вас был обходной путь, можете его убрать
Экспорт SQL Server — Aspire.Hosting.SqlServer теперь экспортирует дополнительные параметры конфигурации сервера для более тонкого контроля
Обновления эмуляторов — эмулятор ServiceBus 2.0.0, эмулятор App Configuration 1.0.2, предварительный эмулятор CosmosDB теперь включает проверку готовности
Azure Managed Redis — теперь по умолчанию использует rediss:// (Redis Secure), так что соединения шифруются из коробки

Последний пункт тонкий, но важный — шифрованный Redis по умолчанию означает на одну настройку меньше в продакшене.

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

Aspire 13.2 — инкрементальный релиз, но интеграции MongoDB EF Core и Data Lake заполняют реальные пробелы. Если вы ждали нормальную поддержку EF Core для MongoDB в Aspire или вам нужен Data Lake как полноценная зависимость, обновитесь до 13.2 и попробуйте. Команда aspire add создаст всё необходимое.

Читайте полные примечания к релизу для подробностей и загляните в галерею интеграций для полного списка.

azd update — Одна команда для всех ваших пакетных менеджеров

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Знаете это сообщение «Доступна новая версия azd», которое появляется каждые несколько недель? То самое, которое вы закрываете, потому что не помните, устанавливали ли вы azd через winget, Homebrew или тот curl-скрипт, который запустили полгода назад? Так вот, это наконец-то исправлено.

Microsoft выпустила azd update — единую команду, которая обновляет Azure Developer CLI до последней версии независимо от того, как вы её изначально установили. Windows, macOS, Linux — неважно. Одна команда.

Как это работает

azd update

Вот и всё. Если хотите ранний доступ к новым возможностям, можно переключиться на ежедневную Insiders-сборку:

azd update --channel daily
azd update --channel stable

Команда определяет текущий метод установки и использует подходящий механизм обновления под капотом. Больше никаких «подожди, я на этой машине winget или choco использовал?»

Небольшой нюанс

azd update доступна начиная с версии 1.23.x. Если у вас более старая версия, придётся выполнить последнее ручное обновление через исходный метод установки. После этого azd update берёт всё на себя.

Проверьте текущую версию командой azd version. Если нужна чистая установка, документация по установке вам поможет.

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

Это небольшое улучшение качества жизни, но для тех из нас, кто ежедневно использует azd для деплоя ИИ-агентов и Aspire-приложений в Azure, быть на последней версии означает меньше моментов «этот баг уже был исправлен в последнем релизе». На одну заботу меньше.

Читайте полный анонс и подробный разбор Джона Галланта для дополнительного контекста.

Azure Smart Tier вышел в GA — Автоматическая оптимизация стоимости Blob Storage без правил жизненного цикла

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Если вы когда-нибудь тратили время на настройку политик жизненного цикла Azure Blob Storage, а потом наблюдали, как они разваливаются при изменении паттернов доступа, эта статья для вас. Microsoft только что объявил о общей доступности smart tier для Azure Blob и Data Lake Storage — полностью управляемой возможности тиеринга, которая автоматически перемещает объекты между уровнями hot, cool и cold на основе реального использования.

Что на самом деле делает smart tier

Концепция проста: smart tier непрерывно оценивает время последнего доступа к каждому объекту в вашем аккаунте хранения. Часто используемые данные остаются в hot, неактивные данные перемещаются в cool через 30 дней, а затем в cold ещё через 60 дней. Когда к данным снова обращаются, они немедленно возвращаются в hot. Цикл начинается заново.

Никаких правил жизненного цикла для настройки. Никаких прогнозов паттернов доступа. Никакой ручной настройки.

Во время превью Microsoft сообщил, что более 50% ёмкости, управляемой smart tier, автоматически переместилось на более холодные уровни на основе реальных паттернов доступа. Это существенная экономия для крупных аккаунтов хранения.

Почему это важно для .NET-разработчиков

Если вы создаёте приложения, генерирующие логи, телеметрию, аналитические данные или любой растущий массив данных — а давайте будем честны, кто этого не делает? — затраты на хранение быстро накапливаются. Традиционный подход заключался в написании политик управления жизненным циклом, их тестировании, а затем перенастройке при изменении паттернов доступа вашего приложения. Smart tier полностью устраняет этот рабочий процесс.

Несколько практических сценариев, где это помогает:

Телеметрия и логи приложений — hot при отладке, почти не используются через несколько недель
Конвейеры данных и выходные данные ETL — интенсивно используются во время обработки, затем в основном cold
Контент, создаваемый пользователями — недавние загрузки hot, старый контент постепенно остывает
Данные резервного копирования и архивирования — иногда используются для соответствия требованиям, в основном простаивают

Настройка

Включение smart tier — это однократная настройка:

Новые аккаунты: Выберите smart tier как уровень доступа по умолчанию при создании аккаунта хранения (требуется зональная избыточность)
Существующие аккаунты: Переключите уровень доступа blob с текущего значения по умолчанию на smart tier

Объекты размером менее 128 КиБ остаются в hot и не облагаются платой за мониторинг. Для всего остального вы платите стандартные тарифы hot/cool/cold без платы за переход между уровнями, без штрафов за раннее удаление и без стоимости извлечения данных. Ежемесячная плата за мониторинг на объект покрывает оркестрацию.

Компромисс, о котором стоит знать

Правила тиеринга smart tier фиксированы (30 дней → cool, 90 дней → cold). Если вам нужны пользовательские пороги — например, перемещение в cool через 7 дней для конкретной рабочей нагрузки — правила жизненного цикла по-прежнему подходят лучше. И не смешивайте оба подхода: избегайте использования правил жизненного цикла для объектов, управляемых smart tier, так как они могут конфликтовать.

Заключение

Это не революция, но решает реальную операционную головную боль. Если вы управляете растущими аккаунтами blob storage и устали поддерживать политики жизненного цикла, включите smart tier и позвольте Azure заниматься этим. Доступно уже сегодня практически во всех зональных регионах публичного облака.

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

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Если вы сейчас создаёте 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 для сериализации сообщений. Платформа просто справляется.

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

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

Нужен нулевой уровень инфраструктуры? → Foundry Agents (портал/SDK, без контейнеров)
Есть пользовательский код агента, но нужен управляемый хостинг? → Foundry Hosted Agents
Нужны событийные краткосрочные задачи агентов? → Azure Functions
Нужен максимальный контроль контейнеров без K8s? → Container Apps
Нужен строгий комплаенс и мультикластер? → AKS
Простой 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 для рабочих примеров.

Agent Skills в .NET стали по-настоящему гибкими

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

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

Если вы строили агентов с Microsoft Agent Framework, вам знаком процесс: определяете навыки, подключаете их к provider и позволяете агенту решать, какой вызвать. Новое — это как вы создаёте эти навыки, и скачок в гибкости значительный.

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

Файловые навыки: отправная точка

Файловые навыки — это именно то, что звучит: директория на диске с файлом SKILL.md, опциональными скриптами и справочными документами. Самый прямой способ дать агенту новые возможности:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

Фронтматтер SKILL.md объявляет имя и описание навыка, а секция инструкций говорит агенту, как использовать скрипты и ссылки:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Затем подключаете SubprocessScriptRunner.RunAsync для выполнения скриптов:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Агент автоматически обнаруживает навык и вызывает скрипт провизионирования, когда нужно проверить статус аккаунтов. Чисто и просто.

Классовые навыки: распространяем через NuGet

Здесь для команд становится интересно. Классовые навыки наследуют от AgentClassSkill<T> и используют атрибуты [AgentSkillResource] и [AgentSkillScript], чтобы фреймворк обнаружил всё через рефлексию:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Красота в том, что команда может упаковать это как NuGet-пакет. Добавляете в проект, помещаете в builder, и оно работает рядом с файловыми навыками без координации:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Оба навыка появляются в системном промпте агента. Агент решает, какой использовать, на основе разговора — никакого кода маршрутизации.

Инлайн-навыки: быстрый мост

Знаете тот момент, когда другая команда строит именно тот навык, который вам нужен, но он будет готов только к следующему спринту? AgentInlineSkill — ваш мост:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Добавьте в builder так же, как и остальные:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Когда NuGet-пакет наконец выйдет, замените инлайн-навык на классовую версию. Агент не заметит разницы.

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

Одобрение скриптов: человек в цикле

Для нас, .NET-разработчиков, строящих продакшен-агентов, это та часть, которая по-настоящему разблокирует разговоры о деплое. Некоторые скрипты имеют реальные последствия — записать кого-то на бенефиты, запросить продакшен-инфраструктуру. Включите UseScriptApproval, и агент делает паузу перед выполнением любого скрипта:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Когда агент хочет выполнить скрипт, он возвращает запрос на одобрение. Ваше приложение собирает решение — одобрить или отклонить — и агент продолжает соответственно. В регулируемых средах это разница между «мы можем это задеплоить» и «юристы сказали нет».

Почему эта комбинация важна

Настоящая сила не в каком-то отдельном паттерне — а в композиции. Вы можете:

Начать с малого с файловым навыком, итерировать инструкции и опубликовать без написания C#
Распространять переиспользуемые навыки как NuGet-пакеты, которые другие команды добавляют одной строкой
Закрывать пробелы инлайн-навыками, когда что-то нужно прямо сейчас
Фильтровать общие директории предикатами, чтобы агент загружал только то, что нужно
Добавить человеческий контроль для скриптов, затрагивающих продакшен-системы

Всё это компонуется через AgentSkillsProviderBuilder. Никакой специальной маршрутизации, никакой условной логики, никаких проверок типа навыка.

Подводя итог

Agent skills в .NET теперь имеют по-настоящему гибкую модель создания. Будь вы соло-разработчик, прототипирующий с файловыми навыками, или корпоративная команда, распространяющая упакованные возможности через NuGet — паттерны подходят. А механизм одобрения скриптов делает решение готовым к продакшену в средах, где нужен человеческий чекпоинт.

Ознакомьтесь с оригинальным объявлением, документацией Agent Skills на Microsoft Learn и примерами .NET на GitHub, чтобы начать.

Azure MCP Server 2.0 выпущен — Self-Hosted Agentic Cloud Automation здесь

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

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

Если вы в последнее время создавали что-то с MCP и Azure, вы наверняка уже знаете, что локальный опыт работает хорошо. Подключите MCP сервер, позвольте вашему AI агенту общаться с ресурсами Azure, и двигайтесь дальше. Но в момент, когда нужно поделиться этой настройкой с командой? Вот тогда всё становится сложным.

Больше не нужно. Azure MCP Server только что достиг стабильности версии 2.0, и главная фишка — это ровно то, о чём просили enterprise команды: поддержка self-hosted удалённых MCP серверов.

Что такое Azure MCP Server?

Быстрое напоминание. Azure MCP Server реализует спецификацию Model Context Protocol и раскрывает возможности Azure в виде структурированных, обнаруживаемых инструментов, которые AI агенты могут вызывать. Думайте об этом как о стандартизированном мосте между вашим агентом и Azure — provisioning, развёртывание, мониторинг, диагностика, всё через один консистентный интерфейс.

Цифры говорят сами за себя: 276 MCP инструментов в 57 сервисах Azure. Это серьёзное покрытие.

Главное: self-hosted удалённые развёртывания

Вот в чём дело. Запуск MCP локально на вашей машине — это нормально для разработки и экспериментов. Но в реальном сценарии с командой вам нужно:

Общий доступ для разработчиков и внутренних систем агентов
Централизованная конфигурация (контекст тенанта, умолчания подписки, телеметрия)
Enterprise границы сети и политики
Интеграция в CI/CD pipelines

Azure MCP Server 2.0 решает все эти проблемы. Вы можете развернуть его как централизованно управляемый внутренний сервис с HTTP-транспортом, правильной аутентификацией и консистентным управлением.

Для аутентификации у вас есть два хороших варианта:

Managed Identity — при работе рядом с Microsoft Foundry
On-Behalf-Of (OBO) flow — OpenID Connect делегирование, которое вызывает Azure API, используя контекст вошедшего пользователя

Этот OBO flow особенно интересен для нас, .NET разработчиков. Это означает, что ваши agentic workflows могут работать с реальными разрешениями пользователя, а не с какой-то чрезмерно привилегированной сервисной учётной записью. Принцип наименьших привилегий, встроенный прямо туда.

Усиление безопасности

Это не просто выпуск фич — это ещё и выпуск безопасности. Релиз 2.0 добавляет:

Более сильную валидацию endpoints
Защиту от injection паттернов в инструментах, ориентированных на запросы
Более жёсткие элементы управления изоляцией для окружений разработки

Если вы собираетесь раскрывать MCP как общий сервис, эти меры защиты имеют большое значение. Большое.

Где вы можете его использовать?

История совместимости клиентов широкая. Azure MCP Server 2.0 работает с:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agents: GitHub Copilot CLI, Claude Code
Standalone: локальный сервер для простых настроек
Self-hosted remote: новая звезда версии 2.0

Плюс есть поддержка sovereign cloud для Azure US Government и Azure, управляемого 21Vianet, что критично для регулируемых развёртываний.

Почему это важно для .NET разработчиков

Если вы создаёте agentic приложения с .NET — будь то Semantic Kernel, Microsoft Agent Framework или ваша собственная оркестровка — Azure MCP Server 2.0 даёт вам production-ready способ дать вашим агентам взаимодействовать с инфраструктурой Azure. Нет пользовательских REST обёрток. Нет сервис-специфичных паттернов интеграции. Просто MCP.

Вместе с fluent API для MCP Apps, который вышел несколько дней назад, экосистема .NET MCP быстро растёт.

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

Выберите свой путь:

GitHub Repo — исходный код, документация, всё
Docker Image — контейнеризованное развёртывание
VS Code Extension — интеграция IDE
Self-hosting guide — главная фишка версии 2.0

В итоге

Azure MCP Server 2.0 — это ровно тот вид upgrade инфраструктуры, который не выглядит ослепительно на демо, но всё изменяет на практике. Self-hosted удалённый MCP с правильной аутентификацией, усилением безопасности и поддержкой sovereign cloud означает, что MCP готов для реальных команд, создающих реальные agentic workflows на Azure. Если вы ждали сигнала “enterprise-ready” — вот он.

Microsoft Foundry Март 2026 — GPT-5.4, Agent Service GA и Обновление SDK, Которое Меняет Всё

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

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

Ежемесячные посты «Что нового в Microsoft Foundry» обычно представляют собой сочетание инкрементальных улучшений и редких ключевых функций. Мартовский выпуск 2026 года? Практически сплошные ключевые функции. Foundry Agent Service выходит в GA, GPT-5.4 выпускается для продакшена, SDK получает крупный стабильный релиз, а Fireworks AI приносит инференс открытых моделей в Azure. Давайте разберём, что важно для .NET-разработчиков.

Foundry Agent Service готов к продакшену

Это главная новость. Среда выполнения агентов нового поколения вышла в общую доступность — построена на OpenAI Responses API, совместима на уровне протокола с агентами OpenAI и открыта для моделей от различных поставщиков. Если вы сегодня строите на Responses API, миграция на Foundry добавит корпоративную безопасность, приватную сеть, Entra RBAC, полную трассировку и оценку поверх вашей существующей агентной логики.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Ключевые дополнения: сквозная приватная сеть, расширение MCP-аутентификации (включая OAuth passthrough), предварительный просмотр Voice Live для голосовых агентов и размещённые агенты в 6 новых регионах.

GPT-5.4 — надёжность важнее чистого интеллекта

GPT-5.4 — это не про то, чтобы стать умнее. Это про надёжность. Более сильное рассуждение в длинных взаимодействиях, лучшее следование инструкциям, меньше сбоев в середине рабочего процесса и встроенные возможности использования компьютера. Для продакшен-агентов эта надёжность значит гораздо больше, чем результаты бенчмарков.

Модель	Цена (за М токенов)	Лучше всего для
GPT-5.4 (≤272K)	$2.50 / $15 вывод	Продакшен-агенты, кодирование, документооборот
GPT-5.4 Pro	$30 / $180 вывод	Глубокий анализ, научное рассуждение
GPT-5.4 Mini	Экономичный	Классификация, извлечение, лёгкие вызовы инструментов

Умная стратегия — маршрутизация: GPT-5.4 Mini обрабатывает высоконагруженную работу с низкой задержкой, а GPT-5.4 берёт на себя запросы с интенсивным рассуждением.

SDK наконец стабилен

SDK azure-ai-projects выпустил стабильные релизы на всех языках — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 и .NET 2.0.0 (1 апреля). Зависимость от azure-ai-agents исчезла — всё живёт под AIProjectClient. Установите через pip install azure-ai-projects, пакет включает openai и azure-identity как прямые зависимости.

Для .NET-разработчиков это означает единый NuGet-пакет для всей поверхности Foundry. Больше никакого жонглирования отдельными SDK для агентов.

Fireworks AI приносит открытые модели в Azure

Пожалуй, самое архитектурно интересное дополнение: Fireworks AI обрабатывает более 13 триллионов токенов в день при ~180K запросов/секунду, теперь доступен через Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 и MiniMax M2.5 при запуске.

Настоящая история — это bring-your-own-weights — загружайте квантованные или дообученные веса откуда угодно без смены стека обслуживания. Развёртывание через бессерверную модель с оплатой за токен или выделенную пропускную способность.

Другие важные моменты

Phi-4 Reasoning Vision 15B — мультимодальное рассуждение для графиков, диаграмм и макетов документов
Evaluations GA — готовые оценщики с непрерывным мониторингом продакшена через Azure Monitor
Priority Processing (Preview) — выделенная вычислительная линия для нагрузок, чувствительных к задержке
Voice Live — среда выполнения «голос-к-голосу», подключаемая напрямую к агентам Foundry
Tracing GA — сквозная инспекция трассировок агентов с сортировкой и фильтрацией
Устаревание PromptFlow — миграция на Microsoft Framework Workflows к январю 2027

Заключение

Март 2026 — это поворотный момент для Foundry. Agent Service GA, стабильные SDK на всех языках, GPT-5.4 для надёжных продакшен-агентов и инференс открытых моделей через Fireworks AI — платформа готова к серьёзным нагрузкам.

Прочитайте полный обзор и создайте своего первого агента, чтобы начать.

SQL MCP Server — Правильный способ дать AI-агентам доступ к базе данных

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

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

Давайте будем честны: большинство доступных сегодня MCP-серверов для баз данных устрашают. Они берут запрос на естественном языке, генерируют SQL на лету и выполняют его против ваших продакшн-данных. Что может пойти не так? (Всё. Абсолютно всё.)

Команда Azure SQL только что представила SQL MCP Server, и он использует принципиально другой подход. Построенный как функция Data API builder (DAB) 2.0, он даёт AI-агентам структурированный, детерминированный доступ к операциям с базой данных — без NL2SQL, без раскрытия вашей схемы и с полным RBAC на каждом шагу.

Почему не NL2SQL?

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

Вместо этого SQL MCP Server использует подход NL2DAB. Агент работает со слоем абстракции сущностей Data API builder и встроенным конструктором запросов для детерминированной генерации точного, хорошо сформированного T-SQL. Тот же результат для пользователя, но без риска галлюцинированных JOIN или случайного раскрытия данных.

Семь инструментов, а не семьсот

SQL MCP Server предоставляет ровно семь DML-инструментов, независимо от размера базы данных:

describe_entities — обнаружение доступных сущностей и операций
create_record — вставка строк
read_records — запрос таблиц и представлений
update_record — изменение строк
delete_record — удаление строк
execute_entity — выполнение хранимых процедур
aggregate_records — запросы агрегации

Это умно, потому что контекстные окна — это пространство для мышления агента. Наводнение их сотнями определений инструментов оставляет меньше места для рассуждений. Семь фиксированных инструментов держат агента сфокусированным на мышлении, а не на навигации.

Каждый инструмент можно включить или выключить отдельно:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Начало за три команды

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Это работающий SQL MCP Server, предоставляющий доступ к вашей таблице Customers. Слой абстракции сущностей позволяет задавать псевдонимы для имён и столбцов, ограничивать поля по ролям и точно контролировать, что видят агенты — не раскрывая внутренних деталей схемы.

История безопасности убедительна

Здесь зрелость Data API builder окупается:

RBAC на каждом уровне — каждая сущность определяет, какие роли могут читать, создавать, обновлять или удалять, и какие поля видны
Интеграция с Azure Key Vault — строки подключения и секреты управляются безопасно
Microsoft Entra + пользовательский OAuth — аутентификация продакшн-уровня
Content Security Policy — агенты взаимодействуют через контролируемый контракт, а не сырой SQL

Абстракция схемы особенно важна. Внутренние имена таблиц и столбцов никогда не раскрываются агенту. Вы определяете сущности, псевдонимы и описания, имеющие смысл для AI-взаимодействия — а не вашу ER-диаграмму.

Мульти-база и мульти-протокол

SQL MCP Server поддерживает Microsoft SQL, PostgreSQL, Azure Cosmos DB и MySQL. А поскольку это функция DAB, вы получаете REST, GraphQL и MCP эндпоинты одновременно из одной конфигурации. Те же определения сущностей, те же правила RBAC, та же безопасность — по всем трём протоколам.

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

Моё мнение

Вот как должен работать корпоративный доступ к базам данных для AI-агентов. Не «эй, LLM, напиши мне SQL и YOLO его по продакшну». Вместо этого: чётко определённый слой сущностей, детерминированная генерация запросов, RBAC на каждом шагу, кеширование, мониторинг и телеметрия. Скучно в самом лучшем смысле.

Для .NET-разработчиков история интеграции чистая — DAB является .NET-инструментом, MCP Server работает как контейнер и интегрируется с Azure SQL, который большинство из нас уже использует. Если вы строите AI-агентов, которым нужен доступ к данным, начните здесь.

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

SQL MCP Server бесплатен, с открытым исходным кодом и работает где угодно. Это предписывающий подход Microsoft к предоставлению AI-агентам безопасного доступа к базам данных. Ознакомьтесь с полным постом и документацией для начала работы.

Агентная платформенная инженерия становится реальностью — Git-APE показывает как

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

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

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

Команда Azure только что опубликовала Часть 2 серии об агентной платформенной инженерии, и эта часть целиком о практической реализации. Они называют это Git-APE (да, акроним намеренный), и это open-source проект, который использует агенты GitHub Copilot плюс серверы Azure MCP для превращения запросов на естественном языке в валидированную и развёрнутую инфраструктуру.

Что Git-APE делает на самом деле

Основная идея: вместо того чтобы разработчики изучали модули Terraform, навигировали по UI порталов или создавали тикеты для платформенной команды, они разговаривают с агентом Copilot. Агент интерпретирует намерение, генерирует Infrastructure-as-Code, валидирует его по политикам и разворачивает — всё внутри VS Code.

Вот настройка:

git clone https://github.com/Azure/git-ape
cd git-ape

Откройте workspace в VS Code, и файлы конфигурации агента автоматически обнаруживаются GitHub Copilot. Вы взаимодействуете с агентом напрямую:

@git-ape deploy a function app with storage in West Europe

Агент использует Azure MCP Server под капотом для взаимодействия с сервисами Azure. Конфигурация MCP в настройках VS Code активирует конкретные возможности:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

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

Для тех из нас, кто строит на Azure, это смещает разговор о платформенной инженерии с «как построить портал» на «как описать наши ограничения как API.» Когда интерфейс вашей платформы — это ИИ-агент, качество ваших ограничений и политик становится продуктом.

Блог Части 1 изложил теорию: хорошо описанные API, схемы контроля и явные ограничения делают платформы agent-ready. Часть 2 доказывает, что это работает, поставляя реальные инструменты. Агент не генерирует ресурсы вслепую — он валидирует по лучшим практикам, соблюдает соглашения об именовании и применяет политики вашей организации.

Очистка так же проста:

@git-ape destroy my-resource-group

Моё мнение

Буду честен — здесь больше о паттерне, чем о конкретном инструменте. Git-APE сам по себе — это демо/референсная архитектура. Но лежащая в основе идея — агенты как интерфейс к вашей платформе, MCP как протокол, GitHub Copilot как хост — вот куда движется experience корпоративного разработчика.

Если вы — платформенная команда, которая ищет, как сделать внутренние инструменты agent-friendly, лучшего стартового пункта не найти. А если вы .NET-разработчик и думаете, как это связано с вашим миром: Azure MCP Server и агенты GitHub Copilot работают с любыми нагрузками Azure. Ваш ASP.NET Core API, ваш стек .NET Aspire, ваши контейнеризированные микросервисы — всё это может быть целью агентного потока деплоя.

Подведём итоги

Git-APE — это ранний, но конкретный взгляд на агентную платформенную инженерию на практике. Клонируйте репозиторий, попробуйте демо и начните думать о том, как API и политики вашей платформы должны выглядеть, чтобы агент мог безопасно их использовать.

Читайте полный пост для walkthrough и видео-демонстраций.

Оценка модернизации GitHub Copilot — лучший инструмент миграции, который вы ещё не используете

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

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

Миграция устаревшего приложения .NET Framework на современный .NET — одна из тех задач, о которых все знают, что их нужно сделать, но никто не хочет начинать. Это никогда не просто «сменить целевой фреймворк». Это API, которые исчезли, пакеты, которых больше нет, модели хостинга, которые работают совершенно по-другому, и миллион мелких решений о том, что контейнеризировать, что переписать и что оставить как есть.

Джеффри Фриц только что опубликовал глубокий разбор оценки модернизации GitHub Copilot, и честно? Это лучший инструмент миграции для .NET, который я видел. Не из-за генерации кода — это уже стандарт. Из-за документа оценки, который он создаёт.

Это не просто движок предложений кода

Расширение VS Code следует модели Оценить → Спланировать → Выполнить. Фаза оценки анализирует всю кодовую базу и создаёт структурированный документ, фиксирующий всё: что нужно изменить, какие ресурсы Azure предоставить, какую модель развёртывания использовать. Всё последующее — инфраструктура как код, контейнеризация, манифесты развёртывания — вытекает из результатов оценки.

Оценка хранится в .github/modernize/assessment/ вашего проекта. Каждый запуск создаёт независимый отчёт, поэтому вы накапливаете историю и можете отслеживать, как меняется ваша позиция по миграции по мере исправления проблем.

Два способа начать

Рекомендованная оценка — быстрый путь. Выберите из курируемых доменов (Обновление Java/.NET, облачная готовность, безопасность) и получите значимые результаты без настройки конфигурации. Идеально для первого взгляда на состояние вашего приложения.

Пользовательская оценка — прицельный путь. Настройте точно, что анализировать: целевой compute (App Service, AKS, Container Apps), целевую ОС, анализ контейнеризации. Выберите несколько целей Azure для сравнения подходов к миграции бок о бок.

Это представление сравнения действительно полезно. Приложение с 3 обязательными проблемами для App Service может иметь 7 для AKS. Видеть оба варианта помогает принять решение по хостингу до того, как вы привяжетесь к пути миграции.

Разбивка проблем действенна

Каждая проблема сопровождается уровнем критичности:

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

И каждая проблема ссылается на затронутые файлы и номера строк, предоставляет подробное описание того, что не так и почему это важно для вашей целевой платформы, даёт конкретные шаги по устранению (не просто «исправьте это») и включает ссылки на официальную документацию.

Вы можете передать отдельные проблемы разработчикам, и у них есть всё необходимое для действий. В этом разница между инструментом, который говорит «есть проблема» и инструментом, который говорит, как её решить.

Охваченные пути обновления

Для .NET конкретно:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

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

Для команд, управляющих несколькими приложениями, есть также CLI, поддерживающий пакетные оценки нескольких репозиториев — клонируйте все репо, оцените их все, получите отчёты по каждому приложению плюс агрегированное представление портфолио.

Моё мнение

Если вы сидите на устаревших приложениях .NET Framework (а давайте будем честны, большинство корпоративных команд именно так и делает), это тот самый инструмент, с которого стоит начать. Только документ оценки стоит потраченного времени — он превращает расплывчатое «нам бы модернизировать» в конкретный, приоритизированный список рабочих элементов с чёткими путями вперёд.

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

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

Оценка модернизации GitHub Copilot превращает миграцию .NET из пугающего, неопределённого проекта в структурированный, отслеживаемый процесс. Начните с рекомендованной оценки, чтобы увидеть текущее состояние, затем используйте пользовательские оценки для сравнения целей Azure и построения плана миграции.

Прочитайте полное руководство и установите расширение VS Code, чтобы попробовать на своей кодовой базе.

Подключите ваши 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-возможностями с правильной аутентификацией и без изменений кода на сервере.

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

Создаём мультиагентные UI в реальном времени, которые не выглядят как чёрный ящик

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

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

Вот в чём дело с мультиагентными системами: в демо они выглядят невероятно. Три агента передают друг другу работу, решают задачи, принимают решения. А потом ты пытаешься показать это реальным пользователям и… тишина. Крутящийся индикатор. Непонятно, какой агент чем занимается и почему система встала на паузу. Это не продукт — это проблема доверия.

Команда Microsoft Agent Framework только что опубликовала отличный walkthrough о том, как связать рабочие процессы MAF с AG-UI — открытым протоколом для потоковой передачи событий выполнения агентов на фронтенд через Server-Sent Events. И честно? Это именно тот мост, которого нам не хватало.

Почему это важно для .NET-разработчиков

Если вы строите приложения с ИИ, наверняка уже упирались в эту стену. Ваша серверная оркестрация работает отлично — агенты передают задачи друг другу, инструменты запускаются, решения принимаются. Но фронтенд понятия не имеет, что происходит за кулисами. AG-UI решает это, определяя стандартный протокол для потоковой передачи событий агентов (RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) напрямую в ваш UI-слой через SSE.

Демо — это рабочий процесс клиентской поддержки с тремя агентами: агент триажа маршрутизирует запросы, агент возвратов обрабатывает денежные вопросы, и агент заказов управляет заменами. У каждого агента свои инструменты, а топология передач определена явно — никакого «разберись из промпта».

Топология передач — настоящая звезда

Что зацепило мой взгляд — как HandoffBuilder позволяет объявить направленный граф маршрутизации между агентами:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Каждый add_handoff создаёт направленное ребро с описанием на естественном языке. Фреймворк генерирует инструменты передачи для каждого агента на основе этой топологии. Решения о маршрутизации основываются на вашей структуре оркестрации, а не на том, что LLM решит сделать. Это огромное преимущество для надёжности в продакшене.

Human-in-the-loop, который действительно работает

Демо показывает два паттерна прерываний, без которых не обойтись ни одному реальному агентному приложению:

Прерывания для одобрения инструментов — когда агент вызывает инструмент с approval_mode="always_require", рабочий процесс ставится на паузу и отправляет событие. Фронтенд рендерит модальное окно одобрения с названием инструмента и аргументами. Никаких циклов повторных попыток, сжигающих токены — просто чистый поток пауза-одобрение-возобновление.

Прерывания запроса информации — когда агенту нужно больше контекста от пользователя (например, ID заказа), он ставит на паузу и спрашивает. Фронтенд показывает вопрос, пользователь отвечает, и выполнение возобновляется с того же места, где остановилось.

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

Подключение удивительно простое

Интеграция между MAF и AG-UI — это один вызов функции:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory создаёт свежий рабочий процесс для каждого потока, так что каждый диалог получает изолированное состояние. Эндпоинт автоматически обрабатывает всю SSE-обвязку. Если вы уже используете FastAPI (или можете добавить его как лёгкий слой), это практически без трения.

Моё мнение

Для нас, .NET-разработчиков, немедленный вопрос: «Можно ли сделать это на C#?» Agent Framework доступен и для .NET, и для Python, а протокол AG-UI не зависит от языка (это просто SSE). Так что хотя конкретная демка использует Python и FastAPI, паттерн переносится напрямую. Вы можете настроить минимальный API ASP.NET Core с SSE-эндпоинтами, следуя той же схеме событий AG-UI.

Более важный вывод — мультиагентные UI становятся полноценной задачей первого класса, а не чем-то придуманным постфактум. Если вы строите что-либо, где агенты взаимодействуют с людьми — клиентская поддержка, рабочие процессы утверждения, обработка документов — эта комбинация оркестрации MAF и прозрачности AG-UI является паттерном, которому стоит следовать.

Подведём итоги

AG-UI + Microsoft Agent Framework даёт вам лучшее из обоих миров: надёжную мультиагентную оркестрацию на бэкенде и видимость в реальном времени на фронтенде. Больше никаких взаимодействий агентов как чёрный ящик.

Посмотрите полный walkthrough и репозиторий протокола AG-UI, чтобы погрузиться глубже.

azd теперь позволяет запускать и отлаживать ИИ-агенты локально — Что изменилось в марте 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Семь релизов за месяц. Именно столько выпустила команда Azure Developer CLI (azd) в марте 2026, и главная фича — та, которую я ждал: локальный цикл запуска и отладки для ИИ-агентов.

PC Chan опубликовала полный обзор, и хотя там много всего, позвольте мне отфильтровать то, что действительно важно для .NET-разработчиков, создающих приложения с ИИ.

Запуск и отладка ИИ-агентов без деплоя

Это главное. Новое расширение azure.ai.agents добавляет команды для полноценного inner-loop для ИИ-агентов:

azd ai agent run — запускает агент локально
azd ai agent invoke — отправляет сообщения (локально или в продакшн)
azd ai agent show — показывает статус контейнера и здоровье
azd ai agent monitor — стримит логи контейнера в реальном времени

Раньше тестирование ИИ-агента означало деплой в Microsoft Foundry при каждом изменении. Теперь можно итерировать локально, тестировать поведение агента и деплоить только когда готов.

GitHub Copilot настраивает ваш azd-проект

azd init теперь предлагает опцию “Set up with GitHub Copilot (Preview)”. Вместо ручного ответа на промпты, Copilot-агент генерирует конфигурацию за вас. Когда команда падает, azd предлагает ИИ-ассистированное устранение неполадок — всё не выходя из терминала.

Container App Jobs и улучшения деплоя

Container App Jobs: azd теперь деплоит Microsoft.App/jobs через существующую конфигурацию host: containerapp.
Настраиваемые таймауты деплоя: Новый флаг --timeout в azd deploy и поле deployTimeout в azure.yaml.
Фолбэк удалённой сборки: При неудаче ACR-сборки azd автоматически переключается на локальный Docker/Podman.
Локальная preflight-валидация: Bicep-параметры проверяются локально перед деплоем.

Улучшения DX

Автоматическое определение pnpm/yarn для JS/TS-проектов
Поддержка pyproject.toml для Python
Локальные каталоги шаблонов — azd init --template принимает пути файловой системы
Улучшенные сообщения об ошибках в режиме --no-prompt
Переменные окружения сборки — инжектируются во все подпроцессы сборки (.NET, Node.js, Java, Python)

Подведём итоги

Локальный цикл отладки ИИ-агентов — звезда этого релиза, но совокупность улучшений деплоя и DX делает azd более зрелым, чем когда-либо. Если вы деплоите .NET-приложения в Azure — особенно ИИ-агенты — это обновление стоит внимания.

Ознакомьтесь с полными заметками о выпуске.

KubeCon Europe 2026: Что на самом деле важно для .NET-разработчиков

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Знаете это чувство, когда выходит огромный пост с анонсами и вы листаете его, думая «круто, но что это на самом деле меняет для меня»? Это я каждый сезон KubeCon.

Microsoft только что опубликовала свой полный обзор KubeCon Europe 2026 — написанный лично Бренданом Бёрнсом — и честно? Здесь настоящая суть. Не просто чеклисты фич, а операционные улучшения, которые меняют подход к управлению в продакшене.

Давайте разберём, что действительно важно для нас, .NET-разработчиков.

mTLS без налога service mesh

Вот в чём дело с service mesh: все хотят гарантий безопасности, никто не хочет операционной нагрузки. AKS наконец закрывает этот разрыв.

Azure Kubernetes Application Network даёт вам mutual TLS, авторизацию с учётом приложения и телеметрию трафика — без развёртывания полного mesh с тяжёлыми sidecar. В сочетании с Cilium mTLS в Advanced Container Networking Services вы получаете зашифрованную связь между подами с использованием сертификатов X.509 и SPIRE для управления идентификацией.

Что это значит на практике: ваши ASP.NET Core API общаются с фоновыми воркерами, ваши gRPC-сервисы вызывают друг друга — всё зашифровано и верифицировано на сетевом уровне, без единого изменения в коде приложения. Это серьёзно.

Для команд, мигрирующих с ingress-nginx, есть также Application Routing с Meshless Istio с полной поддержкой Kubernetes Gateway API. Без sidecar. На основе стандартов. Плюс инструменты ingress2gateway для постепенной миграции.

Наблюдаемость GPU — не как запоздалая мысль

Если вы запускаете AI-инференс рядом с .NET-сервисами (а давайте честно, кто сейчас не начинает?), вы наверняка столкнулись со слепым пятном мониторинга GPU. У вас были отличные дашборды CPU/памяти, а потом… ничего для GPU без ручной настройки экспортёров.

AKS теперь показывает метрики GPU нативно в управляемых Prometheus и Grafana. Тот же стек, те же дашборды, тот же пайплайн алертов. Без кастомных экспортёров, без сторонних агентов.

На сетевой стороне добавлена видимость по потокам для HTTP, gRPC и Kafka-трафика с Azure Monitor в один клик. IP, порты, ворклоуды, направление потока, решения по политикам — всё во встроенных дашбордах.

А вот то, от чего я посмотрел дважды: agentic container networking добавляет веб-интерфейс, где можно задавать вопросы на естественном языке о состоянии сети кластера. «Почему под X не достигает сервис Y?» → диагностика только для чтения из live-телеметрии. Реально полезно в 2 часа ночи.

Кросс-кластерная сеть без учёной степени

Мульти-кластерный Kubernetes исторически был опытом «принеси свой сетевой клей». Azure Kubernetes Fleet Manager теперь обеспечивает кросс-кластерную сеть через управляемый Cilium cluster mesh:

Единая связность между кластерами AKS
Глобальный реестр сервисов для кросс-кластерного обнаружения
Конфигурация управляется централизованно, а не повторяется для каждого кластера

Если вы запускаете .NET-микросервисы в нескольких регионах для отказоустойчивости или соответствия требованиям, это заменяет много хрупкого кастомного клея. Сервис A в West Europe может обнаружить и вызвать Сервис B в East US через mesh, с согласованными политиками маршрутизации и безопасности.

Обновления, не требующие смелости

Давайте честно — обновления Kubernetes в продакшене — это стресс. «Обновить и надеяться» было стратегией по умолчанию для слишком многих команд и главной причиной, по которой кластеры отстают по версиям.

Две новые возможности меняют это:

Blue-green обновления пулов агентов создают параллельный пул нод с новой конфигурацией. Валидируйте поведение, постепенно переключайте трафик и сохраняйте чистый путь отката. Больше никаких мутаций на месте на продакшн-нодах.

Откат пула агентов позволяет вернуть пул нод на предыдущую версию Kubernetes и образ ноды после неудачного обновления — без пересборки кластера.

Вместе они наконец дают операторам реальный контроль над жизненным циклом обновлений. Для .NET-команд это важно, потому что скорость платформы напрямую определяет, как быстро вы можете принять новые рантаймы, патчи безопасности и сетевые возможности.

AI-рабочие нагрузки становятся полноценными гражданами Kubernetes

Upstream-работа в open source не менее важна. Dynamic Resource Allocation (DRA) только что стала GA в Kubernetes 1.36, сделав планирование GPU настоящей первоклассной функцией вместо обходного пути.

Проекты, за которыми стоит следить:

Проект	Что делает
AI Runway	Общий Kubernetes API для инференса — деплой моделей без знания K8s, с обнаружением HuggingFace и оценкой стоимости
HolmesGPT	Агентный troubleshooting для cloud-native — теперь проект CNCF Sandbox
Dalec	Декларативная сборка образов контейнеров с генерацией SBOM — меньше CVE на этапе сборки

Направление ясно: ваш .NET API, слой оркестрации на Semantic Kernel и ваши рабочие нагрузки инференса должны работать на одной согласованной платформенной модели. Мы приближаемся.

С чего бы я начал на этой неделе

Если вы оцениваете эти изменения для своей команды, вот мой честный список приоритетов:

Наблюдаемость в первую очередь — включите метрики GPU и логи сетевых потоков в непродакшен-кластере. Посмотрите, что вы упускали.
Попробуйте blue-green обновления — протестируйте workflow отката перед следующим обновлением продакшен-кластера. Постройте доверие к процессу.
Пилотируйте сеть с учётом идентичности — выберите один внутренний путь сервиса и включите mTLS с Cilium. Измерьте оверхед (спойлер: минимальный).
Оцените Fleet Manager — если у вас больше двух кластеров, кросс-кластерная сеть окупается за счёт сокращения кастомного клея.

Маленькие эксперименты, быстрая обратная связь. Это всегда правильный ход.

Подводя итог

Анонсы KubeCon могут быть ошеломляющими, но эта порция реально двигает стрелку для .NET-команд на AKS. Лучшая сетевая безопасность без оверхеда mesh, настоящая наблюдаемость GPU, более безопасные обновления и более прочные основы AI-инфраструктуры.

Если вы уже на AKS, сейчас отличный момент укрепить ваш операционный baseline. А если планируете перенести .NET-рабочие нагрузки на Kubernetes — платформа только что стала значительно более готовой к продакшену.

SQL MCP Server, Copilot в SSMS и Database Hub с ИИ-агентами: что действительно важно с SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft только что открыла SQLCon 2026 вместе с FabCon в Атланте, и тут есть что разбирать. Оригинальный анонс охватывает всё — от планов экономии до корпоративных функций соответствия требованиям. Я пропущу слайды с корпоративными ценами и сосредоточусь на том, что важно, если вы разработчик, создающий решения с Azure SQL и ИИ.

SQL MCP Server в публичном превью

Это главная новость для меня. Azure SQL Database Hyperscale теперь имеет SQL MCP Server в публичном превью, который позволяет безопасно подключать ваши данные SQL к ИИ-агентам и Copilot через Model Context Protocol.

Если вы следили за волной MCP — а честно говоря, сейчас это трудно пропустить — это большое дело. Вместо создания пользовательских конвейеров данных для передачи контекста из базы данных вашим ИИ-агентам, вы получаете стандартизированный протокол для прямого предоставления SQL-данных. Ваши агенты могут запрашивать, анализировать и действовать на основе актуальной информации из базы данных.

Для тех из нас, кто создаёт ИИ-агентов с Semantic Kernel или Microsoft Agent Framework, это открывает чистый путь интеграции. Вашему агенту нужно проверить наличие товара? Найти запись клиента? Валидировать заказ? MCP даёт ему структурированный способ сделать это без написания индивидуального кода получения данных для каждого сценария.

GitHub Copilot в SSMS 22 вышел в GA

Если вы проводите время в SQL Server Management Studio — и будем честны, большинство из нас до сих пор это делает — GitHub Copilot теперь общедоступен в SSMS 22. Тот же опыт Copilot, который вы уже используете в VS Code и Visual Studio, но для T-SQL.

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

Векторные индексы получили серьёзное обновление

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

Что нового:

Квантование для уменьшения размера индекса без значительной потери точности
Итеративная фильтрация для более точных результатов
Тесная интеграция с оптимизатором запросов для предсказуемой производительности

Если вы используете retrieval-augmented generation (RAG) с Azure SQL в качестве векторного хранилища, эти улучшения напрямую полезны. Вы можете хранить векторы рядом с реляционными данными в одной базе данных, что значительно упрощает архитектуру по сравнению с запуском отдельной векторной базы данных.

Те же улучшения для векторов доступны и в SQL database в Fabric, поскольку обе системы работают на одном движке SQL.

Database Hub в Fabric: агентное управление

Этот анонс больше ориентирован на будущее, но он интересен. Microsoft анонсировала Database Hub в Microsoft Fabric (ранний доступ), который даёт единую панель управления для Azure SQL, Cosmos DB, PostgreSQL, MySQL и SQL Server через Arc.

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

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

Что это значит для .NET-разработчиков

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

Если вы создаёте приложения на .NET с Azure SQL, вот что я бы реально сделал:

Попробуйте SQL MCP Server, если вы создаёте ИИ-агентов. Это самый чистый способ дать вашим агентам доступ к базе данных без пользовательской обвязки.
Включите Copilot в SSMS, если ещё не сделали — бесплатный прирост производительности для ежедневной работы с SQL.
Посмотрите на векторные индексы, если вы используете RAG и сейчас запускаете отдельное векторное хранилище. Консолидация на Azure SQL — это на один сервис меньше для управления.

Итог

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

Ознакомьтесь с полным анонсом от Shireesh Thota для полной картины и зарегистрируйтесь для раннего доступа к Database Hub, если хотите попробовать новый опыт управления.

Azure DevOps MCP Server появился в Microsoft Foundry: что это значит для ваших ИИ-агентов

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) переживает свой момент. Если вы следите за экосистемой ИИ-агентов, вы наверняка заметили, что MCP-серверы появляются повсюду — давая агентам возможность взаимодействовать с внешними инструментами и сервисами через стандартизированный протокол.

Теперь Azure DevOps MCP Server доступен в Microsoft Foundry, и это одна из тех интеграций, которая заставляет задуматься о практических возможностях.

Что здесь на самом деле происходит

Microsoft уже выпустила Azure DevOps MCP Server в публичном превью — это сам MCP-сервер. Новое — это интеграция с Foundry. Теперь вы можете добавить Azure DevOps MCP Server к своим агентам в Foundry прямо из каталога инструментов.

Для тех, кто ещё не знаком с Foundry: это унифицированная платформа Microsoft для создания и управления ИИ-приложениями и агентами в масштабе. Доступ к моделям, оркестрация, оценка, развёртывание — всё в одном месте.

Настройка

Настройка удивительно проста:

В вашем агенте Foundry перейдите в Add Tools > Catalog
Найдите “Azure DevOps”
Выберите Azure DevOps MCP Server (preview) и нажмите Create
Введите имя вашей организации и подключитесь

Вот и всё. Ваш агент теперь имеет доступ к инструментам Azure DevOps.

Контроль доступа агента

Вот что мне нравится: вы не ограничены подходом «всё или ничего». Вы можете указать, какие инструменты доступны вашему агенту. Если вы хотите, чтобы он только читал work items, но не трогал пайплайны, это можно настроить. Принцип наименьших привилегий, применённый к вашим ИИ-агентам.

Это важно для корпоративных сценариев, где вы не хотите, чтобы агент случайно запустил пайплайн развёртывания, потому что кто-то попросил его «помочь с релизом».

Почему это интересно для .NET-команд

Подумайте о том, что это позволяет на практике:

Помощники планирования спринтов — агенты, которые могут извлекать work items, анализировать данные о скорости работы и предлагать ёмкость спринта
Боты для код-ревью — агенты, которые понимают контекст вашего PR, потому что могут реально читать ваши репозитории и связанные work items
Реагирование на инциденты — агенты, которые могут создавать work items, запрашивать последние развёртывания и сопоставлять баги с недавними изменениями
Онбординг разработчиков — “Над чем мне работать?” получает реальный ответ, основанный на фактических данных проекта

Для .NET-команд, уже использующих Azure DevOps для CI/CD-пайплайнов и управления проектами, наличие ИИ-агента, который может напрямую взаимодействовать с этими системами, — это значительный шаг к полезной автоматизации (а не просто чат-бот как сервис).

Более широкая картина MCP

Это часть более крупного тренда: MCP-серверы становятся стандартным способом взаимодействия ИИ-агентов с внешним миром. Мы видим их для GitHub, Azure DevOps, баз данных, SaaS API — и Foundry становится хабом, где все эти соединения объединяются.

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

Итог

Azure DevOps MCP Server в Foundry находится в превью, так что ожидайте его развития. Но основной рабочий процесс надёжен: подключите, настройте доступ к инструментам и позвольте вашим агентам работать с данными DevOps. Если вы уже в экосистеме Foundry, это в нескольких кликах. Попробуйте и посмотрите, какие рабочие процессы вы сможете построить.

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

Foundry Agent Service вышел в GA: что действительно важно для .NET-разработчиков агентов

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Будем честны — создать прототип ИИ-агента — это простая часть. Сложная часть — всё, что идёт после: вывести его в продакшен с правильной сетевой изоляцией, запустить оценки, которые действительно что-то значат, обеспечить соответствие требованиям и не сломать ничего в 2 часа ночи.

Foundry Agent Service только что вышел в GA, и этот релиз сфокусирован именно на этом разрыве «всё, что после».

Построен на Responses API

Вот главная новость: Foundry Agent Service нового поколения построен на OpenAI Responses API. Если вы уже работаете с этим wire-протоколом, миграция на Foundry — это минимальные изменения кода. Что вы получаете: корпоративную безопасность, приватную сеть, Entra RBAC, полную трассировку и оценку — поверх вашей существующей логики агента.

Архитектура намеренно открыта. Вы не привязаны к одному провайдеру моделей или одному фреймворку оркестрации. Используйте DeepSeek для планирования, OpenAI для генерации, LangGraph для оркестрации — рантайм обеспечивает слой согласованности.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Если вы переходите с пакета azure-ai-agents, агенты теперь являются операциями первого класса на AIProjectClient в azure-ai-projects. Удалите отдельную зависимость и используйте get_openai_client() для работы с ответами.

Приватная сеть: корпоративный блокер устранён

Это функция, которая разблокирует корпоративное внедрение. Foundry теперь поддерживает полную сквозную приватную сеть с BYO VNet:

Нет публичного исходящего трафика — трафик агента никогда не проходит через публичный интернет
Внедрение контейнеров/подсетей в вашу сеть для локальной коммуникации
Подключение инструментов включено — MCP-серверы, Azure AI Search, агенты данных Fabric — всё работает через приватные пути

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

Аутентификация MCP сделана правильно

Подключения к MCP-серверам теперь поддерживают полный спектр паттернов аутентификации:

Метод аутентификации	Когда использовать
На основе ключей	Простой общий доступ для внутренних инструментов организации
Entra Agent Identity	Сервис-к-сервису; агент аутентифицируется от своего имени
Entra Managed Identity	Изоляция на уровне проекта; без управления учётными данными
OAuth Identity Passthrough	Делегированный доступ пользователя; агент действует от имени пользователей

OAuth Identity Passthrough — самый интересный. Когда пользователям нужно предоставить агенту доступ к своим личным данным — их OneDrive, их организации Salesforce, SaaS API с пользовательской областью — агент действует от их имени через стандартные OAuth-потоки. Никакой общей системной идентификации, притворяющейся всеми.

Voice Live: речь-в-речь без сантехнических работ

Добавление голоса к агенту раньше означало объединение STT, LLM и TTS — три сервиса, три задержки, три поверхности биллинга, всё синхронизировано вручную. Voice Live сворачивает это в единый управляемый API с:

Семантическое определение голосовой активности и конца реплики (понимает смысл, а не просто тишину)
Серверное подавление шума и эхо-компенсация
Поддержка прерывания (пользователи могут прервать ответ)

Голосовые взаимодействия проходят через тот же рантайм агента, что и текстовые. Те же оценщики, те же трассировки, та же прозрачность затрат. Для поддержки клиентов, полевого обслуживания или сценариев доступности это заменяет то, что раньше требовало пользовательского аудио-пайплайна.

Оценки: от галочки к непрерывному мониторингу

Здесь Foundry серьёзно подходит к качеству продакшена. Система оценки теперь имеет три уровня:

Готовые оценщики — связность, релевантность, обоснованность, качество поиска, безопасность. Подключите к датасету или живому трафику и получите оценки обратно.
Пользовательские оценщики — закодируйте свою бизнес-логику, стандарты тона и специфичные для домена правила соответствия.
Непрерывная оценка — Foundry сэмплирует живой продакшен-трафик, запускает набор оценщиков и отображает результаты через дашборды. Настройте алерты Azure Monitor на случай падения обоснованности или нарушения порогов безопасности.

Всё публикуется в Azure Monitor Application Insights. Качество агента, здоровье инфраструктуры, затраты и телеметрия приложения — всё в одном месте.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Шесть новых регионов для размещённых агентов

Размещённые агенты теперь доступны в East US, North Central US, Sweden Central, Southeast Asia, Japan East и других регионах. Это важно для требований к размещению данных и для снижения задержки, когда ваш агент работает рядом с источниками данных.

Почему это важно для .NET-разработчиков

Хотя примеры кода в анонсе GA написаны на Python, базовая инфраструктура не зависит от языка — и .NET SDK для azure-ai-projects следует тем же паттернам. Responses API, фреймворк оценки, приватная сеть, аутентификация MCP — всё это доступно из .NET.

Если вы ждали, пока ИИ-агенты перейдут от «классной демо» к «я реально могу отправить это на работе», этот GA-релиз — тот самый сигнал. Приватная сеть, правильная аутентификация, непрерывная оценка и продакшен-мониторинг — это были недостающие элементы.

Итог

Foundry Agent Service доступен сейчас. Установите SDK, откройте портал и начинайте строить. Руководство по быстрому старту проведёт вас от нуля до работающего агента за минуты.

Для полного технического погружения со всеми примерами кода ознакомьтесь с анонсом GA.

С ноутбука в продакшен: развёртывание ИИ-агентов в Microsoft Foundry двумя командами

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Вы знаете тот разрыв между «работает на моей машине» и «развёрнуто и обслуживает трафик»? Для ИИ-агентов этот разрыв был болезненно широким. Нужно подготовить ресурсы, развернуть модели, настроить идентификацию, организовать мониторинг — и это до того, как кто-либо сможет реально вызвать вашего агента.

Azure Developer CLI только что превратил это в дело двух команд.

Новый рабочий процесс `azd ai agent`

Давайте пройдём по тому, как это реально выглядит. У вас есть проект ИИ-агента — допустим, агент-консьерж для отеля. Он работает локально. Вы хотите запустить его на Microsoft Foundry.

azd ai agent init
azd up

Вот и всё. Две команды. azd ai agent init генерирует инфраструктуру как код в вашем репозитории, а azd up разворачивает всё в Azure и публикует вашего агента. Вы получаете прямую ссылку на вашего агента в портале Foundry.

Что происходит под капотом

Команда init генерирует реальные, проверяемые шаблоны Bicep в вашем репозитории:

Foundry Resource (контейнер верхнего уровня)
Foundry Project (где живёт ваш агент)
Конфигурация развёртывания модели (GPT-4o и т.д.)
Managed identity с правильными назначениями ролей RBAC
azure.yaml для карты сервисов
agent.yaml с метаданными агента и переменными окружения

Ключевой момент: всё это принадлежит вам. Это версионированный Bicep в вашем репозитории. Вы можете его проверить, настроить и закоммитить рядом с кодом вашего агента. Никаких магических чёрных ящиков.

Внутренний цикл разработки

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

azd ai agent run

Это запускает вашего агента локально. Комбинируйте с azd ai agent invoke для отправки тестовых промптов, и у вас есть быстрый цикл обратной связи. Редактируете код, перезапускаете, вызываете, повторяете.

Команда invoke умная в плане маршрутизации — когда локальный агент запущен, она автоматически направляет на него. Когда нет — обращается к удалённому эндпоинту.

Мониторинг в реальном времени

Вот функция, которая меня купила. После развёртывания агента:

azd ai agent monitor --follow

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

Полный набор команд

Вот краткий справочник:

Команда	Что делает
`azd ai agent init`	Генерирует проект агента Foundry с IaC
`azd up`	Разворачивает Azure-ресурсы и публикует агента
`azd ai agent invoke`	Отправляет промпты удалённому или локальному агенту
`azd ai agent run`	Запускает агента локально для разработки
`azd ai agent monitor`	Транслирует логи от опубликованного агента в реальном времени
`azd ai agent show`	Проверяет состояние и здоровье агента
`azd down`	Удаляет все Azure-ресурсы

Почему это важно для .NET-разработчиков

Хотя пример в анонсе написан на Python, история инфраструктуры не зависит от языка. Ваш .NET-агент получает тот же Bicep-шаблон, ту же настройку managed identity, тот же пайплайн мониторинга. И если вы уже используете azd для своих .NET Aspire-приложений или развёртываний Azure, это вписывается прямо в ваш существующий рабочий процесс.

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

Итог

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

Фоновые ответы в Microsoft Agent Framework: больше никакой тревоги из-за таймаутов

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Если вы создавали что-либо с моделями рассуждения, такими как o3 или GPT-5.2, вы знаете эту боль. Ваш агент начинает обдумывать сложную задачу, клиент сидит и ждёт, и где-то между «всё нормально» и «он завис?» ваше соединение падает по таймауту. Вся работа? Потеряна.

Microsoft Agent Framework только что выпустил фоновые ответы — и честно говоря, это одна из тех функций, которая должна была существовать с первого дня.

Проблема с блокирующими вызовами

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

HTTP-соединения могут упасть по таймауту
Сетевые сбои убивают всю операцию
Ваш пользователь смотрит на спиннер, гадая, происходит ли что-нибудь

Фоновые ответы переворачивают этот подход.

Как работают continuation-токены

Вместо блокировки вы запускаете задачу агента и получаете обратно continuation-токен. Представьте его как квитанцию в ремонтной мастерской — вы не стоите у стойки и ждёте, а приходите, когда всё готово.

Процесс прост:

Отправьте запрос с AllowBackgroundResponses = true
Если агент поддерживает фоновую обработку, вы получаете continuation-токен
Опрашивайте по своему расписанию, пока токен не вернёт null — это значит, результат готов

Вот версия на .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Опрашиваем до завершения
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Если агент завершает немедленно (простые задачи, модели, не требующие фоновой обработки), continuation-токен не возвращается. Ваш код просто работает — никакой специальной обработки не нужно.

Стриминг с возобновлением: настоящая магия

Опрос подходит для сценариев «запустил и забыл», но что если вы хотите видеть прогресс в реальном времени? Фоновые ответы также поддерживают стриминг со встроенным возобновлением.

Каждое потоковое обновление несёт свой continuation-токен. Если соединение прерывается посреди потока, вы продолжаете ровно с того места, где остановились:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Симулируем разрыв сети
}

// Возобновляем ровно с того места, где остановились
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Агент продолжает обработку на стороне сервера независимо от того, что происходит с вашим клиентом. Это встроенная отказоустойчивость без написания логики повторных попыток или circuit breaker’ов.

Когда это действительно использовать

Не каждый вызов агента нуждается в фоновых ответах. Для быстрых завершений вы добавляете сложность без причины. Но вот где они реально полезны:

Сложные задачи рассуждения — многоэтапный анализ, глубокие исследования, всё, что заставляет модель рассуждения действительно думать
Генерация длинного контента — детальные отчёты, многочастные документы, обширный анализ
Ненадёжные сети — мобильные клиенты, периферийные развёртывания, нестабильные корпоративные VPN
Асинхронные UX-паттерны — отправьте задачу, займитесь другим делом, вернитесь за результатами

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

Итог

Фоновые ответы уже доступны в .NET и Python через Microsoft Agent Framework. Если вы создаёте агентов, которые делают что-то сложнее простых вопросов-ответов, это стоит добавить в свой инструментарий. Паттерн с continuation-токенами сохраняет простоту, решая очень реальную продакшен-проблему.

Ознакомьтесь с полной документацией для полного справочника API и дополнительных примеров.

Azure | The .NET Blog

Microsoft Foundry Апрель 2026: Foundry Local GA, GPT-5.5, CodeAct с Hyperlight

Foundry Local Стал Общедоступным

GPT-5.5

Трассировка Agent Framework в Foundry

CodeAct с Hyperlight (Alpha)

Панель Мониторинга Агентов (Предварительная Версия)

Пользовательские Эвалюаторы Непрерывной Оценки (Предварительная Версия)

Инвентарь Агентов в Плоскости Управления

Ваш Локальный Агент MAF Только Что Получил Дом в Продакшене

Что На Самом Деле Делает Foundry Hosted Agents

Разница в Коде Минимальна

Два Протокола, Один Агент

Процесс Развёртывания с azd

Заключение

Foundry Local 1.1: Транскрипция в реальном времени, Embeddings и Responses API

Живая транскрипция аудио

Text Embeddings

Responses API

Улучшения размера пакета

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

Cosmos DB Shell В Публичной Предварительной Версии — И В Нём Встроен MCP-Сервер

Что Отличает Его от Других CLI Баз Данных

Основа с Открытым Исходным Кодом Важна

Три Сценария, Которые Становятся Проще

С Чего Начать

У Вашего ИИ-Агента Проблема с Идентификацией (И Вот Шаблон, Который Её Решает)

Основная Проблема: Аутентификация ≠ Авторизация

Как Работает Цепочка Токенов

Что Развёртывает Шаблон

Принцип Дизайна, Достойный Заимствования

Заключение

Частные Endpoints, VNets, NSG — Aspire Теперь Управляет Сетью

Строительные блоки

Описание в AppHost

Почему Это Важно для Реальных Приложений

Итог

Aspire 13.3: Поддержка Kubernetes, журналы браузера и навык Aspireify

Aspireify: Онбординг с помощью агента

Первоклассное развёртывание Kubernetes и AKS

Журналы браузера в дашборде

Структурированные результаты команд

Итог

SDD Conference 2026

Темы

Спикеры

Билеты и информация

SQL MCP Server на Azure App Service — без контейнеров

Что такое SQL MCP Server?

Проблема контейнеров (и её решение)

Аутентификация без общих API-ключей

Развёртывание на App Service

Почему это важно для .NET-разработчиков

Итог

Устранение Рутинной Работы Миграции с Помощью Agentic Platform Engineering

Входные данные: contoso-migration

Шаг 1: Валидация и аутентификация

Шаг 2: Извлечение намерения

Шаг 3: Сопоставление сервисов

Шаг 4: Агент-критик

Шаг 5: Сгенерированный вывод

Сравнение уровня безопасности

Чем это отличается от конвертора синтаксиса

SQL Server 2025 как База Данных для Агентов: Безопасность, Бэкап и MCP в Одном Движке

Одна Модель Безопасности для Всех Моделей Данных

Единый Бэкап = Атомарное Восстановление

MCP-Интеграция: Агенты Без Middleware

Azure MCP Server Теперь .mcpb — Установка без Какого-либо Runtime

Что такое MCP Bundle?

Как установить

Что можно делать

С чего начать

Azure SDK Апрель 2026: AI Foundry 2.0 и Что Должны Знать .NET-Разработчики

Azure.AI.Projects 2.0.0 — Ломающие Изменения, Которые Имеют Смысл

Cosmos DB Java: Критическое Исправление Безопасности (RCE)

Новые Provisioning-Библиотеки для .NET

GPT-5.5 Уже Здесь и Приходит в Azure Foundry — Что Нужно Знать .NET-разработчикам

Эволюция GPT-5

Что реально изменилось

Цены

Процесс Развёртывания с `azd`