10 ingeniørprincipper for AI-agenter i produktion

Sidste kvartal så jeg en agent-demo køre fejlfrit på scenen -- den kaldte API'er, opsummerede dokumenter og bookede endda et møde. Grundlæggeren var euforisk. Tre uger senere lækkede deres produktionssystem kundedata via en prompt injection gemt i en uploadet PDF.

Demoen virkede. Systemet gjorde ikke.

Over 40 % af AI-agentprojekter fejler -- ikke fordi modellerne er for svage, men fordi risikostyringen og arkitekturen ikke holder. En demo-agent i en notebook tager en eftermiddag at bygge. En agent, der overlever rigtige brugere, kræver en ingeniørdisciplin, som de fleste teams endnu ikke har opbygget.

Disse ti principper er gabet mellem de to.

1. Hvordan definerer du agentens grænser og trusselsmodel?

Prompt injection optræder i over 73 % af produktionsinstallationer ifølge OWASP-data, og bare fem manipulerede dokumenter kan påvirke AI-svar 90 % af gangene via RAG poisoning (OWASP). Det første produktionsprincip er at kortlægge hvert system, din agent kan læse fra, skrive til eller ændre -- før du skriver en eneste linje orkestreringskode.

Kernesårbarheden er det, sikkerhedsforskere kalder confused deputy-problemet. Din agent har forhøjede rettigheder -- API-nøgler, databaseadgang, legitimationsoplysninger til eksterne tjenester -- som slutbrugerne ikke har. Hvis en angriber manipulerer agentens kontekst via naturligt sprog, kaprer de rettighederne til uautoriserede handlinger.

Jeg kalder det permission surface. De fleste teams dokumenterer deres API-endpoints. Næsten ingen dokumenterer det fulde omfang af, hvad deres agent kan gøre med de endpoints, når en LLM bestemmer rækkefølgen. Forsvaret kræver lag på lag: inputfiltrering med deterministisk kode før agenten ser prompten, sanering af alt indhentet indhold, semantisk analyse ud over simpel strengsammenligning og strikte deny/allow-lister for emnedomæner.

Den afgørende indsigt -- og den, jeg bliver ved med at vende tilbage til -- er, at systemprompts er ikke-deterministiske. De er retningslinjer, modellen følger, indtil den ikke gør. Reel sikkerhed skal ligge helt uden for LLM-ræsonneringsloopet.

2. Hvorfor er kontrakter overalt afgørende for agentpålidelighed?

LLM'er mønstergenkender i stedet for at ræsonnere om API'er, og det betyder, at strengt typede skemaer med værktøjer som Pydantic eller Zod ikke er bekvemmeligheder -- de er den eneste mekanisme, der begrænser en LLM's tool calls til gyldige operationer. Uden validering på serversiden stoler du på, at en statistisk model formaterer data korrekt hver eneste gang.

Hvert værktøj skal have eksplicit typede inputs med validering på serversiden. Når en agent genererer et tool call, skal du validere: korrekt værktøjsnavn, alle påkrævede parametre til stede, typer der matcher skemaer, værdier inden for tilladte intervaller.

Når valideringen fejler, så lad være med at crashe. Returnér strukturerede fejlsvar -- det specifikke felt, den overskredne begrænsning, det forventede format -- så agenten kan selvkorrigere og prøve igen. Ved komplekse værktøjer: brug idempotency keys. Uden dem risikerer en agent, der genopretter efter en timeout, at debitere et kreditkort tre gange.

Versionér dine skemaer. Dokumentér alle fejlscenarier i værktøjsbeskrivelserne. LLM'en læser de beskrivelser for at beslutte, hvordan den kalder dine værktøjer. Hvis beskrivelsen er vag, bliver kaldene kreative. Kreativitet er præcis det, du ikke vil have.

3. Hvordan sikrer du agentens værktøjseksekvering?

Zero trust-arkitektur forudsætter, at ingen agent er betroet som standard uanset netværksposition -- et princip, der gælder for agentautentificering via kortlivede certifikater, HSM-nøglelagring og workload identity federation. Hvert værktøj opererer bag autorisering, der håndhæver rollebaseret adgangskontrol før både registrering og eksekvering.

Token-politikker skal have strikse grænser: maksimalt to timers levetid, rotation hver time, eksplicitte scopes, IP-allow-lister og mTLS til intern kommunikation. Da vi testede disse politikker på vores egen agentinfrastruktur, var overhead'et minimalt -- under 3 ms pr. kald -- men reduktionen af angrebsfladen var markant.

Ved operationer med stor effekt -- databasesletninger, ændringer i produktionskonfiguration, kundemails -- brug human-in-the-loop-godkendelser med uforanderlige audit trails. Et detaljeret register, der definerer, hvilke operationer der kræver menneskelig godkendelse, hvem der må godkende, og hvornår de gjorde det. Ingen undtagelser.

4. Hvorfor er context engineering den største ydelseshåndtag?

