TL;DR: Produktionsagenter lever eller dör på (1) tillstånd som går att inspektera, (2) verktyg som går att köra om säkert, och (3) en utvärderingssvit som fångar regressionsfel.
Det finns ett enormt gap mellan en AI-agent som fungerar i en demo och en som fungerar i produktion. Jag har sett det från båda sidorna: demon som får kundens ögon att lysa, och larmet klockan 02 när samma agent med full övertygelse skickar en felaktig faktura till en riktig kund.
Efter att ha byggt och driftsatt agenter i flera branscher har jag utvecklat starka åsikter om vad som faktiskt spelar roll i produktion. Det här är inte en tutorial. Det är en fältrapport om arkitekturbeslut, utvärderingsmönster och de fellägen som ingen pratar om på AI-konferenser.
Arkitektur: Agentloopen räcker inte
De flesta agentramverk ger dig en grundloop: observera → tänk → agera → observera. Det duger för ett hackathon. I produktion behöver du flera ytterligare lager.
Strukturerad tillståndshantering
Din agent behöver explicit, inspekterbart tillstånd, inte bara en växande kontexthistorik. Varje beslut agenten fattar ska vara spårbart till ett tillståndsobjekt som inkluderar: vad den vet, vad den försöker uppnå, vilka verktyg som finns, och vilka begränsningar som gäller.
Jag använder ett mönster jag kallar state-action-outcome-loggning: innan varje verktygskörning skriver agenten en strukturerad post med sitt nuvarande tillstånd, den åtgärd den avser vidta, och varför. Efter att verktyget svarat loggar den utfallet och eventuella tillståndsövergångar. Det här är inte valfritt. Det är så du felsöker agenter klockan 02 och bygger utvärderingsdatamängder från riktig trafik.
Verktygsdesign är hela spelet
Kvaliteten på din agent bestäms till 80 % av hur väl du designar dess verktyg. Några hårt vunna principer:
Gör verktyg atomära och idempotenta där det går. En agent som kör om ett misslyckat "skapa_faktura"-anrop ska inte skapa dubblettfakturor. Designa verktygen så att upprepade anrop med samma parametrar ger samma resultat.
Returnera rika, strukturerade svar. Returnera inte "Klart" från ett verktyg. Returnera det fullständiga tillståndet för objektet som skapades eller ändrades. Agenten behöver kontext för att bestämma nästa steg.
Begränsa handlingsutrymmet. Fler verktyg är inte bättre. Varje verktyg du lägger till ökar sannolikheten att agenten väljer fel. Jag börjar normalt med 4–6 verktyg för en fokuserad agent och motstår frestelsen att lägga till fler tills jag har tydliga bevis på att agenten blockeras utan dem.
Validera indata före exekvering. Dina verktyg ska avvisa felaktiga förfrågningar innan de gör något. Agenten hallucinerar ibland parametervärden. Fånga det vid verktygsgränsen, inte i databasen.
Orkestreringsskiktet
För icke-triviala arbetsflöden behöver du ett orkestreringsskikt som sitter ovanför agentloopen. Det här lagret hanterar:
- Flerstegsarbetsflöden där agenten måste slutföra uppgifter i en bestämd ordning med kontrollpunkter emellan.
- Mänsklig eskalering när tillförlitligheten är låg eller insatserna höga.
- Parallellexekvering när agenten kan göra flera oberoende saker samtidigt.
- Timeout och circuit-breaking när ett steg tar för lång tid eller fortsätter misslyckas.
Jag har funnit att behandla orkestreraren som en deterministisk tillståndsmaskin, med LLM:en som driver individuella steg men inte styr det övergripande flödet, ger långt mer pålitliga system än att låta LLM:en improvisera genom ett komplext arbetsflöde.
Utvärdering: Delen alla hoppar över
Om jag var tvungen att peka ut det enskilt största gapet mellan hobbyagenter och produktionsagenter så är det utvärdering. De flesta team levererar agenter utan något systematiskt sätt att mäta om de fungerar korrekt.
Bygg din utvärderingssvit innan du bygger agenten
Jag menar bokstavligen. Innan du skriver agentkod, definiera:
- En golden dataset med 50–100 representativa scenarier med förväntade utfall. Dessa kommer från verkliga exempel på arbetet agenten ska utföra.
- Automatiserade bedömningsfunktioner som kan poängsätta agentens output utan manuell granskning. För strukturerade utdata är det enkelt. För naturligt språk, använd LLM-as-judge med kalibrerade bedömningskriterier.
- Regressionstester som fångar när en promptändring som förbättrar ett scenario sabbar tre andra.
De tre nivåerna av agentutvärdering
Nivå 1: Rätt verktygsval. Givet en användaravsikt, väljer agenten rätt verktyg med rätt parametrar? Det här är enklast att testa och det vanligaste fellägget. Spåra det som ett enkelt precisionstal.
Nivå 2: Grad av uppgiftsslutförande. Givet ett komplett scenario, uppnår agenten önskat resultat? Det kräver end-to-end-testriggar med mockade verktygsbaksidor. Sikta på 85–90 % för väl avgränsade agenter. Under 80 % är något fundamentalt fel.
Nivå 3: Produktionskvalitetsövervakning. I levande trafik, spåra: slutförandegrad, felfrekvens, eskaleringsfrekvens, latenspercentiler och användarupplevelse. Sätt larm på allihop. En agent som gradvis försämras är värre än en som kraschar högt.
Promptregressionsproblemet
Här är en fälla som fångar alla team förr eller senare: du justerar en systemprompt för att fixa en bugg i scenario A, och det sabbar tyst scenario B, C och D. Utan en regressionssvit upptäcker du det inte förrän produktionsanvändare klagar.
Mitt tillvägagångssätt: varje promptändring körs mot hela utvärderingssviten före deploy. CI-pipelinen blockerar om något mått försämras med mer än 2 %. Det låter tungt, men det har räddat mig från att leverera trasiga agenter fler gånger än jag kan räkna.
Vanliga fallgropar som dödar produktionsagenter
Fallgrop 1: Obegränsade kontextfönster
Agenter som ansamlar konversationshistorik utan sammanfattning eller reducering kommer så småningom att överskrida kontextgränser och börja förlora kritisk information. Implementera en sammanfattningsstrategi som komprimerar äldre interaktioner men bevarar nyckelfakta och beslut.
Fallgrop 2: Övertygelse utan kalibrering
LLM:er har fel med övertygelse på en förutsägbar nivå. Din agentarkitektur måste ta hänsyn till det. Lösningen är inte att göra agenten mindre övertygande. Bygg verifieringssteg i arbetsflödet. Innan en agent skickar ett mejl till en kund, låt den kontrollera sin egen output mot originaldata. Innan den uppdaterar en finanspost, låt den verifiera matten.
Fallgrop 3: Ignorera latens
En perfekt precis agent som tar 45 sekunder att svara på varje steg är oanvändbar för interaktiva arbetsflöden. Profilera din agents latensbudget: hur mycket är LLM-inferens, hur mycket är verktygsexekvering, hur mycket är overhead? Optimera flaskhalsen, inte genomsnittet.
Fallgrop 4: Ingen graceful degradation
När LLM-API:et går ner (och det kommer att ske), när ett verktyg returnerar ett oväntat fel, när agenten stöter på ett scenario den aldrig sett, vad händer? Om svaret är "den kraschar" eller "den hallucinerar ett svar" är du inte produktionsklar. Bygg explicita reservvägar för varje felläge du kan förutse, och en generell eskaleringsväg för de du inte kan.
Fallgrop 5: Behandla agenten som en svart låda
Om du inte kan förklara varför din agent fattade ett specifikt beslut kan du inte felsöka den, inte förbättra den, och absolut inte lita på den med något viktigt. Observerbarhet är inte en trevlig bonus. Det är en förutsättning för produktionsdeploy.
Den ärliga sanningen om var vi är
AI-agenter är kraftfulla, men de är inte magi. Den nuvarande generationen fungerar bäst i avgränsade domäner med tydliga framgångskriterier, bra verktygs-API:er, och mänsklig tillsyn för gränsfall.
De team som lyckas i produktion är inte de med de mest sofistikerade prompterna eller den nyaste modellen. Det är de som behandlar agentutveckling som mjukvaruutveckling: med testning, övervakning, versionskontroll, och en sund respekt för fellägen.
Bygg tråkig infrastruktur runt spännande teknik. Det är hela hemligheten.