Mecanismos de agentes de IA autorreaprendientes

Con sistemas inteligentes uno puede clonarse a sí mismo o, al menos, reducir considerablemente su carga de trabajo. Estoy trasteando ahora mismo con mi propio sistema para empleados virtuales de IA automáticos. A propósito, no he mirado ningún sistema existente para poder pensarlo desde cero.
Más adelante echaré un vistazo a otros sistemas y, si procede, me inspiraré en mecanismos o funciones.

📚 Deep Research — Texto de referencia

Arquitecturas y mecanismos de agentes de IA autodidactas: concepción e implementación del sistema AutolearningAgent

El desarrollo de sistemas de inteligencia artificial atraviesa actualmente una profunda transformación estructural, considerada el mayor cambio de paradigma organizativo desde la revolución industrial y digital. Este cambio se manifiesta en el abandono de modelos generativos estáticos y reactivos en favor de arquitecturas agentivas proactivas, iterativas y persistentes. Mientras que los modelos de lenguaje clásicos reaccionan de forma determinista ante entradas aisladas, los sistemas autónomos de "Agentic AI" se caracterizan por una autonomía orientada a objetivos, razonamiento contextual y la capacidad de interactuar dinámicamente con su entorno.

El objetivo último de esta evolución es el "Lifelong Learning" — la capacidad de los sistemas de IA para optimizarse continuamente a través de experiencias, aciertos y errores, sin que los pesos del modelo subyacente deban ajustarse manualmente en costosas rondas de entrenamiento. Estos agentes autodidactas cubren el vacío entre los modelos fundacionales estáticos y los sistemas con aprendizaje continuo, reconfigurando dinámicamente sus prompts internos, su conocimiento abstraído y sus bibliotecas de herramientas mediante bucles de retroalimentación.

El presente estudio analiza los mecanismos cognitivos, algorítmicos y económicos que subyacen a estos sistemas autodidactas. A partir de ello, se deriva una arquitectura detallada para el concepto de "AutolearningAgent" — un sistema de empleados virtuales autónomos de IA basado en los pilares Dispatcher, tablero de tareas, puente de conocimiento, caja de herramientas, núcleo de empleados y ciclo de aprendizaje. Por último, se desarrollan bloques de prompt sólidos, listos para implementar de inmediato, con el fin de trasladar estos conceptos teóricos a la práctica del sistema.

1. Fundamentos teóricos de la evolución de agentes

La capacidad de un agente para mejorar con el tiempo mediante prueba y error requiere mucho más que simplemente ampliar la ventana de contexto de un modelo de lenguaje. La acumulación no estructurada de historiales de conversación conduce inevitablemente a la degradación de la señal, mayores latencias y costes de inferencia que crecen exponencialmente. La verdadera autoevolución exige, en cambio, la construcción de arquitecturas cognitivas que orquesten de manera sistemática la percepción, la reflexión y la consolidación de la memoria.

1.1 Dimensiones de la autoevolución

La evolución de los agentes puede categorizarse a lo largo de distintas dimensiones para hacer comprensibles los mecanismos subyacentes. En principio, se distingue entre la evolución en tiempo de ejecución (Intra-test-time) y la evolución entre ejecuciones (Inter-test-time). La evolución Intra-test-time abarca procesos adaptativos que tienen lugar durante la propia ejecución de la tarea, como la corrección inmediata de errores tras una llamada a una API fallida. La evolución Inter-test-time, por su parte, describe el aprendizaje asíncrono a lo largo del ciclo de vida del agente, en el que las experiencias de tareas pasadas se abstraen y se generalizan para desafíos futuros similares.

En la práctica, esta evolución afecta principalmente a cuatro componentes centrales del sistema de agentes :

Contexto y memoria: La adaptación dinámica de la información disponible para el agente, con el fin de evitar el olvido catastrófico y maximizar la relevancia de los datos recuperados.
Herramientas (Tools): La creación, refinamiento y modificación autónomos de código ejecutable o rutinas de API basados en señales de interacción verificables.
Arquitectura: La optimización de las estructuras de colaboración en sistemas multiagente, incluida la asignación dinámica de roles y los protocolos de comunicación.
Modelo: La actualización de los comportamientos mediante mecanismos de auto-recompensa o aprendizaje por refuerzo en contexto.

1.2 La arquitectura cognitiva de memoria en tres niveles

Un error fundamental en el diseño de los primeros sistemas de agentes consistía en asumir que una única base de datos vectorial bastaba como memoria universal. Sin embargo, la investigación en ciencias cognitivas demuestra que un almacenamiento tan indiferenciado conduce a la pérdida del contexto temporal y perjudica gravemente la escalabilidad. Por ello, los agentes modernos autodidactas implementan una arquitectura de memoria multinivel, inspirada en la neurobiología humana y dividida en memoria de trabajo, episódica, semántica y procedimental.

