Na tej strani
Poglejmo ponazoritveno nalogo v brskalniku s stotimi koraki. Predpostavimo, da vsak korak uspe v 99 % primerov in da so uspehi neodvisni. Verjetnost, da uspejo vsi koraki, je 0.99^100, torej približno 36,6 %.
Devetindevetdeset odstotkov zveni odlično. Šestintrideset odstotkov ne.
Razprava o transakcijskih opravilih v brskalniku s tem izračunom poudari omejeno, a pomembno razliko: uporabnik dobi vrednost, ko je naloga dokončana, stroški in tveganje napake pa se kopičijo pri vsakem koraku. To je račun pod določeno predpostavko, ne objavljena stopnja uspešnosti kateregakoli brskalniškega agenta ali sinhronizacije Tajo. Resnične napake so lahko medsebojno odvisne. Ena potekla prijava lahko hkrati prekine več poznejših dejanj.
Zato koristno vprašanje ni „Kako natančen je bil zadnji klik modela?“, temveč „Ali se je pojavilo stanje, ki ga je uporabnik zahteval?“
Pomembna enota je transakcija
Predstavljajte si agenta, ki odpre zavarovalniški portal, poišče dokument, ga prenese in potrdi, da pripada pravemu računu. Lahko pravilno prehodi 99 zaslonov, nato pa na stotem prenese napačno datoteko. Dnevnik uspešnih klikov rezultata ne popravi.
Enaka razlika velja pri integraciji. Agent lahko odkrije API, predlaga preslikavo polj in shrani osnutek. Nobeno od teh dejanj še ne pomeni, da ima stik v ciljnem sistemu zdaj predvideno stanje privolitve. Delo je končano šele, ko se odobrena operacija izvede in se preveri ustrezni končni pogoj.
Gre za razliko med dejavnostjo in dokončanjem. Dejavnost je lahko šteti. Dokončanje morate najprej opredeliti.
Pri prenosu datoteke je dokaz morda artefakt, katerega številka računa ustreza zahtevi. Pri sinhronizaciji stika je to lahko zapis v ciljnem sistemu s pravilnim identifikatorjem, polji in dovoljenim statusom sporočanja. Pregled mora preveriti tisto, kar je bilo uporabniku pomembno. Zelen odgovor prejšnjega klica dokazuje, da se je klic vrnil. Morda pa ne dokazuje, da se je ciljni sistem spremenil, kot je bilo predvideno.
Tajov vodnik za povezovanje poslovnih orodij izhaja iz poteka dela in vira resnice za posamezen podatkovni objekt. Ti odločitvi določata pomen končnega pregleda. Če dva sistema oba zahtevata lastništvo istega polja, lahko tudi brezhibno izveden zapis dolgoročno povzroči napačno stanje.
Cena še ene odločitve
Pri isti hipotetični predpostavki 99 % na korak deset neodvisnih odločitev pomeni približno 90,4 % uspeha celotne verige. Petdeset jih pomeni približno 60,5 %, sto pa približno 36,6 %.
Verjetnost uspeha celotne verige (%)
Število neodvisnih korakov
- Predpostavljena 99-odstotna uspešnost na korak
Preglejte izračunane vrednosti
| Koraki | Uspeh celotne verige (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Krivulja hitro pada, ker množenje ne upošteva dobrega povprečja. Vsaka dodatna odločitev mora upravičiti svojo vlogo.
To ne pomeni, da morate vsak klic API združiti v eno ogromno operacijo. Nekateri klici so deterministični: pridobivanje strani z znanim kazalcem, primerjava identifikatorja ali zapis polja po odobreni preslikavi. Modelu se o njih ni treba znova odločati pri vsakem zapisu. Drugi klici prinašajo resnično dvoumnost: novo polje ponudnika, spremenjeno sporočilo o napaki ali zahtevo z nejasnim lastnikom. Ti morda zahtevajo presojo.
Praktična razdelitev je, da presoja oblikuje ali popravi pravilo, običajna koda pa nato uporabi stabilno pravilo. Obratni ETL je uporaben primer ponavljajočega se prenosa podatkov: rutinsko obdelavo vsake vrstice naj izvaja cevovod, ne pogovor. Agent lahko še vedno pomaga odločiti, kaj naj cevovod počne.
To je meja, ne slogan. Če ponudnik spremeni pomen polja, lahko deterministično pravilo popolno ponavlja napačno dejanje. Sistem mora zaznati, da so se njegove predpostavke spremenile, in primer vrniti v pregled.
Zakaj en sam velik klic orodja ni odgovor
Pošten ugovor je: „Če dolge verige odpovedujejo, postavimo celotno nalogo za en klic orodja.“ To pomaga, kadar je orodje dobro opredeljena transakcija s preverljivim rezultatom. Ne pomaga pa, kadar samo skrije dolg, negotov proces.
Recimo, da syncCustomer() po poslanem popravku vrne success: true. Če ciljni sistem posodobitve obdela šele pozneje, klic še ne more dokazati končnega stanja stika. Orodje je zmanjšalo število vidnih korakov. Ni zmanjšalo negotovosti.
Boljši vmesnik razkrije pomembno stanje: sprejeto, uporabljeno, preverjeno ali neuspešno. Vsaka beseda naj ustreza dokazu. Sprejet zapis je morda dovolj za predogled z majhnimi posledicami. Občinstvo kampanje ali sprememba privolitve si zasluži pregled ciljnega sistema, preden jo kdo označi za dokončano.
V tem predlaganem prikazu Tajo sta sprejeta zahteva in izvedena sprememba ločeni od potrjenega stanja v cilju. Končno preverjanje še čaka. Naslednje dejanje ima jasen namen: ugotoviti, kaj je cilj shranil. Še en uspešen klic orodja ne bi odgovoril na prvotno vprašanje.
Opravljen zapis še vedno potrebuje dokaz
Ali se je sinhronizacija strank končala?
Zapis je bil izveden. Preverjanje še čaka.
Stanje v cilju še ni bilo preverjeno.
Dejavnost sinhronizacije
- Zahteva sprejeta
- Sprememba izvedena
- Preverjanje cilja še čaka
Vzorčni zagon · 14:32 UTC
Kaj vemo
- Odgovor ponudnika
- Sprejeto
- Rezultat zapisa
- Izvedeno
- Ponovno branje iz cilja
- Čaka
Uspešen klic ne dokazuje končnega stanja.
Predlagani prikaz temelji na toku dejavnosti Tajo. Ponazoritev doda stanje preverjanja; ne trdi, da je ponovno branje iz cilja že uvedeno.
To spremeni tudi merjenje. Število poskusov beležite, če pomaga razumeti stroške. Vmesne napake beležite, če pokažejo okvarjen korak. Potek dela pa presojajte po preverjeno dokončanih transakcijah, pri čemer način preverjanja zapišite ob številki. Ekipa, ki poroča „99 % klicev je uspelo“, še ni odgovorila, ali so uporabniki dobili opravljeno delo.
Razlaga strežnikov MCP pokaže, kako lahko pomočnik z orodji pokliče drug sistem. Dostop do orodja je šele prvi korak. Pogodba je stanje, ki ostane za njim.
Sto dobrih klikov lahko še vedno ne pusti ničesar. Štejte rezultat.
Pogosto Zastavljena Vprašanja
Zakaj dolg potek dela odpove, če so posamezni koraki običajno pravilni?
Če vsak korak uspe neodvisno z verjetnostjo p, je verjetnost uspeha verige z n koraki enaka p na n-to potenco. Pri predpostavljenih 99 % na korak se veriga stotih korakov dokonča v približno 36,6 % primerov. Resnične napake so lahko povezane, zato gre za ponazoritev in ne za izmerjeno uspešnost agentov.
Ali manj klicev orodij zagotavlja zanesljivost?
Ne. Manj klicev pomaga le, če združena operacija še vedno omogoča prave preglede in točke za odpravo napak. En sam nepregleden klic lahko prikrije neuspešen zapis prav tako kot dolga veriga izgubi pregled nad svojim stanjem.
Kaj naj ekipa meri pri poteku dela z agentom?
Merite preverjen zaključek uporabnikove transakcije, ne le uspešnih klicev modela. Določite artefakt ali stanje ciljnega sistema, ki dokazuje dokončano delo, in zabeležite, kako pogosto se pojavi po celotnem poteku.