Standardowe agent flows w Copilot Studio

Standardowy agent flow w Microsoft Copilot Studio automatyzuje przewidywalny ciąg czynności: wyzwalacz uruchamia określone akcje i warunki. Może działać samodzielnie albo jako narzędzie standardowego agenta. Microsoft opisuje te przepływy jako część standard harness. Nowe workflows na GitHub Copilot harness mają inne doświadczenie projektowe; zestawienie obu dróg znajdziesz w przeglądzie nowego Copilot Studio.

Ten wpis dotyczy konkretnego wykonania w ekosystemie Microsoft AI. Jeśli interesuje Cię nowy designer z węzłami agentowymi, przejdź do workflows na GitHub Copilot harness.

Kiedy flow jest lepszy niż swobodna instrukcja

Jeśli proces brzmi „po otrzymaniu wniosku sprawdź pole, wyślij do właściciela, zapisz status i powiadom zgłaszającego”, jego podstawowa ścieżka jest deterministyczna. Warto zapisać ją w przepływie, gdzie widać wyzwalacz, kroki i błędy. Agent może pomóc rozpoznać intencję albo zebrać brakujące informacje, ale nie musi decydować, czy pomijać obowiązkowe zatwierdzenie.

Przykład hipotetyczny: pracownik pyta agenta o stan zgłoszenia IT. Agent rozumie pytanie, agent flow pobiera rekord przez konektor i zwraca status. Wariant z aktualizacją priorytetu wymaga odrębnego sprawdzenia uprawnień. Taki podział odróżnia rozmowę od działania w systemie.

Zapisz kontrakt między agentem i flow przed implementacją. Wejściem może być identyfikator zgłoszenia i tożsamość użytkownika, wyjściem status i data ostatniej zmiany. Jeśli identyfikator jest pusty, flow powinien zwrócić rozpoznawalny błąd. Jeśli użytkownik nie ma prawa do rekordu, odpowiedź nie powinna zdradzać jego treści. Takie warunki są częścią projektu przepływu, a nie wyłącznie promptu agenta.

Budowa krok po kroku

1. Zapisz zdarzenie rozpoczynające. Może to być uruchomienie ręczne, harmonogram, zdarzenie w aplikacji albo wywołanie przez agenta.
2. W Copilot Studio wybierz Workflows → New agent flow dla standard harness. Dokumentacja Microsoft dopuszcza tworzenie przez opis językowy oraz edytor wizualny.
3. Dodaj akcje, warunki i połączenia. Dla każdej akcji określ wejście, wynik i zachowanie przy błędzie. Wypisz, które dane mogą opuścić system źródłowy.
4. Jeśli flow ma być narzędziem agenta, dodaj wyzwalacz When an agent calls the flow oraz odpowiedź Respond to the agent. Opublikuj flow, a następnie dołącz go w zakładce narzędzi agenta zgodnie z instrukcją Microsoft.
5. Przetestuj sprawę poprawną, brak rekordu, brak uprawnienia, powtórne wywołanie i sytuację, w której system docelowy nie odpowiada.

Flow wywoływany przez agenta powinien zwracać zwięzły, jednoznaczny wynik: identyfikator sprawy, status, informację o błędzie. Agent może potem objaśnić wynik użytkownikowi. Nie zwracaj niepotrzebnych danych osobowych tylko po to, by model miał więcej kontekstu.

Uważaj na ponowienia. Gdy połączenie zostanie przerwane po zapisaniu zmiany, agent może spróbować wywołać flow drugi raz. W operacji zmieniającej dane użyj identyfikatora sprawy lub innego sposobu rozpoznania duplikatu. W teście wywołaj ten sam przypadek dwukrotnie i sprawdź, czy powstała jedna, a nie dwie aktualizacje. To ważniejsze niż sukces pojedynczego przebiegu demonstracyjnego.

Odbiór i utrzymanie

Sprawdź, czy dwa takie same wejścia powodują oczekiwany przebieg, czy warunki nie przepuszczają niepełnych danych i czy ponowienie nie tworzy duplikatu działania. Zmiany w przepływie testuj na przypadkach wcześniej zapisanych. Microsoft informuje, że akcje zużywają pojemność Copilot Studio; uwzględnij również koszt nieudanych uruchomień oraz limit środowiska.

Standardowy flow jest częścią procesu, który ma właściciela i procedurę awaryjną. Gdy kroki są nieprzewidywalne i wymagają elastycznego planowania, rozważ workflow nowego harnessu. Gdy wystarcza reguła, prosty agent flow będzie łatwiejszy do sprawdzenia i utrzymania.

Po publikacji mierz liczbę uruchomień, błędy konektorów, przypadki bez uprawnień i czas zakończenia. Zapisz osobę odpowiedzialną za zmianę połączenia, gdy system źródłowy zmieni API lub strukturę danych. Użytkownik agenta powinien dostać czytelną informację, że sprawa nie została zakończona, zamiast niepotwierdzonego komunikatu o sukcesie.