Zgoda człowieka w agencie AI: zatrzymaj akcję przed skutkiem ubocznym

Zgodę człowieka umieść przed wywołaniem narzędzia, które może wywołać skutek uboczny. Mechanizm zatwierdzania w OpenAI Agents SDK wstrzymuje wtedy przebieg i udostępnia nazwę agenta, narzędzie oraz argumenty oczekującego wywołania. Aplikacja może zapisać stan przerwanego zadania i wznowić ten sam przebieg po decyzji uprawnionej osoby.

Przycisk akceptacji pokazany dopiero po zakończeniu zadania jest spóźniony, jeśli agent zdążył wysłać wiadomość, opublikować treść albo usunąć dane. Zgoda musi dotyczyć konkretnej proponowanej operacji i jej argumentów, a zapis stanu powinien pozwalać czekać na człowieka bez utrzymywania otwartego żądania czy rozpoczynania całej pracy od początku.

Wybierz działania, przy których agent ma się zatrzymać

Regułę ryzyka oprzyj na skutku działania, odbiorcy, zakresie uprawnień i możliwości cofnięcia zmiany. Odczyt publicznej strony, wyszukanie informacji czy przygotowanie prywatnego szkicu zwykle nie wymagają zatwierdzania. Wysłanie wiadomości do zewnętrznego odbiorcy, publikacja, płatność oraz trwałe usunięcie rekordów są przykładami operacji, przy których zgoda daje człowiekowi możliwość zatrzymania skutku.

Nie oceniaj ryzyka wyłącznie po nazwie narzędzia. Funkcja edycji może zapisać roboczą wersję tekstu albo zmienić stronę widoczną dla klientów; rozstrzygające są również obiekt, tryb działania i wartości argumentów. Reguła powinna działać w kodzie aplikacji, z wykorzystaniem danych, którym aplikacja ufa. Deklaracja agenta, że proponowana czynność jest bezpieczna, nie powinna sama zwalniać jej z kontroli.

Przy każdym wywołaniu polityka może dopuścić wykonanie, odmówić go lub skierować operację do człowieka. Niepoprawne argumenty trzeba odrzucić albo zatrzymać do wyjaśnienia, zamiast przepuszczać je przez wyjątek od reguły. Jeśli aplikacja dopuszcza automatyczne wykonanie części zmian, określ granice tego wyjątku tak samo konkretnie jak warunki obowiązkowej zgody.

Przerwij przebieg przy narzędziu wywołującym skutek

Kontrola początkowej prośby i końcowej odpowiedzi nie zabezpiecza każdej czynności pośrodku. Wytyczne OpenAI dotyczące guardrails rozróżniają kontrole wejścia i wyjścia od kontroli wywołań narzędzi oraz wskazują, by walidację umieszczać przy narzędziu powodującym skutek uboczny. Dotyczy to także działań proponowanych przez agenta wywołanego wewnątrz dłuższego przebiegu.

Kolejność jest istotna: agent proponuje wywołanie, aplikacja ocenia jego argumenty, a narzędzie wymagające zgody pozostaje niewykonane do chwili rozstrzygnięcia. Jeżeli zadanie obejmuje kilka wrażliwych operacji, oceniaj każdą z nich osobno. Akceptacja publikacji wpisu nie upoważnia automatycznie do późniejszego wysłania jego treści na listę adresową.

Zachowaj stan długiego procesu

W momencie przerwania zapisz stan przebiegu oraz identyfikator oczekującego wywołania w trwałym magazynie aplikacji. Powiąż z nimi użytkownika, narzędzie, argumenty i zastosowaną wersję reguły ryzyka. Dzięki temu decyzja może nadejść po zamknięciu bieżącego połączenia z przeglądarką, a aplikacja nadal będzie wiedzieć, którą operację ma wznowić lub odrzucić.

