Hvordan AI‑agenter fungerer: Modellen, værktøjer, hukommelse og kontrolsløjfe

En AI‑agent fungerer ved at kombinere en model med instruktioner, værktøjer, hukommelse og en kontrolsløjfe, der gentagne gange beslutter, hvad der skal gøres næste gang. Modellen leverer dømmekraft og sproglige evner, mens den omgivende software omdanner disse evner til en tilstandsfuld proces, der kan handle, inspicere resultater, komme sig efter fejl og stoppe.

At forstå denne arkitektur er mere nyttigt end at betragte en agent som et enkelt intelligent objekt. De fleste succeser og fiaskoer opstår på grund af, hvordan komponenterne interagerer: en fremragende model kan undermineres af vage værktøjer, forældet hukommelse, overdrevne tilladelser eller en kontrolsløjfe uden en pålidelig definition af færdiggørelse.

De fem kernekomponenter i en AI‑agent

1. modellen

Modellen fortolker målet, resonerer over den tilgængelige kontekst og vælger en handling. I mange nuværende agenter er dette en stor sprogmodel, der kan følge instruktioner og producere strukturerede værktøjsopkald såvel som naturligt sprog.

Den mest kapable model er ikke automatisk det bedste valg for hvert trin. Et system kan dirigere vanskelig planlægning til en stærkere model, bruge en hurtigere model til klassificering og stole på deterministisk kode til validering. Denne blanding kan forbedre hastighed, omkostninger og pålidelighed.

2. Instruktioner

Instruktioner definerer agentens rolle, grænser, prioriteter og outputkrav. De kan indeholde en systemprompt, opgavespecifik kontekst, politikker, eksempler, værktøjsbeskrivelser og stopkriterier.

Gode instruktioner er operationelle. De fortæller agenten, hvilket bevis der kræves, hvornår der skal anmodes om godkendelse, hvilke kilder der er acceptable, og hvordan fuldførelse genkendes. Regler, der er vage eller modstridende, tvinger modellen til at gætte, hvilket skaber inkonsistens på tværs af ellers lignende opgaver.

3. Værktøjer

Værktøjer forbinder modellen med funktioner uden for dens aktuelle kontekst. Et værktøj kan søge på nettet, hente en kundepost, køre kode, forespørge en database, styre en browser eller oprette en kalenderbegivenhed.

Modellen udfører normalt ikke funktionen selv. Den vælger et navngivet værktøj og foreslår strukturerede argumenter. Agentens runtime validerer anmodningen, tjekker tilladelser, udfører handlingen og returnerer resultatet. Denne adskillelse er essentiel: den giver softwaren en chance for at afvise fejlformede eller usikre handlinger, før de påvirker den ydre verden.

4. Tilstand og hukommelse

Tilstand er den information, agenten har brug for under den aktuelle kørsel: målet, samtalen, planen, observationerne, værktøjsoutput og afsluttede trin. Hukommelse udvider dette koncept ved at bevare nyttig information ud over den umiddelbare kontekst, såsom tidligere præferencer, tilbagevendende fakta eller erfaringer fra tidligere opgaver.

Mere hukommelse er ikke altid bedre. Irrelevante poster forbruger kontekst og kan lede modellen mod forældede antagelser. Effektive hukommelsessystemer beslutter, hvad der skal gemmes, hvordan det organiseres, hvornår det hentes, og hvordan modstridende eller udløbet information håndteres.

5. kontrolsløjfen

Kontrolsløjfen er orkestreringslaget, der holder processen i gang. Den sender den aktuelle tilstand til modellen, modtager en foreslået handling, kører godkendte værktøjer, registrerer observationen og kalder modellen igen.

Anthropic beskriver en agent som en udvidet sprogmodel, der opererer i en sløjfe med funktioner som genfinding, værktøjer og hukommelse i deres vejledning til building effective agents. OpenAI rammer på samme måde agenteksekvering som en løbende interaktion mellem modellen, dens værktøjer og et miljø i From Model to Agent.

Grænseflader er lige så vigtige som komponenterne

