Знаєте, чат-боти розмовляють, агенти діють, а мультиагентні системи дійсно виконують роботу. Якщо ви благали бота виправити Intune, а він відповів віршем, це для вас. Отже, формат «Дивіться, як на Netflix». Ви дивитесь, ви їсті снеки. Я беру на себе небезпечні сервісні принципи, щоб ніхто не знищив продакшній. Ми створюємо міні-систему з мультиагентами, що самовідновлюється за допомогою Azure AI Foundry та Semantic Kernel. Реальні точки дотику. Intune, Entra, Graph, Azure Automation, Log Analytics. Один агент проти мультиагентної системи – 12 хвилин проти трьох. І єдина втрата – це кредит моєї підписки. По-перше, чому один агент гальмує, а команди літають? Чому одного агента недостатньо? Одиночні агенти – це як швейцарський, ніж із заправки. Технічно інструменти є, а на практиці він гнеться на першому ж гвинті. Ви втискаєте план, міркування, виконання, узгодження та звіти в один промп, і тепер він голодує за контекстом, повільний і дивно впевнений у помилкових речах.

Більшість людей думають, більша модель, більший мозок, і бум, проблему вирішено. Але справжня помилка – це плутанина з ролями. Один агент намагається спланувати зміни, викликати граф, написати скрипт виправлення, запитати схвалення, перевірити результат і задокументувати це. Це ніби доручити техпідтримці, комітету з питань змін та розбору інцидентів одному втомленому стажеру. Ось що відбувається насправді. Одиночний агент намагається втримати забагато станів. Ваш промп перетворюється на цілу повість. Контекстне вікно заповнюється логами, політиками та половиною словника MDM, тому він або обрізає важливі частини, або галюцинує відсутні деталі. Затримки зростають, токи не спалюються, а повторні спроби відчуваються як «день бабака» з рахунком до оплати. Час мультиагентів – ролі, межі, паралелізм. Планувальник фокусується на намірах та обмеженнях. Оператор фокусується на інструментах та виконанні.

Рецензент фокусується на запобіжниках, узгодженнях і перевірці, чи спираємося ми на факти. Кожен агент має чіткий, короткий набір інструкцій та мінімально необхідну пам'ять. Вони передають повідомлення, результати роботи інструментів або стислі підсумки, а не весь інтернет. Чому це важливо для бізнесу? Вам потрібні наскрізні робочі процеси з участю людини, діями з обмеженим доступом, повторними спробами та аудиторськими слідами. Це не однопотоковий чат. Це командна гра. Модель «Планувальник-виконавець-рецензент» зменшує ризики та переробки, бо кожен крок має другу пару очей автоматизованих, які не зависають на 11-й хвилині короткої наради в Teams. Виграш у вартості та затримках також є. Використовуйте малімовні моделі для вилучення та класифікації даних. Використовуйте преміальні моделі міркування лише там, де планування справді допомагає. Запускайте пакетні завдання для звітів, поки користувачі сплять.

Ви отримаєте менше галюцинацій, швидші результати та менші рахунки. Коротка історія. Планувальник розуміє мету, обмеження та середовище. Створює план із викликами інструментів, які може виконати оператор. Оператор викликає інструменти Graph, Logic Apps, функції Azure Automation Runbooks та повертає структуровані результати. Рецензент перевіряє обґрунтованість, відповідність вимогам, погодження та безпеку результатів перед будь-якими ризикованими діями. Консьєрж повідомлень обробляє сповіщення для людей, погодження та підсумки для аудиту. Вони спілкуються через повідомлення та спільний контекст, як дорослі, коротко, чітко та тільки те, що потрібно. Послідовно, коли дії залежать від попередніх результатів, паралельно, коли підзавдання можна безпечно розподілити. Ви не надсилаєте 50-сторінкову політику, ви надсилаєте відповідний фрагмент, ID пристроїв і заплановану зміну. Інструменти – це руки.

