Vad är ett agentharness? Så får AI‑agenter verktyg, minne och kontroll

Idén är inte helt ny. Utvecklare har byggt omslag, ställningar och exekveringsmiljöer runt modeller i flera år. Begreppet spreds efter att Mitchell Hashimoto, medgrundare av HashiCorp, använde "harness engineering" i ett blogginlägg i februari 2026 om sitt AI‑arbetsflöde. Poängen var enkel: när en agent gör ett misstag, ändra miljön så att misstaget inte kan hända igen. OpenAI tog upp termen samma vecka för sitt Codex-arbete, och LangChain följde med samma inramning.

I den här artikeln förklarar jag vad ett agentharness är, varför AI‑agenter behöver ett, hur det skiljer sig från ramverk och runtimes, och vilka verktyg utvecklare använder för att bygga system som liknar harness.

Vad är ett agentharness?

En definition kommer från LangChain: "Om du inte är modellen, är du harnesset." I praktiken är ett agentharness programvaran runt en språkmodell: verktyg, minne, tillstånd, exekvering, skyddsräcken och observerbarhet.

Agent = Modell + Harness

Modellen resonerar. Harnesset ger det resonerandet en plats att agera, minnas, kontrollera resultat och följa regler.

Modell inuti sitt fungerande agentharness. Bild av författaren.

Formeln är användbar, men den är en tankemodell, inte en industristandard. Vissa leverantörer använder fortfarande "harness", "ramverk" och "ställning" för att betyda ungefär samma sak.

Varför AI‑agenter behöver ett harness

En rå språkmodell har begränsningar när du ber den arbeta över många steg. Den håller inte ett beständigt tillstånd själv, kör inte verktyg på egen hand, hanterar inte ett växande kontextfönster eller återhämtar sig från misslyckade verktygsanrop utan hjälp. 

Föreställ dig en agent som ombeds laga ett fallerande test i ett Python‑projekt. Utan ett harness kan modellen skriva något som ser ut som en fix, men den kan inte läsa den faktiska testfilen, köra pytest, se det verkliga felet, redigera den felande funktionen eller bekräfta att fixen går igenom. Med ett harness blir hela loopen några minuters arbete som agenten gör själv, med varje steg loggat någonstans där en människa kan granska.

Anthropics vägledning gäller fortfarande: börja med det enklaste möjliga angreppssättet och lägg bara till rörliga delar när uppgiften kräver dem.

Vad ett agentharness består av

Delarna varierar, men de flesta delar ett fåtal byggblock. Tänk på dem som en checklista, inte en strikt produktspec. En liten agent kan bara behöva några av dessa delar, medan en produktionsagent behöver fler.

Systemprompter och beteenderegler

Harnesset styr vanligtvis modellens grundinstruktioner. Det inkluderar systemprompten, men kan också omfatta projektsregler, kodstandarder, rollbegränsningar och säkerhetspolicys. I LangChains Deep Agents kan till exempel en AGENTS.md‑fil sätta spelreglerna innan en uppgift börjar.

Vissa harness under 2026 använder också stegvis exponering av instruktioner. I stället för att ladda varje verktygsbeskrivning i kontexten vid start, lägger harnesset bara till en sammanfattning av vad som finns tillgängligt. Fullständiga instruktioner för ett verktyg laddas bara när modellen behöver just det verktyget.

Verktyg: hur agenter interagerar med världen

Verktyg låter agenten göra saker bortom textgenerering. Vanliga exempel är webbsökning, fil‑läsning och ‑skrivning, databasfrågor, API‑anrop, webbläsaråtgärder, kodexekvering och terminalkommandon. Harnesset styr vilka verktyg som är tillgängliga, när modellen får anropa dem och hur resultat formateras och återförs till agentens kontext.

Model Context Protocol (MCP) har blivit ett standardgränssnitt för detta 2026. Många harness, inklusive Anthropics Agent SDK, LangChain Deep Agents och OpenAI Agents SDK, använder MCP för att koppla externa verktygsservrar utan att skriva anpassad integrationskod för var och en.

Minne och tillstånd

