Witamy wszystkich w podcaście Mac65FM. Dzisiaj wykraczamy poza jedną z najczęstszych rozmów na temat inżynierii promptów w Microsoft 365 Copilot, ponieważ gdy organizacje zaczynają poważnie korzystać z Copilota, pytanie szybko zmienia się z jak pisać lepsze prompti,

na jak połączyć Copilota z aplikacjami, danymi, procesami biznesowymi i wiedzą, które faktycznie funkcjonują w naszej firmie. I właśnie tutaj rozszerzalność Copilota staje się interesująca. Moim gościem jest dziś Ewa z Harvest, Microsoft MVP, konsultant do spraw aplikacji biznesowych, a i World Group w Szwajcarii. Ewa spracuje z Microsoft 365, Azure, Dynamics 365 oraz Power Platform, koncentrując się na rozszerzaniu możliwości Microsoft 365 Copilot poprzez agentów i własne rozwiązania. Zgłębimy temat rozszerzalności Microsoft 365 Copilot, Copilot Studio, Microsoft Azure, a i Foundry, nie wiem, ciągle zmieniają nazwę Microsoft Graph, własne rozwiązania, MCPS i tak dalej. Więc Ewa z witaj w podcaście MC65. Cześć wszystkim, dzięki za zaproszenie. To naprawdę dobra okazja, żeby tu być. Więc dzięki, że mnie gościcie. Tak, dziękuję. Zanim przejdziemy do technicznych kwestii, czy możesz opowiedzieć trochę o swojej ścieżce, jak trafiłeś do ekosystemu Microsoft?

Jasne, tak, tak. Oczywiście, bo szczerze mówiąc, nie zaczynałem kariery w świecie Microsoft. Zacząłem ją w świecie Apple. Byłem inżynierem oprogramowania na platformę Mac, a później przeszedłem do iOS i tym podobnych rzeczy. Było to dawno temu, może z 15 czy 20 lat temu, kiedy przeszedłem do świata Microsoft.

Szczerze mówiąc, zaczynałem od SharePointa.

A potem przeniosłem się do chmury Azure i M365.

Zaczynałem od SharePointa on-premises, a potem przeszedłem do wszystkich usług w chmurze, na końcu do Power Platform, a ostatnio do wszystkich rzeczy związanych z AI. Szczerze mówiąc, bo to teraz ważna część M365, mamy teraz przejście w stronę agentów i w skrócie, tak wygląda moja zawodowa podróż.

Ale karierę zaczynałem w świecie inżynierii oprogramowania, co dziś jest może terminem, o którym wielu zapomina, bo mamy teraz całą tę sztuczną inteligencję i w zasadzie tego typu aktywności czy stanowiska przeniosły się do AI, więc to zupełnie co innego niż 20 lat temu. Tak, mówisz, że pracujesz z SharePointem, widzę też, że z Graf, technologiami dynamicznymi, Power Platform.

Jak to doświadczenie przygotowało Cię na obecną generację rozwoju AI?

Cóż, w zasadzie mój profil jest naprawdę przekrojowy, ponieważ w trakcie swojej kariery pracowałem z wieloma różnymi produktami.

Mogły to być produkty Microsoftu, jak i te spoza jego ekosystemu, więc zasadniczo mam szeroki wachlarz umiejętności w wielu różnych technologiach i narzędziach. Wszystkie moje poprzednie prace dały mi solidne podstawy, bo teraz AI to bardzo szeroki temat, ponieważ istnieje wiele różnych podejść i technologii do pracy z AI.

Może to być podejście agentowe, bardziej oparte na przepływach pracy czy tego typu rzeczach, więc szczerze mówiąc, wszystkie moje poprzednie zajęcia dały mi wiele umiejętności, dzięki którym jestem gotowy na tę transformację AI. Przechodziłem przez narzędzia typu low-code aż po te w pełni programistyczne, więc tak wszystkie te możliwości i aktywności w moich dotychczasowych pracach dały mi dobre umiejętności, by szczerze mówiąc, czerpać z tego korzyści w świecie AI. Tak, a teraz jesteś liderem testów AI. Czym zajmuje się lider testów AI? Uch! To bardzo dobre pytanie, bo wiele osób mnie o to pyta.

Moim zadaniem jest dopasowanie specyfikacji funkcjonalnej do stosu technicznego.

Przejmuję stery, gdy analiza biznesowa jest już gotowa.

Zdefiniowaliśmy przypadki użycia dla rozwiązań AI. Określiliśmy scenariusze i przypadki użycia. Mamy za sobą pełną analizę biznesową, a moją rolą jest wzięcie tych potrzeb i dopasowanie ich do stosu technologicznego działającego w tle.

A potem kieruję całą implementacją narzędzi i rozwiązań, kiedy jesteśmy już gotowi, by rozpocząć programowanie.

Ciekawe, w zasadzie wiele firm kupuje swoim pracownikom szkolenia, szczególnie z prompt engineeringu, dlaczego więc uważasz, że to nie wystarcza?

Masz na myśli tylko inżynierię promptów obecnie? Tak, tak. Czemu, czemu, czemu, czemu oni?

Czemu to tylko, wiesz, czemu dla firm, uch, nie, nie wystarcza tylko nauczenie ludzi, no, inżynierii promptów? Ach, tak, rozumiem. Widzę, rozumiem.

Ok, tak, tak, uch, w zasadzie, szczerze mówiąc, obecnie masz, tak jak mówiłem wcześniej, masz wiele różnych narzędzi i technologii, więc w pewnym momencie, a i może zrozumieć, co robić i może, uch, trochę cię poprowadzić. Ale dla mnie, uch, rola na przykład architekta czy projektanta oprogramowania, uch, wymaga człowieka za kulisami, ponieważ musisz zrozumieć klienta.

