Вітаємо всіх на подкасті MC65FM. Сьогодні ми виходимо за рамки однієї з найпоширеніших EEE розмов про розробку запитань Microsoft 365 Co-Pilot, тому що, коли одна з організацій почала серйозно використовувати Co-Pilot, питання швидко змінилося з «Як нам писати кращі запити?» На «Як нам підключити Co-Pilot до програм, даних програм EEE, бізнес-процесів та знань, які фактично працюють у нашій компанії?» І саме тут розширюваність Co-Pilot стає цікавою тестування. Моя сьогоднішня гостя є вас Harvest, MVP Microsoft, консультант з бізнес-застосунків, AI-словникова група у Швейцарії. Євас працює з Microsoft 365, Azure Dynamics 365 та Pava Platform, зосереджуючись на розширенні Microsoft 365 Co-Pilot за допомогою агентів та індивідуальної розробки. Ми збираємося дослідити розширюваність Co-Pilot Microsoft 365, Co-Pilot Studio, Microsoft Azure Foundry. Я не знаю, чи змінять вони назву на Microsoft Graph, індивідуальна розробка, MCPS тощо.

Тож так, ласкаво просимо до подкасту MC65. Привіт усім, дякую, що запросили мене. Це справді гарна EEE, гарна можливість для мене бути тут. Тож дякую, що запросили мене. Так, я дякую вам. Перш ніж ми перейдемо до технічних деталей, чи можете ви трохи розповісти про свій шлях, як ви потрапили в екосистему Microsoft? Так, так, так, звичайно. Тому що, чесно кажучи, я розпочав свою кар'єру не у світі Microsoft. Отже, я розпочав свою кар'єру у світі Apple. Я був інженером-програмістом на платформі Mac, а після цього перейшов на iOS. Такі речі.

І о, це було давно. І, можливо, десь 15 чи 20 років тому я перейшов на роботу в Microsoft. Чесно кажучи, ЕЕ, я розпочав свою кар'єру в Sharp у США. ЕЕ, а після цього я перейшов на хмару Azure EEE M365. ЕЕ, якщо я працював у Sharp на місцях, я почав так ЕЕ, а потім я перейшов на всі хмарні сервіси і ЕЕ, на платформу PO, і зовсім недавно, на всі речі, пов'язані зі штучним інтелектом. Чесно кажучи, тому що ЕЕ – це зараз велика частина М265, тому що у вас є, у вас є агентний, ЕЕ – перехід зараз, і ЕЕ – це, якщо коротко, моя, моя, ЕЕ – моя подорож. Але я розпочав свою кар'єру у світі програмної інженерії, що, можливо, сьогодні є словом, яке багато людей забувають, тому що у нас, у вас, у вас зараз є все, що пов'язано зі штучним інтелектом, і ЕЕ, і в основному цей вид діяльності чи роботи перейшов до штучного інтелекту, тому це досить відрізняється від того, що було 20 років тому, ніж зараз. Так, ви працюєте, ви кажете, що працюєте з SharePoint, і я бачу, що ви також працюєте з Graph Spike Dynamic Power Platform.

Як цей досвід підготував вас до поточного покоління розробки ЩІ? Е – в основному, я Е – мій профіль справді.

Наск різний в основному тому, що ЕЕ – у своїй кар'єрі я. Працював з багатьма продуктами. Це можуть бути продукти Microsoft і не Microsoft. Тож, в основному, я маю широкий спектр навичок щодо багатьох різних технологій та інструментів.

Отже, ЕЕ – вся моя робота дає мені хороший бекграунд, тому що зараз зі штучним інтелектом – це біла, це біла тема, тому що є різні підходи, різні технології для роботи зі штучним інтелектом зараз.

Це може бути агентивне, це може бути більше робочого процесу, так і речі. Тож, в основному, вся моя попередня робота дає мені багато навичок, щоб бути готовим до цього переходу на штучний інтелект зараз, якщо чесно. Тож, я перейшов на лоу-коуд, на не ЕЕ до інструментів для обробки коду. Тож, так ЕЕ, оп, так, всі ці можливості та ЕЕ діяльність на моїй роботі дають мені ЕЕ хороші навички, щоб скористатися перевагами у світі штучного інтелекту, якщо чесно. Це справді гарне питання, тому що багато людей мене запитують. Тож, моя робота полягає просто в тому, щоб зіставити ЕЕ функціональну специфікацію з технічним ЕЕ технічним стеком. Тож, я беру на себе ініціативу, коли ЕЕ проведено бізнес-аналіз. ЕЕ ми визначили варіанти використання в щі ЕЕ для речей, пов'язаних зі щі. ЕЕ ми визначили сценарії, варіанти використання. Ми провели повний бізнес-аналіз, і моя робота полягає в тому, що я беру ці потреби та зіставляю їх з технічним стеком за лаштунками.

А після цього я керую всім впровадженням інструментів та рішення ЕЕ, коли ми будемо готові розпочати розробку. Так, цікаво, ЕЕ насправді. Багато компаній купують навчання для своїх співробітників, особливо ЕЕ, так ЕЕ, для швидкої інженерії, і чому ви кажете, що цього недостатньо?

Ви маєте на увазі лише швидку інженерію в наші дні. Так, так, чому, чому, чому, чому, чому, вони?

Чому, це просто, знаєте, чому для компаній ЕЕ недостатньо лише навчити людей швидкої інженерії. А так, добре, зрозуміло, зрозуміло, добре, так, так, ЕЕ.

Чесно кажучи, сьогодні, як я вже казав, у вас є багато різних інструментів і технологій, тому і в певний момент ще може зрозуміти, що робити і, можливо, трохи направити вас. Але для мене ЕЕ – роль, наприклад, архітектора чи розробника програмного забезпечення, ЕЕ – вам потрібна людина за лаштунками, тому що вам потрібно зрозуміти клієнта. В основному ще іноді не може зрозуміти контекст клієнта. ЕЕ – ви бачите всю мережу, але за лаштунками ЕЕ – зосередитися лише на оперативній розробці, це може бути добре в певний момент, але вам потрібно більше, тому що вам потрібно мати за лаштунками ЕЕ деяких людей, які є ЕЕ – архітекторами, розробниками програмного забезпечення і в основному багато людей, які мають навички в технологіях, ЕЕ – інформаційних технологіях, таких як SharePoint, наприклад, Onedrive, якого я не маю, або Salesforce в таких речах. Вам потрібні фахівці з ЕЕ цих технологій, тому що ще може розуміти багато речей.

