Ai | The .NET Blog

NL2SQL — это SQL-инъекция агентной эпохи

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Есть версия предложения NL2SQL, которая звучит идеально: пользователи задают вопросы на естественном языке, агенты генерируют SQL, данные возвращаются. Меньше экранов, меньше запросов, меньше кода. Просто.

Потом вы думаете об этом ещё пять минут.

Проблемы, о которых никто не говорит на демо

Схемы не были созданы для объяснения вещей. Криптические имена таблиц, непоследовательные имена столбцов, технически допустимые связи, которые семантически недопустимы без дополнительных предикатов — это нормально для корпоративных баз данных. Это не баги, это просто накопленная история бизнес-изменений. Но когда вы просите модель вывести намерение из схемы, которая не была создана для передачи намерения, модель попробует в любом случае. Она не сдастся. Она сгенерирует свой лучший вариант запроса и вернёт результаты с уверенностью.

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

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

И затем есть инъекция. В традиционной разработке SQL параметризация решала проблему инъекции, потому что пользовательский ввод заполнял параметры, а не структуру SQL. С NL2SQL модель сама генерирует SQL. Подсказка, контекст схемы, история разговора и полученные данные — всё влияет на то, что выполняется. Если кто-то создаёт подсказку, которая изменяет то, что генерирует модель, это инъекция — не на уровне параметра, а на уровне генерации запроса. И в отличие от удаления таблицы (очевидно, восстановимо), инъекция NL2SQL производит запросы, возвращающие неверные результаты без видимой ошибки. Бизнес-решения принимаются на основе неверных данных.

Что на самом деле решает SQL MCP Server

Именно здесь статья делает свой самый полезный практический вывод. Вместо того чтобы давать агенту произвольный доступ к схеме и надеяться на лучшее, SQL MCP Server предоставляет курируемую поверхность API, построенную на основе Data API builder.

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

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

Правильный вопрос

Статья не говорит “никогда не используйте NL2SQL.” Она говорит: будьте целенаправленны в том, где вы применяете его и что вы открываете. Для исследовательского анализа в контролируемой среде, с ограниченной схемой и доступом только для чтения, NL2SQL может подойти. Для производственных систем, где бизнес-решения зависят от результатов, курируемый уровень API значительно безопаснее.

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

Оригинальная публикация: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

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

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

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

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

GPT-5.5

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

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

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

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

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

CodeAct с Hyperlight (Alpha)

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

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

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

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

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

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

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

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

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

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

Шаблон Handoff: Когда Одного Агента Недостаточно

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

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

Именно для этой проблемы разработан шаблон оркестрации Handoff в Microsoft Agent Framework.

Как Работает Handoff

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

Три вещи делают это отличным от простого вызова агентами друг друга:

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

Минимальный Пример

В .NET создание рабочего процесса handoff выглядит так:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage может отправлять к любому специалисту. Оба специалиста могут отправлять обратно к triage. Граф поддерживает ацикличность, но допускает обратные рёбра когда нужно (“нужно больше информации” → обратно к исследованию).

Когда Использовать Handoff (и Когда Не Стоит)

Handoff хорошо подходит когда:

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

Это не правильный выбор когда:

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

Обратные Рёбра и Human-in-the-Loop

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

Взаимодействия human-in-the-loop также естественно компонуются. Когда специалисту нужен ввод пользователя, рабочий процесс уступает пользователю через стандартный цикл хода, собирает ответ и возобновляется с полным контекстом. Агент никогда не потерял разговор.

Заключение

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

Прочитайте полное руководство в оригинальном посте: A Tour of the Handoff Orchestration Pattern

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

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

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

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

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

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

using Microsoft.Agents.AI.Workflows;

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

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

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

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

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

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

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

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

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

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

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

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

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

Хостинг в Azure Functions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

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

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

app.Run();

В Python:

server = ResponsesHostServer(agent)
server.run()

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Создать Агентов — Это Лёгкая Часть. Безопасно Их Запустить — Вот Что Сложно

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

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

Microsoft Agent Framework поддерживает вас в построении и оркестрации. Agent Governance Toolkit (AGT) покрывает то, что идёт после — управление, применение политик и аудитируемость во время выполнения.

Что На Самом Деле Делает Каждый Проект

Microsoft Agent Framework (MAF) предоставляет модель программирования: мульти-агентные рабочие процессы, совместимость протокола A2A, хуки middleware, память и управляемый хостинг через Foundry Agent Service. Обрабатывает безопасность контента на уровне ввода/вывода модели.

