Tänään luin pitkän artikkelin Harness Engineeringistä — kymmeniä tuhansia sanoja, lähes varmasti tekoälyn kirjoittamia. Ensimmäinen reaktioni ei ollut "vau, mikä voimakas konsepti." Kysymys oli "onko näillä ihmisillä mitään ideoita muuta kuin keksiä uusia termejä vanhoille?" Minua on aina ärsyttänyt tämä kaava tekoälymaailmassa — olemassa olevien käsitteiden jatkuva uudelleenkeksiminen. Nopeasta insinööristä kontekstitekniikkaan, nyt insinööritaitojen hyödyntämiseen. Joka muutama kuukausi joku keksii uuden termin, kirjoittaa 10 000 sanan esseen, lisää mukaan muutaman suuren yrityksen tapaustutkimuksen, ja koko yhteisö alkaa kuhiseda. Mutta jos oikeasti katsoo sisältöä, sama asia on joka kerta: Suunnittele mallisi toimintaympäristö — mitä tietoa se vastaanottaa, mitä työkaluja se voi käyttää, miten virheet siepataan, miten muistia hallitaan istuntojen välillä. Tämä on ollut olemassa siitä päivästä lähtien, kun ChatGPT lanseerattiin. Siitä ei tule uutta oppialaa vain siksi, että joku — mistä tahansa syystä — päätti antaa sille uuden nimen. Siitä huolimatta, valituksista huolimatta, artikkelissa mainituilla tutkimuksilla ja tapaustutkimuksilla on arvoa — erityisesti koska ne menevät vahvasti päällekkäin sen kanssa, mitä olen rakentanut ohjeiden kanssa. Joten haluan käyttää tätä tilaisuutena puhua niistä virheistä, joita olen oikeasti tehnyt. Ensin hieman taustaa. SGLang-yhteisössä yleisimmät kysymykset ovat How-to -kysymykset — miten DeepSeek-V3 otetaan käyttöön 8 GPU:lla, mitä tehdä, kun yhdyskäytävä ei yllä työntekijän osoitteeseen, onko GLM-5 INT4:n ja virallisen FP8:n välinen ero merkittävä. Nämä kysymykset kattavat erittäin laajan teknisen pinnan, ja kun yhteisö kasvaa yhä nopeammin, emme enää pysy vastausten perässä. Aloin siis rakentaa moniagenttijärjestelmää, joka vastaisi niihin automaattisesti. Ensimmäinen idea oli tietenkin kaikkein naiivein — rakentaa yksi kaikkitietävä agentti, tunkea siihen kaikki SGLangin dokumentit, koodit ja keittokirjat ja antaa sen vastata kaikkeen. Se ei toiminut. Et tarvitse hyödyntää insinööriteoriaa selittämään miksi — kontekstiikkuna ei ole RAM-muisti. Mitä enemmän siihen ahdetaan, sitä enemmän mallin huomio hajaantuu ja sitä huonommin vastaukset muuttuvat. Agentti, joka yrittää samanaikaisesti ymmärtää kvantisointia, PD:n disgregaatiota, diffuusiopalvelua ja laitteistoyhteensopivuutta, ei lopulta ymmärrä mitään niistä syvällisesti. Lopulta päädyimme monikerroksiseen ala-asiantuntijaarkkitehtuuriin. SGLangin dokumentaatiossa on jo luonnolliset toiminnalliset rajat — edistyneet ominaisuudet, alustat, tuetut mallit — ja keittokirjat on järjestetty mallin mukaan. Muutimme jokaisen osa-alueen itsenäiseksi asiantuntijaagentiksi, jonka Expert Debating Manager vastaa kysymysten vastaanottamisesta, niiden jakamisesta alakysymyksiin, Expert Routing Tablen konsultoimisesta oikeiden agenttien aktivoimiseksi, rinnakkain ratkaisemisesta ja vastausten synteesistä. Jälkikäteen katsottuna tämä suunnittelu vastaa lähes täydellisesti niitä malleja, joita valjainsinööriyhteisö ajaa. Mutta kun rakensin sitä, minulla ei ollut aavistustakaan, että näillä kuvioilla on nimiä. Enkä tarvinnutkaan. 1. Progressiivinen tiedonantovelvollisuus — emme siirtäneet kaikkea dokumentaatiota yhdellekään välittäjälle. Jokainen toimialan asiantuntija lataa vain oman alatietonsa, ja Manageri päättää, ketkä aktivoidaan kysymystyypin perusteella. Vaistoni on, että tämä suunnittelu tuotti paljon enemmän parannusta kuin vahvemman mallin vaihtaminen koskaan aiemmin. Sinun ei tarvitse tietää, että tätä kutsutaan "progressiiviseksi paljastukseksi" tehdäksesi tämän päätöksen. Sinun täytyy vain kokeilla "pakata kaikki sisään" -menetelmää kerran ja nähdä sen epäonnistuvan. 2. Tietovarasto totuuden lähteenä — koko työnkulku elää ohje-sglang-repossa. Kaikki asiantuntijaagentit ammentavat tietonsa repossa olevista markdown-tiedostoista, ilman riippuvuutta ulkoisista asiakirjoista tai suullisista sopimuksista. Alussa meillä oli halu kirjoittaa yksi valtava sglang-maintain.md joka kattaa kaiken. Opimme nopeasti, ettei se toimi. OpenAI:n Codex-tiimi teki saman virheen — he kokeilivat yhtä ylisuurta AGENTS.md ja näkivät sen mädäntyvän ennustettavilla tavoilla. Sinun ei tarvitse olla lukenut heidän blogiaan astuaksesi tälle miinalle itse. Se on klassinen ohjelmistokehityksen ongelma: "monoliittiset dokumentit menevät aina vanhentuneiksi", paitsi että agentin kontekstissa seuraukset ovat pahempia — vanhentunut dokumentaatio ei vain jää lukematta, vaan se johtaa agenttia harhaan. 3. Rakenteellinen reititys — asiantuntijareititystaulukko määrittää kysymystyypit eksplisiittisesti agenteille. Kysymys GLM-5 INT4:stä aktivoi samanaikaisesti sekä Keittokirjan Domain Expertin että Quantization Domain Expertin. Johtaja ei arvaa; Se noudattaa rakenteellista indeksiä. Valjainsinööriporukka kutsuu tätä "mekanisoiduiksi rajoitteiksi." Kutsun sitä normaaliksi insinööritieteiksi. En sano, että valjastekniikan taustalla olevat ideat olisivat huonoja. Viitattu tutkimus on vankkaa, SWE-agentin ACI-konsepti on aidosti tutustumisen arvoinen, ja Anthropicin kaksoisagenttiarkkitehtuuri (initializer agent + koodausagentti) on arvokasta viitemateriaalia kaikille, jotka tekevät pitkän aikavälin tehtäviä. Minua rasittavana on jatkuva uusien termien keksiminen — pakkaaminen vakiintuneesta insinööritaidosta uutena tieteenalana, sitten valmistusjännitys siitä, että "olet jäljessä, jos et tunne tätä sanaa." Prompt-engineering, kontekstitekniikka, valjastustekniikka — ne ovat eri puolia samasta asiasta. Ensi kuussa joku todennäköisesti keksii scaffold engineeringin tai orkestrointitekniikan, kirjoittaa toisen pitkän esseen viitaten samaan SWE-agentin artikkeliin, ja yhteisö aloittaa uuden vahvistuskierron. Se, mitä opin ohjeesta sglangista, voidaan ilmaista ilman uutta sanastoa:...