Він може ЕЕ може направити вас. Ви можете створювати чудові технічні або функціональні документи, але вам потрібні люди за кадром, які подбають про те, чи це добре. Чи це ЕЕ відповідати на потреби клієнта – такі речі, які ви бачите, щоб перевірити все та зосередитися лише на оперативній інженерії. Для мене зараз так це може бути варіантом, якщо у вас ЕЕ немає часу на навчання або інвестування ЕЕ у ЕЕ у розвиток деяких-деяких навичок. Але для мене, вам, чесно кажучи, потрібно мати хороші навички в базових технологіях, на яких ви хочете будувати свої рішення. Так, так. Так, це гарне питання, тому що, чесно кажучи, два роки тому, коли Коупайлот був випущений, і ЕЕ, можливо, перша версія ЕЕ в основному розмова була, чесно кажучи, дуже-дуже мінімалістичною. В принципі, ви можете, гаразд, це був чат GPT-типу, але Microsoft значно розвинув Microsoft 365 Коупайлот. По суті, тепер у вас є приховано, у вас є різні види функцій, тому тепер розширюваність.

Менша, ніж раніше, тому що ЕЕ раніше ви розробляли деякі плагіни, такі речі, але сьогодні, чесно кажучи, на даний момент ЕЕ – розширюваність. Розширюваність – це коли ви хочете щось створити, і ми хочемо налаштувати, по суті, оркестратор або ЕЕ. Ви хочете трохи більше персоналізувати ЕЕ, наприклад, інтерфейс користувача, якщо ви хочете інтегрувати свого агента не лише в чат Microsoft 365, але й, наприклад, на вашому веб-сайті такого роду. Тож розширюваність починається, коли ви хочете, по суті, більше налаштувати закулісну роботу, ви хочете трохи більше налаштувати.

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

Тепер Microsoft представила спільну роботу Coopilot, і, чесно кажучи, сьогодні спільна робота Coopilot може замінити багато агентів. І хоча ми думаємо про ЕЕ-агента, це просто для того, щоб розділити речі, тому що зараз ми більше працюємо в мультиагентній моделі, де кожен агент має свою сферу діяльності та свої обов'язки. І ми не робимо великого Coopilot, в основному це просто через продуктивність. По-перше, тому що ЕЕ, коли у вас є невеликий набір інструкцій та інструментів, ЕЕ, з точки зору продуктивності, це буде безлад. І ЕЕ, архітектура зараз більш мультиагентна, це може бути в Coopilot Studio, це може бути в агенті розробки на замовлення з точки зору коду туру або індивідуальної розробки. Але сьогодні краще мати мультиагентний підхід, де кожен агент має свою сферу діяльності та свою відповідальність з точки зору ЕЕ, просто з точки зору продуктивності і мати чітку архітектуру з точки зору агента.

Так.

Шопенбер. І коли ми дивимося на це, добре, я думаю, що базова ЕЕ, архітектура агента ЩІ, тоді у нас є, я кажу, деякі паролі.

У нас є паролі. Добре. Але ми повинні думати про міркування, інструменти, знання та ЕЕ, інструктаж ЕЕ в інструкціях.

Як це вписується в архітектуру агента ЩІ? Перше, про що варто подумати, одне з перших питань, на яке потрібно відповісти, це Яка мета? Перша мета цього агента.

В основному, після розробки архітектури агента все залежить від того, чи ви використовуєте лоу-коуд підхід, чи користуєтеся кастомним підходом розробки, тому що підхід зовсім інший, тому що ЕЕ в кастомному підході розробки ви керуєте всім. Тож ви керуєте безпекою, ви керуєте хостингом, ви керуєте ЕЕ, ви керуєте багатьма різними речами. У лоу-коуд підході все зовсім інакше, тому що ЕЕ ви думаєте про те, що ви даєте інструкції, ви вибираєте деякі інструменти. Тож, по суті, архітектура в лоу-коуд підході насправді. Не така проста, як я вже сказав, але вона може бути дуже швидкою, тому що ви можете визначити, у вас є інструкція, ви можете вибрати свої інструменти, ви можете вибрати іншого ЕЕ, іншого ЕЕ, іншого агента, якщо ви хочете підключитися. Але це дійсно просто, коли ви маєте справу з кастомною розробкою або коли ви розробляєте власного агента. Це може бути, наприклад, саментик ядро, ейджант фама, такі речі.

Архівактик може бути набагато складнішим, оскільки вам потрібно мати справу з концепцією справді просунутої концепції безпеки, як я вже казав. Хмій. Що? Стосується автентифікації, якщо у вас є кілька інструментів, наприклад, і ви хочете інтегрувати деякі NCP, якщо ви хочете підключитися до внутрішніх інструментів, захищених зворотними проксі серверами тощо. Отже, в основному вам потрібно більше враховувати. Архітектуру, коли ви маєте справу з користувацькими агентами, наприклад, у Coopilot Studio. Що стосується архітектури, то вам потрібно дуже швидко визначити архітектуру в користувацькому підході до розробки. Вам доводиться мати справу з просунутою концепцією, і для багатьох людей це може бути складно, тому що це дійсно фундаментальний аспект. І, чесно кажучи, у моїй роботі я маю справу з багатьма різними потребами. Це може бути кастомна розробка, це може бути Coopilot Studio, це може бути простий агент Вейджант Білда з дуже простим і акуратним оформленням.

Отже, по суті, визначення архітектури насправді залежить від того, який підхід ви хочете обрати. В основному у вас є загальна EEE-архітектура, яку ви можете створити, але потім це дійсно залежить від підходу, який ви хочете, низький код чи код розумієте. Хмі, але чи можемо ми EEE, можемо, чи можете ви описати анатомію типового корпоративного EEE-ші-агента?

Ах, так, можу.

