BX-System

BX-System non è un framework per agenti. È un kernel di agente che genera i propri strumenti, li verifica rispetto ai risultati attesi, impara dai risultati e segue cinque principi operativi.

Cinque principi operativi

1. 01Architettura del kernel di agente: la guida completaUna guida completa ai componenti di un kernel di agente: il ciclo, il motore AST, il motore di memoria cognitiva e il contesto isolato.
2. 02Kernel di agente vs Framework per agentiUn framework fornisce componenti che uno sviluppatore assembla. Un kernel esegue il ciclo stesso, verifica i risultati e aggiorna i propri pesi.
3. 03BX-System vs. LangGraph: Kernel vs. FrameworkLangGraph è un framework per costruire agenti con stato. BX-System è un kernel che esegue il proprio ciclo e aggiorna i propri pesi senza riprogrammazione.
4. 04Come valutare un kernel di agente: la checklist in 6 puntiUna checklist per valutare un kernel di agente: il ciclo, la verifica, gli aggiornamenti dei pesi, le regole di riparazione, il kill switch e l'efficienza.
5. 05Cos'è un kernel di agente?Un kernel di agente coordina strumenti tramite flussi dichiarativi, ne verifica il comportamento e aggiorna i propri pesi delle strategie in base ai risultati verificati.
6. 06Flussi dichiarativi vs script imperativiUn flusso dichiarativo nomina gli strumenti e l'ordine. Il kernel esegue il flusso; il flusso non esegue se stesso.
7. 07Guida all'implementazione: firmare gli strumenti con SHA-256Una guida passo passo su come il kernel firma gli strumenti con SHA-256 e aggiorna la firma dopo che il motore AST esegue una riparazione.
8. 08Come costruire un flusso dichiarativoUna guida pratica per strutturare un flusso dichiarativo: definire gli strumenti, impostare l'ordine e stabilire i contratti di verifica.
9. 09Un ciclo: generare, verificare, registrare, aggiornareUn ciclo legge il contesto memorizzato, genera uno strumento o un flusso, verifica il risultato, registra il risultato e aggiorna i pesi delle strategie.
10. 010Come un agente genera i propri strumentiUno strumento viene generato come codice, firmato, verificato rispetto a un risultato atteso e registrato. Uno strumento fallito non è affidabile.
11. 011Verifica dei risultati: atteso vs realeLa verifica confronta il risultato reale di uno strumento con il risultato atteso e registra il verdetto.
12. 012Come verificare l'output di un agenteVerifica: definire il risultato atteso, eseguire lo strumento, confrontare reale e atteso, registrare il verdetto, aggiornare i pesi.
13. 013Pesi delle strategie: come i risultati cambiano il comportamentoI pesi delle strategie vengono aggiornati dopo ogni risultato verificato. Una strategia fallita viene deprioritizzata; il codice non cambia.
14. 014Reward tra 0 e 1: progettare la scala del verdettoUna reward è uno scalare tra 0 e 1 calcolato da un risultato verificato. Aggiorna i pesi delle strategie.
15. 015Chiamate a strumenti non dichiarati: quando uno strumento viene inventatoUna chiamata a uno strumento non dichiarato è uno strumento invocato senza essere dichiarato in un flusso. Il kernel lo rifiuta prima dell'esecuzione.
16. 016Il motore AST: riparazione del codice basata su regoleIl motore AST analizza il codice generato, applica le regole di policy, scrive la versione corretta e aggiorna la firma.
17. 017Perché il codice generato da LLM fallisce in produzioneIl codice generato fallisce quando non c'è regola e non c'è verifica. Il motore AST applica regole; la verifica conferma il risultato.
18. 018Definire regole di riparazione per il codice generatoUna regola di riparazione nomina una violazione e la correzione che applica il motore AST. Le regole sono dichiarative e si applicano senza revisione manuale.
19. 019Kill switch e contesto isolatoUn kill switch centrale ferma l'esecuzione. L'isolamento mantiene il contesto con snapshot immutabili, così un arresto e una ripresa non corrompono lo stato.
20. 020Esecuzione solo in RAM per i moduli coreI moduli core vengono eseguiti solo in RAM. Nulla viene scritto su disco durante l'esecuzione, quindi un ciclo fermato non lascia residui eseguibili.
21. 021Cifrare i pacchetti degli strumenti con AES-GCMOgni pacchetto è cifrato con AES-GCM. Il pacchetto viene decifrato nel contesto isolato ed eseguito senza persistenza.
22. 022Stato stabile: a cosa ritorna il kernelLo stato stabile è la condizione a cui il kernel ritorna dopo una riparazione o dopo una verifica fallita.
23. 023Mettere in pausa e riprendere un kernel autonomoLa pausa ferma il ciclo ma conserva i pesi e la memoria. La ripresa legge il contesto memorizzato e continua da lì.
24. 024Contesto del flusso di lavoro e stato di memoriaLo stato di memoria è la conoscenza accumulata a cui ogni ciclo aggiunge. Il contesto del flusso di lavoro registra l'esecuzione corrente.
25. 025Perdita di contesto tra le esecuzioniLa perdita di contesto si verifica quando un'esecuzione non legge la memoria memorizzata. Il kernel riprende dal contesto del flusso di lavoro e dallo stato di memoria.
26. 026Misurare l'efficienza senza indovinareL'efficienza è misurata come rapporto tra energia consumata e risultato ottenuto. Non è misurata dal volume di output.
27. 027Il costo degli agenti sempre attiviUn agente sempre attivo consuma risorse tra un compito e l'altro. Il kernel pesa l'energia consumata rispetto al risultato ottenuto in ogni decisione.
28. 028Cambiare comportamento senza nuovo codiceUna strategia fallita viene deprioritizzata e una strategia che ha funzionato viene elevata. Il codice è invariato; i pesi cambiano.
29. 029Perché gli agenti solo-prompt si rompono su larga scalaUn agente solo-prompt non ha ciclo, non ha verifica e non ha aggiornamento dei pesi. Non può adattarsi dai propri risultati.
30. 030Automazione non verificata: il fallimento silenziosoL'automazione non verificata è un fallimento silenzioso: lo strumento viene eseguito, nulla viene confrontato e il risultato viene presunto. Il kernel registra un verdetto.
31. 031Perché gli agenti AI entrano in loop infinitiUn loop è un ciclo senza verifica. Il kernel ferma il loop perché un ciclo termina con un risultato verificato, non con una supposizione.
32. 032Operazione continuaL'operazione continua è il principio per cui BX-System genera, verifica, registra e impara senza attendere comandi. Ogni ciclo legge la memoria memorizzata, produce nuovo lavoro e aggiorna i propri pesi.
33. 033AutoprotezioneL'autoprotezione è il principio per cui BX-System protegge il proprio codice, i propri strumenti, i propri pacchetti e il proprio contesto di esecuzione tramite meccanismi a più livelli che operano prima, durante e dopo l'esecuzione.
34. 034AdattamentoL'adattamento è il principio per cui BX-System cambia il proprio comportamento in base ai risultati accumulati invece di ripetere una soluzione fissa. Ogni risultato verificato aggiorna i pesi delle strategie; una strategia fallita viene deprioritizzata.
35. 035Riparazione automaticaLa riparazione automatica è il principio per cui BX-System corregge codice difettoso senza revisione manuale. Il motore AST rileva violazioni delle regole e le corregge; il kernel torna a uno stato stabile.
36. 036EfficienzaL'efficienza è il principio per cui BX-System mira a usare il minor numero possibile di risorse. Ogni decisione è pesata dall'energia consumata rispetto al risultato ottenuto.
37. 037I cinque principi operativi in una paginaCinque principi: operazione continua, autoprotezione, adattamento, riparazione automatica, efficienza. Ognuno ha un articolo dedicato.
38. 038Firmare ogni strumento con SHA-256Ogni strumento è firmato con SHA-256. Un cambiamento della firma significa che il codice è cambiato; una firma invariata significa che il codice è come verificato.
39. 039Profili di ruolo: prefisso del prompt, bias, instradamentoUn profilo di ruolo imposta il prefisso del prompt, il profilo di bias e l'instradamento del compito per una chiamata al modello linguistico.