Знаете, чат-боты разговаривают, агенты действуют, а многоагентные системы действительно что-то делают. Если вы умоляли бота починить Инчун, а он ответил стихотворением, то это для вас. Вот в чем дело. Практическое знакомство с Netflix. Смотрите, ешьте закуски. Я придерживаюсь принципа опасного сервиса, чтобы никто не засурил рабочую среду. Мы создаем миниатюрную самовосстанавливающуюся управляемую многоагентную систему с помощью Azure iPhone 3 и Semantic Kernel. Реальные точки взаимодействия. Инчун, Интро, Граф, Azure Automation, Лок Аналитикс. Один агент против многоагентной системы лицом к лицу, 12 минут против трех. И единственная жертва – мой кредитный баланс подписки. Во-первых, почему один агент тормозит, в то время как Teams работает на ура? Почему одного агента недостаточно? Один агент – это швейцарский армейский нож, который вы купили на заправке. Технически у него есть инструменты, практически он гнется на первом же винтике. Вы пытаетесь втиснуть планирование, обоснование, выполнение, согласование и отчетность в один запрос, и в итоге система испытывает недостаток контекста, работает медленно и странно уверенно в неправильных вещах. Большинство людей думают, чем больше модель, тем больше мозг, и проблема решена. Но настоящая проблема – это путаница ролей. Один агент пытается спланировать изменения, вызвать граф, написать сценарий исправления, запросить согласование, проверить результат и задокументировать его. Это как управлять службой поддержки, доской изменений и анализом ошибок с помощью одного очень уставшего стажера. Вот что происходит на самом деле. Единственный агент жонглирует слишком большим количеством состояний. Ваш запрос превращается в повесть. Окно контекста заполняется логами, политиками и половиной глоссария MDM, поэтому оно либо обрезает важные части, либо искажает недостающие детали. Происходят скачки-задержки, расходуются токены, а повторные попытки ощущаются как дежавю со счетом. И тут на помощь приходит многоагентная система, роли, границы, параллелизм. Планировщик фокусируется на намерениях и ограничениях. Оператор фокусируется на инструментах и выполнении. Рецензент фокусируется на ограничениях, согласованиях и на том, насколько мы опираемся на факты. Каждый агент хранит четкий, короткий набор инструкций с минимальным объемом памяти. Они передают сообщения, результаты работы инструментов или краткое резюме, а не весь интернет. Почему это важно для предприятия? Вам нужны сквозные рабочие процессы с участием человека, действиями, ограниченными рамками идентификации, повторными попытками и журналами аудита. Это не однопоточный чат. Это командная работа. Шаблон, планировщик, исполнитель, рецензент снижает риски и объем доработок, потому что каждый шаг проверяется второй парой глаз, автоматизированных, которые не следят за нашей короткой встречей в Teams. Выигрывают также затраты и задержка. Используйте небольшие языковые модели для извлечения и классификации. Используйте премиальные модели рассуждений только там, где планирование действительно помогает. Запускайте пакетные задания для составления резюме, пока пользователи спят. Вы получите меньше ошибок, более быстрые результаты и меньшие счета. Микроистория. Я видел, как один бот, выполняющий все действия, пытался ротировать секрет. Система обновила ключ, забыла настройку приложения и исправила это, удалив ресурс. В тот день мы изобрели агента-рецензента. Многоагентные системы, основы, ясно и просто. Итак, что же такое многоагентная система, которую можно реально внедрить? Представьте себе цифровую команду, а не одного большого мозга. У каждого агента есть роль, четкий набор инструкций и ограниченный набор инструментов. Планировщик понимает цель, ограничение и среду. Создает план с вызовами инструментов, которые может выполнить оператор. Оператор вызывает инструменты, графы, логические приложения, функции, сценарии автоматизации Азур и возвращает структурированные результаты. Рецензент проверяет обоснованность, соответствие области действия, утверждение и безопасность результатов, прежде чем произойдет что-либо рискованное. Консьерж Мессенджара обрабатывает уведомления, утверждения и сводки для журнала аудита. Они общаются посредством сообщений и общего контекста так, как должны общаться взрослые, кратко, ясно и только-то, что необходимо. Последовательный подход, когда действия зависят от предыдущих результатов. Параллельный подход, когда подзадачи могут безопасно распределяться. Вы не отправляете 50-страничный документ, вы отправляете соответствующий фрагмент, идентификатор устройств и предполагаемые изменения. Инструменты — это руки, REST API для Microsoft Graph, поиск Azure AI для подбора знаний, интерпретатор кода для фрагментов, логические приложения для оркестрированных последовательностей, функции для связывания, автоматизация Azure для повторяющихся задач с устройствами. Структурируйте входные данные инструментов с помощью схем, чтобы оператор не мог произвольно удалять ваш клиент. Память — это не магия, это бюджет. Минимизируйте память на одного агента. Используйте внешние состояния, поисковые индексы, векторные хранилища или небольшое хранилище состояний для метадонных потоков. Держите контекстные окна компактными. Если это не нужно для следующего решения, оно не будет записываться вместе с ним. Планирование против выполнения — вот где семантик Кернелл проявляет себя во всей красе. Планировщик делегирует задачи, оператор выбирает подходящий инструмент с помощью каталогов функций. Рецензент оценивает результаты с помощью подсказок для оценки и обеспечения безопасности контента. Если рецензент указывает на риск, связанный с областью действия, планировщик вносит изменения. Как только вы поймете этот цикл, вы перестанете писать подсказки на 800 слов и начнете четко определять роли. Границы безопасности не подлежат обсуждению. Вызовы инструментов с ограничением по идентификаторам и управляемыми идентификаторами. Разрешения агента разделены между чтением и управлением. Менеджер проектов получает права на повышение привилегий при деструктивных действиях. Все вызовы инструментов регистрируются в Log Analytics. Безопасность контента как на входе, так и на выходе. Защита подсказок от взлома и косвенного внедрения подсказок из источников знаний. Время аналогии. Исследователь, аналитик, оператор, специалист по контролю качества. Каждый отвечает за свою часть работы. Оператор не утверждает свои собственные изменения. Аналитик не вмешивается в производственную среду. Специалист по контролю качества не пишет код, который он утверждает. Просто, скучно, безопасно. Почему Azure iPhone 3 плюс Semantic Kernel? Phone 3 предоставляет вам оркестрацию агентов, выбор моделей, привязку знаний, настройку инструментов, безопасность контента, трассировку, оценки и управления в одном месте. Семантик Kernel предоставляет вам планировщики, навыки, конвейеры, повторные попытки и отмену в коде. Вместе вы комбинируете модели для каждой роли, SLM для извлечения данных, класс GPT-4 для планирования, пакетную обработку для сводок. И ваши запросы становятся короткими, радиус поражения небольшим, а выходные – вашими. Теперь давайте создадим это, как Azure iPhone 3 обеспечивает многоагентные рабочие процессы. Здесь Azure iPhone 3 перестает быть просто красивым порталом и начинает работать как производственная площадка. Foundry предоставляет вам места для определения агентов, соединения моделей, добавления знаний, настройки действий и наблюдения за всем этим, не работая в шести разных средах и не имея желания. Это оркестровка без скотча. Начните с определения агентов. В Foundry каждый агент получает инструкции, четкое руководство пароли, а не манифест. Развертывание – это реальная модель, лежащая в его основе. Комбинируйте класс GPT-4 для планирования с SLM-класса FID для извлечения данных. Знания – поисковые индексы Azure AI, загруженные файлы или привязка к Bing, когда вам нужен веб-контекст. Действия – инструменты OpenAPI, логические приложения, функции, графы, сценарий автоматизации Azure или интерпретатор кода для быстрых вычислений и анализа. Да, подключенные агенты могут рассматривать другого агента как инструмент, если это позволяет поддерживать порядок в ролях. Это важно, потому что семантическое ядро подключается к той же вселенной. В коде вы создаете планировщики, определяете навыки и регистрируете инструменты в каталогах функций. Вы организуете цикл планировщика, оператора и рецензента, а Foundry управляет потоками, историей и механизмами безопасности. Вы делаете подсказки короткими и перекладываете основную работу на инструменты с помощью схем. Перевод – меньше галлюцинаций, меньше ошибок, больше выходных. Выбор модели имеет значение. Foundry абстрагирует вывод через конечную точку модели, поэтому вы можете менять модели, не переписывая все приложение. Два распространенных направления – бессерверные конечные точки для премиум-моделей и быстрая итерация. Вы платите за токен, масштабируетесь по требованию и не нянчитесь с графическими процессорами, как в 2018 году. Управляемые вычисления для конкретных открытых моделей, которые вы хотите закрепить в пределах вашего клиента. Вы платите за время работы и контролируете конфигурацию, но Microsoft занимается развертыванием. Смешиваете модели для разных ролей. Планировщик на GPT-4 или 4, один мини для логического вывода. Оператор на небольшой модели, отлично справляющийся с извлечением данных и формированием параметров. Создавайте длинные сводки партиями за ночь, чтобы к утру люди получали глянцевые отчеты. А если модель выходит из строя или вы хотите попробовать варианты DeepSick или Lama, API вывода Foundry позволит вам поддерживать стабильность кода во время экспериментов. Инструменты и действия – вот где оператор заслуживает свой значок. Здесь вы проявляете реальную власть, не передавая агенту ключи от своего королевства. Открытые API-инструменты для внутренних сервисов с помощью Swagger. Строго соблюдайте контракт. Если схема указывает, что устройство – это строка, то это должен быть идентификатор устройства. Приложение логики для потоков утверждения и человеческих ворот. Пусть рецензент направляет изменения утверждающему, а затем возобновляет выполнение при подтверждении. Функции Azure для связующего кода и корректных преобразований. Небольшой тестируемый API-версионированного графа для задач условного доступа к Inchun интро- и пользовательским устройствам. Предоставляйте области чтения агентам мониторинга, а области управления – только ремедиаторам. Автоматизация Azure для сценариев устройств и руководств. Относитесь к этому как к острым предметам в запертом ящике. Открыть его может только агент-исправитель. Как и в случае с установлением границ, поддерживайте порядок. Используйте поиск Azure AI с гибридным ранжированием и семантическим переранжированием. Разделяйте знания по предметной области. Политика Inchun должна быть отделена от стандартных операционных процедур при адаптации. Таким образом, вы не будете использовать все подряд. Оператор должен передавать фрагмент, а не всю энциклопедию. Размеры ваших фрагментов, хранение ссылок и проверка рецензентом соответствия требованиям перед попаданием в рабочую среду. Безопасность не является необязательной. Foundry включает в себя фильтры безопасности контента для ввода и вывода, защиту от взлома и косвенного внедрения, а также проверки защищенного материала. Запускайте проверку безопасности до и после моделирования, чтобы не платить за некорректные входные данные или катастрофы с запросами на слияние на выходе. Сочетайте это с управляемым удостоверением для каждого агента, проверкой на минимальные привилегии и управлением проектами для временного повышения привилегий для деструктивных инструментов. Каждый вызов инструмента отслеживается. Каждое подтверждение регистрируется. Если кто-то спросит, кто что запустил, вы не будете открывать Outlook. Аналитика журналов уже все знает. Наблюдаемость — это режим для взрослых. Включите трассировку, чтобы видеть историю запусков, какой агент вызывал какой инструмент с какими параметрами, с какой задержкой и что было возвращено. Подключите аналитику приложений для выявления закономерности производительности, журналы приложений для аудита и отправляйте результаты оценок в CI, чтобы выявлять отклонения в релевантности, обоснованности и беглости до того, как это заметит пользователь. Если обоснованность снижается, рецензент отмечает это. Планировщик сужает запрос на получение данных, и оператор пытается снова. Никакой паники со стороны человека не требуется. Примитивы развертывания поддерживают порядок. Используйте проекты Phone3 для квот на область действия команды и базовых параметров политик. Разместите Azure API Management перед вашей службой инструментов, чтобы вы могли версионировать, ограничивать скорость, внедрять автоматические выключатели и маршрутизировать между PTU и выводом с оплатой по мере использования. Частные конечные точки, где местонахождение данных или соответствие требованиям говорят о серьезности наших намерений. Регионы, которые соответствуют вашим пользователям, а не только вашим стремлениям. И да, семантическое ядро завершает картину. Вы описываете рабочий процесс в коде. Планировщик декомпозирует его. Оператор выбирает инструменты на основе каталогов функций и доступности. Рецензент обеспечивает проверки с помощью запросов на оценку и результатов проверки безопасности контента, а также предоставляет возможность повторных попыток с токенами отката и отмены, когда внешний API имитирует отключение для технического обслуживания. SK предоставляет вам мозг, выполнение, Phone3, операционную площадку. Объедините все это, и вы получите практичную схему. Определяйте агентов в Phone3 со строгими инструкциями и идентификаторами. Организуйте роли в SK, настраивайте систему с помощью тщательно отобранного поиска, связывайте действия с открытыми API, логическими приложениями, функциями, автоматизацией, обеспечивайте безопасность, да и после вывода, и наблюдайте за всем. Это скучно в лучшем смысле слова. Как ремни безопасности или отказ в предоставлении глобальных прав администратора стажеру с именем «Ключ по умолчанию». Демонстрационный сценарий 1. Очистка устройства. Призрачное устройство CSI Inchun. Знайте эти устройства, которые одновременно отображаются как управляемые, выведенные из эксплуатации и мертвые. Добро пожаловать в CSI Inchun. Наша задача – находить устаревшее, дублирующееся или незарегистрированное оборудование и безопасно устранять неполадки с одобрения, чтобы никто не отправлял гневные электронные письма в юридический отдел. Группа агентов, мониторинг, запросы, Microsoft Graph и аналитика логов, классификация состояния устройств, пометка аномалий. Специалист по устранению неполадок вызывает Inchun и автоматизацию Azure для карантина или вывода устройств из эксплуатации. Аудитор регистрирует все данные, уведомляет людей и составляет отчет о результатах проверки на соответствие требованиям. Процесс выглядит следующим образом. Монитор извлекает из записи устройств граф информацию о последнем подключении, состоянии соответствия, типе регистрации, основном пользователе и флагах вывода из эксплуатации. Он также получает сигналы аналитики логов, сигналы Defender, информацию о соответствии обновлений и события расширения управления Inchun. Он объединяет их в короткую структурированную запись для каждого устройства. Последнее посещение UTC – регистрация, соответствие, дубликаты, сигналы риска. Никаких отчетов, только поля. Теперь переход от интеллектуального управления к практическому. Монитор отправляет предлагаемую классификацию «Устаревшее», дубликат, отсутствие сигнала или штраф. Рецензент проверяет соответствие требованиям. Действительно ли эти поля получены из граф и ла? Служба безопасности контента запускает предварительную модель для блокировки внедрения подсказок из любого загруженного файла или веб-приложения. Если классификация проходит успешно, специалист по устранению неполадок подготавливает действия. Первый этап – мягкое исправление, пометка и карантин. Мы присваиваем кандидату категорию «Списанное устройство», удаляем динамические привязки групп, которые запускают распространение политик, и, при необходимости, перемещаем устройство в карантинную группу Азурет, которая блокирует доступ. Удалений пока нет. Утверждения поступают в логическое приложение. Рецензент включает в себя краткий план, идентификаторы устройств, причины, предлагаемые действия и откат. Утверждающие видят сводку в Teams со ссылками на запросы графов и KQL аналитики журналов. Утверждается токен датчика, средство исправления выполняет вывод устройства из эксплуатации, удаления при необходимости или очистку дубликатов, поддерживая устройство в актуальном состоянии и удаляя фантомные соединения. Управляемое удостоверение обеспечивает нашу безопасность. Монитор работает с разрешением чтения всех устройств. Средство исправления использует отдельное удостоверение с разрешением чтения всех устройств, запись всех устройств и именно теми разрешениями инчун, которые ему необходимы. Удаление осуществляется через PIM. Агент средства исправления не может повысить свои права. При запросе повышения прав логическое приложение требует участия человека и начинается отсчет времени для временного разрешения. Наблюдаемость — это более сложная часть. Каждый вызов инструмента отслеживается. Кто что вызвал, параметры, задержка, ответ. Аудитор записывает записи событий в журнал аналитики с идентификаторами корреляции, чтобы вы могли восстановить картину произошедшего без необходимости заниматься археологией слег. Мы также проводим этап оценки после внесения изменений — обоснованность, релевантность, связность. Если обоснованность снижается, рецензент блокирует дальнейшие деструктивные действия и возвращает план планировщику для уточнения поиска или сужения области действия. Модели намеренно смешиваются. Классификация использует небольшую модель для снижения затрат и задержки. Крайние случаи, например, когда Автопайлот переименовал одно из двух устройств, а Азур-Эд считает их близнецами, получают путь логического вывода с помощью GPT-4 Mini. Сводки обрабатываются пакетами. Никому не нужен шекспировский отчет в 14 часов. На прошлой неделе в тесте с одним агентом пытались исправить устаревшее устройство, выведя из эксплуатации все устройства в одной динамической группе. Рецензент в нашем многоагентном потоке отметил несоответствие в области действия, запросил подтверждение на уровне устройства и остановил процесс. Вот почему мы разделяем планирование, действие и проверку. В результате фантомные устройства перестают создавать проблемы с соблюдением нормативных требований. Вы сокращаете расход лицензий, исключаете ложные срабатывания и перестаете объяснять руководству, почему отказ от работы – это образ жизни. И да, журнал аудита читаем, чего нельзя сказать о половине ваших заявок на изменения. Второй сценарий демонстрации – адаптация без участия человека. Действительно, без участия человека. Никакого участия для пользователя, 500 касаний для инженеров до агентов. Цель – от события в отделе кадров до готового пользователя и устройства без лишних хлопот. Плавно, контролируемо и обратимо, даже если отдел кадров пишет фамилию тремя разными способами. Состав команды. Отдел приема очлеживает веб-перехватчик отдела кадров, нормализует данные и проверяет обязательные поля. Специалист по предоставлению доступа создает пользователя в интро, назначает группы и лицензии, регистрирует профили Автопайлот. Валидатор проверяет соответствие политики и состояние условного доступа, прежде чем мы передадим новый ноутбук. Консьерж отправляет приветственный пакет, ссылки на SharePoint и контрольный список на первый день. Время выполнения. Прием данных получает данные от отдела кадров. Имя, дата начала работы, должность, отдел, руководитель, регион. Небольшая модель извлекает и нормализует их. Она сопоставляет данные с каноническими полями и отлавливает некорректные данные, например, дату начала работы в 2099 году. Если обязательные поля отсутствуют, она отправляет в отдел кадров структурированные сообщения об ошибке через Logic Apps без произвольных формулировок. Провиженер вызывает граф с управляемым идентификатором, ограниченным правами пользователя. Он создает пользователя интро, устанавливает место использования и применяет базовую группу. Затем он формирует назначение лицензии на основе роли и региона. Здесь важна логика, нужна ли этому человеку безопасность E5 или премиум-версия для бизнеса. Мы кодируем политику в данных и позволяем модели выбирать из разрешенных пакетов. Ни одна модель не может создавать лицензии, это строгое меню. Далее следует автопилот. Провиженер либо регистрирует уже имеющийся у нас хэш-оборудование, либо подготавливает профиль, точно в срок, привязанный к группе пользователя. Он помечает группы устройств для базовых политик, после чего активируется валидатор. Система запрашивает у граф и дефендер сигналы соответствия, проверяет, не нарушит ли условный доступ первый вход в систему, и убеждается, что будут применяться правильные политики конфигурации устройства. Если условный доступ заблокирует нового сотрудника в первый день работы, валидатор открывает запрос на утверждение с ограниченным по времени исключением и обоснованием. Консердж обрабатывает ручные операции. Он отправляет менеджеру сообщение в Teams с UPN нового сотрудника, статусом назначения устройства и ссылкой на стартовый комплект SharePoint. Он отправляет новому сотруднику электронное письмо с инструкциями по первому рабочему дню, руководством по настройке многофакторной аутентификации информации о том, где найти ИТ-портал. Он не вставляет ваши внутренние диапазоны IP-адресов в электронное письмо. Контент в софете проверяет выходные данные на предмет утечки информации и тональности. Управление осуществляется по той же принципу «пристегните ремни». Управляемое удостоверение провяженера имеет право на лицензирование, но не может удалять. Интейк не может предоставлять доступ, он только проверяет. PM блокирует любые действия высокого риска, такие как добавление пользователей в конфиденциальную группу. Все действия отслеживаются в App Insights и Log Analytics. Если отдел кадров отправляет исправленные данные, планировщик пересчитывает дельту, а оператор обновляет только то, что изменилось. Отсутствие колебаний членства в группах. Наблюдаемость позволяет отслеживать этапы. Прием данных от отдела кадров, создание входящих запросов, назначение лицензий, профиль автопилота, отправка уведомления о результатах проверки соответствия. Вы получаете метрики SLA и автоматические повторные попытки при временных ошибках графа с задержкой. Если система отдела кадров дает сбой, поток не завершается. Он приостанавливается, регистрирует и возобновляется после исправления. Оценки запускаются в CI на синтетических данных для адаптации новых сотрудников, чтобы выявить регрессии в релевантности и обоснованности до того, как пострадает реальный сотрудник. Сочетание моделей поддерживает баланс. SLM для извлечения и нормализации данных. Обоснование только при принятии решения о выборе политики. Сводки и приветственные письма обрабатываются пакетами, когда это возможно. Цель – низкая задержка при предоставлении доступа с понятностью, сравнимой с человеческим уровнем в журнале Аудита. Краткая история. При адаптации с помощью одного агента пытались добавить пользователя ко всем сотрудникам и подрядчикам, потому что в названии было указано «подрядчики». Многоагентная система обнаружила правила взаимной исключительности в валидаторе, запросила решение человека и предотвратила немедленный пожар в системе условного доступа. В результате пользователь полностью обходится без вмешательства. Один поток, четыре агента, чистые подтверждения и документальное подтверждение, которое вы можете показать своему директору по информационной безопасности, не молясь богам демонстрации. И да, когда отдел кадров неизбежно меняет дату начала работы, система пересчитывает данные, не расходуя бюджет на лицензии. Третий сценарий демонстрации – автоматическое усиление безопасности. Пожалуйста, оставьте битлокер включенным. Отклонение в настройках безопасности подобно сорнякам. Вы выдергиваете три, вырастает пять, и один из них из вредности отключает битлокер. Наша цель – непрерывно обнаруживать отклонения в конфигурации и безопасно устранять их с помощью механизмов, которые уважает юрист. Cast Drift Detector запрашивает граф и Defender. Secure Score получает данные о соответствии инчун и базовые показатели конфигурации устройств и строит дельту отклонения. Fixer отправляет изменения политики инчун, настройки битлокер и кольца обновлений Windows. Запускает сценарии устройств через Azure Automation, когда политика не справляется с задачей. Рецензент обеспечивает соблюдение ограничений, определяет объем изменений, проводит проверки на соответствие требованиям и получает одобрение от людей для рискованных шагов. Missenger напоминал людям в Teams или по электронной почте о кратких планах и подтверждениях. Flow Drift Detector работает по расписанию и по запросу. Он получает информацию о соответствии устройств требованием, статусе битлокер, статусе TPM, версии ОС, кольца обновлений и назначений политик через граф. Он сравнивает каждое устройство с эталонным профилем в виде структурированных данных, а не документа с настройками. Он помечает обнаруженные проблемы, отсутствие битлокер, слабый метод шифрования, непримененная политика, отключение безопасной загрузки, выход кольца обновлений за пределы допустимого диапазона. Запускается планировщик, предлагающий минимальный план для каждой группы устройств. Для битлокера используется политика инчун битлокер, если устройство поддерживает эту функцию. Если политика уже назначена, но ее статус неактивен, предлагается сценарий автоматизации для повторного запуска защитников и депонирования ключа в Azure Red. Для обнаружения отклонений обновлений предлагается переместить устройство в поэтапное кольцо обновлений, а не надеяться на немедленное обновление. В случае проблем с условным доступом предложите временное исключение с необходимым обоснованием. Рецензент оценивает обоснованность. Действительно ли Drift Detector ссылается на поля из Graph и Defender? Он проверяет область действия, идентификаторы устройств, идентификаторы политик, тип изменения. Если что-то похоже на все устройства, это блокируется с предубеждением. Безопасность контента обеспечивается на входе и выходе, чтобы предотвратить внедрение каких-либо внешних знаний или скопированных логов. Действия с высоким риском, такие как удаление конфликтующей локальной политики, блокируются менеджером проекта. Идентификатор исправителя не может повышаться самостоятельно. Утверждение осуществляется в логическом приложении с аккуратной карточкой. Что не так? Что изменится? Шаги отката и ссылки. Утверждение и выполнение исправления. Обновления политик инчун являются мощными элементами и целевыми. Исправление BitLocker использует сценарий выполнения с явными параметрами и проверкой целостности. TPM присутствует. ОС поддерживает путь депонирования XTS-AS-256. Проверено. Если какая-либо предварительная проверка не удается, она завершается с понятным для человека сообщением об ошибке беспобочных эффектов. Миссингер замыкает цикл. Устройство исправлено. В Teams отправляется дайджест с подсчетами, ссылками на трассировки и App Insights и CSV-файлом для тех, кто по-прежнему любит Excel больше, чем свою семью. Если устройство отказывается соответствовать требованиям, рецензент открывает поток обработки исключений с таймером и планирует повторные попытки. Наблюдаемость. Каждый вызов инструмента отслеживается и коррелируется по потоку. Мы блокируем изменения до и после, чтобы аудитор мог видеть несоответствующие и соответствующие требованиям данные, не застревая в KQL. Мы также запускаем агент оценки на сводках после изменений, чтобы проверить обоснованность и ясность. Если обоснованность снижается или частота сбоев резко возрастает, планировщик сужает область поиска, уменьшает размер пакета или приостанавливает деструктивные действия. Модель сочетает SLM для извлечения и классификации. Модель рассуждений для синтеза плана только при необходимости. Пакетная обработка ночного отчета. Никаких сонетов об И. В результате BitLocker действительно работает. Кольца обновлений меньше смещаются. Исключения документируются, ограничены по времени и доступны для проверки. И никто не чинит устройство, переустанавливая операционную систему на финансовых ноутбуках во время закрытия квартала. Архитектурный анализ. PhoneDri. Семантическое ядро. Инструменты. Идентификация. Давайте разберемся, как это работает, не нарушая вашу квоту. Представьте четыре уровня, которые обеспечивают здравый смысл. PhoneDri. Семантическое ядро. Инструменты. Идентификация. PhoneDri. Это базовая система. Вы определяете агентов со строгими инструкциями. Выбираете развертывание для каждой роли. Прикрепляете знания через поиск Azure AI и регистрируете действия. Инструменты. Аупинапи. Логические приложения. Функции. Графы. Автоматизация Azure. Интерпретатор кода. Здесь же находятся угрозы. История выполнения. Трассировка. Оценки и проверка безопасности. Защитные подсказки по безопасности контента и проверке защищенных материалов запускаются и после моделей. Поэтому некорректные входные данные не требуют токенов, а некорректные выходные данные выполнения заданий. Семантическое ядро. Это дирижер. В коде вы подключаете цикл проверки оператора-планировщика. Вы регистрируете каталоги функций для инструментов, отключаете повторную попытку и добавляете токены-отмены. Вы делаете подсказки короткими, переносите сложность в схемы и позволяете семантическому ядру решать, какой инструмент вызвать, исходя из доступности и политики. Если граф выходит из строя по таймауту, семантическое ядро обрабатывает это задержкой. Если уровень обоснованности снижается, он возвращается к планировщику для уточнения. Инструменты — это руки. Строго соблюдайте контракты с открытым API. Разместите управление API на переднем плане для ограничения версий и защиты от сбоев. Приложения логики обрабатывают утверждения и длительные процессы. Функции обеспечивают связь и преобразование. Автоматизация Azure выполняет скрипты с ограничениями и проверками после выполнения. Граф — ваш источник достоверной информации для инчун, интро, соответствие требованиям и оценке безопасности. Поиск Azure AI предоставляет тщательно отобранные знания по каждой области. Никакого супа знаний. Идентификация — это ремень безопасности. Каждый агент имеет свою собственную управляемую идентификацию. Агенты мониторинга получают области чтения. Агенты исправления получают области записи, но никогда не административные. Управление проектами блокирует любые деструктивные действия. Повышение прав требует участия человека и истекает. Частные конечные точки, где важны границы данных. Базовые политики в проектах Foundry обеспечивают соблюдение разрешенных моделей регионов и квот. App Insights и Log Analytics собирают трассировки, метрики и аудиты, чтобы вы могли ответить, кто что сделал, без необходимости поиска информации вслед. Модели подключаются через конечную точку вывода Foundry. Используйте бессерверные вычисления для обоснования приоритетов. Управляйте вычислительными ресурсами для закрепленных открытых моделей. Меняйте модели без переписывания кода, но при этом оценивайте релевантность, обоснованность и совместимость в CI перед продвижением. Регионы соответствуют вашим пользователям, зоны данных — вашим регулирующим органам. В совокупности это скучная, но надежная машина. Агенты, определенные в Foundry, управляемые SK, работающие на основе инструментов, защищенные идентификацией, измеряемые наблюдаемостью и охраняемой безопасностью. Скучная побеждает. Скучная масштабируется. Скучная позволяет вам спать. Лучшие практики внедряются без сожалений. Понятно. Накопите мудрость во времени, чтобы не тратить воскресенье на исправление субботнего. Дайте каждому агенту одну задачу. Планировщик планирует, оператор управляет, рецензент проверяет. Если агент начинает писать трогательный роман, отрежьте его подсказку и передайте текст инструменту. Держите инструкции короткими, ограниченными по объему и скучными. У вас будет меньше неожиданностей. Предпочитайте вызовы инструментов длинным текстом. Размещайте контракты в открытом аппе, схемы на входе и ограничения на выходе. Если инструмент ожидает устройства, отправьте его, а не, например, это устройство в финансовом отделе. Модели креативны, инструменты нет. В этом суть. Применяйте принцип минимальных привилегий, как будто от этого зависит ваша работа, потому что так оно и есть. Разделяйте учетные записи. Только чтение для монитора, только запись для корректировщика, и ни одна учетная запись не может удалять без менеджера проекта. Повышение прав временное, обоснованное и регистрируется. Если кто-то просит постоянного глобального администратора, дайте ему антистрессовый мячик и документ с политикой. Начните с малого, два агента, исполнитель и проверяющий. Добавьте планировщика, когда цикл стабилизируется. Затем, если вам нужно расширить команду, не начинайте с цифровой скром команды из 12 человек. Именно так вы воссоздаете свою организационную структуру в IML и плачете. Смешивайте модели для снижения затрат. SLM для извлечения данных. Класс GPT-4 только для рассуждений там, где это важно. Создавайте пакетные сводки за ночь. Вы не платите за форматирование строковых данных. Оставьте ресурсуемкую модель для принятия решений, а не для повествования. Добавляйте память в последнюю очередь. Используйте внешнее состояние для поиска и или небольшое хранилище состояний, прежде чем начинать забивать контекстные окна, как ручную кладь. Метаденные потоков должны быть минимальными. Если они не нужны для следующего шага, их не нужно добавлять. Регистрируйте все. Включите трассировку. Идентификаторы потоков, параметры инструментов, результаты задержки. Отправляйте результаты оценок в CI, чтобы вы могли обнаружить снижение релевантности и обоснованности до того, как это произойдет в производственной среде. Оповещайте о снижении обоснованности, а не о сбоях в Твитто. Защитные механизмы важнее скорости, одобрение для деструктивных инструментов. Режим пробного запуска без побочных эффектов. Поэтапное развертывание по группам устройств или регионам. Если ваш план развертывания предполагает одновременную реализацию, надеюсь, ваше резюме обновлено. Создавайте условия для сбоев. Повторяйте попытки с задержкой. Откажитесь от ограничения скорости графа. Автоматические выключатели в управлении API. И демпатентные сценарии выполнения. Если шаг можно безопасно повторить, вы будете спать спокойнее. Наконец, документируйте свои политики в виде данных. Правила взаимной исключительности. Пакеты лицензий. Базовые показатели устройств. Представьте их в структурированном виде. Модели могут выбирать. Они не должны изобретать. Вот как сохранить полезность агентов и ограничить радиус поражения. Запомните хотя бы одно, отдельные агенты помогают, но команды агентов, спланированные, управляемые инструментами и заданными правами доступа, незаметно преобразуют вашу среду, пока вы притворяетесь спящим. Если это вас зацепило, подпишитесь и посмотрите продолжение, где я поделюсь репозиторием семантического ядра и шаблоном бицепса, чтобы вы могли беззастенчиво их воровать. Хотите эпизод про агентов оценки, которые выполняют свои обещания? Он уже в очереди, на следующей неделе.