REST-ARI для Microsoft Graph, RIG через Azure AI Search для перевірених знань, інтерпретатор коду для фрагментів, Logic Apps для оркестрації, функції для зв'язку, Azure Automation для повторюваних завдань. Тримайте вхідні дані інструментів структурованими за допомогою схем, щоб оператор не зміг креативно видалити ваш тенант. Пам'ять – це не магія, це бюджет. Мінімізуйте пам'ять для кожного агента. Використовуйте зовнішній стан, індекси пошуку, векторні сховища або невелике сховище мета даних потоку. Тримайте вікна контекстолаконічними. Якщо це не потрібно для наступного рішення, воно не передається далі. Планування проти виконання – це те, де саментик Кернел проявляє себе найкраще. Планувальник делегує, оператор обирає правильний інструмент із каталогів функцій. Рецензент критикує результати за допомогою оціночних промптів та перевірки безпеки контенту. Якщо рецензент вказує на ризик виходу за межі повноважень, планувальник вносить зміни.

Коли ви зрозумієте цей цикл, ви перестанете писати 800-слівні промпти і почнете визначати чіткі ролі. Межі безпеки не підлягають обговоренню. Виклики інструментів із розмежуванням доступу через керовані ідентичності. Права доступу агентів розділені між читанням і керуванням. PIM для підвищення прав при деструктивних діях. Усі виклики інструментів записуються в Log Analytics. Перевірка безпеки контенту як на вході, так і на вигоді. Захист промптів від джейлбрейків та непрямих ін'єкцій із джерел знань. Час для аналогій. Дослідник, аналітик, оператор, QA. Кожен несе відповідальність за свою частину роботи. Оператор не схвалює власні зміни. Аналітик не втручається в роботу продакшні середовища. QA не пише код, який він тестує. Просто, буденно, безпечно. Чому Azure AI Foundry разом із Symantec Kernel? Foundry надає оркестрацію агентів, вибір моделей обґрунтування знань, підключення інструментів, безпеку контенту, відстеження, оцінювання та управління в одному місці.

Symantec Kernel надає вам планувальники, навички, конвейери, повторні спроби та скасування в коді. Разом ви комбінуєте моделі за ролями SLM для вилучення, GPT-4 класу для планування, пакетну обробку для резюме, при цьому зберігаючи промпти короткими, ризики мінімальними, а вихідні – вільними. Тепер давайте це створимо, як Azure AI Foundry забезпечує роботу агентних робочих процесів. Ось де Azure AI Foundry перестає бути просто глянцевим порталом і починає діяти як виробничий майданчик. Foundry дає вам простір для визначення агентів, підключення моделей, додавання знань, налаштування дій і спостереження за всім цим без блукання між шістьма різними вкладками навмання. Це оркестрація без синьої ізоляційної стрічки. Почніть із визначення агентів. У Foundry кожен агент отримує інструкції та чіткі вказівки щодо ролі, а не маніфест. Розгортання – фактична модель, що стоїть за цим. Поєднуйте моделі класу GPT-4 для планування з SLM класу FI для вилучення даних.

Знання, індекси Azure AI Search, завантажені файли або BIN для контексту з інтернету. Дії, інструменти OpenARIE, Logic Apps, функції, граф, Azure Automation або інтерпретатор коду для швидких обчислень і парсингу. Підключені агенти. Так, агент може сприймати іншого агента як інструмент, якщо це дозволяє чітко розмежувати ролі. Це важливо, оскільки Semantic Kernel підключається до того самого Всесвіту. У коді ви будуєте планувальники, визначаєте навички та реєструєте інструменти в каталогах функцій. Ви координуєте цикл, планувальник, оператор, рецензент, а Foundry бере на себе потоки, історію та обмеження безпеки. Ви тримаєте промпти короткими, а основну роботу перекладаєте на інструменти зі схемами. Переклад – менше галюцинацій, менше помилок, більше вільного часу. Вибір моделей має значення. Foundry абстрагує висновок через модельну кінцеву точку, тому ви можете змінювати моделі без переписування всього застосунку.

