Programmerbare forhåndsbetingelser

En programmatisk forutsetning er et faktum som må være etablert i verifisert tilstand før en sensitiv handling kan fortsette. I vårt tilfelle blokkeres refusjonen til get_customer har returnert en post med en verifisert identitet.

Dette handler ikke om at modellen lover at den har kontrollert noe. Det er koden din som observerer de faktiske verktøyresultatene og nekter å kjøre process_refund med mindre verifiseringsfaktumet faktisk er til stede. Garantien kommer fra dataene, ikke fra modellens beskrivelse.

For å kontrollere et verktøy må du vite hvor i løkken du skal gripe inn. For hver tur sender du hele meldingshistorikken, undersøker stop_reason, og hvis den er tool_use, kjører du det forespurte verktøyet, legger til resultatet og kjører løkken på nytt til end_turn.

Forutsetningen ligger i steget «kjør det forespurte verktøyet». Når modellen ber om process_refund, undersøker koden din den akkumulerte tilstanden før verktøyet kjøres. Modellen foreslår; koden din avgjør.

Forutsetningen trenger en sannhetskilde. Oppbevar et lite tilstandsobjekt på serversiden som registrerer det som faktisk er etablert i denne samtalen — ikke det modellen sa at den gjorde.

Når get_customer returnerer, leser dispatcher-en den faktiske nyttelasten og setter et flagg bare hvis posten faktisk er verifisert. Denne tilstanden er beviset for kontrollen.

Nå kobler du inn forutsetningen. Når modellen ber om process_refund, kontrollerer koden din state["identity_verified"] først. Hvis faktumet ikke er etablert, kaller du ikke refusjonsbackend-en — du returnerer et strukturert verktøyresultat som forteller modellen hvorfor det ble blokkert, og hva den skal gjøre videre.

Det er avgjørende at du returnerer dette som et normalt verktøyresultat som modellen kan lese og handle på, ikke som et kastet unntak som krasjer løkken.

En generell feil som "Operation failed" hindrer gjenoppretting — modellen kan ikke se hvorfor det feilet eller hva den skal gjøre videre. En strukturert feil muliggjør intelligent ruting.

Ta med: isError: true, en errorCategory (transient / validation / business / permission), isRetryable, en menneskelesbar message og helst handlingen som ble forsøkt. Her er kategorien permission, og isRetryable er false til forutsetningen er oppfylt — slik vet modellen at den først må verifisere, i stedet for å prøve refusjonen på nytt uten å tenke.

Kontrollen i dispatcher-en ovenfor er én form for forutsetning. Til eksamen forventes det også at du kjenner til hooks for den samme oppgaven. En hook for utgående kall fanger opp et verktøyinvokasjonskall og kan blokkere en handling som bryter med retningslinjene — for eksempel en refusjon på over 500 dollar eller enhver refusjon på en uverifisert konto.

Hooks er 100 % deterministiske; prompter er probabilistiske på rundt 90 %. En PostToolUse-hook kan også fange opp et verktøyresultat før modellen i det hele tatt ser det. Uansett håndheves garantien i kode som modellen ikke kan snakke seg rundt.

En reell policy er ofte sammensatt: Blokker refusjonen med mindre identiteten er verifisert OG beløpet er innenfor den tillatte grensen. Begge kontrollene er deterministiske forutsetninger; ingen av dem hører hjemme i en prompt.

Verifiseringskontrollen beskytter hvem; terskelkontrollen beskytter hvor mye. Et brudd på en av dem returnerer et strukturert og handlingsrettet resultat — eskaler til et menneske i terskeltilfellet, eller send modellen tilbake for å verifisere i identitetstilfellet.

En forutsetning er en korrekthetsgaranti — den sikrer at et bestemt faktum gjelder før en bestemt handling. Ikke forveksle den med løkkens sikkerhetsnett.

• Du skal fortsatt avslutte basert på stop_reason, aldri ved å lete etter ord som «ferdig» eller «verifisert» i teksten.
• Iterasjonsgrenser er et sikkerhetsnett mot løkker som løper løpsk, aldri den primære stoppmekanismen — og aldri måten du håndhever forretningsregler på.

Forutsetningen er målrettet: Den styrer én handling basert på ett verifisert faktum, deterministisk, mens modellen fortsatt driver samtalen.

Her er enda en arkitekturfelle. En verifiseringsforutsetning er en blokkerende og tidssensitiv kontroll — refusjonen kan ikke fortsette før den er avklart i den aktive samtalen.

Det utelukker Message Batches API: Den er 50 % billigere, men har et tidsvindu på opptil 24 timer, ingen SLA for forsinkelse og ingen verktøykall over flere turer. Batch er for nattlige revisjoner og rapporter, aldri for en innebygd kontroll som en kunde venter på. Kjør forutsetninger synkront i den agentiske løkken.

Viktige punkter om programstyrte forhåndsbetingelser:

• Penger, juss og sikkerhet → deterministisk. Instruksjoner treffer omtrent 90 %; hooks og forhåndsbetingelser i kode treffer 100 %.
• Bruk bekreftede fakta som vilkår, ikke fortellinger. Spor den faktiske tilstanden fra get_customer; blokker process_refund til identity_verified er true.
• Grip inn i løkken. Kontroller før verktøyet modellen ba om, kjøres; bruk en hook til å blokkere brudd på regler, for eksempel refusjoner over $500.
• Feil må ha struktur. Returner isError, errorCategory, isRetryable og en tydelig melding slik at modellen kan komme seg videre.
• Hold det synkront. Avslutt ved stop_reason, aldri ved iterasjonsgrenser eller teksttolking – og bruk aldri Batch API for blokkerende kontroller.