Af Greg Nowak. Opdateret den 17. august 2026.
En langvarig AI-anmodning kan nu fortsætte, efter at en browsersession er afsluttet, eller en kort HTTP-timeout er udløbet. Det er nyttigt til dokumentgennemgang, research, berigelse af data, udarbejdelse af rapporter, prioritering af supportsager og andet arbejde, der kan tage minutter frem for sekunder.
Men asynkron afvikling gør ikke den omgivende forretningsproces driftssikker. Modellen kan afslutte opgaven korrekt, mens CRM-systemet er utilgængeligt, en godkendelse stadig afventes, eller den samme afslutningshændelse leveres to gange. En bruger kan også annullere arbejdet, efter at en ekstern opdatering allerede er gennemført. Produktionssystemer har derfor brug for to separate begreber: AI-svaret og det operationelle job, der er ansvarligt for at bruge det.
Background mode løser én type fejl
OpenAI’s Responses API understøtter afvikling i baggrunden ved at sætte background til true. Applikationen kan poll’e svaret, mens dets status er queued eller in_progress, modtage en webhook, når opgaven er afsluttet, og annullere et igangværende svar. En aktuel minimal anmodning ser sådan ud:
curl https://api.openai.com/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "gpt-5.6",
"input": "Prepare the monthly variance review.",
"background": true
}'Det betyder, at en kompleks modelopgave ikke længere afhænger af én ubrudt klientforbindelse. Det registrerer ikke, om økonomiafdelingen har godkendt resultatet, om en kunde er blevet underrettet, eller om en opdatering allerede er skrevet til et andet system.
Datahåndteringen bør også kontrolleres udtrykkeligt under indkøbsprocessen. OpenAI’s aktuelle dokumentation oplyser, at baggrundsanmodninger kan bruge store=false. I projekter med Zero Data Retention gemmes svardata midlertidigt i cirka ti minutter for at understøtte asynkron afvikling og polling. Kontrollér denne adfærd i forhold til organisationens egne kontrakt- og compliancekrav, før følsomt materiale sendes.
Giv forretningsprocessen sin egen jobpost
Opret et internt job, før modellen kaldes. Registrér som minimum et job-ID, jobtype, den bruger, der har anmodet om jobbet, rettighedskontekst, inputversion, tilsigtet sideeffekt, idempotensnøgle, AI-svar-ID, antal genforsøg, tidsstempler og eksterne post-ID’er.
Jobbet bør have forretningsmæssigt forståelige statusser såsom queued, running, awaiting_approval, applying, completed, failed og cancelled. Kopiér ikke udbyderens svarstatus direkte ind i brugerfladen: »response completed« betyder måske kun, at et udkast er klar til gennemgang.
| Opgavemønster | Minimumskontrol | Fornuftigt fundament |
|---|---|---|
| Privat udkast, der returneres til én bruger | Permanent jobpost og status, der kan gendannes | Databasebaseret worker |
| Én opdatering i et CRM-, helpdesk- eller CMS-system | Idempotent skrivning, begrænsede genforsøg og revisionsspor | Administreret kø og worker |
| Flere API’er eller lange venteperioder | Status på trinniveau, timeouts, genforsøg og kompensation | Holdbar workflow engine |
| Kunderettet eller uigenkaldelig handling | Menneskelig godkendelse og nøje afgrænsede legitimationsoplysninger | Workflow med godkendelsespunkt |
Gør webhook-håndteringen bevidst kedelig
Et webhook-endpoint bør verificere signaturen ved hjælp af den rå request body, deduplikere hændelsen, gemme tilstrækkelige oplysninger til at undersøge den, sætte alt væsentligt arbejde i kø og hurtigt returnere et vellykket svar. OpenAI forsøger i øjeblikket at levere mislykkede eller langsomme leverancer igen i op til 72 timer med eksponentiel backoff. Dokumentationen advarer også om, at dublerede hændelser kan forekomme, og anbefaler at bruge headeren webhook-id til deduplikering.
Dette leverings-ID forhindrer, at den samme hændelse accepteres to gange. En separat idempotensnøgle for forretningsprocessen skal forhindre, at den tilsigtede handling udføres to gange. Før der skrives en CRM-note, publiceres indhold eller sendes en notifikation, skal det kontrolleres, om sideeffekten allerede er gennemført. Gem så vidt muligt det ID, som det eksterne system returnerer, i samme transaktion.
Hvis jobbet er annulleret, bør en forsinket webhook om afslutning registreres uden at genaktivere jobbet. Annullering af OpenAI-svaret er idempotent, men en annullering kan ikke tilbagekalde en e-mail, faktura, publicering eller tredjepartsopdatering, som applikationen allerede har gennemført.
Kø, worker eller workflow engine?
En jobtabel i databasen og en worker er ofte tilstrækkeligt til én modelanmodning efterfulgt af én kontrolleret handling. Det gør den første version overskuelig og udnytter infrastruktur, som teamet måske allerede driver.
En administreret beskedkø er relevant, når producenten og workeren skal kunne være tilgængelige eller skaleres uafhængigt af hinanden. Husk, at mange standardkøer bruger at-least-once delivery. Amazon SQS gør for eksempel udtrykkeligt forbrugerne opmærksomme på, at de skal være idempotente, fordi den samme besked af og til kan ankomme igen.
En holdbar workflow engine er sin plads værd, når arbejdet omfatter flere indbyrdes afhængige trin, venter på mennesker eller eksterne hændelser eller kan forblive åbent i flere dage. Temporal er én mulighed. Ifølge dokumentationen bevarer dets workflow executions deres tilstand gennem fejl, kan vente på signaler eller aktiviteter og viser statusserne kørende, sat på pause, afsluttet, fejlet, annulleret og udløbet. Tilsvarende cloudbaserede workflow-tjenester kan passe bedre, hvis organisationen allerede har bundet sig til en bestemt platform.
En praktisk tjekliste til produktion
- Tag et snapshot af inputtet, så en senere ændring ikke ubemærket kan påvirke arbejde, der allerede er i gang.
- Adskil det genererede output fra tilladelsen til at anvende det.
- Definér, hvilke fejl der kan forsøges igen, og fastsæt grænser for genforsøg og omkostninger.
- Brug idempotens på hændelses-, job- og eksternt skrivningsniveau.
- Vis fejlede jobs og afventende godkendelser i en driftsvisning.
- Log statusovergange uden at placere hemmeligheder eller unødvendige personoplysninger i logfilerne.
- Beslut før lanceringen, hvad annullering og kompensation indebærer.
Prompten er kun én del af dette design. Ejerskab, rettigheder, statusovergange, undtagelseshåndtering og den endelige overdragelse til forretningen kræver som regel mere projektarbejde end det første API-kald.
Begynd med den handling, der ikke må ske to gange
Vælg ét workflow til den første produktionsversion, og identificér dets mest konsekvensrige sideeffekt. Byg jobstatusser, godkendelsesregel, idempotenskontrol og gendannelsesvisning op omkring denne handling, før der tilføjes mere autonomi.
Hvis din AI-prototype nu skal arbejde med CRM-, support-, fakturerings- eller publiceringssystemer, kan Greg hjælpe med at omsætte den tekniske idé til en kontrolleret leveranceplan. Drøft workflowet og dets overdragelser uden først at forpligte dig til et større udviklingsprojekt.
Relateret indhold på GrN.dk
- AI-researchassistenter kræver et kildespor – ikke kun kildehenvisninger
- OpenAI Computer Use: Browseragenter kræver legitimationsoplysninger – ikke demoer
- OpenAI’s Guardrails og Run State gør intern udrulning af agenter til en betalt godkendelses- og revisionsopgave
Har du brug for hjælp til denne type arbejde?
Planlæg dit AI-workflow med Greg Kontakt Greg.
