Jak zaprojektować sprawy, które agent przekazuje człowiekowi

Wyzwalacze, które da się spisać i przetestować

• Zastrzeżone przez politykę: reklamacje wspominające kroki prawne, sprawy klientów oznaczonych jako szczególnie wrażliwi, wszystko, o czym według twoich zasad decyduje człowiek
• Brakujące albo sprzeczne informacje, których nie wyjaśnił jeden krok doprecyzowujący
• Awaria systemu poza budżetem ponowień i każdy zapis o nieznanym wyniku
• Nieznana sprawa: szablon dokumentu, typ dostawcy albo język, których brak w zestawie testowym
• Przekroczony budżet kroków albo kosztów; przewodnik Anthropic o agentach opisuje to jako warunek zatrzymania, na przykład maksymalną liczbę iteracji
• Klient prosi o kontakt z człowiekiem

Zwróć uwagę, czego brakuje: deklarowanej pewności modelu jako jedynego wyzwalacza. Pewność deklarowana przez model nie jest domyślnie skalibrowana. Może dodawać eskalacje, ale powyższa lista nie powinna od niej zależeć.

Testuj eskalację w obu kierunkach

Eskalacja może zawieść na dwa sposoby. Niepotrzebne przekazanie kosztuje czas przeglądu i podkopuje zaufanie do agenta. Pominięte przekazanie pozwala agentowi dokończyć sprawę, której nie powinien był ruszać, co zwykle kosztuje więcej. Przewodnik Anthropic po ewaluacji agentów zaleca testowanie zarówno tego, kiedy zachowanie powinno wystąpić, jak i tego, kiedy nie powinno. Przy eskalacjach zestaw testowy potrzebuje spraw, które trzeba przekazać, i podobnych spraw, których przekazywać nie wolno, a wyniki należy raportować osobno.

Co zawiera przekazanie

Poniższy format to szkic dla hipotetycznego agenta przyjmującego zgłoszenia szkód. Ma być wyświetlany w narzędziu, w którym człowiek i tak pracuje, a nie czytany jako surowe dane.

case_id: clm-40517
reason: CONTRADICTORY_INFORMATION
question_for_reviewer: >
  Damage date on the form (12 Aug) is before the policy start (15 Aug).
  The photos are dated 18 Aug. Which date applies?
done:
  - claim created, status awaiting_assessment (ref CL-889120)
failed: []
unknown:
  - acknowledgement email: send timed out, delivery not confirmed
not_done:
  - coverage check, blocked on the date question
proposed_next_step: >
  If 18 Aug applies, run coverage check. If 12 Aug applies,
  decline under clause 4.2 after review.
evidence: [form.pdf, photo_metadata.json, policy_P-2.pdf]
agent_version: claims-intake 2026.10.2
answer_due_by: next working day 12:00

Dwa pola niosą większość wartości. Pytanie powinno być takie, na które człowiek może odpowiedzieć, a nie mglistą prośbą o przejrzenie sprawy. Lista niewiadomych mówi, które efekty zewnętrzne mogły nastąpić albo nie, żeby człowiek sprawdził to, zanim cokolwiek powtórzy.

Kolejka po drugiej stronie

Kolejka eskalacji potrzebuje właściciela, kierowania według powodu, żeby każdą sprawę zobaczył właściwy specjalista, i celu określającego, jak długo sprawa może czekać. SRE Workbook Google'a traktuje takie cele jako stosunek dobrych zdarzeń do wszystkich, ze spisaną zasadą na wypadek ich niespełnienia, i ta sama struktura sprawdza się dla wieku kolejki.

Ustal, czy człowiek kończy sprawę, czy odpowiada na pytanie i ją zwraca. Zwrot działa, gdy stan agenta jest zapisany: na przykład interrupt() w LangGraph wstrzymuje przebieg, aż zostanie wznowiony z odpowiedzią człowieka. W obu wariantach agent po eskalacji nie może już niczego zapisywać w sprawie.

Czego uczą eskalacje

Zapisuj, jak człowiek rozwiązał każdą sprawę, w ustrukturyzowanym polu zamiast wolnego tekstu. Po kilku tygodniach powody pokażą, gdzie jest praca. Jeśli większość eskalacji pochodzi z jednego zawodnego wyszukiwania, napraw narzędzie. Jeśli z jednego szablonu dokumentu, dodaj dla niego sprawy do zestawu testowego. Jeśli ludzie za każdym razem rozwiązują daną kategorię tak samo, może być gotowa dla agenta, gdy przejdzie testy.

Gdzie projekt eskalacji się sypie

Najczęstsze porażki są organizacyjne: kolejka bez właściciela, eskalacja jako śmietnik na każdą niewygodną sprawę, recenzent bez dostępu do systemu, z którego korzystał agent, albo przekazanie trafiające do osobnego narzędzia, do którego nikt nie zagląda. Wytyczne Microsoftu dotyczące transakcji kompensujących mówią coś podobnego o nieudanych operacjach: gdy potrzebna jest ręczna interwencja, alarm powinien zawierać szczegółowy powód. Dobry pierwszy krok to spisanie obecnych powodów eskalacji, dopisanie do każdego pytania, na które człowiek musiałby odpowiedzieć, i sprawdzenie, czy agent potrafi je sformułować.