Design af agenter, der ikke fortsætter i det uendelige

En typisk form for dyr AI-fejl i produktion: Klokken er 3 om natten en tirsdag, og en kundesupportagent går ind i en uendelig løkke. Den kalder det samme værktøj, får den samme fejl, prøver igen med en lidt ændret parameter, får samme fejl og gentager. Hundredvis af gange i minuttet. Om morgenen har teamet fået en uventet regning på fire eller fem cifre — afhængigt af modellen og kaldhyppigheden.

Det er ikke sjældent. Agenter, der kører i løkke, er blandt de mest almindelige — og mest alvorlige — produktionsfejl. De er lumske, fordi det ofte »ser ud, som om de arbejder« — agenten udfører handlinger, og kaldene lykkes (eller fejler forudsigeligt). Først når du undersøger sporingen, ser du det samme mønster gentage sig.

At bygge agenter, der ikke fortsætter i det uendelige, kræver bevidste arkitekturvalg. De fleste agentfejl er forudsigelige, og mønstrene til at forhindre dem er velkendte. De teams, der leverer pålidelige agenter, er dem, der implementerer disse mønstre konsekvent.

Denne artikel gennemgår, hvad der får agenter til at køre i løkke, de arkitekturmønstre, der forhindrer det, og de driftsmæssige værn, som fanger løkker, når de alligevel slipper igennem.

Hvorfor agenter kører i løkke

Her er nogle af mekanismerne bag agentløkker:

1. Uklarhed om fremskridt

Agenten har ikke en klar fornemmelse af: »Har jeg gjort fremskridt?« Den prøver noget, observerer et resultat og beslutter at prøve noget andet. Uden eksplicit registrering af fremskridt kan »prøv noget andet« betyde »det samme på en lidt anden måde«.

2. Manglende stopkriterier

Agentens prompt siger »hjælp brugeren«, men ikke »stop, når X er sandt«. Uden klare stopkriterier fortsætter agenten med at »hjælpe« — den leder efter endnu en oplysning, prøver endnu et værktøj eller finpudser yderligere.

3. Patologiske genforsøg

Når noget fejler, prøver agenter naturligt igen. Uden et budget for genforsøg kan den samme fejl gentages i det uendelige. Agenten opfatter »jeg er ikke lykkedes endnu«, ikke »jeg har allerede prøvet dette 10 gange«.

4. Hukommelsestab om tilstand

Agentens arbejdshukommelse indeholder kun de seneste trin. Hvis en løkke har været gennem 20 forsøg, ser agenten måske kun de sidste 5 i sin kontekst — og mister dermed det mønster, som nu er indlysende for en ekstern observatør.

5. Inkonsistente værktøjer

Et værktøj returnerer forvirrende eller modstridende resultater. Agenten prøver igen. Værktøjet returnerer stadig forvirrende resultater. Agenten ræsonnerer: »Måske var min tidligere fortolkning forkert« og prøver på en anden måde. Værktøjet returnerer fortsat forvirrende resultater. Løkke.

6. Overdreven optimisme

Agentens træning gør den vedholdende — den fortsætter med at prøve, selv når en bedre strategi ville være at stoppe og bede om hjælp. Det er særligt problematisk i langvarige opgaver, hvor små misforståelser hober sig op.

7. Målafdrift

Agenten mister gradvist det oprindelige mål af syne. Den forgrener sig til delopgaver og derefter underdelopgaver og udforsker perifere områder uden at vende tilbage til hovedmålet.

Forskellige agenter fejler på forskellige måder. Forsvarsmekanismerne overlapper hinanden.

Mønster 1: Hårde trinbudgetter

Det enkleste og vigtigste forsvar er et maksimalt antal trin. Agenten har eksempelvis 20 værktøjskald til rådighed. Efter 20, uanset resultatet, skal den levere et endeligt svar (eller eskalere).

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})
    # Hit budget — force final answer
    return force_final_answer(messages)

Budgettet skal tilpasses opgaven. Enkle opgaver: 5-10 trin. Komplekse opgaver med flere kilder: 20-30. Åben research: 50+. Men altid med en fast grænse.

Når budgettet er opbrugt, leverer agenten sit bedste svar ud fra det, den ved. Eller eskalerer til et menneske.

