Harness-utvikling: hva det er og hvordan det fungerer

Hva harness engineering betyr

Harness engineering er arbeidet med å bygge harnessen til et KI-verktøy, altså alle deler av verktøyet bortsett fra selve KI-modellen.

Modellen er KI-systemet, som er trent på store mengder tekst slik at det kan lese og skrive språk. Eksempler på KI-modeller er GPT fra OpenAI, Claude fra Anthropic og Gemini fra Google.

På egen hånd kan en modell bare ta imot tekst (og noen ganger bilder eller lyd) og skrive tekst tilbake. Den kan ikke huske tidligere samtaler, slå opp oppdatert informasjon eller kjøre kode. Derfor trenger den en harness som styrer hvilken informasjon modellen får, hvilke apper den kan bruke, hva den har lov til å gjøre, og hvordan arbeidet den gjør, blir kontrollert.

Selv en enkel chatassistent trenger en harness. Modellen glemmer hver utveksling så snart den har svart, så harnessen fører en logg over samtalen. Hvis noen spør om Paris og så følger opp med «hvor mange bor det der?», sender harnessen begge spørsmålene til modellen samlet. Det er slik modellen vet at «der» viser til Paris.

Harness engineering er en av grunnene til at to verktøy bygget på samme modell kan prestere så ulikt. I en uavhengig test holdt forskerne for eksempel modellen (GPT5) uendret og endret bare harnessen, og modellens poengsum på en kodetest varierte med opptil 11 %.

Utviklere av KI-modeller, som Anthropic og OpenAI, bygger harnesser for sine egne KI-produkter, som Claude Code og Codex. Og selskaper som bygger KI-produkter, utformer harnesser for de underliggende modellene de velger. Også folk som bruker KI-verktøy, former en del av harnessen. Mange verktøy lar dem legge til faste instruksjoner, koble til apper og velge hvilke handlinger som krever godkjenning fra dem før verktøyet går videre.

Harness engineering for KI-agenter

Alle KI-verktøy har en harness, men harness engineering blir spesielt viktig når man jobber med KI-agenter. Agenter håndterer oppgaver i flere trinn på egen hånd, som å undersøke konkurrenter og legge funnene inn i et regneark, og harnessen kjører hvert eneste trinn. Hvis harnessen gjør en feil, for eksempel henter fjorårets priser, påvirker det derfor også resten av trinnene.

De fleste agent-harnesser har seks hoveddeler:

1. Agentløkken

Forstørr

Agentløkken er kode i harnessen som holder en oppgave i gang, ett trinn om gangen.

KI-modellen bestemmer seg for neste trinn som trengs for å fullføre oppgaven, og skriver et verktøykall: en kort forespørsel som navngir et verktøy i harnessen, for eksempel nettsøk, og hva verktøyet skal gjøre.

Harnessen oppdager forespørselen, kjører søket og legger resultatene til i det modellen kan se. Modellen leser dem og bestemmer hva den skal gjøre videre.

2. Konteksthåndtering

En modell lærer generell kunnskap under treningen, men kunnskapen strekker seg bare frem til datoen treningen ble avsluttet. Den omfatter ikke noe som er spesifikt for oppgaven den står overfor, som et selskaps filer, dagens nyheter eller hva som ble sagt tidligere i samtalen.

For alt dette er modellen avhengig av kontekstvinduet sitt: teksten harnessen gir den før hvert svar, for eksempel instruksjonene, spørsmålet, samtalen så langt og søkeresultater.

Vinduet rommer bare en fast mengde tekst. Og selv før vinduet blir fullt, overser modeller noen ganger informasjon som ligger begravd midt i lange inndata.

Derfor står harnessen for konteksthåndteringen og velger bare ut informasjonen hvert trinn trenger. Hvis oppgaven for eksempel er å sammenligne prisene til fem konkurrenter, kan harnessen ta med prissiden til hvert selskap i stedet for hele nettstedet. På lange oppgaver kan harnessen også erstatte den detaljerte loggen over tidligere trinn med et kort sammendrag, slik at modellen holder oversikt over hva den har gjort, uten at historikken fyller opp vinduet.

3. Verktøy

