Dnes jsem četl rozsáhlý článek o inženýrství svazků — desítky tisíc slov, téměř jistě napsaných AI. Moje první reakce nebyla "wow, jaký silný koncept." Bylo to: "Mají tito lidé nějaké nápady kromě vytváření nových termínů pro staré?" Vždy mě tento vzorec ve světě AI rozčiloval — neustálé přetváření stávajících konceptů. Od prompt engineeringu přes kontextové inženýrství, nyní až po využití inženýrství. Každých pár měsíců někdo vymyslí nový termín, napíše eseji o 10 000 slovech, přidá pár případových studií velkých firem a celá komunita začne bzučit. Ale když se na obsah podíváte skutečně, je to pokaždé stejné: Navrhněte prostředí, ve kterém váš model běží — jaké informace přijímá, jaké nástroje může použít, jak se chyby zachytávají, jak je paměť spravována napříč relacemi. To existuje od dne, kdy ChatGPT byl uveden na trh. Nestane se z toho nová disciplína jen proto, že jí někdo — z jakéhokoliv důvodu — dal nové jméno. Nicméně, bez ohledu na stížnosti, výzkum a případové studie uvedené v článku mají hodnotu — zvlášť protože se silně překrývají s tím, co jsem budoval s návody na sglang. Takže využiji tuto příležitost mluvit o chybách, které jsem skutečně udělal. Nejprve trochu pozadí. Nejčastějšími požadavky v komunitě SGLang jsou Návody na otázky — jak nasadit DeepSeek-V3 na 8 GPU, co dělat, když brána nemůže dosáhnout na worker adresu, zda je mezera mezi GLM-5 INT4 a oficiálním FP8 významná. Tyto otázky pokrývají extrémně široký technický rozsah a jak komunita roste stále rychleji, stále méně dokážeme držet krok s odpověďmi. Tak jsem začal budovat systém s více agenty, který na ně odpovídá automaticky. První nápad byl samozřejmě ten nejnaivnější — vytvořit jednoho vševědoucího agenta, nacpat do něj všechny dokumenty, kód a kuchařky SGLang a nechat ho odpovědět na všechno. To nefungovalo. K vysvětlení proč není potřeba teorie inženýrství svazků — kontextové okno není RAM. Čím víc do toho vkládáte, tím víc se pozornost modelu rozptyluje a tím horší jsou odpovědi. Agent, který se snaží současně rozumět kvantizaci, PD disagilaci, difuznímu servírování a hardwarové kompatibilitě, nakonec žádné z nich nerozumí do hloubky. Návrh, na který jsme nakonec dospěli, je vícevrstvá subdoménová expertní architektura. Dokumentace SGLang už má přirozené funkční hranice — pokročilé funkce, platformy, podporované modely — s kuchařkami uspořádanými podle modelů. Každou subdoménu jsme proměnili v nezávislého expertního agenta, kde Expert Debating Manager byl zodpovědný za přijímání otázek, jejich rozklad na podotázky, konzultaci s Expert Routing Table pro aktivaci správných agentů, řešení paralelně a následně syntetizaci odpovědí. Při zpětném pohledu tento návrh téměř dokonale odpovídá vzorům, které komunita inženýrů postrojů prosazuje. Ale když jsem ho stavěl, vůbec jsem netušil, že tyto vzory mají jména. A ani jsem nemusel. 1. Postupné zveřejňování — nepředávali jsme veškerou dokumentaci žádnému jednotlivému agentovi. Každý odborník na oblast načítá pouze své vlastní znalosti domény a manažer rozhoduje, koho aktivovat podle typu otázky. Mám pocit, že tento design přinesl mnohem větší zlepšení než výměna silnějšího modelu. Nemusíte vědět, že se tomu říká "progresivní zveřejňování", abyste se rozhodli. Stačí jen jednou zkusit přístup "nacpat všechno dovnitř" a sledovat, jak to selhalo. 2. Repozitář jako zdroj pravdy — celý pracovní postup je uložen v repozitáři typu howto-sglang. Všichni odborní agenti čerpají své znalosti z markdown souborů uvnitř repozitáře, bez závislosti na externích dokumentech nebo ústních dohodách. Na začátku jsme měli chuť napsat jeden obrovský sglang-maintain.md pokrývající všechno. Rychle jsme zjistili, že to nefunguje. Tým OpenAI pro Codex udělal stejnou chybu — zkusili jeden předimenzovaný AGENTS.md a sledovali, jak se rozpadá předvídatelným způsobem. Nemusíte číst jejich blog, abyste na tuto minu šliapli sami. Je to klasický problém softwarového inženýrství "monolitické dokumenty vždy zastarají", jenže v kontextu agenta jsou důsledky horší — zastaralá dokumentace nejen zůstává nepřečtená, ale aktivně klame agenta. 3. Strukturované směrování — Expertní směrovací tabulka explicitně mapuje typy otázek na agenty. Otázka ohledně GLM-5 INT4 aktivuje současně jak Cookbook Domain Expert, tak Quantization Domain Expert. Manažer nehádá; následuje strukturovaný rejstřík. Odborníci na inženýrství svazů tomu říkají "mechanizovaná omezení". Říkám tomu normální inženýrství. Neříkám, že myšlenky za inženýrstvím svazků jsou špatné. Citovaný výzkum je solidní, koncept ACI ze SWE-agent stojí za znát a architektura Anthropicu s duálním agentem (inicializér agent + kódovací agent) je cenným referenčním materiálem pro každého, kdo dělá dlouhodobé úkoly. Co mě unavuje, je neustálé vytváření nových termínů — balení zavedeného inženýrského zdravého rozumu jako nové disciplíny a pak vytváření úzkosti kolem "jsi pozadu, pokud neznáš toto slovo." Prompt engineering, context engineering, harness engineering — to jsou různé aspekty téže věci. Příští měsíc někdo pravděpodobně vytvoří inženýrství lešení nebo orchestrační inženýrství, napíše další dlouhou esej citující stejný článek o agentu softwaru a komunita začne další cyklus zesilování. Co jsem se skutečně naučil ze sglangu, lze vyjádřit bez nové slovní zásoby:...