W zasadzie, a i czasem nie potrafi zrozumieć kontekstu klienta. Uch, widzisz tam pełny obraz, ale za kulisami, uch, samo skupienie się na inżynierii promptów może być dobre w pewnym momencie, ale potrzebujesz więcej, bo musisz mieć za kulisami, uch, ludzi, którzy są, uch, architektami, inżynierami oprogramowania za kulisami i w zasadzie mnóstwo ludzi, którzy mają umiejętności w technologiach, uch, technologiach informatycznych takich jak SharePoint, jak OnDrive, jak nie wiem, albo Salesforce, tego typu rzeczy. Musisz mieć specjalistów w tych technologiach, ponieważ a i może zrozumieć wiele rzeczy. Może uch może Cię poprowadzić. Może wygenerować świetne dokumenty techniczne lub funkcjonalne, ale potrzebujesz ludzi za kulisami, którzy zadbają o to, czy to jest dobre. Czy to uch odpowiada na potrzeby klienta i tego typu rzeczy, rozumiesz, by wszystko zweryfikować, a skupienie się tylko na inżynierii promptów?

Dla mnie teraz to, tak, to może być, może być opcja, jeśli nie masz, uch, czasu, by, by, by trenować lub zainwestować, uch, w, uch, w, uch, w zdobywanie jakichś, jakichś umiejętności. Ale dla mnie musisz mieć, uch, dobre umiejętności w podstawowych technologiach, w których chcesz budować swoje rozwiązania, szczerze mówiąc. Tak, tak. A jesteś ekspertem w rozszerzalności kopilota.

Gdzie, um, standardowy kopilot w Microsoft 365 się kończy, a gdzie zaczyna się rozszerzalność kopilota? Ha, tak, to dobre pytanie, bo szczerze mówiąc, dwa lata temu, kiedy, kiedy kopilot, uch, został wydany i, uch, może pierwsza wersja, uch, w zasadzie czad był, szczerze mówiąc, naprawdę bardzo minimalistyczny.

W zasadzie można powiedzieć, dobra, przypominało to Shapt, ale Microsoft bardzo rozwinął Microsoft 365 Kopilot.

Teraz mamy dostęp do różnych funkcji, więc możliwości rozszerzeń są inne niż wcześniej. Kiedyś tworzyło się wtyczki i tym podobne rzeczy, ale dzisiaj, szczerze mówiąc, rozszerzalność oznacza sytuację, w której chcesz coś zbudować i dostosować samą orkiestrację lub bardziej spersonalizować interfejs użytkownika.

Jeśli na przykład chcesz zintegrować swojego agenta nie tylko z czatem Microsoft 365, ale też z własną stroną internetową, to rozszerzalność zaczyna się tam, gdzie chcesz wprowadzić więcej modyfikacji za kulisami. Może chodzić o orkiestrator, o własny interfejs lub o inne aspekty, których sam czad Kopilot nie jest w stanie obsłużyć lub na które nie potrafi odpowiedzieć.

I, i.

Myślę, że wiele osób mówi teraz o agentach. Um, czy.

Dlaczego, dlaczego tak wiele myślimy teraz o agentach Kopilot i dlaczego nie budujemy, nie wiem, jednego wielkiego Kopilota do wszystkiego? Tak, to naprawdę interesujące, bo szczerze mówiąc, tak jak wspomniałem, Microsoft bardzo się rozwinął.

Gdybyśmy cofnęli się o 6 miesięcy, agenci byli głównym tematem.

Teraz Microsoft wprowadził Kopilot i szczerze mówiąc, obecnie Kopilot może zastąpić wielu agentów. A kiedy myślimy o agentach, to tylko po to, by rozdzielić zadania, ponieważ jesteśmy teraz w modelu wieloagentowym, gdzie każdy agent ma swój zakres i swoje obowiązki.

A nie tworzymy jednego wielkiego Kopilota, w zasadzie po prostu ze względu na wydajność. Po pierwsze dlatego, że kiedy masz ogromny zestaw instrukcji i narzędzi, pod kątem wydajności powstanie z tego chaos. Architektura jest teraz bardziej wieloagentowa, może być oparta na Kopilot Studio lub na niestandardowych agentach stworzonych za pomocą własnego kodu.

Jednak obecnie lepiej jest przyjąć podejście wieloagentowe, gdzie każdy agent ma swój zakres i odpowiedzialność pod kątem wydajności oraz jasnej architektury agentów.

Tak, Schopenhauer.

Kiedy przyglądamy się podstawowej architekturze agenta AI, to powiedziałbym.

Jakieś hasła. My, my hasła. Dobrze. Musimy jednak pomyśleć o wnioskowaniu, narzędziach, wiedzy i instrukcjach.

Jak to pasuje do architektury agenta AI?

Pierwszą rzeczą, a właściwie jednym z pierwszych pytań, na które trzeba odpowiedzieć, jest jaki jest cel?

Pierwszy cel tego agenta.

Zasadniczo architektura agenta zależy od tego, czy korzystasz z podejścia low-code, czy z własnego programowania, ponieważ te podejścia są zupełnie inne. W przypadku własnego programowania zarządzasz wszystkim.

Zarządzasz więc bezpieczeństwem, hostingiem oraz wieloma innymi różnymi rzeczami. W podejściu low-code wygląda to inaczej, ponieważ zastanawiasz się nad instrukcjami i wybierasz odpowiednie narzędzia. W zasadzie architektura w low-code nie jest tak prosta, jak przed chwilą powiedziałem, ale może być bardzo szybka, bo definiujesz instrukcję, wybierasz narzędzia i możesz połączyć innych agentów, jeśli chcesz.

Jest to jednak naprawdę proste, kiedy masz do czynienia z własnym kodem lub gdy tworzysz własnego agenta. Mogą to być np. semantic kernel, agent framework, czy tym podobne rzeczy. Architektura może być znacznie bardziej złożona, ponieważ musisz mierzyć się z bardzo zaawansowanymi koncepcjami, jak wspomniane bezpieczeństwo. Mym Pod kątem uwierzytelniania, jeśli masz wiele narzędzi i chcesz zintegrować jakieś API lub połączyć się z narzędziami wewnętrznymi chronionymi przez serwery proxy, czy tym podobne.

Więc zasadniczo musisz więcej rozmyślać o architekturze, gdy zajmujesz się niestandardowymi agentami, np. w Copilot Studio.

