Idag läste jag en lång artikel om Harness Engineering — tiotusentals ord, nästan säkert AI-skrivna. Min första reaktion var inte "wow, vilket kraftfullt koncept." Det var "har dessa människor några idéer utöver att hitta nya termer för gamla?" Jag har alltid irriterats på detta mönster i AI-världen – den ständiga förnyelsen av befintliga koncept. Från prompt engineering till kontextingenjörskonst, nu till harness engineering. Var tredje månad myntar någon ett nytt begrepp, skriver en uppsats på 10 000 ord, strör in några stora företagsfallstudier, och hela gemenskapen börjar surra. Men om du faktiskt tittar på innehållet är det samma sak varje gång: Designa miljön som din modell körs i – vilken information den tar emot, vilka verktyg den kan använda, hur fel fångas upp, hur minnet hanteras över sessioner. Detta har funnits sedan dagen ChatGPT lanserades. Det blir inte en ny disciplin bara för att någon – av någon anledning – bestämde sig för att ge den ett nytt namn. Med det sagt, klagomål åt sidan, har forskningen och fallstudierna som nämns i artikeln värde – särskilt eftersom de överlappar mycket med det jag byggt med how-to-sglang. Så låt mig använda detta som ett tillfälle att prata om de misstag jag faktiskt har gjort. Lite bakgrund först. De vanligaste förfrågningarna i SGLang-communityt är How-to Questions — hur man distribuerar DeepSeek-V3 på 8 GPU:er, vad man ska göra när gatewayen inte når arbetsadressen, och om gapet mellan GLM-5 INT4 och officiell FP8 är betydande. Dessa frågor spänner över en extremt bred teknisk yta, och i takt med att communityn växer snabbare och snabbare kan vi alltmer inte hänga med i svaren. Så jag började bygga ett multiagentsystem för att automatiskt svara på dem. Den första idén var förstås den mest naiva – bygg en enda allvetande agent, stoppa in all SGLangs dokumentation, kod och kokböcker i den, och låt den svara på allt. Det fungerade inte. Du behöver inte använda harness engineering-teori för att förklara varför – kontextfönstret är inte RAM. Ju mer du stoppar i den, desto mer sprids modellens uppmärksamhet och desto sämre blir svaren. En agent som försöker förstå kvantisering, PD-disaggregation, diffusionsserving och hårdvarukompatibilitet samtidigt förstår ingen av dem på djupet. Designen vi slutligen kom fram till är en flerskiktad subdomän-expertarkitektur. SGLangs dokumentation har redan naturliga funktionella gränser — avancerade funktioner, plattformar, stödda modeller — med kokböcker organiserade efter modell. Vi gjorde om varje deldomän till en oberoende expertagent, med en expertdebattchef ansvarig för att ta emot frågor, dela upp dem i delfrågor, konsultera Expert Routing Table för att aktivera rätt agenter, lösa parallellt och sedan syntetisera svar. I efterhand stämmer denna design nästan perfekt överens med de mönster som harness-ingenjörsgemenskapen förespråkar. Men när jag byggde den hade jag ingen aning om att dessa mönster hade namn. Och jag behövde inte det. 1. Progressiv disclosure — vi dumpade inte all dokumentation i någon enskild agent. Varje domänexpert laddar endast sin egen domänkunskap, och chefen bestämmer vem som aktiveras baserat på frågetypen. Min magkänsla säger att denna design gav mycket mer förbättring än att byta in en starkare modell någonsin gjorde. Du behöver inte veta att detta kallas "progressiv upplysning" för att fatta detta beslut. Du behöver bara ha försökt "stoppa in allt"-metoden en gång och sett det misslyckas. 2. Repository som sanningskälla — hela arbetsflödet finns i how-to-sglang-repot. Alla expertagenter hämtar sin kunskap från markdown-filer i repoet, utan beroende av externa dokument eller muntliga avtal. Tidigt fick vi lusten att skriva en stor sglang-maintain.md täcka allt. Vi lärde oss snabbt att det inte fungerar. OpenAI:s Codex-team gjorde samma misstag — de försökte en enda överdimensionerad AGENTS.md och såg den ruttna på förutsägbara sätt. Du behöver inte ha läst deras blogg för att själv trampa på denna landmina. Det är det klassiska mjukvaruutvecklingsproblemet med "monolitiska dokument blir alltid inaktuella", förutom att konsekvenserna i ett agentsammanhang är värre — föråldrad dokumentation går inte bara oläst, den vilseleder aktivt agenten. 3. Strukturerad routing — Expert Routing Table kartlägger uttryckligen frågetyper till agenter. En fråga om GLM-5 INT4 aktiverar både Cookbook Domain Expert och Quantization Domain Expert samtidigt. Chefen gissar inte; Den följer ett strukturerat index. Harness-ingenjörsgruppen kallar detta för "mekaniserade begränsningar." Jag kallar det vanlig ingenjörskonst. Jag säger inte att idéerna bakom harness engineering är dåliga. Den citerade forskningen är stabil, ACI-konceptet från SWE-agent är verkligen värt att känna till, och Anthropics dual-agent-arkitektur (initialisatoragent + kodagent) är värdefullt referensmaterial för alla som arbetar med långsiktiga uppgifter. Det jag tycker är tröttsamt är den ständiga myntningen av nya termer – att paketera etablerad ingenjörsmässig sunt förnuft som en ny disciplin, och sedan skapa ångest kring "du ligger efter om du inte känner till det här ordet." Prompt engineering, context engineering, harness engineering – det är olika aspekter av samma sak. Nästa månad kommer någon förmodligen att mynta ställningsingenjörskonst eller orkestreringsteknik, skriva en lång uppsats till samma mjukvaruagent-artikel, och gemenskapen kommer att starta en ny förstärkningscykel. Det jag faktiskt lärde mig från how-to-sglang kan sägas utan något nytt ordförråd:...