EEE, в основному, якщо ви хочете говорити якомога простіше EEE, коли ви, коли вам потрібно, наприклад, це може бути EEE, агент і те підтримки, наприклад, EEE, в основному, це може бути, це може бути, у вас є набір, в основному. Але після «в наш час», як я вже казав, у вас є цей багатоагентний підхід, і в основному я розглядаю першого агента як фронт, EEE як фронт. Отже, це фронт-агент, і цей фронт-агент буде EEE направляти всі.

Запити, наприклад, через різних агентів. Наприклад, якщо користувач запитує щось на кшталт «я не знаю», щодо Salesforce він направлятиме всі запити до ІТ-агента підтримки Salesforce. Бачите, в основному для деяких клієнтів ми створили таку архітектуру, оскільки кожен агент відповідає за обсяг. Це може бути для таких продуктів, як Salesforce. Це може бути для M365 тощо. А за лаштунками кожен агент має один набір інструкцій і один набір із двох. І в наш час краще використовувати MCP-сервери, тому що MCP-сервер зараз є універсальним плагіном для інтеграції кількох сервісів з OL.

У мене є набір MCP-серверів, а також Деякі внутрішні джерела знань. Це може бути JIRA, це може бути база знань служби LED, такі речі. Отже, у вас є набір інструкцій для кожного агента.

EE і ці інструкції визначають область дії агента та EE, яка роль кожного агента, і після EE у вас є набір серверів MCP-с, і, можливо, EE джерелами знань можуть бути PDF-файли. Тож це може бути кілька багато-багато видів EE багато видів джерел даних.

І після, вибачте, коли, коли, наприклад, користувач запитує до головного агента, після EE це визначить, добре, мені потрібно делегувати це завдання.

Відповідному агенту. EE давайте трохи розглянемо можливості.

Coopilot Studio, де він вписується в загальну архітектуру.

Coopilot Studio, чесно кажучи, EE – це локальний інструмент від Microsoft. Отже, по-перше, і EE з точки зору архітектури Coopilot Studio дійсно. Призначений для розробників, в основному для людей, які, перш за все, не є розробниками. І з точки зору EE архітектури, в основному EE, наприклад, якщо ми, якщо ми візьмемо приклад, який я навів раніше, то, наприклад, ІТ-підтримка EE підійде, тому що з точки зору архітектури Coopilot Studio виконує роботу, тому що ви можете визначити її, ви можете визначити NCP сервер, ви можете легко інтегрувати деякі EE, деякі зовнішні джерела знань або внутрішні джерела знань, якщо хочете. EE, після того, як я вже казав раніше, якщо, наприклад, у вас є випадок використання, коли ви хочете трохи налаштувати оркестратор, тому що за лаштунками Coopilot Studio ви не можете, EE, налаштувати оркестратор, тому ви активуєте оркестратор штучного інтелекту, ось і все. Ви не можете, наприклад, налаштувати пріоритет EE, наприклад, завдання, яке ви хочете досягти, тому що за лаштунками компілятор Studio визначить гаразд ваш план, а потім ви його виконаєте.

Але якщо ви, якщо ви хочете мати трохи більше можливостей налаштування, у цьому випадку вам потрібно використовувати користувацьку розробку, наприклад, із Semantic Kernel Longchain Framework, який нещодавно випустила Microsoft, і в цьому PH ви можете EE, легко налаштувати оркестрацію EE, ви можете визначити деякі робочі процеси, ви можете, ви можете налаштувати те, що ви хочете. Це Coopilot Studio як архітектура, яка дійсно чітко визначена для розробників та розробників, тому що дуже просто мати працюючий агент. Єдина проблема з Coopilot Studio, і вам потрібно подбати про це, тому що коли ви визначаєте, коли ви обираєте свій шлях і, можливо, ви визначаєте свою архітектуру, вам потрібно подбати про ліцензування, тому що це велика частина. Кожного рішення зараз EE. І сьогодні Coopilot Studio трохи еволюціонувала в модель оплати по мірі використання, і вам потрібно подбати про оцінку витрат, тому що, виходячи з того, чого ви хочете досягти, іноді краще зробити власну розробку, тому що після того, як ви розмістите там, де хочете, і ви подбаєте про всі витрати, ви можете легше оцінити, ніж зараз.

Тому що з кредитним підходом Coopilot іноді важко передбачити, скільки це коштуватиме за один місяць, два місяці.

То що? І які? Обмеження у Coopilot Studio Studio EE, коли я вибиратиму «Тоді я думаю» «EE» так Microsoft Foundry Azure, Foundry, я не знаю, як це насправді називається «EE» «EE» і коли «EE» я маю сказати «Гаразд!» «Еее» я маю зробити повністю кастомну розробку. Перше питання, на яке потрібно відповісти «Гаразд?» Чи потрібно мені налаштовувати оркестрацію? Це моє перше питання, тому що це питання скаже вам, гаразд, якщо ви не хочете налаштовувати оркестрацію, занадто глибоко заглиблюватися в те, як робиться вся оркестрація або генерується план, ви можете використовувати низькокодовий підхід з Co-Pilot Video EE, наприклад, конструктором. Також іноді, коли у вас простий випадок використання, ви можете використовувати такі інструменти. Але якщо ви хочете налаштувати оркестрацію, вам потрібно перейти до конкретної розробки і в цьому випадку вам потрібно, е-е, вам потрібно використовувати Foundry для моделі або якщо у вас є власна платформа, тому що перевага кастомної розробки.

Ви можете інтегрувати моделі, які не розміщені в Microsoft Fundy. Якщо хочете, можете використовувати моделі Fundy, але також, якщо у вас є. Платформа AWS або Google, платформа Google GooglePlate, вибачте, і ви сказали, наприклад, Gemini або у вас є зовнішня розгорнута модель, ви маєте можливість інтегрувати ці моделі безпосередньо у ваш агент, використовуючи користувацький підхід.

Це також є перевагою, і після того, як ви можете налаштувати оркестрацію, те, як генерується план, все це буде розміщено в агенті Foundry. Проблема Foundry сьогодні полягає в тому, що спочатку Foundry була просто платформою для розміщення моделей. Якщо подивитися на кілька років тому, то це був просто простий каталог моделей, і ви його розгортали.

