Utforma agenter som inte fastnar i oändliga loopar

Ett vanligt slags dyrt AI-fel i produktion ser ut så här: klockan är 3 på natten en tisdag och en kundsupportagent fastnar i en oändlig loop. Den anropar samma verktyg, får samma fel, försöker igen med en något annorlunda parameter, får samma fel och upprepar. Hundratals gånger i minuten. På morgonen möts teamet av en oväntad räkning på ett fyr- eller femsiffrigt belopp, beroende på modell och anropsfrekvens.

Detta är inte ovanligt. Loopande agenter hör till de vanligaste – och mest betydelsefulla – produktionsfelen. De är lömska eftersom det ofta ”ser ut som om de arbetar”: agenten utför åtgärder och anropen lyckas, eller misslyckas förutsägbart. Först när du granskar spårningen ser du att samma mönster upprepas.

Att bygga agenter som inte loopar för evigt kräver medvetna arkitekturbeslut. De flesta agentfel är förutsägbara och mönstren som förhindrar dem är välkända. Teamen som driftsätter tillförlitliga agenter är de som inför dessa mönster rigoröst.

Artikeln beskriver vad som får agenter att loopa, arkitekturmönstren som förhindrar det och de operativa skyddsräckena som fångar loopar som ändå slinker igenom.

Varför agenter loopar

Några mekanismer bakom agentloopar:

1. Osäkerhet om framsteg

Agenten saknar en tydlig uppfattning om ”har jag gjort framsteg?”. Den provar något, observerar ett resultat och bestämmer sig för att prova något annat. Utan uttrycklig uppföljning av framsteg kan ”prova något annat” betyda ”samma sak på ett lite annorlunda sätt”.

2. Avsaknad av avslutningskriterier

Agentens prompt säger ”hjälp användaren” men inte ”sluta när X är sant”. Utan tydliga avslutningskriterier fortsätter agenten att ”hjälpa” – söker efter ytterligare en uppgift, provar ytterligare ett verktyg och finslipar lite till.

3. Patologiska nya försök

När något misslyckas försöker agenter naturligt igen. Utan budgetar för nya försök kan samma fel prövas om i all oändlighet. Agentens uppfattning är ”jag har inte lyckats ännu”, inte ”jag har redan försökt 10 gånger”.

4. Tillståndsamnesi

Agentens arbetsminne innehåller bara de senaste turerna. Om en loop har gått igenom 20 försök kanske agenten bara ser de senaste 5 i kontexten och tappar mönstret som nu är uppenbart för en utomstående betraktare.

5. Inkonsekventa verktyg

Ett verktyg returnerar förvirrande eller motsägelsefulla resultat. Agenten försöker igen. Verktyget returnerar fortfarande förvirrande resultat. Agenten resonerar ”min tidigare tolkning kanske var fel” och provar på ett annat sätt. Verktyget returnerar fortfarande förvirrande resultat. Loop.

6. Överdriven optimism

Agentens träning gör den ihärdig – den fortsätter försöka när en bättre strategi vore att sluta och be om hjälp. Det är särskilt illa i långvariga uppgifter där små oklarheter växer.

7. Målförskjutning

Agenten tappar gradvis bort vad den försökte åstadkomma. Den förgrenar sig i deluppgifter och sedan underuppgifter till deluppgifterna, utforskar områden med svag koppling till målet och återvänder inte till huvudmålet.

Olika agenter misslyckas på olika sätt. Försvaren överlappar.

Mönster 1: Hårda stegbudgetar

Det enklaste och viktigaste försvaret är ett högsta antal steg. Agenten har exempelvis 20 verktygsanrop tillgängliga. Efter 20 måste den ge ett slutsvar eller eskalera.

Implementering:

def agent_loop(query, max_steps=20):
    messages = [{"role": "user", "content": query}]
    for step in range(max_steps):
        response = call_llm(messages, tools=available_tools)
        if response.is_final_answer:
            return response.content
        result = execute_tool(response.tool_call)
        messages.append(response)
        messages.append({"role": "tool", "content": result})
    # Budgeten förbrukad – tvinga fram ett slutsvar
    return force_final_answer(messages)

Budgeten bör anpassas till uppgiften. Enkla uppgifter: 5–10 steg. Komplexa uppgifter med flera källor: 20–30. Öppen informationssökning: 50 eller fler. Men alltid begränsat.