Agent Governance Toolkit (AGT) подключается к тому же pipeline middleware для управления действиями. Каждый вызов инструмента, обращение к ресурсам и сообщение между агентами оценивается относительно политики до выполнения. Накладные расходы менее миллисекунды. Нет сайдкаров, нет прокси, нет изменённых промптов.

Действие Агента --> Проверка Политики --> Разрешить / Запретить --> Журнал Аудита (< 0.1 мс)

Разные слои, полное покрытие, один pipeline.

Подключение — Это Просто Добавление Middleware

В Python AGT добавляется к тому же параметру middleware, который вы использовали бы для логирования или фильтров контента:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

В .NET тот же паттерн через .Use():

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Тот же агент, та же оркестрация, те же инструменты. AGT добавляет возможности управления, не затрагивая логику агента.

Что Вы Получаете

GovernancePolicyMiddleware — оценивает каждое действие по декларативным правилам политики
CapabilityGuardMiddleware — whitelist инструментов, которые агент имеет право вызывать (инструмент approve_small_loan намеренно не включён в список выше)
RogueDetectionMiddleware — обнаруживает аномальные паттерны поведения во время выполнения
AuditTrailMiddleware — журнал аудита с Merkle-цепочкой, чтобы каждое действие было криптографически защищено от подделки

Последнее важно для соответствия требованиям. Merkle-цепочка означает: если кто-то изменит журнал, цепочка нарушится. Аудит является доказательством.

Пять Отраслевых Сценариев

Репозиторий AGT содержит пять полных сквозных сценариев: финансовые услуги (кредитный сотрудник), здравоохранение (данные пациентов), юридический (проверка контрактов), государственные органы (гражданские услуги) и производство (контроль качества). Каждый сочетает настоящие агенты MAF с настоящим middleware управления AGT.

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

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

Если вы создаёте агентов, которые работают с реальными данными, принимают решения с последствиями или работают без наблюдения в продакшне — управление не опционально. Комбинация MAF + AGT даёт вам полный стек: стройте с Agent Framework, управляйте с AGT.

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

Оригинальная публикация: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

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

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

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

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

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

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

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

Text Embeddings

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

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

Responses API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С Чего Начать

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

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

Azure SQL Теперь Может Генерировать Эмбеддинги — На Чистом T-SQL, Без Слоя Приложения

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

Если вы когда-нибудь создавали RAG-пайплайн, вы знаете налог пайплайна: ваши данные живут в SQL, но для генерации эмбеддингов нужно их извлечь, вызвать API эмбеддингов, обработать пакетную обработку и ограничения скорости, и сохранить результаты где-то с поддержкой векторного поиска. Часто в совершенно другой базе данных.

Azure SQL только что устранил большую часть этого с двумя функциями, которые теперь стали общедоступными: CREATE EXTERNAL MODEL и AI_GENERATE_EMBEDDINGS.

Что Они Делают

Эти две функции T-SQL работают как интегрированный пайплайн:

CREATE EXTERNAL MODEL — регистрирует внешний эндпоинт модели ИИ как именованный объект базы данных. Вы устанавливаете расположение, формат API, тип модели и учётные данные один раз. Повторно используете везде.

AI_GENERATE_EMBEDDINGS — скалярная функция T-SQL, которая вызывает зарегистрированную модель и возвращает JSON-массив векторных значений. Работает в инструкциях SELECT, INSERT, UPDATE и MERGE.

Вместе они формируют сквозной пайплайн эмбеддингов без выхода из SQL-движка.

Полный Рабочий Процесс

-- Шаг 1: Зарегистрируйте провайдера эмбеддингов один раз
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Шаг 2: Генерируйте эмбеддинги встроенно в T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Шаг 3: Поиск с векторным расстоянием
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Это весь пайплайн: данные в SQL, эмбеддинги генерируются в SQL, поиск по сходству в SQL. Без слоя оркестрации, без ETL, без отдельной векторной базы данных.

Поддерживаемые Форматы API и Параметры

В GA API_FORMAT поддерживает Azure OpenAI и OpenAI. MODEL_TYPE пока ограничен значением EMBEDDINGS. JSON PARAMETERS позволяет устанавливать значения по умолчанию на уровне модели, включая количество повторных попыток:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

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

Что Это Открывает для Приложений .NET

Для разработчиков .NET, создающих функции ИИ на основе существующих данных SQL, это значительно. Вам не нужно:

Извлекать данные в промежуточное хранилище для эмбеддингов
Управлять внешним пайплайном эмбеддингов
Настраивать отдельную векторную базу данных (хотя можно использовать Azure AI Search для полнофункционального векторного хранилища)
Изменять слой доступа к данным приложения

Вы можете постепенно добавлять семантический поиск в существующие SQL-приложения, используя те же инструменты T-SQL, которые у вас уже есть.