Verktøy er kode som utfører handlingene modellen ber om. Hvert verktøy håndterer én type handling, for eksempel å søke på nettet, åpne og lese en nettside, kjøre kode eller redigere en fil. Når modellen skriver et verktøykall, sender harnessen det videre til riktig verktøy og returnerer resultatet.

Mange harnesser har også koblinger, som er verktøy som knytter agenten til en bestemt app, for eksempel e-post, en kalender eller en delt disk, ved hjelp av tilgang en person har gitt. Med en kalenderkobling kan en agent for eksempel sjekke om noen er ledige, før den foreslår et møtetidspunkt.

4. Minne

Minne er lagret informasjon som følger med fra én økt til den neste. Harnessen lagrer korte notater i løpet av en økt, for eksempel en persons preferanser eller hvor langt et prosjekt har kommet. Ved starten av neste økt legger harnessen disse notatene inn i kontekstvinduet, slik at modellen leser dem før den leser det nye spørsmålet. Det er for eksempel slik en agent kan fortsette med en ukentlig rapport der den slapp, i stedet for å begynne helt fra starten igjen.

5. Tillatelser

Tillatelser er regler for hva en agent kan få tilgang til og gjøre. Tilgangsregler bestemmer hvilke filer, apper eller nettsteder den kan åpne. Godkjenningsregler bestemmer hvilke handlinger som må vente på at en person godkjenner dem, for eksempel å sende en melding eller gjennomføre et kjøp.

Selskapet som lager agenten, setter opp noen av disse reglene i koden til harnessen. Deretter kan administratorer i en organisasjon legge til egne regler, og enkeltbrukere kan velge ting som hvilke kontoer som skal kobles til.

6. Verifisering

Verifisering er kode som kontrollerer agentens arbeid før det når frem til en person. Den bruker to typer kontroller:

• Faste regler, som er spesifikke tester som består eller feiler på samme måte hver gang, for eksempel å bekrefte at hvert tall i en rapport finnes i et dokument agenten faktisk har lest.
• En gjennomgang av en annen KI-modell, som leser arbeidet og vurderer det. Den kan fange opp problemer som er vanskelige å gjøre om til en regel, for eksempel et sammendrag som utelater et viktig poeng.

Ingen enkeltkontroll fanger opp alt, så harnesser kombinerer vanligvis begge typene. Når en kontroll finner et problem, legger harnessen til en beskrivelse av det i modellens kontekstvindu og sender oppgaven tilbake gjennom agentløkken. Modellen retter problemet og prøver igjen, slik at mange feil blir rettet før brukeren ser resultatet.

Eksempler på harness engineering

Forberede et kundemøte

Oppgave: En kundeansvarlig ber en agent om å forberede en briefing til morgendagens møte med en kunde, med åpne saker og et utkast til agenda.

Hva harnessen gjør:

• Gjennom en e-postkobling søker agenten i innboksen til den kundeansvarlige etter meldinger til og fra kunden.
• Tillatelsene lar den lese e-post, men ikke sende e-post.
• Konteksthåndteringen gir modellen bare de siste tre månedenes meldinger til og fra denne kunden, ikke hele innboksen.
• Agentløkken kjører flere runder med søk og lesing, og modellen grupperer funnene i åpne saker.
• Verifiseringen kontrollerer deretter at hver sak i briefingen kan knyttes til en faktisk e-post.

Mulig resultat: Den kundeansvarlige får en briefing på én side der hvert punkt kan spores tilbake til e-posten det kommer fra.

Oppdatere en månedlig salgsrapport

Oppgave: En driftsleder ber en agent om å oppdatere den månedlige salgsrapporten med denne månedens tall.

Hva harnessen gjør:

• Minnet laster inn notater fra forrige måneds økt, blant annet rapportens format og driftslederens ønske om å runde av tallene til nærmeste tusen.
• Et filverktøy åpner salgsregnearket på teamets delte disk.
• Tillatelsene lar agenten redigere rapportutkastet, men ikke kilderegnearket, slik at de opprinnelige tallene ikke kan endres ved en feil.
• Verifiseringen kontrollerer at summene i rapporten stemmer med regnearket.

Mulig resultat: Rapporten kommer i samme format som forrige måned, uten at brukeren må forklare det på nytt.

Sortere en delt innboks

Oppgave: Et supportteam ber en agent om å sortere morgenens innkomne henvendelser etter tema og skrive utkast til svar på de vanligste.