Dette ene mønster forhindrer de fleste katastrofale løkker. Implementér det altid.

Varianter

Tokenbudget. Begræns det samlede antal tokens i stedet for (eller ud over) antallet af trin. Det forhindrer agenter, som tager færre trin, men bruger et ræsonnementsspor på 50K tokens i hvert trin.

Omkostningsbudget. Omsætter trin- og tokenbudgetter til euro. Det gør budgetoverskridelser konkrete.

Tidsbudget. En grænse for den faktiske tid. Nyttig i brugervendte flows (»svar inden for 30 sekunder«).

De fleste produktionsagenter har alle fire budgetter i en eller anden form. Når blot ét af dem rammes, afsluttes kørslen.

Mønster 2: Registrering af fremskridt

Et budget fortæller ikke i sig selv agenten, at den sidder fast — det stopper den blot på et tidspunkt. Registrering af fremskridt hjælper agenten med at genkende en løkke og bryde ud af den.

En enkel implementering er, at agenten fører en eksplicit log over fremskridt. I hvert trin angiver den, hvilken ny information den har fået, eller hvad der har ændret sig.

Step 1: Searched for customer "Smith". Found 12 matches.
Step 2: Filtered to active accounts. 4 remain.
Step 3: Checked recent activity. Customer 234 had a recent ticket about pricing.
Step 4: Pulled the ticket details. The complaint was about a recent price change.
Step 5: Drafted response. Ready to send.

Hvert trin tilføjer ny information. Hvis agenten udfører trin 6 uden at loggen får noget nyt — samme søgning, samme resultater og samme konklusion — står den og spinner.

Prompten kan indeholde:

Before deciding the next action, summarize what you've learned in the last few steps. If you haven't gained new information in the last 3 steps, stop and either:
- Produce your best answer with current information.
- Escalate the issue: explain what you've tried and what's missing.

Det gør »manglende fremskridt« synligt for agenten, så den kan reagere.

Mønster 3: Registrering af gentagelser

Nogle gange gentager agenter præcis det samme værktøjskald. Det er let at opdage programmatisk.

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

Grib ind, hvis en gentagelse opdages:

• Indsæt en besked: »Du har for nylig kaldt dette værktøj med disse parametre. Resultaterne har ikke ændret sig. Prøv en anden tilgang, eller afslut.«
• Eller gennemtving afslutning.

Det fanger automatisk de mest indlysende løkker.

Mønster 4: Registrering af fastlåst tilstand

Ud over præcise gentagelser kan du registrere mere subtile fastlåste tilstande:

Mønstergenkendelse. Brug et separat LLM-kald til at vurdere: »Ser agenten ud til at gøre fremskridt i de sidste 5 trin?« Hvis ikke, bryd ud.

def is_stuck(history):
    recent = format_history(history[-5:])
    response = call_llm(
        system="You are evaluating whether an agent is making progress.",
        user=f"Recent agent steps:\n{recent}\n\nIs the agent making meaningful progress or stuck in a loop? Answer: progressing | stuck."
    )
    return response.content.strip() == "stuck"

Kør kontrollen med få trins mellemrum. Grib ind, hvis den returnerer »stuck«.

Værktøjsvariation. Hvis agenten kun har kaldt 1 værktøj i 5+ trin, er det mistænkeligt. Tving den til at prøve noget andet eller stoppe.

Fejlmønstre. Hvis det samme værktøj har returneret den samme fejl 3+ gange, skal du stoppe med at bruge det. Agenten finder ikke det manglende input ved at prøve flere gange.

Mønster 5: Refleksionspunkter

Tving agenten til eksplicit refleksion på bestemte tidspunkter i kørslen.

After every 5 steps, the agent must produce a reflection:

1. What was my original goal?
2. What have I learned so far?
3. What do I still need to know?
4. Am I making progress, or repeating?
5. Should I continue or stop?

Refleksionen tvinger agenten til at træde et skridt tilbage fra tankerne om den umiddelbart næste handling og vurdere helheden.

Det er særligt effektivt ved langvarige opgaver. Uden tvungen refleksion driver agenter væk fra målet; med den opdager de deres egen afdrift.

Mønster 6: Forankring i målet