Заключение

Паттерны RAG на SQL-данных стали значительно проще. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL означает, что ваше существующее SQL-приложение может получить возможности векторного поиска без добавления новой инфраструктуры.

Обе функции сегодня доступны в GA в Azure SQL Database и Azure SQL Managed Instance.

Оригинальная публикация: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

SDD Conference 2026

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

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

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

Темы

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

Спикеры

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

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

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

Создание конференционного приложения с ИИ на основе составного стека .NET

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

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

Создание конференционного приложения с ИИ на основе составного стека .NET — Microsoft создала ConferencePulse, приложение Blazor Server для сессий живых конференций, объединив пять библиотек расширения .NET. Оно было использовано на MVP Summit.

Что делает ConferencePulse

ConferencePulse работает во время живых сессий и предоставляет: опросы, сгенерированные ИИ из содержимого сессии, вопросы и ответы аудитории с конвейером RAG, извлекающим из живой базы знаний, автоматически сгенерированные выводы и резюме сессий, создаваемые несколькими одновременными агентами ИИ. Стек — .NET 10, Blazor Server, Aspire, разбитый на пять проектов: Web, Core, Ingestion, Agents, Mcp и AppHost.

Microsoft.Extensions.AI: одна абстракция для всего

IChatClient — это унифицированная абстракция — настраивается один раз, и тот же интерфейс работает для Azure OpenAI, OpenAI, Anthropic или любого другого провайдера. Шесть строк для получения полностью настроенного клиента с вызовом функций, трассировкой OpenTelemetry и промежуточным ПО для логирования:

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

Тот же IChatClient повторно используется позже для шага обогащения приёма данных — отдельный клиент для этого не нужен.

Конвейер DataIngestion

Содержимое сессии проходит через конвейер: MarkdownReader → HeaderChunker (500 токенов, перекрытие 50 токенов) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). Обогатители используют тот же IChatClient для генерации резюме и извлечения ключевых слов перед индексацией. Вопросы аудитории, пары вопросов и ответов и результаты опросов принимаются в режиме реального времени по мере продвижения сессии — база знаний растёт во время доклада.

VectorData: поиск, независимый от провайдера

VectorStoreCollection.SearchAsync() работает одинаково независимо от того, является ли резервное хранилище Qdrant или Azure AI Search. Гибридный поиск (вектор + полный текст) поддерживается. Конвейер RAG для вопросов и ответов аудитории запрашивает эту коллекцию и получает соответствующие фрагменты для передачи в качестве контекста клиенту чата.

MCP: содержимое сессии как инструменты

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

Agent Framework: параллельное многоагентное резюме

Резюме сессии генерируется тремя агентами, работающими одновременно — PollSummaryAgent, QuestionSummaryAgent и InsightSummaryAgent — затем объединяется. Это использует шаблон группового чата или параллельного выполнения из Microsoft Agent Framework. Каждый агент обрабатывает одну задачу; оркестратор объединяет результаты.

Принцип проектирования

В посте сделан вывод, который стоит запомнить: используйте самый простой инструмент, который подходит. Прямые вызовы IChatClient для простых задач генерации. Вызов инструмента/функции для извлечения структурированных данных. Полные агенты только тогда, когда нужны автономные многошаговые рассуждения. Слоистость библиотек это обеспечивает — вы можете использовать Microsoft.Extensions.AI без подключения полного Agent Framework.

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

Microsoft Agent Framework Часть 3: От инструментов к воркфлоу — строительные блоки встают на место

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

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

Если вы следили за серией Building Blocks for AI в .NET, вы знаете: Часть 1 дала нам IChatClient (универсальный интерфейс модели), а Часть 2 — Microsoft.Extensions.VectorData (семантический поиск и RAG). Оба — фундаментальные, оба полезны сами по себе. Но здесь всё начинает соединяться.

Часть 3 — о Microsoft Agent Framework. Честно говоря, это именно тот кусочек, которого я ждал в .NET. Версия 1.0 вышла в апреле. API стабильный. Пора строить настоящих агентов.

Что такое агент (vs. чат-бот)

Прежде чем нырять в код, разберёмся с этим различием. Чат-бот получает ввод, вызывает модель, возвращает вывод. Простой цикл.

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

Думайте об этом так: IChatClient — как вести разговор. Агент — как поручить кому-то список задач.

Первый агент в 10 строках

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

Метод расширения .AsAIAgent() — это мост. Тот же паттерн, что и .AsIChatClient() из MEAI — оборачивает SDK провайдера в стабильную абстракцию. Работает с Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry или локальными моделями.