Jeśli chodzi o architekturę, to w podejściu custom dev zdefiniowanie jej bywa bardzo szybkie. Musisz jednak zmierzyć się z zaawansowanymi koncepcjami i dla wielu osób może to być trudne, ponieważ są to bardzo podstawowe kwestie. I uch, szczerze mówiąc, w mojej pracy mam do czynienia z wieloma różnymi potrzebami. Może to być własne rozwiązanie, Copilot Studio albo prosty agent stworzony w Agent Builderze do podstawowych zadań.

Definiowanie architektury zależy więc przede wszystkim od podejścia, które chcesz przyjąć. Zasadniczo istnieje pewna ogólna architektura, ale wszystko zależy od tego, czy wybierzesz podejście Low Code, czy pełne programowanie.

Tak, tak, chm, ale czy moglibyśmy?

Czy możesz opisać anatomię typowego korporacyjnego agenta AI?

Tak, oczywiście.

Mówiąc najprościej, gdy pojawia się potrzeba, np. agenta wsparcia IT, masz zazwyczaj określony zestaw zadań. Obecnie jednak, jak wspomniałem, stosujemy podejście wieloagentowe, w którym pierwszy agent pełni rolę front-endu.

To jest agent główny, który kieruje wszystkie zapytania do odpowiednich agentów.

Jeśli użytkownik pyta np. o Salesforce, agent przekieruje to zapytanie do agenta wsparcia IT do spraw.

Salesforce Dla niektórych klientów stworzyliśmy właśnie taką architekturę, ponieważ każdy agent odpowiada za swój zakres zadań. Może to dotyczyć produktów takich jak Salesforce, może to być M365, czy inne tego typu rzeczy. W tle każdy agent posiada zestaw instrukcji i narzędzi.

Obecnie najlepiej korzystać z serwerów MCP, ponieważ są one uniwersalnym standardem integracji wielu usług z AI. Mam więc zestaw serwerów MCP oraz wewnętrzne źródła wiedzy.

Może to być IRA, baza wiedzy ServiceNow, czy tym podobne. Dla każdego agenta tworzysz zestaw instrukcji.

Te instrukcje określają zakres działania i rolę agenta, a do tego dochodzą serwery MCP i źródła wiedzy, jak np. pliki PDF. Może to być wiele różnych rodzajów źródeł danych.

A potem, przepraszam, kiedy użytkownik wysyła zapytanie, np. do głównego agenta, po wszystkim określi on, dobrze, muszę przekazać to zadanie odpowiedniemu agentowi.

Przyjrzyjmy się nieco bliżej możliwościom lub temu, jak Copilot Studio wpisuje się w ogólną architekturę.

Szczerze mówiąc, Copilot Studio to narzędzie typu low-code od firmy Microsoft. Po pierwsze, pod kątem architektury Copilot Studio jest rzeczywiście stworzone dla twórców, w zasadzie dla osób, które nie są przede wszystkim programistami.

A jeśli chodzi o architekturę, to biorąc pod uwagę wspomniany wcześniej przykład wsparcia IT, Copilot Studio będzie pasować, ponieważ pod względem architektury spełni swoje zadanie, można w nim zdefiniować serwer, łatwo zintegrować zewnętrzne lub wewnętrzne źródła wiedzy, jeśli zajdzie taka potrzeba. Dalej, tak jak mówiłem, jeśli masz przypadek użycia, w którym chcesz nieco dostosować orkiestrator, to w Copilot Studio nie da się tego zrobić od zaplecza, po prostu aktywujesz orkiestrator AI i to wszystko.

Nie możesz na przykład dostosować priorytetu zadania, które chcesz wykonać, ponieważ Copilot Studio automatycznie definiuje twój plan i następnie go realizuje. Jeśli jednak potrzebujesz większej możliwości personalizacji, musisz użyć własnego rozwiązania programistycznego, na przykład z Semantic Kernel czy Langchain lub ostatnio wydanego przez Microsoft Frameworka.

Dzięki temu możesz łatwo dostosować orkiestrację, zdefiniować przepływy pracy i dostosować niemal wszystko, co chcesz.

Copilot Studio jako architektura jest naprawdę stworzone dla budowniczych i twórców, ponieważ uruchomienie działającego agenta jest bardzo proste.

Jedyny problem z Copilot Studio, o który musisz zadbać, to licencjonowanie, ponieważ gdy wybierasz swoją ścieżkę i definiujesz architekturę, jest to teraz istotna część każdego rozwiązania.

Obecnie Copilot Studio nieco ewoluował w stronę modelu płatności za użycie i trzeba dbać o szacowanie kosztów, ponieważ w zależności od celu czasami lepiej jest postawić na własne rozwiązanie, bo wtedy hostujesz to, gdzie chcesz, panujesz nad wszystkimi kosztami i łatwiej je oszacować niż teraz.

Ponieważ przy podejściu opartym na kredytach Copilot czasami trudno jest przewidzieć, ile to będzie kosztować przez miesiąc, dwa miesiące i tego typu rzeczy.

I jakie, jakie, jakie są ograniczenia Copilot Studio?

Studio, uch, kiedy mam wybrać, wtedy myślę um, uch, tak Microsoft Foundry, Azure Foundry, nie wiem jaka jest tak naprawdę ta nazwa um i kiedy uch muszę powiedzieć ok, um muszę zrobić całkowicie własną aplikację.

Uch, pierwsze pytanie, na które?

Należy odpowiedzieć, to ok, czy muszę dostosować uch? Orkiestracje To dla mnie pierwsze pytanie, ponieważ ono odpowie Ci ok, jeśli nie chcesz dostosowywać orkiestracji, zagłębiać się w to, jak cała orkiestra jest tworzona lub jak generowany jest plan, możesz użyć podejścia Low Code z Copilot Studio, uch na przykład kreatora.

Również czasami, gdy masz prosty przypadek użycia, możesz użyć tego typu narzędzi. Ale jeśli chcesz dostosować orkiestrację ok, musisz przejść do specyficznego programowania i w tym przypadku musisz ok, musisz użyć Foundry dla modelu lub jeśli masz własną platformę, ponieważ zaletą własnego rozwiązania jest to, że uch, możesz integrować modele, które nie są hostowain w Microsoft Foundry.