Tipo de memoria	Función cognitiva y contenido	Arquitectura e implementación técnica
Memoria de trabajo (corto plazo)	Almacenamiento temporal del contexto conversacional actual, los objetivos inmediatos y la gestión del estado durante una tarea en curso.	Memoria en RAM, Redis o ventanas de contexto directas del LLM. Se vacía o consolida al finalizar la tarea.
Memoria episódica	Registro de experiencias específicas, acontecimientos cronológicos, trayectorias de interacción, llamadas a herramientas y mensajes de error resultantes.	Bases de datos vectoriales vinculadas a bases de datos de series temporales (p. ej., PostgreSQL Hypertables) para admitir consultas de rango temporal.
Memoria semántica	Conocimiento factual abstraído y específico del dominio, metadatos, políticas empresariales y preferencias de usuario extraídas, desvinculadas de eventos aislados.	Grafos de conocimiento para representar lógica relacional, combinados con bases de datos vectoriales para embeddings conceptuales y búsqueda semántica.
Memoria procedimental	Acción operativa, lógica de ejecución, procedimientos operativos estándar (SOP), habilidades desarrolladas y bibliotecas de código verificadas.	Bases de datos relacionales para flujos de trabajo estructurados y scripts deterministas, complementados por árboles de sintaxis abstracta (AST).

El fenómeno real del "aprendizaje" en el sentido de la evolución de un sistema se manifiesta a través del proceso de consolidación. Los recuerdos episódicos en bruto son útiles para la recuperación directa, pero en sistemas grandes se vuelven rápidamente costosos de explorar. Por ello, estos datos pasan por canales asíncronos de destilación. Un agente, por ejemplo, analiza el registro episódico de una semana de trabajo, detecta patrones (p. ej., "El usuario corrige sistemáticamente el formato de fecha en las consultas a la base de datos de MM-DD-YYYY a YYYY-MM-DD") y extrae de ello una regla semántica generalizable. Si esta regla se aplica con éxito en varias ocasiones, el sistema puede almacenarla como un flujo de trabajo procedimental fijo, automatizando así la ejecución y sin requerir ya esfuerzo cognitivo del LLM.

Arquitecturas como Synapse mejoran además esta recuperación mediante conceptos de dinámica cognitiva. En lugar de búsquedas vectoriales planas, utilizan grafos en los que la relevancia se determina mediante "Spreading Activation" (activación propagada) y "Lateral Inhibition" (inhibición lateral). Esto permite al sistema resaltar dinámicamente subgrafos relevantes y, al mismo tiempo, filtrar interferencias o alucinaciones.

1.3 Mecanismos de reflexión y corrección de errores

Un sistema de IA reactivo suele fallar porque, tras un error, repite exactamente en la siguiente iteración el mismo enfoque erróneo. Falta el bucle sistemático de retroalimentación que vincula los resultados con las decisiones futuras. Para corregir esta deficiencia, las arquitecturas autodidactas recurren a mecanismos de autocrítica explícita y refuerzo verbal (Verbal Reinforcement), tal como se definen en el marco Reflexion.

Reflexion permite a los agentes aprender por prueba y error sin necesidad de un costoso ajuste fino de los parámetros del modelo. El proceso, que adapta el bucle OODA (Observe, Orient, Decide, Act) de la estrategia militar, se desarrolla en fases iterativas :

Acción (Actor): El agente genera una propuesta de solución o ejecuta una acción en el entorno (p. ej., escribir un script de Python o hacer una llamada a una API).
Evaluación (Evaluator): Se evalúa la trayectoria. Esto puede hacerse mediante funciones heurísticas deterministas (p. ej., mensajes de error del compilador, códigos de estado HTTP) o mediante un juez LLM especializado que comprueba la exactitud factual, la coherencia lógica y la consistencia semántica del resultado.
Autorreflexión (Reflector): En caso de fallo, el LLM genera un resumen lingüístico detallado sobre qué salió mal y por qué. Este texto funciona como un gradiente semántico: proporciona una dirección concreta para la optimización dentro del espacio semántico de alta dimensión de las posibles respuestas.
Integración y reintento: Esta reflexión textual se almacena en la memoria episódica a corto plazo y se presenta al agente en la siguiente pasada como contexto ("Self-Hint"), con el fin de evitar específicamente el error identificado.

Este principio se diferencia aún más en Intra-Reflection (evaluación preventiva antes de ejecutar una acción, similar a la simulación mental) e Inter-Reflection (análisis post-hoc después de un fallo). Combinando ambos enfoques en marcos como MIRROR, los agentes pueden anticipar errores y evitar cambios irreversibles en el sistema.

1.4 Abstracción de reglas y síntesis de habilidades

La mejora duradera de una red de agentes requiere pasar de la corrección situacional de errores (Reflexion) a la extracción global de reglas. Sistemas como ReUseIt o AgentRx sintetizan flujos de trabajo reutilizables a partir de trazas de ejecución históricas.