Сьогодні Microsoft розвинула цей продукт таким чином, що ви можете створювати агента за допомогою інтерфейсу Co-Pilot Studio практично без будь-якого коду. Ви можете керувати управлінням, ви можете керувати багатьма речами. Це стало справді агентною платформою, такою як Co-Pilot Studio для локот та подібних речей.

І сьогодні Foundry справді важко розмістити в екосистемі, оскільки Foundry швидко розвивається. І, по суті, Microsoft представила деякі функції, які насправді EEE, я не знаю, не відрізняються, але є подібність до Co-Pilot Studio з точки зору інтеграції MCP таких речей. Але після EEE обмеження Co-Pilot Studio головне обмеження стосується моделей. Тож у вас є гаразд, у вас є можливість інтегрувати код або візуалізувати різні речі. Але якщо ви хочете інтегрувати, наприклад, EEE, свою власну модель, тому що у вас є певна версія вашої моделі EEE, ви не можете цього зробити, і, по суті, вам потрібно використовувати спеціальний розробник, щоб інтегрувати свою власну, наприклад, платформу LM, якщо у вас є. У мене є клієнт, який має власну EEE платформу AWS. У цьому випадку ви можете інтегрувати EEE, цю модель із ціноутворенням EEE, керованим зовні.

Добре, добре. І я думаю, що коли ми створюємо EEE агента на одну тему, це також вся війна.

Так, Шопенбер.

Більшість людей говорять, що це MCP, протокол контексту моделі.

Хмі, чому, чому, чому це стало однією з найбільших тем в агентній розробці і для тих, хто ще з цим не працював, що таке протокол контексту моделі.

Так, це гучне слово. В основному, багато людей говорять про це, тому що це вирішує серйозну проблему.

Ідеться про те, як уніфікувати інтеграцію інструментів, навичок, можливо, я не знаю зовнішніх інструментів для ЩІ, і це вирішило цю проблему, тому що в минулому EEE без MCP все було як безлад, тому що багато сервісів говорять по-різному. У вас є різні EEE, технологічні протоколи, у вас є різні EEE, архітектурні підходи, і в основному MCP уніфікує або інтегрує сервіси EEE. Уваж, це може бути агент ЩІ або рішення ЩІ, якщо я кажу більш загально EEE, але MCP зараз EEE – це справді спосіб інтеграції зовнішніх або внутрішніх інструментів, можливо, і те, і інше. Але MCP зараз є важливою частиною архітектури ЩІ, тому що у вас є ця EEE – єдність з точки зору технологій. І сьогодні це важливо, тому що EEE раніше це була інтеграція АРІ, а тепер це MCP. Хмій. Це EEE – це не еволюція, але в минулому ви інтегрували свого агента з АРІ. Вам потрібно було керувати, гаразд, як автентифікація, керувати цим або викликати інструмент.

Тепер ще може гаразд, у мене є цей інструмент, я можу вибрати, що мені потрібно для досягнення мети.

І що, що насправді змінилося з MCP на АРІ чи підключення? EEE – в основному, в минулому, з точки зору.

Інтеграції в основному АРІ не були інтелектуальними, якщо я можу це сказати, EEE – АРІ – це просто гаразд, ви викликаєте, ви викликаєте, ви викликаєте інструмент, і він надає вам дані. Різниця з MCP полягає в тому, що MCP є більш інтелектуальним з точки зору архітектури, тому що за лаштунками у вас є не тільки інструменти, які надають вам дані чи інформацію, але й навички навчання, EEE та різні види речей, що робить MCP справді інтелектуальним. І, по суті, MCP може сказати ЩІ – гаразд, ви хочете цього досягти. Я можу надати вам EEE, саме ті інструменти, які відповідають вашому EEE запиту, і ви можете викликати не лише один інструмент, але вам потрібно викликати ці інструменти, щоб досягти того, чого ви хочете. Це роль MCP. Він надає ЩІ – у мене є ці інструменти, а після EEE ви можете викликати один або цей, один або кілька інструментів для досягнення ваших цілей.

Він дає вам, дає вам, дає ЩІ контекст, реальний контекст, EEE, всього, і АРІ – це просто добре, у вас є інструменти, у вас є опис, і це майже все, так що це так – це.

Модель контексту протоколу, я думаю, схожа на метадані чи як це працює.

EEE – ні. MCP за лаштунками, EEE – це просто, EEE – це протокол. По суті, це технологічний протокол, і за лаштунками у вас є, так, у вас є метадані, у вас є опис, EEE, у вас є навички ЩІ, які описують більше, EEE – він дійсно зосереджений на ЩІ. По суті, у вас є навички, у вас є інструкції, і, по суті, ЩІ може краще розуміти, гаразд, ці інструменти, EEE, роблять це, цей інструмент робить це, Добре, я можу викликати ці навички, я можу запитувати, EEE, цю інформацію на сервер MCP, щоб досягти того, що я можу запитати. Але у вас є, так, у вас є частина метаданих, тому що вам потрібно визначити, EEE, назву інструменту, що робиться за лаштунками. Чи можемо ми сказати, що майбутнє за MCP? Отже, ми повинні почати думати про те, я не знаю, компанії мають стоарі і стіарі всередині організації, чи повинні вони почати створювати сервери MCP навколо них.

Так, так, в основному EEE, сервер MCP, EEE, ми працюємо з зарі за лаштунками. EEE, це не заміна, по суті. EEE, якщо ви, якщо я підсумую це, тому що сервер MCP просто нормальний. EEE, він дає контекст, і за лаштунками MCP може викликати АРІ. За лаштунками, але MCP сервер, це Frontend, Frontend EEE, Frontend EEE, Frontend EEE, Frontend Інструмент, який вам потрібно викликати, тому що за лаштунками ви будете відправляти EEE, ваш запит на основі. За лаштунками, це може бути АРІ, це може бути база даних, це може бути кілька інструментів, але вам потрібно, якщо хочете мати власний MCP сервер, наприклад, якщо у вашій компанії є EEE, АРІ, і у вас є різні види.

