I dag leste jeg en lang artikkel om Harness Engineering — titusenvis av ord, nesten helt sikkert AI-skrevet. Min første reaksjon var ikke «wow, for et kraftfullt konsept.» Det var «har disse menneskene noen ideer utover å lage nye begreper for gamle?» Jeg har alltid blitt irritert over dette mønsteret i AI-verdenen — den konstante fornyelsen av eksisterende konsepter. Fra prompt engineering til kontekstteknikk, nå til harness engineering. Hver tredje måned finner noen på et nytt begrep, skriver et essay på 10 000 ord, drysser inn noen casestudier fra store selskaper, og hele fellesskapet begynner å summe. Men hvis du faktisk ser på innholdet, er det det samme hver gang: Design miljøet modellen din kjører i — hvilken informasjon den mottar, hvilke verktøy den kan bruke, hvordan feil blir fanget opp, hvordan minnet håndteres på tvers av økter. Dette har eksistert siden dagen ChatGPT ble lansert. Det blir ikke en ny disiplin bare fordi noen — av en eller annen grunn — bestemte seg for å gi den et nytt navn. Når det er sagt, klager til side, har forskningen og casestudiene som er nevnt i artikkelen verdi — spesielt siden de overlapper mye med det jeg har bygget med how-to-sglang. Så la meg bruke dette som en anledning til å snakke om feilene jeg faktisk har gjort. Litt bakgrunn først. De vanligste forespørslene i SGLang-fellesskapet er Hvordan-du-spørsmål — hvordan man distribuerer DeepSeek-V3 på 8 GPU-er, hva man skal gjøre når gatewayen ikke når arbeidsadressen, og om gapet mellom GLM-5 INT4 og offisiell FP8 er betydelig. Disse spørsmålene spenner over et ekstremt bredt teknisk område, og etter hvert som fellesskapet vokser raskere og raskere, klarer vi i økende grad ikke å holde tritt med svarene. Så jeg begynte å bygge et multi-agent-system for å svare dem automatisk. Den første ideen var selvfølgelig den mest naive — å bygge en enkelt allvitende agent, putte alle SGLangs dokumentasjoner, kode og kokebøker inn i den, og la den svare på alt. Det fungerte ikke. Du trenger ikke å bruke ingeniørteori for å forklare hvorfor — kontekstvinduet er ikke RAM. Jo mer du putter inn i det, desto mer sprer modellens oppmerksomhet seg og desto dårligere blir svarene. En agent som prøver å forstå kvantisering, PD-disaggregasjon, diffusionsservering og maskinvarekompatibilitet samtidig, ender opp med å forstå ingen av dem dypt. Designet vi til slutt landet på er en flerlags underdomene-ekspertarkitektur. SGLangs dokumentasjon har allerede naturlige funksjonelle grenser — avanserte funksjoner, plattformer, støttede modeller — med kokebøker organisert etter modell. Vi gjorde hvert deldomene om til en uavhengig ekspertagent, med en ekspertdebattleder ansvarlig for å motta spørsmål, dele dem opp i delspørsmål, konsultere Expert Routing Table for å aktivere riktige agenter, løse parallell, og deretter syntetisere svarene. Når jeg ser tilbake, samsvarer dette designet nesten perfekt med mønstrene harness-ingeniørmiljøet går inn for. Men da jeg bygde det, hadde jeg ingen anelse om at disse mønstrene hadde navn. Og det trengte jeg ikke. 1. Progressiv opplysning — vi dumpet ikke all dokumentasjon i én enkelt agent. Hver domeneekspert laster kun inn sin egen domenekunnskap, og lederen bestemmer hvem som skal aktiveres basert på spørsmålstypen. Min magefølelse sier at dette designet ga langt mer forbedring enn det å bytte inn en sterkere modell noen gang gjorde. Du trenger ikke å vite at dette kalles «progressiv avsløring» for å ta denne avgjørelsen. Du trenger bare å ha prøvd «stuff alt inn»-tilnærmingen én gang og sett det feile. 2. Repository som sannhetskilde — hele arbeidsflyten ligger i how-to-sglang-repoet. Alle ekspertagenter henter sin kunnskap fra markdown-filer i repoet, uten avhengighet av eksterne dokumenter eller muntlige avtaler. Tidlig fikk vi lyst til å skrive en stor sglang-maintain.md som dekket alt. Vi lærte raskt at det ikke fungerer. OpenAIs Codex-team gjorde samme feil — de prøvde en enkelt overdimensjonert AGENTS.md og så den råtne på forutsigbare måter. Du trenger ikke å ha lest bloggen deres for å tråkke på denne landminen selv. Det er det klassiske programvareutviklingsproblemet med «monolittiske dokumenter blir alltid utdaterte», bortsett fra at i en agentkontekst er konsekvensene verre — utdatert dokumentasjon blir ikke bare ulest, den villeder aktivt agenten. 3. Strukturert ruting — Ekspertrutingstabellen kartlegger eksplisitt spørsmålstyper til agenter. Et spørsmål om GLM-5 INT4 aktiverer både Cookbook Domain Expert og Quantization Domain Expert samtidig. Lederen gjetter ikke; Den følger en strukturert indeks. Harness-ingeniørmiljøet kaller dette «mekaniserte begrensninger». Jeg kaller det vanlig ingeniørfag. Jeg sier ikke at ideene bak harness engineering er dårlige. Den siterte forskningen er solid, ACI-konseptet fra SWE-agent er virkelig verdt å kjenne til, og Anthropics dual-agent-arkitektur (initializer-agent + kodeagent) er verdifullt referansemateriale for alle som jobber med langsiktige oppgaver. Det jeg synes er slitsomt, er den stadige nyskapelsen av nye begreper — å pakke etablert ingeniørfornuft som en ny disiplin, og deretter produsere angst rundt «du ligger bak hvis du ikke kjenner dette ordet.» Prompt engineering, kontekst engineering, harness engineering — de er forskjellige sider av det samme. Neste måned vil noen sannsynligvis kalle stillasteknikk eller orkestreringsteknikk, skrive et nytt langt essay med samme SWE-agent-artikkel, og fellesskapet vil starte en ny syklus med forsterkning. Det jeg faktisk lærte fra how-to-sglang kan sies uten noe nytt vokabular:...