Как проверить развёртывание Foundry Hosted Agents перед Microsoft Build 2027?

В документации Microsoft Learn Foundry Hosted Agents описаны как контейнеризированные приложения на управляемой инфраструктуре. Поэтому одного статуса «развёрнуто» недостаточно: до расширения запуска проверьте протокол, готовность, состояние сеанса, настройки идентификации и реальный путь вызова. На этой неделе сначала воспроизведите эти проверки локально, затем опубликуйте тестовую версию и сравните её поведение с локальным запуском.

Эта инструкция для разработчиков Python и .NET, переносящих локального Agent в Microsoft Foundry Hosted Agents.
Она также пригодится платформенным инженерам, отвечающим за контейнер, готовность приложения и выпуск версии.
Если вы готовите инфраструктуру к Microsoft Build 2027, используйте статью для проверки уже выбранного сценария, а не как подтверждение будущих анонсов.

До публикации оцените пригодность управляемой среды

Hosted Agent уместен, когда вы хотите запускать собственный код в облачной среде, а не ограничиваться настройкой Agent внутри визуального конструктора. Например, ваш код сам координирует вызовы инструментов, обрабатывает входящие запросы или реализует прикладную логику, которую нужно поддерживать как приложение. Microsoft Learn описывает такой вариант как контейнеризированный Agent и публикует отдельные материалы по его контракту и развёртыванию: начните с обзора Hosted Agents, затем сверьте план работ с руководством по развёртыванию собственного кода.

Это не означает, что любая программа, запускаемая на ноутбуке, сразу подходит для размещения. До переноса разберите зависимости и ограничения:

• Файлы и состояние. Проверьте, сохраняет ли приложение важные данные только в локальной файловой системе или рассчитывает на неизменяемое состояние процесса. Не считайте файлы контейнера долговременным хранилищем без прямого подтверждения документацией выбранной среды.
• Сетевые подключения. Перечислите внешние API, внутренние сервисы и адреса, к которым обращается Agent. Успешное подключение с ноутбука не доказывает, что те же адреса доступны из облачной среды.
• Секреты и идентификация. Найдите токены и учётные данные в переменных окружения, файлах конфигурации, локальном профиле разработчика и журналировании. Удалите секреты из образа и репозитория; отдельно проверьте, от чьего имени выполняются исходящие вызовы после публикации.
• Запуск процесса. Зафиксируйте команду запуска, рабочую директорию, необходимые переменные и то, как приложение сообщает, что готово принимать запросы. Если процесс начинает принимать запросы до окончания инициализации, это нужно обнаружить до выпуска.
• Неподдерживаемые допущения. Уточните в документации требования к контейнеру, конфигурации, языковой среде и выбранному способу выпуска. Не переносите локальные предположения в облако как гарантированную платформенную возможность.

До выбора архитектуры полезно разделить две задачи: что предоставляет Microsoft Foundry Agent Service, а что обязан гарантировать ваш код. Управляемое размещение упрощает запуск приложения в платформе. Оно не заменяет проверку бизнес-логики, корректной обработки входа, вызова инструментов и безопасного обращения с секретами.

Используйте таблицу как выбор среды, а не как сравнение производительности: приведённые варианты решают разные задачи. Для проверки именно поведения Hosted Agent решающим остаётся вызов развёрнутой версии в целевой среде.

До публикации подготовьте локальную проверку

Сначала подготовьте воспроизводимую копию приложения. Соберите проект тем способом, который предполагаете использовать при публикации. Зафиксируйте зависимости, исходный код, параметры запуска и неконфиденциальную тестовую конфигурацию. Если локальная проверка проходит только с секретом разработчика или его сохранённой сессией, не считайте результат готовым для облака.

Дальше проверьте входной и выходной контракты. В документе Microsoft о контракте Hosted Agent сверьте выбранный протокол, формат запроса, формат ответа и правила обработки ошибок. Используйте точные поля и требования текущей документации для своего сценария: не копируйте старый пример только потому, что он похож на вашу реализацию.

Покройте тестами не только обычный запрос, но и условия, при которых приложение часто ведёт себя иначе:

