Projektuj niezawodne pętle agentowe

Dotyczy tylko:GitHub Copilot harness

Pętla agentyczna pozwala agentowi ocenić wynik i zdecydować, czy kontynuować, poprawić błąd, spróbować innego podejścia, czy przerwać. Ta elastyczność pomaga agentom realizować zadania wieloetapowe, ale potrzebuje też granic. Koszty mogą nadal się kumulować nawet wtedy, gdy zadanie nie jest bliżej ukończenia. Bez limitów powtórek i warunków zatrzymania, powtarzające się wywołania modeli i narzędzi mogą zużywać tokeny i zwiększać opóźnienia bez posuwania pracy do przodu.

Korzystaj z tych wskazówek podczas projektowania lub recenzowania agentów zasilanych przez GitHub Copilot harness w Microsoft Copilot Studio. Wyjaśnia, jak zdefiniować przekazania zadań, ograniczyć próby i zweryfikować zakończenie poprzez siedem ilustracyjnych scenariuszy awarii.

Scenariusze opisują przykładowe narzędzia do przetwarzania i środowiska wykonawcze, a nie wymagania mające zastosowanie do każdego agenta Copilot Studio. Lokalizacje plików, kroki wstępnego przetwarzania i ograniczenia zależności zależą od narzędzi i środowiska uruchomieniowego, którego używasz. Dowiedz się więcej o dwóch uprzężach w Porównanie uprzęży agentów w Copilot Studio.

Jak rozszerzają się pętle agentyczne

Gdy narzędzie zawodzi, agent analizuje jego błąd i wybiera odpowiedź, na przykład poprawiając dane wejściowe lub próbując innego narzędzia. Każdy wynik wpływa na kolejne działanie. Na przykład agent może wywołać narzędzie, ocenić wynik i zdecydować, czy kontynuować, zatrzymać się, czy poprosić o pomoc. Jeśli wynik ujawni kolejny problem lub pozostawi zadanie nieukończone, cykl może się powtórzyć.

Powtarzające się kroki, niejasne warunki zatrzymania i niepełne przekazania mogą utrzymać ten cykl aktywny bez postępów. Niejednoznaczny wynik stwarza kolejne ryzyko: narzędzie mogło wykonać część swojej pracy, mimo że zwróciło błąd. Ponowne próbowanie bez sprawdzenia wyniku może powtórzyć działania lub zmienić istniejące wyniki.

Użyj instrukcji, aby pokierować decyzjami agenta. Tam, gdzie jest to wspierane, używaj walidacji narzędzi i limitów wykonania, aby wymuszać ograniczenia. Same instrukcje nie gwarantują, że wykonywanie się zatrzyma.

Praktyki projektowe

Określ, co agent może zmienić, co musi zachować i kiedy potrzebuje pomocy. Stosuj te praktyki, aby zachować zdolność agenta do adaptacji, ograniczając jednocześnie niepotrzebną pracę.

Nie musisz określać każdej czynności z wyprzedzeniem. Zdefiniuj dozwolone narzędzia, trasy wejściowe i działania zmieniające stan, wraz z kryteriami zakończenia. Następnie pozwól agentowi wybrać, jak postępować w tych granicach.

Dowiedz się więcej o granicach między projektowaniem agenta a orkiestracją w Wykorzystaj ramy projektowania agenta.

Zdefiniuj przekazania między narzędziami

Dla każdego przekazania opisz, co każdy krok otrzymuje, co musi zwrócić, jak następny krok wykorzystuje wynik oraz co pokazuje, że krok się powiódł. Zweryfikować wyjście zgodnie z wymaganiami narzędzia odbiorcy. Nie polegaj na agencie, aby sam wywnioskował wymagany format.

Zapisz umowę w instrukcjach dla agenta, wymagaj, aby pozostała niezmieniona, i zakazuj niezatwierdzonych podmian lub konwersji.

