Microsoft Foundry Agent Service и Microsoft Agent Framework: как запускать ИИ-агентов в продакшене, а не в демках — VogueTech

Что нового

Microsoft показала связку из двух ключевых компонентов для корпоративных ИИ-агентов:

Foundry Agent Service
Платформа на Azure для хостинга и управления агентами:
- деплой прямо из локальной среды (через Visual Studio Code и расширение AI Toolkit);
- автоматическое назначение служебной идентичности в Microsoft Entra ID для каждого агента;
- запуск каждого пользовательского сеанса в изолированном microVM (sandbox);
- централизованный мониторинг: логи, трассировки, токены, стоимость, успешность ответов;
- публикация агентов в Microsoft 365 Copilot и Microsoft Teams одним кликом;
- встроенные политики и guardrails: контент-фильтры, защита от prompt-injection, ограничения по авторскому праву.
Microsoft Agent Framework
Open source-фреймворк (есть реализация на Python) для разработки одиночных и мультиагентных сценариев:
- поддержка single- и multi-agent рабочих нагрузок с оркестрацией;
- работа через GitHub Copilot SDK как агентный цикл над набором инструментов;
- явное описание tools, middleware и skills (напрямую в коде);
- шаблоны и готовые проекты через Azure Developer CLI (azd) для быстрого старта.

Плюс Microsoft завязала Foundry на свой "интеллектуальный слой" для контекста:

Work IQ — данные о работе конкретного пользователя: почта, календарь, встречи, чаты, файлы в Microsoft 365;
Fabric IQ — операционные и аналитические данные: продажи, CRM, логистика, usage-метрики и т.п.;
Foundry IQ — единый доступ к разнородным источникам знаний: базы данных, облачные хранилища, документы, изображения.

На демонстрации использовали sales meeting preparation agent:

агент сам находит важные встречи в календаре;
подтягивает переписку и чаты с клиентом;
достаёт usage- и контрактные данные из Fabric IQ;
ищет релевантные материалы в Foundry IQ;
генерирует Word-бриф для внутренней команды и PowerPoint-презентацию под бренд компании.

Конкретных числовых бенчмарков (скорость, стоимость токена, размер контекста) Microsoft не приводит. Акцент — на безопасности, управляемости и встраивании в Microsoft 365.

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

Архитектура агента

Разработчик пишет агента на любимом стеке. В примере — Python + Microsoft Agent Framework + GitHub Copilot SDK.

В коде явно описываются:

Tools — функции, к которым агент может обращаться (доступ к Work IQ / Foundry IQ / Fabric IQ, генерация документов, работа с CRM и т.п.);
Skills — более крупные сценарии, собранные из tools (например, "собрать бриф" или "собрать презентацию");
Middleware — логика до и после вызова агента (например, блокировка генерации документа, если не хватает данных из всех трёх IQ).

GitHub Copilot SDK запускает agentic loop:

Модель рассуждает над задачей.
Выбирает нужные инструменты.
Вызывает их последовательно или параллельно.
Собирает результаты и формирует итоговый ответ или артефакт (документ, презентация и т.д.).

Деплой через Foundry Agent Service

Разработчик пишет и отлаживает агента локально.
В Visual Studio Code открывает расширение AI Toolkit.
Нажимает Deploy to hosted agents.

Foundry:

упаковывает код агента;
разворачивает его как hosted agent в инфраструктуре Azure;
регистрирует агента в Microsoft Entra ID и выдаёт ему собственную идентичность.

Идентичность и доступ

У агента есть два режима работы с данными:

От своего имени (service identity):
- у агента есть собственные scoped permissions;
- он может, например, читать определённые базы или хранилища, но не видеть личную почту пользователей.
От имени пользователя (on behalf of user):
- агент использует разрешения конкретного человека;
- видит только те письма, календари и файлы, к которым есть доступ у пользователя.

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

Изоляция через microVM

Для каждого пользовательского сеанса Foundry поднимает отдельный microVM:

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

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

Политики и guardrails

Перед каждым вызовом Foundry проверяет политики организации:

контент-фильтры (запрет определённых типов контента);
защита от prompt injection;
ограничения, связанные с авторским правом.

Разработчик может добавить свои правила в middleware. В примере: если агент пытается создать документ без достаточного объёма данных из Work IQ / Fabric IQ / Foundry IQ, middleware блокирует операцию, чтобы снизить риск галлюцинаций.

Интеллектуальный слой: Work IQ, Fabric IQ, Foundry IQ

На демо агент использует все три "IQ":

Work IQ:
- читает переписку и Teams-чаты с клиентом Zava;
- анализирует календарь, прошлые встречи, файлы.
Fabric IQ:
- подтягивает usage-данные по продуктам;
- смотрит историю покупок, контрактные условия, метрики использования.
Foundry IQ:
- ищет в sales enablement-материалах, маркетинговых документах;
- выбирает релевантные кейсы и презентации.

