deploying-scalable-agents

Развертывание масштабируемых агентов с Microsoft Foundry

Вспомогательное умение для Урок 16 – Развертывание масштабируемых агентов. Используйте его, чтобы помочь учащемуся перевести агента от прототипа к масштабируемому, наблюдаемому производственному развертыванию. Основывайте каждую рекомендацию на содержании урока и исполняемом блокноте; не придумывайте API Foundry.

Триггеры

Активируйте это умение, когда учащийся хочет:

• Развернуть агента в Microsoft Foundry как хостинг-агента и сделать его версионированным/наблюдаемым.
• Выбрать между паттернами развертывания клиент-хостинг, хостинг-агент и агент-воркфлоу.
• Добавить маршрутизацию моделей, кэширование ответов или ограниченную конкуренцию для контроля задержки и стоимости.
• Добавить пропускной контроль оценки, чтобы плохая версия агента не была выпущена.
• Добавить шаг одобрения человеком в цикле для действий с высоким риском.
• Инструментировать агента с помощью OpenTelemetry для трассировки и производственной наблюдаемости.
• Провести дымовое тестирование развернутого агента как быстрый постразверточный пропускной контроль.

Основная концепция

Производственный агент — это в основном операционный скелет вокруг модели (~80%), а не сама модель. Сопоставьте каждую рекомендацию с одной из этих областей:

Область	Прототип → Производство
Хостинг	блокнот → версионированный хостинг-сервис
Идентичность	ваш az login → управляемая идентичность + scoped RBAC
Состояние	в памяти → внешний поток/хранилище памяти
Ошибки	обратная трассировка → повторные попытки, альтернативы, оповещения
Стоимость	"пару центов" → отслеживается, маршрутизируется, кэшируется, бюджетируется
Качество	визуальная оценка → автоматический пропускной контроль оценки
Доверие	ваше одобрение → политика + человек в цикле

Паттерны развертывания (выбрать один или комбинировать)

1. Клиент-хостинг — цикл рассуждений работает в вашем процессе. Максимальный контроль; вы отвечаете за масштабирование/состояние.
2. Хостинг-агент (Foundry Agent Service) — Foundry размещает цикл, хранит потоки, применяет RBAC/безопасность контента, показывает агента в портале. Меньше контроля, значительно меньше операционная нагрузка.
3. Агент-воркфлоу — несколько агентов/инструментов, собранных в граф с ветвлениями, узлами одобрения и постоянными контрольными точками.

Жизненный цикл (цикл, который выпускает агента)

create → version → evaluate (gate) → deploy hosted → observe online → collect failures → repeat. Офлайн-оценка — это пропускной контроль, а не дополнение — версия не выпускается, если она не проходит порог. Онлайн-наблюдаемость возвращает реальные ошибки обратно в офлайн-тестовый набор.

Рычаги масштабирования и стоимости (в приоритетном порядке)

1. Подберите размер модели по необходимости — используйте самую маленькую модель, которая проходит пропускной контроль оценки.
2. Маршрутизируйте по сложности — маленькая/быстрая модель для простых запросов, большая модель для реальных рассуждений (самодельный классификатор или Foundry Model Router).
3. Кэширование — обслуживайте почти дублирующие запросы без вызова модели.
4. Бесп состояния + ограниченная конкуренция — вынесите состояние; повторять с повторной попыткой по экспоненте.

Основные паттерны для воспроизведения

Покажите учащемуся эти из блокнота 16-python-agent-framework.ipynb:

• Обработчик запросов: кэш → маршрутизировать по сложности → спан трассировки → выполнить → кэш.
• Пропускной контроль оценки: оценить офлайн-тестовый набор; вернуть pass_rate >= threshold и разворачивать только если истина.
• Одобрение человеком: @tool(approval_mode="always_require") для действий, например, больших возвратов средств.
• Трассировка: обернуть каждый запрос в tracer.start_as_current_span(...) и установить атрибуты, например, routed.model, customer.id.

Дымовое тестирование развернутого агента

После развертывания проверьте, что конечная точка действительно отвечает (зеленое развертывание может быть тихим). Используйте действие AI Smoke Test через .github/workflows/smoke-test.yml с каталогом в tests/. Запускатель POSTит каждый запрос на POST {project_endpoint}/agents/{agent_name}/endpoint/protocols/openai/responses и проверяет текст ответа. Идентичность должна иметь роль Azure AI User на уровне проекта Foundry; аудитория токена должна быть https://ai.azure.com/.

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

Корпоративные меры контроля

• RBAC: дайте каждому хостингу-агенту управляемую идентичность с минимальными привилегиями.
• MCP в производстве: рассматривайте каждый MCP сервер как ненадежную границу — закрепите версию, ограничьте идентичность, валидируйте выводы, ограничьте частоту, никогда не раскрывайте секреты.

Ограничения для помощника

• Предпочитайте канонический паттерн FoundryChatClient(...) + provider.as_agent(...), используемый по всему курсу.
• Не обещайте результаты живого Azure, которые вы не проверили; рекомендуйте рабочий процесс дымового тестирования для подтверждения развертывания.
• Держите рекомендации по оценке и стоимости связанными: оценка задает нижний предел качества, маршрутизация/кэширование держат стоимость близкой к этому пределу.

---

<!-- CO-OP TRANSLATOR DISCLAIMER START --> Отказ от ответственности: Этот документ был переведен с использованием сервиса машинного перевода Co-op Translator. Несмотря на наши усилия по обеспечению точности, имейте в виду, что автоматический перевод может содержать ошибки или неточности. Оригинальный документ на его исходном языке следует считать авторитетным источником. Для получения критически важной информации рекомендуется обратиться к профессиональному человеческому переводу. Мы не несем ответственности за любые недоразумения или неправильные толкования, возникшие в результате использования этого перевода. <!-- CO-OP TRANSLATOR DISCLAIMER END -->