BX-System

BX-System no es un framework de agentes. Es un kernel de agente que genera sus propias herramientas, las verifica contra los resultados esperados, aprende de los resultados y sigue cinco principios operativos.

Cinco principios operativos

1. 01Arquitectura del kernel de agente: la guía completaUna guía completa de los componentes de un kernel de agente: el ciclo, el motor AST, el motor de memoria cognitiva y el contexto aislado.
2. 02Kernel de agente vs Framework de agenteUn framework proporciona componentes que un desarrollador ensambla. Un kernel ejecuta el ciclo él mismo, verifica los resultados y actualiza sus propios pesos.
3. 03BX-System vs. LangGraph: Kernel vs. FrameworkLangGraph es un framework para construir agentes con estado. BX-System es un kernel que ejecuta su propio ciclo y actualiza sus pesos sin reprogramación.
4. 04Cómo evaluar un kernel de agente: la lista de verificación de 6 puntosUna lista de verificación para evaluar un kernel de agente: el ciclo, la verificación, las actualizaciones de pesos, las reglas de reparación, el interruptor de emergencia y la eficiencia.
5. 05¿Qué es un kernel de agente?Un kernel de agente coordina herramientas mediante flujos declarativos, verifica su comportamiento y actualiza sus propios pesos de estrategia a partir de resultados verificados.
6. 06Flujos declarativos vs scripts imperativosUn flujo declarativo nombra las herramientas y el orden. El kernel ejecuta el flujo; el flujo no se ejecuta a sí mismo.
7. 07Guía de implementación: firmar herramientas con SHA-256Una guía paso a paso de cómo el kernel firma las herramientas con SHA-256 y actualiza la firma después de que el motor AST realiza una reparación.
8. 08Cómo construir un flujo declarativoUna guía práctica para estructurar un flujo declarativo: definir las herramientas, establecer el orden y establecer los contratos de verificación.
9. 09Un ciclo: generar, verificar, registrar, actualizarUn ciclo lee el contexto almacenado, genera una herramienta o flujo, verifica el resultado, registra el resultado y actualiza los pesos de estrategia.
10. 010Cómo un agente genera sus propias herramientasUna herramienta se genera como código, se firma, se verifica contra un resultado esperado y se registra. Una herramienta fallida no es de confianza.
11. 011Verificación de resultados: esperado vs realLa verificación compara el resultado real de una herramienta con el resultado esperado y registra el veredicto.
12. 012Cómo verificar la salida de un agenteVerificación: definir el resultado esperado, ejecutar la herramienta, comparar el real con el esperado, registrar el veredicto, actualizar los pesos.
13. 013Pesos de estrategia: cómo los resultados cambian el comportamientoLos pesos de estrategia se actualizan después de cada resultado verificado. Una estrategia que falló se desprioriza; el código no cambia.
14. 014Recompensa entre 0 y 1: diseñar la escala del veredictoUna recompensa es un escalar entre 0 y 1 calculado a partir de un resultado verificado. Actualiza los pesos de estrategia.
15. 015Llamadas a herramientas no declaradas: cuando se inventa una herramientaUna llamada a una herramienta no declarada es una herramienta que se invoca sin estar declarada en un flujo. El kernel la rechaza antes de la ejecución.
16. 016El motor AST: reparación de código basada en reglasEl motor AST analiza el código generado, aplica reglas de política, escribe la versión corregida y actualiza la firma.
17. 017Por qué el código generado por LLM falla en producciónEl código generado falla cuando no hay regla ni verificación. El motor AST aplica reglas; la verificación confirma el resultado.
18. 018Definir reglas de reparación para código generadoUna regla de reparación nombra una violación y la corrección que aplica el motor AST. Las reglas son declarativas y se aplican sin revisión manual.
19. 019Interruptor de emergencia y contexto aisladoUn interruptor de emergencia central detiene la ejecución. El aislamiento mantiene el contexto con instantáneas inmutables para que una detención y una reanudación no corrompan el estado.
20. 020Ejecución solo en RAM para los módulos centralesLos módulos centrales se ejecutan solo en RAM. No se escribe nada en disco durante la ejecución, por lo que un ciclo detenido no deja residuos ejecutables.
21. 021Cifrar paquetes de herramientas con AES-GCMCada paquete se cifra con AES-GCM. El paquete se descifra en el contexto aislado y se ejecuta sin persistir.
22. 022Estado estable: a qué vuelve el kernelEl estado estable es la condición a la que el kernel vuelve después de una reparación o después de una verificación fallida.
23. 023Pausar y reanudar un kernel autónomoLa pausa detiene el ciclo pero conserva los pesos y la memoria. La reanudación lee el contexto almacenado y continúa desde él.
24. 024Contexto de flujo de trabajo y estado de memoriaEl estado de memoria es el conocimiento acumulado al que cada ciclo añade. El contexto de flujo de trabajo registra la ejecución actual.
25. 025Pérdida de contexto entre ejecucionesLa pérdida de contexto ocurre cuando una ejecución no lee la memoria almacenada. El kernel se reanuda desde el contexto de flujo de trabajo y el estado de memoria.
26. 026Medir la eficiencia sin adivinarLa eficiencia se mide como la relación entre la energía consumida y el resultado logrado. No se mide por el volumen de salida.
27. 027El coste de los agentes siempre activosUn agente siempre activo gasta recursos entre tareas. El kernel sopesa la energía consumida frente al resultado logrado en cada decisión.
28. 028Cambio de comportamiento sin código nuevoUna estrategia que falló se desprioriza y una estrategia que funcionó se eleva. El código no cambia; los pesos sí.
29. 029Por qué los agentes solo-prompt se rompen a escalaUn agente solo-prompt no tiene ciclo, no tiene verificación y no tiene actualización de pesos. No puede adaptarse a partir de sus propios resultados.
30. 030Automatización no verificada: el fallo silenciosoLa automatización no verificada es un fallo silencioso: la herramienta se ejecuta, nada se compara y el resultado se asume. El kernel registra un veredicto.
31. 031Por qué los agentes de IA entran en bucle infinitoUn bucle es un ciclo sin verificación. El kernel detiene el bucle porque un ciclo termina en un resultado verificado, no en una suposición.
32. 032Operación continuaLa operación continua es el principio por el cual BX-System genera, verifica, registra y aprende sin esperar comandos. Cada ciclo lee la memoria almacenada, produce nuevo trabajo y actualiza sus propios pesos.
33. 033AutoprotecciónLa autoprotección es el principio por el cual BX-System protege su código, sus herramientas, sus paquetes y su contexto de ejecución mediante mecanismos por capas que operan antes, durante y después de la ejecución.
34. 034AdaptaciónLa adaptación es el principio por el cual BX-System cambia su comportamiento en función de los resultados acumulados en lugar de repetir una solución fija. Cada resultado verificado actualiza los pesos de estrategia; una estrategia que falló se desprioriza.
35. 035Reparación automáticaLa reparación automática es el principio por el cual BX-System corrige código defectuoso sin revisión manual. El motor AST detecta violaciones de reglas y las corrige; el kernel vuelve a un estado estable.
36. 036EficienciaLa eficiencia es el principio por el cual BX-System aspira a usar la menor cantidad de recursos posible. Cada decisión se sopesa por la energía consumida frente al resultado logrado.
37. 037Los cinco principios operativos en una páginaCinco principios: operación continua, autoprotección, adaptación, reparación automática, eficiencia. Cada uno tiene un artículo dedicado.
38. 038Firmar cada herramienta con SHA-256Cada herramienta está firmada con SHA-256. Un cambio de firma significa que el código cambió; una firma sin cambios significa que el código está como se verificó.
39. 039Perfiles de rol: prefijo de prompt, sesgo, enrutamientoUn perfil de rol establece el prefijo de prompt, el perfil de sesgo y el enrutamiento de tareas para una llamada al modelo de lenguaje.