När budgeten är förbrukad ger agenten sitt bästa svar med den kunskap den har eller eskalerar till en människa.

Enbart detta mönster förhindrar de flesta katastrofala loopar. Implementera det alltid.

Varianter

Tokenbudget. Begränsa det totala antalet token i stället för, eller utöver, antalet steg. Det förhindrar agenter som tar färre steg men där varje steg är en resonemangsspårning på 50K token.

Kostnadsbudget. Översätter steg- och tokenbudgetar till euro. Det gör budgetöverskridanden konkreta.

Tidsbudget. Gräns för faktisk tid. Användbart för användarnära flöden (”svara inom 30 sekunder”).

De flesta produktionsagenter har alla fyra budgetarna i någon form. Om någon av dem förbrukas avslutas körningen.

Mönster 2: Uppföljning av framsteg

En budget talar inte om för agenten att den har fastnat – den stoppar bara agenten till slut. Uppföljning av framsteg hjälper agenten att upptäcka en loop och ta sig ur den.

En enkel implementation är att agenten för en uttrycklig framstegslogg. I varje steg anger den vilken ny information den har fått eller vad som har förändrats.

Steg 1: Sökte efter kunden "Smith". Hittade 12 träffar.
Steg 2: Filtrerade på aktiva konton. 4 återstår.
Steg 3: Kontrollerade den senaste aktiviteten. Kund 234 hade ett nytt supportärende om prissättning.
Steg 4: Hämtade uppgifterna om supportärendet. Klagomålet gällde en nylig prisändring.
Steg 5: Skrev ett svarsutkast. Redo att skickas.

Varje steg tillför ny information. Om agenten utför steg 6 utan att framstegsloggen får något nytt – samma sökning, samma resultat och samma slutsats – står den och stampar.

Prompten kan innehålla:

Sammanfatta vad du har lärt dig under de senaste stegen innan du bestämmer nästa åtgärd. Om du inte har fått någon ny information under de senaste 3 stegen ska du sluta och göra något av följande:
- Ge ditt bästa svar med den information du har.
- Eskalera problemet: förklara vad du har försökt och vad som saknas.

Det gör ”brist på framsteg” synligt för agenten så att den kan reagera.

Mönster 3: Upptäckt av upprepningar

Ibland upprepar agenter exakt samma verktygsanrop. Det är enkelt att upptäcka programmatiskt.

def detect_repeat(history):
    recent_calls = [c for c in history[-5:] if c.is_tool_call]
    if len(recent_calls) < 3:
        return False
    call_signatures = [(c.tool, json.dumps(c.args, sort_keys=True)) for c in recent_calls]
    return len(set(call_signatures)) < len(call_signatures) / 2

Ingrip om en upprepning upptäcks:

• Infoga ett meddelande: ”Du har nyligen anropat detta verktyg med dessa parametrar. Resultaten har inte förändrats. Prova en annan metod eller avsluta.”
• Eller framtvinga avslut.

Detta fångar automatiskt de tydligaste looparna.

Mönster 4: Upptäckt av låsta tillstånd

Utöver exakta upprepningar kan du upptäcka mer subtila låsta tillstånd:

Mönsterigenkänning. Använd ett separat LLM-anrop för att bedöma: ”Gör agenten framsteg utifrån de senaste 5 stegen?”. Bryt annars loopen.

def is_stuck(history):
    recent = format_history(history[-5:])
    response = call_llm(
        system="Du utvärderar om en agent gör framsteg.",
        user=f"Agentens senaste steg:\n{recent}\n\nGör agenten meningsfulla framsteg eller har den fastnat i en loop? Svara: progressing | stuck."
    )
    return response.content.strip() == "stuck"

Kör kontrollen med några stegs mellanrum. Ingrip om den returnerar stuck.

Verktygsvariation. Om agenten har anropat endast 1 verktyg i 5 eller fler steg är det misstänkt. Tvinga den att prova något annat eller sluta.

Felmönster. Om samma verktyg har returnerat samma fel 3 eller fler gånger ska det inte användas mer. Agenten kommer inte att lista ut vilka indata som saknas genom fler försök.

Mönster 5: Reflektionspunkter

Tvinga fram uttrycklig reflektion vid särskilda punkter under agentens körning.

Efter vart 5:e steg måste agenten reflektera:

