Agent Harnesses: infrastrukturen bakom tillforlitliga AI-agenter

Manga AI-agentdemos ser likadana ut i borjan: koppla in en stark modell, lagg till nagra verktyg, skriv en bra prompt och lat systemet arbeta igenom en uppgift. Det kan racka for en demo. Det rackar inte for produktion. Produktionsagenter maste komma ihag relevant kontext, anvanda verktyg sakert, aterhamta sig efter fel, respektera behorigheter, verifiera sitt eget arbete och fortsatta arbeta nar en uppgift tar langre tid an ett enda rent modellsvar. Modellen spelar roll, men systemet runt modellen avgor om agenten ar anvandbar varje dag. Detta system kallas ofta agent harness, agent runtime, orchestration layer, execution environment eller agent scaffolding. I den har artikeln anvander vi "agent harness" for att mena runtime- och orkestreringslagret runt modellen. Andra team kan kalla samma lager agent framework, orchestration layer, execution runtime eller agent scaffolding.

Vad en agent harness ar

En agent harness ar den mjukvaruinfrastruktur som gor om en statslos sprakmodell till en fungerande agent. Modellen predicerar, planerar och utfor resonemangsliknande inferens. Harness-lagret ger den en kontrollerad miljo dar den kan agera. Ett produktionsharness innehaller oftast:

orkestreringsloopar
registrering och exekvering av verktyg
kontexthantering
korttids- och langtidsminne
tillstandspersistens
behorighetskontroller
sandboxed execution
retries och felhantering
verifieringsloopar
tracing och observability
modellroutning
delegering till subagenter

Utan detta lager ligger en AI-agent oftast narmare ett chatliknande granssonitt eller en assistent med ett enda steg. Med detta lager kan den bli en workflow-motor. Om en anvandare till exempel ber en agent fixa en checkout-bugg kan modellen kanske bara foresla var man ska titta. Ett harness later agenten inspektera repot, sok efter filer, redigera kod, kora tester, lasa fel, reparera patchen, granska diffen och stoppa forst nar resultatet ar verifierat. Den skillnaden ar produkten.

Varfor harness-lagret blir viktigare

AI-team lar sig att tva produkter som anvander samma modell kan ge mycket olika resultat. Skalet ar infrastrukturen. Frontier-modeller blir snabbt battre. Nar formagor som tool use, structured output, long context, code generation och resonemangsliknande inferens blir tillgangliga hos fler leverantorer flyttas mer av produktfordelen till miljoen runt modellen. Arbete med harness-lagret byggs ocksa pa over tid. Varje fel kan bli en permanent systemforbattring:

Daliga toolargument leder till striktare scheman och validering.
Borttappade beslut leder till battre kontext- och minnesdesign.
Riskabla andringar leder till permission gates.
For tidiga slutmarkeringar leder till mer verifiering.
Dyra upprepade anrop leder till battre cache eller routning.
Svagare beteende vid lang kontext leder till compaction och retrieval.

Promptforbattringar hjalper, men de ar inte tillrackliga. Hallbart beteende kommer fran runtime-design.

Prompt engineering, context engineering och harness engineering

De har begreppen hanger ihop, men de ar inte samma sak. Prompt engineering ar instruktionslagret. Det talar om for modellen vilken roll den ska folja, vilka begransningar som ar viktiga och hur den ska svara. Context engineering ar informationslagret. Det avgor vad modellen ser, nar den ser det och hur mycket som hor hemma i det aktuella fonstret. Harness engineering ar hela exekveringslagret. Det inkluderar prompts och kontext, men ocksa verktyg, tillstand, sakerhet, minne, verifiering, koer, observability och lifecycle management. Den skillnaden ar viktig eftersom prompts ber om ett beteende, medan harness-lagret tvingar fram det. En prompt kan saga: "Radera inte filer utan tillatelse." Ett harness kan blockera destruktiva kommandon tills anvandaren godkanner dem. En prompt kan saga: "Kontrollera ditt arbete." Ett harness kan kora testsviten, inspektera utdata och stoppa avslut om verifieringen misslyckas.

Hur en agent harness fungerar

De flesta agent harnesses foljer en loop. Forst satter harness-lagret samman modellens input. Det kan inkludera systemprompt, utvecklarinstruktioner, anvandarens begaran, tooldefinitioner, minne, aktuell uppgiftsstatus och vald kontext fran filer eller databaser. Sedan svarar modellen. Den kan returnera text, strukturerad data, tool calls eller en begaran om att delegera arbete till en annan agent. Darefter klassificerar harness-lagret utdata. Om modellen gav ett slutligt svar kan loopen stanna. Om den begarde ett verktyg validerar harness-lagret anropet. Validering ar kritisk. Harness-lagret kontrollerar om argumenten matchar schemat, om verktyget ar tillgangligt, om atgarden ar saker och om anvandaren eller systemet har gett nodvandig behorighet. Sedan kor verktyget. Det kan lasa filer, fraga en databas, soka igenom dokument, anropa ett API, exekvera kod, oppna en webblasare eller skriva en patch. Resultatet kommer tillbaka till modellen som en observation. Om verktyget misslyckas maste felet paketeras tillrackligt tydligt for att modellen ska kunna aterhamta sig. Loopen fortsatter tills agenten nar en verifierad stoppunkt, traffar en budgetgrans, behover mansklig input eller avbryts. Det later enkelt. Produktionskvalitet finns i detaljerna runt loopen.