Результат — агент не просто отвечает текстом, а собирает документы:

Word-файл для внутренней команды: состояние аккаунта, история взаимодействий, метрики, тикеты, рекомендованные темы разговора.
PowerPoint-презентацию для клиента: брендовые цвета компании, персонализированные слайды с данными клиента, кампаниями и следующими шагами.

Мониторинг и управление флотом агентов

В портале Foundry разработчик и администратор видят:

здоровье агентов (health, алерты);
оценочную стоимость (estimated cost);
успешность (success rates);
использование токенов;
объём запусков (run volumes) по каждому агенту;
топ- и анти-топ агентов по качеству.

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

Публикация в Microsoft 365 и Teams

После деплоя в Foundry разработчик нажимает Publish:

агент регистрируется как доступный сервис в Microsoft 365 Copilot;
пользователи могут вызывать его прямо из Copilot Chat или Microsoft Teams;
работать можно с десктопа и с мобильных клиентов.

Это снимает проблему "ещё одного веб-приложения, ссылку на которое все потеряют" — агент живёт там, где сотрудники уже проводят рабочее время.

Что это значит для вас

Для кого это вообще

Кому подходит:

крупные и средние компании, уже живущие в экосистеме Microsoft 365 + Azure;
команды продаж, customer success, поддержки, консалтинга — где много рутины вокруг подготовки к встречам, отчётности и персонализированных материалов;
внутренние ИТ и платформенные команды, которые строят внутренний "магазин" агентов для сотрудников;
разработчики, которым важно не только написать агента, но и показать CISO и юристам, что всё под контролем.

Кому не подойдёт:

небольшие команды без подписки на Microsoft 365 и Azure — порог входа по экосистеме высокий;
проекты, где нужен максимально дешёвый и простой чат-бот без требований по аудиту и интеграции с корпоративными данными;
сценарии, где использование облака Azure юридически невозможно.

Типичные сценарии применения

Подготовка к встречам и звонкам
- продажи, аккаунт-менеджмент, партнёрский отдел;
- агент собирает всё по клиенту в один бриф и презентацию.
Агенты для внутренних процессов
- онбординг сотрудников, ответы на вопросы по внутренним регламентам;
- анализ инцидентов, тикетов, обращений в поддержку;
- подготовка отчётов для руководства на основе данных в Fabric и Foundry IQ.
"Тихие" агенты-фоны
- мониторинг ключевых метрик и автоматическая подготовка дайджестов;
- анализ логов, предупреждение о рисках или аномалиях (если данные заведены в Fabric/Foundry IQ).
Мультиагентные сценарии
- несколько агентов с разными ролями: один собирает данные, второй анализирует, третий готовит презентацию;
- Microsoft Agent Framework поддерживает такие оркестрации.

Где лучше не применять

Потребительские продукты вне Microsoft-стека. Если вы делаете B2C-сервис без привязки к Microsoft 365, проще взять более лёгкий фреймворк и отдельный LLM API.
Сценарии, требующие полного он-прем размещения без Azure. Foundry — облачный сервис; если инфраструктура полностью изолирована, придётся искать альтернативу или ждать on-prem-вариантов.
Эксперименты "на коленке". Для быстрых pet-проектов Foundry может оказаться избыточным по настройкам и процедурам.

Важно для читателей из России

Foundry Agent Service и связанный портал ai.azure.com работают в экосистеме Azure.
Доступ к Azure и Microsoft 365 из России может быть ограничен юридически и технически. Для работы часто нужен VPN и корпоративный аккаунт, который обслуживает зарубежный юридический контур.

Если ваша компания официально не использует Azure и Microsoft 365, внедрение Foundry в России будет затруднено.

Место на рынке

Microsoft не приводит прямых сравнений по скорости или цене с GPT-4o, Claude 3.5 или другими моделями. Foundry и Microsoft Agent Framework — это не конкурент "голым" LLM-API, а платформа вокруг них.

Если сравнивать по типу решений:

Против "просто LLM API" (GPT-4o, Claude 3.5, Gemini 1.5 и т.п.):
- LLM даёт вам модель, но не даёт идентичность, microVM, трассировку, публикацию в Teams и Copilot;
- Foundry добавляет поверх выбранной модели слой enterprise-контроля и встраивания в Microsoft 365.
- Цена по токенам зависит от выбранной модели (Microsoft об этом в ролике не говорит), но общая стоимость владения включает Azure и Microsoft 365.
Против open-source оркестраторов (LangChain, LangGraph, Semantic Kernel и др.):
- LangChain / LangGraph — это, по сути, конструкторы пайплайнов и агентов, но вопрос деплоя, мониторинга, безопасности и публикации в корпоративные среды остаётся на вашей совести;
- Microsoft Agent Framework решает часть задач разработки (tools, middleware, skills), а Foundry — деплой, идентичность, мониторинг и интеграцию с Microsoft 365.
Против других enterprise-платформ агентов:
- конкуренты тоже предлагают оркестрацию и мониторинг, но Microsoft делает упор на глубокой интеграции с Work IQ / Fabric IQ / Foundry IQ и Microsoft 365;
- за счёт родной интеграции с Entra ID, Teams, Copilot, Fabric и M365 Foundry логично смотрится там, где уже доминирует стек Microsoft.