Dowiedz się więcej o ustrukturyzowanych danych wyjściowych i przekazywaniu na dalszych etapach w sekcji Dodaj węzeł agenta do workflow (GitHub Copilot).

Ujednolicić kryteria realizacji między agentami

Określ ustalenia, wymagania dotyczące dowodów i format odpowiedzi, których agent wywołujący potrzebuje od połączonego agenta. Określ, co stanowi wystarczającą informację i kiedy każdy agent powinien się zatrzymać. Określ, czy agent dzwoniący musi połączyć lub podsumować wyniki.

Unikaj generowania kolejnej odpowiedzi wyłącznie po to, by przeformatować taką, która już spełnia wymagania. Dodatkowe prace powinny odnieść się do brakującego faktu, połączyć oddzielne wyniki lub rozwiązać konflikt.

Sprawdź wymagania wstępne przed wykonaniem

Sprawdź, czy wymagane biblioteki są dostępne, dozwolone trasy są skonfigurowane, a obowiązkowe wymagania środowiska uruchomieniowego lub bezpieczeństwa są zgodne z instrukcjami skilla. Nie oczekuj, że agent wykryje, zainstaluje, obejdzie lub naprawi swoje środowisko wykonawcze. Rozwiąż konflikty między instrukcjami umiejętności a wymaganiami środowiska uruchomieniowego, zanim agent uruchomi zadanie.

Jeśli wymagana zależność jest niedostępna, określ, czy agent musi przestać, czy skorzystać z zatwierdzonej alternatywy. Nie zostawiaj zmian środowiska, instalacji pakietów ani implementacji zastępczych jako niedookreślonych opcji przywracania.

Dowiedz się więcej o sprawdzaniu pakietów umiejętności i brakujących zasobach w Rozwiązywanie problemów z umiejętnościami, które się nie ładują.

Daj agentowi tylko narzędzia, których potrzebuje

Włączaj tylko narzędzia i operacje serwera MCP wymagane przez zadanie. Używaj narzędzi tylko do odczytu, gdy zadanie nie zmienia danych. Usuń narzędzia dublujące operację, chyba że są zatwierdzonym rozwiązaniem awaryjnym.

Na przykład zadanie, które pobiera i podsumowuje tylko rekordy, nie powinno mieć włączonych operacji aktualizacji lub usuwania. Nie udostępniaj każdej operacji z serwera MCP "na wypadek, gdyby była przydatna"; dodatkowe narzędzia dają agentowi więcej alternatyw do eksploracji po awarii.

Dowiedz się więcej o konfigurowaniu dostępnych narzędzi i operacji MCP w Zarządzanie i usuwanie narzędzi w agencie (GitHub Copilot).

Zwrot pełnego statusu z przepływów pracy

Gdy budujesz workflow, który agent wywołuje, zwracaj jego status wykonywania, wszelkie dane wyjściowe oraz zmiany stanu, a także konkretne błędy. Dołącz informację, czy można spróbować ponownie. Jasno raportuj, kiedy praca jest częściowo zakończona lub gdy efekt jest niepewny. Nie używaj ogólnego komunikatu o sukcesie lub porażce dla tych wyników.

Na przykład, jeśli workflow tworzy dokument, ale dostarczenie się nie powiedzie, zgłoś, że dokument został utworzony, wskaż etap dostarczania, który zakończył się niepowodzeniem, i podaj, czy ten etap można ponowić bez powtarzania przetwarzania. Dołączaj odwołanie do pliku tylko wtedy, gdy następny krok tego wymaga.

Dowiedz się więcej o narzędziach do zarządzania przepływem pracy i odpowiedziach dla agentów w sekcji Dodaj workflow do swojego agenta jako narzędzie (GitHub Copilot).

Określ, kiedy poprawiać, a kiedy przestać

Wypisz błędy wywołania możliwe do poprawienia oddzielnie od ostatecznych błędów technicznych lub konfiguracyjnych. Zdefiniuj limity kontroli i prób, które pozwalają na ponowną próbę.