1. Vad var mitt ursprungliga mål?
2. Vad har jag lärt mig hittills?
3. Vad behöver jag fortfarande veta?
4. Gör jag framsteg eller upprepar jag mig?
5. Ska jag fortsätta eller sluta?

Reflektionen tvingar agenten att ta ett steg tillbaka från tankarna om nästa omedelbara åtgärd och bedöma helheten.

Det är särskilt effektivt för långvariga uppgifter. Utan framtvingad reflektion glider agenten bort från målet. Med reflektion upptäcker den själv avvikelsen.

Mönster 6: Målförankring

Under långa agentkörningar går det ursprungliga målet förlorat. Agentens kontextfönster fylls med mellansteg och den ursprungliga frågan blir en liten del av en stor kontext.

Motverka detta genom att förankra målet upprepade gånger:

• Inkludera det ursprungliga målet överst i varje systemmeddelande.
• Låt agenten återge målet med N stegs mellanrum.
• Använd en separat ”målspårare” som bekräftar att varje steg ligger i linje med målet.

Exempel på tillägg till prompten:

Ursprungligt mål: [användarens begäran ordagrant]

Bekräfta före varje åtgärd:
- Hjälper denna åtgärd mig mot det ursprungliga målet?
- Fortsätt om svaret är ja.
- Återgå direkt till målet om svaret är nej.

Mönster 7: Avgränsning av deluppgifter

Långvariga agenter delar naturligt upp arbetet i deluppgifter. Utan struktur kan deluppgifterna rekursivt skapa egna underuppgifter tills agenten har gått vilse.

Ge arbetet struktur:

• Agenten identifierar deluppgifter uttryckligen.
• Varje deluppgift har en egen budget.
• När en deluppgift har slutförts eller misslyckats återgår agenten till huvuduppgiften.
• Deluppgifter får inte skapa ett obegränsat antal egna underuppgifter.

Det är detta ramverk som LangGraph försöker formalisera – en tillståndsmaskin där varje nod är ett tydligt steg med uttryckliga övergångar.

För komplexa agenter är strukturen nödvändig. För enkla agenter är den överdriven.

Mönster 8: Reträttvägar

När en agent fastnar behöver den uttryckliga sätt att sluta:

Eskalera. ”Jag kan inte slutföra uppgiften. Här är vad jag har försökt och vad som saknas.” Agenten slutar och synliggör problemet.

Delvis slutförande. ”Jag har slutfört del A och B. C blockeras av X.” Agenten behöver inte lyckas fullt ut, utan kan lämna användbara delresultat.

Förtydligande. ”Jag behöver mer information från användaren: …” Agenten pausar och frågar.

Detta bör vara fullvärdiga alternativ för agenten, inte sista utvägar. Agentens prompt bör nämna dem och uppmuntra användning när agenten har fastnat.

Ett användbart tillägg till prompten:

Om du hamnar i någon av följande situationer ska du sluta försöka och svara på lämpligt sätt:
- Ett verktyg returnerar konsekvent samma fel.
- Du har provat 3 olika metoder utan framsteg.
- Du behöver information som bara användaren kan lämna.
- Uppgiften är mer komplex än vad dina verktyg stöder.

I dessa fall:
- Vid verktygsfel: förklara problemet och föreslå att användaren kontaktar supporten.
- Vid brist på framsteg: redovisa vad du har försökt och be om vägledning.
- Vid saknad information: ställ en specifik fråga till användaren.
- Vid för hög komplexitet: eskalera till mänsklig hjälp med en sammanfattning.

Mönster 9: Konfidensmedvetna åtgärder

Agenten bör veta när den är säker och när den inte är det. Agerande med låg konfidens är ett sätt som loopar börjar på.

Ett mönster är att varje betydelsefull åtgärd kräver en uttrycklig konfidensbedömning.

Ange före anropet till delete_record hur säker du är på en skala från 1 till 5 på att detta är rätt åtgärd. Anropa inte om värdet är <4. Be i stället om mänsklig bekräftelse.

Detta fungerar särskilt bra för destruktiva eller dyra åtgärder. Agenten måste förbinda sig till hög konfidens innan den utför dem.

I kombination med reflektion fångar detta fall där agenten ”provar saker” i stället för att ”genomföra en plan”.

Mönster 10: Skydd på verktygsnivå

Utöver mönster på agentnivå kan verktygen själva ha skydd:

Frekvensbegränsning per session. Ett verktyg får bara anropas N gånger under en session. Efter N returnerar det ”rate limit”. Det tvingar agenten att göra något annat.

