В документации Microsoft Learn отдельно описаны разработка, развёртывание и использование агентов в жизненном цикле Foundry Agent Service (обзор жизненного цикла).
Симптом: агент работает у разработчика, но команда не может доказать готовность к выпуску. Решение: проверяйте всю цепочку — от опубликованной версии и прав вызывающего до журналов и отработанного возврата; пока критические условия не подтверждены, ограничьте использование контролируемым пилотом.
Эта проверка предназначена для инженеров, отвечающих за развёртывание Microsoft Foundry Agent Service.
Руководители платформы смогут использовать результаты для решения о допуске.
Специалисты по безопасности и данным — сверить полномочия, сетевые ограничения и границы передачи информации.
Граница приёмки: рабочий запуск ещё не означает готовность
Локальная проверка отвечает на вопрос, может ли код агента выполнить задачу в подготовленной среде. Приёмка перед корпоративным запуском должна ответить на другое: можно ли вызвать нужную опубликованную версию предусмотренным способом, с ожидаемыми полномочиями и без обхода установленных ограничений — и сможет ли команда объяснить сбой или прекратить использование проблемной версии.
Не смешивайте эти этапы. В описании публикации приложений агентов публикация выделена как самостоятельная операция. А инструкции по развёртыванию и проверке размещённого агента задают отдельный контекст для размещения и проверки. Возможности и поля состояния следует сверять с актуальной документацией, а не переносить из старого скриншота или чужой конфигурации.
Перед началом зафиксируйте границы проверки: какая среда рассматривается, какую версию проверяют, кто вызывает агент и какие источники данных или инструменты доступны. Эта процедура помогает принять техническое решение, но не заменяет внутреннее согласование по защите данных, управлению изменениями и отраслевым требованиям. Даже полностью пройденный тест не даёт автоматического разрешения на доступ к данным, которые организация не разрешала обрабатывать.
На практике разработчик может успешно запускать агента из тестовой среды, тогда как корпоративное приложение обращается к другому endpoint или использует иную идентичность. Это не «мелкая разница окружений»: результат разработки не доказывает работоспособность опубликованного пути. В журнале приёмки должны быть указаны проверяемая версия, точка входа, вызывающая сторона и ссылка на свидетельства.
Профиль проверки: что сравнить перед выпуском
Выберите режим проверки до выполнения тестов. Таблица помогает отделить цель внутренней разработки от допуска пилота и эксплуатации. Это не означает, что служба предоставляет один универсальный набор настроек для всех проектов: конкретные возможности и требования зависят от выбранного способа развёртывания, ресурсов и сетевой конфигурации.
| Режим | Что требуется подтвердить | Решение по результату |
|---|---|---|
| Разработка | Агент выполняет задачу в изолированной среде; ограничения тестовых данных и инструментов зафиксированы | Продолжить подготовку, но не считать это подтверждением готовности к выпуску |
| Контролируемый пилот | Опубликованный агент вызывается назначенным клиентом; идентичность, доступные данные, наблюдение и ответственный за остановку определены | Допустить только согласованный сценарий и объём доступа |
| Производственная эксплуатация | Вызовы, разрешения, сеть, журналы, владельцы и возврат версии проверены в условиях целевого процесса | Выпускать только после закрытия обязательных замечаний и внутренних согласований |
Владельца проверки назначьте заранее: без ответственного за каждый блок легко получить набор технически верных наблюдений, из которых никто не делает итогового вывода. Минимально разделите ответственность за развёртывание, управление доступом, сетевую конфигурацию, мониторинг и решение о выпуске. Один человек может выполнять несколько ролей, но в записи должно быть понятно, кто именно подтверждает каждый результат.
Опубликованная версия и вызывающий endpoint
Проверка цепочки вызова отвечает на частый вопрос команды: как удостовериться, что опубликованный endpoint вызывает именно ожидаемую версию? Начните с сопоставления конфигурации развёртывания и записи публикации. Запишите идентификатор или другое доступное обозначение версии, её состояние по актуальной документации, целевой endpoint и вызывающее приложение. Если в интерфейсе или API используются меняющиеся поля состояния, не закладывайте в инструкцию неподтверждённое название: приложите ссылку на соответствующую текущую страницу Microsoft Learn.
После этого пройдите сценарии вызова с предусмотренным клиентом. Зафиксируйте успешный запрос и ответ, затем проверьте ввод, который агент не должен обрабатывать, и запрос без требуемых полномочий. Для каждого случая укажите ожидаемый результат и фактическое наблюдение: например, отказ в доступе, контролируемая ошибка или корректный ответ. Само наличие endpoint не является доказательством стабильности вызова — важны используемая идентичность, ответ на ошибки и соответствие целевой версии.
Для воспроизводимости сохраните безопасный пример запроса, время выполнения проверки, контекст вызывающей стороны и доступные идентификаторы операции. Не копируйте секреты, токены или персональные данные в отчёт. Если ответ приходит, но его нельзя связать с публикацией и конкретным запросом, цепочка остаётся недостаточно наблюдаемой для приёмки.
Отдельно проверьте, кто имеет право вызывать endpoint и кто может менять опубликованный ресурс. Сопоставьте назначенные роли с описанием RBAC для Foundry: важны не только названия ролей, но и область действия назначений. Не заменяйте такой разбор формулировкой «у команды есть доступ» — уточните субъект, ресурс, разрешённое действие и владельца решения.
Идентичность, права и границы данных
В корпоративном сценарии права — это не одна настройка. Проверке подлежат идентичность агента, роли участников проекта, доступ к связанным ресурсам и полномочия внешних инструментов. Сверьте фактическую конфигурацию с официальным описанием идентичности агента и авторизации и отдельно отметьте, какие разрешения необходимы выбранной архитектуре. Не предполагайте, что требования одного размещения автоматически подходят для другого.
| Объект проверки | Что записать в свидетельствах | Признак незакрытого риска |
|---|---|---|
| Идентичность агента | Какой субъект используется, к каким ресурсам он обращается и где проверены разрешения | Неясно, от чьего имени выполняется операция |
| Роли участников | Кто развёртывает, изменяет, вызывает и просматривает ресурсы; область назначения каждой роли | Широкие права выданы без обоснования либо владелец неизвестен |
| Инструменты и данные | Какие сервисы и источники доступны; какие операции разрешены; как ограничен ввод и результат | Инструмент способен передать данные за пределы утверждённого процесса |
| Сеть | Какой вариант подключения настроен и какие ограничения подтверждены в целевом окружении | Команда считает сеть изолированной, но не предъявляет конфигурацию или тест |
Для каждого инструмента составьте короткую карту потока данных: откуда берётся ввод, что агент отправляет инструменту, что возвращается и где сохраняется результат. Проверьте эту карту на соответствие ограничениям организации. Рекомендации Microsoft по защите инструментов агентов полезны для анализа типовых рисков вызова, но команда всё равно должна проверить собственные схемы, обработку ответов и полномочия интеграций.
Данные и идентичность рассмотрите совместно. Если агенту разрешено обращаться к источнику, выясните, какие пользователи смогут инициировать такой вызов и как ограничивается содержание запроса. Если на выходе скрываются чувствительные поля, проверьте не только обычный ответ, но и доступные инструменты, промежуточные результаты и журналы. Описание конфиденциальности и безопасности данных для агентов поможет сопоставить общие меры с документацией, но не подтверждает автоматически безопасность конкретной интеграции.
Сетевые правила также проверяйте на фактическом пути, а не по схеме в презентации. Запишите выбранную модель сетевого подключения, используемые ресурсы, ограничения входящего и исходящего трафика и результат проверки из клиентского окружения. Сверьте решение с актуальным руководством по сетевым возможностям Foundry Agent Service. Если агент публикуется для конкретной среды взаимодействия, например через корпоративный канал, проверьте требования именно этого сценария — для публикации Copilot в виртуальной сети они описаны отдельно в документации по сетевой конфигурации публикации.
Не ставьте отметку «сеть проверена» только потому, что агент отвечает из одной среды. Для приёмки нужен результат проверки из того клиентского пути, который действительно будет использоваться, и объяснение, какие маршруты остаются разрешёнными.
Журналы и разбор контролируемого отказа
Команда должна уметь обнаружить не только успешное выполнение, но и причину неуспешного вызова. Проведите нормальный сценарий и контролируемый сбой — например, запрос с отсутствующим разрешением или заранее выбранный недопустимый ввод. Оба случая должны оставлять достаточно информации, чтобы связать наблюдение с действием, опубликованной версией и ответственным компонентом.
Проверьте, доступны ли сведения о состоянии развёртывания, приложении и ошибке вызова тем, кто дежурит или разбирает инцидент. Убедитесь, что команда знает место просмотра, нужный уровень доступа, период доступности записей и процедуру передачи инцидента. Названия разделов и доступные поля сверяйте с актуальным описанием мониторинга агентов Foundry: интерфейс и состав наблюдений могут зависеть от конфигурации.
Не придумывайте порог задержки или долю успешных ответов, если у команды нет утверждённого источника и методики измерения. Сначала зафиксируйте, какой набор запросов используется, какие ошибки считаются критичными и кто утвердил критерии для конкретного процесса. Если числовые эксплуатационные цели уже заданы внутри организации, приложите ссылку на них и покажите, как собраны результаты. В противном случае приёмка может опираться на явно описанные функциональные сценарии и обработку отказов, а не на неподтверждённые показатели.
Версия и возврат к рабочему состоянию
Проверьте, можно ли однозначно определить проверенную публикацию, сравнить её с предлагаемым изменением и установить, кто вправе выполнить возврат. Документация о публикации описывает поддерживаемые операции, но наличие функции не доказывает, что процесс команды безопасен. Уточните, какие артефакты сохраняются, как выбирается известная рабочая версия, кто подтверждает переключение и как вызывающая сторона узнает, что маршрут изменился.
Проведите контролируемую репетицию по согласованной процедуре: зафиксируйте исходное состояние, выберите безопасный способ проверить возврат, выполните его с разрешённой учётной записью и подтвердите ожидаемый ответ через тот же клиентский путь. Затем верните конфигурацию к согласованному целевому состоянию и документируйте изменения. Не проводите эксперимент на производственном процессе без разрешения ответственного владельца.
Если безопасно выполнить возврат в целевой среде нельзя, укажите это как «ожидает проверки», а не «подтверждено по документации». При неудачном выпуске команда должна знать, кто принимает решение об остановке, какое состояние восстанавливается и что проверяется после переключения. Это и есть практический ответ на вопрос о проверке версии при сбое: нужен документированный сценарий с подтверждённым исполнителем и наблюдаемым результатом.
Порядок работ перед решением о выпуске
Используйте следующую последовательность как рабочую процедуру, а не как формальность для отчёта:
- Зафиксируйте сценарий использования, среду и проверяемую публикацию. Укажите владельца агента и того, кто принимает решение о выпуске.
- Сопоставьте требования процесса с фактической схемой: вызывающий клиент, endpoint, агент, инструменты, данные и внешние ресурсы.
- Выполните вызов опубликованной версии из целевого клиентского окружения. Сохраните безопасные сведения, позволяющие сопоставить запрос, ответ и состояние публикации.
- Проверьте разрешённый сценарий, недопустимый ввод и отказ при отсутствии требуемого права. Запишите ожидаемое поведение и фактический результат.
- Сверьте идентичности, роли, области доступа и конфигурацию сети с актуальной документацией и ресурсами целевой среды.
- Проведите согласованную проверку журналов и контролируемого отказа. Убедитесь, что назначенный специалист может найти и объяснить событие.
- Репетируйте возврат к известному рабочему состоянию в безопасных условиях, затем оформите решение по каждому замечанию и передайте его владельцу.
Матрица решения и критерии допуска
Для итогового решения используйте три статуса: «пройдено», «ожидает проверки» и «не пройдено». К каждому пункту приложите свидетельство, ответственного и дальнейшее действие. Такой формат позволяет отличить реальную готовность от ситуации, когда команда просто не успела проверить настройку.
| Критерий | Пройдено | Ожидает проверки или не пройдено |
|---|---|---|
| Публикация и вызов | Версия и endpoint сопоставлены; вызовы проверены предусмотренным клиентом | Нет подтверждения версии, вход недоступен или результат нельзя связать с запросом |
| Идентичность и права | Субъекты, роли и область доступа объяснены и сверены с конфигурацией | Неясен субъект вызова, права избыточны или не установлено, кто их меняет |
| Данные и сеть | Потоки данных и ограничения проверены для целевого окружения | Есть непроверенный путь к источнику данных или внешнему инструменту |
| Наблюдение | Назначенный специалист находит сведения о нормальном и ошибочном сценариях | Ошибку нельзя локализовать либо доступ к диагностике не определён |
| Возврат версии | Процедура выполнена или безопасно проверена; ответственный и целевое состояние известны | Возврат существует только как предположение или не определены полномочия |
Решение о выпуске должно учитывать последствия непроверенного пункта, а не только общее количество замечаний. Неизвестная граница доступа к чувствительным данным, неясная идентичность или отсутствие безопасного плана восстановления — основание не расширять доступ. Если эти условия нельзя проверить до выпуска, ограничьте запуск согласованным пилотом либо отложите его. Для пилота отдельно обозначьте доступные функции, пользователей, данные, владельца остановки и условия перехода к следующему этапу.
Для работы платформенной команды можно также сверить внутренние инструкции с инфраструктурной информацией Kvmjet и справочным центром. Эти страницы не заменяют документацию Microsoft по Foundry и не подтверждают параметры вашего облачного проекта; используйте их только для вопросов, относящихся к услугам Kvmjet.
Если текущая проверка зависит от общего рабочего Mac или личного устройства инженера, у такого подхода есть практические ограничения: конфигурация может отличаться между участниками, доступ к тестовой машине зависит от её владельца, а повторить проверку в изолированной среде сложнее. Аренда Mac у Kvmjet может подойти, когда вам нужен отдельный временный узел для проверки клиентской части, скриптов или вспомогательного инструментария на macOS; доступные сведения об инфраструктуре и вариантах размещения смотрите на странице инфраструктуры. Однако такой Mac не заменяет Microsoft Foundry Agent Service и сам по себе не подтверждает облачные права, сетевую изоляцию или возврат версии агента. Сначала закройте не пройденные пункты матрицы в целевой среде Foundry, а затем используйте отдельное оборудование только для тех тестов, где оно действительно воспроизводит ваш рабочий сценарий.
Подготовьте удалённую среду для инженерной команды
Kvmjet предоставляет выделенные Mac mini M4 с полноценной средой macOS для разработки и проверок перед запуском.
Используйте отдельный bare-metal узел для сборок, CI/CD и воспроизводимых тестовых сценариев.