Človek v zanki: odobritve in eskalacije v agentic flowu

Razlikujte med odobritvijo in prevzemom primera

Človek v zanki pomeni, da ima poslovni proces načrtovano mesto za presojo ali prevzem dela. Uporabna predaja vsebuje konkreten predlog, razloge za ustavitev in možnost odločitve. Obvestilo »preverite odgovor AI« samo po sebi še ne oblikuje delujočega procesa.

Odobritev pomeni, da je predlog pripravljen, človek pa presodi konkretno nadaljnje dejanje. Eskalacija pomeni, da agent problema ni rešil v svojem obsegu in mora nekdo nadaljevati delo. Ta izhoda imata različne potrebe ter ne bi smela končati v isti nerazločljivi čakalni vrsti.

Pri hipotetičnem distributerju iz serije lahko prodajnik odobri pripravljen osnutek. Če identiteta izdelka ni jasna, primer prevzame produktni strokovnjak. Prvi pregleduje pripravljen rezultat, drugi mora pridobiti ali razložiti manjkajoče informacije. Obema pošljite ustrezen paket podatkov.

Dodajte še možnost zavrnitve in vrnitve v dopolnitev. »Ne« ni enoznačno. Lahko pomeni, da je predlog napačen, da manjka podatek ali da primera sploh ne bomo nadaljevali. Izbrani razlog mora določiti naslednjo fazo, da sistem ne pošilja istega predloga znova.

Mesto človeka določite glede na odločitev

V pregled vključite korake, pri katerih potrebujete poslovno presojo ali potrditev posledice. Ni treba potrjevati vsakega branja kataloga. Pomembno pa je, da ekipa ve, katere odločitve so delegirane agentu in katere ostajajo pri odgovorni osebi.

Načrtujte po vrstah nalog, ne zgolj po samooceni modela. Trditev »prepričan sem« ne nadomesti pravil o tem, kdo sme potrditi izjemo. Primeri zunaj podprte ponudbe ali z neskladnimi podatki lahko zahtevajo predajo ne glede na samozavesten ton odgovora.

Stopnjo pregleda prilagodite dokazom iz uporabe. Za dobro opredeljeno pripravo osnutka lahko po uspešnem pilotu zmanjšate rutinski pregled, če poslovni lastnik sprejme spremembo. Takšna odločitev naj velja za določen obseg, ne kot nedoločeno dovoljenje za vsa prihodnja dejanja.

Pripravite paket, o katerem je mogoče odločiti

Oseba naj prejme povzetek zahteve, predlagano dejanje, ciljni zapis, uporabljene podatke in odprta vprašanja. Pri ponudbi pokažite vsaj stranko, izdelke, količine, cenovno podlago in različico osnutka. Pregled ne sme zahtevati ponovnega sestavljanja primera iz desetih sporočil.

Poudarite razlike glede na zadnjo pregledano različico. Če je spremenjena samo količina, naj bo to jasno. Če se spremeni stranka ali vsebina ponudbe, gre za drugačen predmet odločitve. En sam gumb za potrditev brez vidne vsebine spodbuja rutinsko potrjevanje namesto dejanske presoje.

Microsoftove smernice za interakcijo človeka z AI vključujejo načrtovanje izkušnje ob napačnem vedenju in skozi čas uporabe. V poslovnem vmesniku to prevedemo v razumljive omejitve, vidne razloge za predajo ter preprosto popravljanje ali prevzem naloge.

Odločitev povežite s točno določeno različico

Potrditev naj se nanaša na identifikator primera in različico predloga. Če se po potrditvi spremenijo izdelki, cena ali prejemnik, sistem preveri, ali je odločitev še veljavna. Stara potrditev ne sme samodejno dovoliti vsebinsko drugačnega dejanja.

Pred nadaljevanjem preverite tudi stanje dejstev, ki lahko zastarajo. Za osnutek z včerajšnjimi podatki o zalogi je lahko potreben nov pregled razpoložljivosti. Pravila veljavnosti določite po naravi podatka; univerzalen časovni prag ne ustreza vsakemu procesu.

Dokumentacija OpenAI Agents SDK opisuje ohranjanje stanja pri dolgotrajnih odobritvah in različice čakajočih nalog. To je konkreten tehnični zgled, kako predaja lahko preživi prekinitev seje. Poslovni dogovor o tem, kaj je bilo potrjeno, pa mora še vedno določiti podjetje.

Premor mora ohraniti stanje in preprečiti dvojno izvedbo

Čakanje na človeka lahko traja dlje od spletne seje. Shranite fazo, predlog, že opravljena dejanja in pot nadaljevanja. Ko oseba odloči, se proces nadaljuje iz veljavnega stanja, ne začne celotne naloge od začetka brez preverjanja.

LangGraph opisuje prekinitve, pri katerih se stanje ohrani in izvajanje nadaljuje z zunanjim vhodom. Ne glede na izbrano ogrodje morate preveriti, kateri koraki se ob nadaljevanju lahko izvedejo ponovno. Zapis z zunanjim učinkom potrebuje zaščito pred podvojitvijo.

