På denna sida
Tänk dig en illustrativ webbläsaruppgift med hundra steg. Anta att varje steg lyckas i 99 % av fallen, oberoende av de andra. Sannolikheten att alla steg fungerar är 0.99^100, eller cirka 36,6 %.
Nittionio procent låter utmärkt. Trettiosex procent gör det inte.
Källdiskussionen om transaktionellt arbete i webbläsaren använder beräkningen för en avgränsad poäng: kunden får nytta när uppgiften är klar, medan kostnad och felrisk byggs på för varje steg. Det är matematik utifrån ett antagande, inte en publicerad framgångsgrad för någon webbläsaragent eller Tajo-synkronisering. Verkliga fel kan vara beroende av varandra. En utgången inloggning kan slå ut flera senare åtgärder samtidigt.
Den användbara frågan är alltså inte ”Hur träffsäker var modellens senaste klick?” utan ”Uppstod tillståndet som användaren bad om?”
Transaktionen är enheten som räknas
Tänk dig en agent som öppnar en försäkringsportal, hittar ett dokument, laddar ned det och bekräftar att det hör till rätt konto. Agenten kan navigera rätt genom 99 skärmar och ändå ladda ned fel fil på den hundrade. En logg full av lyckade klick rättar inte till resultatet.
Samma skillnad gäller en integration. En agent kan upptäcka ett API, föreslå en fältmappning och spara ett utkast. Inget av detta betyder att en kontakt i målsystemet nu har avsedd samtyckesstatus. Arbetet är klart först när den godkända åtgärden har körts och dess relevanta slutvillkor har kontrollerats.
Det är skillnaden mellan aktivitet och slutförande. Aktivitet är lätt att räkna. Slutförande måste definieras.
För en nedladdning kan definitionen vara en fil vars kontonummer stämmer med begäran. För en kontaktsynkronisering kan det vara en post med rätt identifierare, fält och tillåten status för meddelanden. Kontrollen måste granska det användaren faktiskt brydde sig om. Ett grönt svar på föregående anrop visar att anropet gav ett svar. Det visar kanske inte att målsystemet ändrades som avsett.
Tajos guide till att koppla ihop företagsverktyg börjar med arbetsflödet och vilken källa som är styrande för varje dataobjekt. De valen ger slutkontrollen mening. Om två system båda gör anspråk på att äga ett fält kan även en perfekt utförd skrivning ge fel långsiktigt tillstånd.
Kostnaden för ännu ett beslut
Med samma hypotetiska antagande om 99 % ger tio oberoende beslut ungefär 90,4 % chans att hela kedjan lyckas. Femtio ger ungefär 60,5 %. Hundra ger cirka 36,6 %.
Sannolikhet att hela kedjan lyckas (%)
Antal oberoende steg
- Antagna 99 % lyckade steg
Läs de beräknade värdena
| Steg | Hela kedjan lyckas (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Kurvan faller brant eftersom multiplikation inte tar hänsyn till ett fint genomsnitt. Varje extra beslut måste förtjäna sin plats.
Det betyder inte att varje API-anrop ska slås ihop till en enda stor åtgärd. Vissa anrop är deterministiska: hämta en sida med en känd markör, jämföra en identifierare eller skriva ett fält enligt en godkänd mappning. En modell behöver inte bestämma detta på nytt för varje post. Andra anrop innehåller verklig osäkerhet: ett nytt leverantörsfält, ett ändrat felmeddelande eller en begäran med oklar ägare. De kan kräva omdöme.
Den praktiska uppdelningen är att låta omdömet utforma eller reparera en regel och sedan låta vanlig kod tillämpa den stabila regeln. Reverse ETL är ett exempel på upprepad dataflytt: pipelinen, inte en konversation, ska utföra varje rutinmässig radåtgärd. En agent kan fortfarande hjälpa till att avgöra vad pipelinen ska göra.
Det här är en gräns, inte en slogan. Om en leverantör ändrar betydelsen av ett fält kan en deterministisk regel upprepa fel åtgärd perfekt. Systemet måste kunna upptäcka att antagandena ändrats och skicka fallet till granskning.
Varför ett enda stort verktyg inte är svaret
En rimlig invändning är: ”Om långa kedjor misslyckas, lägg hela uppgiften bakom ett enda verktygsanrop.” Det hjälper när verktyget är en väldefinierad transaktion med kontrollerbart resultat. Det hjälper inte när verktyget bara döljer en lång och osäker process.
Anta att syncCustomer() returnerar success: true efter att ha skickat en uppdatering. Om målsystemet behandlar uppdateringar senare kan anropet ännu inte bevisa kontaktens slutliga tillstånd. Verktyget minskade antalet synliga steg. Osäkerheten finns kvar.
Ett bättre gränssnitt visar det tillstånd som spelar roll: mottaget, tillämpat, kontrollerat eller misslyckat. Orden ska motsvara bevis. En mottagen skrivning kan räcka för en förhandsvisning med små konsekvenser. En kampanjmålgrupp eller ändrat samtycke förtjänar kontroll i målsystemet innan någon kallar arbetet klart.
I denna föreslagna Tajo-vy är en accepterad begäran och en genomförd uppdatering skilda från ett verifierat tillstånd i målsystemet. Den sista kontrollen väntar. Därför får nästa åtgärd ett syfte: att granska vad målsystemet lagrade. Ännu ett lyckat verktygsanrop skulle lämna den ursprungliga frågan obesvarad.
En slutförd skrivning behöver fortfarande belägg
Är kundsynkroniseringen klar?
Skrivning genomförd. Verifiering väntar.
Tillståndet i målsystemet har ännu inte kontrollerats.
Synkroniseringsaktivitet
- Begäran accepterad
- Uppdatering genomförd
- Kontroll av målsystemet väntar
Exempelkörning · 14:32 UTC
Det vi vet
- Leverantörens svar
- Accepterad
- Skrivresultat
- Genomförd
- Återläsning från målsystemet
- Väntar
Ett lyckat anrop bevisar inte sluttillståndet.
Föreslagen layout inspirerad av Tajos aktivitetsflöde. Illustrationen lägger till ett verifieringsläge; den hävdar inte att återläsning från målsystemet redan finns.
Det ändrar också vad du mäter. Registrera antalet försök om det hjälper att förstå kostnaden. Registrera mellanliggande fel om de pekar på ett trasigt steg. Men bedöm arbetsflödet utifrån verifierade, slutförda transaktioner och ange kontrollmetoden intill siffran. Ett team som rapporterar ”99 % av anropen lyckades” har inte svarat på om kunderna fick jobbet gjort.
Förklaringen av MCP-servrar visar hur verktyg låter en assistent anropa ett annat system. Verktygsåtkomst är bara början. Kontraktet är tillståndet som finns kvar.
Hundra bra klick kan ändå lämna ingenting. Räkna resultatet.
Vanliga Frågor
Varför misslyckas ett långt arbetsflöde när stegen oftast blir rätt?
Om varje steg lyckas oberoende med sannolikheten p, lyckas en kedja med n steg med sannolikheten p upphöjt till n. Med antagna 99 % per steg lyckas hundra steg i cirka 36,6 % av fallen. Verkliga fel kan hänga ihop, så beräkningen är inte en uppmätt träffsäkerhet för agenter.
Garanterar färre verktygsanrop högre tillförlitlighet?
Nej. Färre anrop hjälper bara om den samlade åtgärden fortfarande visar rätt kontroller och punkter för återhämtning. Ett enda ogenomskinligt anrop kan dölja en misslyckad skrivning.
Vad ska ett team mäta för ett agentflöde?
Mät om användarens transaktion verkligen har slutförts, inte bara om modellanrop lyckades. Definiera artefakten eller tillståndet i målsystemet som bevisar att jobbet är klart och följ hur ofta det uppstår efter hela flödet.