The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 проходит с 14 по 18 сентября 2026 года в Oslo Spektrum, Осло, Норвегия.

NDC Oslo — одна из крупнейших и наиболее уважаемых конференций для разработчиков в Европе, охватывающая всё: от .NET и облачных технологий до безопасности, архитектуры, ИИ и другого. Выпуск 2026 года сейчас на этапе бронирования, с масштабной программой в процессе формирования.

В цифрах

160 сессий (бронирование)
150 спикеров (бронирование)
15 воркшопов (бронирование)
5 дней — воркшопы + конференция

Подтверждённые спикеры

Список спикеров формируется, среди подтверждённых имён:

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

Билеты

Билеты Early Bird доступны — предложение Early Bird действует до 22 мая 2026 года.

CFP (Call for Papers) также открыт.

Другие мероприятия NDC в 2026 году

NDC Sydney — 22–24 апреля 2026
NDC Toronto — 5–8 мая 2026
NDC Copenhagen — 1–4 июня 2026
NDC AI — 8–10 июня 2026
NDC TechTown — 21–24 сентября 2026

Ссылки

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 пройдёт 25 августа 2026 года в Arena Cinemas Sihlcity (Kalanderplatz 8, 8045 Цюрих).

Это независимая некоммерческая конференция сообщества для разработчиков, архитекторов и экспертов, посвящённая .NET, C#, ASP.NET Core, Azure и экосистеме разработки Microsoft. Все спикеры и организаторы участвуют добровольно, а излишки от продажи билетов направляются на благотворительность или развитие швейцарского .NET-сообщества.

Что вас ждёт

Качественные доклады от международных экспертов
Нетворкинг с другими участниками
Еда, закуски и напитки во время перерывов, обеда и аперо
Карьерные возможности через взаимодействие со спонсорами
Прямое общение со спикерами в перерывах

Билеты

Категория	Цена	Доступность
Very Early Bird (1–30 апр)	299 CHF	Макс. 100 билетов
Early Bird	399 CHF	Макс. 100 билетов
Обычный	449 CHF	До распродажи

Спикеры и расписание ещё не объявлены — приём заявок открыт на Sessionize.

Организаторы

Ссылки

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 оценили общее впечатление как хорошее, очень хорошее или отличное.

Azure DevOps MCP Сервер Апрельское Обновление: WIQL-Запросы, PAT Аутентификация и Экспериментальные MCP Apps

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

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

Azure DevOps MCP Сервер продолжает совершенствоваться. Апрельское обновление Дэна Хеллема охватывает оба сервера.

Поддержка WIQL-Запросов

Новый инструмент wit_query_by_wiql позволяет запускать Work Item Query Language запросы прямо из MCP-клиента.

Personal Access Tokens

PAT аутентификация на локальном сервере — важна для интеграционных сценариев без интерактивной аутентификации.

Аннотации MCP

Метаданные для read-only, destructive и open-world инструментов — основа надёжности агентов.

Консолидация Wiki-Инструментов

5 отдельных wiki-инструментов → 2 более мощных. Меньше инструментов = лучше производительность LLM.

Экспериментально: MCP Apps

Упакованные рабочие процессы в среде MCP-сервера. Направление правильное.

Оригинальный пост Дэна Хеллема: Azure DevOps MCP Server April Update.

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.

.NET 10 поставляется с Ubuntu 26.04 LTS — Что Нового

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

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

День Ubuntu LTS. Ubuntu 26.04 (Resolute Raccoon) вышел сегодня вместе с .NET 10.

LTS на LTS — пять лет поддержки ОС, совпадающих с окном долгосрочной поддержки .NET 10.

Установить .NET 10 двумя командами

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET является одним из официально поддерживаемых тулчейнов на Ubuntu.