Un agente de extracción especializado realiza para ello análisis por lotes sobre tareas recién finalizadas. Utiliza lógica contrastiva para comparar trayectorias exitosas con ejecuciones fallidas. Si el agente descubre que una búsqueda web siempre falla cuando un determinado elemento CSS no se ha cargado por completo, formula una heurística abstraída. Esta se transforma en comprobaciones de condiciones ejecutables (Execution Guards) y se integra en la memoria semántica o procedimental.

Este principio de ampliación procedimental alcanza su punto culminante en el paradigma Voyager, desarrollado originalmente para el mundo abierto de Minecraft. Voyager utiliza el código como espacio de acción. Cuando el agente aprende, mediante prueba y error, a extraer un recurso complejo, abstrae esa secuencia de acciones, la convierte en una función parametrizada de JavaScript o Python y la guarda en una "Skill Library" (caja de herramientas) en continuo crecimiento. El sistema se programa, de facto, a sí mismo. Si más adelante el agente se enfrenta a una tarea nueva y compleja, no tiene que empezar desde cero, sino que recupera de su biblioteca los bloques de código relevantes y verificados y los encadena. Este enfoque resuelve el problema del olvido catastrófico y fomenta un aprendizaje exponencial y composicional.

2. Orquestación económica: conciencia de presupuesto y eficiencia de costes

Mientras las capacidades cognitivas de los sistemas multiagente aumentan rápidamente, las implementaciones prácticas revelan una debilidad crítica: costes de inferencia desbocados e imprevisibles. La suposición de que más llamadas a LLM conducen inevitablemente a mejores resultados resulta a menudo ser errónea en entornos complejos. Si los agentes no disponen de una comprensión inherente de los límites de recursos, tienden a atascarse en llamadas redundantes a herramientas, bucles infinitos de depuración o una búsqueda excesiva de información.

2.1 Escalado en tiempo de prueba bajo restricciones

El concepto de "Test-Time Scaling" busca aumentar el rendimiento de los LLM en tiempo de inferencia mediante un mayor razonamiento (p. ej., Chain-of-Thought, Tree of Thoughts). Sin embargo, para los sistemas agentivos que operan con herramientas externas, esto no solo significa generar más tokens durante más tiempo, sino también ejecutar acciones reales (llamadas a APIs, consultas a bases de datos) que son costosas y añaden latencia. Un simple aumento del límite de llamadas a herramientas a menudo conduce a un estancamiento del rendimiento, porque los agentes, sin conciencia económica, profundizan demasiado en rutas irrelevantes.

Para abordar este problema, el concepto de "Budget-Awareness" adquiere protagonismo. Marcos como BATS (Budget Aware Test-time Scaling) o BAVT (Budget-Aware Value Tree) dotan al agente de un rastreador de presupuesto que supervisa continuamente el consumo de tokens y llamadas a herramientas. Esta conciencia continua cambia drásticamente el comportamiento del agente:

Exploración dinámica frente a explotación: Mientras los recursos sean abundantes, el sistema anima al agente a realizar una búsqueda amplia y exploratoria de distintas soluciones. Cuando el presupuesto disminuye, el mecanismo matemático obliga al agente a detener la exploración y pasar al modo de "exploitation" (explotación). Debe priorizar la ruta más prometedora hasta el momento y sintetizar una respuesta final antes de que se agoten los recursos.
Estimación de valor a nivel de paso: Para evitar que el sistema se deje llevar por la típica sobreconfianza del LLM, los agentes críticos evalúan tras cada paso el progreso relativo (Residual Value Prediction) en lugar de la calidad absoluta. Así pueden podarse pronto las rutas no informativas, ahorrando presupuesto.

Los estudios empíricos demuestran que los sistemas agentivos con una gestión estricta y consciente del presupuesto superan de forma significativa a los enfoques de escalado descontrolado, incluso cuando solo disponen de una fracción de los recursos de computación.

2.2 Enrutamiento de modelos con conciencia de coste

Otra palanca decisiva para optimizar costes es el enrutamiento dinámico de modelos. Es económicamente ineficiente utilizar el modelo frontier más potente y caro (p. ej., GPT-4o, Claude 3.5 Sonnet) para tareas triviales como formateos, clasificaciones simples o el resumen de textos breves.

Por ello, las arquitecturas modernas implementan una capa de decisión o enrutamiento (p. ej., mediante programación lineal entera en marcos como BAMAS) que calcula antes de cada ejecución el equilibrio óptimo entre inteligencia requerida y coste.

Las tareas simples y deterministas se enrutan hacia modelos más baratos (p. ej., GPT-3.5, Claude Haiku, Llama 3 8B).
Las tareas complejas de planificación y programación de varios pasos se delegan a modelos premium.
Un patrón de "Confidence-based Escalation" permite que un modelo barato inicie una tarea y la escale a un modelo más caro en cuanto detecta incertidumbres o errores repetidos.

Este enfoque requiere una observabilidad integral a nivel de inferencia, ya que el sistema no puede tomar decisiones de enrutamiento fundamentadas sin datos de telemetría.