Послуг, це може бути, я не знаю, фінансова служба, це може бути служба HR, якщо ви хочете створити свій власний MCP, вам потрібно мати справу за цією сферою, EEE, з усіма цими АРІ, і NCP сервер нам знадобиться, щоб надати доступ до всіх цих АРІ, що таке, які послуги, які доступні інструменти, які навички тощо.

Після цього вам потрібно буде мати справу з автентифікацією за лаштунками, тому що АРІ працюють по-різному, тому що ви можете мати автентифікацію за ключем, вводячи такі речі. Отже, вам потрібно з цим розібратися, але MCP надасть доступні інструменти, а за лаштунками всі ці інструменти можуть запитувати кілька АРІ. Один АРІ може бути, у вас є різні типи архітектури за лаштунками. Добре. І?

Як MCP?

Вибирає правильний інструмент, коли у мене є, я не знаю, 100-500 агентів ЩІ. Ее – це буде базуватися на Ее перших речах. В основному, коли у вас є запит до агента Ее, ви виявляєте всі доступні інструменти. Сервер MCP перевірить – гаразд, у мене є всі ці інструменти. І в основному Ее – оркестратор агента зрозуміє – гаразд, у мене це є, у мене доступний ЛЛМ.

Після цього ви створите план. Якщо коротко, ви створите план з деякими діями, які потрібно виконати, і після цієї дії – Ее – дії, яку ви хочете виконати – Ее – ви можете викликати один, два, три або більше інструментів, щоб виконати завдання, яке запросив користувач. Отже, по суті, оркестратор агента розумітиме інструменти MCP та вибиратиме найкращі для запиту. Бачите?

Це справді роль оркестратора у виборі інструментів та подібних речей за допомогою ЛЛМ, звичайно, тому що ЛЛМ, Ее – це частина мозку, і оркестратор буде, гаразд, взаємодіяти з ЛЛМ та інструментами, щоб зробити найкращий вибір та найкращий план для виконання завдання.

Так, я, я думаю, що деякий час багато компаній починали з PowerShell, а тепер вони використовують Microsoft GraveArry. Чи створили вони графік, і NCP з'являється, Ее, або як зробити, так, я думаю, що Ее, насправді, насправді, граф Арі, Ее, чесно кажучи, ні, немає, Ее, MCP, Ее, MCP для графіків.

Якщо ви, якщо ви це назвете, знаєте, у світі Microsoft, Cifi Microsoft представила багато MCP-серверів, і ці MCP-сервери базуються на Microsoft Grave. Наприклад, якщо ви хочете використовувати, я не знаю, LCP-сервер команди за лаштунками, у вас викликається GraveArry, коли ви використовуєте NCP-сервер. Тож, графічний ще у світі Microsoft 365 є центральним, тому що за лаштунками Ее, NCP взаємодіятиме з Grave, щоб зробити запит Ее, щоб запит працював добре. Але так, сьогодні граф також є центральним у Coopilot загалом, тому що семантичний індекс Coopilot базується на необроблених даних, але насправді, знаєте, ви споживаєте граф через звуки MCP. Сьогодні Ее – це так, ніби.

Microsoft 65 містить неймовірну цінність організаційні контексти, документи, зустрічі, електронні листи, люди, команди, розмови та, я кажу, обмін контентом. Як нам розкрити цей контекст – не.

Створюючи кошмару безпеки. Ее – ви маєте на увазі з точки зору управління такими речами.

Так, це завжди проблема, тому що багато людей створюють агента, не створюючи належного управління за лаштунками. Тож я хочу створити агента. Добре, почнемо. Ми створюємо та розгортаємо, і після цього «Ах, але Ее, гаразд, цей агент працюватиме з великою кількістю даних». Як цим керувати? Перше питання – як мені впровадити управління агентами. Раніше це може бути, як ви сказали, безладом. Тому що «Ее» багато людей хочуть. Гаразд, я хочу створити агента-агента-агента, або я хочу створити щось «Ее», я хочу створити рішення на основі штучного інтелекту, але за лаштунками «Ее». Одним з перших, що потрібно зробити, це зрозуміти свої дані. Тому що без розуміння своїх даних ви загубитеся. Вам потрібно зрозуміти свої дані, тому що важливо розуміти, чи маю я справу з конфіденційними даними, чи ні. Чи маю я справу з «Ее» дуже конфіденційними даними. Добре. «Ее» вам потрібно розуміти свої дані. Після того, як ви працюєте в Microsoft CR, вам потрібно впровадити, наприклад, функції DLP, маркування чутливості, тощо, тому що без цього «Ее» це може бути проблемою.

А після цього вам також потрібно трохи очистити «Ее» ваші дані, тому що «Ее» ще з поганими, з поганими даними ваш агент не працюватиме так, як ви хочете, Тому що «Ее», якщо у вас є «Ее», якщо у вас є маска у вашій, я не знаю SharePoint «Ее», команді «Ее», командному каналі. Такого роду річ, якщо це маска «Ее», в основному буде важко правильно працювати «Ее» в агентському «Ее» підході. Але так, вам потрібно розуміти свої дані, вам потрібно впровадити деякі «Ее», засоби безпеки «Ее», базові, такі як «Ее», автентифікація, як я вже казав, функції PureView «Ее» і PureView став центральним рішенням для впровадження всіх цих «Ее», всіх засобів безпеки та управління «Ее» речей на місці. І після того, як ви очистите свої дані, коли впровадите деякі основні заходи безпеки, вам також потрібно зрозуміти «Ее» ліцензування, тому що перш ніж почати створювати агента, вам потрібно зрозуміти, що таке розробники, чи навчені вони цьому, чи маємо ми правильне ліцензування, щоб почати роботу, чи потрібні нам такі підписки «Ее», після «Ее» ще одна.

Велика проблема – це інструменти «Ее», як мені правильно інтегрувати всі інструменти «Ее» в «Мій», у моєму розробнику «Мій агент» «Ее», чи потрібно мені щось обмежити.

Тож, чесно кажучи, це велике питання, у вас є різні види діяльності, які потрібно враховувати, але «Ее», для мене найважливіше розуміти ваші дані, і «Ее», якщо компанія не розуміє дані, це буде проблемою на початку, чесно кажучи.

Добре. І «Ее», коли, коли ми, як?