Контейнеры: обновить `-noble` на `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

Все существующие варианты образов — включая Chiseled — доступны.

Native AOT: запуск за 3мс, бинарник 1,4МБ

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# нативный бинарник 1,4МБ, запуск за 3мс

Для cloud-native рабочих нагрузок, где время холодного запуска важно — Functions, контейнеры, serverless — реальная игра меняется.

Нужен .NET 8 или 9?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

Полный пост содержит больше деталей о cgroup v2, пост-квантовой криптографии и Linux 7.0.

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).

CodeAct в Agent Framework: Как сократить задержку агента вдвое

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

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

В каждом проекте с агентами наступает момент, когда смотришь на трассировку и думаешь: «Почему это так долго работает?» Модель в порядке. Инструменты работают. Но для получения результата, который можно вычислить за один раз, происходит семь туров обмена данными.

Именно эту проблему решает CodeAct — и команда Agent Framework только что выпустила альфа-поддержку через новый пакет agent-framework-hyperlight.

Что такое CodeAct?

Паттерн CodeAct элегантно прост: вместо того чтобы давать модели список инструментов для поочерёдного вызова, вы даёте ей единственный инструмент execute_code и позволяете выразить весь план как короткую программу на Python.

Подход	Время	Токены
Традиционный	27,81с	6 890
CodeAct	13,23с	2 489
Улучшение	52,4%	63,9%

Безопасность: Микро-VM Hyperlight

Пакет agent-framework-hyperlight использует микро-VM Hyperlight. Каждый вызов execute_code получает собственную свежесозданную микро-VM. Запуск измеряется в миллисекундах. Изоляция практически бесплатна.

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

Минимальная настройка

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Когда использовать CodeAct (и когда не стоит)

Используйте CodeAct, когда:

Задача включает много небольших вызовов инструментов (поиск, объединение, вычисления)
Важны задержка и стоимость токенов
Нужна надёжная изоляция для кода, генерируемого моделью

Оставайтесь на традиционном вызове инструментов, когда:

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

Попробуйте сейчас

pip install agent-framework-hyperlight --pre

Читайте полную статью в блоге Agent Framework для углублённого изучения.

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: "МойАгент");

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

VS Code 1.118: Copilot CLI получает имена сессий, значки модели и TypeScript 7.0 Nightly

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

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

Visual Studio Code 1.118 — небольшой сфокусированный релиз, в основном с улучшениями Copilot CLI.

Copilot CLI: сессии получают настоящие имена

API заголовков сессий SDK Copilot CLI теперь используются как источник истины для имён сессий. Вместо автоматически сгенерированных меток сессии показывают реальное имя из SDK.

Быстрое переключение между сессиями

В приложение Agents теперь добавлены Ctrl+1, Ctrl+2 и т.д. для быстрого переключения между сессиями.

Значки модели в чате

Ответы Copilot CLI в панели чата теперь показывают значок модели — можно с первого взгляда понять, какая модель обработала каждый запрос.

Автоматический выбор модели в Copilot CLI

Функция автоматического выбора модели теперь работает и в агенте Copilot CLI.

Подключение TypeScript 7.0 Nightly

Теперь можно включить тестирование ночных сборок TypeScript 7.0 прямо из настроек VS Code. TypeScript 7.0 — значительный релиз (бета вышла несколько дней назад).

Смотрите полные примечания к релизу.

Где Ваш Агент Помнит Вещи? Практическое Руководство по Хранению Истории Чата

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

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

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

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

Два основных паттерна

Управляемое сервисом: ИИ-сервис хранит состояние разговора. Ваше приложение хранит ссылку, и сервис автоматически включает нужную историю в каждый запрос.

Управляемое клиентом: ваше приложение поддерживает полную историю и отправляет нужные сообщения с каждым запросом. Сервис не имеет состояния. Вы контролируете всё.

Как Agent Framework это абстрагирует

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Меня зовут Алиса.", session);
var second = await agent.RunAsync("Как меня зовут?", session);

session = agent.create_session()
first = await agent.run("Меня зовут Алиса.", session=session)
second = await agent.run("Как меня зовут?", session=session)

Быстрый справочник по поставщикам

Поставщик	Хранилище	Модель	Компрессия
OpenAI/Azure Chat Completions	Клиент	N/A	Вы
Foundry Agent Service	Сервис	Линейная	Сервис
Responses API (по умолчанию)	Сервис	Ветвящаяся	Сервис
Anthropic Claude, Ollama	Клиент	N/A	Вы

Как выбрать

Нужны ветвление или «отмена»? → Responses API, управляемый сервисом
Нужен полный контроль над данными? → Управляемое клиентом с DB-бэкендом
Простой чатбот? → Линейное, управляемое сервисом, — достаточно

Читайте полный пост для полного дерева решений.

Aspire 13.2: Поддержка Bun, Улучшенные Контейнеры и Меньше Трений при Отладке

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

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

Если вы строите .NET-бэкенды с JavaScript-фронтендами в Aspire, 13.2 — это обновление, которое тихо делает ваш день лучше.

Bun теперь первоклассный

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

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

Yarn стал надёжнее

Пользователи Yarn получают меньше загадочных сбоев с withYarn() и addViteApp().

Улучшения контейнеров

ImagePullPolicy.Never для использования локального образа без обращения к registry. PostgreSQL 18+ с томами данных теперь работает корректно.

Улучшения отладки

DebuggerDisplayAttribute на основных типах, лучшие сообщения об ошибках для WaitFor, BeforeResourceStartedEvent срабатывает в нужный момент.

Оригинальный пост Дэвида Пайна: Aspire 13.2: Bun Support and Container Enhancements.

68 Минут в День на Переобъяснение Кода? Есть Решение

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

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

Знаете тот момент, когда сессия Copilot достигает /compact и агент полностью забывает, над чем вы работали? Следующие пять минут вы тратите на повторное объяснение структуры файлов, неудачного теста, трёх подходов, которые уже пробовали. Затем это происходит снова.

Деси Вильянуэва измерил: 68 минут в день — только на переориентацию. Не на написание кода, не на ревью PR. Просто на то, чтобы снова ввести ИИ в курс дела.

Ложь о Контекстном Окне

Реальная математика: из 200K токенов, MCP инструменты съедают ~65K, файлы инструкций ~10K. В итоге ~125K до того, как вы напечатали хоть слово. LLM деградируют при 60% заполнении — реальный лимит 45K токенов.

Налог на Компактизацию

Жестокая часть: память уже существует. Copilot CLI записывает каждую сессию в локальную SQLite базу по адресу ~/.copilot/session-store.db. Агент просто не может её прочитать.

auto-memory: Слой Отзыва, Не Система Памяти

pip install auto-memory

~1900 строк Python. Нулевые зависимости. Устанавливается за 30 секунд.

Вместо того чтобы заполнять контекст результатами grep, вы даёте агенту хирургический доступ к тому, что реально важно — 50 токенов вместо 10 000.

Заключение

Context rot — это реальное архитектурное ограничение. auto-memory обходит его, давая агенту дешёвый и точный механизм отзыва.

Посмотрите: auto-memory на GitHub. Оригинальный пост Деси Вильянуэвы: I Wasted 68 Minutes a Day.

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

Windows App Dev CLI v0.3: F5 из терминала и UI-автоматизация для агентов

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

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

Опыт F5 в Visual Studio великолепен. Но открывать VS только для запуска и отладки упакованного Windows-приложения — это лишнее, особенно в CI-пайплайне, автоматизированном воркфлоу или когда AI-агент прогоняет тесты.

Windows App Development CLI v0.3 только что вышел и решает это напрямую с двумя ключевыми функциями: winapp run и winapp ui.

winapp run: F5 из любого места

winapp run принимает папку распакованного приложения и манифест, выполняя всё то, что VS делает при отладочном запуске: регистрирует loose-пакет, запускает приложение и сохраняет LocalState между повторными деплоями.

# Собери приложение, затем запусти как упакованное
winapp run ./bin/Debug

Работает для WinUI, WPF, WinForms, Console, Avalonia и других. Режимы рассчитаны как на разработчиков, так и на автоматизированные воркфлоу:

--detach: Запускает и немедленно возвращает управление терминалу. Идеально для CI.
--unregister-on-exit: Удаляет зарегистрированный пакет при закрытии приложения.
--debug-output: Захватывает сообщения OutputDebugString и исключения в реальном времени.

Новый NuGet-пакет: dotnet run для упакованных приложений

Для .NET-разработчиков появился новый NuGet-пакет: Microsoft.Windows.SDK.BuildTools.WinApp. После установки dotnet run берёт на себя весь inner loop: сборка, подготовка loose-layout-пакета, регистрация в Windows и запуск — всё в один шаг.

winapp init
# или
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI-автоматизация из командной строки

Это функция, открывающая агентные сценарии. winapp ui предоставляет полный доступ UI Automation к любому запущенному Windows-приложению — WPF, WinForms, Win32, Electron, WinUI3 — прямо из терминала.

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

Перечислить все окна верхнего уровня
Обходить полное дерево UI Automation любого окна
Искать элементы по имени, типу или ID автоматизации
Кликать, вызывать и устанавливать значения
Делать снимки экрана
Ждать появления элементов — идеально для синхронизации тестов

Сочетание winapp ui с winapp run создаёт полный воркфлоу build → запуск → проверка из терминала. Агент может запустить приложение, проверить состояние UI, программно взаимодействовать с ним и валидировать результат.

Другие нововведения

winapp unregister: Удаляет sideloaded-пакет после завершения работы.
winapp manifest add-alias: Добавляет алиас для запуска приложения по имени из терминала.
Автодополнение: Одна команда для настройки дополнения в PowerShell.

Как получить

winget install Microsoft.WinAppCli
# или
npm install -g @microsoft/winappcli

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

Хуки azd на Python, TypeScript и .NET: прощай, shell-скрипты

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

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

Если вы когда-нибудь вели проект полностью на .NET и всё равно писали Bash-скрипты для хуков azd — вы знаете эту боль. Зачем переходить к синтаксису shell в шаге pre-provisioning, когда весь остальной проект написан на C#?

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

Что такое хуки

Хуки — это скрипты, выполняемые в ключевых точках жизненного цикла azd — до провизионинга, после деплоя и не только. Они определяются в azure.yaml и позволяют внедрять пользовательскую логику без изменений в CLI.

Раньше поддерживались только Bash и PowerShell. Теперь можно использовать Python, JavaScript, TypeScript или .NET — остальное azd обрабатывает автоматически.

Как работает определение языка

Просто укажите хук на файл, и azd определит язык по расширению:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Дополнительная конфигурация не нужна. При неоднозначном расширении можно явно указать kind: python (или нужный язык).

Важные детали по языкам

Python

Разместите requirements.txt или pyproject.toml рядом со скриптом (или в родительской директории). azd автоматически создаёт виртуальное окружение, устанавливает зависимости и запускает скрипт.

JavaScript и TypeScript

Тот же принцип — package.json рядом со скриптом, и azd сначала выполнит npm install. Для TypeScript используется npx tsx без этапа компиляции и без tsconfig.json.

.NET

Два режима:

Режим проекта: если рядом со скриптом есть .csproj, azd автоматически выполнит dotnet restore и dotnet build.
Single-file режим: на .NET 10+ автономные .cs-файлы запускаются напрямую через dotnet run script.cs. Файл проекта не нужен.

Конфигурация по исполнителю

Каждый язык поддерживает опциональный блок config:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

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

Хуки были последним местом в проекте на базе azd, где приходилось менять язык. Теперь весь деплой-пайплайн — от кода приложения до lifecycle-хуков — может жить в одном языке. Можно переиспользовать существующие .NET-утилиты, ссылаться на общие библиотеки и забыть про поддержку shell-скриптов.

Итог

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

Обновитесь Прямо Сейчас: .NET 10.0.7 Внеплановое Обновление Безопасности (ASP.NET Core Data Protection)

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

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

Это обновление не является опциональным. Если ваше приложение использует Microsoft.AspNetCore.DataProtection, необходимо обновиться до 10.0.7.

Что Произошло

После Patch Tuesday релиза .NET 10.0.6 пользователи начали сообщать об ошибках дешифрования. В ходе расследования была обнаружена уязвимость CVE-2026-40372: тег HMAC-валидации вычислялся над неправильными байтами, что могло привести к повышению привилегий.

Как Исправить

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

Затем пересоберите и переразверните приложение.

Оригинальное объявление Рахула Бхандари: .NET 10.0.7 Out-of-Band Security Update.

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, которая приносит реальную ценность.

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

Написание нативных аддонов Node.js на C# с .NET Native AOT

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

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

Вот сценарий, который мне нравится: команда, работающая над инструментами .NET, имела нативные аддоны Node.js, написанные на C++ и скомпилированные через node-gyp. Работало. Но для сборки пакета, который никто в команде не трогал напрямую, на каждой машине разработчика требовался Python — причём старая версия Python.

Поэтому они задали вполне разумный вопрос: SDK .NET уже установлен — зачем вообще писать C++?

Ответом стал Native AOT, и результат получился действительно элегантным.

Основная идея

Нативный аддон Node.js — это разделяемая библиотека (.dll на Windows, .so на Linux, .dylib на macOS), которую Node.js может загрузить во время выполнения. Интерфейс называется N-API — стабильный, ABI-совместимый C API. N-API не заботится о том, каким языком создана библиотека — только о том, что она экспортирует нужные символы.

.NET Native AOT может создать именно это. Он компилирует C#-код ahead-of-time в нативную разделяемую библиотеку с произвольными точками входа. В этом весь трюк.

Настройка проекта

Файл проекта минимален:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot указывает SDK создать разделяемую библиотеку при dotnet publish. AllowUnsafeBlocks нужен для N-API interop с указателями на функции и фиксированными буферами.

Экспорт точки входа

Node.js ожидает, что библиотека экспортирует napi_register_module_v1. В C# это делает [UnmanagedCallersOnly]:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

Несколько моментов стоит отметить: nint — целое число нативного размера, управляемый эквивалент intptr_t. Суффикс u8 создаёт ReadOnlySpan<byte> с UTF-8 строковым литералом, передаваемым прямо в N-API без выделений памяти под кодировку. А [UnmanagedCallersOnly] экспортирует метод с точно тем именем точки входа, которое ищет Node.js.

Разрешение N-API через хост-процесс

Функции N-API экспортирует сам node.exe, а не отдельная библиотека. Поэтому вместо линковки против чего-либо, они разрешаются против запущенного процесса при старте:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

После этого объявления P/Invoke с [LibraryImport] и сгенерированным маршалингом работают корректно.

Реальная экспортируемая функция

Вот ридер реестра, который они написали:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Важное замечание про try/catch: необработанное исключение в методе [UnmanagedCallersOnly] обрушит хост-процесс. Всегда перехватывайте и передавайте в JavaScript через ThrowError.

Вызов из TypeScript

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#, без Python, без C++.

Что получили

Мгновенный выигрыш — опыт контрибьюторов: никакой конкретной версии Python, yarn install работает только с Node.js и .NET SDK. CI-пайплайны также упростились. Производительность сопоставима с реализацией на C++.

Итоги

Команда C# Dev Kit заменила сложность Python/C++ на чистый C#-код, который каждый в команде уже умеет писать и отлаживать. Полный разбор со всеми вспомогательными методами маршалинга строк найдёте в оригинальной статье в блоге .NET.

VS Code 1.117: Агенты получают собственные ветки Git, и я полностью за

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

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

Грань между «ИИ-ассистентом» и «ИИ-тиммейтом» продолжает стираться. VS Code 1.117 только что вышел, и полные заметки о релизе насыщены, но суть ясна: агенты становятся полноценными участниками вашего рабочего процесса разработки.

Вот что действительно важно.

Режим Autopilot наконец запоминает ваши настройки

Раньше приходилось заново включать Autopilot каждый раз при запуске новой сессии. Раздражало. Теперь режим разрешений сохраняется между сессиями, и вы можете настроить значение по умолчанию.

Agent Host поддерживает три конфигурации сессии:

Default — инструменты запрашивают подтверждение перед запуском
Bypass — автоматически одобряет всё
Autopilot — полностью автономный, сам отвечает на свои вопросы и продолжает работу

Если вы создаёте новый .NET-проект с миграциями, Docker и CI — установите Autopilot один раз и забудьте. Эта настройка сохранится.

Worktree и git-изоляция для сессий агентов

Это главное. Сессии агентов теперь поддерживают полную изоляцию worktree и git. Это значит, что когда агент работает над задачей, он получает собственную ветку и рабочую директорию. Ваша основная ветка остаётся нетронутой.

Ещё лучше — Copilot CLI генерирует осмысленные имена веток для этих worktree-сессий. Никаких больше agent-session-abc123. Вы получаете название, которое действительно описывает, чем занимается агент.

Для .NET-разработчиков, управляющих несколькими feature-ветками или исправляющих баги, пока длительная задача скаффолдинга выполняется, это кардинально меняет ситуацию. Можно поручить агенту создавать API-контроллеры в одном worktree, пока вы отлаживаете проблему в сервисном слое в другом. Никаких конфликтов. Никакого стеширования. Никакого хаоса.

Субагенты и команды агентов

Agent Host Protocol теперь поддерживает субагентов. Агент может запускать других агентов для обработки частей задачи. Считайте это делегированием — ваш главный агент координирует, а специализированные агенты занимаются отдельными частями.

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

Вывод терминала автоматически включается, когда агенты отправляют ввод

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

Если вы когда-нибудь наблюдали, как агент запускает dotnet build, терпит неудачу, а потом делает ещё один round-trip, чтобы увидеть ошибку — это трение исчезло. Он видит вывод мгновенно и реагирует.

Приложение Agents на macOS обновляется автоматически

Автономное приложение Agents на macOS теперь обновляется самостоятельно. Больше не нужно вручную скачивать новые версии. Оно просто остаётся актуальным.

Мелочи, которые стоит знать

Подсказки package.json теперь показывают и установленную версию, и последнюю доступную. Полезно, если вы управляете npm-инструментами наряду с .NET-проектами.
Изображения в комментариях JSDoc корректно отображаются в подсказках и автодополнении.
Сессии Copilot CLI теперь показывают, были ли они созданы в VS Code или извне — удобно, когда переключаетесь между терминалами.
Copilot CLI, Claude Code и Gemini CLI распознаются как типы оболочек. Редактор знает, что вы запускаете.

Итог

VS Code 1.117 — это не броский набор фич. Это инфраструктура. Изоляция worktree, постоянные разрешения, протоколы субагентов — это строительные блоки для рабочего процесса, в котором агенты выполняют реальные параллельные задачи, не затрагивая ваш код.

Если вы разрабатываете на .NET и ещё не погрузились в агентный рабочий процесс, честно говоря, сейчас самое время начать.

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, начните относиться к своему облачному счёту так же, как к своему коду — регулярно ревьюйте, рефакторите, когда становится беспорядочно, и никогда не деплойте, не понимая, во сколько это обойдётся.

Docker Sandbox позволяет агентам Copilot рефакторить ваш код без риска для машины

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

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

Если вы использовали агентный режим Copilot для чего-то большего, чем мелкие правки, вы знаете эту боль. Каждая запись файла, каждая команда в терминале — ещё один запрос на разрешение. А теперь представьте это на 50 проектах. Совсем не весело.

Команда Azure опубликовала пост о Docker Sandbox для агентов GitHub Copilot, и, честно говоря, это одно из самых практичных улучшений в агентном инструментарии, которое я видел. Система использует микро-ВМ, чтобы дать Copilot полностью изолированную среду, где он может делать всё что угодно — устанавливать пакеты, запускать сборки, выполнять тесты — не затрагивая вашу хост-систему.

Что Docker Sandbox реально даёт

Основная идея проста: запустить легковесную микро-ВМ с полноценным окружением Linux, синхронизировать в неё ваше рабочее пространство и позволить агенту Copilot свободно работать внутри. Когда он закончит, изменения синхронизируются обратно.

Вот что делает это чем-то большим, чем просто «запустить что-то в контейнере»:

Двусторонняя синхронизация рабочего пространства с сохранением абсолютных путей. Структура вашего проекта выглядит идентично внутри песочницы. Никаких ошибок сборки из-за путей.
Приватный Docker-демон работает внутри микро-ВМ. Агент может собирать и запускать контейнеры, не монтируя Docker-сокет вашего хоста. Это серьёзное преимущество для безопасности.
HTTP/HTTPS-фильтрующие прокси контролируют, к чему агент может обращаться в сети. Вы решаете, какие реестры и эндпоинты разрешены. Атаки на цепочку поставок через вредоносный npm install внутри песочницы? Заблокированы.
Режим YOLO — да, именно так они его называют. Агент работает без запросов на разрешения, потому что буквально не может повредить ваш хост. Каждое деструктивное действие изолировано.

Почему разработчикам .NET стоит обратить внимание

Подумайте о работе по модернизации, с которой сейчас сталкивается так много команд. У вас есть решение на .NET Framework с 30 проектами, и его нужно перенести на .NET 9. Это сотни изменений в файлах — файлы проектов, обновления пространств имён, замена API, миграция NuGet.

С Docker Sandbox вы можете направить агента Copilot на проект, позволить ему свободно рефакторить внутри микро-ВМ, запустить dotnet build и dotnet test для валидации и принять только те изменения, которые реально работают. Никакого риска, что он случайно разрушит вашу локальную среду разработки во время экспериментов.

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

Вопрос безопасности имеет значение

Вот что большинство людей упускает: когда вы позволяете ИИ-агенту выполнять произвольные команды, вы доверяете ему всю вашу машину. Docker Sandbox переворачивает эту модель. Агент получает полную автономию внутри одноразовой среды. Сетевой прокси гарантирует, что он может загружать только из одобренных источников. Ваша хостовая файловая система, Docker-демон и учётные данные остаются нетронутыми.

Для команд с требованиями комплаенса — а это большинство корпоративных .NET-компаний — это разница между «мы не можем использовать агентный ИИ» и «мы можем внедрить его безопасно».

Итог

Docker Sandbox решает фундаментальное противоречие агентного программирования: агентам нужна свобода, чтобы быть полезными, но свобода на вашей хост-машине опасна. Микро-ВМ дают вам и то, и другое. Если вы планируете масштабный рефакторинг или модернизацию .NET, стоит настроить это прямо сейчас. Сочетание интеллекта Copilot в работе с кодом и безопасной среды выполнения — это именно то, чего ждали продакшн-команды.

Хватит нянчить терминал: отсоединённый режим Aspire меняет рабочий процесс

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

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

Каждый раз, когда вы запускаете Aspire AppHost, ваш терминал пропадает. Заблокирован. Занят, пока вы не нажмёте Ctrl+C. Нужно быстро выполнить команду? Откройте ещё одну вкладку. Хотите проверить логи? Ещё одна вкладка. Мелкое неудобство, которое быстро накапливается.

Aspire 13.2 решает эту проблему. James Newton-King описал все подробности, и, честно говоря, это одна из тех фич, которая сразу меняет подход к работе.

Отсоединённый режим: одна команда — терминал свободен

aspire start

Это сокращение для aspire run --detach. Ваш AppHost запускается в фоне, и терминал сразу возвращается к вам. Никаких лишних вкладок. Никаких мультиплексоров терминала. Просто ваш промпт, готовый к работе.

Управление запущенными процессами

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

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Это превращает Aspire CLI в полноценный менеджер процессов. Вы можете запускать несколько AppHost, проверять их статус, отслеживать логи и останавливать их — всё из одной сессии терминала.

Сочетание с изолированным режимом

Отсоединённый режим естественно сочетается с изолированным. Хотите запустить два экземпляра одного проекта в фоне без конфликтов портов?

aspire start --isolated
aspire start --isolated

Каждый получает случайные порты, отдельные секреты и собственный жизненный цикл. Используйте aspire ps, чтобы увидеть оба, aspire stop, чтобы остановить ненужный.

Почему это важно для агентов кода

Вот тут становится по-настоящему интересно. Агент кода, работающий в вашем терминале, теперь может:

Запустить приложение с помощью aspire start
Запросить его состояние через aspire describe
Проверить логи через aspire logs для диагностики проблем
Остановить его командой aspire stop по завершении

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

Команда Aspire серьёзно вложилась в это. Запуск aspire agent init настраивает файл навыков Aspire, который обучает агентов этим командам. Таким образом, инструменты вроде агента кода Copilot могут управлять вашими рабочими нагрузками Aspire из коробки.

Подводя итог

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

Прочитайте полный пост для всех подробностей и установите Aspire 13.2 командой aspire update --self.

Инструменты 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. И честно говоря, чем меньше переключений между вкладками, тем лучше.

Кластеризация пинов наконец появилась в .NET MAUI Maps — Одно свойство, ноль проблем

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

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

Знаете тот момент, когда загружаешь карту с сотней пинов и всё превращается в нечитаемое пятно? Да, именно так работали .NET MAUI Maps до сих пор. Больше нет.

David Ortinau только что объявил, что .NET MAUI 11 Preview 3 поставляется с кластеризацией пинов из коробки на Android и iOS/Mac Catalyst. И лучшая часть — включить её невероятно просто.

Одно свойство, чтобы править всеми

<maps:Map IsClusteringEnabled="True" />

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

Независимые группы кластеризации

Вот тут становится интересно. Не все пины должны группироваться вместе. Кофейни и парки — это разные вещи, и ваша карта должна это знать.

Свойство ClusteringIdentifier позволяет разделять пины на независимые группы:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Пины с одинаковым идентификатором кластеризуются вместе. Разные идентификаторы формируют независимые кластеры, даже если пины расположены рядом. Нет идентификатора? Группа по умолчанию. Чисто и предсказуемо.

Обработка нажатий на кластер

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

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Аргументы события предоставляют Pins (пины в кластере), Location (географический центр) и Handled (установите в true, если хотите переопределить стандартное поведение масштабирования). Просто, практично, именно то, что ожидаешь.

Детали платформ, которые стоит знать

На Android кластеризация использует собственный алгоритм на основе сетки, который пересчитывается при изменении масштаба — без внешних зависимостей. На iOS и Mac Catalyst используется нативная поддержка MKClusterAnnotation из MapKit, что означает плавные, нативные для платформы анимации.

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

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

Кластеризация пинов была одной из самых запрашиваемых функций в .NET MAUI (issue #11811), и неспроста. Каждое приложение, показывающее местоположения на карте — отслеживание доставки, поиск магазинов, недвижимость — нуждается в этом. Раньше приходилось реализовывать самостоятельно или подключать стороннюю библиотеку. Теперь это встроено.

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

Начинаем

Установите .NET 11 Preview 3 и обновите рабочую нагрузку .NET MAUI. Пример Maps включает новую страницу Clustering, с которой можно поэкспериментировать прямо сейчас.

Создайте что-нибудь с этим — и дайте вашим картам наконец вздохнуть.

.NET Апрель 2026 Servicing — Патчи безопасности, которые стоит применить сегодня

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

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

Сервисные обновления за апрель 2026 для .NET и .NET Framework вышли, и на этот раз в них есть исправления безопасности, которые стоит применить как можно скорее. Исправлено шесть CVE, включая две уязвимости удалённого выполнения кода (RCE).

Что исправлено

Краткая сводка:

CVE	Тип	Затрагивает
CVE-2026-26171	Обход функций безопасности	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Удалённое выполнение кода	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Удалённое выполнение кода	.NET 10, 9, 8
CVE-2026-32203	Отказ в обслуживании	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Отказ в обслуживании	.NET Framework 3.0–4.8.1
CVE-2026-32226	Отказ в обслуживании	.NET Framework 2.0–4.8.1

Две CVE с RCE (CVE-2026-32178 и CVE-2026-33116) затрагивают самый широкий спектр версий .NET и должны быть приоритетом.

Обновлённые версии

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Все доступны через обычные каналы — dotnet.microsoft.com, образы контейнеров на MCR и менеджеры пакетов Linux.

Что делать

Обновите свои проекты и пайплайны CI/CD до последних версий с патчами. Если вы используете контейнеры, загрузите последние образы. Если вы на .NET Framework, проверьте примечания к выпуску .NET Framework для соответствующих патчей.

Для тех, кто использует .NET 10 в продакшене (это текущий релиз), обновление до 10.0.6 обязательно. То же касается .NET 9.0.15 и .NET 8.0.26, если вы на этих LTS-версиях. Две уязвимости RCE — это не то, что можно откладывать.

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 DevOps Server Патч Апрель 2026 — Исправление Завершения PR и Обновления Безопасности

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

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

Быстрое уведомление для команд, использующих самостоятельно размещённый Azure DevOps Server: Microsoft выпустила Патч 3 за апрель 2026 с тремя целевыми исправлениями.

Что исправлено

Сбои завершения pull request — исключение нулевой ссылки при автоматическом завершении рабочих элементов могло приводить к сбою слияния PR. Если вы сталкивались с случайными ошибками завершения PR, вероятно, это была причина
Валидация перенаправления при выходе — улучшена валидация при выходе из системы для предотвращения потенциально вредоносных перенаправлений. Это исправление безопасности, которое стоит применить как можно скорее
PAT-подключения к GitHub Enterprise Server — создание подключений с помощью Personal Access Token к GitHub Enterprise Server было сломано, теперь восстановлено

Как обновить

Скачайте Патч 3 и запустите установщик. Чтобы проверить, что патч применён:

<patch-installer>.exe CheckInstall

Если вы используете Azure DevOps Server на собственных серверах, Microsoft настоятельно рекомендует поддерживать актуальную версию патчей как для безопасности, так и для надёжности. Ознакомьтесь с примечаниями к выпуску для получения полной информации.

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” — вот он.

.NET Aspire 13.2 хочет стать лучшим другом вашего ИИ-агента

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

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

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

Команда Aspire только что опубликовала очень продуманный пост именно об этой проблеме, и их ответ убедителен: Aspire 13.2 спроектирован не только для людей, но и для ИИ-агентов.

Проблема реальна

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

Мы нагружаем их Markdown-инструкциями, кастомными навыками и промптами, чтобы направить, но они непредсказуемы, не компилируются и стоят токенов даже для парсинга. Команда Aspire попала в точку с ключевым инсайтом: агентам нужны компиляторы и структурированные API, а не больше Markdown.

Aspire как инфраструктура для агентов

Вот что Aspire 13.2 приносит для агентной разработки:

Весь ваш стек в типизированном коде. AppHost определяет полную топологию — API, фронтенд, базу данных, кэш — в компилируемом TypeScript или C#:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

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

Одна команда, чтобы править ими всеми. Вместо того чтобы агенты жонглировали docker compose up, npm run dev и скриптами запуска баз данных, всё сводится к aspire start. Все ресурсы запускаются в правильном порядке, на правильных портах, с правильной конфигурацией. Долгоживущие процессы тоже не вешают агента — Aspire управляет ими.

Изолированный режим для параллельных агентов. С --isolated каждый запуск Aspire получает собственные случайные порты и отдельные пользовательские секреты. Несколько агентов работают в git worktrees? Они не столкнутся. Это огромное преимущество для инструментов вроде фоновых агентов VS Code, которые создают параллельные среды.

Глаза агента через телеметрию. Вот где становится действительно мощно. Aspire CLI предоставляет полные данные OpenTelemetry во время разработки — трейсы, метрики, структурированные логи. Ваш агент не просто читает вывод консоли и надеется на лучшее. Он может отследить неудавшийся запрос через сервисы, профилировать медленные эндпоинты и точно определить, где что ломается. Это наблюдаемость продакшен-уровня в цикле разработки.

Аналогия с бамперами на боулинге

Команда Aspire использует отличную аналогию: думайте об Aspire как о бамперах на дорожке боулинга для ИИ-агентов. Если агент несовершенен (а он таким и будет), бамперы не дают ему закатывать шар в жёлоб. Определение стека предотвращает неправильную конфигурацию, компилятор ловит ошибки, CLI управляет процессами, а телеметрия обеспечивает обратную связь.

Комбинируйте это с чем-то вроде Playwright CLI, и ваш агент может реально использовать ваше приложение — кликать по флоу, проверять DOM, видеть поломки в телеметрии, исправлять код, перезапускать и тестировать снова. Построить, запустить, наблюдать, исправить. Это тот автономный цикл разработки, к которому мы стремились.

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

Новичок в Aspire? Установите CLI с get.aspire.dev и следуйте руководству по началу работы.

Уже используете Aspire? Выполните aspire update --self для получения 13.2, затем наведите ваш любимый кодирующий агент на репозиторий. Вы можете удивиться, насколько дальше он продвинется с ограничителями Aspire.

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

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

Читайте полный пост от команды Aspire со всеми деталями и демо-видео.

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

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

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

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

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

Что такое MCP Apps?

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

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

Fluent API за три шага

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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-агентам безопасного доступа к базам данных. Ознакомьтесь с полным постом и документацией для начала работы.

VS Code 1.116 — Приложение Agents Получает Навигацию с Клавиатуры и Автодополнение Контекста Файлов

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

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

VS Code 1.116 — это апрельский релиз 2026 года, и хотя он легче некоторых недавних обновлений, изменения целенаправленны и значимы — особенно если вы ежедневно используете приложение Agents.

Вот что появилось, на основе официальных заметок о релизе.

Улучшения приложения Agents

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

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

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

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

Разрешение ссылок CSS `@import`

Приятно для фронтенд-разработчиков: VS Code теперь разрешает CSS @import-ссылки, использующие пути node_modules. Вы можете переходить через Ctrl+клик по импортам вроде @import "some-module/style.css" при использовании бандлеров. Мелочь, но убирает точку трения в CSS-рабочих процессах.

Заключение

VS Code 1.116 — это про совершенствование: сделать приложение Agents более удобным для навигации, более доступным и более дружелюбным к клавиатуре. Если вы проводите значительное время в приложении Agents (а я подозреваю, что многие из нас так и делают), эти изменения накапливаются.

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

Агентная платформенная инженерия становится реальностью — 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 и видео-демонстраций.

Изолированный режим Aspire устраняет кошмар конфликтов портов при параллельной разработке

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

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

Если вы когда-нибудь пытались запустить два экземпляра одного проекта одновременно, вы знаете эту боль. Порт 8080 уже используется. Порт 17370 занят. Убить что-то, перезапустить, жонглировать переменными окружения — настоящий убийца продуктивности.

Эта проблема не улучшается, а ухудшается. ИИ-агенты создают git worktrees для независимой работы. Фоновые агенты поднимают отдельные среды. Разработчики дважды клонируют один репозиторий для feature-веток. Каждый из этих сценариев упирается в одну и ту же стену: два экземпляра одного приложения борются за одни и те же порты.

Aspire 13.2 решает это одним флагом. James Newton-King из команды Aspire описал все детали, и это одна из тех фич «почему у нас этого не было раньше».

Решение: `--isolated`

aspire run --isolated

Вот и всё. Каждый запуск получает:

Случайные порты — больше никаких коллизий между экземплярами
Изолированные пользовательские секреты — строки подключения и API-ключи остаются раздельными для каждого экземпляра

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

Реальные сценарии, где это сияет

Множественные checkout. У вас feature-ветка в одной директории и bugfix в другой:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Оба работают без конфликтов. Дашборд показывает, что где запущено.

Фоновые агенты в VS Code. Когда фоновый агент Copilot Chat создаёт git worktree для независимой работы с вашим кодом, ему может понадобиться запустить ваш Aspire AppHost. Без --isolated это конфликт портов с основным worktree. С ним оба экземпляра просто работают.

Навык Aspire, поставляемый с aspire agent init, автоматически инструктирует агентов использовать --isolated при работе в worktrees. Так что фоновый агент Copilot должен справляться с этим из коробки.

Интеграционные тесты параллельно с разработкой. Нужно запускать тесты против работающего AppHost, продолжая разрабатывать фичи? Изолированный режим даёт каждому контексту собственные порты и конфигурацию.

Как это работает под капотом

Когда вы передаёте --isolated, CLI генерирует уникальный ID экземпляра для запуска. Это управляет двумя поведениями:

Рандомизация портов — вместо привязки к предсказуемым портам, определённым в конфигурации AppHost, изолированный режим выбирает случайные доступные порты для всего — дашборда, эндпоинтов сервисов, всего. Service discovery автоматически подстраивается, чтобы сервисы находили друг друга независимо от назначенных портов.
Изоляция секретов — каждый изолированный запуск получает собственное хранилище пользовательских секретов, привязанное к ID экземпляра. Строки подключения и API-ключи одного запуска не утекают в другой.

Ваш код не нуждается в изменениях. Service discovery Aspire разрешает эндпоинты во время выполнения, так что всё подключается правильно независимо от назначения портов.

Когда использовать

Используйте --isolated при запуске нескольких экземпляров одного AppHost одновременно — будь то параллельная разработка, автоматизированные тесты, ИИ-агенты или git worktrees. Для разработки с единственным экземпляром, где вы предпочитаете предсказуемые порты, обычный aspire run по-прежнему отлично работает.

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

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

Прочитайте полный пост для всех технических деталей и попробуйте с aspire update --self для получения 13.2.

Оценка модернизации 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, чтобы погрузиться глубже.

Та Самая Настройка Плавающих Окон в Visual Studio, О Которой Вы Не Знали (Но Должны)

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

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

Если вы используете несколько мониторов с Visual Studio (а честно говоря, кто сейчас не использует?), вы наверняка сталкивались с раздражающей проблемой: плавающие окна инструментов исчезают при сворачивании основной IDE, они всегда остаются поверх всего остального и не отображаются отдельными кнопками в панели задач. Это работает для некоторых рабочих процессов, но для мультимониторных конфигураций — это расстраивает.

Мадс Кристенсен из команды Visual Studio поделился малоизвестной настройкой, которая полностью меняет поведение плавающих окон. Один выпадающий список. Вот и всё.

Настройка

Tools > Options > Environment > Windows > Floating Windows

Выпадающий список “These floating windows are owned by the main window” имеет три варианта:

None — полная независимость. Каждое плавающее окно получает собственную запись в панели задач и ведёт себя как обычное окно Windows.
Tool Windows (по умолчанию) — документы свободно плавают, окна инструментов привязаны к IDE.
Documents and Tool Windows — классическое поведение Visual Studio, всё привязано к главному окну.

Почему “None” — лучший выбор для мультимониторных настроек

Установите None, и внезапно все ваши плавающие окна инструментов и документов начинают вести себя как настоящие приложения Windows. Они появляются в панели задач, остаются видимыми при сворачивании основного окна Visual Studio и перестают навязчиво выходить на передний план.

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

Быстрые рекомендации

Продвинутые пользователи с несколькими мониторами: Установите None, используйте в паре с FancyZones
Иногда используете плавающие окна: Tool Windows (по умолчанию) — хороший компромисс
Традиционный рабочий процесс: Documents and Tool Windows сохраняет классическое поведение

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

Заключение

Это одна из тех настроек из серии «не могу поверить, что я этого не знал». Если плавающие окна в Visual Studio когда-либо вас раздражали, идите и измените эту настройку прямо сейчас.

Прочитайте полный пост для подробностей и скриншотов.

VS Code 1.115 — Уведомления фонового терминала, режим SSH-агента и другое

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

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

VS Code 1.115 только что вышел, и хотя это более лёгкий релиз в плане основных функций, улучшения, связанные с агентами, действительно полезны, если вы ежедневно работаете с AI-ассистентами для написания кода.

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

Фоновые терминалы общаются с агентами

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

Почему это важно? Если вы использовали режим агента Copilot для запуска команд сборки или тестовых наборов в фоне, вы знаете боль от “оно уже закончилось?” — фоновые терминалы по сути работали по принципу “запустил и забыл”. Теперь агент получает уведомление, когда ваш dotnet build или dotnet test завершается, видит вывод и может соответственно реагировать. Небольшое изменение, которое делает рабочие процессы на основе агентов значительно надёжнее.

Также появился новый инструмент send_to_terminal, позволяющий агентам отправлять команды в фоновые терминалы с подтверждением пользователя, исправляя проблему, когда run_in_terminal с таймаутом перемещал терминалы в фон и делал их доступными только для чтения.

Удалённый хостинг агентов через SSH

VS Code теперь поддерживает подключение к удалённым машинам по SSH с автоматической установкой CLI и запуском в режиме хоста агентов. Это означает, что ваши сессии AI-агентов могут напрямую работать с удалёнными окружениями — полезно для .NET-разработчиков, которые собирают и тестируют на Linux-серверах или облачных виртуальных машинах.

Отслеживание изменений в сессиях агентов

Изменения файлов, сделанные во время сессий агентов, теперь отслеживаются и восстанавливаются, с поддержкой diff, отмены/повтора и восстановления состояния. Если агент вносит изменения в ваш код и что-то идёт не так, вы можете точно увидеть, что изменилось, и откатить это. Спокойствие при том, что агенты модифицируют вашу кодовую базу.

Распознавание вкладок браузера и другие улучшения

Ещё несколько улучшений качества жизни:

Отслеживание вкладок браузера — чат теперь может отслеживать и ссылаться на вкладки браузера, открытые во время сессии, чтобы агенты могли ссылаться на веб-страницы, которые вы просматриваете
Вставка файлов в терминал — вставляйте файлы (включая изображения) в терминал с помощью Ctrl+V, перетаскивания или правого клика
Покрытие тестами в миникарте — индикаторы покрытия тестами теперь отображаются в миникарте для быстрого визуального обзора
Масштабирование щипком на Mac — встроенный браузер поддерживает жесты масштабирования щипком
Права Copilot в Сессиях — строка состояния показывает информацию об использовании в представлении Сессий
Фавиконы в Перейти к файлу — открытые веб-страницы показывают фавиконы в списке быстрого выбора

Подводя итог

VS Code 1.115 — это инкрементальный релиз, но улучшения агентов — уведомления фонового терминала, хостинг агентов через SSH и отслеживание изменений — в сумме дают заметно более гладкий опыт разработки с помощью ИИ. Если вы используете режим агента Copilot для .NET-проектов, это именно те улучшения качества жизни, которые уменьшают ежедневное трение.

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

C# 15 получает типы-объединения — и это именно то, что мы просили

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

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

Это та самая фича, которую я ждал. C# 15 вводит ключевое слово union — настоящие размеченные объединения с исчерпывающим сопоставлением с образцом, контролируемым компилятором. Если вы когда-нибудь завидовали размеченным объединениям F# или enum в Rust, вы точно знаете, почему это важно.

Билл Вагнер опубликовал подробный разбор в блоге .NET, и честно? Дизайн чистый, практичный и очень в духе C#. Давайте я покажу, что тут на самом деле есть и почему это более значимо, чем может показаться на первый взгляд.

Проблема, которую решают объединения

До C# 15 возврат «одного из нескольких возможных типов» из метода всегда был компромиссом:

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

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

Синтаксис красиво прост

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Одна строка. Pet может содержать Cat, Dog или Bird. Неявные преобразования генерируются автоматически:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

А вот и магия — компилятор обеспечивает исчерпывающее сопоставление:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

Дискард _ не нужен. Компилятор знает, что этот switch покрывает все возможные случаи. Если позже вы добавите четвёртый тип в объединение, каждое выражение switch, которое его не обрабатывает, выдаст предупреждение. Пропущенные случаи обнаруживаются на этапе сборки, а не в рантайме.

Где это становится практичным

Пример с Pet милый, но вот где объединения действительно сияют в реальном коде.

API-ответы, возвращающие разные формы

public union ApiResult<T>(T, ApiError, ValidationFailure);

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

Одно значение или коллекция

Паттерн OneOrMore<T> показывает, как объединения могут иметь тело со вспомогательными методами:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Вызывающий код передаёт удобную форму:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Композиция несвязанных типов

Это убойная фича по сравнению с традиционными иерархиями. Можно объединять типы, не имеющие ничего общего — string и Exception, int и IEnumerable<T>. Общий предок не нужен.

Пользовательские объединения для существующих библиотек

Вот умное решение в дизайне: любой класс или struct с атрибутом [Union] распознаётся как тип-объединение, если он следует базовому паттерну (публичные конструкторы для типов-случаев и свойство Value). Библиотеки вроде OneOf, которые уже предоставляют типы, похожие на объединения, могут подключить поддержку компилятора без переписывания внутренней реализации.

Для чувствительных к производительности сценариев с типами-значениями библиотеки могут реализовать паттерн доступа без boxing через методы HasValue и TryGetValue.

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

Типы-объединения — часть более широкой истории исчерпывающей проверки в C#:

Типы-объединения — исчерпывающее сопоставление по замкнутому набору типов (доступно сейчас в preview)
Закрытые иерархии — модификатор closed предотвращает создание производных классов вне определяющей сборки (предложено)
Закрытые enum — предотвращает создание значений, отличных от объявленных членов (предложено)

Вместе эти три фичи дадут C# одну из самых полных систем типобезопасного сопоставления с образцом среди всех мейнстримных языков.

Попробуйте сегодня

Типы-объединения доступны в .NET 11 Preview 2:

Установите .NET 11 Preview SDK
Укажите net11.0 в качестве целевой платформы проекта
Установите <LangVersion>preview</LangVersion>

Одно замечание: в Preview 2 вам нужно объявить UnionAttribute и IUnion в проекте, так как их ещё нет в рантайме. Возьмите RuntimePolyfill.cs из репозитория документации, или добавьте это:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Подводя итог

Типы-объединения — одна из тех фич, которые заставляют задуматься, как мы обходились без них. Исчерпывающее сопоставление, контролируемое компилятором, чистый синтаксис, поддержка дженериков и интеграция с существующим pattern matching — это всё, что мы просили, реализованное в стиле C#.

Попробуйте их в .NET 11 Preview 2, ломайте вещи и делитесь обратной связью на GitHub. Это preview, и команда C# активно слушает. Ваши граничные случаи и отзывы о дизайне повлияют на финальный релиз.

Полную языковую справку смотрите в документации по типам-объединениям и спецификации фичи.

Aspire 13.2 получает CLI для документации — и ваш ИИ-агент тоже может им пользоваться

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

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

Знаете тот момент, когда вы погружены в Aspire AppHost, подключаете интеграции, и вам нужно проверить, какие именно параметры ожидает интеграция Redis? Вы переключаетесь Alt-Tab на браузер, ищете на aspire.dev, вглядываетесь в документацию API, возвращаетесь в редактор. Контекст потерян. Поток прерван.

Aspire 13.2 только что выпустил решение этой проблемы. CLI aspire docs позволяет искать, просматривать и читать официальную документацию Aspire прямо из терминала. А поскольку за ним стоят переиспользуемые сервисы, ИИ-агенты и навыки могут использовать те же самые команды для поиска документации вместо того, чтобы галлюцинировать несуществующие API.

Проблема, которую это действительно решает

David Pine точно подмечает в оригинальном посте: ИИ-агенты были ужасны в помощи разработчикам при создании приложений на Aspire. Они рекомендовали dotnet run вместо aspire run, ссылались на learn.microsoft.com для документации, которая живёт на aspire.dev, предлагали устаревшие NuGet-пакеты, и — моё любимое — галлюцинировали API, которых не существует.

Почему? Потому что Aspire был специфичен для .NET гораздо дольше, чем является полиглотом, а LLM работают на тренировочных данных, которые предшествуют последним возможностям. Когда вы даёте ИИ-агенту возможность реально искать актуальную документацию, он перестаёт угадывать и начинает быть полезным.

Три команды, ноль вкладок браузера

CLI освежающе прост:

Показать всю документацию

aspire docs list

Возвращает каждую страницу документации, доступную на aspire.dev. Нужен машиночитаемый вывод? Добавьте --format Json.

Поиск по теме

aspire docs search "redis"

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

Чтение полной страницы (или только одного раздела)

aspire docs get redis-integration

Выводит полную страницу в формате markdown в ваш терминал. Нужен только один раздел?

aspire docs get redis-integration --section "Add Redis resource"

Хирургическая точность. Никакого прокручивания 500 строк. Только нужная часть.

Аспект ИИ-агентов

Вот где становится интересно для нас, разработчиков, работающих с ИИ-инструментами. Те же команды aspire docs работают как инструменты для ИИ-агентов — через навыки, MCP-серверы или простые CLI-обёртки.

Вместо того чтобы ваш ИИ-ассистент придумывал API Aspire на основе устаревших тренировочных данных, он может вызвать aspire docs search "postgres", найти официальную документацию по интеграции, прочитать нужную страницу и дать вам документированный подход. Актуальная документация в реальном времени — а не то, что модель запомнила шесть месяцев назад.

Архитектура за этим — намеренная. Команда Aspire создала переиспользуемые сервисы (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) вместо одноразовой интеграции. Это значит, что один и тот же поисковый движок работает для людей в терминале, ИИ-агентов в редакторе и автоматизации в CI-пайплайне.

Реальные сценарии

Быстрые справки в терминале: Вы на три файла в глубину и вам нужны параметры конфигурации Redis. Две команды, девяносто секунд, обратно к работе:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Разработка с помощью ИИ: Ваш навык VS Code оборачивает команды CLI. Вы спрашиваете «Добавь базу данных PostgreSQL в мой AppHost», и агент сначала смотрит реальную документацию, а потом отвечает. Никаких галлюцинаций.

Валидация CI/CD: Ваш пайплайн программно проверяет конфигурации AppHost по официальной документации. Вывод --format Json чисто передаётся в jq и другие инструменты.

Пользовательские базы знаний: Создаёте свои ИИ-инструменты? Направляйте структурированный JSON-вывод напрямую в свою базу знаний:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

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

Документация всегда актуальна

Это то, что я ценю больше всего. CLI не скачивает снимок — он обращается к aspire.dev с кэшированием на основе ETag. В момент обновления документации ваш CLI и любой навык, построенный на его основе, отражает это. Никаких устаревших копий, никаких моментов «но в вики было написано…».

Подводя итог

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

Если вы разрабатываете на .NET Aspire и ещё не попробовали CLI, запустите aspire docs search "ваша-тема" и почувствуйте, как это работает. Затем подумайте о том, чтобы обернуть эти команды в свои ИИ-навыки или настройки автоматизации — ваши агенты скажут вам спасибо.

Ознакомьтесь с глубоким разбором David Pine о том, как создавались инструменты документации, и с официальной справкой CLI для всех деталей.

Microsoft Agent Framework Достиг 1.0 — Вот Что Действительно Важно для .NET-Разработчиков

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

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

Если вы следили за путешествием Agent Framework с ранних дней Semantic Kernel и AutoGen, это событие значительное. Microsoft Agent Framework только что достиг версии 1.0 — готов к продакшену, стабильные API, обязательство долгосрочной поддержки. Он доступен и для .NET, и для Python, и действительно готов к реальным нагрузкам.

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

Коротко

Agent Framework 1.0 объединяет то, что раньше было Semantic Kernel и AutoGen, в единый SDK с открытым исходным кодом. Одна абстракция агента. Один движок оркестрации. Множество AI-провайдеров. Если вы метались между Semantic Kernel для корпоративных паттернов и AutoGen для исследовательских мульти-агентных рабочих процессов, можете остановиться. Теперь это единственный SDK.

Начать работу почти нечестно просто

Вот работающий агент на .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Вот и всё. Несколько строк — и у вас есть AI-агент, работающий через Azure Foundry. Эквивалент на Python столь же лаконичен. Добавляйте инструменты-функции, многоходовые диалоги и стриминг по мере необходимости — поверхность API масштабируется без странностей.

Мульти-агентная оркестрация — это серьёзно

Одиночные агенты подходят для демо, но продакшен-сценарии обычно требуют координации. Agent Framework 1.0 поставляется с проверенными в бою паттернами оркестрации прямо из Microsoft Research и AutoGen:

Последовательная — агенты обрабатывают по очереди (писатель → рецензент → редактор)
Параллельная — распределение по нескольким агентам параллельно, объединение результатов
Handoff — один агент делегирует другому на основе намерения
Групповой чат — несколько агентов обсуждают и сходятся к решению
Magentic-One — исследовательский мульти-агентный паттерн от MSR

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

Самые важные возможности

Вот мой список того, что стоит знать:

Middleware-хуки. Знаете, как ASP.NET Core имеет middleware-конвейеры? Тот же концепт, но для выполнения агентов. Перехватывайте каждый этап — добавляйте безопасность контента, логирование, политики соответствия — не трогая промпты агента. Именно так вы делаете агентов готовыми для enterprise.

Подключаемая память. История разговоров, персистентное key-value состояние, векторный поиск. Выбирайте бэкенд: Foundry Agent Service, Mem0, Redis, Neo4j или создайте свой. Память — это то, что превращает stateless-вызов LLM в агента, который действительно помнит контекст.

Декларативные YAML-агенты. Определяйте инструкции агента, инструменты, память и топологию оркестрации в версионируемых YAML-файлах. Загружайте и запускайте одним вызовом API. Это меняет правила игры для команд, которые хотят итерировать поведение агента без редеплоя кода.

Поддержка A2A и MCP. MCP (Model Context Protocol) позволяет агентам динамически обнаруживать и вызывать внешние инструменты. A2A (протокол Agent-to-Agent) обеспечивает кросс-рантайм взаимодействие — ваши .NET-агенты могут координироваться с агентами в других фреймворках. Поддержка A2A 1.0 появится в ближайшее время.

Превью-возможности, за которыми стоит следить

Некоторые возможности вышли в превью в 1.0 — функциональны, но API могут измениться:

DevUI — локальный отладчик в браузере для визуализации выполнения агента, потоков сообщений и вызовов инструментов в реальном времени. Представьте Application Insights, но для рассуждений агента.
GitHub Copilot SDK и Claude Code SDK — используйте Copilot или Claude как агентную обвязку прямо из кода оркестрации. Составляйте агента с возможностями программирования рядом с другими агентами в одном рабочем процессе.
Agent Harness — настраиваемый локальный рантайм, дающий агентам доступ к шеллу, файловой системе и циклам обмена сообщениями. Думайте о кодинг-агентах и паттернах автоматизации.
Skills — переиспользуемые пакеты доменных возможностей, дающие агентам структурированные способности из коробки.

Миграция с Semantic Kernel или AutoGen

Если у вас есть существующий код на Semantic Kernel или AutoGen, есть специальные помощники миграции, которые анализируют ваш код и генерируют пошаговые планы миграции. Руководство по миграции с Semantic Kernel и руководство по миграции с AutoGen проведут вас через всё.

Если вы были на RC-пакетах, обновление до 1.0 — это просто смена версии.

Подводя итог

Agent Framework 1.0 — это продакшен-веха, которую ждали корпоративные команды. Стабильные API, поддержка нескольких провайдеров, паттерны оркестрации, реально работающие в масштабе, и пути миграции как с Semantic Kernel, так и с AutoGen.

Фреймворк полностью открыт на GitHub, и вы можете начать прямо сейчас с dotnet add package Microsoft.Agents.AI. Посмотрите руководство по быстрому старту и примеры, чтобы попробовать на практике.

Если вы ждали сигнала «безопасно использовать в продакшене» — вот он.

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 — особенно ИИ-агенты — это обновление стоит внимания.

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

Azure DevOps наконец-то исправил Markdown-редактор, на который все жаловались

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

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

Если вы используете Azure Boards, вы наверняка сталкивались с этим: читаете описание рабочего элемента, может проверяете критерии приёмки, и случайно делаете двойной клик. Бум — вы в режиме редактирования. Вы ничего не хотели редактировать. Просто читали.

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

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

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

Когда действительно хотите редактировать, нажмите на иконку редактирования вверху поля. Закончили — явно вернитесь в режим просмотра. Просто, намеренно, предсказуемо.

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

Тред обратной связи от сообщества был длинным. Поведение двойного клика для редактирования было введено с Markdown-редактором в июле 2025, и жалобы начались почти сразу.

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

Статус развёртывания

Уже раскатывается для части пользователей и расширится на всех в ближайшие две-три недели.

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

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

Bookmark Studio добавляет слотовую навигацию и обмен закладками в Visual Studio

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

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

Закладки в Visual Studio всегда были… нормальными. Ставишь одну, переходишь к следующей, забываешь какая есть какая. Работают, но никогда не были чем-то, что назвали бы мощным.

Mads Kristensen только что выпустил Bookmark Studio — экспериментальное расширение, которое заполняет именно те пробелы, с которыми вы, вероятно, сталкивались.

Слотовая навигация

Закладки можно назначить на слоты 1–9 и перейти к ним напрямую через Alt+Shift+1 по Alt+Shift+9. Новые закладки автоматически получают следующий свободный слот.

Менеджер закладок

Новое окно инструментов показывает все закладки с фильтрацией по имени, файлу, расположению, цвету или слоту.

Организация с метками, цветами и папками

Закладки могут иметь метки, цвета и группироваться в папки. Метаданные сохраняются по solution.

Экспорт и обмен

Bookmark Studio позволяет экспортировать закладки как текст, Markdown или CSV.

Закладки, следующие за кодом

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

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

Bookmark Studio ничего не переизобретает. Берёт функцию, которая годами была «достаточной», и делает её действительно полезной. Скачайте из Visual Studio Marketplace.

Дашборд Aspire 13.2 теперь с API телеметрии — и это меняет всё

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

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

Если вы создавали распределённые приложения на .NET Aspire, вы уже знаете, что дашборд — лучшая часть всего опыта. Все ваши трейсы, логи и метрики в одном месте — без внешнего Jaeger, без настройки Seq, без моментов «дай проверю другой терминал».

Aspire 13.2 значительно всё улучшил. James Newton-King объявил об обновлении, и честно? Функции экспорта телеметрии и API сами по себе стоят обновления.

Экспорт телеметрии по-человечески

Вот сценарий, который мы все пережили: вы отлаживаете распределённую проблему, наконец воспроизводите её после двадцати минут настройки, и теперь нужно показать команде, что произошло. Раньше? Скриншоты. Копирование ID трейсов. Обычный хаос.

Aspire 13.2 добавляет диалог Управление логами и телеметрией, где можно:

Очистить всю телеметрию (полезно перед попыткой воспроизведения)
Экспортировать выбранную телеметрию в ZIP-файл в стандартном формате OTLP/JSON
Повторно импортировать этот ZIP в любой дашборд Aspire позже

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

Отдельные трейсы, спаны и логи также получили опцию «Export JSON» в контекстных меню. Нужно поделиться конкретным трейсом? Правый клик, копируете JSON, вставляете в описание PR. Готово.

API телеметрии — настоящий прорыв

Вот чему я больше всего рад. Дашборд теперь предоставляет HTTP API по пути /api/telemetry для программного запроса данных телеметрии. Доступные эндпоинты:

GET /api/telemetry/resources — список ресурсов с телеметрией
GET /api/telemetry/spans — запрос спанов с фильтрами
GET /api/telemetry/logs — запрос логов с фильтрами
GET /api/telemetry/traces — список трейсов
GET /api/telemetry/traces/{traceId} — все спаны конкретного трейса

Всё возвращается в формате OTLP JSON. Это питает новые CLI-команды aspire agent mcp и aspire otel, но реальное значение больше: теперь можно создавать инструменты, скрипты и интеграции с ИИ-агентами, которые напрямую запрашивают телеметрию вашего приложения.

Представьте ИИ-агента для кодинга, который может видеть ваши реальные распределённые трейсы во время отладки. Это уже не гипотетически — именно это делает возможным этот API.

Телеметрия GenAI становится практичной

Если вы создаёте приложения с ИИ на Semantic Kernel или Microsoft.Extensions.AI, вам понравится улучшенный визуализатор телеметрии GenAI. Aspire 13.2 добавляет:

Описания ИИ-инструментов отображаются как Markdown
Специальная кнопка GenAI на странице трейсов для быстрого доступа
Улучшенная обработка ошибок для обрезанного или нестандартного JSON GenAI
Навигация с подсветкой по клику между определениями инструментов

Пост упоминает, что VS Code Copilot chat, Copilot CLI и OpenCode поддерживают настройку OTEL_EXPORTER_OTLP_ENDPOINT. Направьте их на дашборд Aspire, и вы буквально сможете наблюдать, как ваши ИИ-агенты думают в реальном времени через телеметрию. Такой опыт отладки вы больше нигде не найдёте.

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

Aspire 13.2 превращает дашборд из «приятного UI для отладки» в «программируемую платформу наблюдаемости». Рабочий процесс экспорта/импорта сам по себе экономит реальное время при распределённой отладке, а API телеметрии открывает дверь к диагностике с помощью ИИ.

Если вы уже на Aspire — обновляйтесь. Если нет — это хороший повод попробовать aspire.dev.

Мартовское обновление Visual Studio позволяет создавать собственные агенты Copilot — и find_symbol меняет правила игры

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

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

Visual Studio только что получила самое значительное обновление Copilot. Mark Downie объявил о мартовском релизе, и заголовок — пользовательские агенты, но честно говоря, инструмент find_symbol может оказаться функцией, которая больше всего изменит ваш рабочий процесс.

Пользовательские агенты Copilot в вашем репозитории

Хотите, чтобы Copilot следовал стандартам кодирования вашей команды? Пользовательские агенты определяются как файлы .agent.md в .github/agents/. Каждый агент имеет полный доступ к workspace, пониманию кода, инструментам, вашей предпочтительной модели и MCP-соединениям.

Навыки агента: переиспользуемые наборы инструкций

Навыки автоматически подхватываются из .github/skills/ в вашем репозитории или ~/.copilot/skills/ в профиле.

find_symbol: навигация с поддержкой языка

Новый инструмент find_symbol даёт агентному режиму Copilot навигацию по символам на основе языковых сервисов. Вместо текстового поиска агент может находить все ссылки на символ и получать доступ к информации о типах и области видимости.

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

Профилирование тестов с Copilot

В контекстном меню Test Explorer появился Profile with Copilot. Profiling Agent запускает тест и автоматически анализирует производительность.

Perf Tips во время отладки

Оптимизация производительности теперь происходит прямо во время отладки. Visual Studio показывает время выполнения inline. Увидели медленную строку? Кликните Perf Tip и попросите Copilot предложить оптимизации.

Исправление уязвимостей NuGet из Solution Explorer

При обнаружении уязвимости NuGet-пакета в Solution Explorer появляется ссылка Fix with GitHub Copilot.

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

Пользовательские агенты и навыки — заголовок, но find_symbol — скрытая жемчужина, которая фундаментально меняет точность Copilot при рефакторинге .NET-кода. Скачайте Visual Studio 2026 Insiders, чтобы всё попробовать.

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.

VS Code 1.112: что действительно важно для .NET-разработчиков

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

VS Code 1.112 только что приземлился, и честно? Этот релиз ощущается иначе, если вы проводите дни в мире .NET. В официальных заметках о релизе много всего, но позвольте мне сэкономить вам время и сосредоточиться на том, что действительно важно для нас.

Copilot CLI стал намного полезнее

Главная тема этого релиза — автономность агентов — предоставление Copilot больше пространства для работы без того, чтобы вы контролировали каждый шаг.

Управление сообщениями и очередь

Знаете тот момент, когда Copilot CLI на полпути через задачу, и вы понимаете, что забыли что-то упомянуть? Раньше приходилось ждать. Теперь вы можете просто отправлять сообщения, пока запрос ещё обрабатывается — либо для корректировки текущего ответа, либо для постановки в очередь последующих инструкций.

Это огромное улучшение для длинных задач генерации dotnet, когда вы наблюдаете, как Copilot настраивает проект и думаете «ой, мне ещё нужен MassTransit туда».

Уровни разрешений

Вот что меня больше всего радует. Сессии Copilot CLI теперь поддерживают три уровня разрешений:

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

Если вы делаете что-то вроде создания нового ASP.NET Core API с Entity Framework, миграциями и Docker-настройкой — режим Автопилот означает, что вы описываете, что хотите, и идёте за кофе. Он разберётся.

Включить Автопилот можно через настройку chat.autopilot.enabled.

Предварительный просмотр изменений перед делегированием

Когда вы делегируете задачу Copilot CLI, он создаёт worktree. Раньше, если у вас были незакоммиченные изменения, приходилось проверять Source Control, чтобы увидеть, что будет затронуто. Теперь представление Chat показывает ожидающие изменения прямо перед тем, как вы решите, копировать, переместить или проигнорировать их.

Мелочь, но это спасает от того момента «подождите, что у меня было в staged?».

Отладка веб-приложений без выхода из VS Code

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

Появился новый тип отладки editor-browser, и если у вас уже есть конфигурации запуска для msedge или chrome, миграция так же проста, как изменение поля type в вашем launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Для Blazor-разработчиков это переломный момент. Вы уже запускаете dotnet watch в терминале — теперь и отладка остаётся в том же окне.

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

Песочница для MCP-серверов

Это важнее, чем может показаться. Если вы используете MCP-серверы — может быть, настроили пользовательский для ваших Azure-ресурсов или запросов к базе данных — они работали с теми же правами, что и ваш процесс VS Code. То есть полный доступ к файловой системе, сети, всему.

Теперь их можно изолировать в песочнице. В вашем mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Когда изолированному серверу нужен доступ к чему-то, чего у него нет, VS Code запрашивает разрешение. Гораздо лучше подхода «надеемся, никто не сделает ничего странного».

Примечание: Песочница доступна на macOS и Linux на данный момент. Поддержка Windows на подходе — но удалённые сценарии вроде WSL уже работают.

Обнаружение кастомизаций в монорепозиториях

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

Раньше, если вы открывали подпапку вашего репозитория, VS Code не находил ваш copilot-instructions.md, AGENTS.md или пользовательские скиллы, находящиеся в корне репозитория. Теперь с настройкой chat.useCustomizationsInParentRepositories он поднимается до корня .git и обнаруживает всё.

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

/troubleshoot для отладки агентов

Когда-нибудь настраивали пользовательские инструкции или скиллы и гадали, почему они не подхватываются? Новый скилл /troubleshoot читает отладочные логи агента и сообщает, что произошло — какие инструменты были использованы или пропущены, почему инструкции не загрузились и что вызывает медленные ответы.

Включите его с помощью:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Затем просто введите /troubleshoot почему мой пользовательский скилл не загружается? в чат.

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

Поддержка изображений и бинарных файлов

Агенты теперь могут читать файлы изображений с диска и бинарные файлы нативно. Бинарные файлы представлены в формате hexdump, а выводы изображений (например, скриншоты из встроенного браузера) отображаются в карусельном виде.

Для .NET-разработчиков подумайте: вставьте скриншот UI-бага в чат, и агент поймёт, что не так, или пусть он проанализирует вывод рендеринга компонента Blazor.

Автоматические ссылки на символы

Небольшое улучшение качества жизни: когда вы копируете имя символа (класс, метод и т.д.) и вставляете его в чат, VS Code теперь автоматически преобразует его в ссылку #sym:Name. Это даёт агенту полный контекст об этом символе без необходимости вручную добавлять его.

Если вам нужен обычный текст, используйте Ctrl+Shift+V.

Плагины теперь можно включать/отключать

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

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

Итог

VS Code 1.112 явно усиленно развивает агентный опыт — больше автономности, лучшая отладка, более строгая безопасность. Для .NET-разработчиков встроенная отладка браузера и улучшения Copilot CLI — это главные новшества.

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

Скачайте VS Code 1.112 или обновите изнутри VS Code через Help > Check for Updates.

С ноутбука в продакшен: развёртывание ИИ-агентов в 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 и дополнительных примеров.

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

Пишите для The .NET Blog

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog — это публикация, управляемая сообществом, где разработчики делятся инсайтами, туториалами и историями о .NET, Azure, ИИ и облачно-нативной разработке. Мы приветствуем вклад разработчиков любого уровня — будь вы новичком, пишущим первую техническую статью, или опытным докладчиком.

Как присоединиться

Всё хранится на GitHub и следует рабочему процессу pull request. Вот как начать:

1. Форкните репозиторий

Перейдите на github.com/thedotnetblog/blog и форкните репозиторий в свой аккаунт GitHub.

2. Создайте профиль автора

Создайте папку content/authors/your-username/ с файлом index.md, указав имя, роль и биографию. Добавьте изображение аватара (квадратное, минимум 200×200px) в static/img/authors/.

3. Напишите статью

Создайте папку content/posts/your-username/your-post-slug/ и добавьте файл index.md с заголовком, датой, автором, описанием и тегами.

4. Откройте Pull Request

Отправьте изменения в ваш форк и откройте pull request в ветку main. Наша команда проверит его и даст обратную связь в течение нескольких дней.

Что мы ищем

Туториалы — пошаговые руководства по .NET, Azure, ИИ, Blazor, Aspire и другим технологиям
Глубокий анализ — детальное изучение технологий, паттернов или архитектур
Истории сообщества — ваш опыт использования .NET в продакшне
Обзоры событий — резюме конференций, митапов или вебинаров

Связаться с нами

Откройте issue на GitHub или напишите нам в X / Twitter. Будем рады видеть вас в сообществе!

The .NET Blog

NDC Oslo 2026

В цифрах

Подтверждённые спикеры

Билеты

Другие мероприятия NDC в 2026 году

Ссылки

.NET Day Switzerland 2026

Что вас ждёт

Билеты

Организаторы

Ссылки

SDD Conference 2026

Темы

Спикеры

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

Azure DevOps MCP Сервер Апрельское Обновление: WIQL-Запросы, PAT Аутентификация и Экспериментальные MCP Apps

Поддержка WIQL-Запросов

Personal Access Tokens

Аннотации MCP

Консолидация Wiki-Инструментов

Экспериментально: MCP Apps

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

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

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

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

.NET 10 поставляется с Ubuntu 26.04 LTS — Что Нового

Установить .NET 10 двумя командами

Контейнеры: обновить -noble на -resolute

Native AOT: запуск за 3мс, бинарник 1,4МБ

Нужен .NET 8 или 9?

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

CodeAct в Agent Framework: Как сократить задержку агента вдвое

Что такое CodeAct?

Безопасность: Микро-VM Hyperlight

Минимальная настройка

Когда использовать CodeAct (и когда не стоит)

Попробуйте сейчас

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

Эволюция GPT-5

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

Цены

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

VS Code 1.118: Copilot CLI получает имена сессий, значки модели и TypeScript 7.0 Nightly

Copilot CLI: сессии получают настоящие имена

Быстрое переключение между сессиями

Значки модели в чате

Автоматический выбор модели в Copilot CLI

Подключение TypeScript 7.0 Nightly

Где Ваш Агент Помнит Вещи? Практическое Руководство по Хранению Истории Чата

Два основных паттерна

Как Agent Framework это абстрагирует

Быстрый справочник по поставщикам

Как выбрать

Aspire 13.2: Поддержка Bun, Улучшенные Контейнеры и Меньше Трений при Отладке

Bun теперь первоклассный

Yarn стал надёжнее

Улучшения контейнеров

Улучшения отладки

68 Минут в День на Переобъяснение Кода? Есть Решение

Ложь о Контекстном Окне

Налог на Компактизацию

auto-memory: Слой Отзыва, Не Система Памяти

Заключение

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

Что такое Toolbox?

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

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

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

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

Итог

Windows App Dev CLI v0.3: F5 из терминала и UI-автоматизация для агентов

Контейнеры: обновить `-noble` на `-resolute`