Używaj hooków do stosowania reguł odzyskiwania po błędzie i zmiany zachowania agenta, w tym zachowania przy ponawianiu.

Warunki końcowe mają pierwszeństwo przed wszelkim pozostałym limitem ponownych prób. Wymagaj od agenta, aby się zatrzymał oraz zgłosił problem lub eskalował go, zamiast szukać innej drogi.

Gdy wymagana jest kontrola przez człowieka, określ, co agent musi zgłosić. Zdefiniuj wymaganą akceptację, poprawione dane wejściowe lub zmianę konfiguracji, których potrzebuje, zanim będzie można wznowić jego działanie.

Przestań, gdy powtarzane kroki nie przynoszą żadnych nowych rezultatów. Gdy żadne zatwierdzone działanie nie ma zastosowania, wymagaj od agenta wyjaśnienia, zgłoszenia niepowodzenia lub eskalacji.

Dowiedz się więcej o błędach produktu i powiązanych z nimi działaniach naprawczych w Error codes reference for agents (GitHub Copilot).

Ogranicz powtórki i weryfikuj poprzedni stan

Zdefiniuj, co się liczy jako próba. Podaj maksymalną liczbę prób, dokładne warunki upoważniające do kolejnej próby oraz wymaganą weryfikację przed ponownym podjęciem akcji, która mogła zmienić stan.

Tam, gdzie jest to obsługiwane, należy egzekwować limit prób w narzędziu lub czasie działania. Nie polegaj tylko na instrukcjach.

W przypadku błędów poza wywołaniem narzędzia hook Error może określać retryCount przy żądaniu ponowienia.

Spróbuj ponownie tylko wtedy, gdy błąd wskazuje możliwe do poprawienia dane wejściowe, a poprzednia próba nie wprowadziła żadnych zmian. Jeśli wynik jest nieznany, zgłoś go i przestań.

Egzekwowanie granic w środowisku uruchomieniowym

Użyj instrukcji do określenia dozwolonych działań i warunków zatrzymania. Tam, gdzie jest to obsługiwane, egzekwuj granice krytyczne za pomocą narzędzi lub mechanizmów kontrolnych środowiska wykonawczego. Gdy akcja zostanie odrzucona, zażądaj, aby agent ją zgłosił i przerwał działanie, zamiast próbować innego polecenia, narzędzia lub trasy.

W instrukcjach agenta umieść zasady zatrzymania i ponownego próbowania, które dotyczą każdego zadania. Wprowadź zasady specyficzne dla procedur w odpowiednim skillu. Na przykład hook pre-tool-use może sprawdzić i odrzucić wywołanie narzędzia, które narusza politykę.

W przypadku błędów poza wywołaniem narzędzia, hook Error może zmienić zachowanie odzyskiwania i powiadomienia użytkownika. W przypadku nieudanego wywołania narzędzia, hook po niepowodzeniu wywołania narzędzia może dostarczyć modelowi wskazówek.

Dowiedz się więcej o sprawdzaniu wywołań narzędzi i odzyskiwaniu błędów w Hooks (GitHub Copilot).

Potwierdź nieodwracalne działania

Zanim agent usunie lub nadpisze dane, wyśle informacje lub wykona inną nieodwracalną akcję, wymagane jest potwierdzenie przez użytkownika lub autoryzowana weryfikacja przez upoważnioną osobę. Stosuj ten sam wymóg, gdy agent ponawia próbę lub zmieni podejście. Krok odzyskiwania nie może wprowadzać niezatwierdzonego, nieodwracalnego działania.

Na przykład, jeśli plik wyjściowy już istnieje, nie pozwól agentowi go nadpisać tylko po to, by wykonać zadanie. Wymagaj od agenta wyjaśnienia konfliktu i uzyskania potwierdzenia przed zastąpieniem pliku. W przeciwnym razie musi zgłosić konflikt i zatrzymać się.