3. Arquitectura del sistema AutolearningAgent

Basándose en los paradigmas teóricos de consolidación de la memoria, reflexión verbal, evolución procedimental de habilidades y estricta conciencia de presupuesto, puede derivarse ahora una especificación de alta resolución para el "AutolearningAgent". Este sistema se libera de la limitación de sesiones de chat aisladas y opera, en su lugar, como un ciclo asíncrono y autorreferencial.

El sistema se estructura en seis pilares funcionales que interactúan de forma permanente y se optimizan mutuamente.

3.1 El metrónomo (Dispatcher)

El Dispatcher actúa como el sistema nervioso central, que a la vez es enrutador de eventos, gestor de recursos e instancia de enrutamiento. No realiza por sí mismo trabajo de pensamiento sustantivo, sino que garantiza la estabilidad operativa y la economía del sistema.

Orquestación guiada por eventos (Event-Driven Architecture): El Dispatcher está vinculado a distintos disparadores. En lugar de permanecer continuamente en un bucle de sondeo que consume muchos recursos, se activa de forma asíncrona por eventos externos (p. ej., entrada de correo electrónico, webhooks de API, nuevos archivos en un almacenamiento en la nube o trabajos cron programados).
Gestión y asignación de presupuesto: En cuanto un evento define un objetivo (p. ej., "Analiza el nuevo informe financiero"), el Dispatcher evalúa el presupuesto diario disponible, que puede crecer dinámicamente por factores externos (ventas, donaciones). Descompone el objetivo principal en subtareas y asigna a cada empleado virtual un límite estricto de recursos (en tokens o USD).
Enrutamiento dinámico de modelos: En función de la complejidad de la subtarea, el Dispatcher decide qué LLM base se carga en el núcleo del empleado. Las tareas estándar reciben modelos eficientes pero baratos; las tareas de análisis críticas se derivan a los modelos más caros.
Lógica de activación y control del ciclo de vida: El Dispatcher supervisa las dependencias y activa a un empleado de IA solo cuando se cumplen todos los requisitos previos (p. ej., la finalización de la fase de investigación por otro agente).

3.2 El tablero de tareas (State & Task Management)

El tablero de tareas sustituye la efímera pestaña del terminal por un control de estado persistente, tipo Kanban. Es la fuente única de verdad para el estado operativo de toda la red multiagente.

Modelo de visualización centrado en objetivos: Las unidades de trabajo no se definen como conversaciones, sino como objetivos concretos (Goals) con estados estructurados (p. ej., Queued, In Progress, Needs Review, Blocked, Done).
Delegación distribuida y protocolos de handoff: Cuando un empleado especializado (p. ej., el analista de datos) completa su subtarea, genera una salida JSON legible por máquina con artefactos, estado y niveles de confianza. El tablero de tareas transmite esta carga útil sin fricción al siguiente empleado (p. ej., el redactor del informe) como instrucción inicial.
Prevención de fallos en cascada (Fail-Loud-Design): Los agentes autónomos tienden a producir errores silenciosos, en los que un resultado intermedio incorrecto conduce inadvertidamente a un resultado final catastrófico. El tablero de tareas implementa "Execution Guards". Si un agente detecta una incoherencia o un fallo de la API, cambia el estado inmediatamente a Blocked y documenta el obstáculo. A continuación, el tablero detiene la cascada, aísla el error y, en caso necesario, recurre a un supervisor humano para su autorización (Human-in-the-Loop).

3.3 El puente de conocimiento (interfaz de contexto)

El puente de conocimiento es la implementación del "Second Brain". Evita el fenómeno de la amnesia del agente y garantiza que el sistema se vuelva más inteligente contextualemente con cada interacción.

Agentic RAG (Retrieval-Augmented Generation): A diferencia de los sistemas RAG tradicionales, que insertan documentos en el prompt de forma rígida y acrítica, el puente de conocimiento actúa de manera autónoma. Los agentes formulan por sí mismos consultas a su memoria semántica y episódica, filtran la información redundante y estructuran el contexto relevante para la tarea en curso.
Arquitectura de memoria híbrida: El puente de conocimiento combina bases de datos vectoriales (para búsquedas de similitud conceptual entre documentos) con bases de datos de grafos (para representar relaciones explícitas entre personas, proyectos y entidades).
Consolidación y "Forgetting": Para no superar los límites de la ventana de contexto y ahorrar costes, el puente de conocimiento realiza optimizaciones periódicas (p. ej., trabajos batch nocturnos). Lee los registros episódicos de los agentes, extrae de ellos nuevos hechos semánticos o preferencias de usuario, los almacena y archiva las conversaciones obsoletas o redundantes.

3.4 La caja de herramientas (base de datos de habilidades)

La caja de herramientas traduce el concepto de memoria procedimental y el paradigma Voyager a la arquitectura del AutolearningAgent.