Hva harnessen gjør:

• Agentløkken går gjennom innboksen én melding om gangen.
• For hver melding velger modellen en temaetikett, og harnessen legger den til via e-postkoblingen.
• Ved starten av oppgaven legger harnessen teamets godkjente svarmaler inn i kontekstvinduet som veiledning, slik at modellen baserer hvert utkast på en mal.
• En godkjenningsregel holder hvert svar tilbake som utkast til noen i teamet har gått gjennom og sendt det.

Mulig resultat: Teamet starter dagen med sorterte henvendelser og svar som venter på gjennomgang.

Rette en feil på et nettsted

Oppgave: En utvikler ber en kodeagent om å rette en feil som gjør at en betalingsknapp ikke fungerer.

Hva harnessen gjør:

• Agenten jobber i en sandbox, en isolert kopi av koden der endringene ikke kan påvirke det publiserte nettstedet.
• Et kodeverktøy lar modellen lese og redigere filer.
• Etter hver endring kjører verifiseringen prosjektets automatiserte tester.
• Eventuelle feil sendes tilbake til modellen som ny informasjon.

Mulig resultat: Agenten fortsetter å justere rettelsen til testene består. Deretter går utvikleren gjennom endringen før den publiseres.

Harness engineering vs. prompt engineering vs. context engineering

Prompt engineering er arbeidet med å bygge og optimalisere ett enkelt spørsmål. Context engineering er arbeidet med å styre alt modellen ser. Harness engineering er prosessen med å utforme og forbedre hele systemet modellen arbeider innenfor.

Hvordan brukere kan påvirke en KI-harness

Det meste av en agent-harness kommer fra selskapet som lager agenten, men mange KI-produkter lar brukerne justere deler av den gjennom innstillinger som egendefinerte instruksjoner, tilkoblede apper og godkjenninger.

Brukere kan forme en agent-harness, og forbedre agentens resultater, på fire måter:

1. Faste instruksjoner

Faste instruksjoner er notater en person skriver én gang, slik at harnessen kan legge dem inn i kontekstvinduet ved starten av hver oppgave. De er verdt å sette opp for alt en person ellers ville gjentatt i spørsmål etter spørsmål: hvem de er og hva de gjør, hvordan de vil ha tekster skrevet, eller reglene for en tilbakevendende jobb, som en kundes månedsrapport.

Mange KI-produkter tilbyr faste instruksjoner på to nivåer. Instruksjoner for hele kontoen passer for ting som gjelder alt arbeid, som rettskrivingspreferanser. Prosjektinstruksjoner passer for én enkelt kunde eller arbeidsflyt, slik at veiledning for den ene ikke smitter over på en annen.

Faste instruksjoner fungerer på samme måte i chatassistenter og agenter, men agenter er mer avhengige av dem. I en chat kan en person korrigere KI-en etter hvert svar. En agent kan ta mange trinn før noen ser arbeidet, så instruksjoner som gis på forhånd, er en av få måter å styre den underveis på.

Slik skriver du effektive faste instruksjoner

• Start med en kort instruksjon, for eksempel: «Jeg er markedssjef i et programvareselskap. Skriv på enkel og klar engelsk, hold sammendrag under 200 ord, og bruk amerikansk rettskriving.»
• Utvid dem når KI-en gjør en feil. Hvis KI-en stadig runder av tall som teamet trenger nøyaktige, legger du til en linje om det.
• Gjør instruksjonene konkrete: «Oppgi nøyaktige tall, aldri avrundede» fungerer bedre enn «Vær nøyaktig».
• Hold listen kort, og fjern linjer når de ikke lenger er nyttige, siden hver linje tar opp plass i kontekstvinduet.

2. Tilkoblede apper

Tilkoblede apper knytter et KI-produkt til verktøyene en person allerede bruker, for eksempel e-post, en kalender eller en delt disk. Når en app er koblet til, kan KI-en jobbe med personens egen informasjon i stedet for bare det som limes inn i chatten.

Tilkoblinger er verdt å sette opp når en oppgave avhenger av informasjon som ligger i disse appene, for eksempel å forberede en møtebriefing ut fra e-posttråder eller oppsummere dokumenter på en delt disk.

Slik kobler du til apper på en trygg måte