Centrala delar i ett produktionsharness

1. Orkestreringsloop

Orkestreringsloopen styr agentens turer. Vanliga monster:

ReAct: resonera, agera, observera, upprepa
plan and execute: skapa plan och genomfor den
generate, test, repair: skapa resultat, verifiera det, laga fel
gather, act, verify: samla kontext, agera, kontrollera resultat

SjAlva loopen kan vara tekniskt liten. Det svara ar att avgora vilken kontext som ska in i varje tur, vilka handlingar som ar tillatna, vad fel betyder och nar uppgiften faktiskt ar klar.

2. Verktygslagret

Verktygen ar hur agenten ror vid varlden. Bra verktyg designas for modeller, inte bara for manniskor. En manniska kan tolka brusig CLI-utdata, dolda standardvarden, tvetydiga flaggor och partiella fel. En agent behover tydligare gransser. Verktygslagret ska hantera:

namn och beskrivningar
argumentscheman
behorighetskontroller
sandboxing
exekvering
formatering av utdata
retries
auditloggar

Designen av verktygen avgor ofta agentens kvalitet. For manga verktyg forvirrar modellen. Otydliga parametrar ger opalitliga anrop. Breda behorigheter skapar risk. Starka harnesses exponerar minsta mojliga verktygsuppsattning for det aktuella steget.

3. Kontexthantering

Kontext ar inte lagring. Det ar en knapp arbetsyta. Stora kontextfonster hjalper, men de tar inte bort behovet av urval. Nar irrelevanta loggar, gamla utdata, foraldrade planer och upprepat innehall fyller fonstret blir modellen mindre tillforlitlig. Produktionsharnesses anvander strategier som:

ladda sma index forst
hamta exakta filer eller poster on demand
sammanfatta tidigare samtalsturer
maskera gamla toolutdata
behalla beslut och oppna problem men ta bort brus
delegera utforskning till subagenter som returnerar kompakta sammanfattningar

Målet ar inte maximal kontext. Målet ar minsta mojliga high-signal-kontext som hjalper modellen att gora nasta steg ratt.

4. Minne

Minne later en agent bara med sig anvandbar information mellan turer och sessioner. Korttidsminne tacker den aktiva uppgiften. Langtidsminne lagrar varaktiga fakta, preferenser, projektregler och aterkommande beslut. Arbetsminne kan besta av progressfiler, todo-listor eller strukturerade scratchpads. Minne ska inte behandlas som sanning. Det ska behandlas som en ledtrad. Om minnet sager att ett projekt anvander ett visst ramverk bor agenten anda inspektera projektet innan ramverksspecifika andringar goras. Det forhindrar att gammalt minne blir hallucinerad sakerhet. Minne behover ocksa isolering och granskning, eftersom daliga eller illvilliga lagrade fakta kan paverka framtida korningar. Ett produktionssystem ska undvika att minne lagcker mellan anvandare, team, tenants eller behorighetsgranser.

5. Tillstandspersistens

Produktionsuppgifter overlever ofta fler an ett enda modellsvar. Harness-lagret bor folja:

sessions-ID
run-ID
aktuell status
vantande tool calls
berorda filer
child agents
beviljade godkannanden
kostnad och tokenanvandning
slutresultat
leveransstatus

Tillstand gor det mojligt att ateruppta en uppgift efter avbrott. Det ger ocksa auditerbarhet: vad som hande, nar, varfor och genom vilket verktyg.

6. Felhantering

Fel ar normala i agentiska arbetsfloden. Ett starkt harness skiljer pa feltyper:

temporara fel ska provas igen med backoff
argumentfel ska ge tydlig feedback till modellen
behorighetsfel ska be om godkannande eller valja en saker vag
ovantade fel ska stoppa med anvandbar diagnostik

Detta ar viktigt eftersom uppgifter i flera steg bygger upp fel over tid. Aven en hog framgangsgrad per steg kan bli svag over en lang sekvens. Aterhamtningslogik ar inte valfri.

7. Guardrails och behorigheter

Modellen kan bestamma vad den vill gora. Harness-lagret maste bestamma vad den far gora. Anvandbara behorighetsgranser inkluderar:

read-only kontra write access
workspace-scope
godkannande for destruktiva kommandon
godkannande for databasmutationer
granser for externa API:er
begransningar for credential-atkomst
mansklig granskning fore en anvandarvAnd handling

Detta lager maste genomdrivas i kod, inte bara beskrivas i en prompt. For hogriskatgarder ska godkannandet ske innan verktyget kors, inte efterat.