Abstracción modular: En lugar de equipar a los agentes con cientos de herramientas estáticas —lo que sobrecarga la ventana de contexto con un "Tool Soup" y genera enormes explosiones de costes—, la caja de herramientas gestiona las habilidades de forma modular.
Asignación dinámica: Un empleado de IA toma prestado para una tarea específica solo el subconjunto de herramientas que necesita. El Dispatcher o el propio agente cargan las definiciones de funciones relevantes en el contexto de trabajo activo solo cuando hacen falta.
Evolución de habilidades: El sistema no se limita a APIs predefinidas. Si un agente, mediante razonamiento e iteración, completa con éxito un flujo de trabajo complejo (p. ej., la limpieza multinivel de un conjunto de datos concreto), solicita al ciclo de aprendizaje que abstraiga esa secuencia como un nuevo bloque de código ejecutable (Skill). Esta habilidad se persiste en la caja de herramientas y queda a disposición de todo el sistema como una macroherramienta altamente eficiente.

3.5 El núcleo del empleado (lógica de decisión)

El núcleo del empleado es la sala de máquinas cognitiva en la que se ejecuta la lógica ReAct (Reasoning and Acting). Aquí, el modelo de lenguaje en bruto se transforma en un actor disciplinado mediante "Context Engineering" estructurado.

Bucle ReAct: Antes de que el agente ejecute una acción (p. ej., escribir código, llamar a una API), su prompt de sistema le obliga a exteriorizar su proceso de pensamiento (Observation -> Thought -> Action -> Result). Esto fuerza al modelo a adoptar un pensamiento cuidadoso de "Sistema 2" y reduce las alucinaciones.
Higiene del contexto: Dado que las interacciones largas provocan deriva de contexto, el núcleo comprime continuamente sus salidas de herramientas y descarta pasos intermedios que ya no se necesitan. Se centra en la densidad de señal para mantener bajas la latencia y los costes de tokens.
Evitar la complacencia (sycophancy): El núcleo está entrenado mediante prompts defensivos para informar activamente de premisas erróneas o datos faltantes, en lugar de adivinar a ciegas ("Sycophancy"). Ante ambigüedades, el agente escala el problema al tablero de tareas, en lugar de fabricar resultados incorrectos.

3.6 El ciclo de aprendizaje (reflexión y optimización)

El ciclo de aprendizaje es el núcleo del autolearning. Transforma los resultados binarios (éxito/fracaso) en sabiduría textual y asegura la escalabilidad a largo plazo de la inteligencia del sistema.

Análisis de trazas y análisis de causa raíz: Tras la finalización o cancelación de una tarea, un agente evaluador independiente y de alta inteligencia examina los registros de ejecución (traces) del núcleo del empleado. Realiza un análisis de causas para determinar por qué falló un agente (p. ej., parámetros incorrectos, contexto ausente, uso ineficiente de herramientas).
Refuerzo verbal (Reflexion): El evaluador formula consejos concretos, basados en texto, sobre cómo evitar el error en el futuro.
Generación de Execution Guards: Estos consejos no permanecen como texto no estructurado, sino que se traducen en reglas de ejecución reutilizables (Execution Guards) o en precondiciones y postcondiciones (Pre/Post-Conditions). El ciclo de aprendizaje guarda estos nuevos aprendizajes en el puente de conocimiento o como una actualización en la caja de herramientas, de modo que todo el equipo de IA sea inmune a ese tipo específico de error la próxima vez que se enfrente a un problema similar.

4. Context Engineering: principios para sistemas autónomos

Para operacionalizar la arquitectura descrita, la creación de prompts debe pasar de la tradicional "programación de prompts" al "Context Engineering".

La instrucción de un agente difiere fundamentalmente de la de un chatbot. Un prompt de chatbot solicita una única respuesta aislada. Un prompt de agente, en cambio, inicia un proceso de varios pasos que abarca decisiones secuenciales, llamadas a herramientas, gestión de errores y control de presupuesto a lo largo de un periodo prolongado. El objetivo principal del Context Engineering es maximizar en cada paso iterativo el presupuesto de atención fuertemente limitado del modelo de lenguaje (la densidad de señal), minimizando al mismo tiempo los datos de registro irrelevantes o las instrucciones desmesuradas ("Instruction Bloat").

Los prompts de agentes exitosos en entornos de producción presentan una arquitectura altamente estructurada, a menudo dividida en etiquetas XML o Markdown. Esta estructura garantiza que el modelo pueda interpretar con claridad su papel, los datos de contexto disponibles, las reglas de comportamiento estrictas y las condiciones de parada.

Los siguientes principios de diseño (Best Practices) sustentan los bloques de prompt que se presentan a continuación:

Instrucciones defensivas: Definición de estrategias explícitas de gestión de errores (p. ej., "Si la búsqueda no arroja resultados tras 3 intentos, no inventes hechos, sino informa: STATUS: BLOCKED").
Separación clara de la cognición (ReAct): Instrucción explícita al modelo para que separe estrictamente sus razonamientos ("Thought") de sus acciones ("Action"), con el fin de garantizar la trazabilidad lógica para el ciclo de aprendizaje.
Límites económicos (Budget-Awareness): Implementación de umbrales matemáticos directamente en el prompt del sistema para forzar el cambio de exploración a explotación.