Jeśli chcesz, możesz używać modeli Foundry, ale jeśli masz też AWS lub Google, uch, platformę Google, platformę Google, przepraszam, uch i masz powiedzmy Gemini lub wdrożyłeś model zewnętrznie, masz możliwość bezpośredniego zintegrowania tych modeli w swoim agencie, gdy używasz własnego podejścia.

To jest również zaleta, uch i później możesz dostosować orkiestrację, to jak generowany jest plan, wszystkie te rzeczy trafią do agenta Foundry.

Problemem Foundry jest obecnie to, że na początku Foundry było tylko platformą hostingową dla modeli. Kiedy spojrzysz wstecz na kilka lat, wyglądało to jak prosty katalog modeli, który wdrażasz.

Obecnie Microsoft rozwinął ten produkt tak, że można tworzyć agentów w interfejsie typu Copilot Studio, w zasadzie bez pisania kodu.

Możesz zarządzać ładem korporacyjnym i wieloma innymi rzeczami. Stało się to prawdziwą platformą agentową, podobną do Copilot Studio dla rozwiązań low-code i tym podobnych.

Obecnie bardzo trudno jest umiejscowić Foundry w całym ekosystemie, ponieważ Foundry rozwija się bardzo szybko.

W zasadzie Microsoft wprowadził pewne funkcje, które są bardzo, nie wiem, może nie inne, ale podobne do Copilot Studio pod względem integracji z MCP i tym podobnych.

Jednak głównym ograniczeniem Copilot Studio są modele. Masz możliwość integracji kodu czy wizualizacji różnych rzeczy. Ale jeśli chcesz zintegrować na przykład własny model, bo masz jego specyficzną wersję, to nie możesz tego zrobić i w zasadzie musisz użyć niestandardowych rozwiązań, aby podłączyć własną platformę LLM, jeśli taką posiadasz.

Mam klienta, który korzysta z własnej platformy AWS. W tym przypadku można zintegrować ten model z zewnętrznie zarządzanym cennikiem.

Rozumiem. Dobrze. Myślę, że kiedy budujemy agenta, jednym z tematów jest też cała ta otoczka.

Tak.

Schopenhauer.

Większość ludzi mówi o MCP, czyli model kontekst protokol. Dlaczego stało się to jednym z najważniejszych tematów w rozwoju agentów i dla kogoś, kto jeszcze z tym nie pracował, czym właściwie jest model kontekst protokol?

Tak, to wielkie słowo. W zasadzie wiele osób o tym mówi, ponieważ rozwiązuje to poważny problem.

Chodzi o to, jak ujednolicić integrację narzędzi, umiejętności, czy też zewnętrznego oprzyrządowania z AI, co rozwiązuje problem z przeszłości, gdy bez MCP panował bałagan, bo wiele usług komunikowało się w różny sposób.

Mamy różne protokoły technologiczne, różne podejścia do architektury, a w zasadzie MCP ujednolica sposób integracji usług z Twoim agentem, AI czy rozwiązaniem, a i jeśli mam być bardziej ogólny, ale MCP to teraz naprawdę sposób na łączenie zewnętrznych lub wewnętrznych narzędzi może być jedno i drugie.

Ale MCP jest teraz dużą częścią architektury, ponieważ zapewnia tę jednolitość w wymiarze technologicznym. I obecnie jest to bardzo istotny punkt. Ponieważ kiedyś była to integracja przez API, a teraz jest to MCP. Mym To nie jest EE, to nie jest ewolucja, ale w przeszłości integrowało się agenta z API. Musiałeś zarządzać, dobra, jak się uwierzytelnić, jak tym zarządzać, albo jak wywołać narzędzie. Teraz AI potrafi, okej, mam dostępne to narzędzie, mogę wybrać to, czego potrzebuję, by osiągnąć cel. A co, co, co tak naprawdę zmieniło się w przejściu z MCP do połączenia API? W zasadzie w przeszłości, w kwestii integracji, API nie były inteligentne, jeśli mogę tak powiedzieć, EE, API po prostu, okej, wywołujesz, wywołujesz, wywołujesz narzędzie, a ono daje Ci dane.

Różnica przy MCP polega na tym, że MCP jest bardziej inteligentne pod względem architektury, ponieważ za kulisami masz nie tylko narzędzia, które dają dane czy informacje, ale masz też umiejętności i instrukcje, EE i różne inne rzeczy, które czynią MCP naprawdę inteligentnym.

I w zasadzie MCP może przekazać AI, okej, chcesz to osiągnąć?

Mogę dać Ci EE, dokładne narzędzia, które pasują do Twojego zapytania i możesz wywołać nie tylko jedno narzędzie, ale musisz wywołać te narzędzia, aby osiągnąć to, czego chcesz. To jest rola MCP. Daję AI znać, okej. Mam te narzędzia i możesz teraz wywołać to lub tamto albo wiele narzędzi, aby osiągnąć swoje cele.

Daję to, daję to, daję AI kontekst, prawdziwy kontekst wszystkiego, podczas gdy API to tylko okej, masz narzędzia, masz opis i to w zasadzie wszystko.

Więc czy to, czy to jest model kontekst protokol, myślę, że podobne do metadanych, czy jak to działa?

EE nie. MCP za kulisami EE to po prostu EE, to protokół.

W zasadzie to technologia protokołu, a za kulisami masz, masz tak, masz metadane, masz opisy EE, masz umiejętności AI, które opisują więcej EE, to naprawdę skupione na AI. W zasadzie masz umiejętności, masz instrukcję i AI może lepiej zrozumieć, okej, te narzędzia EE robią to, to narzędzie robi tamto, okej, mogę wywołać te umiejętności, mogę poprosić EE o te informacje serwer MCP, aby osiągnąć moje zadanie.

Ale masz, tak masz, pewną część metadanych, ponieważ musisz zdefiniować, okej, nazwę narzędzia i co robi za kulisami.

