AI-agenter kraschar sällan. De misslyckas i det tysta – och forskning visar varför

Agenter baserade på stora språkmodeller besvarar numera supportärenden, söker i databaser och planerar resor. När något går fel ger de oftast ett självsäkert svar och en statuskod som signalerar att allt gått bra. En växande mängd forskning förklarar varför de här felen är svåra att upptäcka och hur ingenjörsteam håller på att lära sig mäta dem.

Ett fel som ser ut som en framgång

Traditionell programvara tenderar att fallera på ett tydligt sätt. En funktion utlöser ett undantag, en server returnerar en felkod och en övervakningspanel lyser rött. En AI-agent fungerar annorlunda. Den arbetar i en loop: en språkmodell läser en prompt, beslutar sig för att anropa ett verktyg, till exempel ett sök-API eller en databas, läser resultatet och avgör vad den ska göra härnäst. Varje steg kan gå fel, samtidigt som alla nätverksanrop i kedjan ändå lyckas.

Tänk på ett vanligt exempel. Ett väderverktyg slutar fungera och returnerar texten ”tjänsten är inte tillgänglig” i ett i övrigt normalt svar. Modellen läser texten, ber artigt om ursäkt eller, ännu värre, skriver en trovärdig prognos utifrån sina träningsdata. Användaren får ett välformulerat svar. Serverloggarna visar ett lyckat anrop med normal svarstid. Inget i en konventionell övervakningslösning registrerar att något har gått fel.

Modellleverantörer beskriver samma kunskapslucka i sin egen dokumentation. Googles guide till Gemini API påpekar att modellen ”inte själv kör funktionen”. Den föreslår bara ett funktionsnamn och argument, medan utvecklarens applikation utför anropet. Applikationen är därför den enda delen av systemet som ser det faktiska resultatet. Anthropics tekniska guide till att bygga agenter lyfter en närliggande poäng: agenter behöver ”facit” från omgivningen i varje steg, till exempel resultat från verktyg, för att kunna bedöma sina egna framsteg. När ett verktyg rapporterar ett fel som vanlig text är det facit som agenten får felaktigt, och den har inget sätt att upptäcka det.

Det här är inte ett nytt slags problem, utan en skarpare version av ett gammalt. År 2015 beskrev Google-ingenjörer under ledning av D. Sculley ”dold teknisk skuld” i maskininlärningssystem. De hävdade att de flesta riskerna i ett produktionssatt maskininlärningssystem finns utanför modellkoden, i databeroenden, konfiguration och sammanbindande kod. Agenter lägger till ytterligare ett lager på den listan. Promptar och verktygsbeskrivningar är konfiguration som kan förändra ett systems beteende utan att själva koden ändras.

Små ändringar, stora effekter

Hur stor betydelse kan en liten ändring av en prompt ha? I en artikel som presenterades vid ICLR 2024 ändrade Melanie Sclar vid University of Washington och hennes kollegor bara formateringen av few-shot-promptar: avgränsare, mellanrum och versaler. Innebörden förblev densamma. Ändå varierade resultatet på samma uppgift med upp till 76 träffsäkerhetspunkter för LLaMA-2-13B. Känsligheten försvann inte med större modeller, fler exempel eller instruktionsträning.

Författarna rekommenderar att man redovisar ett intervall för resultaten med olika rimliga promptformat i stället för en enda siffra. För ingenjörsteam är den praktiska lärdomen enklare: en ändring av en prompt är en kodändring. Den behöver versionshistorik och måste testas innan den når användarna.

Samma sak gäller verktygsbeskrivningar, som modellen läser som en del av prompten. Anthropics guide framhåller att verktygsdefinitioner förtjänar ”lika mycket omsorg i promptutformningen” som huvudprompten. Guiden beskriver en kodningsagent som gång på gång gjorde fel med relativa filsökvägar. När verktyget ändrades så att det krävde absoluta sökvägar använde modellen det utan fel. Modellen ändrades inte. Det enda som ändrades var beskrivningen den läste.

Ett lyckat försök säger inte mycket

En annan forskningsinriktning undersöker konsekvens. Riktmärket τ-bench, som publicerades av Shunyu Yao och kollegor på Sierra och presenterades vid ICLR 2025, simulerar kundtjänstsamtal där en agent måste använda verktyg och följa affärsregler. Författarna introducerade ett mått kallat pass^k: sannolikheten att en agent löser samma uppgift korrekt vid samtliga k försök.

Resultaten var nedslående. En GPT-4o-agent löste omkring 61 % av detaljhandelsuppgifterna vid ett enda försök. När den behövde klara samma uppgift åtta gånger i rad sjönk andelen till omkring 25 %. En demonstration som fungerar en gång säger föga om hur ett system beter sig vid det tusende försöket.

Där multiagentsystem går sönder

Många team kopplar numera ihop flera agenter, där en planerar, en annan utför arbetet och en tredje kontrollerar resultatet. En studie från UC Berkeley från 2025, ”Varför fallerar LLM-system med flera agenter?”, analyserade över 1 600 annoterade körningsspår från sju populära ramverk för multiagentsystem. Författarna, under ledning av Mert Cemri, tog fram en taxonomi kallad MAST med 14 feltyper i tre grupper: problem med systemdesignen, bristande samordning mellan agenter och verifiering av uppgifter.