8. Verifieringsloopar

Verifiering ar platsen dar agenter blir tillforlitliga. For mjukvaruuppgifter kan verifiering inkludera tester, type checks, linters, builds, screenshots, browser checks och diffgranskning. For verksamhetsfloden kan verifiering inkludera schemavalidering, databasconstraints, mansklig granskning, confidence thresholds, dokumentcitat och trace-inspektion. En del verifiering ar deterministisk. En annan del anvander en modell som domare. Deterministiska kontroller bor foredras nar objektiv ground truth finns.

9. Observability

Team maste kunna se hur agenter beter sig. Ett produktionsharness bor traca:

prompts och modellutdata
tool calls
toolresultat
fel
retries
approvals
tokenanvandning
latens
verifieringsresultat
slutresultat

Utan observability kan team inte forbattra systemet. De kan bara gissa varfor det misslyckades.

Subagenter och multi-agent lifecycle management

Nar en agent kan skapa andra agenter forandras problemet. Subagenter ar anvandbara nar arbete kan delas upp. En agent kan granska dokumentation medan en annan granskar kod. En kan testa UI medan en annan patchar backendlogik. En kan undersoka kallor medan en annan skriver utkastet. Men att skapa subagenter ar inte samma sak som att hantera dem. Multi-agent lifecycle management borjar nar runtime-lagret maste aga manga koRande agenter over tid. Ett seriost multi-agentsystem behover:

varaktiga child-agent-ID:n
parent-child-lineage
run-ID:n
roller och djupgranser
koer
cancellation
steering
completion events
cleanup policy
recovery efter omstart

Karnfragan blir da: var lever child-agenten, vem ager den, hur rapporterar den tillbaka och vad hander om parent-agenten redan har gatt vidare. Enkel delegering returnerar en sammanfattning till parent-agenten. Multi-agent lifecycle management behandlar completion som ett routingproblem. En child kan bli klar medan parent-agenten ar aktiv, idle, omstartad eller borta. Runtime-lagret maste leverera resultatet till ratt plats med intakt provenans. Darfor borjar avancerade agentsystem likna processhanterare. De behover identitet, lifecycle, koer, recovery och cleanup.

Managed agents kontra anpassade harnesses

Plattformar for managed agents blir vanligare. De paketerar harness-lagret och produktionsinfrastrukturen sa att team kan komma igang snabbare. Det kan vara vardefullt nar ett team vill ha:

snabbare lansering
hostad runtime
inbyggd skalning
hanterad tool-exekvering
standardiserad observability
mindre infrastrukturansvar

Men managed agents ar ocksa ett arkitekturbeslut. Team kan fortfarande behova ett anpassat harness nar:

workflow-kvalitet ar central produktnytta
domanverktyg ar mycket specifika
behorigheter och audit trails ar strikta
kostnad per uppgift spelar roll
langlivade agenter behover egna lifecycle-regler
vendor lock-in ar en risk
standardagentens beteende presterar svagt i interna evals

For manga team ar den praktiska vagen varken "bygga allt sjalva" eller "bara anvanda managed runtime". Den ar stegvis. Borja med befintliga verktyg. Bygg evals. Hitta felmonster. Anpassa harness-lagret dar upprepade fel eller ekonomi motiverar det.

Nar ditt team bor bry sig

Du bor ta harness-design pa allvar nar ett AI-workflow gar bortom prototypstadiet. Tydliga signaler:

anvandare ar beroende av resultatet
fel skapar operativ kostnad
workflowet ror privata eller reglerade data
agenten behover verktyg med side effects
uppgiften innehaller manga steg
resultatet behover verifiering
mansklig granskning behover audit trails
tokenkostnader blir synliga
agentens beteende varierar oforutsagbart mellan korningar

Da ar modellen bara en del av systemet. Tillforlitlighet kommer fran harness-lagret.

Hur vi arbetar med detta pa Lunover

Pa Lunover behandlar vi AI-agenter som produktionssystem i mjukvara, inte som prompt-experiment. Det betyder att vi borjar med workflow-varde. Vi kartlagger den verkliga processen, datakallor, risker, anvandare och framgangskriterier innan vi bygger. Sedan valjer vi ratt niva av harness-komplexitet for arbetet. For en enkel intern assistant kan det betyda retrieval, tool use och grundlaggande overvakning. For ett kundnara workflow kan det krava striktare behorigheter, evals, fallbacks, trace review och manskligt godkannande. For langvarig automation kan det krava durable state, job queues, recovery och tydligt agarskap for varje handling agenten gor. Målet ar inte att fa agenten att se imponerande ut i en demo. Målet ar att gora systemet anvandbart efter lansering. Om ditt team bygger AI-agenter, copilots, RAG-system eller workflowautomation kan Lunover hjalpa till via AI-utveckling, Webbappsutveckling och Affarssystem, med fokus pa produktionslagret runt er modell: verktyg, minne, behorigheter, verifiering, observability och deployment.