Et arkitekturd iagram kan få hver komponent til at fremstå rent adskilt, men reel pålidelighed afhænger af kontrakterne mellem dem. Modellen har brug for værktøjsbeskrivelser, der skelner mellem lignende funktioner. Runtime’en har brug for typede argumenter og eksplicitte fejltilgange. Hukommelses‑genfinding har brug for proveniens og friskheds‑information. Afslutnings‑kontrollen har brug for kriterier, der kan testes, frem for en vag fornemmelse af, at svaret er tilstrækkeligt.

Overvej et søgeværktøj, der returnerer en tom liste. Resultatet kan betyde, at ingen relevante poster findes, at forespørgslen var fejlformet, at brugeren mangler tilladelse, eller at tjenesten udløb. Hvis værktøjet samler alle fire betingelser i samme output, kan modellen ikke resonere pålideligt om, hvad der skete. En veludformet grænseflade returnerer struktureret evidens: status, kilde, tidsstempel, forespørgsel, resultatantal og en maskin‑læselig fejl, når det er relevant.

Det samme princip gælder for kontekst. Instruktioner, autoritative poster, hentede passager, model‑genererede noter og upålideligt eksternt indhold bør ikke behandles som ækvivalent tekst. At mærke deres kilde og autoritet hjælper runtime’en med at håndhæve politik og hjælper modellen med korrekt at vægte evidens. Dette er en praktisk form for kontekst‑engineering: at beslutte ikke kun, hvilken information modellen ser, men også hvordan den information organiseres, og hvad systemet tillader den at kontrollere.

Et trin‑for‑trin‑eksempel

Forestil dig en agent, der skal sammenligne tre potentielle leverandører og udarbejde en anbefaling.

1. Modtag målet: agenten læser beslutningskriterierne, deadline, budgettet og det krævede output.
2. Undersøg den tilgængelige kontekst: den tjekker, om leverandørnavne, interne krav og kilde‑dokumenter er til stede.
3. Udarbejd en plan: den beslutter at indsamle prisoplysninger, sikkerhedsinfo, servicevilkår og kundedokumentation for hver leverandør.
4. Vælg et værktøj: den søger i et godkendt dokumentlager eller kalder et eksternt forskningsværktøj.
5. Observer: runtime’en returnerer resultater, inklusive mulige fejl eller manglende felter.
6. Opdater tilstand: agenten registrerer, hvad den har lært, og markerer ubesvarede spørgsmål.
7. Tilpas: den ændrer forespørgsler, konsulterer en anden kilde eller beder en person om et utilgængeligt dokument.
8. Verificer: den tjekker, at hver anbefaling er understøttet, og at sammenligninger bruger de samme kriterier.
9. Stop eller anmod om godkendelse: den udarbejder et udkast til anbefaling, men overlader købsbeslutningen til den autoriserede person.

Det vigtige er, at sekvensen ikke var fuldstændig hårdkodet. Systemet valgte trin som svar på, hvad det fandt, men det opererede stadig inden for designede begrænsninger.

Planlægning er ikke altid en separat fase

Nogle agenter udarbejder en fuld plan, før de handler. Andre beslutter et trin ad gangen. Mange bruger en hybrid: de laver en grov plan, udfører den næste handling og reviderer den resterende plan, efterhånden som observationerne kommer ind.

Lange, stive planer kan blive forældede efter det første uventede resultat. Rent reaktive agenter kan vandre eller gentage arbejde. Et praktisk design bevarer nok planlægning til at holde retningen, mens det tillader omplanlægning, når miljøet ændrer sig.

ReAct‑rammen er et grundlæggende eksempel på at flettes ræsonnement sammen med handlinger og observationer. Dens centrale indsigt er, at et eksternt resultat kan korrigere, forfine eller omdirigere det næste ræsonnementstrin.

Hvordan agenter ved, hvornår de skal stoppe

Stop er et systemdesign‑problem. En model kan erklære succes for tidligt, fortsætte finpudsning efter målet er nået, eller fortsætte i en sløjfe, når et værktøj gentagne gange fejler.

Pålidelige agenter kombinerer flere stop‑mekanismer:

• Færdiggørelseskriterier: eksplicitte betingelser såsom påkrævede felter, beståede tests eller verificerede kildehenvisninger.
• Budgetter: grænser for trin, tid, model‑tokens, værktøjsopkald eller omkostninger.
• Fejlgrænser: eskalering efter gentagne fejl eller observationer med lav tillid.
• Godkendelsesporte: en pause før handlinger med høj påvirkning eller irreversible konsekvenser.
• Eksterne bedømmere: deterministiske kontroller eller separate modeller, der vurderer, om output opfylder opgaven.

Almindelige agentarkitekturer

En enkelt‑agent‑sløjfe er det simpleste design: en model bruger gentagne gange værktøjer, indtil den er færdig. Det er lettere at fejlfinde og ofte tilstrækkeligt.

En router klassificerer forespørgslen og sender den til en specialiseret prompt, værktøjssæt eller model. Routing reducerer irrelevante valg og kan anvende forskellige politikker på forskelligt arbejde.

En orchestrator‑worker‑arkitektur lader en ledende agent oprette delopgaver og delegere dem til arbejdere, hvorefter resultaterne syntetiseres. Dette er nyttigt, når arbejde kan køres parallelt eller kræver forskellige specialer, men det øger token‑forbruget og koordinerings‑fejltilstande.

En evaluator‑optimizer‑sløjfe adskiller generering fra kritik. En komponent producerer et svar; en anden tjekker det mod definerede kriterier; den første reviderer det. Dette fungerer godt, når kvalitet kan måles, og forbedring gennem iteration er værd den ekstra omkostning.

Hvad går typisk galt

• Dårlige værktøjsbeskrivelser: modellen vælger den forkerte funktion eller leverer ugyldige argumenter.
• Ubegrænset kontekst: lange transskriptioner fyldes med irrelevant detaljer og begraver afgørende information.
• Stille værktøjsfejl: et tomt eller delvist resultat opfattes som en gyldig observation.
• Svag forankring: agenten handler på en antagelse i stedet for at tjekke systemets registre.
• Overdreven autonomi: agenten kan foretage væsentlige handlinger uden en passende godkendelsesgrænse.
• Ingen trajektorievaluering: teams vurderer det endelige svar, men inspicerer ikke, hvordan agenten nåede det.

Designprincipper for pålidelige agenter

Start med den mindste arkitektur, der kan løse opgaven. En deterministisk arbejdsgang bør håndtere kendte trin; reserver model‑diskretion til beslutninger, der virkelig kræver fortolkning. Giv hvert værktøj et snævert formål, typede input, eksplicitte fejltilgange og mindst‑mulig tilladelse.

Gør tilstanden synlig. Log hver værktøjs‑kald, resultat, genforsøg, godkendelse og model‑beslutning, der er nødvendig for diagnostik. Komprimer gammel kontekst i stedet for uendeligt at tilføje den, og bevar autoritative data separat fra model‑genererede opsummeringer.

Design runtime’en så fejl er eksplicitte. Et værktøj bør skelne mellem “ingen poster fundet” og “forespørgsel fejlet”, og tilstands‑lageret bør skelne mellem verificerede fakta og model‑genererede opsummeringer. Ellers kan modellen behandle en mangel forårsaget af en timeout som bevis for, at noget ikke findes.

Endelig, evaluer det komplette system. Kør den samme opgave flere gange, mål succes og ressourceforbrug, og inspicer trajektorier for overtrædelser af politik eller skrøbelige genveje. Anthropic’s vejledning til agent‑evalueringer understreger, at agenter har brug for opgaver, gentagelige forsøg, transskriptioner og bedømmere – ikke kun et håndfuld imponerende demoer.

Hvad man skal huske om, hvordan AI‑agenter fungerer

En AI‑agent er en konstrueret sløjfe, ikke blot en smart model. Modellen beslutter; værktøjer handler; hukommelse bærer tilstand; miljøet returnerer evidens; og kontrolsløjfen bestemmer, hvad der sker næste gang.

Når disse dele har klare grænseflader og afgrænsninger, kan en agent håndtere åbent arbejde, som konventionel automatisering ikke kan forudse. Når de ikke har det, forstærker autonomi tvetydighed. Kvaliteten af en agent afhænger derfor lige så meget af systemdesign, tilladelser og evaluering som af den underliggende model.