Ми «Ее» запитали про це.

«Ее» – тема безпеки. «Ее», я думаю, є два, два, так, два типи людей.

Одні кажуть, що їм потрібні дозволи користувача, а інші кажуть, що їм потрібні дозволи програми.

Чи повинен агент генерувати, як взагалі повинен працювати агент? І «Ее», моя найкраща рекомендація – це, в основному, коли вам потрібно мати справу з агентським рішенням, завжди робіть «Ее», вибачте, у розділі «Делеговані дозволи користувача», тому що з точки зору безпеки, чесно кажучи, це краще, тому що користувач матиме доступ лише до даних та інструментів, до яких він має доступ. Це найголовніший принцип. Згодом, якщо вам потрібен дозвіл програми для конкретного «Я не знаю», конкретного «Арі», конкретного «Ее», контексту ви можете.

Але не «Ее», не використовуйте безпосередньо дозвіл програми «Ее», зробіть це «Ее» в контексті обгортки.

Отже, ви створюєте «Я не знаю», це може бути, можливо, MCP-сервер, наприклад, і інтегруєте цей MCP з дозволом програми залаштунками. Отже, MCP викликатиме, наприклад, «Я не знаю», ваш «Арі» залаштунками з дозволом програми, і після цього він надасть вам інформацію або «Ее» інформацію, яка вам потрібна, але користувач не має безпосереднього стосунку до дозволів програми.

Наприклад, ми викликаємо MCP-сервер з дозволом користувача, і MCP-сервер викликатиме закулісну програму або служби з дозволом на доступ до програми. Бачите різницю? Гаразд. Цікаво. Я думаю, що коли ми думаємо про архітектуру, ми також маємо «Ее», ми дивимося трохи глибше.

Я думаю, що в архітектурі є три великі теми.

У нас є генерація аргументів пошуку, у нас є тема знань і у нас є, я кажу, бекдор для корпоративного пошуку.

М. З чого почнемо зі стійки? Де стійка вписується в архітектуру. З точки зору «Ее» продуктивності, тому що ще повинен розуміти «Ее», різні типи даних, і, по суті, «Ее», «Арейджі» тут для того, щоб відповісти «Ее» на питання. Тому що в минулому, коли у вас не було «Арейджі», по суті, «Ее», вам потрібно було мати справу з іншим підходом «Ее». Ми не старої школи, але це було складно.

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

Але це правда, що багато користувачів, коли говорять про «Арейджі» за лаштунками, не знають, що це таке, тому що Microsoft сьогодні, чи багато інших «Ее», програмних компаній не говорять про це, тому що за лаштунками «Ее» є «Арейджі», Але, наприклад, у кого «Пайлот Стюдіо» користувач не розуміє, що відбувається за лаштунками, це «Арейджі» і «Ее», сьогодні, коли ви хочете зануритися глибше, у вас є така концепція, але для багатьох користувачів «Арейджі» взагалі не знає, що це таке, тому що вони просто використовують інструменти, і у них за лаштунками є ця концепція, а потім у нас є наступна тема «Це знання про те», як ми отримуємо ці знання, звідки системи штучного інтелекту отримали свої знання, чи це я збираю джоульборд, чи як це працює.

Насправді у вас є, ви повинні бути чесними.

Знання можуть бути розміщені в багатьох різних системах.

Це може бути звичайний текстовий файл, це може бути файл-маркдаун, це може бути база знань, це може бути що завгодно. Але насправді, якщо у вас є MCP-сервер, ви можете отримати доступ до цих знань. Або, наприклад, якщо у вас є конектор для точки спільного доступу, конектор для багатьох сервісів у наш час, тож доступ до знань став простішим, ніж раніше, будемо відвертими. Тому що в минулому вам потрібно було створити свій плагін і відвідати все. Сьогодні у вас є прямий конектор до будь-яких систем, ви можете інтегрувати свої знання, не маючи справу з великим ЕЕ, великим штатом розробників разом. Я, я думаю, часто ми, я не знаю, збираємо дані для мого, я кажу своєму, я не знаю, одному хлопцю. М і як.

Щі розуміє, що.

Є неготовими документами, або застарілими, або, я не знаю, дублюваними. Як, як, як, як зрозуміти це за допомогою системи ЩІ, що нам слід використовувати і що. М, в основному ЕЕ, ви використовуєте RAG, тому що за лаштунками вам потрібно розуміти добре ЕЕ, що є вашими даними.

Але ЕЕ, чесно кажучи, якщо я трохи підсумую, ЕЕ, ви починаєте з підказки ГАРАЗД. Користувач хоче ГАРАЗД, ви хочете, наприклад, шукати Я не знаю, в базі знань і, наприклад, на одному диску.

За лаштунками ЕЕ, коли, коли оркестратор за допомогою LM розуміє підказку та намір користувача, ЕЕ, за лаштунками ЕЕ, у вас є індекс по суті. Тому що, наприклад, у Копиот у вас є семантичний індекс, і цей семантичний індекс дає вам ЕЕ, по суті, ГАРАЗД, у мене є всі ці знання, і ви можете за допомогою запиту семантичного індексу ЕЕ, Штучний інтелект може безпосередньо запитувати семантичний індекс, щоб виконати ЕЕ, виконати RAG, наприклад, і ви можете безпосередньо, ГАРАЗД, вибрати потрібні документи на основі ЕЕ потреб. Але в Коупайлот у вас є цей семантичний індекс, і штучний інтелект може безпосередньо запитувати цей індекс ЕЕ за допомогою природної мови за лаштунками. Отже, я запитаю, добре, я хочу зрозуміти, ЕЕ, я не знаю, як ЕЕ, як налаштувати VPN моєї компанії. А за лаштунками ви виконаєте RAG над семантичним індексом і, по суті, отримаєте документ, який містить, наприклад, усі налаштування VPN-компанії.