Dowiedz się więcej o ludzkim nadzorze nad kluczowymi działaniami w Projektowanie autonomicznych możliwości agentów.

Weryfikowanie ukończenia

Zdefiniuj obserwowalne wyniki, które dowodzą, że zadanie jest zakończone. Samo raportowanie sukcesu narzędzia może nie potwierdzić, że rezultat odpowiada żądaniu użytkownika.

Prowadź testy z wcześniej zdefiniowanymi kryteriami sukcesu lub porażki, takimi jak walidacja wejściowa i weryfikacja wyników, w komponentach odpowiedzialnych za nie. Jeśli to możliwe, niech narzędzie odpowiedzialne za wyjście przeprowadzi te kontrole.

Wymagaj od agenta sprawdzenia, czy zwrócone dowody spełniają kryteria ukończenia zadania i wywołaj wszelkie dodatkowe wymagane weryfikacje. Jeśli brakuje dowodów lub test się nie powiedzie, zgłoś zadanie jako nieukończone i stosuj się do zdefiniowanej reguły naprawczej.

Dowiedz się więcej o oczekiwanych odpowiedziach i metodach oceny w Tworzenie zestawu testowego dla agenta.

Użyj śladów do znalezienia brakujących kontrolek

Sprawdź śledzenie aktywności pod kątem powtarzających się połączeń, niepotrzebnych wyszukiwań, zmian tras oraz działań kontynuujących się po spełnieniu warunku zatrzymania. Przeanalizuj wyświetlone uzasadnienie, aby ustalić, dlaczego agent działał, próbował ponownie, zmienił trasę lub nie zdołał się zatrzymać. Zidentyfikuj brakującą instrukcję, kontrakt, konfigurację lub granicę środowiska uruchomieniowego stojącą za takim zachowaniem.

Zmodyfikuj instrukcję, kontrakt narzędziowy lub konfigurację środowiska wykonawczego odpowiedzialną za problem. Następnie ponownie przeprowadź ten sam test i zweryfikowaj oczekiwane zachowanie.

Dowiedz się więcej w Użyj śledzenia aktywności do debugowania agenta (GitHub Copilot) oraz Przeprowadź ewaluację dla agenta.

Zachowaj oryginalne dane wejściowe i wyniki narzędzi

Dla każdego narzędzia lub kroku zachowaj oryginalne dane wejściowe, wynik wygenerowany przez narzędzie, status walidacji lub kod błędu. Nie pozwól agentowi zgadnąć brakującej wartości ani po cichu zmienić wynik zwrócony przez narzędzie. Zachowaj oryginalny wynik do weryfikacji.

Jeśli brakuje wiarygodnych danych wejściowych lub wyniku, albo nie da się ich zweryfikować, zgłoś to i przestań. Nie twórz zamiennika.

Jeśli konieczna jest konwersja, przypisz ją do wyznaczonego komponentu i zweryfikuj przekonwertowany wynik.

Dowiedz się więcej o zachowaniu wyników pośrednich i współdzielonym stanie w kontekście i zarządzaniu stanem.

Scenariusze awarii

Każdy z poniższych scenariuszy awarii pokazuje wzorzec awarii, brakującą kontrolę oraz oczekiwany wynik do testowania. Diagramy ilustrują przykładowe umowy przetwarzania. Ograniczenia dotyczą tylko przykładów, a nie wszystkich narzędzi czy agentów.

Niejednoznaczne wyniki narzędzia

Narzędzie przetwarzające zwraca niezerowy kod wyjścia bez komunikatu wyjaśniającego. Gdy agent nie jest w stanie określić, czy program został wywołany nieprawidłowo, zakończył się niepowodzeniem lub nie zwrócił żadnego wyjścia diagnostycznego, może próbować zdiagnozować awarię poprzez samodzielne działania w pętli, takie jak zmiana polecenia i ponowne uruchomienie.