Стриминг тоже работает:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Даём агенту инструменты

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

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Два момента. Первый: AIFunctionFactory из MEAI — та же фабрика инструментов, что используется с обычным IChatClient. Если вы уже определили инструменты для сценариев чата, здесь они тоже работают.

Второй: атрибуты Description имеют большое значение. Именно через них модель понимает, что делает инструмент и когда его применять. Относитесь к ним как к документации для ИИ, а не для людей.

Сессии: разговоры с настоящей памятью

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Без сессии каждый вызов RunAsync — безсостоянческий. С сессией агент знает, о каком анекдоте вы говорите. AgentSession сохраняет историю разговора между ходами.

Для stateless-сервисов в продакшне сессии сериализуются чисто:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... сохраните куда-нибудь ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

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

AIContextProvider: постоянная память между сессиями

Сессии сохраняют историю разговора внутри сессии. Но что насчёт знания о пользователе между сессиями? Этим занимается AIContextProvider.

У него два хука:

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

Паттерн элегантный: можно складывать несколько провайдеров — один для предпочтений пользователя, один для недавних взаимодействий, один который запрашивает VectorData-хранилище на предмет релевантных документов. Последний — это именно RAG-паттерн из Части 2, теперь автоматически выполняющийся при каждом вызове агента.

Мультиагентные воркфлоу

Здесь фреймворк оправдывает своё название. Он включает графовую систему воркфлоу, где исполнители (агенты, функции, что угодно) соединяются рёбрами.

Некоторые поддерживаемые паттерны:

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

Пример писатель-критик:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Чисто, читаемо, и маршрутизация на основе условий означает, что логику цикла писать самому не нужно.

Human-in-the-Loop

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

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

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

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

Если сделать шаг назад:

MEAI даёт универсальный интерфейс к любой модели
VectorData открывает агентам доступ к знаниям организации через семантический поиск
Agent Framework оркестрирует всё — использует IChatClient под капотом, компонуется с провайдерами контекста, координирует через воркфлоу

Каждая часть разработана для компоновки с другими. Смотрите оригинальный пост Джереми Ликнесса и GitHub-репозиторий Agent Framework для полных примеров.

Итог

Пост Часть 3 Microsoft Agent Framework закрывает цикл серии строительных блоков. Для .NET-разработчиков, которые хотят строить агентов ИИ — не просто чат-ботов, а настоящих агентов, использующих инструменты, помнящих и координирующих — это ваш путь вперёд.

Стабильный релиз 1.0 означает, что это можно использовать в продакшне. Если вы ждали момента, чтобы войти в разработку агентов в .NET, этот момент — сейчас.

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

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

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

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

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

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-бэкендом
Простой чатбот? → Линейное, управляемое сервисом, — достаточно

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

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, все подробности — в оригинальном анонсе.

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

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

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

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

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

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

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

Дашборд 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 и дополнительных примеров.

Ai | The .NET Blog

NL2SQL — это SQL-инъекция агентной эпохи

Проблемы, о которых никто не говорит на демо

Что на самом деле решает SQL MCP Server

Правильный вопрос

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

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

GPT-5.5

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

CodeAct с Hyperlight (Alpha)

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

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

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

Шаблон Handoff: Когда Одного Агента Недостаточно

Как Работает Handoff

Минимальный Пример

Когда Использовать Handoff (и Когда Не Стоит)

Обратные Рёбра и Human-in-the-Loop

Заключение

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

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

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

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

Хостинг в Azure Functions

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

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

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

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

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

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

Заключение

Создать Агентов — Это Лёгкая Часть. Безопасно Их Запустить — Вот Что Сложно

Что На Самом Деле Делает Каждый Проект

Подключение — Это Просто Добавление Middleware

Что Вы Получаете

Пять Отраслевых Сценариев

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

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

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

Text Embeddings

Responses API

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

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

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

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

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

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

С Чего Начать

Azure SQL Теперь Может Генерировать Эмбеддинги — На Чистом T-SQL, Без Слоя Приложения

Что Они Делают

Полный Рабочий Процесс

Поддерживаемые Форматы API и Параметры

Что Это Открывает для Приложений .NET

Заключение

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

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

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

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

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

Заключение

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

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

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

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

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

Итог

SDD Conference 2026

Темы

Спикеры

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

Создание конференционного приложения с ИИ на основе составного стека .NET

Что делает ConferencePulse

Microsoft.Extensions.AI: одна абстракция для всего

Конвейер DataIngestion

VectorData: поиск, независимый от провайдера

MCP: содержимое сессии как инструменты

Agent Framework: параллельное многоагентное резюме

Принцип проектирования

Microsoft Agent Framework Часть 3: От инструментов к воркфлоу — строительные блоки встают на место

Что такое агент (vs. чат-бот)

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