Два основні шляхи – безсерверні кінцеві точки для преміум-моделей і швидкої ітерації. Ви платите за токен, масштабуєтеся за запитом і не доглядаєте за GPU, як у 2018 році. Керовані обчислення для конкретних відкритих моделей, які ви хочете закріпити у межах свого тенента. Ви платите за час роботи та контролюєте конфігурацію, але Microsoft бере на себе клопоти з розгортання. Комбінуйте моделі за ролями. Планувальник на базі GPT-4 або 4, один міні для логічних міркувань. Оператор на невеликій моделі, що ефективна у вилученні та структурованні параметрів. Пакетна обробка довгих звітів вночі, щоб люди отримували готові результати вранці. І якщо модель застаріє або ви захочете спробувати варіанти DeepSeek, чи лама АРІ висновку Foundry дозволить зберегти стабільність коду під час експериментів. Інструменти та дії – це те, де оператор здобуває свій авторитет. Саме тут ви надаєте реальну силу, не віддаючи агенту ключі від вашого королівства.

Відкривайте АРІ інструментів для внутрішніх сервісів через Svega. Дотримуйтесь суворих контрактів. Якщо в схемі для пристрою вказано рядок, це має бути ідентифікатор пристрою. Logic Apps для потоків затвердження та контролю з боку людини. Нехай перевіряльник спрямовує зміни до особи, що їх погоджує, а потім відновлює виконання після схвалення. Azure Functions для сполучного коду та коректних перетворень. Невеликий версійний граф АРІ, що легко тестується для завдань Intune, Entra та умовного доступу користувачів до пристрою. Надавайте права на читання агентам моніторингу, а права на керування – лише агентам виправлення. Azure Automation для скриптів пристроїв та посібників з експлуатації. Поведьтеся з цим, як і з гострими предметами, в замкненій шухляді. Лише агент виправлення може її відкрити. Як і з граундингом, підтримуйте вміст у впорядкованому стані. Використовуйте Azure AI Search із гібридним ранжуванням та семантичним переранжуванням.

Розподіляйте знання за доменами. Політики Intune окремо від інструкцій з онбордингу. Щоб не завантажувати зайвого. Оператор має передавати фрагмент, а не всю енциклопедію. Визначайте розміри блоків, зберігайте посилання та доручіть перевіряльнику оцінити обґрунтованість перед виходом у продуктивне середовище. Безпека – це не опція. Foundry містить вбудовані фільтри безпеки в місту для вводу та виводу, захист від зламу та непрямих ін'єкцій, а також перевірку захищених матеріалів. Виконуйте перевірку безпеки до та після моделі, щоб не платити за погані дані або піар-катастрофи на вигоді. Поєднуйте це з керованою ідентичністю для кожного агента, принципом найменших привілеїв та тимчасовим підвищенням прав для деструктивних інструментів. Кожен виклик інструменту відстежується. Кожне затвердження реєструється. Якщо хтось запитає, хто що запустив, ви не відкриваєте Outlook. Log Analytics уже все знає.

Спостережуваність – це ознака дорослого підходу. Увімкніть трасування, щоб бачити історію запусків, який агент, який інструмент, з якими параметрами, з якою затримкою викликав і що отримав у відповідь. Налаштуйте Application Insights для аналізу продуктивності, логи додатків для аудиту та впроваджуйте оцінки в CI, щоб виявляти відхилення в релевантності, обґрунтованості та зв'язності до того, як це зробить користувач. Якщо обґрунтованість падає, перевіряльник позначає це, планувальник звужує запит на отримання даних, і оператор робить ще одну спробу. Жодної паніки з боку людини не потрібно. Примітиве розгортання допомагають підтримувати порядок. Використовуйте проєкти Foundry для квот, команд та базових політик. Розмістіть Azure Arie Management перед сервісом інструментів для керування версіями, обмеження швидкості, впровадження запобіжників та маршрутизації між пітію та моделью оплати за фактом використання.