Idempotens. Upprepade identiska anrop returnerar det cachade resultatet utan att köra åtgärden igen. Det förhindrar loopar som hamrar på ett verktyg.

Kostnadstak. Dyra verktyg – tunga databasfrågor och tredjeparts-API:er med användningskostnader – har gränser per session.

Automatiska brytare vid fel. Ett verktyg som har misslyckats 3 gånger under sessionen inaktiveras. Agenten kan inte längre anropa det.

Detta kompletterar mönstren på agentnivå. Agenten kan försöka loopa, men verktyget hindrar den.

Mönster 11: Extern övervakning

Trots alla mönster inuti agenten behövs en extern övervakare som fångar det som slinker igenom.

En övervakningsprocess bevakar alla agenter som körs. Den kontrollerar:

• Antal steg per agent.
• Tokenanvändning per agent.
• Kostnad per agent.
• Tid per agent.
• Mönster för verktygsanrop.

Avsluta agenten och skicka en avisering när den överskrider något tröskelvärde.

Det är den sista försvarslinjen. Även om själva agenten är trasig fångar övervakaren den innan den skadar plånboken.

I implementationen:

• En tidsseriedatabas registrerar agentmätvärden.
• Regler utlöser avslutningsorder (”om agenten har körts i mer än 5 minuter, avsluta”).
• En liten tjänst övervakar och verkställer.

Det är nödvändigt för system som kör många agenter samtidigt.

Mönster 12: Kontrollpunkter med människa i processen

Bygg in mänskliga kontrollpunkter för agenter med höga insatser. Agenten körs fram till en kontrollpunkt och inväntar sedan mänskligt godkännande.

Typiska kontrollpunkter:

• Före destruktiva åtgärder.
• Efter ett beslut som agenten inte kan återkalla.
• Vid viktiga milstolpar i en lång uppgift.
• När konfidensen sjunker.

Det handlar inte om misstro, utan om att fånga fel när de fortfarande är billiga att åtgärda.

Ett praktiskt arbetsflöde är att agenten utför förberedelserna självständigt och visar en sammanfattning och föreslagna åtgärder. En människa godkänner och agenten verkställer. Människan deltar i besluten, inte i varje steg.

Ett praktiskt exempel: en långvarig informationssökningsagent

Som illustration tillämpar vi mönstren på en verklig agent:

Uppgift: undersök en konkurrent och ta fram ett kort beslutsunderlag.

Uppskattat arbete: 10–30 webbsökningar, läsning av 20–50 sidor och syntes till ett underlag på 1 000 ord.

Tillämpade mönster:

1. Stegbudget: totalt 60 steg.

2. Tokenbudget: 300K token (kontext + åtgärder). Om den överskrids, sammanfatta de aktuella resultaten och fortsätt.

3. Kostnadsbudget: 2 euro per körning. Om den överskrids, sluta och returnera ett ofullständigt underlag.

4. Tidsbudget: 5 minuters faktisk tid.

5. Uppföljning av framsteg: i varje steg uppdaterar agenten en ”resultatlogg” med ny information. Om 3 steg går utan nya resultat ska agenten använda en reträttväg.

6. Upptäckt av upprepningar: om samma sökfråga körs två gånger med liknande resultat ska en annan metod framtvingas.

7. Reflektionspunkter: agenten reflekterar över framsteg och återstående arbete vart 10:e steg.

8. Målförankring: underlagets ursprungliga mål står överst i varje systemmeddelande.

9. Reträttvägar: både ”Jag har tillräckligt med information” och ”Jag kan inte hitta tillräcklig information” avslutar agenten på ett kontrollerat sätt.

10. Extern övervakare: en oberoende övervakare avslutar agenter som överskrider budgetarna.

Resultat: medianen för körtiden är 3 minuter. Mediankostnaden är 0,40 euro. Felfrekvensen – loopar eller tidsgränser – är < 1 %. De framtagna underlagen är 700–1 200 ord, faktabaserade och användbara utgångspunkter.

Utan mönstren förekommer enstaka körningar på 30 minuter, kostnader över 20 euro och sessioner som ibland låser sig helt. Mönstren minskar extremfallen drastiskt.

Upptäckt i produktion

Även med dessa mönster slinker enstaka problem igenom. Upptäck dem:

Aviseringar om långvariga agenter. En agent som kör längre än 2 gånger mediantiden utlöser en avisering.

