Na tejto stránke
Predstavte si ilustratívnu úlohu v prehliadači so sto krokmi. Predpokladajme, že každý krok uspeje v 99 % prípadov nezávisle od ostatných. Pravdepodobnosť, že sa podaria všetky kroky, je 0.99^100, teda asi 36,6 %.
Deväťdesiatdeväť percent znie výborne. Tridsaťšesť percent už nie.
Zdrojová diskusia o transakčnej práci v prehliadači používa tento výpočet na úzky záver: zákazník získava hodnotu po dokončení úlohy, zatiaľ čo náklady a riziko zlyhania rastú s každým krokom. Je to aritmetika založená na predpoklade, nie zverejnená úspešnosť konkrétneho prehliadačového agenta ani synchronizácie Tajo. Skutočné chyby môžu byť závislé. Jedno vypršané prihlásenie môže naraz pokaziť viac neskorších akcií.
Užitočná otázka teda nie je „Aké presné bolo posledné kliknutie modelu?“, ale „Vznikol stav, ktorý používateľ požadoval?“.
Dôležitou jednotkou je transakcia
Predstavte si agenta, ktorý otvorí poistný portál, nájde dokument, stiahne ho a potvrdí, že patrí k správnemu účtu. Môže správne prejsť 99 obrazovkami a na 100. obrazovke stiahnuť nesprávny súbor. Zoznam úspešných kliknutí výsledok neopraví.
Rovnaký rozdiel platí pre integráciu. Agent môže nájsť API, navrhnúť mapovanie polí a uložiť návrh. Nič z toho ešte neznamená, že kontakt v cieľovom systéme má zamýšľaný stav súhlasu. Práca sa skončí až po vykonaní schválenej operácie a overení príslušnej výslednej podmienky.
Je to rozdiel medzi činnosťou a dokončením. Činnosť sa počíta ľahko. Dokončenie vyžaduje definíciu.
Pri stiahnutom súbore môže byť dôkazom artefakt, ktorého číslo účtu zodpovedá požiadavke. Pri synchronizácii kontaktu cieľový záznam so správnym identifikátorom, poľami a povoleným stavom komunikácie. Kontrola musí skúmať to, na čom používateľovi záležalo. Zelená odpoveď predchádzajúceho volania dokazuje, že volanie vrátilo odpoveď. Nemusí dokazovať, že sa cieľ zmenil podľa zámeru.
Sprievodca prepájaním firemných nástrojov Tajo začína pracovným postupom a zdrojom pravdy pre každý dátový objekt. Tieto rozhodnutia dávajú záverečnej kontrole význam. Ak si dva systémy nárokujú vlastníctvo toho istého poľa, aj technicky dokonalý zápis môže vytvoriť nesprávny dlhodobý stav.
Cena ďalšieho rozhodnutia
Pri rovnakom hypotetickom predpoklade 99 % dá desať nezávislých rozhodnutí úspešnosť celého reťazca približne 90,4 %. Päťdesiat dá asi 60,5 %. Sto dá približne 36,6 %.
Úspešnosť celého reťazca (%)
Počet nezávislých krokov
- Predpoklad: 99 % úspech na krok
Vypočítané hodnoty
| Kroky | Úspech celého reťazca (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Krivka prudko klesá, lebo násobenie nemá ohľad na dobrý priemer. Každé ďalšie rozhodnutie si musí zaslúžiť svoje miesto.
Neznamená to, že všetky volania API treba zlúčiť do jednej obrovskej operácie. Niektoré sú deterministické: načítanie stránky so známym kurzorom, porovnanie identifikátora alebo zápis poľa podľa schváleného mapovania. Model o nich nemusí znovu rozhodovať pri každom zázname. Iné volania prinášajú skutočnú nejednoznačnosť: nové pole dodávateľa, zmenené chybové hlásenie alebo požiadavku s nejasným vlastníkom. Tie môžu potrebovať úsudok.
Praktické rozdelenie je nechať úsudok navrhnúť či opraviť pravidlo a bežný kód používať stabilné pravidlo. Reverzné ETL je príkladom opakovaného presunu dát: bežnú operáciu nad každým riadkom má robiť pipeline, nie rozhovor. Agent stále môže pomôcť rozhodnúť, čo má pipeline robiť.
Toto je hranica, nie heslo. Ak dodávateľ zmení význam poľa, deterministické pravidlo môže dokonale opakovať nesprávnu akciu. Systém musí vedieť rozpoznať zmenu predpokladov a vrátiť prípad na preskúmanie.
Prečo jedno veľké volanie nestačí
Rozumná námietka znie: „Ak dlhé reťazce zlyhávajú, skryme celú úlohu za jedno volanie nástroja.“ Pomôže to, ak je nástroj jasne vymedzenou transakciou s overiteľným výsledkom. Zlyhá to, ak iba schová dlhý neistý postup.
Predpokladajme, že syncCustomer() vráti success: true po odoslaní aktualizácie. Ak cieľ spracúva aktualizácie neskôr, volanie zatiaľ nedokazuje konečný stav kontaktu. Nástroj znížil počet viditeľných krokov. Neznížil neistotu.
Lepšie rozhranie rozlišuje dôležité stavy: prijaté, použité, overené alebo zlyhané. Každé slovo má zodpovedať dôkazu. Prijatý zápis môže stačiť pri menej dôsledkovom náhľade. Publikum kampane alebo zmena súhlasu si zaslúži kontrolu cieľa skôr, než ju niekto nazve dokončenou.
V tomto navrhovanom pohľade Tajo sú prijatá požiadavka a vykonaná zmena oddelené od overeného stavu v cieľovej službe. Posledná kontrola čaká. Ďalší krok má jasný účel: zistiť, čo cieľ uložil. Ďalšie úspešné volanie nástroja by pôvodnú otázku nezodpovedalo.
Dokončený zápis stále potrebuje dôkaz
Skončila sa synchronizácia zákazníkov?
Zápis sa vykonal. Overenie čaká.
Stav v cieľovej službe sa zatiaľ neskontroloval.
Aktivita synchronizácie
- Požiadavka prijatá
- Zmena vykonaná
- Kontrola cieľovej služby čaká
Ukážkové spustenie · 14:32 UTC
Čo vieme
- Odpoveď poskytovateľa
- Prijaté
- Výsledok zápisu
- Vykonané
- Spätné načítanie z cieľa
- Čaká
Úspešné volanie nedokazuje konečný stav.
Navrhované rozloženie vychádza z prehľadu aktivity Tajo. Ilustrácia pridáva stav overenia; netvrdí, že spätné načítanie z cieľa už bolo implementované.
Mení to aj meranie. Počet pokusov zaznamenajte, ak pomáha diagnostikovať náklady. Medzichyby zaznamenajte, ak ukazujú poškodený krok. Postup však hodnoťte podľa overených dokončených transakcií a vedľa čísla uvádzajte spôsob overenia. Tím hlásiaci „99 % volaní uspelo“ stále neodpovedal, či zákazníci dostali hotovú prácu.
Vysvetlenie serverov MCP ukazuje, ako nástroje umožňujú asistentovi volať iný systém. Prístup k nástroju je len začiatok. Zmluvou je stav, ktorý po práci zostane.
Sto dobrých kliknutí môže nezanechať nič. Počítajte výsledok.
Často Kladené Otázky
Prečo dlhý postup zlyháva, keď sú jeho kroky zvyčajne správne?
Ak každý krok uspeje nezávisle s pravdepodobnosťou p, celý reťazec s n krokmi uspeje s pravdepodobnosťou p na n-tú. Pri predpokladaných 99 % na krok dokončí sto krokov asi 36,6 % prípadov. Skutočné chyby môžu spolu súvisieť, takže výpočet je ilustrácia, nie nameraná úspešnosť agenta.
Zaručí menej volaní nástrojov vyššiu spoľahlivosť?
Nie. Menej volaní pomôže iba vtedy, ak spojená operácia stále poskytuje potrebné kontroly a body obnovy. Jediné neprehľadné volanie môže skryť neúspešný zápis rovnako ako dlhý reťazec môže stratiť nadväznosť.
Čo má tím merať pri postupe agenta?
Merajte overené dokončenie transakcie požadovanej používateľom, nielen úspešné volania modelu. Určite artefakt alebo cieľový stav dokazujúci dokončenie práce a sledujte, ako často vznikne po celom postupe.