Приватні кінцеві точки там, де вимагається відповідність вимогам або резиденція даних. Регіони, що відповідають вашим користувачам, а не лише вашим амбіціям. І так, Сементик Кернел завершує цю картину. Ви описуєте робочий процес у коді. Планувальник декомпозує завдання. Оператор обирає інструменти на основі каталогів функцій та їх доступності. Рецензент виконує перевірки за допомогою оцінювальних підказок і результатів перевірки безпеки в місту, а ви отримуєте повторні спроби з очікуванням та маркерами скасування, Це нудно в найкращому розумінні цього слова. Як паски безпеки або відмова від надання прав глобального адміністратора-стажеру на ім'я Default Key. Демо сценарій 1 – очищення пристроїв, підрозділ привидів CSI Intune. Знаєте ці пристрої, які відображаються як керовані, списані та живі мерці одночасно? Ласкаво просимо до CSI Intune. Наша робота – знайти застаріле, дублюване або незареєстроване обладнання та безпечно виправити ситуацію після схвалення, щоб ніхто не нацилав гнівні листи юристам.

Команда агентів – монітор, запити, Microsoft Graph та Log Analytics, класифікація станів пристроїв, позначення аномалій. Засіб виправлення викликає Intune та Azure Automation для карантину або списання пристроїв. Аудитор записує все, сповіщає людей і пише звіт про виконані дії для відповідності вимогам. Процес виглядає так. Монітор отримує з графа записи про пристрої останню реєстрацію, стан відповідності, тип реєстрації, основного користувача та пропорції списання. Він також збирає сигнали Log Analytics, серцебиття Defenda, відповідність оновлень та події розширення керування Intune. Він об'єднує їх у короткий структурований запис для кожного пристрою. Останній сеанс UTC зареєстрований, сумісний, кандидати на дублювання, сигнали ризику. Жодних романів, лише поля. Тепер передача від мозку до м'язів. Монітор надсилає запропоновану класифікацію за старілий, дублікат, немає серцебиття або в нормі.

Рецензент перевіряє обґрунтованість. Чи справді ці дані надійшли з графа та Log Analytics? Перевірка безпеки в місту працює перед моделью, щоб заблокувати ін'єкції підказок із будь-яких завантажених файлів або веб-джерел.

Ди дата на списання, видаляємо прив'язки до динамічних груп, що спричиняють розростання політик і, за потреби, переміщуємо пристрій у групу карантину Azure ID, яка блокує доступ. Поки що ніякого видалення. Запити на схвалення потрапляють у Logic App. Рецензент додає компактний план, ID пристроїв, причини, запропоновані дії та відкат. Особа, що схвалює, бачить зведення в Teams із посиланнями на запити графа та KQL з Log Analytics. Схвалення повертає маркер, засіб виправлення виконує списання, очищення, якщо обґрунтовано, або видаляє дублікати, залишаючи пристрій із найсвіжішим серцебиттям і розриваючи зв'язки з привидами. Керована ідентичність тримає наші руки чистими. Монітор працює з правами на читання всіх пристроїв. Ремедіатор використовує окрему ідентичність із правами читання та запису пристроїв та рівно тими дозволами Intune, які йому потрібні. Видалення захищене через PIM. Агент-ремедіатор не може підвищувати власні права.

Коли запитується підвищення прав, логічний додаток потребує участі людини і запускається таймер тимчасового доступу. Спостережуваність – це доросла частина системи. Кожен виклик інструменту відстежується. Хто викликав – параметри, затримка, відповідь. Аудитор записує події в Log Analytics з ідентифікаторами кореляції, щоб ви могли відтворити послідовність дій без археології в слег. Ми також проводимо етап оцінки після внесення змін – обґрунтованість, релевантність, плинність.