Under lange agentkørsler forsvinder det oprindelige mål. Agentens kontekstvindue fyldes med mellemliggende trin, og det oprindelige spørgsmål bliver en lille del af en stor kontekst.

Modvirk det ved gentagne gange at forankre agenten i målet:

• Medtag det oprindelige mål øverst i hver systembesked.
• Lad agenten gentage målet for hvert N trin.
• Brug en separat »målsporing«, der bekræfter, at hvert trin stemmer overens med målet.

Ekstra tekst til prompten:

Original goal: [verbatim user request]

Before each action, confirm:
- Is this action helping me toward the original goal?
- If yes, proceed.
- If no, return to the goal directly.

Mønster 7: Afgrænsning af delopgaver

Langvarige agenter opdeler naturligt arbejdet i delopgaver. Uden struktur kan delopgaver rekursivt skabe underdelopgaver, indtil agenten farer vild.

Skab struktur:

• Agenten identificerer delopgaver eksplicit.
• Hver delopgave har sit eget budget.
• Når en delopgave er fuldført (eller fejler), vender agenten tilbage til hovedopgaven.
• Delopgaver må ikke skabe et ubegrænset antal underdelopgaver.

Det er det, frameworks som LangGraph forsøger at formalisere — en tilstandsmaskine, hvor hver node er et klart trin med eksplicitte overgange.

For komplekse agenter er denne struktur afgørende. For enkle agenter er den overdimensioneret.

Mønster 8: Nødudgange

Når en agent sidder fast, skal den have eksplicitte måder at stoppe på:

Eskalering. »Jeg kan ikke fuldføre denne opgave. Her er, hvad jeg har prøvet, og hvad der mangler.« Agenten stopper og gør problemet synligt.

Delvis fuldførelse. »Jeg har fuldført del A og B. C er blokeret af X.« Agenten behøver ikke lykkes fuldt ud; den kan levere et nyttigt delresultat.

Afklaring. »Jeg har brug for flere oplysninger fra brugeren: …« Agenten sætter arbejdet på pause og spørger.

Det bør være agentens naturlige valgmuligheder, ikke sidste udvej. Agentens prompt bør omtale dem og tilskynde til at bruge dem, når arbejdet sidder fast.

Et nyttigt tillæg til prompten:

If you encounter any of these situations, stop trying and respond appropriately:
- A tool consistently returns the same error.
- You've tried 3 different approaches without progress.
- You need information only the user can provide.
- The task is more complex than your tools support.

In these cases:
- For tool errors: explain the issue, suggest the user contacts support.
- For lack of progress: report what you've tried and ask for guidance.
- For missing information: ask the user a specific question.
- For complexity: escalate to human assistance with a summary.

Mønster 9: Handlinger baseret på sikkerhed

Agenten bør vide, hvornår den er sikker, og hvornår den ikke er. Handling på lav sikkerhed er ofte starten på en løkke.

Et mønster er, at enhver betydningsfuld handling kræver eksplicit angivelse af sikkerhed.

Before calling delete_record, state your confidence on a 1-5 scale that this is the right action. If <4, do not call. Instead, ask for human confirmation.

Det virker særligt godt ved destruktive eller dyre handlinger. Agenten skal forpligte sig til høj sikkerhed, før den udfører dem.

Kombineret med refleksion fanger det tilfælde, hvor agenten »prøver sig frem« frem for at »udføre en plan«.

Mønster 10: Værn på værktøjsniveau

Ud over mønstre på agentniveau kan værktøjerne selv have værn:

Hastighedsbegrænsning pr. session. Et værktøj kan kun kaldes N gange i en session. Efter N returnerer det »rate limit«. Det tvinger agenten til at gøre noget andet.

Idempotens. Gentagne, identiske kald returnerer det cachede resultat uden at udføre handlingen igen. Det forhindrer løkker, der bombarderer et værktøj.

Omkostningslofter. Dyre værktøjer (tunge databaseforespørgsler, tredjeparts-API’er med brugsbetaling) har grænser pr. session.

Automatsikringer ved fejl. Et værktøj, der er fejlet 3 gange i samme session, deaktiveres. Agenten kan ikke længere kalde det.

