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. 01 Arquitectura del kernel de agente: la guía completa Una 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. 02 Kernel de agente vs Framework de agente Un framework proporciona componentes que un desarrollador ensambla. Un kernel ejecuta el ciclo él mismo, verifica los resultados y actualiza sus propios pesos.
3. 03 BX-System vs. LangGraph: Kernel vs. Framework LangGraph 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. 04 Cómo evaluar un kernel de agente: la lista de verificación de 6 puntos Una 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. 06 Flujos declarativos vs scripts imperativos Un flujo declarativo nombra las herramientas y el orden. El kernel ejecuta el flujo; el flujo no se ejecuta a sí mismo.
7. 07 Guía de implementación: firmar herramientas con SHA-256 Una 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. 08 Cómo construir un flujo declarativo Una guía práctica para estructurar un flujo declarativo: definir las herramientas, establecer el orden y establecer los contratos de verificación.
9. 09 Un ciclo: generar, verificar, registrar, actualizar Un ciclo lee el contexto almacenado, genera una herramienta o flujo, verifica el resultado, registra el resultado y actualiza los pesos de estrategia.
10. 010 Cómo un agente genera sus propias herramientas Una 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. 011 Verificación de resultados: esperado vs real La verificación compara el resultado real de una herramienta con el resultado esperado y registra el veredicto.
12. 012 Cómo verificar la salida de un agente Verificación: definir el resultado esperado, ejecutar la herramienta, comparar el real con el esperado, registrar el veredicto, actualizar los pesos.
13. 013 Pesos de estrategia: cómo los resultados cambian el comportamiento Los pesos de estrategia se actualizan después de cada resultado verificado. Una estrategia que falló se desprioriza; el código no cambia.
14. 014 Recompensa entre 0 y 1: diseñar la escala del veredicto Una recompensa es un escalar entre 0 y 1 calculado a partir de un resultado verificado. Actualiza los pesos de estrategia.
15. 015 Llamadas a herramientas no declaradas: cuando se inventa una herramienta Una 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. 016 El motor AST: reparación de código basada en reglas El motor AST analiza el código generado, aplica reglas de política, escribe la versión corregida y actualiza la firma.
17. 017 Por qué el código generado por LLM falla en producción El código generado falla cuando no hay regla ni verificación. El motor AST aplica reglas; la verificación confirma el resultado.
18. 018 Definir reglas de reparación para código generado Una 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. 019 Interruptor de emergencia y contexto aislado Un 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. 020 Ejecución solo en RAM para los módulos centrales Los 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. 021 Cifrar paquetes de herramientas con AES-GCM Cada paquete se cifra con AES-GCM. El paquete se descifra en el contexto aislado y se ejecuta sin persistir.
22. 022 Estado estable: a qué vuelve el kernel El 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. 023 Pausar y reanudar un kernel autónomo La pausa detiene el ciclo pero conserva los pesos y la memoria. La reanudación lee el contexto almacenado y continúa desde él.
24. 024 Contexto de flujo de trabajo y estado de memoria El 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. 025 Pérdida de contexto entre ejecuciones La 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. 026 Medir la eficiencia sin adivinar La 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. 027 El coste de los agentes siempre activos Un agente siempre activo gasta recursos entre tareas. El kernel sopesa la energía consumida frente al resultado logrado en cada decisión.
28. 028 Cambio de comportamiento sin código nuevo Una estrategia que falló se desprioriza y una estrategia que funcionó se eleva. El código no cambia; los pesos sí.
29. 029 Por qué los agentes solo-prompt se rompen a escala Un 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. 030 Automatización no verificada: el fallo silencioso La 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. 031 Por qué los agentes de IA entran en bucle infinito Un 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. 032 Operación continua La 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. 033 Autoprotección La 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. 034 Adaptación La 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. 035 Reparación automática La 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. 036 Eficiencia La 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. 037 Los cinco principios operativos en una página Cinco principios: operación continua, autoprotección, adaptación, reparación automática, eficiencia. Cada uno tiene un artículo dedicado.
38. 038 Firmar cada herramienta con SHA-256 Cada 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. 039 Perfiles de rol: prefijo de prompt, sesgo, enrutamiento Un perfil de rol establece el prefijo de prompt, el perfil de sesgo y el enrutamiento de tareas para una llamada al modelo de lenguaje.