Наприклад, у чаті Microsoft 365 Coopilot ЕЕ за лаштунками це граф АРІ, тому що, як я вже казав раніше, у вас є семантичний індекс, побудований на граф АРІ. Це функція граф позаду, але ЕЕ, коли у вас є індивідуальна розробка, у вас є, наприклад, Foundry AQ позаду. Це були служби Azure з іншою назвою. Але тепер ви можете мати власну стійкову систему, якщо хочете. І в основному ви можете ЕЕ, коли у вас є спеціальний агент, ви можете безпосередньо запитати це для екземпляра Foundry AQ. Добре, ЕЕ, я хочу використовувати ЕЕ, я хочу отримати налаштування ЕЕ, моєї компанії VPN і штучний інтелект може ЕЕ отримати те, що вам потрібно з точки зору документів. Це можуть бути PDF-файли, Word, Excel, щось таке.

І Ось так працює пошук, чи не так?

Або ЕЕ, за лаштунками, ви маєте на увазі. Так А за лаштунками? Так, у вас є пошук.

ЕЕ, але в основному зараз у вас є ЕЕ, за лаштунками ЕЕ, чату Co-Pilot, ЕЕ, Co-Pilot, у вас є три ЕЕ. Три можливості, у вас є стандартний пошук, який є, по суті, пошуком, який ви просто ЕЕ, вводите деякі ключові слова і ЕЕ, ви шукаєте у своїх документах тощо. Це простий пошук. Ми всі знаємо пошук за ключовими словами, як у Google. Після цього у вас є дві різні ЕЕ-можливості. Спочатку у вас є ганчірка за лаштунками. У вас є можливість ArrayG в граф, а також у вас є ЕЕ, пошук за семантичним індексом Co-Pilot, який трохи відрізняється, тому що ArrayG насправді більш просунутий, ніж пошук за семантичним індексом Co-Pilot.

Але у вас є всі ці три можливості за лаштунками, щоб зробити ваші ЕЕ. Це не ви, але за лаштунками ще може викликати ці три ЕЕ різні можливості, щоб отримати дані на одному диску Teams M365 загалом після. Він може включати також семантичний індекс Co-Pilot, що включає коннектори Co-Pilot. Наприклад, якщо у вас є підключений Salesforce до коннектора Co-Pilot, він також може шукати всі ваші дані в Salesforce, які зараз використовуються в кількох інструментах. Оскільки все це ЕЕ, за допомогою коннектора Co-Pilot ви інтегрували всі дані в граф, ЕЕ, індекс, семантичний індекс, ви можете безпосередньо запитувати ваші зовнішні системи. ГМІ Добре І ГМІ, я думаю, що Коли ми створюємо агентів, у нас є частина управління, і одна з частин також для мене, я кажу, управління життєвим циклом агента. Як це виглядає насправді?

ЕЕ, чесно кажучи, в екосистемі Microsoft це досить просто, якщо можна так сказати. Тому що, коли ви маєте справу з низьким кодом, наприклад, компілятор Studio, ви маєте справу з чотирма платформами, концепціями IEM і ЕЕ, нічого не змінилося. Отже, у вас є рішення, у вас є ELM, у вас є конвейер. Отже, коли ви маєте справу з Co-Pilot Studio, чесно кажучи, це як і раніше, тому що у вас є всі ті речі, в які ви інвестували з точки зору управління Pava Platform життєвого циклу ELM. Це абсолютно те саме. Е, це добре, тому що багато людей запитують мене о Competent Studio, як ви керуєте. Чи це відрізняється? Ні, це дуже просто, як PAPES або Co-Automate ЕЕ – управління життєвим циклом додатків. Отже, в цьому випадку це управління життєвим циклом агента, але за лаштунками та ж концепція ЕЕ, як у Co-Platform. А коли ви маєте справу ЕЕ, наприклад, з користувацькою розробкою, це в основному, як коли ви створюєте ЕЕ, додатки ЕЕ, мережеві додатки тощо, тому що ви керуєте всім, як кодом.

Отже, у вас є фреймворки, у вас є аспект безпеки, такі речі. Тож, чесно кажучи, все ЕЕ з точки зору управління додатками життям агентів – це дійсно та ж концепція, що й раніше. І це гарний момент для мене, тому що вам не потрібно багато інвестувати ЕЕ з точки зору ЕЕ процесу життєвого циклу таких речей. Але єдині, що у вас є деякі зміни, ЕЕ – одна з великих змін полягає в тому, що, гаразд, вам потрібно подбати про ЛЛМ, такі речі, розгортання, такі речі. Але за лаштунками, схоже, що в минулому підхід DevOps з конвейером – такі речі. Тож, на мою думку, нічого не змінилося, тому що ми керуємо агентом ЕЕ. Це може бути розробка на замовлення або впоратися, ви з тим самим підходом, що й раніше, чесно кажучи, сьогодні. І Це означає, що коли компанія не використовує ЩІ раніше, але у них є ідеальне налаштування для перевірки для захисника та всі інші інструменти, чи є якісь зміни, які потрібно зробити, чи це означає готовність до ЩІ?

Це велике питання, тому що готовність до ЩІ ЕЕ для Microsoft ЕЕ є нормальною. ЕЕ, ЕЕ, ви загострюєте комісію, керуєте такими речами, але ЕЕ, добре, готовність для мене – це не лише технічний підхід, тому що добре, технічно, ми знаємо, що робити. Добре, нам потрібно керувати дозволами для багатьох сервісів, розумієте? Для мене готовність ЩІ повинна також включати ЕЕ, дані, дані, розумієте? Тому що ЕЕ, коли ви не розумієте свої дані, як я вже казав, ЕЕ, ви не можете ЕЕ взяти, ви не можете керувати технічною частиною, тому що ЕЕ, коли ви не знаєте, що є конфіденційним, а що ні, наприклад, ЕЕ, важко запровадити деякі. Деякі засоби безпеки. Але якщо ми, якщо ми наслідуємо Microsoft, готовність ЩІ – це нормально, ви керуєте дозволами, ви хочете встановити мітки конфіденційності, ЕЕ, ви повинні зробити GLP, ЕЕ, такі речі.

Але у вас також є більш високий рівень ЕЕ, високий рівень ЕЕ, аспект, і для мене готовність ЩІ – це не лише технічний, ви також маєте. Функціональний або високорівневий аспект, який слід враховувати, чесно кажучи, сьогодні.