• Запрос с ожидаемыми данными. Передайте валидный вход, проверьте, что приложение его разбирает и возвращает ответ ожидаемого формата. Для повторного теста сохраните вход и результат, не включая реальные секреты.
• Неполный или неверный вход. Убедитесь, что приложение возвращает понятный ответ об ошибке, а не зависает и не завершает процесс без объяснения. Сверьте формат реакции с контрактом.
• Потоковая выдача. Если ваша реализация использует потоковый ответ, проверьте начало, продолжение и завершение потока на стороне клиента. Наличие SDK само по себе не подтверждает, что приложение правильно формирует все части ответа.
• Продолжение сеанса. Отправьте связанные запросы так, как их отправит реальный клиент. Установите, где хранится контекст и что именно позволяет восстановить связь между обращениями. Не делайте вывод о сохранности состояния только по тому, что локальный процесс остаётся запущенным.
• Сбой инструмента или внешнего API. Вызовите ошибку контролируемым способом и проверьте, какую информацию получает клиент, что попадает в журнал и не утекает ли туда секрет.

Готовность процесса и правильный ответ — разные проверки. Сначала установите, что приложение действительно готово принимать запросы; затем отдельными вызовами проверьте результат, ошибку и продолжение разговора.

Контракт запросов и проверку готовности проверяйте раздельно

Сопоставьте обработчики приложения с контрактом Hosted Agent. Для каждого типа запроса зафиксируйте входные поля, обязательную валидацию, формат успешного ответа и поведение при исключении. Затем проверьте, что клиент может распознать успешное завершение, ошибку и потоковую выдачу, если она предусмотрена вашей реализацией. Ориентируйтесь на официальное описание runtime contract, а не на догадки о том, что «обычно делает SDK».

Проверку готовности также нужно разделить на приложение и платформу. На уровне приложения определите, какие условия должны выполниться до приёма трафика: например, завершилась ли инициализация необходимых компонентов и доступны ли обязательные конфигурационные значения. На уровне публикации сверьте требования к проверке состояния с текущим руководством для выбранного варианта размещения. Не назначайте произвольный путь, код ответа или интервал опроса как будто это универсальная настройка Hosted Agents.

Запишите результаты каждого теста: вход, ожидаемый результат, фактический ответ и относящуюся к нему запись журнала. Это даст вам базу для сравнения после публикации. Если локально проверяется только «успешный ответ» без негативного сценария и готовности, расширять запуск рано.

При публикации проверьте упаковку и состояние версии

Перед отправкой кода определите способ публикации, поддерживаемый текущей версией документации для вашей среды. В актуальном руководстве Microsoft по развёртыванию Hosted Agent проверьте названия действий, команд и параметров. Команды и SDK могут меняться: не переносите старые фрагменты в производственный сценарий, не сверив их с текущим руководством.

Практический порядок удобно организовать так:

• Подготовьте пакет. Убедитесь, что в сборку входят исходники и необходимые зависимости, а локальные файлы с секретами исключены. Сверьте стартовую команду и конфигурацию с тем, что прошло локальный тест.
• Создайте тестовую версию. Используйте поддерживаемый для выбранного способа публикации процесс. Не считайте отправку пакета доказательством того, что код успешно запустился.
• Дождитесь состояния, допускающего проверку. Сопоставьте отображаемое состояние версии с определениями в официальной документации. Если публикация остаётся в промежуточном или ошибочном состоянии, сначала исследуйте причину, а не переключайте на неё реальный поток запросов.
• Зафиксируйте связь между версией и кодом. Сохраните идентификатор версии, исходную ревизию и конфигурацию, с которой проводился тест. Так вы сможете отличить проблему нового кода от случайного изменения окружения.
• Вызовите именно опубликованную версию. Используйте разрешённый для вашего приложения способ обращения и тестовую нагрузку. Локальный запрос не заменяет проверку опубликованного endpoint.

Если запуск не проходит, изучайте журналы конкретной попытки и этапа, а не повторяйте публикацию без изменений. В официальном руководстве по отладке сверьте рекомендуемый путь поиска проблемы. Разделяйте ошибки упаковки, старта процесса, готовности, аутентификации и обработки запроса: у этих групп разные причины и разные действия по исправлению.

Не подменяйте тестовый пример из документации конфигурацией Hashvps. Документация Microsoft объясняет процесс на стороне Foundry; доступные параметры, условия доставки и состав услуг Hashvps проверяйте отдельно по описанию пакетов Hashvps.

После публикации подтвердите состояние сеанса и идентификацию

