Każdy może zbudować agenta AI. Trudności zaczynają się po konfiguracji
Microsoft Source opublikował prosty przewodnik po agentach AI, mimo że technologia ta przeszła od odpowiadania na pytania do wykonywania działań o istotnych konsekwencjach. Artykuł przedstawia tworzenie agentów jako dostępny proces oparty na celach, instrukcjach, wiedzy, narzędziach i testowaniu. Takie ujęcie obniża barierę wejścia, ale tworzy też nowy problem. Zbudowanie demonstracji staje się łatwiejsze niż udowodnienie, że agent zasługuje na rzeczywiste uprawnienia.
Przewodnik pojawia się w czasie, gdy Microsoft rozszerza możliwości tworzenia agentów w Microsoft 365 Copilot i Copilot Studio. Użytkownik może opisać agenta językiem naturalnym, połączyć go z informacjami organizacyjnymi, dodać działania i przetestować wynik. Podejście Microsoftu umieszcza tworzenie agentów w oprogramowaniu, z którego korzysta już wiele firm.
Prawdziwa rywalizacja nie toczy się między Microsoftem a innym dostawcą modeli. Chodzi o proste tworzenie kontra niezawodność operacyjną. Microsoft Source może pokazać niemal każdemu, jak złożyć agenta, lecz wykorzystanie produkcyjne wymaga uprawnień, ewaluacji, monitorowania i rozliczalnych decyzji podejmowanych przez ludzi.
Microsoft Source przedstawia budowanie agentów jako konfigurację
Najważniejsza zmiana polega na tym, że Microsoft przedstawia dziś tworzenie agentów jako zadanie konfiguracyjne, od którego mogą zacząć osoby niebędące programistami.
Agent AI to oprogramowanie, które wykorzystuje model do interpretacji celu, wyboru informacji lub narzędzi oraz wykonania jednego lub większej liczby działań. Podstawowy chatbot generuje odpowiedź. Agent może zdecydować, jaki krok wykonać dalej, i współdziałać z innym systemem.
Przewodnik Microsoft Source porządkuje tę ideę dla szerokiego grona odbiorców. Jego tytuł wyraźnie sygnalizuje zamierzoną zmianę. Budowanie agenta nie powinno już wyglądać na zajęcie zarezerwowane dla badaczy lub wyspecjalizowanych zespołów inżynieryjnych.
Ten przekaz odpowiada obecnemu kierunkowi rozwoju produktów Microsoftu. Microsoft 365 Copilot obejmuje Agent Builder do lekkich agentów tworzonych za pomocą opisów w języku naturalnym. Copilot Studio zapewnia większą kontrolę nad przepływami pracy, integracjami, wdrożeniem, analityką i zarządzaniem.
Nowsze środowisko Copilot Studio firmy Microsoft umieszcza instrukcje i połączone komponenty na jednej powierzchni tworzenia. Twórcy mogą definiować zachowanie agenta, łączyć źródła wiedzy, dodawać narzędzia, wybierać model i ustawiać ograniczenia. Karta Build platformy obsługuje także pamięć i połączonych agentów.
Zmienia to pierwszy etap rozwoju. Użytkownik biznesowy nie musi już zaczynać od architektury aplikacji ani zbioru wywołań API. Może zacząć od opisania pożądanego rezultatu zwykłym językiem.
Weźmy pracownika, który potrzebuje cotygodniowej aktualizacji projektu. Agent może przeszukać zatwierdzone dokumenty, wskazać ostatnie decyzje, podsumować otwarte ryzyka i przygotować raport. Taki projekt nadal obejmuje kilka komponentów, ale początkowa specyfikacja może wyglądać jak jasne pisemne zadanie.
Tworzenie w języku naturalnym przyspiesza również iterację. Twórca może zawęzić zakres, przepisać instrukcje, dodać źródło wiedzy lub usunąć działanie bez przebudowy całej aplikacji. Szablony oferują kolejny punkt wyjścia dla znanych zadań.
Konfiguracja nie jest jednak równoznaczna z ukończeniem. Pierwsza wersja wyraża jedynie to, co twórca chce, aby agent robił. Nie określa, jak niezawodnie agent będzie interpretował żądania, wybierał dowody, obsługiwał wyjątki ani bezpiecznie się zatrzymywał.
To rozróżnienie ma znaczenie, ponieważ agent łączy probabilistyczne zachowanie modelu z deterministycznymi systemami biznesowymi. Model może generować różne odpowiedzi na podobne dane wejściowe. Połączony system może wykonać każde prawidłowe żądanie dokładnie tak, jak je otrzymał.
Błędny akapit w szkicu jest niewygodny. Błędna instrukcja wysłana do przepływu pracy, bazy danych klientów lub systemu komunikacji niesie ze sobą inny poziom ryzyka. Łatwość tworzenia zwiększa więc znaczenie starannie wyznaczonych granic.
Microsoft skrócił dystans między pomysłem a działającym prototypem. Kolejny dystans, od prototypu do zaufanego wdrożenia, pozostaje znacznie trudniejszy do pokonania.
Dlaczego Microsoft upraszcza agentów właśnie teraz
Microsoft upraszcza tworzenie agentów, ponieważ jego strategia AI dla przedsiębiorstw coraz bardziej zależy od tego, że ludzie delegują przepływy pracy, a nie tylko proszą o wygenerowany tekst.
Firma od kilku lat umieszcza interfejsy Copilot w aplikacjach zwiększających produktywność, deweloperskich, bezpieczeństwa i biznesowych. Agenci rozszerzają tę strategię, nadając tym interfejsom cel, połączoną wiedzę i uprawnienia do działania.
Microsoft Work Trend Index z 2025 roku opisał przyszłość opartą na zespołach ludzi i agentów. Badanie bazowało na danych ankietowych od 31 000 pracowników z 31 rynków, obok sygnałów z Microsoft 365 i LinkedIn. Jego raport roczny przedstawiał agentów jako uczestników zmieniających się struktur pracy.
Ta wizja wymaga większej liczby twórców agentów, niż mogą zapewnić profesjonalni programiści. Każdy dział rozumie własne procesy zatwierdzania, terminologię, źródła danych i powtarzalne zadania. Narzędzia języka naturalnego pozwalają ekspertom dziedzinowym bezpośrednio wyrażać te wymagania.
Specjalista ds. operacji sprzedażowych wie, kiedy lead powinien przejść między etapami. Kierownik wsparcia rozumie, które sprawy wymagają eskalacji. Menedżer produktu wie, gdzie rejestrowane są decyzje, dowody od klientów i ryzyka związane z realizacją.
Użytkownicy ci nadal potrzebują wsparcia technicznego i z zakresu zarządzania. Mogą jednak stworzyć pierwszą użyteczną specyfikację bez przekazywania każdego szczegółu przez osobny zespół deweloperski. Microsoft korzysta na tym, gdy ta specyfikacja pozostaje w jego środowisku oprogramowania.
Strategia odpowiada również na ograniczenie asystentów ogólnego przeznaczenia. Szeroki asystent może dobrze pisać, ale nie rozumie automatycznie wewnętrznych definicji, uprawnień ani procesów firmy. Agent może koncentrować się na jednym zadaniu i korzystać z wybranych zasobów organizacyjnych.
Microsoft rozróżnia swoje dwie główne ścieżki tworzenia. Agent Builder służy osobom i mniejszym grupom, które potrzebują wyspecjalizowanych agentów w Microsoft 365 Copilot. Copilot Studio obsługuje szersze grupy odbiorców, niestandardowe integracje, wieloetapowe przepływy pracy i ściślejsze zarządzanie cyklem życia.
Firmowe porównanie narzędzi do tworzenia wyraźnie przedstawia ten podział. Agent Builder priorytetowo traktuje szybkie, kontekstowe tworzenie, podczas gdy Copilot Studio jest przeznaczone dla bardziej złożonych lub szeroko wdrażanych systemów.
To wielowarstwowe podejście daje Microsoftowi szeroki lejek adopcyjny. Użytkownik może zacząć od wąskiego agenta wiedzy, wykazać, że współpracownicy uznają go za użytecznego, a później skopiować go lub przebudować w Copilot Studio.
Termin odzwierciedla także szerszą zmianę na rynku. IBM, Google, Salesforce, OpenAI, Anthropic i wielu mniejszych dostawców opisuje dziś modele jako komponenty systemów agentowych. Konkurencyjny nacisk przesunął się w stronę narzędzi, orkiestracji, pamięci, ewaluacji i wdrożenia.
Microsoft wchodzi do tej rywalizacji z przewagą w postaci kontekstu przedsiębiorstwa. Wiele organizacji przechowuje już dokumenty w SharePoint, rozmowy w Teams, tożsamości w Entra, a artefakty pracy w całym Microsoft 365.
Ten zasięg nie gwarantuje udanego agenta. Ogranicza jednak liczbę odłączonych systemów, które niektóre firmy muszą zestawić. Microsoft może oferować budowanie agentów jako rozszerzenie istniejącej pracy, a nie odrębne środowisko eksperymentalne.
Presja spada na administratorów platform i liderów biznesowych. Muszą wspierać eksperymenty pracowników, jednocześnie decydując, którym agentom można zapewnić dostęp do wrażliwych danych lub pozwolić wykonywać działania. Proste tworzenie sprawia, że kwestia zarządzania staje się pilna.
Podstawowy mechanizm jest prosty, ale niezawodność nie
Agent potrzebuje celu, instrukcji, kontekstu i narzędzi, lecz niezawodność wynika z kontrolowania sposobu, w jaki te elementy ze sobą współdziałają.
Cel definiuje rezultat. „Pomagaj w sprzedaży” jest zbyt szerokie, ponieważ nie określa jasnego warunku ukończenia. „Przygotuj e-mail z dalszymi krokami na podstawie zatwierdzonych notatek ze spotkania” daje agentowi konkretny wkład, zadanie i wynik.
Instrukcje definiują zasady działania. Mogą określać ton, wymagane dowody, zakazane działania, warunki eskalacji i oczekiwany format odpowiedzi. Dobre instrukcje zmniejszają niejednoznaczność, choć nie eliminują każdej nieoczekiwanej interpretacji.
Kontekst dostarcza agentowi istotnych informacji. Może obejmować dokumenty, rekordy baz danych, wcześniejsze wiadomości lub pobrane fragmenty. Generowanie wspomagane wyszukiwaniem, zwykle nazywane RAG, dostarcza modelowi wybrane informacje zewnętrzne przed wygenerowaniem odpowiedzi.
Narzędzia pozwalają agentowi zrobić coś poza generowaniem tekstu. Narzędzie może sprawdzić stan magazynowy, utworzyć zgłoszenie, zaktualizować rekord, wysłać wiadomość lub wywołać innego agenta. Każde połączenie zamienia decyzję językową w potencjalne działanie systemowe.
Model tworzenia Microsoftu łączy te elementy. Jego dokumentacja podaje, że twórcy mogą łączyć źródła wiedzy, dodawać narzędzia, konfigurować ograniczenia, wybierać model i analizować wynikowe komponenty. Orkiestracja generatywna określa następnie, który dostępny komponent powinien obsłużyć żądanie.
Proces ten tworzy główny kompromis. Jawne przepływy pracy wymagają od twórców wcześniejszego zmapowania rozgałęzień i warunków. Orkiestracja generatywna może obsłużyć bardziej zróżnicowane żądania, lecz jej wybory są mniej przewidywalne.
Wąski agent powinien więc zaczynać od jednego mierzalnego zadania. Twórca może zebrać realistyczne przykłady, zdefiniować akceptowalne wyniki i wskazać warunki wymagające przeglądu przez człowieka. Rozszerzanie zakresu powinno wynikać z dowodów, a nie z entuzjazmu.
Załóżmy, że zespół tworzy agenta do przygotowywania podsumowań odnowienia umów klientów. Agent może pobierać zatwierdzone rekordy kont, podsumowywać ostatnie sprawy wsparcia i przygotowywać pytania dla opiekuna klienta. Wynik pozostaje rekomendacją, dopóki nie przejrzy go człowiek.
Przyznanie temu samemu agentowi uprawnień do zmiany warunków umowy stworzyłoby inny system. Cel, uprawnienia, kryteria ewaluacji i konsekwencje wymagałyby znacznie głębszego przeglądu. Skuteczny agent przygotowujący podsumowania nie kwalifikuje się automatycznie jako agent negocjacyjny.
Jakość wiedzy wprowadza kolejne ograniczenie. Agent oparty na zduplikowanych, nieaktualnych lub sprzecznych dokumentach może udzielać pewnych odpowiedzi na podstawie słabego kontekstu. Podłączenie większej liczby plików niekoniecznie poprawia wynik.
Zespoły potrzebują celowo zaprojektowanej warstwy wiedzy. Muszą wskazać autorytatywne źródła, zarządzać wersjami, zachować użyteczne metadane i ograniczać wyszukiwanie do odpowiednich materiałów. Przepływ pracy knowledge blending może pomóc ludziom uporządkować rozproszony kontekst pracy, zanim zaczną na nim polegać w powtarzalnych zadaniach AI.
Pamięć wymaga podobnej powściągliwości. Trwała pamięć może personalizować agenta lub zachowywać postępy między sesjami. Może także przechowywać nieistotne, wrażliwe lub wprowadzające w błąd szczegóły dłużej, niż zamierzano.
Projektowanie narzędzi staje się jeszcze ważniejsze. Każde narzędzie powinno mieć precyzyjny opis, wąskie uprawnienia, zweryfikowane dane wejściowe i zrozumiałe zachowanie w przypadku błędu. Agent powinien wiedzieć, kiedy użycie narzędzia jest właściwe, a kiedy musi poprosić o zatwierdzenie.
Twórcy potrzebują również idempotencji, co oznacza, że powtórzone żądanie nie tworzy niezamierzonych, zduplikowanych działań. Jeśli przekroczenie limitu czasu sieci ukryje udaną operację, automatyczna ponowna próba nie powinna wysyłać tej samej wiadomości ani ponownie tworzyć tego samego rekordu.
Prosta architektura wciąż pozostaje użyteczna. Cel, instrukcje, wiedza i narzędzia zapewniają początkującym jasny model myślowy. System produkcyjny potrzebuje jednak także uwierzytelniania, autoryzacji, logowania, oceny, odzyskiwania i jasno określonej odpowiedzialności.
Microsoft Source upraszcza punkt wejścia. Nie usuwa pracy inżynieryjnej i zarządczej, która zaczyna się, gdy agent dotyka rzeczywistego procesu.
Proste tworzenie wywiera presję na tradycyjną automatyzację
Agenci wykorzystujący język naturalny podważają sztywne narzędzia workflow, ale nie czynią deterministycznej automatyzacji przestarzałą.
Tradycyjna automatyzacja działa najlepiej, gdy dane wejściowe, reguły i rezultaty są znane. System może skopiować zatwierdzone pole, wygenerować standardowe powiadomienie lub skierować zgłoszenie zgodnie z ustalonym warunkiem.
Agenci obsługują mniej ustrukturyzowaną pracę. Mogą interpretować e-mail, porównywać dokumenty, wyodrębniać dorozumiane żądanie i wybierać spośród kilku narzędzi. Ta elastyczność sprawia, że są atrakcyjni dla procesów, które wcześniej na każdym etapie wymagały ludzkiego osądu.
Najsilniejsze rozwiązanie często łączy oba podejścia. Agent interpretuje sytuację i proponuje kolejne działanie. Deterministyczny workflow weryfikuje żądanie, sprawdza uprawnienia i wykonuje zatwierdzoną operację.
Taki podział chroni krytyczne systemy przed nieograniczonymi wynikami modelu. Zachowuje również czytelny proces biznesowy. Audytorzy i operatorzy mogą zobaczyć, jakie warunki pozwalają na działanie, nawet gdy agent pomógł sklasyfikować dane wejściowe.
Strategia platformowa Microsoft wspiera to połączenie. Copilot Studio może łączyć agentów z workflowami, wiedzą, konektorami i niestandardowymi narzędziami. Twórcy mogą stosować rozumowanie generatywne tam, gdzie liczy się zmienność, oraz jawne reguły tam, gdzie liczy się spójność.
Wywiera to presję na dostawców tradycyjnej automatyzacji, by dodawali tworzenie w języku naturalnym i decyzje oparte na modelach. Wywiera też presję na dostawców agentów, by rozwijali funkcje ładu korporacyjnego, które oferują już ugruntowane platformy przedsiębiorstw.
Dla kupujących kluczowe pytanie nie brzmi, czy agenci zastąpią workflowy. Chodzi o to, gdzie probabilistyczna interpretacja tworzy wystarczającą wartość, aby uzasadnić dodatkową niepewność.
Etap podsumowywania dokumentu może tolerować niewielkie różnice w sformułowaniach. Etap zatwierdzania płatności nie może tolerować wymyślonego numeru konta. Odpowiednia architektura zależy od konsekwencji błędu.
Agent Builder i Copilot Studio obsługują również różne profile ryzyka. Microsoft 365 Agent Builder nadaje się do ukierunkowanego dostępu do wiedzy i lekkiego użycia zespołowego. Copilot Studio oferuje szersze mechanizmy kontroli potrzebne przy złożonym wdrożeniu.
Microsoft dokumentuje ścieżkę kopiowania projektu Agent Builder do Copilot Studio. Skopiowana wersja staje się odrębnym agentem, podczas gdy oryginał pozostaje dostępny. Zmiany w jednym z nich nie aktualizują automatycznie drugiego.
To rozdzielenie zapewnia użyteczną kontrolę, ale może też powodować zamieszanie związane z wersjami. Zespoły muszą określić, który agent jest autorytatywny, kto go utrzymuje oraz jak użytkownicy będą przechodzić między wersjami.
Konkurenci podążają podobnymi ścieżkami — od promptów w stronę zarządzanych systemów. IBM opisuje współczesnych agentów jako modele językowe działające z połączonymi narzędziami i danymi. Google promuje rozwój agentów za pośrednictwem swojej platformy chmurowej, podczas gdy Salesforce łączy agentów z danymi klientów i działaniami biznesowymi.
Frameworki open source oferują zespołom inżynieryjnym większą kontrolę. Mogą wspierać niestandardowe modele, wyspecjalizowaną ocenę i wybór infrastruktury. Zwykle wymagają jednak od zespołów zbudowania większej części stosu tożsamości, monitorowania, wdrażania i ładu.
Microsoft zakłada, że dla wielu organizacji integracja przeważy nad maksymalną elastycznością. Znany system tożsamości i istniejące środowisko danych mogą skrócić pracę wdrożeniową. Ta przewaga słabnie, gdy istotne procesy działają poza produktami Microsoft.
Rynek podzieli się zatem według zadań i wymagań dotyczących kontroli. Małe zespoły mogą preferować kreatory w języku naturalnym. Grupy inżynieryjne mogą wybierać frameworki code-first. Organizacje regulowane mogą łączyć oba podejścia w ściśle zarządzanych środowiskach.
Przekaz Microsoft Source, że każdy może zbudować agenta, jest zasadniczo trafny. Trudniejsze pytanie brzmi, czy każdy powinien wdrażać go bez wsparcia operacyjnego.
Bezpieczeństwo i ocena to brakujący poziom trudności
Agent staje się ryzykowny, gdy przekonujący język, niezaufane dane i szerokie uprawnienia spotykają się w tym samym workflowie.
Microsoft ostrzega, że narzędzia mogą pobierać informacje z niezaufanych źródeł, w tym e-maili i zgłoszeń wsparcia. Złośliwa instrukcja ukryta w takiej treści może próbować manipulować agentem lub wywołać niewłaściwe działanie.
Atak ten jest powszechnie nazywany prompt injection. Atakujący umieszcza instrukcje w danych przetwarzanych przez model, licząc, że zastąpią one reguły zamierzone przez twórcę.
Wskazówki Microsoft dotyczące bezpieczeństwa agentów zalecają twórcom konfigurowanie bezpiecznych konektorów dla wiedzy i niestandardowych narzędzi. Ostrzeżenie jest istotne, ponieważ agent może traktować zwykłą treść jednocześnie jako dowód i wskazówkę.
E-mail od klienta może zawierać tekst nakazujący agentowi ignorowanie jego zasad. Pobrana strona internetowa może instruować model, aby ujawnił wewnętrzny kontekst. Przejęty dokument może próbować przekierować workflow.
Same instrukcje nie zapewnią pełnej ochrony. Otaczający system powinien ograniczać dostępne narzędzia, rekordy, do których mogą uzyskać dostęp, oraz działania wymagające potwierdzenia przez człowieka.
Zasada najmniejszych uprawnień jest użyteczna. Agent powinien otrzymywać wyłącznie minimalny dostęp potrzebny do zdefiniowanego zadania. Agent redagujący nie potrzebuje uprawnień do wysyłania wiadomości. Agent raportujący nie potrzebuje uprawnień do modyfikowania rekordów źródłowych.
Działania o dużym wpływie powinny wykorzystywać bramki zatwierdzeń. Usuwanie danych, przesuwanie pieniędzy, zmiana uprawnień, wysyłanie komunikacji zewnętrznej lub modyfikowanie warunków prawnych nie powinny zależeć od pojedynczej decyzji modelu.
Ocena musi także obejmować więcej niż dopracowane odpowiedzi. Użyteczny zestaw testowy zawiera typowe żądania, niejednoznaczne dane wejściowe, brakujące dane, sprzeczne źródła, złośliwą treść, awarie narzędzi i powtarzane operacje.
Każdy przypadek potrzebuje mierzalnego wyniku. Agent może musieć wskazać właściwe źródło, wybrać odpowiednie narzędzie, zachować wymagane fakty, unikać zakazanych danych lub eskalować sprawę zamiast działać.
Microsoft’s Copilot Agent Kit wspiera zestawy testowe, ocenę wsadową, szczegóły dotyczące opóźnień, wyniki zaliczenia lub niezaliczenia oraz rubryki definiowane przez użytkownika. Funkcje te uznają, że samo testowanie konwersacyjne nie może potwierdzić gotowości produkcyjnej.
Twórcy powinni analizować kompletne ślady wykonania, a nie tylko końcowe odpowiedzi. Poprawna odpowiedź może ukrywać niepotrzebne wywołanie narzędzia, niebezpieczne pobranie danych albo nieudaną operację, której model nie ujawnił.
Zdarza się również sytuacja odwrotna. Niedoskonale sformułowana odpowiedź może realizować właściwy proces i wykorzystywać autorytatywne informacje. Kryteria oceny powinny odzwierciedlać rezultat biznesowy, zamiast nagradzać wyłącznie powierzchowną płynność językową.
Niezależne wytyczne dotyczące ryzyka wzmacniają ten szerszy pogląd. Profil AI NIST omawia ryzyka związane z niedokładnymi wynikami, prywatnością, bezpieczeństwem informacji, zależnością człowieka oraz pomiarem systemów generatywnych.
Organizacje powinny traktować agenta jako zmieniający się system. Modele są aktualizowane, dokumenty się zmieniają, API ewoluują, uprawnienia są przenoszone, a zachowanie użytkowników ujawnia przypadki pominięte przez początkowe testy.
Monitorowanie powinno śledzić sukces realizacji zadań, wskaźniki eskalacji, błędy narzędzi, odrzucenia zatwierdzeń, opóźnienia i nieoczekiwane próby dostępu. Zespół potrzebuje również jasnego procesu wyłączania agenta, gdy jego zachowanie staje się niebezpieczne.
Odpowiedzialność nie może pozostać niejasna. Ktoś musi zatwierdzać zmiany, analizować incydenty, utrzymywać przypadki testowe i decydować, czy wydajność uzasadnia dalsze wdrożenie.
Prosty przewodnik Microsoft jest wartościowy, ponieważ czyni komponenty zrozumiałymi. Jego prostota staje się niebezpieczna tylko wtedy, gdy czytelnicy mylą działający prototyp z kontrolowaną usługą produkcyjną.
Co obserwować po przewodniku Microsoft Source
Kolejny etap będzie mierzony zarządzanym wdrażaniem, powtarzalnymi ocenami i dowodami, że agenci wykonują użyteczną pracę bez stałego nadzoru.
Pierwszym sygnałem będzie przejście nowego środowiska tworzenia Copilot Studio od wersji preview do szerszego użycia produkcyjnego. Microsoft obecnie oznacza części tego środowiska jako funkcjonalność preview, przy czym niektóre możliwości różnią się od klasycznego produktu.
Stabilne wydanie wzmocniłoby twierdzenie Microsoft, że tworzenie w języku naturalnym może wspierać poważne wdrożenia. Utrzymujące się niekompatybilności lub trudności migracyjne osłabiłyby argument za traktowaniem prostego tworzenia jako niezawodnego cyklu życia.
Organizacje powinny obserwować, czy Microsoft zapewnia jaśniejsze ścieżki konwersji między klasycznymi i nowymi agentami. Powinny również śledzić, jak połączeni agenci, pamięć, workflowy i Microsoft IQ działają w warunkach produkcyjnego ładu.
Drugim sygnałem jest jakość danych dotyczących oceny i monitorowania. Twórcy agentów potrzebują więcej niż transkrypcji rozmów lub wskaźników satysfakcji użytkowników. Potrzebują dowodów dotyczących wyboru narzędzi, zgodności z politykami, odzyskiwania po błędach i ukończonych wyników.
Microsoft może wzmocnić swoją pozycję, czyniąc powtarzalne zestawy testowe i ślady wykonania centralnym elementem procesu tworzenia. Kupujący powinni oczekiwać wersjonowanych ocen przed każdą istotną zmianą.
Dobry proces wdrożeniowy powinien odpowiadać na bezpośrednie pytania. Które przypadki testowe się zmieniły? Czy dokładność wywołań narzędzi się poprawiła? Czy agent ujawnił dane objęte ograniczeniami? Jak często ludzcy recenzenci odrzucali proponowane przez niego działania?
Trzecim sygnałem jest to, czy firmy rozszerzają wąsko ukierunkowanych agentów bez utraty kontroli. Wczesny sukces często wynika ze skoncentrowanych zadań, takich jak podsumowania badań, wyszukiwanie dokumentów, przygotowanie spotkań lub klasyfikacja zgłoszeń.
Rozszerzenie przetestuje model. Agent, który odnosi sukces w jednym zespole, może zawieść, gdy zmienią się dokumenty, słownictwo, uprawnienia i oczekiwania. Szerszy dostęp może również wprowadzić więcej niezaufanej treści i narzędzi o poważniejszych konsekwencjach.
Dowody kontrolowanego skalowania wsparłyby główną tezę Microsoft. Dowody te powinny obejmować wskazanych właścicieli, wąskie uprawnienia, ludzkie zatwierdzanie wrażliwych działań, mierzalne kryteria sukcesu i niezawodną ścieżkę wyłączenia.
Duży zakres ręcznych poprawek osłabiłby to twierdzenie. Podobnie jak wzorzec agentów, którzy przyciągają początkową ciekawość, lecz tracą użytkowników, ponieważ wyniki pozostają niespójne.
Przewodnik Microsoft Source opisuje rzeczywistą zmianę. Osoba może teraz przejść od celu opisanego prostym językiem do działającego agenta AI, bez budowania od podstaw każdej warstwy oprogramowania.
To osiągnięcie zmienia to, kto może uczestniczyć w projektowaniu automatyzacji. Nie rozpowszechnia jednak wiedzy potrzebnej do zabezpieczania, oceniania i zarządzania każdym powstałym systemem.
Zacznij od jednego wąskiego zadania, które ma jasne dowody, mierzalny rezultat i ludzkiego właściciela. Zachowaj nieodwracalne działania poza zakresem uprawnień agenta, dopóki testy nie uzasadnią szerszej roli. Następnie zadaj pytanie ważniejsze niż to, czy ktokolwiek może zbudować agenta: czy twój zespół potrafi wyjaśnić, dlaczego temu agentowi należy zaufać przy następnym działaniu?