Disse supplerer mønstrene på agentniveau. Agenten forsøger måske at køre i løkke, men værktøjet forhindrer det.

Mønster 11: Ekstern overvågning

På trods af alle mønstrene i agenten fanger en ekstern overvågning det, der slipper igennem.

En overvågningsproces holder øje med alle aktive agenter. Den kontrollerer:

• Antal trin pr. agent.
• Tokenforbrug pr. agent.
• Omkostning pr. agent.
• Tid pr. agent.
• Mønstre i værktøjskald.

Hvis en agent overskrider en grænse, standses den. Send en alarm.

Det er den sidste forsvarslinje. Selv hvis agenten er defekt, fanger overvågningen den, før den skader økonomien.

I en implementering:

• En tidsseriedatabase registrerer agentmålinger.
• Regler udløser stopordrer (»hvis agenten har kørt i > 5 minutter, stands den«).
• En lille tjeneste overvåger og håndhæver reglerne.

For systemer, der kører mange agenter samtidigt, er dette afgørende.

Mønster 12: Kontrolpunkter med et menneske i løkken

Byg menneskelige kontrolpunkter ind for agenter med stor konsekvens. Agenten arbejder frem til et kontrolpunkt og venter derefter på menneskelig godkendelse.

Typiske kontrolpunkter:

• Før destruktive handlinger.
• Efter en beslutning, som agenten ikke kan omgøre.
• Ved store milepæle i en lang opgave.
• Når sikkerheden falder.

Det handler ikke om mistillid — det handler om at fange fejl, mens de er billige at rette.

En praktisk arbejdsgang: Agenten udfører forberedelser selvstændigt, viser et resumé og foreslåede handlinger, et menneske godkender, og agenten udfører. Mennesket er med i løkken ved beslutninger, ikke ved hvert trin.

Et gennemarbejdet eksempel: en langvarig researchagent

For at illustrere det anvender vi mønstrene på en virkelig agent:

Opgave: Undersøg en konkurrent, og udarbejd en briefing.

Anslået arbejde: 10-30 websøgninger, 20-50 læste sider og sammenfatning i en briefing på 1000 ord.

Anvendte mønstre:

1. Trinbudget: 60 trin i alt.

2. Tokenbudget: 300K tokens (kontekst + handlinger). Hvis det overskrides, sammenfattes de aktuelle resultater, og arbejdet fortsætter.

3. Omkostningsbudget: €2 pr. kørsel. Hvis det overskrides, stoppes arbejdet, og der returneres en delvis briefing.

4. Tidsbudget: 5 minutters faktisk tid.

5. Registrering af fremskridt: I hvert trin opdaterer agenten en »resultatlog« med nye oplysninger. Hvis der går 3 trin uden nye resultater, bruges en nødudgang.

6. Registrering af gentagelser: Hvis den samme søgeforespørgsel køres to gange med lignende resultater, gennemtvinges en anden tilgang.

7. Refleksionspunkter: For hvert 10 trin reflekterer agenten over fremskridt og resterende arbejde.

8. Forankring i målet: Den oprindelige briefings mål står øverst i hver systembesked.

9. Nødudgange: »Jeg har information nok« og »Jeg kan ikke finde tilstrækkelig information« afslutter begge agenten på en kontrolleret måde.

10. Ekstern overvågning: En uafhængig overvåger standser agenter, der overskrider budgetterne.

Resultat: Median køretid på 3 minutter. Medianomkostning på €0.40. Fejlrate (løkker eller timeouts) < 1%. De producerede briefinger er på 700-1200 ord, faktuelt funderede og nyttige som udgangspunkt.

Uden disse mønstre: lejlighedsvise kørsler på 30 minutter, lejlighedsvise omkostninger på €20+ og lejlighedsvise fastlåste sessioner. Mønstrene reducerer den ekstreme hale markant.

Registrering i produktion

Selv med mønstrene slipper enkelte problemer igennem. Sådan opdager du dem:

Alarmer for langvarige agenter. Enhver agent med en varighed > 2x medianen udløser en alarm.

Alarmer ved omkostningsstigninger. Omkostning pr. agent eller samlet omkostning over en grænse.

Alarmer ved gentagelsesmønstre. Mønstre i værktøjskald, der tyder på løkker.