Spójrz, czy możemy powiedzieć, że przyszłością jest MCP? Więc musimy zacząć myśleć o tym, nie wiem, firmy mają setki API REST wewnątrz organizacji, czy powinny zacząć budować wokół nich serwery MCP? Tak, tak, zasadniczo serwer MCP pracuje z API za kulisami. To nie jest zamiennik w zasadzie. Jeśli, jeśli miałbym to podsumować, to serwer MCP jest po prostu okej. Daję kontekst, a za kulisami MCP może wywoływać API. Za kulisami, ale serwer MCP to frontend, to narzędzie, które musisz wywołać, bo za kulisami rozdzielasz swoje żądania. Za kulisami może być API, baza danych lub wiele narzędzi, ale jeśli chcesz mieć własny serwer MCP, na przykład jeśli masz wewnętrznie w firmie API i różne rodzaje usług, może to być dział finansowy lub HR, musisz obsłużyć za kulisami wszystkie te API, a serwer MCP będzie musiał je udostępnić, jakie są usługi, jakie narzędzia są dostępne, jakie są umiejętności i tego typu rzeczy.

PEM Następnie musisz zająć się uwierzytelnianiem za kulisami, ponieważ API nie działają tak samo, możesz mieć uwierzytelnianie przez klucz lub tego typu rzeczy.

Więc musisz się tym zająć, ale MCP udostępni dostępne narzędzia, a za kulisami wszystkie te narzędzia mogą odpytywać wiele API. Jedno API mogą być różne rodzaje architektury za kulisami. OK.

A jak MCP? Wybiera właściwe narzędzie, gdy mam, nie wiem, 100 czy 500 agentów AI.

Cóż, będzie to oparte na kilku pierwszych rzeczach. Zasadniczo, kiedy masz żądanie w agencie, odkrywasz wszystkie dostępne narzędzia. Serwer MCP sprawdzi OK, mam te wszystkie narzędzia do dyspozycji.

I w zasadzie uch, orkiestrator agenta zrozumie, dobrze, mam to, mam dostępny model LLM.

Następnie utworzysz plan. Jeśli mogę to podsumować, tworzysz plan z określonymi działaniami, a następnie, w ramach tego działania, które chcesz wykonać, możesz wywołać jedno, dwa, trzy lub więcej narzędzi, aby osiągnąć zadanie, o które poprosił użytkownik.

Więc zasadniczo, orkiestrator agenta zrozumie narzędzia MCP i wybierze najlepsze dla danego zapytania. Widzisz.

I to jest właśnie rola orkiestratora, wybieranie narzędzi i tym podobnych rzeczy, oczywiście z pomocą modelu LLM, ponieważ LLM jest częścią mózgu, a orkiestrator będzie komunikował się z LLM oraz z narzędziami, aby dokonać najlepszego wyboru i stworzyć najlepszy plan realizacji zadania.

Tak, myślę, że przez pewien czas wiele firm zaczynało od PowerShell, a teraz korzystają z interfejsu Microsoft Graph API.

Czy Graph i MCP jakoś się łączą, czy jak to, kropka, tak, myślę, że szczerze mówiąc, nie, nie ma żadnego MCP dla Graph. Jeśli tak to nazwiesz, wiesz, masz teraz w świecie Microsoft 365 sytuację, w której Microsoft wprowadził wiele serwerów MCP, a te serwery MCP opierają się za kulisami na Microsoft Graph.

Więc na przykład, jeśli chcesz użyć, nie wiem, serwera MCP dla Teams, to za kulisami wywoływany jest Graph API, gdy korzystasz z tego serwera MCP.

Więc Graph API w świecie Microsoft 365 jest kluczowe, ponieważ za kulisami MCP komunikuje się z Graph, aby zapytanie działało poprawnie.

Ale tak, obecnie Graph jest kluczowy także dla Copilota w ogóle, ponieważ indeks semantyczny Copilota opiera się na surowych danych, ale właściwie korzystasz z Graph za pośrednictwem serwerów MCP.

Obecnie tak właśnie jest.

Microsoft 365 zawiera niesamowitą wartość konteksty organizacyjne, dokumenty, spotkania i maile ludzi, zespoły, konwersacje i powiedziałbym udostępnione treści.

Jak udostępnić ten kontekst? Nie, kropka tak. Tworząc przy tym koszmar związany z bezpieczeństwem? Masz na myśli kwestie ładu, governance i tego typu rzeczy?

Tak, to zawsze jest problem, ponieważ wiele osób tworzy agentów, nie zapewniając odpowiedniego ładu za kulisami. Chcę więc zbudować agenta. Dobrze, zaczynajmy. Budujemy, wdrażamy, a potem, och, ten agent będzie przetwarzał mnóstwo danych. Jak tym zarządzać? Pierwsze pytanie brzmi, jak wprowadzić ład dla agentów? Bo wcześniej, tak jak mówiłeś, może zapanować chaos.

Wiele osób chce budować agentów lub rozwiązania, ale w środowisku Microsoft 365 jedną z pierwszych rzeczy do zrobienia jest zrozumienie swoich danych. Bez zrozumienia danych jesteś zagubiony. Musisz zrozumieć swoje dane, bo ważne jest, czy masz do czynienia z danymi poufnymi, czy nie. Czy mam do czynienia z danymi ściśle tajnymi? Zrozumiano. Musisz rozumieć swoje dane.

Jeśli działasz w środowisku Microsoft, musisz wdrożyć funkcje DLP, etykiety wrażliwości i tym podobne, bo bez tego mogą pojawić się problemy. Musisz też trochę uporządkować swoje dane, bo sztuczna inteligencja na słabych danych nie zadziała tak, jak oczekujesz. Jeśli w SharePoint czy w kanałach Teams panuje bałagan, agentowi będzie trudno pracować poprawnie w podejściu agentowym.

Tak, musisz rozumieć dane i wdrożyć podstawowe zabezpieczenia, takie jak uwierzytelnianie czy funkcje Perview, które stało się centralnym rozwiązaniem do zarządzania bezpieczeństwem i ładem.

A potem, kiedy już oczyścisz dane i wprowadzisz podstawowe zabezpieczenia, musisz też zrozumieć kwestie licencyjne, ponieważ zanim zaczniesz budować agenta, musisz wiedzieć, czy programiści są do tego przeszkoleni, czy mamy odpowiednie licencje, czy potrzebujemy subskrypcji i tym podobne.

Dużym problemem są narzędzia, jak poprawnie zintegrować je w moim procesie tworzenia agenta?

Czy muszę coś ograniczyć?

