Oggi ho letto un lungo articolo su Harness Engineering — decine di migliaia di parole, quasi certamente scritto da un'AI. La mia prima reazione non è stata "wow, che concetto potente." È stata "queste persone hanno idee oltre a coniare nuovi termini per vecchi concetti?" Sono sempre stato infastidito da questo schema nel mondo dell'AI — la costante reinvenzione di concetti esistenti. Dall'ingegneria dei prompt all'ingegneria del contesto, ora all'ingegneria di harness. Ogni pochi mesi qualcuno conia un nuovo termine, scrive un saggio di 10.000 parole, aggiunge qualche studio di caso di grandi aziende, e tutta la comunità inizia a ronzare. Ma se guardi realmente al contenuto, è sempre la stessa cosa: Progetta l'ambiente in cui il tuo modello opera — quali informazioni riceve, quali strumenti può usare, come vengono intercettati gli errori, come viene gestita la memoria tra le sessioni. Questo esiste sin dal giorno in cui è stato lanciato ChatGPT. Non diventa una nuova disciplina solo perché qualcuno — per qualsiasi motivo — ha deciso di dargli un nuovo nome. Detto ciò, a parte le lamentele, la ricerca e gli studi di caso citati nell'articolo hanno valore — soprattutto poiché si sovrappongono pesantemente a ciò che ho costruito con how-to-sglang. Quindi lasciami usare questa opportunità per parlare degli errori che ho effettivamente fatto. Un po' di contesto prima. Le richieste più comuni nella comunità SGLang sono le Domande How-to — come distribuire DeepSeek-V3 su 8 GPU, cosa fare quando il gateway non riesce a raggiungere l'indirizzo del lavoratore, se il divario tra GLM-5 INT4 e FP8 ufficiale è significativo. Queste domande coprono una superficie tecnica estremamente ampia, e man mano che la comunità cresce sempre più velocemente, non riusciamo a tenere il passo con le risposte. Così ho iniziato a costruire un sistema multi-agente per rispondere automaticamente. La prima idea era, ovviamente, la più ingenua — costruire un singolo Agente onnisciente, inserire tutta la documentazione, il codice e i ricettari di SGLang al suo interno, e lasciarlo rispondere a tutto. Non ha funzionato. Non hai bisogno della teoria dell'ingegneria di harness per spiegare perché — la finestra di contesto non è RAM. Più ne metti dentro, più l'attenzione del modello si disperde e peggiorano le risposte. Un Agente che cerca di comprendere simultaneamente la quantizzazione, la disaggregazione PD, il servizio di diffusione e la compatibilità hardware finisce per non comprendere profondamente nessuno di essi. Il design su cui siamo infine approdati è un'architettura a strati di esperti di sotto-dominio. La documentazione di SGLang ha già confini funzionali naturali — funzionalità avanzate, piattaforme, modelli supportati — con ricettari organizzati per modello. Abbiamo trasformato ogni sotto-dominio in un agente esperto indipendente, con un Manager di Dibattito Esperto responsabile della ricezione delle domande, della loro scomposizione in sotto-domande, della consultazione della Tabella di Routing degli Esperti per attivare gli agenti giusti, della risoluzione in parallelo e poi della sintesi delle risposte. Guardando indietro, questo design si mappa quasi perfettamente sui modelli che la comunità dell'ingegneria di harness sostiene. Ma quando lo stavo costruendo, non avevo idea che questi modelli avessero nomi. E non ne avevo bisogno. 1. Divulgazione progressiva — non abbiamo scaricato tutta la documentazione in un singolo agente. Ogni esperto di dominio carica solo le proprie conoscenze di dominio, e il Manager decide chi attivare in base al tipo di domanda. La mia sensazione è che questo design abbia portato a un miglioramento molto maggiore rispetto a quello che ha mai fatto l'inserimento di un modello più forte. Non hai bisogno di sapere che questo si chiama "divulgazione progressiva" per prendere questa decisione. Devi solo aver provato l'approccio "metti tutto dentro" una volta e averlo visto fallire. 2. Repository come fonte di verità — l'intero flusso di lavoro vive nel repository how-to-sglang. Tutti gli agenti esperti attingono le loro conoscenze da file markdown all'interno del repository, senza dipendenze da documenti esterni o accordi verbali. All'inizio, avevamo l'impulso di scrivere un enorme sglang-maintain.md che coprisse tutto. Abbiamo rapidamente imparato che non funziona. Il team di Codex di OpenAI ha commesso lo stesso errore — ha provato un singolo AGENTS.md sovradimensionato e l'ha visto marcire in modi prevedibili. Non hai bisogno di aver letto il loro blog per calpestare questa mina. È il classico problema dell'ingegneria del software di "la documentazione monolitica va sempre in disuso," tranne che in un contesto di agenti le conseguenze sono peggiori — la documentazione obsoleta non solo non viene letta, ma inganna attivamente l'agente. 3. Routing strutturato — la Tabella di Routing degli Esperti mappa esplicitamente i tipi di domande agli agenti. Una domanda su GLM-5 INT4 attiva sia l'Esperto di Domini Ricettari che l'Esperto di Domini Quantizzazione simultaneamente. Il Manager non indovina; segue un indice strutturato. La folla dell'ingegneria di harness chiama questo "vincoli meccanizzati." Io lo chiamo ingegneria normale. Non sto dicendo che le idee dietro l'ingegneria di harness siano cattive. La ricerca citata è solida, il concetto ACI di SWE-agent è genuinamente degno di nota, e l'architettura a doppio agente di Anthropic (agente inizializzatore + agente di codifica) è materiale di riferimento prezioso per chiunque stia svolgendo compiti a lungo termine. Quello che trovo stancante è la costante coniazione di nuovi termini — confezionare il buon senso ingegneristico consolidato come una nuova disciplina, per poi generare ansia attorno a "sei indietro se non conosci questa parola." L'ingegneria dei prompt, l'ingegneria del contesto, l'ingegneria di harness — sono diverse sfaccettature della stessa cosa. Il mese prossimo qualcuno probabilmente conierà l'ingegneria di impalcature o l'ingegneria di orchestrazione, scriverà un altro lungo saggio citando lo stesso documento SWE-agent, e la comunità inizierà un altro ciclo di amplificazione. Ciò che ho effettivamente appreso da how-to-sglang può essere dichiarato senza alcun nuovo vocabolario:...