Agent-Framework | The .NET Blog

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

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

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

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

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

GPT-5.5

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

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

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

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

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

CodeAct с Hyperlight (Alpha)

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

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

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

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

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

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

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

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

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

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

Шаблон 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

A2A v1 Здесь: Кросс-Платформенная Коммуникация Агентов в Microsoft Agent Framework для .NET

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

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

A2A v1 Здесь: Кросс-Платформенная Коммуникация Агентов в Microsoft Agent Framework для .NET — Протокол A2A только что достиг v1.0, и оба пакета A2A Agent (клиент) и A2A Hosting (сервер) для .NET обновлены.

Что такое A2A v1 на самом деле

A2A — это открытый протокол совместимости для AI-агентов, поддерживаемый техническим руководящим комитетом с представителями AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP и ServiceNow. Метка v1 означает, что это теперь стабильный, готовый к производству стандарт. Пакеты SDK и Agent Framework, реализующие его, всё ещё находятся в предварительной версии, но сам протокол зафиксирован.

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

Подключение к удалённому агенту A2A

Удалённый агент A2A — это просто AIAgent в вашем коде — тот же RunAsync, то же потоковое воспроизведение, то же управление сессиями:

// Обнаружение через well-known URI
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// Прямая конфигурация
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// Потоковое воспроизведение работает так же
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

Раскрытие вашего агента как конечной точки A2A

Любой AIAgent, который вы уже создали — на Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic или AWS Bedrock — можно раскрыть как конечную точку A2A двумя строками в ASP.NET Core:

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

Карточка агента автоматически обслуживается по адресу /.well-known/agent-card.json.

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

Стабильный протокол v1 означает, что вы можете соединять своих .NET-агентов с агентами, созданными на Python, Java или любом другом языке, не беспокоясь о критических изменениях. Криптографическая идентичность в подписанных Agent Cards также обеспечивает основу для проверки доверия между агентами.

Полный журнал изменений и заметки о миграции с v0.3 см. в полном посте.

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

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

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, чтобы начать.

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

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. Посмотрите руководство по быстрому старту и примеры, чтобы попробовать на практике.

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

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

Agent-Framework | The .NET Blog

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

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

GPT-5.5

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

CodeAct с Hyperlight (Alpha)

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

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

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

Шаблон 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

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

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

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

A2A v1 Здесь: Кросс-Платформенная Коммуникация Агентов в Microsoft Agent Framework для .NET

Что такое A2A v1 на самом деле

Подключение к удалённому агенту A2A

Раскрытие вашего агента как конечной точки A2A

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

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

Что такое CodeAct?

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

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

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

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

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

Эволюция GPT-5

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

Цены

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

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

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

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

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

Как выбрать

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

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

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

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

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

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

Подводя итог

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

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

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

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

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

Моё мнение

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

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

Коротко

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

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

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

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

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

Подводя итог

Фоновые ответы в Microsoft Agent Framework: больше никакой тревоги из-за таймаутов

Проблема с блокирующими вызовами

Как работают continuation-токены

Стриминг с возобновлением: настоящая магия

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