Ta sekwencja może prowadzić do kaskadowych awarii. Na przykład, jeśli pierwsza próba utworzyła folder wyjściowy, zanim się nie powiodła, kolejna próba może się nie powieść, ponieważ ten folder już istnieje.

Brakującą kontrolą jest polityka ponawiania, która obejmuje niepełne wyniki i stan częściowy. Bez niego wariacje poleceń mogą wydawać się osobnymi akcjami diagnostycznymi, a nie powtarzanymi próbami.

Dowiedz się więcej w Ogranicz powtórki i weryfikuj poprzedni stan oraz Zwróć pełny status z workflowów.

W tym przykładzie konfiguruj agenta poprzez instrukcje lub narzędzia tak, aby dopuścił kolejną próbę dopiero po zidentyfikowaniu konkretnego błędu wywołania i potwierdzeniu, że poprzednia próba nie wniosła żadnych zmian. Jeśli nie da się wykluczyć stanu poprzedniego, wymagaj, aby agent zatrzymał się zamiast ponownie wywoływać krok przetwarzania. Narzędzia z udokumentowaną obsługą idempotentnego ponawiania mogą zamiast tego korzystać z własnego mechanizmu ponawiania.

Aby zweryfikować poprawkę, symuluj niepełny wynik po utworzeniu częściowego wyjścia. Potwierdź, że agent obsługuje ten etap przetwarzania zgodnie z określoną kontrolą ponowień.

Sprzeczne wymagania dotyczące środowiska uruchomieniowego i umiejętności

Skill zezwala tylko na dołączony do niego program, ale czas działania używany przez harness GitHub Copilot wymaga warunku wstępnego sprzecznego z instrukcjami skilla. Środowisko uruchomieniowe może zablokować próbę kontynuowania przez umiejętność. Ten konflikt może skłonić agenta do wydania innego polecenia zamiast rozwiązania konfliktu konfiguracji lub potraktowania go jako warunku zatrzymania.

Brakujący mechanizm kontrolny to zatwierdzona ścieżka wykonania, która spełnia zarówno wymagania wykonania, jak i instrukcje umiejętności.

Dowiedz się więcej w sekcji Sprawdź wymagania wstępne przed wykonaniem oraz Egzekwuj granice w czasie działania.

Diagram oznacza przykładowy krok wstępnego przetwarzania jako "analyzing-docx". Ta etykieta nie ustanawia wymaganego wbudowanego kroku Copilot Studio.

Rozwiąż sprzeczne wymagania przed uruchomieniem zadania. Jeśli obowiązkowa akcja środowiska uruchomieniowego jest nieobecna lub zabroniona przez zatwierdzoną ścieżkę, zażądaj, aby agent zatrzymał się i zgłosił konflikt po pierwszej odmowie. Nie pozwól agentowi zmienić polecenia, skopiować wejścia, wyszukać innej ścieżki ani omijać kontroli środowiska uruchomieniowego.

Aby zweryfikować poprawkę, zablokuj wymagany warunek wstępny. Potwierdź, że agent zgłasza problem z konfiguracją, nie próbując innej ścieżki.

Nieprawidłowo wyrównane kryteria ukończenia

Agent wywołujący i jego połączony agent (podrzędny) mają sprzeczne cele wyjściowe bez wspólnej umowy dotyczącej zakończenia. Bez wyraźnego warunku zatrzymania (na przykład jeśli osiągnięto limity wyszukiwania w sieci), agent wywołujący może kontynuować wyszukiwanie, dodawać przykłady i rozszerzać swoją odpowiedź, nawet jeśli połączony agent już zwraca satysfakcjonujący wynik.

Brakującym mechanizmem zabezpieczającym jest wspólna definicja wystarczających dowodów oraz format odpowiedzi między agentami lub narzędziami.

Dowiedz się więcej w Dostosowywanie kryteriów ukończenia między agentami.

