Pe această pagină
Ia în calcul o sarcină ilustrativă în browser, cu o sută de pași. Presupune că fiecare pas reușește în 99 % dintre cazuri, independent de ceilalți. Probabilitatea ca toți pașii să funcționeze este 0.99^100, adică aproximativ 36,6 %.
Nouăzeci și nouă la sută sună excelent. Treizeci și șase la sută nu.
Discuția sursă despre sarcinile tranzacționale în browser folosește calculul pentru o idee precisă: clientul obține valoare când sarcina se termină, iar costul și riscul de eșec se acumulează la fiecare pas. Este aritmetică bazată pe o presupunere, nu o rată publicată de succes a vreunui agent de browser sau a unei sincronizări Tajo. Erorile reale pot depinde unele de altele. O autentificare expirată poate strica deodată mai multe acțiuni ulterioare.
Întrebarea utilă nu este „Cât de precis a fost ultimul clic al modelului?” Este „A apărut starea cerută de utilizator?”
Contează tranzacția întreagă
Imaginează-ți un agent care deschide un portal de asigurări, găsește un document, îl descarcă și confirmă că aparține contului corect. Poate naviga corect prin 99 de ecrane și totuși descărca fișierul greșit la al o sutălea. Un jurnal plin de clicuri reușite nu repară rezultatul.
Aceeași diferență se aplică unei integrări. Un agent poate descoperi un API, propune o mapare de câmpuri și salva o ciornă. Niciuna dintre aceste acțiuni nu înseamnă că un contact din destinație are acum starea de consimțământ dorită. Munca este gata doar după ce operațiunea aprobată a rulat și condiția sa finală relevantă a fost verificată.
Este diferența dintre activitate și finalizare. Activitatea se numără ușor. Finalizarea trebuie definită.
Pentru descărcarea unui fișier, definiția poate fi un document al cărui număr de cont corespunde cererii. Pentru sincronizarea unui contact, poate fi un profil în destinație cu identificatorul, câmpurile și starea permisiunii de comunicare corecte. Verificarea trebuie să examineze lucrul care îl interesa pe utilizator. Un răspuns pozitiv la apelul anterior dovedește că apelul a primit răspuns. Poate să nu dovedească faptul că destinația s-a schimbat cum trebuia.
Ghidul Tajo pentru conectarea instrumentelor de afaceri începe cu fluxul de lucru și sursa de adevăr pentru fiecare obiect de date. Aceste alegeri dau sens verificării finale. Dacă două sisteme pretind că dețin același câmp, chiar și o scriere executată impecabil poate produce o stare greșită pe termen lung.
Costul încă unei decizii
Cu aceeași presupunere ipotetică de 99 %, zece decizii independente dau aproximativ 90,4 % șanse de reușită a întregului lanț. Cincizeci dau aproximativ 60,5 %. O sută dau aproximativ 36,6 %.
Probabilitatea de reușită a întregului lanț (%)
Numărul de pași independenți
- Reușită presupusă de 99 % pe pas
Citește valorile calculate
| Pași | Reușita întregului lanț (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Curba coboară abrupt, fiindcă înmulțirea nu ține cont de o medie bună. Fiecare decizie în plus trebuie să își justifice locul.
Nu înseamnă că toate apelurile API trebuie înghesuite într-o singură operațiune uriașă. Unele apeluri sunt deterministe: citirea unei pagini cu un cursor cunoscut, compararea unui identificator sau scrierea unui câmp potrivit unei mapări aprobate. Modelul nu trebuie să le decidă din nou pentru fiecare înregistrare. Alte apeluri implică ambiguitate reală: un câmp nou al furnizorului, un mesaj de eroare schimbat sau o cerere cu proprietar neclar. Acestea pot avea nevoie de judecată.
Împărțirea practică este să lași judecata să proiecteze ori să repare regula, iar codul obișnuit să aplice regula stabilă. Reverse ETL este un exemplu util de mutare repetată a datelor: fluxul automat, nu o conversație, ar trebui să execute operațiunile obișnuite pentru fiecare rând. Agentul poate ajuta în continuare să decidă ce ar trebui să facă fluxul.
Aceasta este o graniță, nu un slogan. Dacă furnizorul schimbă sensul unui câmp, o regulă deterministă poate repeta perfect acțiunea greșită. Sistemul are nevoie de o cale prin care să detecteze schimbarea presupunerilor și să trimită cazul înapoi la verificare.
De ce un singur instrument mare nu este răspunsul
O obiecție corectă este: „Dacă lanțurile lungi eșuează, pune întreaga sarcină în spatele unui singur apel de instrument.” Ajută când instrumentul este o tranzacție bine definită, cu rezultat verificabil. Nu ajută când doar ascunde un proces lung și nesigur.
Să presupunem că syncCustomer() întoarce success: true după trimiterea unei actualizări. Dacă destinația procesează actualizările mai târziu, apelul nu poate dovedi încă starea finală a contactului. Instrumentul a redus pașii vizibili. Nu a redus incertitudinea.
O interfață mai bună arată starea care contează: primit, aplicat, verificat sau eșuat. Cuvintele trebuie să corespundă unor dovezi. O scriere primită poate fi suficientă pentru o previzualizare cu consecințe reduse. Un public de campanie sau o schimbare de consimțământ merită verificată în destinație înainte să fie numită finalizată.
În această vizualizare propusă Tajo, cererea acceptată și actualizarea aplicată sunt separate de starea verificată a destinației. Ultima verificare este în așteptare. Următoarea acțiune are un scop clar: inspectarea a ceea ce a stocat destinația. Încă un apel reușit al instrumentului ar lăsa fără răspuns întrebarea inițială.
O scriere încheiată are încă nevoie de dovezi
S-a încheiat sincronizarea clienților?
Scrierea a fost aplicată. Verificarea este în așteptare.
Starea din destinație nu a fost încă verificată.
Activitatea sincronizării
- Cerere acceptată
- Actualizare aplicată
- Verificarea destinației este în așteptare
Rulare exemplificativă · 14:32 UTC
Ce știm
- Răspunsul furnizorului
- Acceptată
- Rezultatul scrierii
- Aplicată
- Recitire din destinație
- În așteptare
Un apel reușit nu dovedește starea finală.
Aspect propus bazat pe fluxul de activitate Tajo. Ilustrația adaugă o stare de verificare; nu afirmă că recitirea din destinație este deja implementată.
Asta schimbă și măsurarea. Înregistrează numărul de încercări dacă ajută la diagnosticarea costului. Înregistrează erorile intermediare dacă indică un pas defect. Dar judecă fluxul după tranzacțiile finalizate și verificate, cu metoda de verificare lângă număr. O echipă care raportează „99 % dintre apeluri au reușit” nu a răspuns dacă utilizatorii și-au terminat treaba.
Explicația serverelor MCP arată cum instrumentele permit unui asistent să apeleze alt sistem. Accesul la instrument este doar începutul. Contractul este starea rămasă în urmă.
O sută de clicuri bune pot lăsa totul neterminat. Numără rezultatul.
Întrebări Frecvente
De ce eșuează un flux lung dacă pașii săi sunt de obicei corecți?
Dacă fiecare pas reușește independent cu probabilitatea p, șansa de reușită a unui lanț cu n pași este p la puterea n. La un procent presupus de 99 % pe pas, un lanț de o sută de pași se termină în aproximativ 36,6 % dintre cazuri. În realitate, eșecurile pot fi corelate, deci calculul este ilustrativ, nu o rată măsurată a agenților.
Mai puține apeluri de instrumente garantează fiabilitatea?
Nu. Ajută doar dacă operațiunea combinată păstrează verificările și punctele de recuperare potrivite. Un singur apel opac poate ascunde o scriere eșuată la fel cum un lanț lung își poate pierde locul.
Ce ar trebui să măsoare o echipă pentru un flux cu agenți?
Măsoară finalizarea verificată a tranzacției cerute de utilizator, nu doar apelurile reușite ale modelului. Definește artefactul sau starea destinației care dovedește finalizarea și apoi înregistrează cât de des apare după întregul flux.