Когда тестовая версия доступна для вызова, пройдите последовательность действий в той же конфигурации, в которой будет работать клиент. Успешный ответ на одиночный запрос не подтверждает правильность состояния сеанса, а действительный токен разработчика не подтверждает, что приложение использует ожидаемую идентификацию в облаке.

Сначала отправьте обычный запрос и сверьте результат с локальной записью: формат, содержание, завершение и отсутствие лишних диагностических данных. Затем отправьте связанный запрос с тем контекстом или идентификатором, который использует клиент. Проверьте, относится ли ответ к ожидаемому сеансу, не смешиваются ли данные параллельных обращений и не теряется ли контекст при новой публикации или перезапуске. Эти свойства определяются вашим приложением и его моделью хранения; не делайте вывод о поведении продукта без собственного теста.

Далее проверьте неуспешные варианты: неверные данные, отсутствующая идентификация, отказ инструмента и временно недоступная зависимость. Запишите, что видит клиент, что получает журнал и какие действия требуются для восстановления. Отдельно убедитесь, что ошибка не превращается в успешный ответ с пустым или вводящим в заблуждение содержимым.

Права проверяйте от источника к назначению. Уточните, каким способом приложение получает учётные данные, какой ресурс оно вправе вызывать и кто отвечает за обновление конфигурации. Сверьте подход с текущей документацией вашей среды; не помещайте токен в код, образ или открытый журнал. При сомнении повторите тест с учётными данными, у которых намеренно нет доступа к тестируемой зависимости: предсказуемый отказ помогает подтвердить, что проверяется именно нужный путь авторизации.

Для диагностики сопоставляйте ответ клиента с журналами и трассировками. Microsoft публикует отдельные инструкции по журналам Hosted Agent и настройке трассировки Agent. Это материалы о доступных средствах наблюдения, а не гарантия того, что именно ваша бизнес-операция корректно трассируется. Проверьте, что в выбранной конфигурации действительно видны нужные события и что диагностические данные не раскрывают чувствительную информацию.

В первую неделю зафиксируйте основания для расширения испытания

После выпуска команда должна сама выбрать наблюдаемые показатели и границы реакции. Записывайте категории ошибок вызова, повторные попытки, сбои сеансов, изменения конфигурации и версию кода, которая отвечала на запрос. Это внутренние контрольные показатели команды, а не обещанные Microsoft значения задержки, доступности или качества.

Сравнивайте поведение тестового запуска с локальной базой. Если запросы завершаются ошибкой после смены версии, проверьте сначала связь между версией и конфигурацией. Если клиент получает ответ, но контекст теряется в следующем сообщении, проверьте обработку сеанса и место хранения состояния. Если ошибки видны только в облачной среде, сопоставьте идентификацию и доступность зависимостей, а затем изучите журналы и трассировку.

Расширяйте испытание только после того, как команда может объяснить типичные отказы и знает, как вернуть приложение к последней проверенной версии. Если причина сбоев не установлена, сессии ведут себя непредсказуемо или журналирование не помогает локализовать проблему, остановите расширение и исправьте сценарий. Проверить состояние пакета и получить помощь по процессу аренды Hashvps можно через центр поддержки; это не заменяет диагностику развёртывания в Microsoft Foundry.

Перед решением «расширять или чинить» ответьте на вопросы: воспроизводится ли успешный вызов, распознаётся ли ошибка, сохраняется ли ожидаемая связь между запросами, проверена ли идентификация и можно ли связать результат с конкретной версией. Если хотя бы на один ответ нет подтверждения тестом, оставьте запуск в ограниченном режиме.

Microsoft Foundry Hosted Agents — разумный выбор, когда вам нужно проверить именно работу собственного Agent в управляемой облачной среде. У такого решения остаются операционные обязанности: следить за изменениями платформы и SDK, отдельно проверять сетевые зависимости и поддерживать собственную логику наблюдения. Локальная среда проще для отладки, но не воспроизводит все условия облачного вызова. Удалённый Mac тоже не заменяет Hosted Agents для проверки контейнера в Foundry; он нужен, если разработка или тест зависят от macOS и соответствующих инструментов.

Сначала пройдите проверки выше на существующем окружении. Если вам отдельно нужны временные удалённые ресурсы для работы с Mac-зависимым проектом, изучите предложение Hashvps и сопоставьте его с задачей. Если же цель — принять выпуск Foundry, решение принимайте по результатам тестов в самой целевой среде, а не по факту успешной публикации.