Konfiguruj agentów inicjujących połączenie i połączonych z tymi samymi kryteriami zakończenia i formatem odpowiedzi. Wymagaj, aby połączony agent zwrócił odpowiedź gotową dla wywołującego agenta, używając zdefiniowanej struktury:

• Żądane ustalenie
• Dowody wspierające i ich źródło
• Wszelkie nierozwiązane luki dowodowe

Pozwól agentowi wywołującemu wykonać dodatkowe przetwarzanie odpowiedzi tylko w celu usunięcia konkretnej luki, połączenia wyników od wielu połączonych agentów lub rozwiązania sprzecznych wyników. Jeśli żądanych informacji nie można znaleźć w limicie wyszukiwania, zwróć ten status. Jeśli pojedynczy połączony agent już zwraca odpowiedź spełniającą wymagania, zwróć ją bez kolejnego kroku syntezy. Diagram oznacza agenta wywołującego jako rodzica, a powiązanego jako dziecko.

Aby zweryfikować poprawkę, niech połączony agent zwróci odpowiedź spełniającą żądane ustalenia, wymagane dowody i wymagania dotyczące formatu. Potwierdź, że agent wywołujący zwraca to bez wykonywania nieproszonych wyszukiwań, dodawania nieproszonych przykładów czy generowania innej syntetycznej odpowiedzi.

Brakujące zależności uruchomieniowe

Agent wywołuje umiejętność, która wymaga biblioteki, która jest niedostępna. W tym scenariuszu zasady w środowisku wykonawczym harnessu GitHub Copilot odmawiają wielu poleceń modyfikujących sieć lub system. Próby agenta rozwiązania brakującej zależności mogą obejmować wyszukiwania instalatorów, plików instalacyjnych offline, bezpośrednich pobrań lub kopii biblioteki w innych miejscach w środowisku wykonawczym harness GitHub Copilot.

Brakująca kontrola to sprawdzenie warunku wstępnego z określoną odpowiedzią, gdy wymagana zależność nie zostanie znaleziona.

Dowiedz się więcej w sekcji Sprawdź wymagania wstępne przed wykonaniem oraz Egzekwuj granice w czasie działania.

Użyj instrukcji globalnych, aby wymagać wspieranych bibliotek oraz przeprowadzić sprawdzenie zależności za pomocą narzędzia przed rozpoczęciem przetwarzania. Instrukcje muszą wymagać od agenta zgłoszenia brakującej wymaganej biblioteki i zatrzymania się bez tworzenia wyjścia. Zakaz zmian w źródłach pakietów, ustawieniach certyfikatów lub proxy albo ścieżkach bibliotek podczas przetwarzania.

Aby zweryfikować naprawę, uruchom sprawdzenie wymagań wstępnych, gdy biblioteka jest niedostępna. Potwierdź, że agent identyfikuje zależność, nie generuje danych wyjściowych i nie podejmuje prób instalacji.

Niedopasowane ścieżki wejściowe dokumentów

Instrukcje przetwarzania nie wskazują lokalizacji przesłanego dokumentu, więc agent może potraktować przesłany dokument jako brakujący.

Bezpośrednie przesyłanie i przesłania w ramach przepływu pracy mogą dostarczać dokumenty w różnych lokalizacjach lub reprezentacjach w środowisku wykonawczym GitHub Copilot. Agent może zastosować swoje założenia wyszukiwania dla jednej trasy do drugiej. Brak pliku w oczekiwanym miejscu może wtedy skłonić agenta do przeszukania innych katalogów lub próby odzyskania brakujących danych wejściowych.

Brakujący mechanizm to mapowanie każdej obsługiwanej ścieżki wejściowej do wymagań wyszukiwania, których agent musi przestrzegać, oraz narzędzia określającego lokalizację jego dokumentu.

Dowiedz się więcej w Definiuj przekazania narzędzi oraz Zwracanie pełnego statusu z przepływów pracy.

