Wróć do katalogu
Microsoft Copilot Studio
Edycja 2026. Techniczne, dogłębne spojrzenie na Microsoft Copilot Studio, obejmujące takie zagadnienia jak generative orchestration, agent flows, tools, enterprise grounding i wiele więcej (2026).
Teraz odtwarzane
Click play to start
0:00
0:00
1
Generative Orchestration
Odkryj zmianę paradygmatu z klasycznych fraz wyzwalających na Generative Orchestration w Microsoft Copilot Studio. Dowiedz się, jak sztuczna inteligencja dynamicznie wybiera topics i tools na podstawie opisów, całkowicie eliminując potrzebę sztywnego mapowania konwersacji. Ten odcinek wyjaśnia, jak inteligentne rutowanie bez wysiłku radzi sobie z zapytaniami o wielu intencjach.
2
AI-Based Agent Authoring
Dowiedz się, jak używać języka naturalnego, aby przyspieszyć proces budowania botów. Odkrywamy AI-Based Agent Authoring, które pozwala generować złożone topics, prompts i flows po prostu je opisując. Zrozum, jak modele LLM są wykorzystywane na etapie tworzenia (build-time) do szybkiego prototypowania agentów.
3
Topics i Nodes
Zanurz się w strukturalną anatomię agenta. Ten odcinek szczegółowo omawia System topics w porównaniu do Custom topics oraz deterministyczną logikę węzłów wymaganą dla określonych reguł biznesowych. Dowiedz się, jak mapować precyzyjne ścieżki konwersacyjne za pomocą variables i conditions.
4
State i Variables
Daj swojemu agentowi pamięć. Odkryj, jak pracować z variables w Copilot Studio, aby przekazywać kontekst między topics, eliminując powtarzające się pytania. Badamy również wykorzystanie environment variables do bezpiecznego przechowywania sekretów z Azure Key Vault.
5
Entities i Slot Filling
Wyodrębniaj ustrukturyzowane dane z nieustrukturyzowanego języka naturalnego. Ten odcinek wyjaśnia prebuilt entities, custom closed lists, regex entities oraz magię proactive slot filling, która pozwala sztucznej inteligencji pomijać pytania, gdy użytkownik z góry poda potrzebne informacje.
6
Enterprise Knowledge Grounding
Zmień swoje istniejące dane firmowe w konwersacyjnego eksperta. Dowiedz się, jak podłączyć SharePoint, Dataverse i publiczne strony internetowe jako źródła wiedzy dla Generative Answers. Odkryj ograniczenia i możliwości ugruntowania (grounding) Twojej sztucznej inteligencji.
7
Tenant Graph Grounding
Uwolnij pełną moc Microsoft Graph i wyszukiwania semantycznego dla wysoce precyzyjnego wyszukiwania informacji. Ten odcinek eksploruje Tenant Graph Grounding, wykorzystując licencje Microsoft 365 Copilot do przeszukiwania ogromnych dokumentów firmowych z głębokim zrozumieniem semantycznym.
8
Prompt Tools
Daj swojemu agentowi możliwość wykonywania określonych zadań przetwarzania danych lub podsumowywania w locie. Dowiedz się, jak tworzyć Prompt Tools, definiować szablony, określać inputs i ustawiać formaty odpowiedzi bezpośrednio w Copilot Studio.
9
Agent Flows
Połącz Copilot Studio ze złożonymi, wieloetapowymi automatyzacjami backendowymi za pomocą Agent Flows. Ten odcinek szczegółowo opisuje, jak dodawać przepływy Power Automate jako tools, kładąc nacisk na krytyczny limit 100 sekund na wykonanie oraz wymagania dotyczące odpowiedzi synchronicznych.
10
Power Platform Connectors
Skorzystaj z tysięcy istniejących API w ekosystemach Microsoft i firm trzecich. Odkryj, jak używać Power Platform Connectors jako aktywnych tools w Twoich agentach Copilot Studio, aby bez wysiłku wchodzić w interakcje z zewnętrznymi usługami.
11
Computer Use Tool
Automatyzuj starsze systemy, które nie mają API, za pomocą automatyzacji opartej na wizji. Odkryj narzędzie Computer Use Tool w wersji preview, które wykorzystuje modele takie jak Claude Sonnet 4.5 do interakcji z graficznymi interfejsami użytkownika za pomocą wirtualnej myszy i klawiatury, wraz z firmowymi zabezpieczeniami.
12
User Authentication
Zabezpiecz swojego agenta i odblokuj spersonalizowane doświadczenia. Zanurz się w User Authentication w Copilot Studio, porównując opcję 'Authenticate with Microsoft' z ręcznymi konfiguracjami Manual OAuth2. Dowiedz się, jak konfigurować scopes i zapewnić dostęp na zasadzie najmniejszych uprawnień.
13
Voice i IVR
Przenieś swojego agenta z klawiatury na linię telefoniczną. Odkryj możliwości Interactive Voice Response (IVR) w Copilot Studio. Dowiedz się o rozpoznawaniu mowy, DTMF, funkcji barge-in oraz dostosowywaniu głosów agentów za pomocą SSML.
14
Agent Analytics
Nie możesz ulepszyć tego, czego nie mierzysz. Ten odcinek szczegółowo omawia pulpit nawigacyjny Analytics w Copilot Studio, wyjaśniając widok hybrydowy dla sesji konwersacyjnych i autonomicznych oraz sposób eksportowania transkrypcji do głębokiej analizy.
15
Model Context Protocol
Zabezpiecz swoich agentów na przyszłość dzięki otwartemu standardowi dla kontekstu AI. Dowiedz się, jak zintegrować Copilot Studio z zewnętrznymi serwerami Model Context Protocol (MCP), aby dynamicznie pobierać Resources, Tools i Prompts.
Odcinki
1
Generative Orchestration
3m 57sOdkryj zmianę paradygmatu z klasycznych fraz wyzwalających na Generative Orchestration w Microsoft Copilot Studio. Dowiedz się, jak sztuczna inteligencja dynamicznie wybiera topics i tools na podstawie opisów, całkowicie eliminując potrzebę sztywnego mapowania konwersacji. Ten odcinek wyjaśnia, jak inteligentne rutowanie bez wysiłku radzi sobie z zapytaniami o wielu intencjach.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 1 z 15. Większość twórców botów spędza godziny, próbując przewidzieć i zmapować każdą możliwą frazę, którą użytkownik może wpisać. Dodajesz pięćdziesiąt wariantów zgłoszenia do supportu, a system i tak zawodzi, gdy ktoś wpisze frazę, której się nie spodziewałeś. Generative Orchestration całkowicie eliminuje tę potrzebę dzięki dynamicznemu dopasowywaniu opisów.
Często, gdy ludzie słyszą słowo generatywny w tym kontekście, zakładają, że oznacza to generowanie tekstu konwersacyjnego. W tym przypadku tak nie jest. Generative Orchestration to wyłącznie dynamiczny routing i wybór tooli. To inteligencja, która decyduje, jaką akcję podjąć, a nie tylko pisze odpowiedź.
W klasycznej orkiestracji budujesz topic i ręcznie definiujesz listę triggerów. Silnik rozumienia języka naturalnego opiera się na tych konkretnych frazach, aby zroutować użytkownika. Generative Orchestration całkowicie eliminuje triggery. Zamiast tego piszesz jasny opis plain-textem dla każdego topicu i toola w twoim agencie. Duży model językowy pod spodem odczytuje query użytkownika, ewaluuje wszystkie dostępne opisy i dynamicznie określa najlepsze dopasowanie. Nie mapujesz już inputów na triggery. Po prostu opisujesz, co robią twoje toole.
To całkowicie zmienia sposób, w jaki agent obsługuje złożone inputy. Wyobraź sobie użytkownika, który pyta: Jaka jest pogoda w Seattle i kiedy otwierają sklep?
W klasycznym setupie to się wysypuje. System wykrywa dwie sprzeczne intencje i albo zgaduje jedną, albo rzuca błędem fallback. Generative Orchestration radzi sobie z tym bez problemu. Model parsuje całe zdanie i rozpoznaje dwa różne cele. Skanuje twoje opisy. Najpierw znajduje tool pogodowy. Wyciąga Seattle z query użytkownika, przekazuje do toola pogodowego jako parametr wejściowy i go wykonuje. Następnie pamięta drugą połowę promptu użytkownika. Ponownie skanuje twoje topiki, znajduje ten opisany jako obsługa godzin otwarcia sklepu i go triggeruje.
I tu jest kluczowa sprawa. Agent automatycznie chainuje te akcje ze sobą. Obsługuje request o pogodę, a następnie płynnie przechodzi do topicu godzin otwarcia sklepu, łącząc wyniki. Nie piszesz żadnej logiki routingu ani kodu przejścia, żeby to osiągnąć.
Ta zmiana oznacza, że jakość twojego agenta zależy teraz wyłącznie od jakości twoich opisów. Jeśli opis twojego toola pogodowego to po prostu pogoda, model może mieć problem z dokładnym routingiem. Jeśli opis mówi pobiera aktualne warunki pogodowe dla podanej nazwy miasta, routing staje się dokładny. Co więcej, jeśli użytkownik ztriggeruje ten tool pogodowy, ale zapomni podać miasto, silnik generatywny automatycznie zauważy, że brakuje wymaganego parametru. Dynamicznie wygeneruje pytanie do użytkownika o miasto przed wykonaniem toola.
Główny wniosek jest taki. Generative Orchestration zmienia routing z kruchego dopasowywania fraz w inteligentne wyszukiwanie możliwości, uwalniając twój czas, byś mógł skupić się na tym, co twój agent potrafi, zamiast zgadywać, jak użytkownik o to poprosi.
Jeśli chcesz wesprzeć podcast, znajdziesz nas szukając DevStoriesEU na Patreon. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!
2
AI-Based Agent Authoring
3m 49sDowiedz się, jak używać języka naturalnego, aby przyspieszyć proces budowania botów. Odkrywamy AI-Based Agent Authoring, które pozwala generować złożone topics, prompts i flows po prostu je opisując. Zrozum, jak modele LLM są wykorzystywane na etapie tworzenia (build-time) do szybkiego prototypowania agentów.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 2 z 15. Zazwyczaj budowanie flow konwersacyjnego oznacza przeciąganie node'ów na canvas, ręczne łączenie drzew logicznych i zgadywanie każdego możliwego trigger phrase'a, który może wpisać użytkownik końcowy. Ale co, gdybyś mógł po prostu powiedzieć AI, co dokładnie chcesz zbudować, i pozwolić jej wygenerować logikę strukturalną za ciebie? Ten mechanizm to tak zwany AI-based agent authoring.
Kluczowe jest odróżnienie tego od zachowania AI w runtime. Developerzy często mylą generatywne AI w build time z generatywnym AI w runtime. Runtime to moment, w którym prawdziwy użytkownik zadaje pytanie, a agent dynamicznie generuje odpowiedź, korzystając z zewnętrznej bazy wiedzy. Build-time authoring to zupełnie inna sprawa. Polega to na użyciu asystenta AI wewnątrz studia do zbudowania statycznego frameworku samego agenta.
Zaczynasz na authoring canvasie. Zamiast klikać, aby dodać poszczególne elementy, wchodzisz w interakcję z Copilot authoring pane. Załóżmy, że potrzebujesz flow do obsługi zwrotów sprzętu. Wpisujesz prosty opis po angielsku, prosząc o topic, który pyta użytkownika o numer zamówienia, sprawdza, czy sprzęt to laptop, czy urządzenie mobilne, a następnie podaje prawidłowy adres zwrotny na podstawie typu urządzenia.
Po wysłaniu tego promptu model rozumienia języka naturalnego przetwarza twoje instrukcje i mapuje je bezpośrednio na wewnętrzny schemat node'ów Copilot Studio. Automatycznie generuje zestaw zróżnicowanych trigger phrases, które prawdziwy użytkownik może wypowiedzieć, aby zainicjować ten konkretny flow. Umieszcza question node na canvasie, aby przechwycić numer zamówienia i przypisuje do niego zmienną. Tworzy condition node, aby rozgałęzić logikę między laptopem a urządzeniem mobilnym. Następnie wypełnia końcowe message node'y placeholderami adresów zwrotnych. Cały szkielet topicu pojawia się natychmiast na twoim ekranie.
Oto kluczowa kwestia. Ten proces authoringu jest ściśle iteracyjny. Nie musisz akceptować początkowej generacji jako finalnego produktu. Jeśli spojrzysz na wygenerowany flow i zdasz sobie sprawę, że musisz przechwycić datę zakupu, nie musisz ręcznie zrywać połączeń i wstawiać nowego node'a. Po prostu mówisz authoring Copilotowi, żeby dodał pytanie o datę zakupu tuż przed pytaniem o numer zamówienia. Model pod spodem analizuje aktualny stan twojego canvasu, rozumie sekwencyjny punkt wstawienia i bezpiecznie modyfikuje flow.
Ponieważ AI tłumaczy język naturalny bezpośrednio na standardowe komponenty Copilot Studio, zachowujesz pełną kontrolę nad architekturą. Wygenerowane node'y nie są black boxami. Są to dokładnie te same elementy, które utworzyłbyś ręcznie. Możesz kliknąć w gałęzie condition, dostosować typy zmiennych lub ręcznie przepisać tekst promptu. Model językowy po prostu zajmuje się mechanicznym składaniem canvasu.
Prawdziwa siła AI-based authoringu nie polega na tym, że pisze on bezbłędne flow konwersacyjne za pierwszym razem, ale na tym, że przekształca powolny, mechaniczny proces łączenia node'ów w szybki dialog o intencjach biznesowych. Dzięki, że wpadłeś. Mam nadzieję, że dowiedziałeś się czegoś nowego.
3
Topics i Nodes
4m 13sZanurz się w strukturalną anatomię agenta. Ten odcinek szczegółowo omawia System topics w porównaniu do Custom topics oraz deterministyczną logikę węzłów wymaganą dla określonych reguł biznesowych. Dowiedz się, jak mapować precyzyjne ścieżki konwersacyjne za pomocą variables i conditions.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 3 z 15. Nawet najbardziej zaawansowani agenci AI w końcu potrzebują deterministycznej logiki dla konkretnych reguł biznesowych. Gdy klient pyta o politykę zwrotów lub godziny otwarcia sklepu, nie możesz pozwolić sobie na probabilistyczne zgadywanie przez model językowy. Potrzebujesz precyzyjnej, gwarantowanej odpowiedzi. Topics i Nodes dają ci dokładnie taką kontrolę nad strukturą.
Pomyśl o topicu jak o odrębnej ścieżce konwersacji. To predefiniowane drzewo dialogowe, które dokładnie określa, jak twój agent obsługuje konkretną intencję. Twój agent to w zasadzie zbiór takich topiców, które współpracują ze sobą, aby odpowiednio routować użytkownika. Często mylone jest rozróżnienie między System topics a Custom topics. To prostsze, niż się wydaje. System topics obsługują podstawowe zachowania agenta. Zarządzają one kluczowymi eventami, takimi jak powitanie użytkownika, zakończenie konwersacji, eskalacja do człowieka lub przechwycenie błędu, gdy agent nie rozumie inputu. Możesz modyfikować ich tekst, aby pasował do głosu twojej marki, ale nie możesz ich usunąć. Są one stałymi elementami architektury systemu. Custom topics to ścieżki, które budujesz samodzielnie, całkowicie pod twoją kontrolą, aby obsługiwać konkretne scenariusze biznesowe.
Wewnątrz każdego topicu konwersacja wykonuje się z góry na dół przez poszczególne kroki zwane nodami. Nody to funkcjonalne bloki budulcowe twojej ścieżki. Aby zrozumieć, jak ze sobą współdziałają, wyobraź sobie Custom topic zaprojektowany do obsługi zapytań o godziny otwarcia sklepu.
Gdy użytkownik uruchomi ten topic, pierwszym krokiem w twoim flow może być Question node. Question node prosi użytkownika o informacje i czeka na określony typ odpowiedzi. W tym przypadku agent pyta, które miasto użytkownik planuje odwiedzić. Gdy użytkownik odpowie, node przechwytuje tę odpowiedź.
To wprowadza nas w temat zarządzania zmiennymi. Question node automatycznie zapisuje odpowiedź użytkownika w zmiennej. Przechowujesz teraz w pamięci konkretny fragment state'u, co pozwala ci dynamicznie routować konwersację na podstawie tego, co właśnie powiedział użytkownik.
I tu robi się ciekawie. Zamiast zwracać generyczną odpowiedź, dodajesz Condition node, aby sprawdzić tę zmienną. Condition node działa jak logiczne rozwidlenie drogi. Sprawdza aktualny state twojej zmiennej względem zdefiniowanych przez ciebie reguł. Jeśli zapisane miasto to Nowy Jork, node kieruje flow w jedną gałąź. Jeśli miasto to Londyn, kieruje flow w inną. Możesz dodać tyle gałęzi, ile potrzebujesz dla różnych stanów, plus gałąź fallback, jeśli zmienna nie pasuje do żadnego znanego miasta.
Wreszcie, na końcu każdej gałęzi warunkowej umieszczasz Message node. Message node po prostu wyświetla użytkownikowi tekst lub multimedia. Gałąź dla Nowego Jorku trafia na Message node z informacją, że sklep otwiera się o dziewiątej rano. Gałąź dla Londynu trafia na inny Message node z informacją, że sklep otwiera się o dziesiątej.
Chainując ze sobą nody typu Question, Variable, Condition i Message, dokładnie określasz, jak płynie logika. Najważniejszy wniosek z tego jest taki, że topics izolują twoje deterministyczne reguły biznesowe w przewidywalne ścieżki, zapewniając niezawodne działanie agenta, gdy precyzja ma większe znaczenie niż generowanie.
Dzięki za wysłuchanie. Do usłyszenia następnym razem!
4
State i Variables
3m 45sDaj swojemu agentowi pamięć. Odkryj, jak pracować z variables w Copilot Studio, aby przekazywać kontekst między topics, eliminując powtarzające się pytania. Badamy również wykorzystanie environment variables do bezpiecznego przechowywania sekretów z Azure Key Vault.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 4 z 15. Najszybszym sposobem na sfrustrowanie użytkownika jest zmuszenie go do powtórzenia informacji, które przed chwilą ci podał. Jeśli twój bot pyta o imię, odpala nowy workflow, a potem znowu pyta o imię, to user experience całkowicie leży. Mechanizmem, który zapobiega tej amnezji, są state i zmienne.
Zmienna w Copilot Studio przechowuje dane wyciągnięte od użytkownika lub pobrane z backendu. Najważniejszą decyzją, jaką podejmujesz przy tworzeniu zmiennej, jest określenie jej scope'u. Słuchacze często mylą zmienne na poziomie topicu ze zmiennymi globalnymi. Zmienna na poziomie topicu jest ściśle lokalna. Istnieje tylko wtedy, gdy jej parent topic jest aktywny. W momencie, gdy ten topic się kończy, zmienna jest czyszczona z pamięci. Z kolei zmienna globalna utrzymuje się przez cały czas trwania konwersacji. Każdy topic może ją odczytać i każdy topic może ją nadpisać.
Kuszące jest zrobienie z każdego współdzielonego kawałka danych zmiennej globalnej. Nie rób tego. Nadużywanie zmiennych globalnych powoduje nieprzewidywalne zmiany state'u, gdy topiki przerywają sobie nawzajem. Zamiast tego przekazuj zmienne lokalne bezpośrednio między topikami. Wyobraź sobie topic o nazwie Greeting. Pyta on użytkownika o imię i zapisuje je w zmiennej lokalnej. Greeting się kończy, a flow przekierowuje do nowego topicu o nazwie Talk to Customer. Aby przenieść to imię, konfigurujesz topic Talk to Customer tak, aby odbierał wartości z innych topików. Definiujesz input variable w tym docelowym topicu. Następnie, wracając do twojego topicu Greeting, node przekierowujący automatycznie poprosi cię o zmapowanie wartości do tego inputu. Przekazujesz lokalną zmienną z imieniem przez tego node'a. Docelowy topic ją przechwytuje, bot kontynuuje konwersację używając poprawnego imienia, a twój global state pozostaje niezaśmiecony. Kiedy ten docelowy topic skończy swoją pracę, może również zwrócić wartości z powrotem do oryginalnego topicu wywołującego, używając output variables.
To tyle, jeśli chodzi o dane generowane podczas czatu. Teraz druga kwestia, czyli dane, których twój agent potrzebuje, zanim czat w ogóle się zacznie. Jeśli twój agent łączy się z zewnętrznymi systemami, potrzebuje credentials. Absolutnie nigdy nie przechowuj API keys ani connection strings w zmiennych konwersacji. Do tego używasz environment variables. Environment variables żyją całkowicie poza sesją użytkownika. Przechowują dane konfiguracyjne, które dotyczą samego agenta, pozwalając ci na przeniesienie bota ze środowiska development do testowego, a ostatecznie na produkcję, bez hardcodowania wartości.
Zwróć uwagę na ten fragment. Kiedy masz do czynienia z bardzo wrażliwymi danymi, environment variables integrują się bezpośrednio z Azure Key Vault. Zamiast wklejać hasło do Copilot Studio, tworzysz environment variable oznaczoną jako secret. Ta zmienna przechowuje referencję do konkretnego klucza w twoim Azure Key Vault. Podczas runtime'u, agent bezpiecznie pobiera ten secret, aby zautoryzować request do backendu. Ten secret nigdy nie jest eksponowany w authoring canvas, nigdy nie jest drukowany w logach czatu i jest wykluczony z twoich eksportów do source control.
Najbezpieczniejszy state to scoped state, więc trzymaj zmienne konwersacji lokalnie, kiedy tylko to możliwe, przekazuj je jawnie przez granice topików i zawsze deleguj systemowe credentials do bezpiecznych environment variables. Dzięki za wysłuchanie, happy coding wszystkim!
5
Entities i Slot Filling
4m 12sWyodrębniaj ustrukturyzowane dane z nieustrukturyzowanego języka naturalnego. Ten odcinek wyjaśnia prebuilt entities, custom closed lists, regex entities oraz magię proactive slot filling, która pozwala sztucznej inteligencji pomijać pytania, gdy użytkownik z góry poda potrzebne informacje.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 5 z 15. Tworzysz bota do przyjmowania zamówień, ale zmusza on użytkowników do przebrnięcia przez pięć żmudnych pytań. Użytkownik podał już wszystkie szczegóły w pierwszej wiadomości, a twój bot ignoruje ten kontekst i nadal pyta o nie po kolei. To sztywne zachowanie frustruje użytkowników i właśnie ten problem rozwiązują encje i slot filling.
Encje to sposób, w jaki Copilot Studio rozpoznaje rzeczywiste obiekty w chaotycznym języku naturalnym. Wyobraź sobie encję jako konkretny typ danych, który twój bot został nauczony rozpoznawać w zdaniu. Zamiast analizować całe wyrażenie Chciałbym wydać dwadzieścia dolców, AI po prostu szuka encji money i wyciąga wartość dwadzieścia.
Copilot Studio zawiera duży zestaw wbudowanych encji. Obsługują one standardowe koncepty danych out of the box. Wbudowane encje rozpoznają wiek, daty, kolory, liczby, imiona i pieniądze. Automatycznie normalizują dane. Niezależnie od tego, czy użytkownik wpisze dwadzieścia dolarów, znak dolara i 20, czy dwadzieścia dolców, wbudowana encja money wyciąga dokładną wartość liczbową i walutę.
Ale twój biznes opiera się na specyficznej terminologii. Aby to uchwycić, tworzysz customowe encje. Będziesz używać dwóch głównych typów customowych encji. Pierwszy to encja typu closed list. Definiujesz ścisłą listę dozwolonych elementów, a następnie do każdego z nich przypisujesz synonimy. Jeśli sprzedajesz sprzęt outdoorowy, możesz utworzyć encję kategorii produktów z głównym elementem o nazwie hiking. Następnie dodajesz synonimy, takie jak trekking, backpacking i trail walking. Gdy użytkownik wpisze którykolwiek z tych synonimów, AI mapuje jego input bezpośrednio na główną wartość hiking.
Drugi customowy typ to encja wyrażenia regularnego, czyli regex. Encji regex używasz, gdy użytkownicy muszą podać sformatowane stringi, a nie konkretne słowa. Częsty use case to ticket do supportu albo order ID. Jeśli twój system używa numerów trackingowych, które zawsze zaczynają się od liter TRK, po których następuje pięć cyfr, definiujesz ten pattern za pomocą regexa. AI przeskanuje wiadomość użytkownika i czysto wyciągnie dokładnie ten string, ignorując otaczający tekst.
Identyfikacja encji to dopiero pierwszy krok. Musisz zapisać te dane, aby ich użyć. Ta akcja nazywa się slot filling. Mapujesz wyciągniętą encję na zmienną, wypełniając slot danymi użytkownika.
Tutaj zaczyna się robić ciekawie. Copilot Studio używa funkcji zwanej proactive slot filling. Domyślnie silnik rozumienia języka naturalnego analizuje każdą wiadomość użytkownika pod kątem wszystkich zmiennych, których wymaga twój temat konwersacji. Jeśli AI wykryje wymagane encje w początkowym inpucie użytkownika, natychmiast wypełnia te sloty.
Wyobraź sobie użytkownika, który triggeruje twój temat zakupowy, mówiąc: Chcę kupić buty do hikingu za mniej niż 100 dolarów. Masz customową encję closed list dla kategorii produktów i używasz wbudowanej encji money dla budżetu. Dzięki proactive slot filling, AI przetwarza całe to zdanie naraz. Izoluje hiking, mapuje go na twoją zmienną kategorii i zapisuje. Izoluje 100 dolarów, mapuje je na twoją zmienną budżetu i to również zapisuje.
Ponieważ te sloty są już wypełnione, bot automatycznie i całkowicie pomija nody z pytaniami Jakiej kategorii szukasz? oraz Jaki jest twój budżet?. Flow konwersacji przeskakuje od razu nad nimi i przechodzi bezpośrednio do kolejnego brakującego elementu informacji.
Definiując ścisłe encje i ufając, że proactive slot filling zajmie się ekstrakcją, przestajesz pisać sztywne drzewa decyzyjne i zaczynasz budować agentów konwersacyjnych, którzy szanują czas użytkownika.
To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!
6
Enterprise Knowledge Grounding
4m 07sZmień swoje istniejące dane firmowe w konwersacyjnego eksperta. Dowiedz się, jak podłączyć SharePoint, Dataverse i publiczne strony internetowe jako źródła wiedzy dla Generative Answers. Odkryj ograniczenia i możliwości ugruntowania (grounding) Twojej sztucznej inteligencji.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 6 z 15. Najtrudniejszą częścią budowania agenta konwersacyjnego było kiedyś przewidywanie każdego pytania użytkownika i ręczne tworzenie odpowiedzi. Spędzałeś tygodnie na mapowaniu drzew dialogowych, tylko po to, żeby użytkownicy zapytali o coś lekko poza skryptem i trafili w ślepy zaułek. Enterprise Knowledge Grounding całkowicie odwraca ten model. Zamiast pisać odpowiedzi, twoje istniejące dane firmowe odwalają całą czarną robotę.
Generyczny large language model jest bardzo elokwentny, ale nie wie absolutnie nic o twojej konkretnej firmie. Enterprise Knowledge Grounding wypełnia tę lukę, łącząc copilota bezpośrednio z twoimi rzeczywistymi danymi biznesowymi, takimi jak publiczne strony internetowe, katalogi SharePoint, wgrane pliki i tabele Dataverse.
Weźmy na warsztat scenariusz obsługi klienta. Potrzebujesz agenta, który odpowiada na pytania o twój sprzęt. Zamiast budować setki customowych topiców, wgrywasz swoje instrukcje produktów w PDF do copilota i wklejasz URL swojej publicznej strony z dokumentacją. Kiedy użytkownik pyta, jak zresetować konkretny model routera, copilot przeszukuje te podłączone źródła, pobiera odpowiedni tekst i syntetyzuje bezpośrednią odpowiedź. Podaje również link do źródła do konkretnej instrukcji lub strony internetowej, dzięki czemu użytkownik może zweryfikować te informacje.
Często mylącą kwestią jest to, gdzie dokładnie ta wiedza żyje w architekturze. Możesz podpiąć wiedzę w dwóch różnych miejscach: na poziomie agenta lub na poziomie topicu.
Wiedza na poziomie agenta jest globalna. Działa jak siatka bezpieczeństwa dla całego copilota. Jeśli użytkownik zada pytanie i nie zostanie uruchomiony żaden ręcznie stworzony topic, system robi fallback do tej globalnej puli wiedzy. Przeszukuje wszystkie twoje podłączone źródła na poziomie agenta, aby wygenerować odpowiedź. Oznacza to, że zyskujesz natychmiastową wartość bez pisania żadnych customowych flow konwersacji.
Oto kluczowa kwestia. Czasami potrzebujesz ścisłej kontroli nad tym, jakich danych używa AI, i właśnie tutaj wkracza wiedza na poziomie topicu. Konfigurujesz to, przeciągając node Generative Answers bezpośrednio na canvas tworzenia konkretnego customowego topicu.
Jeśli użytkownik uruchomi customowy topic do przetwarzania roszczeń gwarancyjnych, nie chcesz, żeby AI zaciągało odpowiedzi z twojej ogólnej strony marketingowej. Używając node'a Generative Answers wewnątrz tego konkretnego topicu, możesz ograniczyć jego źródło danych wyłącznie do folderu SharePoint zawierającego prawne dokumenty gwarancyjne. Scope AI jest ograniczony dokładnie do kontekstu tego kroku konwersacji.
Podczas podłączania tych firmowych źródeł, system inteligentnie zarządza dostępem. W przypadku publicznych stron internetowych, copilot po prostu indeksuje publiczne strony. Dla źródeł wewnętrznych, takich jak SharePoint, copilot używa credentials z Entra ID osoby wchodzącej w interakcję z botem. Ściśle respektuje istniejące uprawnienia do plików. Jeśli pracownik nie ma dostępu do konkretnego wewnętrznego dokumentu w SharePoint, copilot nie odczyta tego dokumentu i nie użyje go do odpowiedzi na jego pytanie.
W przypadku danych ustrukturyzowanych, możesz podłączyć się bezpośrednio do tabel Dataverse, pozwalając copilotowi na opieranie swoich odpowiedzi na rekordach live z twoich aplikacji biznesowych.
Użycie node'a Generative Answers wewnątrz customowego topicu pozwala ci na ścisłą kontrolę dokładnych granic wiedzy AI w konkretnych punktach konwersacji, zapobiegając zaburzaniu bardzo specyficznych workflowów przez szerokie, globalne dane. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!
7
Tenant Graph Grounding
3m 57sUwolnij pełną moc Microsoft Graph i wyszukiwania semantycznego dla wysoce precyzyjnego wyszukiwania informacji. Ten odcinek eksploruje Tenant Graph Grounding, wykorzystując licencje Microsoft 365 Copilot do przeszukiwania ogromnych dokumentów firmowych z głębokim zrozumieniem semantycznym.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 7 z 15. Standardowe wyszukiwanie słów kluczowych zawodzi w momencie, gdy użytkownik zadaje zniuansowane pytanie dotyczące wewnętrznej polityki. Nie potrzebujesz lepszych słów kluczowych. Potrzebujesz systemu, który rozumie rzeczywiste znaczenie pytania w ogromnych zbiorach danych. I tu właśnie wchodzi do gry Tenant Graph Grounding.
Tenant Graph Grounding wprowadza głębokie zrozumienie semantyczne bezpośrednio do twoich danych firmowych. Najpierw rozwiejmy pewien powszechny mit. To nie jest standardowe wyszukiwanie w Dataverse i nie ma nic wspólnego ze scrapowaniem publicznych stron internetowych. To zaawansowana funkcja retrievalu dla firm, która podłącza twojego copilota bezpośrednio do Microsoft Graph. Została stworzona specjalnie do obsługi złożonej wiedzy wewnętrznej przechowywanej w ramach twojego tenanta.
Aby korzystać z tej funkcji, twoje środowisko musi spełniać kilka twardych wymagań. Potrzebujesz licencji Microsoft 365 Copilot. Twoje dane muszą być indeksowane przez Semantic Index for Copilot. Co najważniejsze, twój copilot musi być skonfigurowany z uwierzytelnianiem Microsoft Entra ID. To nie jest opcjonalne. Copilot musi bezpiecznie przekazywać tożsamość osoby zadającej pytanie do Microsoft Graph.
Weźmy na przykład wewnętrznego copilota HR, zaprojektowanego do przeszukiwania ogromnych podręczników dla pracowników. Te podręczniki często siedzą w SharePoint lub OneDrive jako gigantyczne dokumenty. Standardowe narzędzia do retrievalu często dławią się przy dużych plikach, ale Tenant Graph Grounding obsługuje pliki o rozmiarze do 512 megabajtów. Kiedy pracownik pyta o bardzo specyficzny scenariusz, na przykład o politykę urlopów rodzicielskich dla drugiego opiekuna pracującego na pół etatu, tradycyjna wyszukiwarka szuka dokładnie tych słów. Jeśli podręcznik używa innych sformułowań, wyszukiwanie zawodzi.
I tu jest kluczowa sprawa. Ponieważ ta funkcja korzysta z Semantic Index, mapuje relacje koncepcyjne między zapytaniem użytkownika a danymi firmowymi. Rozumie, że zapytanie o urlop rodzicielski mapuje się koncepcyjnie na sekcję zatytułowaną czas wolny dla rodziny, nawet jeśli słowa kluczowe nie pokrywają się idealnie.
Cały flow logiki działa całkowicie w obrębie bezpiecznych granic twojego tenanta. Użytkownik wysyła prompt do copilota. Copilot używa tokenu Entra ID tego konkretnego użytkownika, aby odpytać Microsoft Graph. Następnie Microsoft Graph przeszukuje Semantic Index, ale bierze pod uwagę tylko te pliki, do których dany użytkownik ma już uprawnienia do odczytu. Jeśli dostęp do dokumentu jest ograniczony, Graph po prostu go ignoruje dla tego użytkownika.
Graph pobiera wysoce trafne dopasowania semantyczne i zwraca je do copilota. Następnie copilot używa dokładnie tych chunków danych, aby wygenerować precyzyjną, ugruntowaną odpowiedź. Cała transakcja odbywa się z niemal natychmiastową precyzją, omijając opóźnienia i niedokładności związane z próbami budowania własnych, customowych indeksów wyszukiwania na danych z SharePointa.
Tenant Graph Grounding przenosi cały ciężar retrievalu z twojej customowej logiki bezpośrednio na infrastrukturę semantyczną Microsoft 365, gwarantując, że twój copilot respektuje istniejące granice danych firmowych, zapewniając jednocześnie niezrównaną dokładność kontekstową. Jeśli chcesz wesprzeć podcast, znajdziesz DevStoriesEU na Patreon. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!
8
Prompt Tools
3m 54sDaj swojemu agentowi możliwość wykonywania określonych zadań przetwarzania danych lub podsumowywania w locie. Dowiedz się, jak tworzyć Prompt Tools, definiować szablony, określać inputs i ustawiać formaty odpowiedzi bezpośrednio w Copilot Studio.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 8 z 15. Czasami nie musisz budować skomplikowanego API ani integrować zewnętrznego serwisu do parsowania, żeby przetworzyć przychodzące dane. Wystarczy ci large language model, który spojrzy na chaotyczny string tekstu i przetworzy go dokładnie tak, jak chcesz. I tu do gry wchodzą Prompt Tools.
Najpierw musimy wyjaśnić jedną częstą wątpliwość. Prompt Tools to coś zupełnie innego niż Generative Answers. Generative Answers skanują zewnętrzną bazę wiedzy albo stronę internetową, żeby dynamicznie odpowiadać na pytania użytkowników. Prompt Tools nie szukają odpowiedzi. To konkretne, mocno dopracowane instrukcje, które mówią large language modelowi, żeby wykonał ściśle zdefiniowane zadanie na danych, które mu dostarczysz.
Pomyśl o Prompt Tool jak o funkcji wielokrotnego użytku, w której logika pod spodem jest napisana w języku naturalnym zamiast w kodzie. Budujesz go, definiując prompt template, określając input variables i dostarczając ścisłe reguły kontekstowe.
Weźmy pod uwagę typowy scenariusz. Dostajesz blok nieustrukturyzowanego, chaotycznego feedbacku od klienta. Chcesz wyciągnąć z niego sentyment i wygenerować czystą listę konkretnych action items. Zamiast pisać skomplikowane regular expressions albo własny skrypt do parsowania, tworzysz Prompt Tool.
Zaczynasz od zdefiniowania inputów. W Copilot Studio tworzysz input variable o nazwie feedback text i ustawiasz jej typ danych. Ten prosty krok mówi narzędziu, żeby oczekiwało dynamicznego stringa za każdym razem, gdy jest wywoływane przez system.
Następnie piszesz prompt template. To główny zestaw instrukcji wysyłany do language modela. Rozpisujesz dokładnie, co model musi zrobić. Instruujesz go, żeby odczytał zmienną feedback text, określił, czy ton jest pozytywny, negatywny, czy neutralny, i zidentyfikował wszystkie zadania, którymi musi zająć się zespół supportu na podstawie tego tekstu.
I tu jest kluczowa sprawa. Ten template jest praktycznie bezużyteczny bez ścisłego kontekstu. Nie pytasz po prostu modelu o sentyment, licząc na ładną odpowiedź. Definiujesz dokładną strukturę outputu w kontekście prompta. Wyraźnie instruujesz model, żeby zwrócił wynik sformatowany jako ścisły obiekt JSON, zawierający klucz sentiment i array z action items. Zabraniasz dodawania konwersacyjnych wypełniaczy. Ten kontekst przekształca ogólną, gadatliwą odpowiedź language modela w przewidywalny, ustrukturyzowany payload danych, który twoje downstream systems mogą faktycznie sparsować.
Kiedy twój agent triggeruje to narzędzie podczas rozmowy na żywo, execution flow jest całkowicie zautomatyzowany. Agent bierze odpowiedź klienta na żywo i przekazuje ją do twojego inputu feedback text. Narzędzie dynamicznie wstrzykuje ten string do twojego template'u, wysyła kompletny pakiet instrukcji do modelu i zwraca ustrukturyzowanego JSON-a. Agent może następnie użyć tych wyciągniętych action items, żeby automatycznie zaktualizować bazę danych albo przekierować użytkownika do specjalistycznej kolejki supportu.
Definiujesz to narzędzie raz, a agent wywołuje je automatycznie za każdym razem, gdy rozpozna potrzebę przetworzenia nieustrukturyzowanego tekstu. Dobrze zaprojektowany Prompt Tool przenosi ciężar skomplikowanego przetwarzania tekstu z kodu twojej aplikacji na language model, pozwalając ci wyciągnąć idealnie ustrukturyzowane dane z kompletnego chaosu, używając tylko kilku linijek zwykłego angielskiego. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!
9
Agent Flows
3m 56sPołącz Copilot Studio ze złożonymi, wieloetapowymi automatyzacjami backendowymi za pomocą Agent Flows. Ten odcinek szczegółowo opisuje, jak dodawać przepływy Power Automate jako tools, kładąc nacisk na krytyczny limit 100 sekund na wykonanie oraz wymagania dotyczące odpowiedzi synchronicznych.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 9 z 15. Twój agent musi wykonać skomplikowany backendowy workflow obejmujący wiele systemów. Może musi jednocześnie odpytać odizolowaną bazę danych, przefiltrować dane i zaktualizować system magazynowy. Pojedynczy API call nie poradzi sobie z taką orkiestracją. Rozwiązaniem jest Agent Flow.
Agent Flows łączą Copilot Studio z Power Automate. Umożliwiają ci opakowanie wieloetapowej automatyzacji w samodzielne narzędzie, które twój agent może autonomicznie ztriggerować. Agent w pełni polega na nazwie i opisie, które podasz dla tego flow. Na podstawie tego tekstu agent decyduje, czy dany flow może rozwiązać obecny request użytkownika. Gdy znajdzie dopasowanie, agent wyciąga niezbędne parametry z konwersacji, przekazuje je do flow, czeka na wykonanie i używa końcowego outputu do wygenerowania odpowiedzi.
Struktura Agent Flow jest ściśle określona. Musi zaczynać się od konkretnego triggera zaprojektowanego dla Copilota, który jawnie definiuje inputy tekstowe lub liczbowe. Musi kończyć się konkretną akcją, która zwraca odpowiedź do Copilota, definiując outputy tekstowe lub liczbowe. Wszystko pomiędzy tymi dwoma nodami to standardowa logika Power Automate. Możesz iterować po arrayach, wywoływać custom connectory albo parsować pliki.
Wyobraź sobie scenariusz, w którym twój agent musi pobrać historię zamówień z bazy SQL typu legacy. Użytkownik pyta o swoje ostatnie zamówienia. Agent triggeruje flow, przekazując string z ID klienta jako input. Wewnątrz flow budujesz logikę, która łączy się z bazą SQL, wykonuje query i formatuje surowe wiersze z bazy w czystego stringa JSON. Następnie flow przekazuje tego sformatowanego stringa z powrotem do agenta przez response node. Agent odczytuje stringa, wyciąga szczegóły zamówienia i odpowiada użytkownikowi w języku naturalnym.
Oto kluczowa kwestia. Wykonanie musi być w pełni synchroniczne. Agent inicjuje flow i utrzymuje otwarte połączenie, czekając na odpowiedź. Jeśli zbudujesz asynchroniczny flow, nie zadziała on jako agent tool. Nie możesz dodawać kroków, które pauzują logikę. Jeśli twój flow wysyła maila z prośbą o akceptację i czeka, aż człowiek kliknie przycisk, agent się wywali. Tool pattern wymaga natychmiastowego zwrócenia danych.
To prowadzi nas do twardego limitu systemowego. Masz dokładnie sto sekund. Od momentu, gdy agent ztriggeruje flow, logika ma sto sekund na wykonanie każdego kroku, odpytanie bazy danych, sformatowanie outputu i odesłanie odpowiedzi. Jeśli serwer legacy SQL jest obciążony, albo twój flow iteruje po zbyt wielu rekordach, wykonanie przekroczy timeout. Kiedy to się stanie, agent całkowicie zrywa połączenie i zwraca użytkownikowi komunikat o błędzie.
Aby poradzić sobie z tym limitem, musisz utrzymać wąski scope automatyzacji. Jeśli proces na backendzie zajmuje pięć minut, nie uruchamiaj go wewnątrz Agent Flow. Zamiast tego, użyj flow, żeby odpalić zewnętrznego background joba i natychmiast zwrócić agentowi tracking ID.
Architektura twojej automatyzacji musi respektować okno timeoutu. Projektuj swoje flowy tak, aby wykonywały się szybko, pobierały dokładnie to, czego potrzebujesz, i zwracały kontrolę do agenta, upewniając się, że użytkownik nigdy nie zostanie z zawieszonym połączeniem.
To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!
10
Power Platform Connectors
3m 59sSkorzystaj z tysięcy istniejących API w ekosystemach Microsoft i firm trzecich. Odkryj, jak używać Power Platform Connectors jako aktywnych tools w Twoich agentach Copilot Studio, aby bez wysiłku wchodzić w interakcje z zewnętrznymi usługami.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 10 z 15. Spędzasz dni na pisaniu i utrzymywaniu customowych integracji API, tylko po to, żeby twój agent mógł komunikować się ze światem zewnętrznym. Tymczasem tysiące gotowych wrapperów już siedzi w twoim środowisku, czekając na odpalenie. Dzisiaj przyjrzymy się Power Platform Connectors.
Konektory to ustandaryzowane wrappery API. Zapewniają przewidywalny sposób na komunikację Microsoft Copilot Studio z zewnętrznymi serwisami. Zanim sprawdzimy, jak działają, musimy wyjaśnić jedno powszechne nieporozumienie. Użytkownicy często mylą wykorzystanie zewnętrznego systemu jako źródła wiedzy z używaniem go jako narzędzia. Jeśli twój agent odpytuje bazę danych tylko po to, żeby wyciągnąć fakty i oprzeć na nich swoje odpowiedzi, to jest to wiedza pasywna. Użycie konektora jako narzędzia to zupełnie co innego. To aktywna operacja. Dajesz agentowi uprawnienia do wykonywania akcji, tworzenia rekordów lub triggerowania zewnętrznych procesów w imieniu użytkownika.
Dostępne są trzy kategorie konektorów. Standardowe konektory pokrywają podstawowe usługi Microsoftu i popularne publiczne endpointy. Konektory premium wymagają odpowiedniej licencji i łączą się z systemami enterprise, takimi jak Salesforce czy ServiceNow. Jeśli system, do którego musisz się dobić, to wewnętrzne, autorskie API, możesz zbudować customowy konektor. Customowy konektor to po prostu wrapper OpenAPI, który definiujesz sam. Po zarejestrowaniu w twoim środowisku, zachowuje się dokładnie tak samo jak te standardowe i premium. Agenta nie obchodzi, kto go zbudował.
Zobaczmy, jak ta logika działa w konkretnym scenariuszu. Chcesz, żeby twój agent zebrał podsumowanie projektu i wysłał je mailem do twojego zespołu inżynierów. Zamiast ręcznie budować request HTTP, dodajesz konektor Office 365 Outlook bezpośrednio do swojego copilota jako akcję. Każdy konektor wystawia konkretne operacje. W tym przypadku wybierasz akcję wysłania maila.
I to jest ta najważniejsza część. Nie piszesz proceduralnego kodu, żeby dyktować dokładnie, kiedy ten mail ma wyjść. Zamiast tego definiujesz parametry, których konektor potrzebuje do działania. Konektor Outlook potrzebuje adresu docelowego, tematu i treści. Konfigurujesz te inputy i dostarczasz jasny opis w naturalnym języku, mówiący o tym, co robi ta akcja.
Copilot polega całkowicie na tym opisie, żeby ustalić, kiedy ztriggerować to narzędzie. Kiedy użytkownik każe agentowi wysłać cotygodniowy update statusu do zespołu inżynierów, agent ewaluuje swoje dostępne narzędzia. Dopasowuje request użytkownika do opisu twojego konektora Outlook. Następnie agent dynamicznie wyciąga nazwę odbiorcy i tekst podsumowania z trwającej konwersacji. Mapuje te wyciągnięte wartości na inputy konektora i odpala akcję.
Kiedy zewnętrzne API przetworzy request, konektor przekazuje odpowiedź z powrotem do agenta. Może to być prosty kod sukcesu albo payload ze szczegółowymi informacjami o transakcji. Agent odbiera te dane, weryfikuje, czy akcja została zakończona, i generuje odpowiedź w języku naturalnym, informując użytkownika, że mail został wysłany.
Dzięki standaryzacji interfejsu, te wrappery eliminują potrzebę zarządzania tokenami uwierzytelniającymi, headerami i error handlingiem dla każdego serwisu z osobna. Konfigurujesz połączenie raz, a agent orkiestruje wykonanie. Konektory zmieniają twojego agenta ze statycznego interfejsu konwersacyjnego w operacyjne narzędzie, które faktycznie zmienia stan w twojej infrastrukturze. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!
11
Computer Use Tool
3m 53sAutomatyzuj starsze systemy, które nie mają API, za pomocą automatyzacji opartej na wizji. Odkryj narzędzie Computer Use Tool w wersji preview, które wykorzystuje modele takie jak Claude Sonnet 4.5 do interakcji z graficznymi interfejsami użytkownika za pomocą wirtualnej myszy i klawiatury, wraz z firmowymi zabezpieczeniami.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 11 z 15. Jeśli aplikacja nie ma API, tradycyjna automatyzacja odbija się od ściany. Albo piszesz niestabilne skrypty, które wysypują się, gdy tylko przycisk zmieni miejsce, albo godzisz się na ręczne wprowadzanie danych. Narzędzie Computer Use rozwiązuje ten problem, pozwalając twojemu AI dosłownie widzieć ekran i samodzielnie obsługiwać maszynę.
Ta funkcja, dostępna w wersji preview, pozwala twojemu agentowi na interakcję z graficznym interfejsem użytkownika za pomocą wirtualnej myszy i klawiatury. Opiera się na Computer-Using Agents, napędzanych przez modele wizyjne, takie jak Claude 3.5 Sonnet od Anthropic. Musimy sobie wyjaśnić, czym to nie jest. To nie jest tradycyjne Robotic Process Automation. Standardowe RPA opiera się na strukturalnych hookach, takich jak tagi DOM czy ID elementów UI. Narzędzie Computer Use operuje wyłącznie na pikselach.
Flow logiki to ciągła pętla. Narzędzie robi zrzut ekranu środowiska desktopowego i przekazuje go do modelu. Model analizuje layout wizualny, wnioskuje na temat żądania użytkownika i oblicza dokładne współrzędne swojego kolejnego ruchu. Następnie zwraca instrukcje z powrotem do systemu. System tłumaczy je na przesunięcie wirtualnego kursora na konkretną pozycję X i Y, kliknięcie przyciskiem myszy lub wysłanie stringa z sekwencją klawiszy. Po wykonaniu akcji, narzędzie robi kolejny zrzut ekranu, aby ocenić nowy stan interfejsu. Weryfikuje, czy otworzyło się okno albo czy pojawił się tekst, zanim zdecyduje o kolejnym kroku.
Wyobraź sobie scenariusz, w którym musisz wyciągnąć dane z desktopowej aplikacji legacy na Windowsa i wprowadzić je do nowoczesnego formularza webowego. Agent patrzy na zrzut ekranu aplikacji legacy, wizualnie lokalizuje numer faktury i zapisuje tę informację. Następnie zwraca instrukcje, żeby przesunąć myszkę na okno przeglądarki, kliknąć w docelowe pole formularza webowego i wpisać cyfry. Nawiguje po interfejsie dokładnie tak, jak zrobiłby to człowiek, kierując się wyłącznie kontekstem wizualnym na ekranie.
Oddanie modelowi AI fizycznej kontroli nad desktopem wymaga rygorystycznych kontroli bezpieczeństwa. I tu pojawia się kluczowa kwestia. Nigdy nie deployujesz tego na serwerze produkcyjnym ani na głównej stacji roboczej użytkownika. Agent musi działać w dedykowanej, odizolowanej maszynie wirtualnej lub kontenerze. Nadajesz temu środowisku absolutne minimum uprawnień potrzebnych do wykonania konkretnego zadania. Ponieważ model potrafi samodzielnie nawigować po przeglądarkach webowych, musisz wymusić rygorystyczne kontrole sieciowe. Stosujesz allowlistę adresów URL, żeby agent miał dostęp tylko do zatwierdzonych domen, co powstrzyma go przed interakcją z niezaufanymi stronami czy zewnętrznymi serwisami. Upewniasz się też, że maszyna wirtualna nie przechowuje żadnych wrażliwych danych poza tymi niezbędnymi do bieżącego workloadu.
Traktując graficzny interfejs użytkownika po prostu jako kolejny wizualny strumień wejściowy, zasypujesz przepaść między inteligentnym wnioskowaniem a niedostępnym oprogramowaniem legacy, bez pisania choćby jednej linijki kodu integracyjnego. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!
12
User Authentication
3m 34sZabezpiecz swojego agenta i odblokuj spersonalizowane doświadczenia. Zanurz się w User Authentication w Copilot Studio, porównując opcję 'Authenticate with Microsoft' z ręcznymi konfiguracjami Manual OAuth2. Dowiedz się, jak konfigurować scopes i zapewnić dostęp na zasadzie najmniejszych uprawnień.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 12 z 15. Agent jest tylko tak potężny, jak dane, do których ma dostęp. Jeśli jednak twój agent odpyta prywatny system i przypadkowo udostępni twój osobisty kalendarz zupełnie innemu pracownikowi, masz ogromną lukę w bezpieczeństwie. Aby temu zapobiec, musisz poprawnie skonfigurować User Authentication.
Najczęstszym błędem popełnianym tutaj przez programistów jest mylenie credentials dostarczonych przez twórcę z credentials end-usera. Jeśli zaszyjesz własne API keys lub credentials service principala w akcji agenta, bot wykona te akcje jako ty. Każda osoba czatująca z agentem ominie swoje limity bezpieczeństwa i uzyska dostęp do danych, używając twoich uprawnień. User Authentication wymusza na agencie wykonywanie zapytań dokładnie jako osoba wpisująca prompt, opierając się całkowicie na jej unikalnej tożsamości.
W Copilot Studio wybierasz głównie między dwoma stanami autentykacji: Authenticate with Microsoft oraz Authenticate manually. Authenticate with Microsoft to uproszczona ścieżka dla wewnętrznych narzędzi. Jeśli twój agent działa wyłącznie wewnątrz Microsoft Teams lub Power Apps, to ustawienie automatycznie używa tokena Microsoft Entra ID osoby aktualnie zalogowanej do aplikacji. Nie ma osobnego okienka logowania. Kontekst użytkownika po prostu przepływa do agenta.
Przełączasz się na Authenticate manually, gdy twój agent działa na customowej zewnętrznej stronie internetowej lub gdy potrzebujesz ścisłej, granularnej kontroli nad uprawnieniami. Ta metoda opiera się na skonfigurowaniu połączenia OAuth2 z identity providerem, którym zazwyczaj jest App Registration w Microsoft Entra ID.
Weźmy konkretny scenariusz. Budujesz agenta, który sprawdza osobisty harmonogram pracownika. Konfigurujesz Authenticate manually i łączysz je ze swoim App Registration w Entra ID. Oto najważniejsze. Agent nie dostaje całkowitego dostępu do całego konta Microsoft użytkownika. Zamiast tego definiujesz ścisłe scope'y w swojej konfiguracji. Konfigurujesz node autentykacji tak, aby żądał konkretnego scope'a o nazwie Calendars dot Read.
Gdy użytkownik pyta agenta o swój harmonogram, agent pauzuje swoją logikę i wyświetla kartę logowania na czacie. Użytkownik klika link, autentykuje się w przeglądarce i widzi ekran z prośbą o udzielenie agentowi dostępu do odczytu kalendarza. Gdy wyrazi zgodę, Microsoft Entra ID generuje access token i bezpiecznie przekazuje go z powrotem do agenta.
Ten access token jest ściśle powiązany z tym konkretnym użytkownikiem i ograniczony wyłącznie do scope'a kalendarza. Kiedy agent wykonuje właściwy HTTP request, aby pobrać harmonogram, dołącza do niego ten token. Backend API sprawdza token, potwierdza tożsamość użytkownika i bezpiecznie zwraca tylko jego konkretne wydarzenia z kalendarza. Prawidłowe skonfigurowanie User Authentication to coś, co przekształca generycznego chatbota w spersonalizowanego asystenta, udowadniając twoim systemom backendowym, kto dokładnie prosi o dane, dzięki czemu nigdy nie wyciekną ci prywatne informacje między sesjami.
Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.
13
Voice i IVR
3m 53sPrzenieś swojego agenta z klawiatury na linię telefoniczną. Odkryj możliwości Interactive Voice Response (IVR) w Copilot Studio. Dowiedz się o rozpoznawaniu mowy, DTMF, funkcji barge-in oraz dostosowywaniu głosów agentów za pomocą SSML.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 13 z 15. Przyszłość obsługi klienta to nie tylko tekst na ekranie. Ludzie nadal dzwonią na linie wsparcia, a kiedy to robią, oczekują natychmiastowej, inteligentnej odpowiedzi, a nie niekończącego się drzewa menu. Wypełnienie tej luki wymaga bezpośredniego podłączenia twojego AI do sieci telefonicznych. Właśnie tym zajmiemy się dzisiaj: Voice i IVR.
Aby agent zbudowany w Copilot Studio mógł odbierać telefony, musisz skonfigurować go dla kanału telefonicznego, zazwyczaj przez Dynamics 365 lub Azure Communication Services. To przekształca twoją logikę w system Interactive Voice Response, polegający na natywnym speech recognition do konwersji audio dzwoniącego na tekst oraz silnikach text-to-speech do odpowiadania. Jednak przełożenie logiki czatu na logikę voice wymaga obsłużenia fizycznych realiów rozmowy telefonicznej.
Pomyśl o kliencie dzwoniącym na linię wsparcia. Bot odbiera i zaczyna czytać wymagane prawnie powitanie lub listę opcji. Dzwoniący już wie, że potrzebuje działu rozliczeń. Gdyby to był czat tekstowy, po prostu wpisałby swoje pytanie. Przez telefon, zaczyna mówić, przerywając botowi. To wymaga funkcji o nazwie Barge-in. Bez włączonego Barge-in, system ignoruje przychodzące audio, dopóki bot całkowicie nie skończy odtwarzania. Z aktywnym Barge-in, speech recognizer nasłuchuje równolegle. W momencie, gdy wykryje, że użytkownik mówi, natychmiast zatrzymuje output text-to-speech bota i przetwarza przychodzące audio. To replikuje naturalny flow ludzkiej rozmowy i sprawia, że dzwoniący nie czują się uwięzieni przez maszynę.
Po przerwaniu botowi, dzwoniący jest proszony o podanie numeru konta. Mógłby wypowiedzieć cyfry na głos, ale może jest w zatłoczonym pomieszczeniu. Zamiast tego, wstukuje cyfry na ekranie. To prowadzi nas do DTMF, czyli Dual-Tone Multi-Frequency. Ludzie często mylą obsługę DTMF ze standardowymi inputami tekstowymi, ale to zupełnie oddzielne mechanizmy. DTMF obsługuje interakcje z klawiaturą telefonu globalnie w całej sieci telefonicznej. Kiedy dzwoniący naciska klawisz, sieć wysyła ton o określonej częstotliwości. Copilot Studio przechwytuje te tony bezpośrednio. Konfigurujesz input node'y, aby nasłuchiwały sekwencji DTMF, wyciągasz z nich cyfry i zapisujesz je jako zmienne. Możesz wymusić maksymalną liczbę cyfr, ustawić timeouty i zdefiniować znak kończący, na przykład instruując użytkownika, żeby wcisnął krzyżyk, gdy skończy wpisywać.
Oto kluczowa kwestia. Samo przechwytywanie inputu to za mało; sposób, w jaki twój agent odpowiada, decyduje o tym, czy dzwoniący się rozłączy. Domyślny text-to-speech może brzmieć płasko. Żeby to naprawić, używasz SSML, czyli Speech Synthesis Markup Language. Zamiast wysyłać plain text do silnika głosowego, owijasz swoje odpowiedzi w tagi. SSML pozwala ci kontrolować pitch, dostosowywać tempo mówienia i wymuszać konkretną wymowę. Jeśli nazwa twojej firmy to akronim, możesz użyć SSML, żeby wymusić na silniku przeliterowanie jej, zamiast zgadywania, jak brzmi jako słowo. Możesz wstawiać precyzyjne pauzy, dodając półsekundową przerwę po skomplikowanej instrukcji, żeby pozwolić dzwoniącemu przetworzyć informacje.
Budowanie rozwiązań voice wymaga traktowania linii telefonicznej jako unikalnego interfejsu, uwzględniającego przerwy, tony klawiatury i tempo audio. Najskuteczniejsi agenci voice nie zmuszają użytkowników do sztywnych menu audio; łączą płynny Barge-in i precyzyjną obsługę DTMF, żeby po prostu nie wchodzić dzwoniącemu w drogę. Dzięki, że słuchasz. Do następnego razu!
14
Agent Analytics
3m 19sNie możesz ulepszyć tego, czego nie mierzysz. Ten odcinek szczegółowo omawia pulpit nawigacyjny Analytics w Copilot Studio, wyjaśniając widok hybrydowy dla sesji konwersacyjnych i autonomicznych oraz sposób eksportowania transkrypcji do głębokiej analizy.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 14 z 15. W końcu robisz deploy swojego agenta, testujesz go i wszystko wygląda idealnie. Tydzień później zadowolenie użytkowników spada, a procesy w tle padają po cichu. Problemem nie jest twój początkowy build, ale brak wglądu w to, jak zachowuje się na produkcji. Narzędziem, które to naprawi, jest Agent Analytics.
Agent Analytics daje ci ujednolicony widok na to, jak twój agent radzi sobie z prawdziwym ruchem. Pierwsze, co widzisz, to strona Summary. Działa ona jak centrum dowodzenia. Agreguje kluczowe wskaźniki, takie jak całkowita liczba sesji, engagement rate, resolution rate i escalation rate. Zamiast zgadywać, czy twój agent pomaga użytkownikom, AI insights na stronie Summary analizują intencje użytkowników i pokazują ci dokładnie, które tematy prowadzą do rozwiązania problemu, a które sprawiają, że użytkownicy porzucają sesję lub proszą o połączenie z człowiekiem.
Oto kluczowy wniosek. Copilot Studio śledzi dwa zupełnie różne typy sesji, a dashboard prezentuje je w widoku hybrydowym. Po pierwsze, masz sesje konwersacyjne. Są dokładnie tym, na co wskazuje nazwa. Użytkownik otwiera okno czatu i wymienia wiadomości z agentem. Analityka śledzi tury dialogu, sentyment użytkownika i triggerowanie tematów. Po drugie, masz sesje autonomiczne. Działają one całkowicie w tle. Są triggerowane przez zewnętrzne eventy, takie jak utworzenie nowego rekordu w bazie danych albo przychodzący e-mail, a nie przez użytkownika wpisującego wiadomość. Nie ma tu interfejsu czatu. Analityka śledzi, czy agent pomyślnie wykonał swoją logikę w tle, czy trafił na błąd.
Potrzebujesz obu tych widoków, żeby utrzymać agenta w dobrej kondycji. Wyobraź sobie scenariusz, w którym przeglądasz ten hybrydowy dashboard. Twoje metryki konwersacyjne wyglądają dobrze, ale zauważasz nagły skok failure rate. Filtrowanie po typie sesji ujawnia, że wszystkie błędy występują w sesjach autonomicznych. Proces triggerowany eventem, który ma aktualizować statusy zamówień, failuje w tle. Dashboard Summary mówi ci, że wystąpił błąd, ale nie podaje dokładnej linijki logiki, która go spowodowała.
W tym momencie przechodzisz z dashboardu do surowych danych. Copilot Studio przechowuje szczegółowe logi z wykonania w Microsoft Dataverse jako transkrypty. Pobierasz konkretny transkrypt dla sesji autonomicznej, która zfailowała. Czytając transkrypt, dostajesz trace z wykonania krok po kroku. Możesz zobaczyć dokładną zmienną, która przekazała nieprawidłową wartość, namierzyć failujący node i naprawić logikę bez konieczności ślepego odtwarzania błędu.
Dashboard mówi ci, gdzie szukać, ale transkrypt mówi ci, co naprawić. Jeśli chcesz pomóc w tworzeniu kolejnych takich technicznych analiz, możesz wesprzeć program, wyszukując DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i twórz dalej!
15
Model Context Protocol
4m 11sZabezpiecz swoich agentów na przyszłość dzięki otwartemu standardowi dla kontekstu AI. Dowiedz się, jak zintegrować Copilot Studio z zewnętrznymi serwerami Model Context Protocol (MCP), aby dynamicznie pobierać Resources, Tools i Prompts.
Cześć, tu Alex z DEV STORIES DOT EU. Microsoft Copilot Studio, odcinek 15 z 15. Spędzasz tygodnie na tworzeniu customowych pluginów, żeby twój agent mógł odpytywać wewnętrzne bazy danych i triggerować akcje. Potem startuje nowa platforma i musisz przepisywać dokładnie te same integracje od zera. Rozwiązaniem tego niekończącego się cyklu nadmiarowej pracy jest Model Context Protocol.
Model Context Protocol, czyli MCP, to otwarty standard, który łączy modele AI z zewnętrznymi źródłami danych i toolsami. Wdrażając otwarty standard, skutecznie zabezpieczasz swoich agentów na przyszłość. Logikę integracji piszesz dokładnie raz, hostujesz ją na serwerze MCP, a każdy kompatybilny klient AI może z niej od razu korzystać. Copilot Studio działa właśnie jako jeden z takich klientów.
Wyobraź sobie scenariusz, w którym twój zespół inżynierów polega na 50 różnych wewnętrznych skryptach diagnostycznych i plikach logów w czasie rzeczywistym. Nie chcesz ręcznie tworzyć i mapować 50 osobnych akcji w Copilot Studio. Zamiast tego konfigurujesz agenta tak, aby łączył się bezpośrednio z waszym własnym, wewnętrznym serwerem MCP. Kiedy agent się inicjalizuje, pyta serwer, co może zrobić. Serwer odpowiada listą możliwości, od razu dając agentowi dostęp do wszystkich 50 toolsów inżynieryjnych i zasobów plików live.
Serwer MCP udostępnia twojemu agentowi trzy główne komponenty. Są to Resources, Tools oraz Prompts. Resources to źródła danych tylko do odczytu. Kiedy twój agent musi sprawdzić plik konfiguracyjny live albo rekord w bazie danych, serwer MCP dostarcza te dane jako resource, ładując je bezpośrednio do kontekstu modelu. Tools to funkcje wykonywalne. Jeśli agent zdecyduje, że musi zrestartować maszynę wirtualną albo zaktualizować ticket inżynieryjny, wywołuje odpowiedni tool MCP, a zewnętrzny serwer wykonuje akcję. Prompts to predefiniowane szablony instrukcji dostarczane przez serwer. Instruują one agenta, jak dokładnie formatować zapytania albo interpretować dane specyficzne dla tego zewnętrznego systemu.
I tu jest kluczowa sprawa. Ludzie często zakładają, że kiedy podłączasz serwer MCP, Copilot Studio importuje i zapisuje na stałe kopie tych toolsów w swoim własnym interfejsie użytkownika. To tak nie działa. Tools oraz resources są hostowane całkowicie na zewnątrz. Copilot Studio dynamicznie odczytuje to, co serwer wystawia podczas runtime'u. Jeśli twój zespół inżynierów doda pięćdziesiąty pierwszy tool diagnostyczny albo zmodyfikuje parametry istniejącego skryptu, po prostu aktualizuje zewnętrzny serwer MCP. Copilot Studio automatycznie odzwierciedla te zmiany. Nigdy nie musisz logować się do interfejsu Studio, żeby zrepublishować albo zaktualizować akcję.
Ponieważ logika żyje w całości na serwerze, utrzymujesz single source of truth dla danych i akcji w twojej organizacji. Agent pozostaje lekki, działając jedynie jako silnik wnioskujący, który decyduje, kiedy skomunikować się z serwerem.
Oddzielając swoje tools od konkretnej platformy agenta, centralizujesz integracje i gwarantujesz, że twoje AI zawsze ma najnowsze możliwości, niezależnie od tego, jaki interfejs klienta zdeployujesz. Gorąco zachęcam cię do przeczytania oficjalnej dokumentacji, samodzielnego spróbowania podłączenia serwera MCP, albo odwiedzenia DEV STORIES DOT EU, żeby zasugerować tematy, które chcesz zobaczyć w przyszłej serii. To wszystko w tym odcinku. Dzięki za wysłuchanie i koduj dalej!