microsoft-foundry

Этот официальный навык Microsoft описывает жизненный цикл AI-агентов в Microsoft Foundry через azd и связанные workflow. В его область входят scaffold, запуск и deploy hosted agent, создание prompt agent, добавление инструментов, вызов агента, batch evaluation, continuous evaluation и monitoring. Там же собраны prompt optimizer, Agent Optimizer, подготовка agent.yaml, отбор датасета из traces и настройка fine-tuning с SFT, DPO и RFT. Это карта процессов Foundry, а не утверждение, что конкретный проект уже имеет ресурс, права, квоту или опубликованную версию агента. Навык задаёт строгую последовательность перед выполнением действий. После загрузки нужно запустить check-and-setup-dependencies.sh на macOS или Linux либо соответствующий PowerShell-скрипт в Windows и дождаться его завершения. Для конкретного workflow сначала читается его sub-skill документ: deploy, invoke, observe, trace, troubleshoot, create, quota, RBAC и другие ветви имеют собственные проверки. Перед azd-командой требуется прочитать azd-guidance, а перед операциями Foundry MCP — вызвать Azure MCP foundry-инструмент и посмотреть доступные операции и параметры. Эти границы не дают заменить проверку окружения догадками. Подбор маршрута зависит от задачи. Публичный проект, ресурс AI Services и сетевой вариант с VNet относятся к разным workflow; деплой существующего агента отличается от создания нового. Для оценки и улучшения сначала выбирается observe, для анализа traces — trace, для журналов и телеметрии — troubleshoot, а для ролей и разрешений — RBAC. Fine-tuning вынесен в отдельный workflow: в нём рассматриваются SFT-дистилляция, DPO-предпочтения, RFT с graders, загрузка больших файлов, выбор checkpoint и последующая оценка. Общие команды Azure deployment или Azure Functions этим навыком не заменяются. Для локального состояния агент может использовать каталог .foundry рядом с исходниками. В нём допускаются agent-metadata.yaml и environment-specific overlay, suites, datasets, evaluators и results. Deployment-контекст в azd-проекте выводится из azure.yaml и azd env get-values: endpoint проекта, имя и версия агента, registry и Application Insights не следует дублировать в metadata, если их уже предоставляет azd. Локальный metadata-файл хранит только непроизводные overlays и кэш удалённых ссылок после успешного remote lookup или регистрации. При разрешении контекста сначала ищется сервис azure.ai.agent в azure.yaml, затем подходящий .foundry metadata-файл. Если кандидатов несколько, выбор нельзя делать молча. Environment определяется явным вводом, azd-конфигурацией или единственной средой в metadata; расходящиеся значения из azd и metadata требуют решения, а не автоматического слияния. eval.yaml трактуется как локальное намерение: его suite, dataset, evaluator и модель нужно подтвердить удалённо перед сохранением ссылки. Если контекст уже известен из пользователя или предыдущего шага, повторное разрешение не требуется. Навык различает два типа агентов: prompt, основанный на model deployment, и hosted, работающий как контейнерный код. Для hosted-проекта важны azd и его переменные окружения, для prompt-сценариев — доступные Foundry MCP операции. В любом случае результатом должны быть проверяемые входы, целевой environment и подтверждённый ответ сервиса. Документ не обещает исправить RBAC, доступность модели, региональную capacity, quota, качество промпта или ошибки приложения без фактических проверок. Рискованные действия, публикация версии, выдача ролей и изменение production остаются отдельными шагами с review и smoke-проверкой.