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. 01 Architettura del kernel di agente: la guida completa Una guida completa ai componenti di un kernel di agente: il ciclo, il motore AST, il motore di memoria cognitiva e il contesto isolato.
2. 02 Kernel di agente vs Framework per agenti Un framework fornisce componenti che uno sviluppatore assembla. Un kernel esegue il ciclo stesso, verifica i risultati e aggiorna i propri pesi.
3. 03 BX-System vs. LangGraph: Kernel vs. Framework LangGraph è un framework per costruire agenti con stato. BX-System è un kernel che esegue il proprio ciclo e aggiorna i propri pesi senza riprogrammazione.
4. 04 Come valutare un kernel di agente: la checklist in 6 punti Una 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. 05 Cos'è 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. 06 Flussi dichiarativi vs script imperativi Un flusso dichiarativo nomina gli strumenti e l'ordine. Il kernel esegue il flusso; il flusso non esegue se stesso.
7. 07 Guida all'implementazione: firmare gli strumenti con SHA-256 Una 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. 08 Come costruire un flusso dichiarativo Una guida pratica per strutturare un flusso dichiarativo: definire gli strumenti, impostare l'ordine e stabilire i contratti di verifica.
9. 09 Un ciclo: generare, verificare, registrare, aggiornare Un ciclo legge il contesto memorizzato, genera uno strumento o un flusso, verifica il risultato, registra il risultato e aggiorna i pesi delle strategie.
10. 010 Come un agente genera i propri strumenti Uno strumento viene generato come codice, firmato, verificato rispetto a un risultato atteso e registrato. Uno strumento fallito non è affidabile.
11. 011 Verifica dei risultati: atteso vs reale La verifica confronta il risultato reale di uno strumento con il risultato atteso e registra il verdetto.
12. 012 Come verificare l'output di un agente Verifica: definire il risultato atteso, eseguire lo strumento, confrontare reale e atteso, registrare il verdetto, aggiornare i pesi.
13. 013 Pesi delle strategie: come i risultati cambiano il comportamento I pesi delle strategie vengono aggiornati dopo ogni risultato verificato. Una strategia fallita viene deprioritizzata; il codice non cambia.
14. 014 Reward tra 0 e 1: progettare la scala del verdetto Una reward è uno scalare tra 0 e 1 calcolato da un risultato verificato. Aggiorna i pesi delle strategie.
15. 015 Chiamate a strumenti non dichiarati: quando uno strumento viene inventato Una chiamata a uno strumento non dichiarato è uno strumento invocato senza essere dichiarato in un flusso. Il kernel lo rifiuta prima dell'esecuzione.
16. 016 Il motore AST: riparazione del codice basata su regole Il motore AST analizza il codice generato, applica le regole di policy, scrive la versione corretta e aggiorna la firma.
17. 017 Perché il codice generato da LLM fallisce in produzione Il codice generato fallisce quando non c'è regola e non c'è verifica. Il motore AST applica regole; la verifica conferma il risultato.
18. 018 Definire regole di riparazione per il codice generato Una 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. 019 Kill switch e contesto isolato Un 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. 020 Esecuzione solo in RAM per i moduli core I moduli core vengono eseguiti solo in RAM. Nulla viene scritto su disco durante l'esecuzione, quindi un ciclo fermato non lascia residui eseguibili.
21. 021 Cifrare i pacchetti degli strumenti con AES-GCM Ogni pacchetto è cifrato con AES-GCM. Il pacchetto viene decifrato nel contesto isolato ed eseguito senza persistenza.
22. 022 Stato stabile: a cosa ritorna il kernel Lo stato stabile è la condizione a cui il kernel ritorna dopo una riparazione o dopo una verifica fallita.
23. 023 Mettere in pausa e riprendere un kernel autonomo La pausa ferma il ciclo ma conserva i pesi e la memoria. La ripresa legge il contesto memorizzato e continua da lì.
24. 024 Contesto del flusso di lavoro e stato di memoria Lo stato di memoria è la conoscenza accumulata a cui ogni ciclo aggiunge. Il contesto del flusso di lavoro registra l'esecuzione corrente.
25. 025 Perdita di contesto tra le esecuzioni La 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. 026 Misurare l'efficienza senza indovinare L'efficienza è misurata come rapporto tra energia consumata e risultato ottenuto. Non è misurata dal volume di output.
27. 027 Il costo degli agenti sempre attivi Un 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. 028 Cambiare comportamento senza nuovo codice Una strategia fallita viene deprioritizzata e una strategia che ha funzionato viene elevata. Il codice è invariato; i pesi cambiano.
29. 029 Perché gli agenti solo-prompt si rompono su larga scala Un agente solo-prompt non ha ciclo, non ha verifica e non ha aggiornamento dei pesi. Non può adattarsi dai propri risultati.
30. 030 Automazione non verificata: il fallimento silenzioso L'automazione non verificata è un fallimento silenzioso: lo strumento viene eseguito, nulla viene confrontato e il risultato viene presunto. Il kernel registra un verdetto.
31. 031 Perché gli agenti AI entrano in loop infiniti Un loop è un ciclo senza verifica. Il kernel ferma il loop perché un ciclo termina con un risultato verificato, non con una supposizione.
32. 032 Operazione continua L'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. 033 Autoprotezione L'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. 034 Adattamento L'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. 035 Riparazione automatica La 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. 036 Efficienza L'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. 037 I cinque principi operativi in una pagina Cinque principi: operazione continua, autoprotezione, adattamento, riparazione automatica, efficienza. Ognuno ha un articolo dedicato.
38. 038 Firmare ogni strumento con SHA-256 Ogni strumento è firmato con SHA-256. Un cambiamento della firma significa che il codice è cambiato; una firma invariata significa che il codice è come verificato.
39. 039 Profili di ruolo: prefisso del prompt, bias, instradamento Un profilo di ruolo imposta il prefisso del prompt, il profilo di bias e l'instradamento del compito per una chiamata al modello linguistico.