5. Bloques de prompt concretos para la integración del sistema

Los siguientes cuatro bloques de prompt representan la base técnica para implementar el AutolearningAgent. Están redactados en sintaxis estructurada XML/Markdown y diseñados para ser rellenados dinámicamente en tiempo de ejecución mediante la orquestación de la arquitectura con variables (entre llaves {}).

5.1 Bloque de prompt 1: El metrónomo (Dispatcher & Router)

Este prompt controla el "sistema nervioso". La llamada al LLM suele ser breve y puede ser ejecutada por un modelo rápido y económico. El objetivo es la clasificación pura, la gestión del presupuesto y el enrutamiento.

XML

# System-Prompt: AutolearningAgent Dispatcher

<system_identity>
Eres el DISPATCHER del sistema AutolearningAgent. Eres el órgano de control central y el gestor económico de recursos. NO eres responsable de resolver tareas de contenido, escribir código ni realizar investigaciones.
Tu única función consiste en analizar eventos entrantes, distribuir presupuestos de trabajo y derivar las tareas a los empleados virtuales especializados (Worker Core) en el tablero de tareas.
</system_identity>

<current_system_state>
- Presupuesto diario disponible del sistema: {daily_budget_remaining_usd} USD
- Roles de agentes activos: {available_agent_roles}
- Carga actual del sistema: {system_load_metrics}
</current_system_state>

<incoming_event>
- Fuente: {event_source}
- Contenido/consulta del usuario: {event_payload}
</incoming_event>

<operating_procedures>
Al procesar el evento entrante, realiza exactamente los siguientes pasos:
1. **Análisis del evento:** Evalúa la complejidad de la solicitud. ¿Se trata de un formateo de datos trivial o de una tarea lógica compleja y multinivel?
2. **Gestión de costes (Budgeting):** Asigna a esta tarea un límite de coste estricto. Usa el nivel de coste "LOW" (asignación a modelos de bajo consumo de recursos) para tareas sencillas y "HIGH" (asignación a modelos frontier de alto rendimiento) para tareas críticas. El límite asignado nunca debe superar {max_task_budget_threshold} USD.
3. **Delegación al empleado:** Identifica el rol de agente más adecuado de entre los {available_agent_roles} y prepara la entrada para el tablero de tareas.
</operating_procedures>

<constraints>
- PROHIBIDO: Nunca ejecutes llamadas a herramientas para resolver el problema de contenido.
- PROHIBIDO: No inventes roles de agente que no figuren en {available_agent_roles}.
- ESCALADA: Si el presupuesto diario no es suficiente, establece el estado en "BLOCKED_BUDGET".
</constraints>

<output_schema>
Tu salida DEBE ser un objeto JSON validado, sin bloques de código Markdown adicionales, que refleje exactamente el siguiente esquema:
{
  "event_classification": "Breve justificación del análisis",
  "routing_decision": {
    "assigned_role": "",
    "model_tier": ""
  },
  "budget_allocation": {
    "cost_limit_usd": 0.00,
    "max_tool_calls": 0
  },
  "task_payload": {
    "objective": "Objetivo final inequívoco y orientado a la acción para el empleado",
    "context_keywords":
  }
}
</output_schema>

5.2 Bloque de prompt 2: El núcleo del empleado (Worker Agent con ReAct)

Este bloque define al agente ejecutor. Contiene mecanismos para el razonamiento estructurado (ReAct), la protección frente a la "Sycophancy" (adaptación excesiva) y el cumplimiento de los límites de presupuesto establecidos por el Dispatcher.

XML

# System-Prompt: AutolearningAgent Worker Core

<system_identity>
Eres un empleado virtual autónomo en el sistema AutolearningAgent. 
Tu especialización es: {assigned_role}.
Tu objetivo principal es cumplir la tarea asignada de forma metódica, sin errores y dentro de las estrictas restricciones presupuestarias.
</system_identity>

<task_context>
- Tu tarea: {objective}
- Contexto recuperado del puente de conocimiento (Second Brain): {semantic_knowledge_context}
- Herramientas asignadas (base de datos de habilidades): {available_tools_json}
</task_context>

<budget_and_constraints>
ATENCIÓN LÍMITE ECONÓMICO: Puedes usar como máximo {max_tool_calls} llamadas a herramientas para esta tarea.
- Llamadas realizadas hasta ahora: {current_tool_call_count}
- Llamadas restantes: {remaining_tool_calls}

LÓGICA DE CONCIENCIA DE PRESUPUESTO:
- Si {remaining_tool_calls} >= 3: estás en "Exploration Mode". Explora sistemáticamente las vías de solución.
- Si {remaining_tool_calls} < 3: estás en "Exploitation Mode". Interrumpe las investigaciones abiertas. Usa los datos ya recopilados para generar la mejor respuesta posible y fundamentada antes de agotar el presupuesto.
</budget_and_constraints>