Datahentning æder 40-50 % af den samlede eksekveringstid, når konteksten ikke styres bevidst. Løsningen er arkitektonisk: adskil arbejdshukommelse fra langtidsvidenssøgning, og komprimer aggressivt, før du injicerer kontekst i promptvinduet.

Da jeg profilerede vores egne agentpipelines, var forskellen mellem at dumpe rå samtalehistorik og bruge intentionsbaseret søgning med opsummering en 4x-reduktion i latenstid på flertrinsopgaver.

Mønsteret fungerer sådan: intentionsdetektorer bestemmer, hvornår historisk kontekst er nødvendig. Når de udløses, henter de relevante uddrag fra vektor- eller strukturerede databaser. En mindre, hurtigere model opsummerer uddragene. Kun de kompakte opsummeringer kommer ind i agentens hovedprompt. Sigt efter et 10:1-komprimeringsforhold, mens du bevarer beslutningsrelevante detaljer.

Sporbarhed er også vigtig her. Registrér, hvilken kontekst der blev hentet, hvorfor den blev valgt, hvordan den blev transformeret, og hvad der påvirkede den endelige beslutning. I regulerede brancher er rekonstruktion af kontekstens herkomst ikke et "nice to have". Det er et juridisk krav.

5. Hvorfor skal videnssøgning være et styret værktøj?

Traditionelle RAG-systemer henter og svarer, men agentbaserede RAG-systemer henter, beslutter og handler -- og det gør dataisolering og kildestyring til kritiske sikkerhedsgrænser frem for valgfrie funktioner. Hård tenant-isolering på datalaget med sikkerhedstrimning ved forespørgselstidspunktet er ufravigelig.

Kildestyring definerer din søgbare viden: godkendte interne dokumenter, verificerede eksterne kilder og strengt blokerede domæner. Bevar sporbarhed fra kildedokumenter gennem chunking, embedding, søgning og endeligt svar.

Den adskillelse, de fleste teams overser: at læse en vidensbase bør aldrig implicit give skriveadgang. Søgerettigheder og eksekveringsrettigheder kræver helt separate autorisationstjek. Da vi auditerede tre agentinstallationer sidste kvartal, havde alle tre søgepipelines, der i stilhed kunne udløse skriveoperationer via kædede tool calls. Ingen opdagede det, før vi kortlagde den fulde permission surface.

6. Hvordan bliver orkestrering til kontrolflow?

State machine-orkestrering passer til compliance-kritiske flows, hvor orkestratoren styrer workflowets tilstand, og agenterne kun bestemmer handlinger inden for forhåndsgodkendte muligheder. ReAct-mønstre veksler mellem ræsonnering og handling til dynamiske opgaver, men kræver hårde iterationsgrænser for at forhindre løbske loops.

Tre roller holdes adskilt: orkestratorer koordinerer workflow, agenter beslutter næste skridt, værktøjer eksekverer kode. Blander du dem, får du agenter, der ikke kan debugges.

Ved komplekse problemer bruger planlægningsbaseret orkestrering manager-agenter, der opbygger opgaveregistre og delegerer til snævre, specialiserede sub-agenter. Uanset mønster: håndhæv eksplicitte afslutningsbetingelser -- succeskriterier, iterationslofter, fremdriftssporing og punkter for manuel indgriben. Brug circuit breakers -- ti fejl på 60 sekunder bør åbne kredsløbet og fejle hurtigt.

Det orkestreringsmønster, du vælger, betyder mindre end de grænser, du håndhæver inden for det. Jeg har set state machines fejle spektakulært og ReAct-loops køre perfekt -- fordi teamet med ReAct havde strikse stopbetingelser, mens state machine-teamet antog, at mønsteret i sig selv var beskyttelsen.

7. Hvorfor er hukommelse en arkitekturbeslutning og ikke en funktion?

Adskillelse af arbejdshukommelse (hurtig, in-memory, sessionsafgrænset) fra persistent hukommelse (vektordatabaser, relationelle databaser, tidsserielogfiler) med aggressive opbevaringspolitikker og løbende genverificering af rettigheder forebygger de stale-cache-sårbarheder, som de fleste agentframeworks ignorerer.

Korttidshukommelse bruger sliding windows og sub-millisekund-lagre som Redis. Den holder aktuel tilstand, seneste tool calls og arbejdsvariabler -- og nulstilles fuldstændigt mellem sessioner.

Langtidshukommelse persisterer på tværs af sessioner via vektordatabaser til semantisk genkaldelse, relationelle databaser til struktureret viden og tidsserielagre til hændelsessekvenser. Kryptér data både i hvile og under transport overalt. Ved følsomme data: feltniveaukryptering. Brug en dataklassificeringsmatrix -- offentlig, intern, fortrolig, begrænset -- der dikterer lagringskrav og adgangskontrol.

Genverificér altid tenant- og rollebegrænsninger, før du udfører nogen hukommelsesoperation. Antag aldrig, at cachede rettigheder stadig gælder.

8. Hvilke pålidelighedsmekanismer kræver produktionsagenter?