Agenter behöver veta vad som hände tidigare i en uppgift. Ett harness kan hålla kortsiktigt tillstånd i den aktiva konversationen och mer långsiktigt tillstånd i filer, loggar, sammanfattningar eller sparade preferenser. Vissa harness komprimerar också långa historiker till kortare sammanfattningar så att modellen inte bär med sig varje detalj i kontexten.

Exekveringsmiljö: där agenten körs och agerar

Många användbara agenter behöver någonstans att faktiskt arbeta. Det kan vara ett filsystem, en container, en sandlådeförsedd terminal, en webbläsarinstans eller en moln‑runtime. Utan en exekveringsmiljö som hanteras av harnesset har verktygsanrop ingenstans att landa.

Många harness använder nu isolerade sandlåde‑containrar: kortlivade miljöer avgränsade till en enda session, som städas upp när uppgiften är klar, så att filskrivningar, installerade paket och nätverksanrop från en agentuppgift inte spiller över till en annan.

Orkestrering och planering

Vissa uppgifter passar inte i en enda rak stegsekvens. Harnesset kan tillhandahålla ett planeringsverktyg som bryter ned ett mål i deluppgifter och spårar deras status. Det kan också starta underagenter som hanterar en del av arbetet och bara returnerar en sammanfattning till huvudagenten.

LangChain Deep Agents spårar till exempel planeringssteg i en fil på filsystemet och uppdaterar varje steg från väntande till klart under körningen.

Skyddsräcken och behörigheter

Harnesset är där du lägger reglerna: mänskligt godkännande, blockerade verktygsanrop, rollbaserade behörigheter och utdata‑kontroller. OpenAI Agents SDK, LangChain Deep Agents och Microsoft Agent Framework stöder alla den här typen av styrning. Det säkrare mönstret är att kontrollera indata, utdata och verktygsbehörigheter separat.

Observerbarhet och spårning

När en femtio‑stegs agentuppgift misslyckas vid steg trettiosju visar ett spår vad som hände. Spårning registrerar modell‑anrop, verktygsanrop, överlämningar, fel, latens och kostnad över en hel körning. OpenAI Agents SDK slår på spårning som standard. LangSmith lägger till felsöknings‑ och utvärderingspaneler ovanpå. OpenTelemetry har blivit standard för att exportera spår i ett leverantörsneutralt format, så att du inte låses in i ett enda observabilitetsverktyg.

Agentharness vs. ramverk vs. runtime: vad är skillnaden?

Den här frågan dyker ofta upp, och svaret är rörigare än de flesta förklaringar antyder. Taxonomin är användbar, men den är inte fast.

Tre lager, ökad abstraktion nerifrån och upp. Bild av författaren.

Jag börjar med ramverk, eftersom många utvecklare redan har använt ett.

Vad är ett agentramverk?

Ett agentramverk ger utvecklare byggblock för att skapa agenter. Det täcker modell‑anrop, verktygsdefinitioner, minnesmönster och agentloopens struktur. Exempel inkluderar tidiga LangChain, CrewAI och Google ADK. Ett ramverk talar om hur du strukturerar en agent, men inte alltid hur du kör den tillförlitligt i produktion.

Vad är en agent‑runtime?

En agent‑runtime är lagret som hjälper en agent att köra tillförlitligt över tid. Det hanterar beständig exekvering, tillståndsbeständighet, retry‑försök, människa‑i‑loopen‑steg och streaming. LangGraph, Temporal och Inngest är exempel. Harrison Chase erbjöd denna analogi: om Node.js är runtime och Express är ramverket, är ett harness som Next.js.

Vad gör ett harness annorlunda?

Ett harness ligger på en högre nivå än ett ramverk. Där ett ramverk ger dig komponenter, kommer ett harness vanligtvis med fler beslut redan fattade: verktyg, planering, filsystemåtkomst och kontexthantering.

Användningsfall för agentharness: kodning, research, data och företag

Samma byggblock dyker upp i mycket olika jobb, men mixen förändras. En kodningsagent och en företags‑arbetsflödesagent behöver båda ett harness, men de belastar olika delar av det. Dessa kategorier är inga formella standarder. De är praktiska sätt att se hur samma idé böjs efter arbetet framför den.