• Koble bare til appene en oppgave trenger, siden hver tilkobling gir enda en mulighet for feil.
• Velg kun lesetilgang der det tilbys. En agent som forbereder møtebriefinger, trenger for eksempel å lese e-post, ikke sende den.
• Angi tilkoblinger per prosjekt der produktet tillater det. I Perplexity kan man for eksempel velge hvilke koblinger hvert prosjekt bruker.
• Husk å koble fra apper som ikke lenger er i bruk.

3. Godkjenningsinnstillinger

Godkjenningsinnstillinger bestemmer hvilke handlinger som må vente på at en person godkjenner dem, før KI-en går videre. Noen godkjenninger er innebygd i produktet, og enkelte produkter lar brukerne velge hvilke andre handlinger som skal kreve godkjenning.

Slik setter du opp godkjenningsregler

• Krev godkjenning for handlinger som ikke kan angres, for eksempel å sende en melding, foreta et kjøp eller slette en fil.
• Hold listen over godkjenninger kort. Hvis en agent ber om klarsignal for hvert lille steg, begynner folk å godkjenne uten å lese.

4. Standarder og kontroller

De fleste AI-produkter har noen innebygde standarder. Perplexity tar for eksempel med kildehenvisninger i svarene sine, slik at hver påstand kan kontrolleres. Standarder som brukeren selv setter, tilfører det et produkt ikke kan vite på egen hånd, for eksempel hvilket rapportformat et team foretrekker.

Slik setter du standarder for arbeid utført av AI

• Gi en mal for gjentakende arbeid, slik at AI-en har en fast struktur å fylle ut.
• Del et eksempel på tidligere arbeid som teamet likte, slik at AI-en kan treffe samme tone og detaljnivå.
• Be om en kildelenke ved siden av hvert tall.
• Gå nøye gjennom de første resultatene, og gjør mangler som går igjen, om til en ny fast instruksjon.

Perplexitys tilnærming til agent-harnesser

Perplexity Computer kjører på en modelluavhengig harness som samler over 20 avanserte modeller i ett system. Den deler hver oppgave opp i deloppgaver, gir dem videre til underagenter (separate agenter som tar hver sin del), og sender hver arbeidsdel til en modell som egner seg for den.

Se hvordan du setter opp instruksjoner, filer og koblinger i veiledningen til prosjekter i Perplexity.

Vanlige spørsmål

Hva er en harness-ingeniør?

En harness-ingeniør utformer og vedlikeholder systemet som gjør at en AI-modell kan utføre arbeid på en pålitelig måte. Det kan bety å legge til et nytt verktøy som agenten kan bruke, finne ut hvorfor en agent stadig gjør den samme feilen, eller skjerpe kontrollene den kjører før den fullfører en oppgave. Det er ikke en etablert stillingstittel, selv om det kan endre seg. Arbeidet gjøres som regel av programvareutviklere i AI-selskaper eller i team som bygger agenter. Innen industri brukes den engelske tittelen «harness engineer» om noen som konstruerer ledningsnett, altså kabelbuntene inne i biler og maskiner.

Hva er en agent-harness?

En agent-harness betyr vanligvis alt i en AI-agent bortsett fra selve modellen. Det omfatter koden som kjører agentløkken, håndterer kontekst, utfører verktøykall, lagrer minne, håndhever tillatelser og kontrollerer agentens arbeid før det når et menneske.

Har alle AI-verktøy en harness?

Ja. Selv en enkel chatassistent er avhengig av en harness for å holde styr på samtalen, siden modellen ikke husker tidligere meldinger på egen hånd.

Utviklere kan også bruke en modell ved å sende forespørsler til den fra sin egen programvare via et API (en forbindelse som lar ett program sende forespørsler til et annet). I så fall er det utviklerens egen kode som gjør harnessens jobb.

Vil bedre modeller gjøre harnesser overflødige?

Bedre modeller trenger kanskje mindre veiledning steg for steg, så noe av det harnesser gjør i dag, kan bli mindre. Men en modell alene gjør bare tekst om til tekst. Den har ingen internettilkobling og ingen tilgang til andre apper. Å få tilgang til filer, utføre handlinger og håndheve godkjenningsregler skjer i programvaren rundt modellen, så det arbeidet blir trolig liggende hos harnessen, uansett hvor dyktige modellene blir.