Уточнення пошуку або звуження обсягу. Моделі змішуються цілеспрямовано. Класифікація використовує невелику модель для зниження вартості та затримки. Виняткові випадки, як-от два пристрої, де OtoPilot перейменував один, а Azure ID вважає їх ідентичними, отримують шлях міркування з GPT-4 Mini. Підсумки пакетуються. Нікому не потрібен шекспірівський звіт о 14.00, лише стисла історія. Минулого тижня тест з одним агентом спробував виправити застарілий пристрій, видаливши все у тій же динамічній групі. Рецензент у нашому мультиагентному потоці виявив невідповідність обсягу, запитав підтвердження на рівні пристрою та зупинив це. Ось чому ми розділяємо планування, дію та перевірку. Кінцевий результат – пристрої привиди перестають заважати комплеєнсу. Ви зменшуєте марну витрату ліцензій, кількість хибних спрацювань і припиняєте пояснювати керівництво, чому помилки видалення стали нормою життя. І так, журнал аудиту читабельний, що більше, ніж я можу сказати про половину ваших тікетів на зміни.

Демо сценарій 2. Адаптація без дотиків. Zero-touch onboarding. Насправді без жодного дотику. 0 дотиків для користувача, 500 дотиків для інженерії до появи агентів. Ціль – відкадрової події до готового користувача та пристрою без зайвих рухів. Плавно, керовано та оборотно, коли HR пише прізвище трьома різними способами. Склад команди. Інтейк слухає HR-вебхук, нормалізує корисні дані та перевіряє обов'язкові поля. Провіженер створює користувача Ventra, призначає групи та ліцензії, реєструє профілі AutoPilot. Веледий та перевіряє відповідність політикам та стан умовного доступу, перш ніж ми віддамо новий ноутбук. Консьєрж надсилає вітальний пакет, посилання на SharePoint та чек-лист для першого дня. Час потоку. Інтейк отримує кадрові дані, ім'я, дату виходу, роль, відділ, керівника, регіон. Невелика модель вилучає та нормалізує їх. Вона зіставляє дані з канонічними полями та виловлює дурниці, як от дата початку у 2099 році.

Якщо обов'язкові поля відсутні, система надсилає HR-структуровану помилку через Logic Apps без вільної поезії. Провіженер викликає граф із керованою ідентичністю, обмеженою правами користувача. Вона створює користувача Ventra, встановлює місцеве користання та застосовує базову групу. Далі він формує призначення ліцензій на основі ролі та регіону. Тут допомагає логічне мислення. Чи потрібна цій особі і 5 Security або Business Premium? Ми кодуємо політику в даних і дозволяємо моделі обирати з дозволених пакетів. Жодна модель не може вигадувати ліцензії, є лише суворе меню. Далі йде AutoPilot. Засіб надання доступу або реєструє апаратний хеш, який ми вже маємо, або готує профіль, точно в строк, прив'язаний до групи користувача. Він позначає групи пристроїв для базових політик, після чого вмикається валідатор. Він запитує граф і дафенда щодо сигналів відповідності, перевіряє, чи не завадить умовний доступ першому входу і перевіряє застосування правильних політик конфігурації.

Якщо умовний доступ блокує новачка в перший день, валідатор створює запит на схвалення з часовим виключенням та обґрунтуванням. Консьєрж займається людськими справами. Він надсилає повідомлення в тім з менеджеру з UPN новачка статусом призначення пристрою та посиланням на стартовий набір SharePoint. Він надсилає електронний лист новачку з інструкціями на перший день, налаштуванням МФА та інформацією про ІТ-портал. Він не вставляє ваші внутрішні IP-діапазони в електронний лист. Безпека контенту перевіряє результати на предмет витоку даних і тону. Управління дотримується тієї ж концепції ременів безпеки. Керована ідентичність провіженер має права на ліцензії, але не на видалення. Модуль прийому даних не надає доступ, він лише перевіряє. PM контролює будь-які ризиковані дії, наприклад, додавання користувачів до чутливих груп. Усі дії відстежуються WebInsights та Log Analytics. Якщо HR надсилає виправлені дані, планувальник перераховує різницю, а оператор оновлює лише те, що змінилося.