Точных чисел "быстрее на X%" или "дешевле в Y раз" Microsoft не приводит. Ключевой аргумент — снижение операционной сложности и рисков для ИТ и безопасности.

Установка / Как запустить

В ролике показаны два основных рабочих контура: через Azure Developer CLI и через Visual Studio Code + AI Toolkit.

1. Быстрый старт через Azure Developer CLI

На демо Jeff Hollan делает следующее:

Открывает терминал на ноутбуке.
Запускает Azure Developer CLI (azd) для создания нового проекта агента:

azd init
# далее в интерактивном режиме выбирает шаблон, например "sales prep agent"

Шаблон:

создаёт структуру проекта;
добавляет код простого агента;
настраивает конфигурацию для деплоя в Foundry.

После инициализации можно:

# локальный запуск и отладка (примерная команда, в демо детали не проговариваются)
azd up
# или запуск через стандартные команды Python / фреймворка
python main.py

Далее разработчик дорабатывает агента, добавляет tools и skills, и уже после — деплоит в Foundry через VS Code.

2. Деплой из Visual Studio Code через AI Toolkit

Установить Visual Studio Code.
Поставить расширение AI Toolkit от Microsoft.
Открыть папку с проектом агента.
В панели AI Toolkit выбрать свой агент и нажать Deploy to hosted agents.

AI Toolkit:

упакует код;
отправит его в Foundry;
создаст hosted agent с идентичностью в Entra ID.

После этого агент станет доступен в Foundry portal, где можно:

протестировать его в playground;
посмотреть трассировки;
настроить доступы и политики;
опубликовать в Microsoft 365 / Teams.

3. Работа с Microsoft Agent Framework и GitHub Copilot SDK

В исходном видео приводят только концептуальные фрагменты, но общая схема кода выглядит так:

from microsoft_agent_framework import Agent, Tool, Middleware
from github_copilot_sdk import CopilotAgent

# Определяем инструменты
work_iq_tool = Tool(name="work_iq", ...)
foundry_iq_tool = Tool(name="foundry_iq", ...)
fabric_iq_tool = Tool(name="fabric_iq", ...)

generate_briefing_doc = Tool(name="generate_briefing_doc", ...)
generate_ppt = Tool(name="generate_ppt", ...)

# Middleware для проверки, что данных достаточно
class DataGuardMiddleware(Middleware):
    def before_tool_call(self, context):
        if context.tool_name in ["generate_briefing_doc", "generate_ppt"]:
            if not context.state.get("work_iq") or \
               not context.state.get("foundry_iq") or \
               not context.state.get("fabric_iq"):
                raise Exception("Недостаточно данных для надёжного документа")

# Настраиваем Copilot SDK как агентный цикл
copilot_agent = CopilotAgent(
    tools=[
        work_iq_tool,
        foundry_iq_tool,
        fabric_iq_tool,
        generate_briefing_doc,
        generate_ppt,
    ],
    middlewares=[DataGuardMiddleware()],
)

# Оборачиваем во фреймворк агента
agent = Agent(core=copilot_agent)

if __name__ == "__main__":
    query = "Помоги подготовиться к встрече с Zava"
    result = agent.run(query)
    print(result)

Этот пример иллюстративный: в реальных проектах инструменты будут вызывать Work IQ / Foundry IQ / Fabric IQ через соответствующие SDK и API, а не через заглушки.

Итог: кому стоит попробовать прямо сейчас

Если вы уже платите за Microsoft 365, строите аналитику в Fabric и рассматриваете Copilot — Foundry Agent Service логично продолжает эту линию. Агенты получают доступ к вашим данным и живут там же, где работают сотрудники.
Если ваша задача — вытащить ИИ-агентов из стадии "демки" в реальный прод с аудитом, безопасностью и управлением флотом, связка Foundry + Microsoft Agent Framework закрывает большую часть инфраструктурных вопросов.
Если вам нужен просто чат-бот на GPT-4o для лендинга — это тяжёлая артиллерия. Проще взять прямой API и лёгкий фреймворк.

Начать можно с официальных ресурсов:

портал Foundry: https://ai.azure.com
репозиторий с примерами и SDK: https://github.com/microsoft-foundry