Preizkusite dvojni klik na potrditev, odločitev iz dveh odprtih oken in ponovni zagon po prekinitvi. Vsi trije primeri naj pripeljejo do enega dogovorjenega izida. Oseba mora jasno videti, ali je odločitev že sprejeta, zastarela ali izvedena.

Čakalna vrsta potrebuje lastnika in način razporejanja

Predaja v splošni kanal brez lastnika lahko samo prestavi zastoj. Določite primarnega prevzemnika, nadomestilo ob odsotnosti in način označitve nujnosti. Dogovor naj sledi dejanski organizaciji dela, vključno z urnikom in razpoložljivostjo strokovnjakov.

Merite čas čakanja ločeno od časa pregleda. Velika razlika pokaže težavo pri razporejanju, ne nujno pri kakovosti agenta. Spremljajte tudi starost najstarejših odprtih primerov. Povprečje lahko prikrije nekaj nalog, ki se nikoli ne premaknejo naprej.

Ob pretečenem dogovorjenem roku določite naslednji korak. To je lahko obvestilo nadomestni osebi ali ročni prevzem procesa. Izostanek odgovora ne sme samodejno pomeniti potrditve, razen če je takšno poslovno pravilo izrecno dogovorjeno za konkretno vrsto naloge.

Povratne informacije uporabite za izboljšanje poti

Pri zavrnitvah beležite razlog: napačen izdelek, napačen vir, nepopoln predlog ali primer zunaj obsega. Če večina predaj nastane zaradi istega manjkajočega polja, je lahko najboljša rešitev boljši vhodni obrazec. Dodaten model ne odpravi nujno procesnega vzroka.

Ocenjujte tudi delo pregledovalcev. Če vedno popravijo isto obliko izhoda, prilagodite predlogo. Če za presojo potrebujejo podatek, ki ga agent ne priloži, dopolnite paket predaje. Uspeh ni samo manj predaj, ampak manj nepotrebnega dela ob ohranjeni kakovosti.

Ne zamenjajte visoke stopnje potrditev z dokazom pravilnosti. Ljudje lahko predlog potrjujejo rutinsko. Občasno preverite vzorec potrjenih primerov in ugotovite, ali so bila dogovorjena merila res izpolnjena. Pregled mora preverjati rezultat, ne le obstoj klika.

Primer delovnega zaslona za pregledovalca

Na vrhu kartice pokažite, kaj oseba odloča: »Pregled osnutka ponudbe za primer X, različica 3«. Sledi kratka razlika glede na prejšnjo različico, na primer nova količina pri eni postavki. Pregledovalec mora takoj vedeti, ali gre za rutinski pregled pripravljenega dela ali za vprašanje, ki zahteva dodatno strokovno presojo.

Pod predlogom pokažite podatkovno podlago in čas preverjanja dejstev, ki so pomembna za odločitev. Če je izdelek zgolj predlagano ujemanje, ga tako tudi označite. Osebi ne prikazujte dolge zgodovine celotnega pogovora kot edinega načina preverjanja. Bolj uporabne so neposredne povezave do ustreznih zapisov ter jasno navedene odprte točke.

Na voljo naj bodo smiselne poti: potrdi pripravljeni predlog, popravi in ponovno preveri, zahtevaj dopolnitev ali zavrni primer. Izbira naj spremeni status in določi naslednjega lastnika. Če oseba zapre zaslon brez odločitve, primer ostane v jasnem stanju čakanja. Zaprt zaslon ni poslovni dogodek potrditve.

Pred izvedbo nadaljevanja aplikacija preveri, ali se kartica še nanaša na trenutno različico. Če je drug sodelavec medtem spremenil postavko, pokaže razliko in zahteva ustrezno novo presojo. Tako ohranite povezavo med tem, kar je človek videl, tem, kar je odločil, in tem, kar bo sistem dejansko izvedel.

Predajo preverite kot samostojen produktni del

Na prevzemu pokažite popoln krog: agent pripravi predlog, oseba ga popravi, sistem shrani novo različico in izvede ustrezno nadaljevanje. Dodajte zastarel predlog, odsotnega prevzemnika in nepopolno odločitev. Vsak primer mora imeti razumljiv zaključek.

Pri NUMEDIA zasnova agentov vključuje tudi delovno mesto človeka, ki primer prevzame. To pomeni uporabna obvestila, ohranjene podatke in jasno stanje. Dobro urejena predaja lahko odloča o uporabnosti celotne rešitve bolj kot še ena dodatna funkcija agenta.

Ko predaje delujejo, je naslednje vprašanje operativni obseg uvedbe. V zadnjem delu serije pokažemo, kako preiti iz zgodovinskih primerov v spremljani pilot in nato širiti uporabo brez izgube pregleda nad rezultati.

Viri in metodologija

1. Guidelines for Human-AI Interaction (Microsoft, dostop 2026-10-19)
2. Interrupts (LangChain, dostop 2026-10-19)
3. Human-in-the-loop (OpenAI Agents SDK, dostop 2026-10-19)

Pogosta vprašanja