Harness för kodningsagenter

Kodningsagenter är ett bra aktuellt exempel eftersom harnesset är synligt. För att göra användbart kodarbete behöver en agent filåtkomst, git‑kontext, terminalexekvering, testkörning, beroendeinstallation och projektsregler. Claude Code och Codex är exempel på detta mönster: båda kör på mycket harness‑kod, inte ett naket modell‑API.

Skillnaden mellan ett bra och ett mediokert kodnings‑harness syns oftast i små detaljer: hur det återhämtar sig från ett misslyckat test, om det kan rulla tillbaka en dålig ändring, hur rent det exponerar git‑historik för modellen. Det är i de detaljerna som större delen av ingenjörsarbetet faktiskt hamnar.

Harness för research‑agenter

Research‑agenter behöver en annan verktygslåda: webbsökning, källspårning, anteckningar, referenshantering och sammanfattning. Harnesset hanterar hur sökresultat lagras, hur källor attribueras och hur långa dokument styckas upp och läggs åt sidan för att undvika att konsumera hela kontextfönstret i ett svep.

Harness för dataanalys‑agenter

Dataagenter behöver åtkomst till dataset, SQL‑databaser, Python‑exekveringsmiljöer och schema‑kontext så att de vet vilka tabeller och kolumner som finns innan de börjar skriva frågor. Harnesset upprätthåller också behörighetsgränser, vilket är viktigt när agenten kan röra produktionsdata.

Företags‑arbetsflödens harness

Företagsutrullningar lägger till ytterligare krav: autentisering, granskningsloggar, godkännandeflöden, rollbaserad åtkomstkontroll och kopplingar till interna system. AWS AgentCore är ett hanterat exempel i den här kategorin, med identitet, VPC‑nätverk och observerbarhet inkluderat. Microsoft Agent Framework täcker liknande områden för team i Azure‑ eller .NET‑miljöer.

Verktyg för att bygga agentharness‑system 2026

Ett fåtal produkter dyker upp oftast i mitten av 2026. De befinner sig på olika punkter på spektrumet ramverk‑runtime‑harness, och gränserna rör sig fortfarande.

LangChain Deep Agents

LangChain Deep Agents är LangChains öppna harness, byggt på LangGraph som sin runtime. Det levereras med ett planeringsverktyg, virtuellt filsystem, underagent‑spawning, automatisk kontextkompaktering och mellanlager för människa‑i‑loopen‑godkännande och PII‑detektering. Det är modellagnostiskt, stöder OpenAI‑kompatibla ändpunkter och kopplar till sandlådsleverantörer som Modal, Runloop och Daytona för kodexekvering.

Anthropic Agent SDK

Anthropic Agent SDK (paketnamn: claude-agent-sdk) extraherades från Claude Code och släpptes som ett fristående alternativ. Det inkluderar en inbyggd agentloop, verktyg för bash‑exekvering, fil‑läsning och ‑skrivning, webbsökning, MCP‑integration och kontextkompaktering. Det fungerar endast med Claude‑modeller, via Anthropics API, Amazon Bedrock, Vertex AI och Azure.

OpenAI Agents SDK

Som jag nämnde tidigare har OpenAI Agents SDK gått från ramverk in i harness‑territorium i takt med att funktionsuppsättningen vuxit. April 2026‑släppet lade till inbyggd sandlåds‑exekvering, minneskompaktering och filsystemverktyg. Tillgänglig i Python och TypeScript, stöder SDK:et verktygsanvändning, agent‑överlämningar och skyddsräcken.

Google Agent Development Kit

Google ADK stöder multi‑agent‑orkestrering med inbyggda klasser för sekventiella, parallella och loop‑baserade agentstrukturer. Det inkluderar utvärderingsverktyg, fungerar med Vertex AI för hanterad driftsättning och stöder MCP för verktygsanslutning. Tillgängligt i Python, Java, TypeScript och Go, är det optimerat för Gemini‑modeller men beskrivs som modellagnostiskt.

Microsoft Agent Framework