Хмі – так, це справді цікаво. Я думаю, що багато компаній почали це зі штучного інтелекту, але тепер, коли агенти почали використовувати цей метод, багато компаній кажуть «О, вони видалили всі мої, я не знаю, електронні листи чи щось таке, зле-зле».

Як ви подумали, що компанії скажуть, що бояться штучного інтелекту?

Це гарне питання, тому що я живу у Швейцарії, і в основному у нас багато приватних банків, і в нас багато, чесно кажучи, дуже чутливих клієнтів, якщо чесно, і ЕЕ, і, в основному, найважливіше, де обробляються дані. І ЕЕ, так, також, чи шукає штучний інтелект мої електронні листи. І таке інше.

Отже, за лаштумками вони завжди запитують про це, але, знаєте, найважливіше для них, гаразд, мені потрібно зрозуміти, де обробляються дані і ЕЕ, а також гаразд, ЕЕ, я. Власник ШІ. Тож, я даю інструкцію ШІ, і ШІ за лаштумками виконує роботу, і вони бояться, наприклад, автономного ЕЕ аспекту, тому що в наш час гаразд, ви можете гаразд зробити це, і за лаштумками ШІ шукатиме щось, ЕЕ запитуватиме щось за лаштумками, і вони бояться гаразд ЕЕ, коли я прошу щось зробити, що виконується за лаштумками. І ЕЕ, так, є багато таких запитань. Гаразд.

Як мені взяти під контроль весь процес, це може бути агент ШІ чи служба ШІ.

Так, є деякі ЕЕ, подібні питання, але це справді питання впровадження, а також навчання ЕЕ, щоб запровадити певне ЕЕ, певне навчання про те, як зрозуміти ШІ, як зрозуміти, що саме виконується за лаштумками ЕЕ. І прозорість також є важливим моментом ЕЕ, тому що прозорість має бути ЕЕ, запроваджена в кожному рішенні ЩІ, тому що прозорість для мене є важливою темою, тому що вам потрібно ЕЕ запровадити все, тому що ваше рішення ЩІ має бути прозорим. Вам потрібно розуміти, що виконується за лаштумками ЕЕ, які дані запитуються ЕЕ, вам потрібно відстежувати, вам потрібно все реєструвати. Тож усе має бути прозорим, коли у вас є рішення сьогодні, тому що вам потрібно точно розуміти ЕЕ, що виконується за лаштунками, і ЕЕ, які дані обробляються, і ЕЕ, яка причина цього. Добре. Як ви, ЕЕ, створили цей план на основі яких фактів і подібних речей? Чудово. О, я бачу, у нас трохи обмаль часу. Тож, так, вибачте.

Знаєте, це було справді чудово. Але в кожному моєму ЕЕ в подкасті є швидкий раунд. Отже, ЕЕ. Тож, ЕЕ, я даю коротке речення, а ви даєте коротку відповідь. ЕЕ, ви готові? Так. Co-Pilot Studio чи Custom Code? Co-Pilot Studio. ЕЕ, Microsoft Foundry чи Co-Pilot Studio? Co-Pilot Studio. ЕЕ, TypeScript чи Cypresscript?

Дітхаб чи Azure DevOps? Дітхаб. ЕЕ, Rec чи FineTuning? Добре. Який найбільш недооцінений АРІ-Майкрософт? ЕЕ, 365.

Рег-рег АРІ. Одна з технологій, яку кожен розробник Майкрософт повинен вивчити у 2026 році. Дітхаб Co-Pilot.

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

Всі необхідні управлінські речі і... Кого мені запросити далі на подкаст і яке питання мені поставити?

О, гарне питання. У мене багато друзів, але ЕЕ, так, можливо, ви можете попросити мене. У мене є співдоповідач на багатьох конференціях. Ви можете запитати, наприклад, Хлої Моро. Вона була функціональним консультантом, перш ніж зараз займатися технічною стороною. І в неї є дуже гарна історія про функціональні, менш технічні речі у світі динаміки.

Тож, можливо, ви можете запросити її та запитати, як сьогодні поєднувати функціональну та технічну роботу, бо тут є деякі, хмій, великі, великі виклики.

Так, і моє, моє, моє заключне запитання, чого повинні люди, коли вони можуть навчитися на цьому занятті, що вони повинні взяти.

З нього ви маєте на увазі.

Хмій, в основному, ще швидко розвивається.

І якщо ви хочете бути в курсі сучасних подій Хмій, вам потрібно стежити за всім, тому що сьогодні ще дійсно поширюється на всі податки Microsoft, якщо чесно. І сьогодні одна з речей, яку вам потрібно зрозуміти, це те, що еволюція відбувається швидко, і вам потрібно бути в курсі подій ЕЕ, справді, справді, ЕЕ, у будь-який час, тому що ЕЕ, ви щось пропустите в якийсь момент, якщо ви ЕЕ, якщо ви не навчитися, якщо ви не зрозумієте еволюцію в цьому виді. Так, так, так, ЕЕ, дякую, що приєдналися до мене, я думаю.

Важливий висновок з цієї розмови полягає в тому, що розширюваність Microsoft C65 Co-Pilot полягає не просто в написанні дедалі складніших підказок. ЕЕ, я думаю, що ми рухаємося до архітектури, де Co-Pilot та агенти можуть поєднувати знання організації, бізнес-додатки Microsoft, Graph, AP тощо. ЕЕ, так, я думаю, що Co-Pad Studio, Microsoft Foundry, розробка на замовлення та такі технології, як MCP, дають ЕЕ розробникам, так. ЕЕ і так, але чим більш ЕЕ, так, спроможними стають агенти, тим важливішими стають також фундаментальні аспекти ідентифікація, дозволи, безпека, управління, тестування, спостережуваність ЕЕ, управління життєвим циклом, застосунків тощо. Тож так, я думаю, що ви дали справді ЕЕ хороший огляд усіх цих тем. Тож дякую, що приєдналися до мене і слухачам за всю інформацію, яку ви знайдете в нотатках до шоу на сторінці подкасту MC65FM і ЕЕ, так, де ви можете приєднатися, щоб побачити роботу ЕЕС, і так, дякую, що були тут.

Дякую, що запросили мене. Було дуже добре проведено час з вами. Дякую.