Впровадження агентів у продакшн за допомогою сервісу Foundry Agent Service та фреймворку Agent Framework
Як агент підготовки до продажів переходить від локального коду до розгортання в хмарі з обмеженим доступом, контролем ідентичності та моніторингом, яке публікується в Microsoft 365 та ґрунтується на даних бізнесу.
Джерела: Foundry Agent Service + Microsoft Agent Framework Explained
Від прототипу до продакшн-агента
Змусити ШІ-агента працювати на ноутбуці — це проста частина. Складнішим завданням у великій компанії є безпечна робота цього агента для тисяч користувачів: надання йому ідентичності, обмеження доступу до інформації, записування його дій та розміщення його перед користувачами у інструментах, які вони вже використовують. Microsoft Foundry Agent Service разом із відкритим кодом Microsoft Agent Framework спрямовані саме на подолання цієї проблеми. Перший забезпечує хостинг із корпоративним контролем, можливістю вимірювання та пошуку, а також дозволяє використовувати агентів, створених за допомогою будь-яких бажаних інструментів. Другий допомагає створювати як одиночні агенти, так і багатоагентні системи з оркестрацією.
Ідея полягає у тому, що агента можна розгорнути безпосередньо з локального середовища, запустити під захищеним обліковим записом із обмеженими правами, а також контролювати кожну його дію, щоб можна було виправляти помилки, покращувати функціонал та масштабувати його без втрати контролю. Агенти також можна опублікувати у знайомих інструментах, де кожна дія залишається простежуваною, контрольованою та ізольованою.
Інша частина проблеми — це практична реалізація. Агенти стають корисними, коли працюють із реальними бізнес-даними: електронні листи, зустрічі та операційні системи надають персоналізовані дані, документи та презентації. Команди будують рішення за допомогою знайомих фреймворків, а потім керують продуктивністю, витратами та якістю усіх своїх агентів у міру їх зростання кількості.
Що ускладнює розгортання в корпоративних умовах
Створення агентів стало набагато простішим. Однак їх безпечне та надійне впровадження в усій організації залишається складним завданням. Багато з сучасних агентів вже давно вийшли за межі невеликих пілотних проектів. Деякі з них — це чат-функції, якими користуються тисячі співробітників, а інші працюють у фоновому режимі, іноді підключаючись до критично важливих систем.
Усі вони потребують одних і тих самих основ: контролю ідентичності та доступу, приватної зв’язності, а також телеметрії та відстеження на рівні окремого агента та всього флоту. Об’єднати ці елементи вручну є складним, і саме цю проблему призначені вирішити сервіси Foundry, щоб агенти працювали безпечно, у масштабі та з повною прозорістю. Корисно уявити альтернативу: команда, яка сама хостить свій агент, мусить вирішувати, як агент автентифікується, який обліковий запис він використовує, куди потрапляють журнали, як дані одного користувача залишаються окремими від даних іншого, та кому надсилати сповіщення у разі його неналежної роботи. Кожна з цих відповідей є окремим проектом, і під час перевірки безпеки буде ставлено запитання щодо кожної з них, перш ніж агент зможе працювати з календарем чи записом клієнта.
Приклад: агент для підготовки до зустрічі з клієнтом
Прикладом є агент, який допомагає команді з продажів підготуватися до зустрічей з клієнтами. Його код вже написаний з використанням Microsoft Agent Framework у Python, хоча можна використовувати будь-яку іншу фреймворк-систему та мову програмування. У ньому визначена чимала кількість інструментів, логіка середовища проміжного оброблення та процес роботи, і на цьому етапі все працює локально.
Відкритим питанням залишається те, як перетворити його на щось безпечне, масштабоване, відповідне стандартам та захищене в межах всієї організації. У Visual Studio Code розширення AI Toolkit пропонує функцію розгортання на хостованих агентах. Воно пакує агента у вигляді, у якому він написаний, та розгортає його в Foundry як хостованого агента. Той самий агент, який працював локально, тепер з’являється у порталі Foundry, і середовище для тестування може викликати його, щоб показати, що додає шар хостингу.
Запит у агента про те, які важливі зустрічі заплановані цього тижня, демонструє новіші підходи до роботи з агентами. Агент працює у захищеному середовищі — мікро-ВМ, де він може міркувати, перевіряти календар та писати та виконувати код, так само, як це роблять агенти для програмування, такі як GitHub Copilot CLI чи Claude Code.
Ідентичність, ізоляція та обмеження
Як тільки агент розгортається, відбувається кілька процесів, а на наступному зображенні показано, де саме в порталі відображається налаштування ідентичності та дозволів.
- Агент отримує свій унікальний ідентифікатор від Microsoft Entra. Кожна його дія, наприклад читання календаря, може бути простежена до нього. За допомогою цієї ідентичності він може автономно отримувати доступ до ресурсів у межах власних дозволів або діяти від імені людини, використовуючи її дозволи.
- Кожен користувач, який розпочинає сеанс агента, отримує окрему захищену мікроVM. Якщо два продавці ставлять запитання одночасно, у кожного є окрема інстанція агента, тож інформація з кожного сеансу читається, записується та зберігається у власному просторі.
- Для кожної взаємодії сервіс перевіряє правила та обмеження, визначені організацією, які стосуються фільтрації контенту, захисту від вставки команд та використання матеріалів, захищених авторським правом. Точний контроль над тим, що може робити та до чого може отримати доступ агент, забезпечується завдяки налаштуванням, які автоматично створюються під час розгортання.
Повернувшись на майданчик, агент надсилає свою відповідь. На основі зібраних та проаналізованих сигналів найвищим пріоритетом виявляється один обліковий запис клієнта — Zava DIY. У цьому випадку агент діяв від імені користувача, використовуючи його ідентифікацію та права, щоб переглянути календар та виявити облікові записи, які потребують уваги. Оскільки необхідно читати поштову скриньку, календар, бази даних та файли, наявність належних механізмів контролю доступу є саме тим, що потрібно для сумісної системи.
Моніторинг та публікація
Ще дві потреби корпоративних клієнтів походять безпосередньо від Foundry. Перша — це можливість спостереження. Портал забезпечує моніторинг та відстеження, тож ви можете стежити за кожною розмовою, бачити, як агент відповідає на кожне запитання, та перевіряти загальний стан агента.
Другим фактором є доступність. Коли агент починає працювати, він все одно має дістатися до людей, які його потребують, і нікому не подобається створювати новий додаток, сподіваючись, що всі знайдуть посилання та додадуть його у закладки. Якщо компанія вже використовує Microsoft 365 та Teams, кнопка „Опублікувати“ може взяти будь-який агент, розгорнутий у Foundry, та зареєструвати його в цих сервісах. Тоді люди знаходять його та використовують у тих місцях, де вони вже працюють — на настільному комп’ютері чи телефоні поза офісом. У Microsoft 365 агент з’являється у функції Copilot Chat, а також є у Teams.
Шар інтелекту, що лежить в основі обґрунтованих відповідей
Foundry також інтегрується з уніфікованим шаром інтелекту Microsoft для ШІ, який забезпечує, щоб агенти опиралися на правильні знання та бізнес-контекст, що робить їхні результати релевантними. Це значно перевищує можливості сервера MCP з одним джерелом інформації. Його складають три компоненти.
- Work IQ надає контекст про те, як працює людина: посилання на електронну пошту, календар, попередні зустрічі, чати в Teams, файли та багато іншого.
- Fabric IQ додає контекст щодо пов’язаних бізнес-операцій, таких як дані про продажі, записи клієнтів чи логістика.
- Foundry IQ поєднує кілька джерел знань для агента — від структурованих даних та баз даних до неструктурованих матеріалів у хмарних сховищах; навіть зображення можна отримати за допомогою процесів агента.
Під час першого запуску було видно лише пошук у календарі, що є частиною Work IQ. Більш розвинений агент використовує всі три компоненти.
Повний запуск: підготовка до зустрічі в Zava
Цей же агент має доступ до всіх трьох систем IQ за допомогою інструментів та навичок, які йому надано. У середовищі для роботи примітка з попереднього результату роботи агента вказує на важливу зустріч із Zava, тому наступне запитання просить його допомогти підготуватися до цієї зустрічі.
У середовищі sandbox він робить те, що щойно було описано. Він звертається до системи Work IQ для отримання кореспонденції, завантажуючи електронні листи та розмови в Teams щодо Zava. Він також звертається до системи Fabric IQ за даними про використання, закономірностями покупок та деталями контрактів. Крім того, він шукає матеріали для підтримки продажів та маркетингу в системі Foundry IQ, щоб знайти найбільш релевантні для цього клієнта матеріали.
Агент також володіє кількома навичками, створеними на основі популярної схеми навичок агентів. Одна з них дозволяє створювати презентації у форматі PowerPoint, а інша — готувати інформаційні документи у Word. Він повертає два посилані файли: інформаційний документ у Word для внутрішньої команди та індивідуальну презентацію для використання з Zava.
- У цьому звіті узагальнюється інформація з рівня розвідки, а також дані про стосунки з клієнтом з системи CRM, останні листування з користувачем, аналітика щодо стану бізнесу, рівня використання та обліку, а ще заявки на підтримку з системи обробки заявок. Результатом є єдиний документ для підготовки з рекомендованими темами для обговорення.
- Презентація адаптована саме під цю конкретну взаємодію з клієнтом та використовує кольори бренду компанії. Вона поєднує матеріали з Fabric IQ та Foundry IQ у формі ключових тез та інсайтів, специфічних для клієнта щодо останньої діяльності, разом із даними про бізнес-операції, показниками кампаній, а також новими можливостями та послугами, які можуть розвинути партнерство далі.
Ця цінність походить не лише від процесу розгортання: агенти працюють на рівні шару інтелекту, де вони отримують доступ до робочих даних, бізнес-даних та організаційних знань від імені користувача, завдяки тісній інтеграції з Microsoft 365.
Як це створюється
Для розробників, які хочуть створити щось подібне, відправною точкою є простіша версія, ніж повний приклад. Azure Developer CLI дозволяє ініціалізувати новий проект, наприклад агента для підготовки до продажів. Підтримуються агенти на основі чату, які залишаються дуже популярними; можна використовувати будь-яку фреймворк, включаючи LangGraph, а сервіс також підтримує нові підходи. Шаблони створюють структуру необхідних файлів, і з їх допомогою проект можна відлагоджувати локально та розгортати. Це простий агент, створений за допомогою шаблону, з великою кількістю можливостей для налаштувань.
Якщо повернутися до розгляду розширеного агента, можна побачити, що стоїть за ним. У коді визначаються інструменти та джерела знань, включаючи три типи інтелекту, а також інші види навичок, які можна додати до шаблонів кодуючих агентів сьогодні. У основі роботи агента лежить SDK GitHub Copilot, який запускає цикл обробки через визначений набір інструментів. Цей цикл аналізує десятки файлів, електронних листів, попередніх зустрічей, а також оперативні та сервісні дані, і саме на основі цього аналізу формуються рекомендації.
Microsoft Agent Framework об’єднує всі компоненти та додає такі елементи, як мідлверд. Ось приклад правила: якщо агент для кодування намагається створити один із цих документів без достатньої кількості даних з трьох IQ, мідлверд блокує цей процес, адже результат без належних даних майже завжди є хибним. Такі патерни мають велике значення під час масштабування корпоративних рішень, коли контроль якості охоплює всю команду з продажів та додаткові механізми захисту. Повна користь проявляється тоді, коли фреймворки та патерни поєднуються та розміщуються всередині Foundry Agent Service.
Керування флотом
Як тільки починає працювати кілька агентів, наступним питанням є їх моніторинг та керування, що є можливим завдяки тому, що все відбувається всередині Foundry. Портал демонструє продуктивність та витрати для всього флоту в одному вигляді: стан агентів та сповіщення (у демо-версії всі агенти у стані «здорові», сповіщень поки немає), орієнтовні витрати, показники успішності та використання токенів, а також детальну інформацію про обсяги роботи найактивніших агентів. Найкращі та найгірші агенти за показниками успішності вказують, які з них потребують уваги.
Усе необхідне для переходу від експериментування до продакшну та для публікації серед усіх кінцевих користувачів вже вбудовано разом із повною можливістю моніторингу. Основна мета — скоротити складність безпечного та надійного створення та розгортання агентів у всій організації. Для тих, хто готовий спробувати, достатньо розпочати перший проект у порталі Foundry та ознайомитися з публічними зразками від Microsoft, щоб знайти відповідний SDK.
З усього цього випливає практичний порядок дій. Почніть з невеликого агента за шаблоном та запустіть його локально. Додавайте інструменти та джерела інформації по одному, використовуючи проміжне програмне забезпечення, яке не дозволяє продовжувати роботу при відсутності необхідних даних. Розгорніть систему у хостованому середовищі якомога раніше, щоб можливості ідентифікації, ізоляції та відстеження функціонували ще до приходу справжніх користувачів. Опублікуйте її у чат-інструментах, які вже використовують люди, лише після того, як дані відстеження будуть достовірними, та тримайте перегляд усіх агентів активним, коли кілька з них вже працюють, адже саме там спочатку проявляються зростання витрат та зниження рівня ефективності. Команди, які дотримуються цієї послідовності, зазвичай виявляють проблеми, коли їх ще легко вирішити.
Чому локальні та хостовані рішення поводяться настільки по-різному
Варто розділяти те, що написав розробник, від того, що додає платформа. Інструменти, середовище міжрівневого програмування та процеси роботи в агенті з продажів є звичайним кодом додатку, і вони поводяться однаково як на ноутбуці, так і в хмарі. Після розгортання змінюється все, що оточує цей код: існує система ідентифікації, сеанси ізольовані, політики оцінюються при кожній взаємодії, накопичуються записи про дії, а також відкривається шлях для публікації. Для всього цього не потрібно переписувати агента, тому в демонстрації розгортання розглядається як єдиний крок у редакторі, а не як проект міграції.
Три запитання підсумовують цей підхід, і кожне з них відповідає певному рівню, описаному вище.
- Хто діє? На це питання відповідає система ідентифікації Entra – чи використовує агент власні дозволи, чи бере їх у користувача.
- Де відбувається робота та хто може її бачити? Мікро-середовища VM на рівні користувача ізолюють сеанси, а політики щодо контенту та вставки від організації застосовуються до кожного запиту.
- Що воно робило та чи працює належним чином? Історія дій, перегляд розмов, показники стану, підсумки витрат та коефіцієнта успішності дають відповіді на ці запитання як для окремого агента, так і для всієї системи.
Механізми контролю всередині коду
Механізми захисту платформи не замінюють захисні правила, вбудовані безпосередньо в агента. Хорошим прикладом є правило проміжного програмного забезпечення, яке блокує створення документа, якщо три індикатори якості не надали достатньо даних, адже воно забезпечує певний рівень якості, про який жодна універсальна політика не може знати. Інформація, підготовлена без використання історії CRM чи показників використання, все одно виглядатиме професійно, і продавець може відвідати зустріч з клієнтом, спираючись на вигадані деталі. Зупинити це на рівні коду, ще до створення файлу, дешевше, ніж виправляти проблему пізніше.
Саме такий підхід пояснює, чому демо-версія об’єднує навички у окремі, повторно використовувані елементи. Навичку створення колоди та навичку написання короткого опису можна окремо тестувати, створювати для них версії та використовувати іншими агентами, причому цикл агентів визначає, коли їх викликати. Поєднання цього циклу, проміжного програмного забезпечення фреймворку та шару хостингу дає три можливості для здійснення контролю: спосіб міркувань агента, те, що йому дозволено передавати, та те, що дозволяє середовище.
Аспекти, які потрібно врахувати перед копіюванням цього паттерну
У прикладі показано ідеальний варіант, коли всі джерела даних підключені, а права доступу налаштовані належним чином. На практиці якість інформації залежить від якості базових даних CRM, систем обробки замовлень та аналітики. Обмежені права доступу допомагають лише тоді, коли вони справді обмежені, а агент, який діє в межах прав власного користувача, може бачити все те, що бачить цей користувач, тому надто широкі облікові записи призводять до надто широких повноважень агентів. Панелі керування флотом корисні для виявлення найслабших агентів, але хтось все одно мусить аналізувати записи та вирішувати, чи низький рівень успішності пов’язаний із моделлю, інструментом, відсутнім джерелом даних чи занадто суворими обмеженнями.
Пов’язана література
- MAF 1.0, LangGraph чи CrewAI? Вибір фреймворку агента у 2026 році — Порівняння Microsoft Agent Framework 1.0, LangGraph та CrewAI щодо стану, пам’яті, налагодження, протоколів, шляхів у Azure та витрат, із коротким алгоритмом прийняття рішень та схемою впровадження.
- Знімки пам’яті агента, навички, занепад якості та обмеження пам’яті за гілками — Чотири доповнення до вбудованого шару пам’яті у вигляді векторної БД для програмування агентів: портативні знімки з можливістю об’єднання, активація навичок, занепад якості з перевіркою конфліктів та пам’ять, обмежена за гілками.