Microsoft Agent Framework är Microsofts nuvarande migrationsväg för AutoGen‑projekt. Det stöder Python och .NET, fungerar med Azure AI‑tjänster och inkluderar MCP‑stöd för verktygsanslutning.

CrewAI

CrewAI tar ett rollbaserat angreppssätt för multi‑agentsystem. Du definierar agenter med specifika roller, tilldelar uppgifter, sätter upp team och konfigurerar minne och skyddsräcken deklarativt. Det passar problem som naturligt kan mappas till ett team av specialister.

Temporal och Inngest

Dessa är inte agentharness i sig. De är plattformar för beständig exekvering som hanterar vad som händer när en agentuppgift behöver köras i timmar eller dagar utan att tappa tillstånd. Vid fel spelar motorn upp från den senaste lyckade kontrollpunkten i stället för att börja om.

Utmaningar och avvägningar med agentharness

Att lägga till ett harness låter systemet göra mer, men varje tillagt verktyg, behörighet och agent lägger till ännu ett sätt för saker att gå sönder. När uppgifter blir längre slutar skyddsräcken, spårning och beständigt tillstånd att vara valfria och blir det mesta av det som håller en lång körning återhämtningsbar.

Det finns också en kopplingsrisk som överraskar team. LangChain rapporterade ett lyft på 10 till 20 poäng på en tau2‑bench‑delmängd efter att ha lagt till modellspecifika harness‑profiler. Artificial Analysis gjorde en liknande poäng i sitt Coding Agent Index: resultat för kodningsagenter beror på modellen och harnesset tillsammans, med kostnad, tokenanvändning och tid per uppgift som varierar mycket mellan kombinationer. Modellen ändrades inte. De omgivande prompterna, verktygen och mellanlagren gjorde det. Den profilen i sig är harness‑arbete.

Behöver du faktiskt ett agentharness?

Här är ett rakt sätt att tänka igenom om du behöver ett.

Du behöver sannolikt ett harness om ditt system uppfyller ett eller flera av dessa villkor:

• Det behöver använda externa verktyg
• Det behöver komma ihåg framsteg mellan sessioner
• Det behöver köra kod i en riktig miljö
• Det koordinerar mer än en agent
• Det behöver återhämta sig från partiella fel utan att tappa arbete
• Det kräver mänskligt godkännande

Du behöver sannolikt inte ett harness om uppgiften är ett förutsägbart arbetsflöde där varje steg är förutbestämt.

Ett användbart test: om uppgiften kan hanteras av ett enda modell‑anrop, eller av ett litet deterministiskt skript med ett fåtal villkorssatser, är ett harness troligen överdrivet. I samma ögonblick som uppgiften kräver att agenten fattar beslut, använder verktyg och reagerar på resultat över tid börjar harnesset göra verkligt arbete.

Ett mönster jag ofta ser är att team sträcker sig efter ett harness för tidigt och bygger spårning och sandlådor för något som egentligen är en one‑shot textgenereringsuppgift. Det omvända misstaget är det smärtsamma: att skeppa modellen direkt och sedan inse vid det andra misslyckade testet, det tredje verktygsanropet eller den femte omstarten att det inte finns någon infrastruktur att falla tillbaka på.

Avslutande tankar

Som jag nämnde tidigare använder inte alla leverantörer samma ord för samma saker, och gränsen mellan ramverk, runtime och agentharness är fortfarande i rörelse.

För one‑shot‑generering är omslaget överdrivet. För agenter som måste agera, minnas och återhämta sig under långa sessioner blir agentharnesset en stor del av systemet. Att välja rätt är i allt högre grad ett separat beslut från att välja rätt modell. Jag är nyfiken på hur mycket av detta lager nästa generation av modeller absorberar själva, eftersom vissa drag från OpenAI och Anthropic antyder att gränsen kommer att fortsätta skifta. Grundidén står kvar: en agent är en modell plus ett agentharness.

Om du vill lära dig mer om att bygga agentsystem täcker vår kurs Building Scalable Agentic Systems mönstren bakom verktygsanvändning, orkestrering och långkörande agentarbetsflöden.