Varningar om kostnadstoppar. Kostnader per agent eller sammanlagda kostnader över tröskelvärdet.

Varningar om upprepade mönster. Mönster i verktygsanrop som tyder på loopar.

Daglig granskning av långvariga spårningar. En människa ögnar igenom dagens 10 längsta spårningar. Det fångar problem som utvärderingarna missar.

Aggregerade mätvärden: loopfrekvens över tid. Det upptäcker när en förändring – modelluppdatering eller promptändring – ökar loopfrekvensen.

En användbar instrumentpanel visar fördelningen av agentkörningarnas längd. Svansen visar förekomsten av loopar.

Vanliga misstag

Några återkommande mönster:

Misstag 1: Ingen stegbudget. ”Vi lägger till det om det behövs.” Sedan loopar agenten klockan 3 på natten och du önskar att du hade gjort det. Lägg alltid till budgeten från dag ett.

Misstag 2: För höga budgetar. ”100 steg borde räcka” – men en loop fyller dem. Sätt budgetarna till 2–3 gånger medianen, inte värsta tänkbara fall.

Misstag 3: Ingen extern övervakare. Teamet litar på att agenten stoppar sig själv. Ibland gör den inte det. Extern övervakning är nödvändig i produktion.

Misstag 4: Loopar fångas men analyseras inte. En loop inträffar, övervakaren avslutar agenten och teamet går vidare. Samma loop inträffar nästa vecka. Gör alltid en efteranalys av fångade loopar: vad utlöste den, vad förändrades och kan vi förhindra hela felkategorin?

Misstag 5: Överdriven reflektion för enkla uppgifter. Att tvinga fram reflektion vart 5:e steg i en uppgift med 5 steg är en omkostnad utan nytta. Anpassa efter uppgiftens komplexitet.

Misstag 6: Mål går förlorade i långa kontexter. Ett mål som nämns en gång i steg 1 överlever inte till steg 50. Förankra det regelbundet på nytt.

Misstag 7: Tillit till agentens egen rapportering om framsteg. Agenter säger att de gör framsteg även när de inte gör det. Verifiera externt där det är möjligt.

Misstag 8: Agenter tillåts anropa sig själva rekursivt. ”Dela upp uppgiften mellan underagenter” kan ge en exponentiell tillväxt av skapade agenter. Om du tillåter det ska budgeten vara strikt.

När loopar är godtagbara

Alla loopar är inte dåliga. Vissa uppgifter kräver många iterationer:

• Iterativ förbättring av kod (skriv, testa, korrigera, upprepa).
• Informationssökning i flera steg med förgreningar.
• Optimeringsuppgifter (prova varianter, utvärdera, förbättra).

I dessa fall är looparna själva arbetet, inte ett fel. Mönstren ändras:

• Generösa stegbudgetar (50–200 steg).
• Uttrycklig inramning som ”iteration”, inte ”loop”.
• Uppföljning av kvalitetsförbättring – varje iteration bör förbättra ett mätvärde.
• Hårt stopp när förbättringen planar ut.

Principen är att skilja ”avsiktligt iterativt arbete” från ”oavsiktliga loopar”. Tillämpa mönstren på lämpligt sätt för respektive kategori.

Checklista för produktion

Agenter som loopar för evigt är förutsägbara, vanliga och möjliga att förhindra. Mönstren är välkända: stegbudgetar, uppföljning av framsteg, upptäckt av upprepningar, reflektion, målförankring, reträttvägar, verktygsskydd och externa övervakare.

Detta är inte valfri finslipning. Det är skillnaden mellan agenter som når produktion och agenter som ger oväntade fyrsiffriga räkningar.

Checklistan för varje produktionsagent:

• Högsta stegbudget.
• Högsta tokenbudget.
• Högsta kostnadsbudget.
• Högsta tidsbudget.
• Upptäckt av upprepade anrop.
• Uppföljning av framsteg.
• Regelbunden reflektion.
• Målförankring.
• Flera reträttvägar.
• Extern övervakare med möjlighet att avsluta agenten.

Varje punkt är enkel att implementera. Tillsammans utgör de skillnaden mellan ”den här agenten är farlig att lämna igång” och ”den här agenten är tillförlitlig i produktion”.

Bygg in mönstren. Testa dem. Den extrema risk du eliminerar är värd arbetet många gånger om.