Prompt, context, loop e graph engineering si sono rivelati tutti pezzi dello stesso meccanismo. L'harness è il luogo in cui finalmente convivono.
Ogni fase della costruzione con l'AI ha ottenuto il proprio titolo professionale. Il prompt engineering è arrivato per primo, quando tutta l'arte consisteva nel trovare la frase giusta.
È seguito il context engineering, una volta diventato evidente che la frase contava meno di tutto ciò che le veniva caricato attorno. Quest'estate è toccato ai loop, e poche settimane dopo, ai grafi.
Il nome che si sta diffondendo ora è harness engineering, ed è il primo che spiega tutti gli altri.
Un harness è tutto ciò che circonda il modello: gli strumenti che può chiamare, i file che legge prima di qualsiasi altra cosa, le directory in cui può scrivere, i controlli che l'output deve superare, la pianificazione che lo sveglia e la regola che termina l'esecuzione.
Ogni disciplina precedente a questa si rivela essere un singolo componente di quella struttura, costruita separatamente e dotata di un proprio nome.
Ho iniziato a prestare attenzione per una ragione pratica. Il modello sottostante continua a cambiare, a volte di diciassette posizioni in classifica in un singolo aggiornamento, e l'harness è l'unica parte del sistema che rimane tua.
1/ Sette Ingegnerie, Una Macchina
Disciplina
La domanda a cui risponde
Dove vive nell'harness
Prompt engineering
Cosa sto chiedendo esattamente
SKILL.md, la specifica del task caricata per prima
Context engineering
Cosa vede il modello ad ogni passo
L'assemblatore di contesto: vincoli, schemi, pagine recuperate
Tool engineering
A cosa può accedere, e in quale formato
Definizioni degli strumenti con input e output tipizzati
Loop engineering
Cosa avvia un'esecuzione e cosa la termina
Il runner: trigger, condizioni di stop, budget
Graph engineering
Cosa ricorda e come si collegano le cose
Il layer di memoria: nodi, archi tipizzati, alias
Eval engineering
Come viene rifiutato un risultato
Il verificatore, fuori dal controllo dell'agente
Harness engineering
Cosa tiene insieme tutto quanto sopra
La struttura, i permessi e gli hook
Leggi la tabella dall'alto verso il basso ed è una storia. Leggila dal basso verso l'alto ed è un'architettura: l'harness engineering è il lavoro di decidere dove vive ciascuno degli altri sei, affinché nessuno finisca nascosto in un prompt.
Quest'ultimo punto porta la maggior parte del peso.
Un prompt è il posto più facile in cui mettere qualsiasi cosa, quindi tutto vi deriva: il formato di output, la regola di arresto, le correzioni della settimana scorsa, l'elenco delle cose che l'agente non deve mai toccare. Funziona magnificamente sul modello per cui è stato scritto, e poi il modello successivo legge lo stesso paragrafo in modo diverso.
2/ Anatomia di un Harness
L'abitudine più utile che ho acquisito è scrivere l'intero harness come un unico file di configurazione, così che nulla di importante rimanga implicito:
1# harness.yaml2model: kimi-k3 # una riga. tutto ciò che segue sopravvive a uno swap3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # notturno, mentre dormi12 stop: 40 nodi verificati OPPURE 3 passaggi senza novità13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Tre righe in quel file fanno la maggior parte del lavoro.
model: è una riga apposta. Tutto il resto è scritto in modo che non importi cosa dice quella riga. Questa è l'intera storia della portabilità.
permissions: conta più di tools:, anche se si trova più in basso nel file. Scrivere cosa l'agente può modificare e su cosa deve chiedere prima è ciò che separa un sistema che lasci funzionare durante la notte da uno che stai seduto a guardare.
verify: ha due voci per un motivo. Lo script non costa nulla e cattura qualsiasi cosa meccanica. Il reviewer è un secondo agente che non ha mai visto lavorare il primo, perché un agente che valuta il proprio output trova ogni scusa per approvarlo.
Su disco, l'harness è una cartella, e ogni ingegneria dalla tabella ottiene il proprio indirizzo al suo interno.
3/ Perché Kimi K3 È il Motore Che Ci Metterei Dentro
Ciò di cui l'harness ha bisogno
Ciò che Kimi K3 offre
Un runner capace di espandersi (fan-out)
Agent Swarm: fino a 300 agenti su un problema contemporaneamente, senza scrivere un orchestratore
Codice abbastanza forte da scrivere i propri controlli
#1 nella Frontend Code Arena con 1.679, davanti a Fable 5 (1.631) e GPT-5.6 Sol (1.618), leader in 6 dei 7 domini
Un motore che migliora sotto di te
Da #18 a #1 in un singolo aggiornamento di luglio
La prima riga conta più di quanto sembri. Quasi ogni harness fatto in casa sviluppa un orchestratore costruito a mano a un certo punto, ed è solitamente il file più fragile nella cartella. Con lo swarm, il fan-out diventa una voce di budget, agents: 300, e all'harness basta gestire ciò che torna indietro.
La seconda riga conta perché un harness è per lo più codice che il modello scrive per te: script di hook, controlli di schema, la piccola dashboard che legge 40-runs. Un motore che guida l'arena frontend li azzecca al primo colpo molto più spesso.
La terza riga è il caso per l'harness engineering in un singolo dato. Quando un modello sale di diciassette posizioni durante la notte, un harness mette quel salto a lavoro lo stesso giorno, perché l'unica riga che deve cambiare è model.
4/ Hooks: I Riflessi
Un hook è un breve script che l'harness esegue in un momento fisso, qualunque cosa il modello decida di fare. Gli hook sono il punto in cui un harness smette di essere una struttura di cartelle e inizia a comportarsi come un sistema di sicurezza.
Hook
Quando scatta
Cosa fa
pre_tool
Prima di qualsiasi chiamata allo strumento
Blocca le scritture fuori dalla lista dei permessi
post_tool
Dopo ogni ritorno
Esegue il controllo dello schema e rifiuta immediatamente l'output malformato
pre_send
Prima che qualcosa lasci la macchina
Lo trattiene in una coda finché non lo autorizzi
on_fail
Dopo un risultato rifiutato
Allega la ragione del fallimento al retry
post_run
Quando scatta la condizione di stop
Aggiunge il record dell'esecuzione a 40-runs e fa il diff del grafo
L'hook pre_tool della prima riga sta in cinque righe:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "bloccato: $TARGET è fuori dalla lista di scrittura"; exit 1 ;;5esac
L'hook on_fail da solo cambia l'economia di un loop. Un retry che porta con sé la ragione per cui l'ultimo tentativo è fallito è una correzione. Senza quella ragione, il loop paga per lo stesso errore una seconda volta.
5/ Come Sembra una Notte
Metti insieme tutti i pezzi e l'harness si comporta come un turno di notte che segue le regole. Alle 02:00 scatta il trigger e la query di lancio seleziona ogni nodo che necessita di lavoro. Lo swarm si espande, un agente per nodo.
I ritorni che mancano lo schema vengono rifiutati da post_tool prima di raggiungere il grafo, e ogni nodo rifiutato riprova una volta con allegata la sua ragione di fallimento. Quando un agente cerca di scrivere fuori dalla sua cartella, pre_tool lo ferma senza svegliare nessuno.
Nodi fusi e archi tipizzati atterrano in 20-graph. Un'email bozza raggiunge pre_send e aspetta. post_run aggiunge il record, e il loop si ferma sulla sua stessa condizione, ben dentro il budget di 45 minuti della configurazione.
Alle 07:30 leggi un file e prendi due decisioni. Questo è l'intero costo mattutino di eseguire il loop engineering e il graph engineering in questo modo, ed è il punto centrale dell'harness: tutto ciò che poteva funzionare senza di te ha funzionato, e le poche cose che avevano bisogno di te stanno aspettando in un unico posto.
6/ Il Test di Swap
L'audit più veloce di qualsiasi setup di agenti: cambia la riga del modello e eseguilo di nuovo. Qualsiasi cosa si rompesse era un harness vissuto nel posto sbagliato.
Cosa si rompe dopo lo swap
Dove era nascosto
Dove appartiene
Il formato di output deriva
"rispondi sempre in JSON" nel prompt
Uno schema di ritorno più uno script che rifiuta qualsiasi altra cosa
Le esecuzioni smettono di terminare da sole
"continua finché non è esaustivo"
Una condizione di stop fatta di conteggi
Le correzioni della settimana scorsa sono sparite
La cronologia della chat
CONSTRAINTS.md, caricato ad ogni esecuzione
La stessa azienda appare tre volte
Il giudizio del modello
aliases.csv, controllato prima della fusione
Scrive da qualche parte dove non dovrebbe
Una frase gentile nel prompt
Una lista di permessi e un hook pre_tool
Un setup che supera il test di swap è portabile, e portabile è ciò che lo rende prezioso.
Quanto Costa e Quanto Paga
Le aziende investono interi trimestri in piattaforme interne per agenti. Un harness funzionante è una cartella, un file di configurazione e cinque brevi script, e gira su un abbonamento Kimi. Quel divario è l'opportunità.
Canale
Quanto paga
Di cosa hai bisogno prima
Setup dell'harness per un piccolo team
Una tariffa una tantum a quattro cifre per la configurazione, gli hook e il verificatore attorno al loro workflow
Un tuo harness, funzionante su una pianificazione
Retainer del giorno di rilascio
Una tariffa mensile per eseguire il test di swap su ogni major release del modello e spostare il team su chiunque sia leader
Un cliente le cui esecuzioni registrano già su 40-runs
Template di harness di nicchia
La cartella e lo yaml impacchettati per un settore: ricerca, recruiting, compliance
Lo stesso harness dimostrato in due mercati diversi
Il secondo canale è quello che costruirei per primo. Ogni major release rimescola la classifica, solo K3 si è mosso di diciassette posizioni in un aggiornamento, e ogni team con un harness ha bisogno di qualcuno il cui lavoro sia eseguire il test di swap il giorno del rilascio.
La Versione Breve
Prompt, context, tool, loop, graph e eval engineering si rivelano tutti componenti di una singola macchina, e l'harness engineering è decidere dove vive ciascuno di essi.
Metti il modello dietro una riga, i permessi davanti agli strumenti e il verificatore fuori dall'agente. Allora il prossimo salto in classifica sarà un cambio di configurazione invece di una ricostruzione.
E se l'hai trovato utile:
- Salva tra i preferiti questo articolo. I link cambiano e nuovi repo spuntano settimanalmente, ti servirà come riferimento
- Per approfondimenti settimanali sull'architettura AI, trading quantitativo e l'economia degli agenti, seguimi: @polydao
- Unisciti al Canale TG: Buzzoni Notes - qui condivido i miei prompt grezzi, skill personalizzate e alpha troppo presto per X
