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

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

Тригери

Активуйте цю навичку, коли навчаючий хоче:

• Розгорнути агента в Microsoft Foundry як хостований агент і зробити його версійованим/спостережуваним.
• Обрати між патернами розгортання клієнт-хостований, хостований агент та agent-workflow.
• Додати маршрутизацію моделі, кешування відповідей або обмежену паралельність для контролю затримок та вартості.
• Додати контрольну точку оцінки, щоб погана версія агента не була випущена.
• Додати крок затвердження з участю людини для високоризикових дій.
• Інструментувати агента за допомогою OpenTelemetry для трасування і спостережуваності у виробництві.
• Здійснити smoke-тестування розгорнутого агента як швидке перевірочне gate.

Основна ментальна модель

Агент у виробництві — це здебільшого операційний скелет навколо моделі (~80%), а не сама модель. Зв’язуйте кожну рекомендацію з однією з цих проблем:

Патерни розгортання (оберіть один або комбінуйте)

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

Життєвий цикл (цикл, що випускає агента)

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

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

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

Ключові патерни для відтворення

Направте навчаючого на ці з блокноту 16-python-agent-framework.ipynb:

• Обробник запитів: кеш → маршрутизація за складністю → трасування → виконання → кеш.
• Контрольна точка оцінки: оціночний бал офлайн набору; повертає pass_rate >= threshold і розгортає лише якщо true.
• Затвердження людиною: @tool(approval_mode="always_require") для дій як великі повернення коштів.
• Трасування: обгорнути кожен запит у tracer.start_as_current_span(...) і встановити атрибути як routed.model, customer.id.

Smoke-тестування розгорнутого агента

Після розгортання перевірте, що кінцева точка справді відповідає (зелений розгортання може бути безшумним). Використовуйте дію 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/.

Корпоративний контроль

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

Ограничення для асистента

• Не обіцяйте результати live-Azure, які не перевірили; рекомендуйте процес smoke-тестування для підтвердження розгортання.
• Віддавайте перевагу канонічному патерну FoundryChatClient(...) + provider.as_agent(...), що використовується по всьому курсу.
• Не обіцяйте результати live-Azure, які не перевірили; рекомендуйте робочий процес smoke-test для підтвердження розгортання.
• Тримайте поради з оцінки та вартості разом: оцінка встановлює мінімальний рівень якості, маршрутизація/кешування підтримують витрати близько до цього рівня.

Відмова від відповідальності: Цей документ було перекладено за допомогою сервісу штучного інтелекту для перекладу Co-op Translator. Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ рідною мовою слід вважати авторитетним джерелом. Для критично важливої інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникли внаслідок використання цього перекладу.