Wybierz ścieżkę wejściową przed przetwarzaniem. Niech wyznaczone narzędzie zlokalizuje dokument i zwróci referencję do pliku, której oczekuje narzędzie przetwarzające.

W instrukcjach określ, gdzie znaleźć dokument dla każdej ścieżki wejściowej oraz jakiego narzędzia użyć do jego lokalizacji. Określ także typ pliku, format odniesienia oraz pole wejściowe wymagane przez narzędzie odbierające.

Wymagaj od agenta, aby zachował wybraną trasę przyjmowania dokumentów i ustaloną lokalizację bez zmian podczas całego przetwarzania. Musi również zachować uzgodnione odniesienie bez zmian podczas weryfikacji i dostarczania.

Agent nie może przeszukiwać niepowiązanych katalogów ani rekonstruować dokumentu poza wyznaczonym narzędziem. Jeśli ustalenie trasy się nie powiedzie, agent musi zgłosić błąd wejścia. Może oferować ponowne przesłanie przez inną wspieraną ścieżkę tylko wtedy, gdy ta ścieżka jest zatwierdzoną opcją przywracania. Jeśli dokument jest nieobecny, agent musi zgłosić błąd wejścia i zakończyć działanie.

Jeśli uzgodnione referencje nie mogą zostać dostarczone, agent musi zgłosić niepowodzenie przekazania i przerwać proces.

Aby zweryfikować naprawę, należy przesłać element wejściowy, którego brakuje w oczekiwanej lokalizacji wybranej trasy. Potwierdź, że agent zgłasza błąd wejścia i zatrzymuje się bez cichego przełączania trasy.

Niezdefiniowane przekazywanie plików

Narzędzie przetwarzające zwraca ścieżkę do pliku, ale narzędzie odbiorcze oczekuje załącznika. Agent próbuje podać URI pliku, skopiowaną ścieżkę oraz zakodowaną treść, nie ustalając, która reprezentacja jest wymagana. Jedna próba może nawet stworzyć plik zawierający tekst ścieżki zamiast przetworzonego dokumentu.

Brakującą kontrolą jest uzgodniony format przekazywania plików.

Dowiedz się więcej w Przekazywanie narzędzi oraz Weryfikacja ukończenia.

Zdefiniuj typ pliku, format odniesienia oraz pole odbiorcze na granicy integracji. W tym przykładzie narzędzie odbiorcze wymaga załącznika zarządzanego przez środowisko uruchomieniowe. Lokalna ścieżka nie jest zamiennikiem. Lokalizacja /app/created/ na diagramie jest ilustracyjna, a nie gwarantowana lokalizacja wyjściowa.

Przekaż uzgodniony załącznik bez zmian w procesie weryfikacji i dostarczania. Jeśli mechanizm GitHub Copilot nie jest w stanie tego zapewnić, zgłoś niepowodzenie przekazania i przestań. Inne integracje mogą korzystać ze ścieżek lub zakodowanych treści, gdy te formaty są wyraźnie wspierane.

Aby zweryfikować poprawkę, wróć do ścieżki, w której wymagany jest załącznik. Potwierdź, że agent zgłasza niezgodność zamiast przeliczać wartość lub twierdzić, że dostawa zakończyła się sukcesem.

Dane wejściowe o nieprawidłowej strukturze

Narzędzie przetwarzające raportuje, że obiekt wejściowy — na przykład dokument — jest nieprawidłowy. Agent może dalej próbować uczynić go użytecznym, zamiast przestawać. Na przykład agent może transkrybować zakodowane wejście, porównywać różne kopie, zmieniać podejrzane znaki lub bajty, testować dekompresję lub szukać możliwych podstawień.

Brakująca kontrola to instrukcja, która wymaga od agenta zatrzymania się, gdy walidacja strukturalna zawodzi, zamiast próbować napraw na podstawie przypuszczeń.

