ByteNex›Artículos
Artículos
Tiempo de ejecución
- ¿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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
AI bots
- 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í.
- 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.
Infraestructura
- 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.
- 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.
- 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.
- 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.
- 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.
- 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ó.
Verificación
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Reparación de código
- 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.
- 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.
- 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.
Operaciones
- 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.
- 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.
- 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.
Arquitectura
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.