Daglig gennemgang af langvarige spor. Et menneske ser kort på dagens 10 længste spor. Det fanger problemer, som evalueringerne overser.

Samlede målinger: løkkerate over tid. Det afslører, når noget ændres (modelopdatering, promptændring), så løkkefrekvensen stiger.

Et nyttigt dashboard viser fordelingen af agenternes køretider. Halen fortæller dig, hvor ofte løkker forekommer.

Almindelige fejl

Her er nogle mønstre, vi ser igen og igen:

Fejl 1: Intet trinbudget. »Vi tilføjer det, hvis vi får brug for det.« Så kører agenten i løkke klokken 3 om natten, og du ville ønske, at du havde tilføjet det. Tilføj det altid fra første dag.

Fejl 2: For høje budgetter. »100 trin burde være rigeligt« — men en løkke udfylder dem. Sæt budgetterne til 2-3x medianen, ikke det værst tænkelige tilfælde.

Fejl 3: Ingen ekstern overvågning. Man stoler på, at agenten stopper sig selv. Nogle gange gør den det ikke. Ekstern overvågning er afgørende i produktion.

Fejl 4: Løkker fanges, men analyseres ikke. En løkke opstår, overvågningen standser den, og teamet går videre. Den samme løkke opstår ugen efter. Foretag altid en efteranalyse af fangede løkker — hvad udløste den, hvad blev ændret, og kan vi forhindre hele fejlklassen?

Fejl 5: Overdreven refleksion ved enkle opgaver. Tvungen refleksion for hvert 5 trin i en opgave på 5 trin er overhead uden fordel. Tilpas det efter opgavens kompleksitet.

Fejl 6: Mål mistes i lange kontekster. Et mål, der nævnes én gang i trin 1 overlever ikke til trin 50. Forankr det igen med jævne mellemrum.

Fejl 7: Tillid til agentens egen rapportering af fremskridt. Agenter siger, at de gør fremskridt, selv når de ikke gør. Kontrollér det eksternt, hvor det er muligt.

Fejl 8: Agenter får lov at kalde sig selv rekursivt. »Opdel denne opgave blandt underagenter« kan skabe eksponentielt mange agenter. Hvis du tillader det, skal budgettet være stramt.

Hvornår løkker er acceptable

Ikke alle løkker er dårlige. Nogle opgaver kræver reelt mange iterationer:

• Iterativ forbedring af kode (skriv, test, ret, gentag).
• Research i flere trin med forgreninger.
• Optimeringsopgaver (prøv varianter, evaluér, forbedr).

Her er løkkerne selve arbejdet, ikke en fejl. Mønstrene ændres:

• Generøse trinbudgetter (50-200 trin).
• Eksplicit framing som »iteration«, ikke som »løkke«.
• Registrering af kvalitetsforbedring — hver iteration skal forbedre et målepunkt.
• Hårdt stop, når forbedringen flader ud.

Princippet er at skelne mellem »tilsigtet iterativt arbejde« og »utilsigtede løkker«. Anvend mønstrene korrekt på hver type.

Tjeklisten til produktion

Agenter, der fortsætter i det uendelige, er forudsigelige, almindelige og mulige at forhindre. Mønstrene er velkendte: trinbudgetter, registrering af fremskridt, registrering af gentagelser, refleksion, forankring i målet, nødudgange, værktøjsværn og ekstern overvågning.

Det er ikke valgfri finpudsning. Det er forskellen mellem agenter, der kommer i produktion, og agenter, der giver uventede regninger på fire cifre.

Tjeklisten for enhver produktionsagent:

• Maksimalt trinbudget.
• Maksimalt tokenbudget.
• Maksimalt omkostningsbudget.
• Maksimalt tidsbudget.
• Registrering af gentagne kald.
• Registrering af fremskridt.
• Periodisk refleksion.
• Forankring i målet.
• Flere nødudgange.
• Ekstern overvågning med mulighed for at standse agenten.

Hvert punkt er enkelt at implementere. Tilsammen er de forskellen mellem »denne agent er farlig at lade køre« og »denne agent er pålidelig i produktion«.

Byg mønstrene ind. Test dem. Den halerisiko, du eliminerer, er arbejdet værd mange gange.