Szczerze mówiąc, to złożona kwestia i trzeba wziąć pod uwagę wiele działań, ale dla mnie najważniejsze jest zrozumienie danych. Jeśli firma ich nie rozumie, to na początku będzie to problem.

OK. I UM.

Kiedy, kiedy, my jak?

Czy my UM OK zapytaliśmy o to? UM. Temat bezpieczeństwa. UCH. Myślę, że są tu dwie, dwie, dwie.

Tak, dwa rodzaje ludzi.

Jedni mówią, że potrzebują uprawnień użytkownika, a drudzy, że uprawnień aplikacji. Jak agent powi, jak agent powinien generalnie działać?

Generalnie moją najlepszą rekomendacją jest to, by pracując z rozwiązaniami agentowymi zawsze używać uprawnień użytkownika, czyli delegowanych.

Pod kątem bezpieczeństwa jest to po prostu lepsze, ponieważ użytkownik operuje tylko na danych i narzędziach, do których ma dostęp.

To. To jest najważniejsza zasada. Później, jeśli potrzebujesz uprawnień aplikacji dla konkretnego API czy specyficznego kontekstu, możesz to zrobić.

Ale nie używaj uprawnień aplikacji bezpośrednio, zrób to w kontekście rappera.

Tworzysz więc, powiedzmy, serwer MCP i integrujesz go z uprawnieniami aplikacji w tle.

Wtedy serwer MCP wywoła na przykład Twoje API w tle przy użyciu uprawnień aplikacji i przekaże Ci potrzebne informacje, ale użytkownik nie ma bezpośredniej styczności z uprawnieniami aplikacji.

Wywołujemy serwer MCP przy użyciu uprawnień użytkownika, a serwer MCP w tle komunikuje się z usługami za pomocą dedykowanych uprawnień aplikacji. Widzisz różnicę? Uch, okej. Uch, ciekawe.

Myślę, że kiedy myślimy o architekturze, patrzymy też nieco głębiej.

Sądzę, że istnieją trzy wielkie tematy w architekturze. Mamy generowanie wspomagane wyszukiwaniem, mamy temat wiedzy oraz mamy, jak to nazywam, tylną furtkę wyszukiwania korporacyjnego. Um.

Gdzie zacznijmy od RAK? Gdzie RAK pasuje do architektury?

Ach, RAK.

Szczerze mówiąc, RAK jest tak naprawdę najbardziej, szczerze mówiąc, wydajny, ponieważ AI musi rozumieć różne rodzaje danych, a zasadniczo RAK służy do odpowiadania na pytania. Bo w przeszłości, kiedy nie było RAK, zasadniczo trzeba było radzić sobie z innym podejściem. Nie to, żeby było to staroświeckie, ale było to skomplikowane.

Ale RAK jest kluczowy, ponieważ rozumie różne rodzaje danych i w zasadzie pobierasz informacje, których AI potrzebuje z dokumentów, mogą to być różne typy danych.

Więc tak, RAK jest obecnie centralnym punktem w architekturze AI. Tak, ale to prawda, że dla wielu użytkowników, kiedy mówisz o RAK za kulisami, oni nie wiedzą, co to jest, bo Microsoft czy wiele innych firm programistycznych o tym nie mówi, ponieważ za kulisami masz RAK, ale na przykład w Copilot Studio użytkownik nie rozumie, że za kulisami jest RAK. Rozumiesz? I obecnie, kiedy chcesz zgłębić temat, masz tego typu koncepcje, ale dla wielu użytkowników RAK to kompletna nowość. Nie wiedzą, co to jest, bo po prostu używają narzędzia, a za kulisami masz te koncepcje i potem przechodzimy do kolejnego tematu, czyli wiedzy, jak zdobywamy, skąd systemy, a i czerpią swoją wiedzę, czy zbieram to ręcznie, czy jak to działa.

Właściwie musisz, musisz być szczery, wiedza jest, jest.

Może, może być hostowana w wielu różnych, w wielu różnych systemach.

Może to być zwykły plik tekstowy, może to być plik markdown, może to być baza wiedzy, może to być cokolwiek. Ale właściwie, jeśli masz serwer MCP, możesz uzyskać dostęp do tej wiedzy. Albo jeśli masz na przykład, nie wiem, konektor do SharePointa, masz konektory do wielu usług obecnie, więc dostęp do wiedzy jest łatwiejszy niż kiedyś, bądźmy szczerzy. Ponieważ w przeszłości musiałeś budować własną wtyczkę i wszystko wizytować. Obecnie masz bezpośredni łącznik do dowolnych systemów i możesz integrować swoją wiedzę bez konieczności angażowania dużych zespołów programistycznych.

Myślę, że często, nie wiem, zbieram to dla moich, mówię moim, nie wiem, ludziom.

A skąd AI wie, które dokumenty nie są gotowe, albo są przestarzałe, albo, nie wiem, zduplikowane?

Jak, jak, jak może, jak system AI może to zrozumieć? Czego powinniśmy używać i do czego?

W zasadzie używasz RAC, ponieważ w tle musisz zrozumieć, OK, czym są Twoje dane.

Ale szczerze mówiąc, podsumowując trochę, zaczynasz od promptu OK.

Użytkownik chce, powiedzmy, przeszukać bazę wiedzy oraz na przykład on-drive.

W tle, kiedy orkiestrator z pomocą LLM rozumie prompt i intencje użytkownika, w zasadzie masz indeks.

Ponieważ, na przykład, w kopilocie masz indeks semantyczny, który daje Ci w zasadzie OK. Mam całą tę wiedzę i AI może bezpośrednio odpytywać ten indeks semantyczny, aby wykonać, na przykład, RAC, dzięki czemu możesz bezpośrednio wybierać odpowiednie dokumenty w oparciu o potrzeby.

Ale w kopilocie masz ten indeks semantyczny i AI może w tle odpytywać go bezpośrednio za pomocą języka naturalnego.

Więc zapytam OK, chcę zrozumieć, nie wiem, jak skonfigurować firmową sieć VPN.

A w tle zostanie wykonany RAC na indeksie semantycznym, co pozwoli pobrać dokument, który zawiera, na przykład, całą konfigurację firmowej sieci VPN.