Deras huvudsakliga slutsats är att många fel beror på hur systemet är utformat, inte bara på begränsningar hos den underliggande modellen. Agenter ignorerar sin tilldelade roll, tappar tråden i samtalet eller förklarar en uppgift avslutad utan att kontrollera resultatet. Sådana fel lämnar inga felmeddelanden efter sig. De går bara att upptäcka om någon kan läsa vad varje agent faktiskt gjorde. Unite.AI:s bevakning av paradoxen med flera agenter lyfter en närliggande arkitekturfråga: fler agenter kan förstärka ett tidigt fel i stället för att jämna ut det.

Så blir det osynliga synligt

Det tekniska arbetet hämtar inspiration från distribuerade system, där man länge har följt förfrågningar genom många tjänster med en teknik som kallas spårning. Tillämpat på agenter blir varje användarförfrågan ett spår, och varje anrop till en modell eller ett verktyg blir ett spårsegment i det. Ett spårsegment registrerar indata, utdata, antalet använda token och hur lång tid det tog. OpenTelemetry, branschens standardiseringsorgan för det här arbetet, utarbetar gemensamma konventioner för spårsegment inom generativ AI. År 2026 är konventionerna fortfarande märkta som under utveckling, så attributnamnen kan fortfarande ändras.

Flera projekt med öppen källkod, till exempel Langfuse, Arize Phoenix och AcruxCore, använder redan den här metoden. Deras källkod är offentlig, så team kan granska hur ett spår lagras och köra programvaran på sina egna servrar. Projekten registrerar anrop till modeller och verktyg som spårsegment i ett och samma spår och låter teamen koppla kvalitetsbetyg till dem. Valet av verktyg är mindre viktigt än en detalj: ett spårsegment för ett verktyg måste registrera vad verktyget faktiskt returnerade, inte bara om nätverksförfrågan lyckades. Annars förblir det tidigare beskrivna felet med väderverktyget osynligt.

Branschundersökningar tyder på att spårning nu är vanligt, men att testningen släpar efter. LangChains rapport om läget för agentutveckling omfattade 1 340 yrkesverksamma i slutet av 2025. Kvalitet var det oftast angivna hindret för att ta agenter i produktion och nämndes av 32 % av de svarande. 89 % av organisationerna uppgav att de hade någon form av observerbarhet för sina agenter, och 62 % hade detaljerad spårning av enskilda steg och verktygsanrop. Bara 52,4 % genomförde utvärderingar offline med testmängder, och 37,3 % utvärderade trafik i realtid. De flesta team kan se vad deras agenter gjorde. Färre kontrollerar om det var korrekt.

Att bedöma svar i stor skala

Spår visar vad som hände. De säger inte om svaret var bra. Det går inte att läsa igenom varje konversation manuellt i stor skala, så allt fler team använder en andra modell för att bedöma svaren – en metod som kallas LLM som domare. En artikel från NeurIPS 2023 av Lianmin Zheng och kollegor visade att starka modeller som GPT-4 överensstämde med människors preferenser i mer än 80 % av fallen, ungefär lika ofta som människor var överens med varandra.

Samma artikel dokumenterade metodens svagheter. Bedömningsmodeller föredrar svaret som visas först, föredrar längre svar och kan gynna text som de själva har skrivit. Modellernas bedömningar är därför uppskattningar. De är användbara när stora mängder ska bedömas, men behöver kontrolleras mot ett mindre urval av exempel som människor har märkt upp, där svarens ordningsföljd har slumpats.

Från praktik till policy

Det här arbetet med mätning håller också på att bli ett krav inom styrning. USA:s nationella institut för standarder och teknik publicerade sitt ramverk för riskhantering inom AI i januari 2023. En av dess fyra grundfunktioner, ”Mäta”, innebär att organisationer ska kvantifiera, följa upp och dokumentera AI-risker över tid. För en agent är spår och utvärderingsresultat det underlag som funktionen efterfrågar.

Vad team kan göra redan nu

Det här speglar argumentet som har framförts på den här plattformen: det verkliga testet för agentisk AI är tillförlitlighet. Forskningen ovan tillför detaljer om hur detta ska mätas: tillförlitlighet är inte en egenskap man kontrollerar en gång, utan ett spann som måste mätas löpande.

Forskningen pekar på ett fåtal konkreta arbetssätt, och de stora modellleverantörerna rekommenderar många av samma saker. OpenAIs praktiska guide till att bygga agenter uppmanar team att ”sätta upp utvärderingar för att fastställa en baslinje för prestandan” innan de optimerar, och att lämna över kontrollen till en människa när en agent överskrider ett fastställt antal misslyckade försök eller ställs inför en handling med hög risk. Anthropic rekommenderar ”omfattande tester i sandlådemiljöer” innan agenter agerar på egen hand.

I praktiken innebär det några konkreta steg. Versionshantera prompter och verktygsbeskrivningar som kod. Testa varje ändring av en prompt mot en fast testdatamängd och räkna med ett spann av resultat snarare än ett enda tal. Kör varje testfall flera gånger, eftersom en enda genomkörning döljer variationer. Registrera verktygens utdata i spåren, så att ett verktygsfel inte kan döljas bakom en lyckad statuskod. Se automatiska bedömningar som uppskattningar och kontrollera dem med hjälp av människor.

Inget av dessa arbetssätt kräver ett genombrott i modellernas förmåga. De kräver att man behandlar en AI-agent som det den är: ett probabilistiskt system som måste mätas, eftersom det sällan själv meddelar när det har misslyckats.