Dokumentacja przerwań LangGraph opisuje zapis punktu kontrolnego i użycie identyfikatora wątku do wznowienia tego samego stanu. Wskazuje też ważną cechę wykonania: kod węzła przed przerwaniem może uruchomić się ponownie. W takim środowisku umieść działanie ze skutkiem ubocznym za punktem zgody, najlepiej w osobnym kroku, a wcześniejsze operacje projektuj z myślą o ponownym wykonaniu.

Pełny stan trzymaj po stronie serwera. Interfejs zatwierdzania powinien otrzymać tylko szczegóły potrzebne uprawnionej osobie i niejawny identyfikator oczekującej decyzji. Sam identyfikator nie daje prawa do zatwierdzenia; wysłany z przeglądarki stan procesu ani podmienione argumenty nie mogą zastąpić zapisu, którym zarządza aplikacja.

Pokaż operację, którą człowiek rzeczywiście zatwierdza

Na ekranie decyzji pokaż nazwę działania, jego cel i argumenty, które trafią do narzędzia. Dla przykładowej płatności będą to odbiorca, kwota i waluta; dla publikacji — kanał oraz treść lub czytelny podgląd zmiany. Są to warunkowe przykłady projektu interfejsu: zestaw niezbędnych pól wynika z konkretnego narzędzia i jego skutków.

Dodaj krótki kontekst polecenia: kto zlecił zadanie, dlaczego agent proponuje tę operację i jaki obiekt zostanie zmieniony. Ogólny przycisk „Akceptuj” bez tych danych nie pozwala ocenić decyzji. Dane wrażliwe pokazuj tylko osobie uprawnionej do ich obejrzenia, a nazwy narzędzi i argumenty traktuj w interfejsie jako niezaufaną treść wymagającą bezpiecznego wyświetlenia.

Zatwierdzenie przypisz do konkretnego wywołania i zestawu argumentów. Jeśli zatwierdzający zmienia odbiorcę, treść lub kwotę, aplikacja powinna utworzyć nową propozycję i ponownie zastosować do niej regułę ryzyka. Obok akceptacji przewidź wyraźną odmowę; po niej chronione narzędzie pozostaje niewykonane, a agent może zakończyć zadanie albo zaproponować inne rozwiązanie.

Wznów po ważnej decyzji i zachowaj ślad wykonania

Po otrzymaniu odpowiedzi uwierzytelnij osobę zatwierdzającą i sprawdź jej prawo do rozstrzygnięcia właśnie tego wywołania. Następnie odczytaj oczekującą operację z własnego magazynu, sprawdź jej status i ważność decyzji oraz oznacz żądanie jako wykorzystane w sposób atomowy. Dopiero na tej podstawie wznów zapisany przebieg; równoczesne kliknięcia nie powinny uruchomić go dwukrotnie.

Termin ważności zgody ustala aplikacja odpowiednio do rodzaju działania. Po jego upływie zatrzymaj wykonanie i ponownie oceń uprawnienia, stan obiektu oraz argumenty. Jeżeli propozycja się zmieniła, pokaż ją do nowej decyzji. Ta sama zasada dotyczy odmowy: późniejsza próba wykonania podobnej operacji wymaga własnej oceny, a nie ponownego użycia wcześniejszego rozstrzygnięcia.

W rejestrze audytowym zachowaj identyfikatory przebiegu i wywołania, zatwierdzony zestaw argumentów lub jego chroniony zapis, zastosowaną regułę, tożsamość decydenta, czas decyzji oraz wynik narzędzia. Osobno zadbaj o bezpieczne ponawianie operacji: gdy połączenie zerwie się po wysłaniu polecenia, najpierw ustal, czy skutek już nastąpił. Zgoda określa, czy działanie wolno wykonać; zapobieganie podwójnemu wykonaniu po awarii wymaga dodatkowo kontroli stanu lub mechanizmu idempotencji.

Przeczytaj także:

• Klucz dostępu chroni przed phishingiem, ale nie twórz go na wspólnym sprzęcie
• Agenci OpenAI wysłali 53 obrazy użytkowników na zewnętrzne serwisy
• GitHub zażąda ponownego logowania przed zmianą tokenu lub webhooka