Exponential backoff med jitter -- startende ved 1 sekund og dobbelt op til et loft på 32 sekunder -- kombineret med circuit breakers, der åbner efter ti fejl på 60 sekunder, forhindrer de kaskaderende fejl, der vælter produktionsagentsystemer.

Klassificér fejl: 429 og 503 kan prøves igen. 400 og 403 kan ikke. Circuit breakers sporer fejlrater over sliding windows. Når kredsløbet åbner, fejl hurtigt -- send ikke trafik til en tjeneste, der kæmper. Half-open states tester forsigtigt, om tjenesten er kommet sig.

Kontrolleret nedgradering er også vigtig. Hvis din primære LLM er nede, fald tilbage til mindre modeller. Hvis vektorsøgning fejler, skift til nøgleordssøgning. Brug checkpointing ved logiske grænser, så du kan genoptage fra det seneste gemte punkt i stedet for at starte forfra.

9. Hvordan bygger du observability til ikke-deterministiske systemer?

OpenTelemetry giver leverandørneutral instrumentering, hvor hver brugerforespørgsel opretter et rod-span med child spans for LLM-kald, værktøjsinvokationer, RAG-operationer og sub-agent-overdragelser -- det gør agentadfærd sporbar på tværs af hele eksekveringskæden.

De spørgsmål, agent-observability skal besvare: Opførte agenten sig som tiltænkt? Kaldte den de rigtige værktøjer? Var latenstiden acceptabel? Var beslutningerne logisk fornuftige?

Instrumentér én gang, eksportér overalt -- Datadog, Grafana, Azure Monitor, CloudWatch. Spor modelparametre, eksakte prompts, svar, tokenforbrug, tool calls og metadata fra udbydere. Agentspecifik instrumentering fanger tilstandsovergange, hukommelsesoperationer, beslutningspunkter og de rå parameterværdier, der sendes til værktøjer.

Økonomisk sporing er kritisk. Agenter kan foretage hundredvis af LLM-kald pr. opgave. Tag traces med pr.-model-omkostninger, aggregér pr. session, og sæt aggressive alarmer på prisanomalier. Uden omkostnings-observability bliver din agentregning den fejltilstand, ingen forudså.

10. Hvordan forhindrer evalueringer og governance drift?

Korrekt konfigurerede LLM-as-judge-frameworks stemmer overens med menneskelige ekspertvurderinger 85 % af gangene, hvilket gør automatiseret evaluering skalerbar nok til at fange regressioner på tværs af offline-udvikling, CI/CD-regressionstest og live produktionsovervågning.

Byg gyldne datasæt, der repræsenterer almindelige opgaver, edge cases, historiske fejl og compliance-scenarier. Definér eksplicitte kriterier: faktuel nøjagtighed, brugbarhed, præcision, sikkerhed, brandtone. Brug chain-of-thought-prompting og few-shot-eksempler for at reducere bedømmerbias.

Governance-kontroller håndhæver PII-detektion og -maskering før logning, indholdssikkerhedsfiltre på alle inputs og outputs, og compliance-tjek med audit trails. I regulerede brancher har hver agenthandling brug for skudsikker sporbarhed -- hvem der startede, hvad der var autoriseret, hvilke værktøjer der eksekverede, hvilke data der blev tilgået, hvilken beslutning der blev truffet.

Overvåg for drift: agentadfærd, der ændrer sig, selv om koden er uændret. Etablér baselines i pre-produktion, sammenlign løbende med produktionstrafik, og alarmér ved markante afvigelser.

Ofte stillede spørgsmål

Hvad er det vigtigste princip for AI-agenter i produktion?

Trusselsmodellering (princip 1) er fundamentet -- alle andre principper afhænger af, at du kender din agents fulde permission surface. Over 73 % af produktionsinstallationer rammes af prompt injection-angreb (OWASP), og forsvar, der lever inde i LLM-ræsonneringsloopet, kan per definition omgås.

Kan du bygge produktionsagenter uden OpenTelemetry?

Du kan bruge alternative observability-stakke, men princippet består: du har brug for distribueret tracing, der fanger flertrins-workflows, tool calls og omkostningsmønstre. OpenTelemetrys leverandørneutrale tilgang undgår vendor lock-in og giver standardiserede semantiske konventioner for LLM-operationer.

Hvordan virker circuit breakers i agentsystemer?

Circuit breakers sporer fejlrater over sliding windows. Når en tærskel rammes -- f.eks. ti fejl på 60 sekunder -- åbner kredsløbet og fejler hurtigt i stedet for at sende trafik til en tjeneste, der kæmper. En half-open state tester periodisk, om den bagvedliggende tjeneste er kommet sig, før kredsløbet lukkes helt igen.

Spørgsmålet i 2026 er ikke, hvilken model din agent kører på. Det er, om din ingeniørdisciplin matcher de rettigheder, du har givet den. Disse ti principper er ikke ambitioner -- de er minimumskravet for ethvert agentsystem, der håndterer rigtige data, rigtige brugere og rigtige konsekvenser. Teams, der springer dem over, ender i de 40 %, der fejler. Teams, der følger dem, bygger systemer, der overlever det, produktionen faktisk kaster efter dem.