Na przykład w czacie Microsoft 365 kopilot w tle działa Graph API, ponieważ, jak wspomniałem wcześniej, masz indeks semantyczny zbudowany na Graph API.

W tle to funkcja Graph, ale w przypadku własnych rozwiązań masz, na przykład, Foundry AI w tle.

To była usługa Azure pod inną nazwą. Ale teraz możesz mieć własny system RAC, jeśli chcesz. W zasadzie, gdy masz własnego agenta, możesz zapytać bezpośrednio o instancję Foundry AQ. OK.

Chcę użyć, chcę uzyskać ustawienia mojej sieci VPN w firmie, AA i może pobrać to, czego potrzebujesz w dokumentach. Mogą to być pliki PDF, Word, Excel, tego typu rzeczy.

I, i.

Tak właśnie działa wyszukiwanie, prawda?

Albo. Chodzi Ci o to, co dzieje się za kulisami? Tak. A za kulisami? Tak. Masz wyszukiwanie.

W zasadzie obecnie za kulisami Copilot Hat masz trzy możliwości. Standardowe wyszukiwanie, czyli po prostu wpisujesz słowa kluczowe i przeszukujesz swoje dokumenty i tego typu rzeczy.

To proste wyszukiwanie. Wszyscy znamy wyszukiwanie słów kluczowych jak w Google. Następnie masz dwie różne możliwości.

Po pierwsze masz rak za kulisami.

Masz funkcję rak w graph, a także wyszukiwanie za pomocą indeksu semantycznego Copilota, które jest nieco inne, ponieważ rak jest bardziej zaawansowany niż ten indeks.

Masz jednak te trzy możliwości za kulisami, dzięki którym AI może wywołać te trzy różne funkcje, aby pobrać dane z OnDrive, Teams czy całego M365.

Indeks semantyczny Copilota uwzględnia również konektory Copilota.

Na przykład, jeśli masz połączony Salesforce przez konektor Copilota, możesz przeszukiwać wszystkie dane w Salesforce, ServiceNow i wielu innych narzędziach.

Dzięki konektorowi Copilota integrujesz wszystkie dane w indeksie semantycznym graph, więc możesz odpytywać bezpośrednio swoje systemy zewnętrzne.

Mym. OK. I myślę, że... Budując agentów mamy część dotyczącą zarządzania, a jedną z jej części jest dla mnie zarządzanie cyklem życia agenta.

Jak to właściwie wygląda?

Szczerze mówiąc, w ekosystemie Microsoftu jest to dość proste, jeśli można tak powiedzieć. Ponieważ korzystając z rozwiązań Low Code, na przykład Copilot Studio, pracujesz z Power Platform. Koncepcja ALM i tak dalej nic się nie zmieniło. Masz rozwiązania, masz wdrożone ALM, masz potoki. Jeśli chodzi o Copilot Studio, szczerze mówiąc, jest tak samo jak wcześniej, ponieważ masz wszystko to, w co zainwestowałeś w zakresie zarządzania Power Platform, cyklu życia i ALM. Jest dokładnie tak samo.

To dobrze, bo wielu ludzi pyta mnie och, a jak zarządzać Copilot Studio? Czy to coś innego? Cudzy słów, nie, to naprawdę proste, tak jak zarządzanie cyklem życia aplikacji w Power Apps czy Power Automate. W tym przypadku to zarządzanie cyklem życia agenta, ale w tle te same koncepcje, co w Power Platform.

A kiedy zajmujesz się na przykład tworzeniem własnych rozwiązań, to zasadniczo tak, jak przy budowaniu aplikacji .NET i tym podobnych, bo zarządzasz wszystkim jak kodem.

Więc masz frameworki, aspekty bezpieczeństwa i tym podobne. Szczerze mówiąc, wszystko w zakresie zarządzania cyklem życia aplikacji i agentów to naprawdę te same koncepcje, co wcześniej.

Dla mnie to duży plus, ponieważ nie musisz wiele inwestować w procesy cyklu życia i tego typu rzeczy.

Jedyna zmiana, a raczej jedna z największych zmian to OK, musisz zadbać o LLM, wdrażanie i tego typu sprawy.

Ale w tle wygląda to jak dawne podejście DevOps z potokami i tym podobnymi narzędziami. Moim zdaniem nic się nie zmieniło, bo zarządzamy agentami.

Tak. Może to być własny program lub kopilot. Obecnie szczerze mówiąc, stosujemy to samo podejście, co wcześniej. I. To oznacza, że jeśli firma nie używała wcześniej sztucznej inteligencji, ale ma idealną konfigurację Perview, Defendera i wszystkich pozostałych narzędzi.

Czy trzeba coś zmieniać? Czy to już oznacza gotowość na AI?

To wielkie pytanie, ponieważ gotowość na AI dla Microsoftu jest w porządku.

Zarządzanie uprawnieniami i tym podobne jest ważne, ale gotowość na AI to dla mnie nie tylko podejście techniczne, bo technicznie wiemy, co robić.

Okej, musimy zarządzać uprawnieniami w wielu usługach, rozumiesz? Dla mnie gotowość na AI musi obejmować także dane, same dane, rozumiesz?

Ponieważ, gdy nie rozumiesz swoich danych, tak jak wspomniałem wcześniej, nie możesz zarządzać stroną techniczną, bo jeśli nie wiesz, co jest poufne, a co nie, na przykład, trudno jest wdrożyć jakiekolwiek zabezpieczenia.

Ale jeśli podążamy za Microsoftem, gotowość na AI oznacza, musisz zarządzać uprawnieniami, chcesz wprowadzić etykiety wrażliwości, musisz zadbać o zgodność i tego typu rzeczy.

Istnieje jednak także bardziej ogólny aspekt, a według mnie gotowość na AI nie jest tylko kwestią techniczną, trzeba również wziąć pod uwagę aspekt funkcjonalny, mówiąc szczerze, w dzisiejszych czasach.

Tak, to naprawdę interesujące.

Myślę, że wiele firm zaczynało z AI, ale teraz wraz z agentami wiele z nich obawia się, że AI usunie ich maile albo zrobi coś niedobrego.