<learned_heuristics>
El sistema ha aprendido de errores pasados. Atiende obligatoriamente a las siguientes reglas procedimentales provenientes del ciclo de aprendizaje:
{historical_execution_guards}
</learned_heuristics>

<reasoning_protocol>
Trabajas estrictamente según el paradigma ReAct (Reasoning and Acting). 
1. Cuestiona la premisa: si falta contexto o las herramientas devuelven errores, no adivines (sin alucinaciones). Informa de un error.
2. Planifica por pasos: razona en voz alta antes de llamar a una herramienta.
</reasoning_protocol>

<execution_format>
Genera siempre tu salida exactamente en el siguiente formato:

THOUGHT:

ACTION:
ACTION_INPUT:
</execution_format>

5.3 Bloque de prompt 3: Tablero de tareas y puente de conocimiento (State & Memory Consolidation)

Este prompt se ejecuta cuando un agente trabajador ha completado una tarea (FINAL_ANSWER). Sirve para la gestión del estado y la extracción de conocimiento para el Segundo Cerebro (transición de memoria episódica a semántica).

XML

# System-Prompt: Board Manager & Memory Consolidator

<system_identity>
Eres el STATE MANAGER y KNOWLEDGE ARCHIVIST del sistema AutolearningAgent.
Evalúas los resultados finales de los empleados, mantienes el estado en el tablero de tareas y extraes conocimiento relevante a largo plazo para la memoria semántica (puente de conocimiento).
</system_identity>

<execution_result>
- Tarea original: {objective}
- Agente ejecutor: {assigned_role}
- Salida final del agente: {agent_final_answer}
</execution_result>

<operating_procedures>
1. **Evaluar el estado del tablero:** Comprueba si la {agent_final_answer} cumple por completo el objetivo original {objective}.
2. **Lógica de handoff:** Determina si el resultado marca el final del proceso global o si debe activarse un agente posterior (p. ej., corrección de estilo tras la investigación).
3. **Extracción de conocimiento (Semantic Memory):** Lee la salida del agente. Aísla hechos, preferencias del usuario, credenciales o conocimiento conceptual que resulte valioso de forma permanente para el "Segundo Cerebro" del usuario, más allá de esta tarea aislada.
</operating_procedures>

<output_schema>
Devuelve exclusivamente un objeto JSON:
{
  "board_update": {
    "task_status": "",
    "requires_handoff": true/false,
    "next_agent_role_needed": null,
    "handoff_payload": "Resumen para el siguiente agente, si procede."
  },
  "semantic_memory_extraction": [
    {
      "entity_name": "Nombre de la persona, proyecto o concepto",
      "fact_description": "Afirmación formulada con claridad y de validez duradera",
      "confidence_score": 0.9
    }
  ]
}
</output_schema>

5.4 Bloque de prompt 4: El ciclo de aprendizaje (Reflector & Rule Extractor)

Este prompt controla el verdadero "Autolearning". Analiza de forma asíncrona en segundo plano las trazas de ejecución históricas, identifica las causas de los errores (Root Cause Analysis) y sintetiza nuevas reglas de ejecución (Execution Guards) o propone nuevas habilidades (Skills) para la caja de herramientas.

XML

# System-Prompt: Autolearning Reflector & Rule Extractor

<system_identity>
Eres el REFLECTOR y RULE EXTRACTOR, el núcleo cognitivo del proceso de Autolearning.
Analizas el cuaderno episódico (Execution Traces) de tareas pasadas para detectar ineficiencias, diagnosticar errores y generar reglas de comportamiento abstractas y reutilizables para el futuro. Desarrollas el sistema sin modificar el código de los LLM.
</system_identity>

<episodic_memory_trace>
- ID de tarea: {task_id}
- Presupuesto asignado: {budget_assigned} | Presupuesto consumido: {budget_consumed}
- Éxito/fracaso: {task_outcome_status}
- Registro de ejecución (pensamientos, acciones, códigos de error):
{full_execution_trace}
</episodic_memory_trace>

<analysis_protocol>
Realiza un análisis profundo de causa raíz (Root-Cause-Analysis) a partir de las trazas:
1. **Diagnóstico de herramientas:** ¿Hubo llamadas a API que fallaron repetidamente (p. ej., HTTP 400/429)? ¿El agente resolvió esos errores de forma constructiva o los repitió de manera mecánica?
2. **Anomalías cognitivas:** ¿Hubo saltos lógicos, alucinaciones o "Context Loss" durante trayectorias largas?
3. **Reconocimiento de patrones (Contrastive Analysis):** Si la tarea falló, ¿cuál fue el punto crítico de inflexión? Si tuvo éxito, ¿hubo una combinación de herramientas especialmente eficiente?
</analysis_protocol>