Dowiedz się więcej w Zachowaj oryginalne dane wejściowe i wyniki narzędzi oraz Potwierdź działania nieodwracalne.

Zidentyfikuj zaufany komponent upoważniony do wykonywania ograniczonego, weryfikowalnego odzyskiwania. Jeśli walidacja się nie powiedzie, zatrzymaj się i poproś o prawidłowy zamiennik lub autoryzowaną korektę sprawdzoną przez człowieka. Nie pozwól agentowi zgadywać brakującej treści źródłowej. Wznów przetwarzanie dopiero po dostarczeniu ważnego obiektu zastępczego lub autoryzowanej korekty zweryfikowanej przez człowieka.

Aby zweryfikować poprawkę, podaj nieprawidłowy dokument. Potwierdź, że agent zgłasza niepowodzenie walidacji i nie modyfikuje ani nie rekonstruuje tekstu źródłowego. Jeśli udostępnione jest narzędzie do autoryzowanej konwersji, potwierdź, że tylko to narzędzie wykonuje ograniczoną, weryfikowalną konwersję i że przetwarzanie wznawia się dopiero po dostarczeniu poprawnego obiektu zastępczego.

Weryfikowanie projektu

Przed opublikowaniem zmian przetestuj zarówno zadania zakończone powodzeniem, jak i warunki niepowodzenia dotyczące Twojego agenta:

• Każda ścieżka wejściowa odnajduje oczekiwany dokument lub zgłasza wyraźny błąd.
• Narzędzia wymieniają uzgodnione formaty wejścia i wyjścia.
• Agenci zatrzymują się, gdy spełnią kryteria ukończenia.
• Konflikty konfiguracji i brakujące zależności zatrzymują wykonywanie zgodnie z ustawieniami.
• Liczba powtórek pozostaje w granicach skonfigurowanego limitu, w tym warianty poleceń.
• Niejednoznaczne wyniki wywołują weryfikację stanu, a nie automatyczne ponowne próbowanie.
• Nieprawidłowa treść źródłowa pozostaje niezmieniona.
• Zakończenie jest raportowane dopiero po przejściu wymaganych kontroli wyjściowych.
• Kontrole w czasie działania blokują zakazane akcje, a agent informuje o odmowie i zatrzymuje się bez próby kolejnego polecenia, narzędzia czy trasy.
• Nieodwracalne działania wymagają potwierdzenia użytkownika lub autoryzowanej oceny przez człowieka.

Porównaj ślad aktywności i wyniki oceny przed i po każdej zmianie. Przeanalizuj wyświetlane rozumowanie wraz z wywołaniami narzędzi, wejściami, wyjściami, błędami i czasem, aby ustalić, dlaczego agent wybrał akcję, co spowodowało ponowną próbę, dlaczego zmienił trasę oraz który warunek powinien był spowodować zatrzymanie.

Wykorzystaj te ustalenia, aby zidentyfikować brakującą instrukcję, kontrakt, konfigurację lub granicę środowiska uruchomieniowego. Zmień warstwę odpowiedzialną za to i przeprowadź ten sam test. Potwierdź, że niepożądane zachowanie już nie występuje i wymagany rezultat nadal jest osiągany. Mniej akcji lub krótszy bieg same w sobie nie są dowodem na postęp.

Informacje pokrewne

• Projektuj autonomiczne możliwości agenta
• Korzystaj z ram projektowania agentów
• Dlaczego systemy LLM z wieloma agentami zawodzą? (artykuł naukowy)
• Zweryfikowane wywołania narzędzi poprawiają niezawodność agentów LLM w przypadku awarii nieatomowych (artykuł naukowy)
• Świadome budżetu użycie narzędzi umożliwia efektywne skalowanie agentów (artykuł naukowy)
• Kontrola budżetu podczas wnioskowania dla agentów wyszukiwawczych LLM (praca naukowa)