Жодних безглуздих змін у членстві груп. Можливість спостереження забезпечує контрольні точки. HR-інтеграція, створення Entra, призначення ліцензії, профіль AutoPilot, відправка результатів перевірки відповідності. Ви отримуєте показники SLA та автоматичні повторні спроби при тимчасових помилках граф із затримкою. Якщо в системі HR стається збій, потік не зупиняється. Він призупиняється, записується в журнал і відновлюється після усунення проблеми. Оцінки виконуються в CI на синтетичних даних, щоб виявити регресії в релевантності до того, як постраждає реальний працівник. Комбінація моделей дозволяє оптимізувати витрати. SLM для вилучення та нормалізації даних. Логічний прохід лише для рішень щодо вибору політики. Підсумки та привітальні листи групуються, коли це можливо. Мета – надання доступу з низькою затримкою та чіткістю аудиторського сліду на людському рівні. Коротка історія. Онбординг через одного агента намагався додати користувача до всіх співробітників і підрядників, бо в посади було вказано «підрядний персонал».

Мультиагентний підхід виявив правило взаємного виключення у валідаторі, запитав рішення людини й уникнув миттєвої проблеми з доступом. Результат – справжнє нульове втручання для користувача. Один потік, чотири агенти, чисті схвалення та звіт, який можна показати CISO без благань до «Богів демо-версій». І так, коли відділ кадрів неминуче змінює дату початку, система перераховує в себе шкоди для бюджету ліцензій. Демонстраційний сценарій 3 – автоматизоване зміцнення безпеки. Будь ласка, нехай бітлока буде увімкнено. Дрейв безпеки, як бур'яни. Висмикнеш три – з'являться п'ять, і один із них назло вимкне бітлока. Наша мета – постійно виявляти дрейв конфігурації та безпечно його усувати за допомогою засобів контролю, які схвалив би навіть юрист. Детектор дрейву каст запитує граф та дафенда. Сак'юрсько отримує дані про відповідність Інтюн та базові конфігурації пристроїв, формуючи дельту дрейву.

Фікса впроваджує зміни політик Інтюн, налаштування бітлока та кільця оновлення Віндовс. Запускає сценарії для пристроїв через Azure Automation, коли політик недостатньо. Рав'юа забезпечує дотримання правил, обмежує зміни, перевіряє обґрунтованість і вимагає схвалення людиною для ризикованих кроків. Месенджа сповіщає людей у Teams або електронною поштою з короткими планами та звітами. Процес «Детектор дрейфу» запускається за розкладом і на вимогу. Він отримує дані про відповідність пристроїв, статус бітлока, стан TPM, версію ОС, кільце оновлень та призначення політик через граф. Він порівнює кожен пристрій із золотим профілем як структуровані дані, а не як абстрактний документ. Він позначає виявлені проблеми, відсутність бітлока, слабкий метод шифрування, незастосована політика, вимкнений безпечний завантажувач, кільце оновлень поза межами. Вступає в дію плена, пропонуючи мінімальний план для кожної групи пристроїв.

Для бітлока використовується політика Intune, якщо пристрій підтримує її. Якщо політика призначена, але статус вимкнено, пропонується сценарій автоматизації для повторного запуску захисту та депонування ключа вежу RayD. Для дрейфу оновлень пропонується переміщення пристрою до поетапного кільця оновлень, а не підхід оновлюй і сподівайся. Для проблем із умовним доступом пропонується часове виключення з обов'язковим обґрунтуванням. Рав'юа оцінює обґрунтованість. Чи справді детектор дрейфу посилався на поля з графта до фенда? Він перевіряє область дії, ідентифікатори пристроїв, ідентифікатори політик та тип змін. Якщо щось нагадує масові зміни на всіх пристроях, це негайно блокується. Безпека в місту перевіряється на вході та вигоді, щоб запобігти ін'єкціям у запити з будь-яких зовнішніх джерел або вставлених логів. Високоризикові дії, як от видалення конфліктуючої локальної політики, потребують підтвердження менеджером.