<rule_synthesis>
Abstrae tus hallazgos en "Execution Guards" (reglas de ejecución) para todo el sistema. Las reglas deben basarse en condiciones (SI, ENTONCES [acción]).
Ejemplo: SI una consulta a la base de datos devuelve vacío, ENTONCES verifica las mayúsculas y minúsculas de los términos de búsqueda antes de informar de que no hay datos.
</rule_synthesis>

<output_schema>
Tu salida DEBE ser un documento JSON válido:
{
  "diagnostic_report": {
    "root_cause_of_failures": "Análisis de las causas de los errores (si los hay)",
    "efficiency_evaluation": "Evaluación del uso del presupuesto"
  },
  "extracted_execution_guards":
    }
  ],
  "new_skill_proposal": {
    "propose_new_skill": true/false,
    "skill_description": "Si se identifica una secuencia compleja y recurrente de llamadas a herramientas, descríbela aquí para que pueda incorporarse como un script ejecutable en la caja de herramientas (Skill Library)."
  }
}
</output_schema>

6. Análisis de errores, seguridad y perspectivas

Con la implementación de mecanismos de autolearning y la capacidad de los agentes para generar sus propias reglas (y potencialmente su propio código mediante el paradigma Voyager), aumentan de forma significativa los requisitos de estabilidad y seguridad del sistema.

Uno de los retos centrales consiste en la detección de anomalías dentro de las trazas de ejecución. Dado que los agentes actúan de forma probabilística, los métodos tradicionales de prueba de software solo pueden aplicarse de manera limitada. Los fallos silenciosos (Silent Failures) — en los que un agente incurre en una cascada de errores lógicos que solo se hacen visibles por sus efectos al final del flujo de trabajo — requieren la implementación de marcos de fuzzing guiados por comportamiento (p. ej., ABTest), que confronten sistemáticamente al sistema con casos límite para descubrir vulnerabilidades. Además, la prevención de la "Sycophancy" (la tendencia del modelo a asentir ciegamente a premisas erróneas del usuario) en dominios sensibles debe impedirse obligatoriamente mediante contra-prompts explícitos.

Las futuras iteraciones de los sistemas Autolearning dependerán cada vez más de una interconexión todavía más estrecha de las memorias multiagente. El desafío consistirá en mantener la coherencia de la memoria compartida basada en grafos (Shared Graph Memory), mientras agentes descentralizados consolidan simultáneamente, de forma asíncrona, hechos y reglas procedimentales procedentes de sus ciclos de aprendizaje individuales. La arquitectura del AutolearningAgent proporciona para ello una base escalable, consciente del presupuesto y autocorrectiva.

mckinsey.com

La organización agentiva: Un nuevo modelo operativo para la IA | McKinsey

Mecanismos de agentes de IA autorreaprendientes

⚡Lo más importante

Arquitecturas y mecanismos de agentes de IA autodidactas: concepción e implementación del sistema AutolearningAgent

1. Fundamentos teóricos de la evolución de agentes

1.1 Dimensiones de la autoevolución

1.2 La arquitectura cognitiva de memoria en tres niveles

1.3 Mecanismos de reflexión y corrección de errores

1.4 Abstracción de reglas y síntesis de habilidades

2. Orquestación económica: conciencia de presupuesto y eficiencia de costes

2.1 Escalado en tiempo de prueba bajo restricciones

2.2 Enrutamiento de modelos con conciencia de coste

3. Arquitectura del sistema AutolearningAgent

3.1 El metrónomo (Dispatcher)

3.2 El tablero de tareas (State & Task Management)

3.3 El puente de conocimiento (interfaz de contexto)

3.4 La caja de herramientas (base de datos de habilidades)

3.5 El núcleo del empleado (lógica de decisión)

3.6 El ciclo de aprendizaje (reflexión y optimización)

4. Context Engineering: principios para sistemas autónomos

5. Bloques de prompt concretos para la integración del sistema

5.1 Bloque de prompt 1: El metrónomo (Dispatcher & Router)

5.2 Bloque de prompt 2: El núcleo del empleado (Worker Agent con ReAct)

5.3 Bloque de prompt 3: Tablero de tareas y puente de conocimiento (State & Memory Consolidation)

5.4 Bloque de prompt 4: El ciclo de aprendizaje (Reflector & Rule Extractor)

6. Análisis de errores, seguridad y perspectivas

❓ Preguntas frecuentes

¿Qué son los agentes de IA que aprenden por sí mismos?

¿Cómo aprenden los agentes de IA de la experiencia?

¿Por qué no basta con un almacén vectorial como memoria para los agentes de IA?

¿Qué papel desempeña la memoria en los agentes de IA que aprenden por sí mismos?

¿Cómo está estructurado el AutolearningAgent?

Seguir leyendo

Barrierefreiheit per KI: Der Vibe-Coding Skill

Guía de peces de Paraguay - ¿Qué hay y qué tan bueno es?

Guía de la carne en Paraguay: cómo aprovechar cada parte

💬 Comentarios

Escribir un comentario