Harcmistrz.

Jak myślisz, co mówią firmy, które boją się AI?

To dobre pytanie, ponieważ mieszkam w Szwajcarii, gdzie mamy wiele banków prywatnych i bardzo wrażliwych klientów, więc najbardziej krytyczną kwestią jest, gdzie przetwarzane są dane?

W zasadzie tak, a także, czy AI przeszukuje moje maile?

Tego typu rzeczy.

Więc za kulisami zawsze o to pytają, ale najbardziej kluczowe jest dla nich muszę zrozumieć, gdzie są przetwarzane dane oraz, czy ja jestem właścicielem AI? Właścicielem AI,

więc wydaje instrukcję AI, a ona wykonuje pracę w tle, ale obawiają się one na przykład aspektu autonomii, bo dzisiaj możesz to zrobić, a AI w tle będzie czegoś szukać, wysyłać zapytania, więc martwią się, co właściwie dzieje się za kulisami, gdy o coś proszę.

Tak, pojawia się wiele pytań tego typu. Okej. Jak? Jak mogę przejąć kontrolę nad pełnym procesem kryjącym się za czymś, czy to agentem AI, czy usługą AI?

Tak, pojawiają się takie pytania, ale to naprawdę kwestia adopcji, a także szkoleń, aby wprowadzić pewne szkolenia dotyczące tego, jak rozumieć AI, jak zrozumieć, co dokładnie dzieje się za kulisami.

Przejrzystość to również ważny punkt, ponieważ musi być ona zapewniona w każdym rozwiązaniu AI.

Przejrzystość jest dla mnie kluczowym tematem, bo trzeba wdrożyć wszystko, aby Twoje rozwiązanie AI było transparentne.

Musisz rozumieć, co dzieje się za kulisami, jakie dane są odpytywane, musisz śledzić i logować wszystko.

Więc wszystko musi być przejrzyste, gdy masz dzisiaj jakieś rozwiązanie, ponieważ musisz dokładnie rozumieć, co jest wykonywane w tle, jakie dane są przetwarzane i jakie jest rozumowanie za kulisami. Dobrze. Jak wygenerowałeś ten plan? Na podstawie jakich faktów i tego typu rzeczy? Wspaniale. O, widzę, że kończy nam się czas. Więc, tak, przepraszam. Wiesz, to było naprawdę niesamowite, ale w każdym moim podcaście mam rundę szybkich pytań. Więc, więc podaję krótkie zdanie, a Ty udzielasz krótkiej odpowiedzi. Więc, czy jesteś gotowy? Tak. Kopilot Studio czy własny kod? Kopilot Studio Microsoft Foundry czy Kopilot Studio? Kopilot Studio TypeScript czy C Sharp?

GitHub czy Azure DevOps? GitHub Rack czy Dostrajanie?

W porządku. Jakie jest najbardziej niedoceniane API Microsoft 365?

API Rack. Jedna technologia, której każdy programista Microsoft powinien nauczyć się w 2026 roku. GitHub Kopilot.

Gdyby Satya Nadella przyszedł do Ciebie i powiedział masz wszystkie pieniądze i zasoby, których potrzebujesz, aby ulepszyć naszą platformę AI. Możesz rozwinąć jedną funkcję, jaka by to była? Wszystkie kwestie związane z zarządzaniem governance, których potrzebujemy.

IUM. Kogo powinienem zaprosić jako następnego do podcastu i jakie pytanie zadać?

O, dobre pytanie. Mam wielu znajomych, ale tak, może możesz zapytać moją współprelegentkę z wielu konferencji. Możesz zapytać na przykład Chloe Moro. Była konsultantką funkcjonalną, zanim przeszła na stronę techniczną. I ma naprawdę dobrą historię o rzeczach mniej technicznych, a bardziej funkcjonalnych w świecie Dynamics.

Może więc zaprosisz ją i zapytasz powiedz mi, jak dzisiaj radzić sobie z równoważeniem pracy funkcjonalnej i technicznej, bo masz tam pewne, no wiesz, całkiem spore wyzwania.

Tak, a moje, moje, moje ostatnie pytanie brzmi, co ludzie, jeśli mieliby wyciągnąć jedną, jedną lekcję z tego spotkania, co powinni zapamiętać.

Z tej sesji masz na myśli w zasadzie, że sztuczna inteligencja rozwija się szybko.

I jeśli chcesz być dziś na bieżąco, musisz śledzić, no wiesz, wszystko, bo szczerze mówiąc, SI przenika obecnie cały stos technologiczny Microsoftu. I obecnie jedną z rzeczy, które musisz zrozumieć jest to, że ewolucja postępuje szybko i musisz być na bieżąco, naprawdę w każdym momencie, ponieważ w pewnym punkcie coś przegapisz, jeśli nie będziesz się uczyć i nie będziesz rozumieć tego typu ewolucji.

Tak, więc bardzo dziękuję za dołączenie do mnie. Myślę, że ważnym wnioskiem z naszej rozmowy jest to, że rozszerzalność Microsoft 365 kopilot to nie tylko pisanie coraz bardziej zaawansowanych promptów. Myślę, że zmierzamy w stronę architektury, w której kopilot i agenci mogą łączyć wiedzę organizacyjną, Microsoft Graph, aplikacje biznesowe, API itd.

Mym, tak. Uważam, że kopilot studio, Microsoft Foundry, rozwiązania customowe i technologie takie jak MCP dają programistom niesamowity i potężny zestaw narzędzi.

I tak, im bardziej sprawni stają się agenci, tym ważniejsze stają się podstawy, tożsamość, uprawnienia, bezpieczeństwo, zarządzanie, testowanie, obserwowalność, cykl życia aplikacji itd.

Więc tak myślę, że przedstawiłeś naprawdę, naprawdę dobry przegląd wszystkich tych tematów. Dziękuję za dołączenie do mnie, a słuchaczy odsyłam do notatek w odcinku na stronie podcastu M365FM, gdzie znajdą wszystkie informacje, gdzie mogą się skontaktować i zobaczyć pracę EES. Dziękuję, że tu jesteś. Dzięki za zaproszenie. To był naprawdę dobrze spędzony z Tobą czas.