Ідентифікатор фікса не може самостійно підвищувати свої права. Схвалення відбувається в логічній програмі з наочною карткою. Що не так? Що зміниться? Кроки для відкату та посилання на джерела. Ви підтверджуєте, фікса виконує. Оновлення політик Intune є і демпотентними, та цілеспрямованими. Виправлення бітлока використовує ранбук з явними параметрами та перевіркою коректності. Перевірено наявність TPM, підтримку OS X TSS 256 та шлях депонування. Якщо попередня перевірка не проходить, виводиться зрозуміла користувачеві помилка безпобічних ефектів. Месенджер закриває цикл. Пристрій виправлено. Звіт надходить у Teams із підрахунками, посиланнями на трасування AppInsights та CSV файлом для того, хто досі любить Excel більше за власну родину. Якщо пристрій не відповідає вимогам, перевіряльник відкриває гілку виключення з таймером і запланованими повторними спробами. Можливість спостереження. Кожен виклик інструменту відстежується і пов'язується з потоком.

Ми фіксуємо зміни до та після, щоб аудит бачив невідповідності без постійного моніторингу в KQL. Ми також запускаємо агент оцінки для резюме після змін, щоб перевірити обґрунтованість і чіткість. Якщо рівень обґрунтованості падає або зростає кількість помилок, планувальник звужує пошук, зменшує розмір пакету або зупиняє деструктивні дії. Поєднання моделей SLM для вилучення та класифікації, модель міркувань для синтезу плану лише за потреби. Пакетна обробка нічного звіту. Жодних сонетів про щі. Кінцевий результат. Бітлока дійсно увімкнено. Кільця оновлень менше відхиляються від норми. Виключення задокументовані, обмежені в часі та підлягають перевірці. І ніхто не лагодить пристрій шляхом перевстановлення ОС на ноутбуках фінансового відділу під час закриття кварталу. Структура архітектури Foundry плюс SK плюс інструменти та ідентифікація. Давайте відкриємо капот, не розливши мастило на вашу квоту.

Уявіть чотири рівні, які зберігають систему в нормі Foundry, Semantic, Kernel, Інструменти, Ідентифікація. Foundry – це база. Ви визначаєте агентів із суворими інструкціями, обираєте розгортання для кожної ролі, додаєте знання через Azure AI Search і реєструєте дії. Інструменти OpenARIE, Logic Apps, функції, Graph, Azure Automation, Інтерпретатор коду. Тут живуть загрози, історія запусків, трасування, оцінки та безпека. Захист вмісту, екрани запитів і перевірки захищених матеріалів працюють до і після моделей, щоб погані вхідні дані не витрачали токени, а результати не псували роботу. Semantic Kernel – це диригент. У коді ви налаштовуєте цикл планувальника, оператора та рецензента. Ви реєструєте каталоги функцій для інструментів, налаштовуєте затримку повторних спроб і додаєте токени з касування. Ви робите запити короткими, перекладаєте складність на схеми та дозволяєте SK вирішувати, який інструмент викликати, залежно від доступності та політики.

Якщо Graph видає тайм-аут, SK обробляє це з джітером. Якщо обґрунтованість знижується, планувальник повертається до оточнення. Інструменти – це руки системи. Підтримуйте суворі контракти з OpenARIE. Помістіть ARIE Management попереду для регулювання версій і захисту від збою. Logic Apps обробляють схвалення та тривалі робочі процеси. Функції виконують роль клею та перетворення даних. Azure Automation виконує скрипти з обмеженнями та подальшими перевірками. Graph – це ваше джерело істини для Intune, Entra, комплеєнсу та показників безпеки. Azure AI Search надає структуровані знання за доменами. Жодної каші зізнань. Ідентифікація – це ремінь безпеки. Кожен агент має власну керовану ідентичність. Агенти моніторингу отримують права лише на читання. Агенти виправлення отримують права на запис, але ніколи права адміністратора. PM блокує будь-які деструктивні дії. Підвищення прав вимагає участі людини та має термін дії.

Приватні кінцеві точки там, де важливі межі даних. Базові політики в проєктах Foundry забезпечують використання дозволених моделей, регіонів і квот. App Insights та Log Analytics збирають трасування, метрики та аудити, щоб ви могли відповісти, хто і що зробив без археології в слеп. Моделі підключаються через Endpoint висновку Foundry. Використовуйте серверлес для складних міркувань, керуйте обчисленнями для закріплених відкритих моделей. Міняйте моделі без переписування коду, але оцінюйте релевантність, обґрунтованість і пленність у CI перед впровадженням. Регіони відповідають вашим користувачам, зони даних – вашим регуляторам. Разом це нудна, надійна машина. Агенти, визначені у Foundry, оркестровані SK, живляться суворими інструментами, захищені ідентифікацією, вимірюються спостережуваністю та охороняються безпекою.

