Дата публикации
ai_products

Как Microsoft учит Copilot писать агентов за вас: SKILL, Agent Framework и Foundry

Что нового

Microsoft собрала воедино то, что многие команды делают хаотично: теперь есть чёткая двухслойная архитектура для AI-агентов и готовый «агент‑инженер» на базе GitHub Copilot.

Ключевые новинки:

  1. Двухслойная модель разработки агентов

    • Coding Agent (слой 1) — это не пользовательский бот, а «разработчик‑агент», который пишет код, тесты, eval‑наборы, конфиги и документацию.
    • Runtime Agent (слой 2) — тот самый рабочий агент, который общается с пользователями, вызывает инструменты, пишет и читает память, запускает воркфлоу.
  2. SKILL — центральный контракт для Copilot

    • SKILL — это структурированный документ, который объясняет Coding Agent’у, как именно писать код в вашем проекте: какие библиотеки, паттерны, соглашения по именованию, как подключать данные и инструменты.
    • SKILL хранится в репозитории, версионируется и обновляется вместе с кодом.
    • Один раз обновляете SKILL при смене фреймворка или идиом — все новые агенты автоматически следуют новым правилам.
  3. Microsoft Agent Framework + Foundry как общая платформа

    • Microsoft Agent Framework — SDK для Python и .NET (C#), который описывает агентов, инструменты, память, воркфлоу и AG‑UI.
    • Microsoft Foundry — платформа, куда публикуются оба слоя: и артефакты сборки, и рабочие агенты. Там же живут Toolbox‑инструменты, Agent Skills, память и наблюдаемость.
  4. Готовый учебный проект ZavaShop

    • Фиктивная глобальная e‑commerce‑компания с 5 фулфилмент‑центрами, десятками поставщиков и живыми данными: 10 SKU, 6 заказов на закупку (PO), 8 поставщиков, 5 контрактов, 4 клиента (3 VIP), 6 заказов, 5 перевозчиков, 4 открытых инцидента.
    • Все артефакты, которые генерирует Coding Agent, привязаны к этим фикстурам: цифры согласованы по всему стеку.
  5. Шесть готовых SKILL‑файлов для Python и .NET
    Для каждого языка — три SKILL’а под разные задачи:

    Python:

    • agent-framework-azure-ai-py — одиночный агент на Foundry/Azure AI: инструменты, MCP, Toolbox, Skills, Memory, Threads.
    • agent-framework-workflows-py — многоагентные воркфлоу: WorkflowBuilder, executors, Human‑in‑the‑Loop (HITL), checkpointing.
    • agent-framework-agui-py — AG‑UI сервер + клиент: SSE, фронтенд/бэкенд‑инструменты, shared state, HITL.

    .NET (C#):

    • agent-framework-azure-ai-csharp — аналог Python‑версии под C#.
    • agent-framework-workflows-csharp — воркфлоу для C#.
    • agent-framework-agui-csharp — AG‑UI в ASP.NET Core (MapAGUI, AGUIChatClient, HITL).
  6. Полный набор артефактов агента как стандарт
    Coding Agent генерирует не только код, но и:

    • agent definitions (имя, инструкции, список инструментов),
    • Workflows (WorkflowBuilder‑графы),
    • Skills (runtime‑способности в Foundry),
    • коннекторы (MCP‑серверы, Toolbox‑регистрации),
    • eval‑наборы (eval_queries.jsonl + harness),
    • тесты, конфиги и README.
  7. Жёсткий build‑pipeline: тесты, eval и red‑teaming до деплоя
    Перед тем как агент попадёт в Foundry и Azure, проходят четыре проверки:

    • юнит‑ и интеграционные тесты,
    • линтер и типы (ruff/mypy для Python, dotnet build предупреждения для .NET),
    • прогон eval‑набора с метриками (правильный инструмент, правильный факт в ответе),
    • red‑team‑пробы с SDK Foundry, чтобы поймать prompt‑инъекции и уходы от темы.
  8. Единая модель по всему стеку

    • В воркшопе везде используется одна и та же модель: gpt-5.5 на Foundry и эмбеддинги text-embedding-3-small.
    • Меняете одну переменную окружения — и запускаете те же артефакты на Python или .NET.

Цифровых бенчмарков по скорости или стоимости Microsoft не приводит, но есть конкретные технические метрики:

  • пример acceptance‑критериев: P95‑латентность < 4 секунд,
  • доля неверных вызовов инструментов на eval‑наборе — < 5%.

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

Две роли: Coding Agent и Runtime Agent

Большинство гайдов по агентам смешивают два разных процесса: разработку и исполнение. Microsoft жёстко разделяет их:

  • Coding Agent (build time)
    Работает внутри GitHub Copilot Chat в Agent Mode. Это настроенный агент, который:

    • читает SKILL и контекст проекта,
    • планирует, какие файлы и артефакты создать,
    • пишет код агентов, инструменты, воркфлоу, тесты, eval‑наборы, конфиги,
    • запускает проверки и готовит bundle для Foundry.
  • Runtime Agent (runtime)
    Это уже рабочий агент, который живёт в Teams, веб‑приложении или другом канале. Он:

    • планирует шаги с помощью LLM,
    • вызывает инструменты (функции, MCP, Toolbox, Agent Skills),
    • читает и пишет память,
    • передаёт ответы пользователю и триггерит действия в других системах.

SKILL: инструкция для Copilot, как писать «ваш» код

SKILL — это файл в .github/skills/, который описывает:

  • Область применения
    Например: «используй этот SKILL для агентов на Foundry/Azure AI: инструменты, MCP, Toolbox, Skills, Memory, Threads».

  • Идиомы фреймворка
    Как правильно:

    • создавать AzureAIAgentClient,
    • регистрировать function tools,
    • подключать HostedMCPTool,
    • работать с Thread.
  • Кодовые паттерны
    Набор эталонных сниппетов: порядок импортов, типы, обработка ошибок, соглашения по именам. Coding Agent просто подражает этим образцам.

  • Контракт с данными/фикстурами
    Как грузить workshop/data/, какие есть лоадеры (find_stock, find_po и т.д.), как правильно трогать sys.path.

  • Анти‑паттерны
    Чего не делать: не хардкодить имя модели, не писать inline‑моки словарями, не обходить лоадеры.

  • Критерии приёмки
    Как превратить требования LAB в проверки: какие eval‑строки создать, какие smoke‑тесты запустить.

Coding Agent каждый раз начинает с одного и того же ритуала: сначала читает SKILL, потом пишет код. Это заложено в его определение в .github/agents/zavashop-coding-agent.agent.md.

Пример цикла Coding Agent’а

Запрос разработчика в VS Code:

«Я работаю над inventory‑агентом на Python — подключи поиск stock и PO по фикстурам и добавь HostedMCPTool для warehouse handbook»

Дальше происходит следующее:

  1. Маршрутизация
    Coding Agent подгружает нужный SKILL и описание лабораторной задачи (LAB README) в контекст.

  2. Планирование
    На основе SKILL и acceptance‑критериев он строит план: какие файлы создать, какие функции, какие eval‑кейсы добавить. Все пункты плана опираются либо на SKILL (как), либо на LAB (что).

  3. Генерация кода
    Только после этого Copilot пишет код. Пример файла scripts/inventory_agent.py:

# scripts/inventory_agent.py
import os
import sys
from pathlib import Path

# Pattern from SKILL: add data folder to sys.path, import named loaders
sys.path.insert(0, str(Path(__file__).resolve().parents[1] / "data"))
from zava_data import find_stock, find_po   # noqa: E402

from agent_framework import HostedMCPTool
from agent_framework_azure_ai import AzureAIAgentClient
from azure.identity import DefaultAzureCredential


def stock_lookup(sku: str, warehouse: str) -> dict:
    """Return on-hand quantity for a SKU at a warehouse."""
    return find_stock(sku, warehouse)


def po_lookup(po_id: str) -> dict:
    """Return the status of a purchase order."""
    return find_po(po_id)


async def main() -> None:
    client = AzureAIAgentClient(
        project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
        model_deployment_name=os.environ["FOUNDRY_MODEL"],   # gpt-5.5 from env
        async_credential=DefaultAzureCredential(),
    )

    agent = client.create_agent(
        name="Zara",
        instructions=(
            "You are Zara, the warehouse assistant for Seattle DC (SEA-01). "
            "Use the tools when asked about stock or POs. "
            "Answer briefly."
        ),
        tools=[
            stock_lookup,
            po_lookup,
            HostedMCPTool(
                name="warehouse-docs",
                url=os.environ["WAREHOUSE_DOCS_MCP_URL"],
            ),
        ],
    )

    thread = agent.get_new_thread()
    print(await agent.run("How many SKU-7421 are at SEA-01?", thread=thread))

SKILL незаметно навязал:

  • конфиг через переменные окружения,
  • именованные function tools с докстрингами,
  • паттерн с sys.path и лоадерами,
  • HostedMCPTool рядом с функциями,
  • использование Thread для многотурового диалога.
  1. Валидация
    Coding Agent запускает:

    • smoke‑тест по фикстурам (например, SKU-7421 @ SEA-01 → 312),
    • eval‑набор (eval_queries.jsonl): правильный инструмент? есть ожидаемый факт в ответе?,
    • red‑team‑прогоны.

    Пример отчёта: «3/3 acceptance‑критериев выполнены. Eval 5/5. Prompt‑инъекций не прошло».

  2. Артефакт‑bundle
    В репо попадает не только скрипт, но и:

    • определение агента,
    • инструменты,
    • eval‑строки,
    • краткий README.
      Всё в одном стиле и с общими фикстурами.

Что входит в «агента» как продукт

Coding Agent создаёт восемь типов артефактов:

  • Source code — программы агентов и воркфлоу.
  • Agent definitions — имя, инструкции, список инструментов (редактируются отдельно от кода).
  • Workflows — графы WorkflowBuilder для многоагентных сценариев.
  • Skills (runtime) — переиспользуемые способности, которые могут вызывать разные агенты.
  • Connectors — MCP‑серверы и регистрации Toolbox‑инструментов.
  • Evalseval_queries.jsonl и обвязка для прогонов.
  • Tests & configs — юнит‑тесты, схема .env, манифесты деплоя.
  • Документация — README и runbook’и.

Важно не путать понятия:

  • SKILL (верхний регистр) — файл для Coding Agent на этапе сборки.
  • Skill (Agent Skill в Foundry) — runtime‑способность, которую вызывает рабочий агент.

Publish & Deploy

Когда все проверки зелёные, артефакты уходят дальше:

  • В Microsoft Foundry
    Регистрируются agent definitions, Skills, Toolbox‑инструменты и кастомные eval’ы в рамках проекта Foundry. Всё версионируется и попадает под политику и мониторинг.

  • В Azure
    Разворачиваются runtime‑хосты: сервер AG‑UI, воркеры воркфлоу, приложения для Teams, API.
    Поддерживаются разные варианты: App Service, Container Apps, AKS, Functions. Те же переменные окружения работают локально и в облаке.

Runtime Agent: что происходит во время диалога

Runtime Agent — это конкретный объект вида:

agent = client.create_agent(
    name="Zara",
    instructions="You are Zara, the warehouse assistant for Seattle DC.",
    tools=[stock_lookup, po_lookup, warehouse_docs_mcp],
)
``

Внутри цикла агент:
- планирует следующий шаг,  
- выбирает и вызывает инструмент,  
- обновляет thread и память,  
- стримит ответ в канал (Teams, веб, и т.д.).

### Инструменты и интеграции

У Runtime Agent есть четыре типа возможностей:

1. **Function tool**  
   Обычная функция в процессе агента. Подходит для вычислений, запросов к БД, работы с фикстурами.

2. **MCP tool**  
   Внешний MCP‑сервер. Хорош для возможностей, которыми владеет другая система, но которые нужны агенту.

3. **Toolbox tool**  
   Инструмент на стороне Foundry, общий для всех агентов в тенанте. Нужен, когда одну и ту же интеграцию используют несколько агентов, и её нужно централизованно контролировать.

4. **Agent Skill**  
   Комбинация инструментов и политики, оформленная как одна именованная способность.

Логика эволюции простая: начали с локальных функций, как только второй агент трогает тот же домен — выносите в Toolbox и Skills.

### Память и состояние

Состояние делится на два вида:

- **Thread** — состояние внутри одной сессии.  
  Пример:

```python
thread = agent.get_new_thread()
await agent.run("Look up PO-1043.", thread=thread)
await agent.run("And its supplier?", thread=thread)  # агент помнит контекст
  • Memory (Foundry Memory) — долговременные факты о пользователе: VIP‑статус, предпочтения упаковки, временные окна доставки. Это не лог чата, а устойчивые знания.

Workflows и действия

Агенты не только отвечают текстом, но и:

  • триггерят события (запуск воркфлоу, уведомление человека),
  • создают артефакты (PO, письма, записи в системах),
  • обновляют внешние каналы (Teams, дашборды, вебхуки).

За сложные сценарии отвечает WorkflowBuilder в Agent Framework. Важные возможности:

  • переиспользование инструментов, написанных на build‑этапе, как узлов воркфлоу,
  • Human‑in‑the‑Loop: воркфлоу может остановиться, дождаться решения человека и продолжить с того же шага,
  • checkpointing: воркфлоу переживает рестарты процессов.

Общие сервисы безопасности и управления

Оба слоя опираются на инфраструктуру Azure:

  • Microsoft Entra ID — аутентификация пользователей и агентов, managed identity для вызова инструментов.
  • Microsoft Defender for Cloud — защита compute и data‑плоскости агентов.
  • Microsoft Sentinel — SIEM, который связывает действия агентов с сигналами безопасности.
  • Azure Key Vault — секреты, ключи и строки подключения живут здесь, а не в коде или .env в git.
  • Azure Monitor / Application Insights — наблюдаемость за каждым поворотом агента, вызовом инструмента и шагом воркфлоу.
  • Azure Policy и governance — кто и где может деплоить, какие ресурсы доступны.

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

Когда это действительно полезно

  1. У вас несколько агентов или команд, и вы устали от «одноразовых ботов»
    SKILL + Agent Framework помогают превратить разрозненный зоопарк в общую архитектуру:

    • единые паттерны кода,
    • общие инструменты через Toolbox и Skills,
    • общий eval‑набор и метрики.
  2. Вы хотите, чтобы Copilot писал код как senior из вашей команды, а не «как попало»
    SKILL позволяет зашить в Copilot:

    • ваш стиль кода,
    • вашу структуру проекта,
    • ваши соглашения по конфигам и логированию.
      Результат ближе к тому, что написал бы техлид, а не «обобщённый» ИИ.
  3. У вас строгие требования к проверкам и безопасности
    Подход Microsoft делает eval и red‑teaming частью сборки, а не «когда‑нибудь потом».
    Для enterprise‑среды это критично: вы разворачиваете не просто «агента», а артефакт с измеримой точностью и отчётом по атакам.

  4. Вы уже в Azure и используете Microsoft 365
    Runtime Agents легко вывести в Teams и Outlook.
    Foundry и Agent Framework хорошо вписываются в существующие процессы безопасности и мониторинга.

  5. Вы хотите многоагентные сценарии и HITL‑воркфлоу
    WorkflowBuilder закрывает кейсы, где нужно:

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

Когда это может быть избыточно

  1. Один простой бот без интеграций
    Если вам нужен чат‑бот с FAQ без доступа к внутренним системам, Agent Framework и Foundry могут оказаться слишком тяжёлым решением. Проще обойтись готовым Copilot’ом или лёгким backend’ом.

  2. У вас нет Azure и Microsoft 365 в продакшене
    Технология завязана на Azure, Foundry и экосистему Microsoft. Если инфраструктура строится вокруг других облаков и вы не планируете Azure, придётся закладывать миграцию.

  3. Небольшие команды без процессов разработки
    Если у вас ещё нет культуры тестов, eval‑наборов и code review, придётся сначала выстроить базовые практики. Agent Framework не заменяет инженерную дисциплину, он её масштабирует.

Доступность из России

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

Практический совет: как использовать

  • Если вы руководите платформенной командой — начните с описания одного SKILL под ваш стек и один репозиторий‑пример. Сделайте «эталон» агента с eval‑набором и выложите его как внутренний стандарт.
  • Если вы разработчик — заведите привычку: перед каждым запросом Copilot’у открывайте SKILL и смотрите, какие паттерны он ожидает. Это сильно повышает качество результата и облегчает ревью.
  • Если вы продукт‑менеджер — описывайте задачи не как «сделай бота», а как в примере ZavaShop: конкретная боль (Mei получает 60 вопросов про остатки в день), фикстуры и измеримые acceptance‑критерии.

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

Microsoft здесь делает ставку не на очередную LLM, а на инженерную методологию вокруг агентов.

По сравнению с «голым» GitHub Copilot

  • Без SKILL Copilot — «общий» помощник по коду. Он часто знает библиотеки, но не знает ваш фреймворк, ваши фикстуры и соглашения.
  • С SKILL и Agent Framework Copilot превращается в Coding Agent, который:
    • знает, как создавать AzureAIAgentClient,
    • автоматически подключает MCP и Toolbox,
    • сразу пишет eval‑наборы и тесты.

Чётких цифр по повышению качества кода Microsoft не приводит, но сам факт появления формализованного SKILL‑контракта — шаг к тому, чтобы Copilot перестал быть просто «автодополнением» и стал инструментом для воспроизводимой генерации артефактов.

По сравнению с «агентами в вакууме» (LLM + HTTP‑эндпоинт)

Многие команды строят агентов поверх GPT‑5 или Claude 4 как набор prompt’ов и HTTP‑запросов. Microsoft предлагает:

  • Общий SDK (Agent Framework) для Python и .NET вместо самописных обвязок.
  • Платформу (Foundry) для:
    • хранения и версионирования определений агентов и Skills,
    • централизованных Toolbox‑инструментов,
    • eval‑наборов и red‑teaming.

Прямых сравнений по скорости или стоимости с решениями на GPT‑4o, GPT‑5 или Claude 4 Microsoft не даёт. Основной фокус — не на LLM, а на архитектуре и процессе вокруг неё.

Для кого это конкурентное преимущество

  • Enterprise‑команды на Azure получают нативную интеграцию с Entra ID, Defender for Cloud, Sentinel, Key Vault и Azure Monitor. Это снижает барьер для запуска агентов в продакшене.
  • Команды с сильной инженерной культурой могут переложить свои стандарты в SKILL и масштабировать их на все будущие агенты.

Установка

Ниже — шаги из официального воркшопа ZavaShop. Они показывают, как быстро развернуть среду и запустить Coding Agent.

git clone https://github.com/microsoft/Learn-Microsoft-Agent-Framework-with-Foundry-ZavaShop-Supply-Chain-Workshop
cd Learn-Microsoft-Agent-Framework-with-Foundry-ZavaShop-Supply-Chain-Workshop

# Foundry prereqs: gpt-5.5 + text-embedding-3-small deployed in your Foundry project
az login --use-device-code

# Python track
python -m venv .venv && source .venv/bin/activate
pip install agent-framework agent-framework-azure-ai agent-framework-ag-ui \
            azure-identity python-dotenv fastapi "uvicorn[standard]"

# .NET track
dotnet --version   # ≥ 10.0.100

# .env at repo root
cat > .env <<EOF
FOUNDRY_PROJECT_ENDPOINT=https://<your-project>.services.ai.azure.com/api/projects/<project-name>
FOUNDRY_MODEL=gpt-5.5
AZURE_OPENAI_EMBEDDING_MODEL=text-embedding-3-small
AGUI_SERVER_URL=http://127.0.0.1:5100/
AG_UI_API_KEY=zava-control-tower-demo-key
EOF

# In VS Code → Copilot Chat → Agent Mode → pick zavashop-coding-agent
# Then say: "I'm working on the inventory agent in Python — meet Mei."

После этого Coding Agent в VS Code начнёт работать по описанному выше сценарию: прочитает SKILL, спланирует артефакты, сгенерирует код и запустит проверки.

Как запустить и что вы получите в воркшопе ZavaShop

Артефакты Layer 1 (build time)

В репозитории ZavaShop уже лежит всё для изучения архитектуры:

  • .github/agents/zavashop-coding-agent.agent.md — определение Coding Agent’а.
  • .github/skills/agent-framework-{azure-ai,workflows,agui}-{py,csharp}/ — шесть SKILL‑файлов.
  • workshop/data/ — общие фикстуры (склады, SKU, PO, клиенты, поставщики, контракты, заказы, перевозчики, инциденты).
  • README для каждой лабораторной + eval_queries.jsonl — входные данные для проверки Layer 1.

Артефакты Layer 2 (runtime), которые вы соберёте по ходу воркшопа

  • Zara — складской агент с function tools, HostedMCPTool и Thread.
  • Pierre — агент закупок с Toolbox‑инструментами, Agent Skills и политикой approvals.
  • Aria — агент поддержки клиентов с Foundry Memory, eval‑набором и red‑team‑отчётом.
  • Diego — многоагентный фулфилмент‑воркфлоу на WorkflowBuilder с HITL и checkpointing.
  • AG‑UI control tower для CEO — React‑дашборд, который демонстрирует все 7 возможностей AG‑UI: стриминг, фронтенд/бэкенд‑инструменты, shared state, generative UI, predictive updates, HITL.

Везде используется одна и та же пара моделей: gpt-5.5 и text-embedding-3-small. Меняете переменную окружения — и запускаете тот же стек на Python или C#.

Три привычки сильного инженера агентов

  1. Всегда начинайте со SKILL
    Coding Agent делает это автоматически. Делайте то же самое, когда ревьюите его код: откройте SKILL и спросите себя, насколько результат ему соответствует.

  2. Относитесь к инструментам как к публичному API
    Имена, сигнатуры, докстринги, формат возвращаемых данных — это то, как модель «видит» вашу систему. Плохой дизайн API = плохое поведение агента. Рефакторьте инструменты так же тщательно, как обычные публичные методы.

  3. Сначала измеряйте, потом тюньте
    Изменение prompt’а без изменения метрик — это просто ощущение. Eval‑набор с числовыми результатами превращает тюнинг в инженерную задачу.

Если вы ищете ответ на вопрос «как нам строить агентов в компании, а не играться с демо», архитектурная связка SKILL + Agent Framework + Foundry — это конкретный, воспроизводимый путь: от одной фразы требований до валидированного и развернутого агента.


Читайте также