Зрозуміло. Вибудовуйте мудрість завчасно, щоб не витрачати неділю на виправлення суботи. Дайте кожному агенту одну роботу. Планувальник планує, оператор оперує, рецензент рецензує. Якщо агент починає писати душевний роман, скоротіть його промп і віддайте прозу інструменту. Тримайте інструкції короткими, обмеженими та нудними. Ви отримаєте менше сюрпризів. Надавайте перевагу викликам інструментів, а не довгій прозі. Вкладайте контракти у відкритий арі, схеми у вхідні дані, а бар'єри у вихідні. Якщо інструмент очікує пристрій, надійшліть пристрій, а не може цей пристрій у фінансах. Моделі креативні, інструменти – ні. У цьому суть. Забезпечуйте мінімальні привілеї так, ніби від цього залежить ваша робота, бо так воно і є. Розділяйте ідентичності. Тільки читання для монітора, тільки запис для ремедіатора, і жодна ідентичність не має права видалення без ПМ. Підвищення прав має бути тимчасовим, обґрунтованим і зафіксованим у логах.

Якщо хтось просить постійного глобального адміна, дайте йому антистрес-м'ячик і документ із політикою. Починайте з малого – два агенти, виконавець і перевіряльник. Додайте плановальника, коли цикл стане стабільним. Потім, якщо потрібно масштабуватися, не починайте з цифрової схрам команди з 12 осіб. Ось як ви відтворюєте свою оргструктуру в IAML і плачете. Змішуйте моделі, щоб скоротити витрати. SLM для вилучення, GPT-4 клас лише для міркувань там, де це важливо. Пакетні підсумки робіть вночі. Ви не платите преміальні тарифи за форматування рядка дати. Збережіть важку модель для рішень, а не для розповіді. Пам'ять додавайте в останню чергу. Використовуйте зовнішній стан як ваш AI-пошук або невелике сховище, перш ніж набивати контекстні вікна, як ручну поклажу. Метадані потоку мають бути крихітними. Якщо це не потрібно для наступного кроку, воно не передається. Логуйте все. Увімкніть трасування, ID потоків, параметри інструментів, результати затримки.

Впроведжуйте оцінки в CI, щоб виявляти падіння релевантності та обґрунтованості до того, як вони потраплять у продакшні. Сповіщайте, коли падає обґрунтованість, а не твітер. Бар'єри безпеки перед швидкістю, схвалення для деструктивних інструментів. Режим тестового запуску безпобічних ефектів. Поступове розгортання за групами пристроїв або регіонами. Якщо ваш план розгортання, все одразу, сподіваюся, ваше резюме оновлене. Будуйте з розрахунком на відмову. Повторюйте спроби з джітером. Послабте обмеження в графі. Використовуйте запобіжники в управлінні АРІ. І демпотентні плани дій. Якщо крок можна безпечно повторити, ви спите спокійніше. Нарешті, документуйте свої політики як дані. Правила взаємовиключення пакети ліцензій, базові налаштування пристроїв, переведіть їх у структуровану форму. Моделі можуть обирати, але не повинні вигадувати. Ось як зберегти корисність агентів та обмежити зону можливих збоїв.

Якщо запам'ятаєте одне, знайте, окремі агенти допомагають, але команди агентів сплановані, керовані інструментами та з обмеженими правами тихо змінюють ваше середовище, поки ви вдаєте, що спите. Якщо це вам близько, підпишіться та дивіться продовження, де я викладу репозиторій Semantic Kernel та шаблон BICEP, щоб ви могли безсоромно їх запозичити. Хочете епізод про агентів оцінювання, які підтверджують виконання ваших обіцянок? Він у черзі на наступний тиждень.