Capítulo 8: La Evolución Continua del Agente

Los Agentes actuales se enfrentan a una clara paradoja de capacidad: pueden resolver tareas complejas nunca antes vistas en modo zero-shot, pero tras procesar diez mil tareas similares, al día siguiente pueden seguir cometiendo los mismos errores del primer día. La capacidad de aprender de forma autónoma a partir de la experiencia se está convirtiendo en la competencia clave para que un Agente pase de "ser capaz de completar tareas" a "poder trabajar de manera confiable", siendo además un tema de investigación central para la próxima generación de modelos. Sin embargo, la capacidad de aprendizaje continuo del modelo en sí sigue siendo muy insuficiente.

La razón radica en que un modelo desplegado no modifica automáticamente sus parámetros tras una inferencia. El aprendizaje en contexto, el mantenimiento de estado y la compresión discutidos en el Capítulo 2 permiten que el Agente se adapte dentro de la tarea actual; no obstante, una vez finalizado el contexto, esos cambios no se trasladan de forma natural a la siguiente tarea. Almacenar conversaciones en la memoria tampoco equivale a aprender nuevos comportamientos: las trayectorias originales pueden ser largas y contener tanto estrategias efectivas como éxitos fortuitos, atribuciones erróneas e entradas no confiables.

Existe una distinción que suele causar confusión: guardar experiencias no es lo mismo que aprender de ellas. Colocar cien trayectorias en un contexto largo o en una base de datos vectorial ayuda a que el modelo recupere un caso cuando lo necesite, pero no realiza automáticamente una comparación entre casos: qué pasos se repiten en las trayectorias exitosas, qué prácticas solo funcionaban en versiones antiguas de las interfaces, o si un éxito particular derivó de una estrategia correcta o de la casualidad del entorno. El aprendizaje ocurre después de que el sistema realiza activamente la "evaluación, contraste, inducción y verificación", y no en el instante en que el registro se escribe en el disco. La memoria de usuario del Capítulo 3 consolida principalmente "cómo son el usuario y el mundo"; el aprendizaje de experiencia de este capítulo profundiza en "bajo qué condiciones se debe actuar de qué manera". La primera permite que el Agente recuerde más, mientras que el segundo hace que pase de ser inteligente a ser experto.

Entonces, ¿por qué no permitir que el modelo se entrene directamente a sí mismo tras cada tarea? Porque los entornos de producción rara vez proporcionan señales de aprendizaje limpias. Que el usuario esté satisfecho no garantiza el cumplimiento normativo, y que los tests pasen puede deberse simplemente a que se eliminaron los casos de prueba fallidos; además, una actualización local puede causar olvido de capacidades, deriva de estrategia o degradación de seguridad. Si se permite que un modelo en ejecución modifique directamente sus parámetros basándose en retroalimentación no verificada, las experiencias erróneas y la inyección de prompts podrían consolidarse y amplificarse continuamente en tareas posteriores. El entrenamiento periódico del modelo base puede mejorar las capacidades generales, pero no puede absorber a tiempo las reglas privadas, cambios de herramientas y experiencias locales con las que cada Agente se topa a diario.

Por lo tanto, mientras el modelo en sí no pueda aprender de forma continua y confiable, se debe estructurar el "aprendizaje" como un sistema autónomo periférico al modelo: registrar evidencia de ejecución, verificar resultados y procesos, extraer patrones comunes de múltiples trayectorias y decidir si se deben actualizar conocimientos, instrucciones, programas o parámetros del modelo. Todas las modificaciones forman primero versiones candidatas que, tras pasar pruebas de regresión y verificaciones de seguridad, pueden cambiar la siguiente ronda de ejecución. Esto no reemplaza la capacidad de aprendizaje del modelo, sino que constituye una ruta de ingeniería para dotar al Agente de capacidad de aprendizaje continuo bajo las condiciones tecnológicas actuales.

Los capítulos anteriores ya han presentado los componentes principales requeridos por este sistema. El Capítulo 2 aborda el estado intra-tarea, el Capítulo 3 proporciona la infraestructura de conocimiento, el Capítulo 5 otorga al Agente meta-capacidades para crear herramientas y modificar el sistema, el Capítulo 6 establece la evaluación y verificación, y el Capítulo 7 explica cómo actualizar los parámetros del modelo. La tarea de este Capítulo 8 es organizar estos componentes en el bucle cerrado de evolución continua mostrado en la Figura 8-1.

La evolución continua requiere provenir de experiencias operativas trazables, ser capaz de alterar comportamientos posteriores y contar con la verificación de que no ha provocado una degradación evidente. Este capítulo analiza primero cómo juzgar en qué acertó y en qué falló una ejecución concreta; luego compara cuatro métodos de actualización y sus límites aplicables; por último, aborda cómo estas actualizaciones se verifican, despliegan, revisan y descartan durante un funcionamiento a largo plazo.

Derivación de Señales de Aprendizaje a partir de Trayectorias Operativas

El punto de partida de la evolución continua no es el "resumen", sino la "evaluación". Si el sistema no sabe si la tarea se completó ni qué paso causó el éxito o el fracaso, la reflexión generada por el modelo de lenguaje solo será una conjetura. Una vez que una evaluación errónea ingresa en el conocimiento a largo plazo, en los prompts del sistema o en los datos de entrenamiento, su impacto se amplificará a lo largo de las tareas posteriores.

Los resultados de algunas tareas son relativamente fáciles de verificar. Un Coding Agent puede ejecutar pruebas, verificaciones de tipos y benchmarks de rendimiento; un Agente que tramita reembolsos para usuarios puede consultar el estado del pedido y el monto real reembolsado. Estas señales provienen del estado real del entorno y suelen ser más confiables que la descripción que el modelo hace de su propio comportamiento. Sin embargo, que el resultado sea correcto no significa que el proceso lo haya sido. Eliminar casos de prueba fallidos también hace que las pruebas pasen, y prometer verbalmente al usuario "le haremos el reembolso en 7 días, por favor espere con paciencia" también puede recibir una satisfacción temporal. Por ello, una evaluación confiable debe analizar tanto el resultado como la trayectoria seguida para alcanzarlo.

Muchas tareas no tienen una única respuesta correcta. Determinar si un agente de atención al cliente fue paciente, si ofreció alternativas dentro del margen normativo, si un informe de investigación captó la evidencia clave o si el texto generado es natural y conciso requiere un juicio contextual. En estos casos se puede utilizar el LLM-as-a-Judge introducido en el Capítulo 6, pero no se debe permitir que el juez emita únicamente una puntuación global vaga. Un enfoque más efectivo consiste en definir previamente una rúbrica de evaluación (Rubric), exigir que el verificador puntúe elemento por elemento, cite evidencia de la trayectoria y declare explícitamente su incertidumbre cuando la evidencia sea insuficiente.

La Figura 8-2 ilustra una estructura de verificación de tres capas. El verificador de resultados de la capa inferior lee los resultados de las pruebas, el estado de la base de datos y los retornos de las herramientas, respondiendo a la pregunta de "si el asunto realmente se completó"; el verificador de procesos de la capa intermedia comprueba las reglas de negocio, los permisos y las secuencias de acciones, respondiendo a "si se completó de la manera permitida"; el verificador de calidad de la capa superior evalúa el lenguaje y la estrategia según la Rubric, respondiendo a "si se completó de forma adecuada". Cuanto más abajo se encuentre el indicador, más debe depender del código y de la verdad de entorno, dejando al modelo de lenguaje únicamente la parte difícil de formalizar.

Tomando como ejemplo un Agente de atención al cliente, una Rubric útil debe cubrir al menos las dimensiones mostradas en la Tabla 8-1. Las primeras cinco dimensiones restringen los límites fundamentales, mientras que las últimas dos miden la calidad del servicio. Esta división ofrece mayor valor diagnóstico que "saber si el usuario está satisfecho": un usuario puede estar satisfecho porque el Agente realizó un reembolso violando las normas, o insatisfecho debido a restricciones normativas; un indicador de satisfacción único no puede distinguir entre ambos escenarios.

Tabla 8-1 Dimensiones de evaluación de trayectoria para un Agente de atención al cliente

Dimensión	Pregunta de verificación	Evidencia principal
Resultado de la tarea	¿Se resolvió la solicitud central del usuario?	Estado ambiental final, resultados de herramientas
Cumplimiento de reglas	¿Se violó alguna política, permiso o procedimiento necesario?	Repositorio de políticas, trayectoria de acciones
Límites de privacidad	¿Se divulgó información que no debía proporcionarse?	Texto de respuesta, registros de acceso a datos
Confiabilidad factual	¿Las afirmaciones cuentan con respaldo de conocimiento o herramientas?	Fuentes citadas, retornos de herramientas
Consistencia promesa-acción	¿Las operaciones que se afirmaron haber realizado ocurrieron realmente?	Cotejo de respuestas con registros de herramientas
Calidad de expresión	¿Es natural y concisa, evitando repeticiones y plantillas?	Diálogo completo, Rubric de lenguaje
Alternativas cumplidoras	Cuando el plan original no fue factible, ¿se halló una alternativa permitida?	Objetivo del usuario, políticas y acciones posteriores

Entre ellas, la "consistencia promesa-acción" es especialmente adecuada para escenarios de Agentes. La evaluación de texto tradicional solo lee la respuesta final, siendo propensa a considerar "ya he tramitado su reembolso" como un buen servicio; la evaluación de trayectoria, en cambio, verifica si realmente se invocó la herramienta de reembolso, si la llamada fue exitosa y si cambió el estado del pedido. De igual forma, las "alternativas cumplidoras" no incentivan al modelo a romper las reglas arbitrariamente, sino que le exigen comprender el objetivo real del usuario y, si el reembolso no es factible, examinar opciones legales como cambios de fecha, prórrogas o compensaciones parciales.

Los resultados de la verificación no deben comprimirse en un escalar único. La evaluación de una trayectoria se asemeja más a un diagnóstico estructurado: la tarea fue parcialmente exitosa, el cumplimiento de reglas fue aprobado, pero se detectó una declaración sin evidencia, una falsa promesa y la respuesta explicó repetidamente la política tres veces. Las señales dimensionales preservan tanto la naturaleza del problema como la ubicación de la evidencia. Esto permite que los módulos posteriores determinen si la declaración sin evidencia se debió a falta de conocimiento, ausencia de requisitos de citación o capacidad insuficiente del modelo; o si una falsa promesa requiere modificar los prompt words o agregar una verificación de consistencia entre la respuesta y el estado de la herramienta en el Harness.

El propio verificador LLM requiere calibración. Los sistemas de producción suelen preparar un pequeño conjunto de trayectorias anotadas por expertos para verificar la consistencia del verificador en cada dimensión; los casos de alto riesgo o baja confianza se derivan a un segundo modelo o a revisión humana; tras cambios de versión del modelo, se vuelve a ejecutar el conjunto de calibración. El verificador se encarga de proporcionar evaluaciones y evidencias, mientras que la decisión sobre qué parte del Agente modificar debe recaer en un módulo independiente de diagnóstico y evolución, evitando que el mismo modelo actúe como juez y reescriba directamente las reglas.

Experimento 8-1 ★★: Construir un verificador de trayectorias para un Agente de atención al cliente

Objetivo del experimento: Convertir una trayectoria de ejecución de atención al cliente en un diagnóstico estructurado utilizable para el aprendizaje posterior, y verificar si "conclusiones multidimensionales más evidencia" permiten localizar la causa raíz mejor que una puntuación global única.

Datos y proceso: El experimento prepara cuatro tipos de trayectorias etiquetadas por expertos: reembolso normal, falsa promesa, fuga de privacidad y rechazo excesivo. La primera capa lee el estado final del pedido y los registros de herramientas para determinar si el reembolso o cambio ocurrió realmente; la segunda capa coteja paso a paso las políticas del negocio, comprobando permisos, procesos necesarios, privacidad, base factual y consistencia promesa-acción; la tercera capa evalúa la calidad de expresión y las alternativas cumplidoras según la Rubric de la Tabla 8-1, reservando los turnos de evidencia para las conclusiones fallidas. El Judge de calidad predeterminado utiliza reglas deterministas, ofreciéndose además un LLM Judge real; independientemente del modelo usado en la capa superior, las capas de resultados y reglas no se dejan a la conjetura del modelo de lenguaje.

Contraste e indicadores: La línea base solo emite una puntuación global; el grupo experimental emite pass, fail o uncertain para cada dimensión, junto con la evidencia y la confianza. En la fase de calibración se calcula la precisión y cobertura de identificación de fallas por dimensión, reportando la tasa de coincidencia exacta con las etiquetas de los expertos; asimismo, se verifica que fallas como las falsas promesas entreguen evidencias no vacías y no solo una conclusión.

Criterios de aceptación: El verificador debe identificar de forma estable infracciones clave, falsas promesas y rechazos excesivos; una puntuación global alta no debe ocultar fallos en dimensiones de privacidad o reglas; los casos de baja confianza y alto riesgo deben pasar a un segundo verificador o a revisión humana, en lugar de convertirse automáticamente en señales de aprendizaje.

La implementación correspondiente se encuentra en trajectory-verifier, utilizando por defecto un Judge de calidad reproducible sin conexión; con --judge llm se puede ejecutar el verificador LLM real implementado.

Cuatro Métodos para la Evolución Continua del Agente

La señal de aprendizaje indica que el Agente debe cambiar, pero no especifica dónde debe ocurrir dicho cambio. El criterio primario para elegir el método de actualización no es cuánto tiempo hace que apareció la experiencia, sino si la capacidad objetivo se puede expresar de forma natural en un soporte determinado. Los hechos y las experiencias son adecuados para redactarse como documentos de conocimiento; las estrategias que se pueden verbalizar claramente son aptas para incorporarse en prompts o Skills; los procesos y restricciones que se pueden ejecutar con precisión son adecuados para escribirse como programas; mientras que las capacidades de alta dimensión como la percepción, el estilo del lenguaje y las estrategias implícitas deben ingresar en los parámetros del modelo. La Figura 8-3 muestra estos cuatro métodos y sus relaciones.

La Tabla 8-2 presenta una comparación compacta. Los cuatro métodos no son mutuamente excluyentes: un Agente de imágenes médicas depende de parámetros para identificar lesiones, utiliza una base de conocimientos para ofrecer las guías más recientes y emplea código para calcular indicadores de riesgo; el tono natural de un modelo de atención al cliente proviene del post-entrenamiento, las políticas corporativas específicas las proporcionan el conocimiento y las Skills, y las reglas de cumplimiento clave las asegura el código del servidor.

Tabla 8-2 Límites aplicables de los cuatro métodos de evolución continua

Método de actualización	Contenido adecuado	Ventajas principales	Limitaciones principales
Base de conocimientos de experiencia	Hechos, patrones experimentales, excepciones y fuentes	Actualización rápida, trazabilidad, recuperación bajo demanda	Depende de la recuperación y de la correcta aplicación del modelo
Prompt y Skill	Principios de juicio y normas operativas verbalizables	Interpretable, alcance de acción controlable	Propenso a sobrecarga, conflictos u omisiones
Programa y Harness	Procesos deterministas, herramientas y restricciones fuertes	Evaluable, ejecución estable, bajo costo	Costo de desarrollo y mantenimiento relativamente alto
Parámetros del modelo	Percepción de alta dimensión, estilo de generación y estrategias implícitas	Alta capacidad de generalización, bajo costo de inferencia	Alto costo de actualización y prueba de regresión

Consolidación de la Experiencia en Conocimiento

El método de evolución más ligero consiste en organizar la experiencia que reaparece en múltiples ejecuciones en documentos de conocimiento recuperables. La "base de conocimientos de experiencia" mencionada aquí comparte las tecnologías de almacenamiento, indexación y recuperación del Capítulo 3, pero difiere en las fuentes de conocimiento y los objetivos de verificación. El Capítulo 3 extrae principalmente "cómo son el usuario y el mundo" a partir de conversaciones, documentos y conjuntos de datos; este capítulo extrae "cómo se debe actuar bajo qué condiciones" a partir de las trayectorias de acción y los resultados del Agente. Por ejemplo, "esta aerolínea exige reservar comidas especiales con veinticuatro horas de anticipación" es conocimiento del dominio; mientras que "verificar el plazo límite de comidas especiales antes de reservar el boleto para evitar descubrir que no se puede satisfacer la necesidad tras el pago" es experiencia de acción.

La trayectoria original no es adecuada como unidad formal de conocimiento. Es larga y ruidosa, e incluye salidas crudas de herramientas, desvíos casuales y detalles del entorno. Un sistema más sólido conserva tres capas de datos: trayectorias primarias inmutables para auditoría, análisis de ejecuciones individuales que registran éxitos, fracasos y lecciones candidatas, y múltiples trayectorias de la misma categoría que se comparan, agrupan e inducen para formar documentos de conocimiento en Markdown orientados al futuro. Los documentos formales suelen detallar los escenarios aplicables, las estrategias recomendadas, las prácticas prohibidas, las condiciones de excepción, las fuentes de evidencia y la fecha de última verificación, en lugar de recontar el proceso completo de una sola tarea.

Este diseño comparte la misma noción de dos etapas que el enfoque User-as-Code del Capítulo 3. User-as-Code agrega primero los hechos de la conversación a un registro inmutable y luego reconstruye periódicamente el modelo estructurado del usuario; el aprendizaje de experiencia debe del mismo modo guardar la evidencia primero y luego generar conocimiento mutable fuera de línea. La Figura 8-4 ilustra este proceso. Separar el registro de la sistematización evita que un éxito fortuito o un fallo de red altere inmediatamente al Agente, permitiendo además que el sistema juzgue los patrones comunes tras observar múltiples éxitos y fracasos.

Los documentos de experiencia no son simples resúmenes de trayectorias. El contenido con verdadero valor de transferencia proviene del contraste: qué hicieron las trayectorias exitosas de la misma categoría y qué les faltó a las fallidas; en qué versiones del entorno funcionó cierta estrategia y bajo qué condiciones previas falló. El Capítulo 3 ya presentó la extracción, agrupación y recuperación de conocimiento; este capítulo no repite esos algoritmos, sino que se centra en cómo la evaluación de trayectorias se convierte en una condición de extracción y en si el conocimiento extraído logra mejorar el rendimiento en tareas posteriores.

Un flujo completo de destilación de conocimiento se puede dividir en cinco pasos. En primer lugar, se guardan las trayectorias inmutables y los resultados ambientales; a continuación, se genera un análisis estructurado para cada ejecución individual, detallando el tipo de tarea, las capacidades requeridas, las estrategias observadas, los errores y las excepciones; luego se agrupan las ejecuciones similares por familias de tareas, construyendo para cada patrón candidato una tabla de evidencia con "qué trayectorias lo respaldan y cuáles lo refutan"; únicamente aquellos candidatos que alcanzan el umbral de respaldo se escriben en los documentos formales; finalmente, se evalúa el efecto de transferencia en nuevas tareas que no participaron en la destilación. El conocimiento formal y los análisis candidatos se almacenan en bases separadas, lo que permite al sistema volver a inducir patrones sin alterar la evidencia original y revocar con precisión una conclusión cuando cambia la versión del entorno.

El aprendizaje de experiencia en GAIA proporciona un ejemplo intuitivo. GAIA² contiene problemas de múltiples pasos que requieren búsqueda integrada, lectura de páginas web, procesamiento de archivos y cálculos, mientras que AWorld³ proporciona el entorno de ejecución para ejecutar Agentes, invocar estas herramientas y guardar trayectorias; el primero es como el examen y el segundo como el aula y el sistema de registro experimental. El enfoque antiguo consistía en generar un resumen de estrategia inmediatamente tras el éxito de una tarea e ingresarlo vectorizado en la base de datos; una implementación más rigurosa utiliza primero la verificación de respuestas de GAIA u otros verificadores de entorno para marcar éxitos, éxitos parciales y fracasos, comparando luego múltiples rutas de la misma familia de tareas. Las trayectorias exitosas aportan estrategias candidatas, las fallidas aportan conocimiento de exclusión y las parcialmente exitosas ayudan a identificar "qué tramo fue efectivo y cuál sigue presentando problemas". La reflexión en lenguaje natural propuesta por Reflexion¹ puede participar en la generación de lecciones candidatas, pero la reflexión en sí no es evidencia: solo aquello que coincide con los resultados ambientales, cuenta con respaldo entre trayectorias y muestra una transferencia positiva en nuevas tareas debe ingresar a los documentos formales de experiencia.

Experimento 8-2 ★★: Extraer documentos de conocimiento de experiencia a partir de trayectorias de GAIA

Objetivo del experimento: Verificar si los "documentos de conocimiento entre trayectorias" son más fáciles de transferir que "recordar el resumen de un solo éxito", reduciendo la transferencia negativa provocada por éxitos casuales y experiencias erróneas.

Datos y proceso: gaia-experience guarda primero la trayectoria completa y el environment_score externo de cada ejecución, convirtiéndolos luego en un registro de aprendizaje mínimo: task_family, capabilities requeridas, applies_when, estrategias observadas, errores, excepciones e ID de trayectorias de origen. El verificador de resultados clasifica las ejecuciones en éxito, éxito parcial y fracaso; el módulo de aprendizaje compara las rutas dentro de la misma familia de tareas; el LLM puede proponer inducciones candidatas, pero una estrategia recomendada debe contar al menos con el respaldo de dos trayectorias no fallidas. Los documentos Markdown finales incluyen escenarios aplicables, estrategias recomendadas, errores comunes, condiciones de excepción, fuentes y fecha de última verificación. La fase de aplicación solo recupera estos documentos, sin introducir trayectorias originales extensas directamente en el contexto.

Tres grupos de contraste: El primer grupo no utiliza experiencia histórica; el segundo recupera el resumen de la trayectoria más similar a la tarea actual; el tercer grupo recupera documentos de conocimiento respaldados conjuntamente por múltiples trayectorias. Los conjuntos de aprendizaje y de transferencia deben ser estrictamente disjuntos para evitar filtrar las respuestas de una misma pregunta de GAIA como "experiencia" a la evaluación.

Indicadores y aceptación: Se reportan simultáneamente la tasa de éxito en tareas de transferencia, el promedio de caracteres o tokens recuperados y la tasa de transferencia negativa, comprobando si cada conclusión formal enumera sus trayectorias de origen. Si los documentos entre trayectorias solo acortan el contexto sin mejorar el rendimiento en nuevas tareas, no se demuestra que el sistema haya aprendido de la experiencia; si un éxito fortuito se promociona a conocimiento formal o si los documentos no se pueden rastrear hasta la trayectoria original, la prueba no se considera superada.

La implementación correspondiente se encuentra en gaia-experience. demo_documents.py se ejecuta por defecto sin conexión; utilizando --extractor llm un LLM real puede proponer candidatos de experiencia entre trayectorias.

Codificación de la Experiencia como Instrucciones (Prompts y Skills)

La base de conocimientos de experiencia proporciona material de referencia al Agente, mientras que los Prompts y Skills poseen un carácter instructivo más fuerte. Cuando múltiples trayectorias revelan repetidamente el mismo error de estrategia y la regla se puede expresar con claridad en lenguaje natural, el sistema puede promoverla de "experiencia de referencia" a "regla que se debe cumplir". Las reglas aplicables a casi todas las tareas deben ingresar en los prompts del sistema; los procesos complejos que solo se aplican a un dominio, proyecto o herramienta concreta son más adecuados para escribirse como Skills cargadas bajo demanda o archivos de instrucciones de proyecto.

El aprendizaje de prompts difiere de la ingeniería de prompts del Capítulo 2. El Capítulo 2 responde a cómo redactar prompts de estructura clara y amigables con el almacenamiento en caché; aquí se responde a qué retroalimentación de producción es suficiente para activar la modificación de prompts y cómo se verifican las nuevas reglas antes de su despliegue. Las modificaciones no deben consistir en reescribir repetidamente todo el prompt del sistema. Un enfoque más confiable consiste en generar un diff mínimo basado en un conjunto de fallas similares, indicar el alcance de la regla, verificar si contradice reglas existentes y evaluarlo simultáneamente en casos límite que provocaron la falla y en el conjunto de retención de tareas antiguas.

Andrej Karpathy denominó provisionalmente a este nuevo paradigma aprendizaje de prompts del sistema (System Prompt Learning) en un extenso artículo de 2025⁷. Su resumen señala que el pre-entrenamiento aprende principalmente conocimiento y el ajuste fino moldea comportamientos habituales; pero los humanos poseen otro tipo de aprendizaje: tras encontrar un problema y dar con la solución, se recuerdan a sí mismos en lenguaje claro para el futuro: "la próxima vez que enfrente este tipo de problemas, debo intentar primero este método". Karpathy compara a los LLM que carecen de este bloc de notas con el personaje de la película Memento, e indica que tanto el aprendizaje de prompts del sistema como el aprendizaje por refuerzo mejoran el comportamiento a partir de la experiencia, pero sus algoritmos de actualización son distintos: el primero edita texto, mientras que el segundo modifica parámetros mediante descenso de gradiente. El ejemplo que cita es que el prompt del sistema de Claude (de unos 17,000 términos en su momento) exigía específicamente: al enfrentar problemas de conteo de palabras, letras o caracteres, numerar primero elemento por elemento y contar explícitamente antes de responder, diseñado justamente para manejar preguntas como cuántas "r" hay en "strawberry".

Llevado a los sistemas de Agentes, esto implica escribir las lecciones verbalizables tras una falla como reglas candidatas que las ejecuciones futuras puedan leer directamente. En comparación con los resultados escalares de sólo "éxito/fracaso", un diagnóstico con evidencia puede señalar si el error estuvo en la verificación de identidad, la selección de herramientas o los límites de transferencia, permitiendo generar modificaciones candidatas más enfocadas. Lo que Karpathy describe como "la revisión guiada por conocimiento posee un canal de retroalimentación de mayor dimensión que la recompensa escalar" explica por qué este método puede lograr una mayor eficiencia de datos; no obstante, una mayor riqueza de información no garantiza que sea correcta por naturaleza: la opinión de un usuario puede aplicarse solo a un cliente o a una política antigua, por lo que debe pasar por procesos de agrupación, juicio de alcance y pruebas de regresión.

La optimización automática de prompts cuenta con varias rutas. DSPy⁴ trata los programas compuestos por múltiples llamadas a modelos de lenguaje como objetos optimizables, buscando instrucciones y ejemplos en el conjunto de desarrollo; OPRO⁵ permite que el modelo de lenguaje continúe proponiendo candidatos basándose en prompts históricos y sus puntuaciones; mientras que GEPA⁶ utiliza reflexiones en lenguaje natural de trayectorias fallidas para generar y filtrar prompts candidatos complementarios. Estos enfoques están orientados a la optimización por lotes en conjuntos de evaluación fuera de línea; el diff mínimo en sistemas de producción se asemeja más al mantenimiento continuo, siendo activado por nuevos casos límite aparecidos y enfatizando la fuente, la auditoría y la reversión rápida. En la práctica, se puede buscar primero una versión inicial óptima fuera de línea y luego mantener las reglas de cola larga en línea mediante parches caso por caso.

Por ejemplo, un Agente de atención al cliente de aerolíneas suele transferir prematuramente la llamada a un agente humano cuando el usuario cuestiona la política. La evaluación de trayectoria muestra que no violó las reglas, pero le faltaron alternativas cumplidoras. Un parche candidato puede exigir que el Agente explique primero la política, identifique el objetivo real del usuario y busque soluciones alternativas permitidas, transfiriendo a un humano únicamente si el usuario lo solicita explícitamente o si supera sus permisos. Si la nueva regla reduce las transferencias excesivas pero provoca que eventos de seguridad que debían transferirse sigan siendo procesados por el Agente, la regla no habrá pasado la prueba de regresión. El valor del aprendizaje de prompts del sistema no reside en añadir más texto automáticamente, sino en usar casos límite de producción para aclarar continuamente el alcance de las reglas.

El aprendizaje de Skills sigue los mismos principios, aunque su alcance es más local. Una Skill se puede entender como un manual operativo de puesto abierto bajo demanda: si múltiples experiencias forman colectivamente un proceso completo de reclamos de seguros, el sistema puede generar o revisar la Skill correspondiente. Una Skill candidata no debe ser solo el resumen de una conversación, sino explicar al menos cuándo cargarse, las condiciones previas, los pasos operativos, las trampas conocidas y los métodos de verificación, conservando las trayectorias de origen. El sistema busca primero capacidades similares en la biblioteca de Skills existente: si existe el mismo proceso, prioriza un patch local; solo cuando aparece una capacidad independiente realmente nueva crea un nuevo directorio, evitando llenar la biblioteca con manuales de nombres diferentes y contenidos similares. El Skill Creator de Anthropic⁸ muestra un ciclo de generación de "redacción - prueba - evaluación - revisión"; este resuelve cómo elaborar y mejorar Skills, siendo lo realmente difícil determinar qué evidencias operativas son suficientes para activar la generación, cómo manejar conflictos y si tras la modificación se superan las pruebas de regresión en tareas del dominio y tareas antiguas.

Experimento 8-3 ★★: Optimizar prompts del sistema a partir de trayectorias de falla

Objetivo del experimento: Permitir que un Agente de atención al cliente de aerolíneas aprenda de las trayectorias de falla de "transferir prematuramente a un humano cuando el usuario cuestiona la política", demostrando al mismo tiempo que la nueva regla no destruye los escenarios antiguos que realmente requieren transferencia.

Proceso: En primer lugar, se ejecutan por separado el conjunto de retención de tareas antiguas y el conjunto límite de transferencia excesiva; learning_signal.py divide la falla en tres dimensiones: cumplimiento de reglas, resolución de tareas y alternativas cumplidoras, conservando los ID de caso de origen. A continuación, el Coding Agent lee el prompt existente y genera únicamente una edición mínima auditable old_str → new_str: exigiendo que el Agente explique primero la política, identifique el objetivo real y busque alternativas válidas, conservando las rutas de transferencia cuando el usuario lo solicite explícitamente o ante eventos de seguridad. El parche se escribe en el manifest candidato junto con la fuente, las reglas objetivo y la justificación.

Tres grupos de contraste: Prompt inicial, Prompt candidato generado automáticamente y Prompt ajustado manualmente de una sola vez. Los tres utilizan el mismo modelo y el mismo lote de tareas retenidas/límite; --quick solo reduce la cantidad de casos, manteniendo llamadas reales al Agente de tareas, LLM Judge y Coding Agent, por lo que no debe tomarse como un resultado de simulación fuera de línea.

Umbral de publicación e indicadores: El candidato debe cumplir cuatro condiciones: parche no vacío, fuente trazable, mejora confirmada en el conjunto límite y sin degradación en el conjunto de retención. Se comparan la precisión en tareas límite, la precisión en tareas retenidas, el incremento de longitud del prompt, el número de regresiones introducidas y el tiempo transcurrido desde la detección de la falla hasta la generación del candidato. Superar el umbral solo otorga release_to_canary, sin sobrescribir directamente el Prompt estable; si falla cualquiera de las condiciones, se debe retornar reject_candidate.

La implementación correspondiente se encuentra en prompt-auto-optimization. Las pruebas fuera de línea cubren el diagnóstico y los umbrales de publicación, mientras que --quick realiza llamadas reales al Agente de tareas, LLM Judge y Coding Agent.

Codificación de la Experiencia como Programas (RPA y Workflows)

Cuando la experiencia describe operaciones estables, repetitivas y verificables, hacer que el modelo vuelva a leer documentos y razonar en cada ocasión no resulta económico. En estos casos, lo más adecuado es compilar la experiencia en flujos de trabajo, herramientas o código de Harness, transformando una exploración puntual en un programa ejecutable y repetible. El Capítulo 5 explicó cómo un Coding Agent lee y escribe archivos, ejecuta pruebas y genera sistemas; esta sección no se enfoca en la generación de código general, sino en cómo el Agente modifica versiones futuras de sí mismo basándose en sus propias trayectorias.

Los objetos modificables van mucho más allá de nuevas herramientas. En la capa operativa, se pueden compilar trayectorias del navegador en flujos de trabajo parametrizados o generar adaptadores para API cambiantes; en la capa de control, se pueden modificar el enrutamiento de herramientas, los reintentos, los interruptores de circuito y las estrategias de compresión de contexto; en la capa de verificación, se pueden agregar verificaciones de parámetros, verificadores de estado y pruebas de regresión basadas en fallos de producción; mientras que en la capa de arquitectura, se pueden incorporar agentes revisores (Reviewer Agents) para alterar el flujo de información entre la planificación y la ejecución.

Los flujos de trabajo en navegador ilustran el valor de la experiencia programada. Se pueden analogar a la grabación de macros en hojas de cálculo: la primera vez que envía un correo electrónico, un Agente multimodal busca controles como "redactar, destinatario, asunto, cuerpo, enviar" a través del ciclo observación - pensamiento - acción; al enviar otro correo posteriormente, el proceso no cambia y solo difieren el destinatario y el contenido, por lo que no es necesario volver a llamar al modelo para redescubrir toda la ruta desde los píxeles y el DOM. Lo que debe hacer el sistema es compilar la trayectoria generada en la primera exploración en un pequeño programa con parámetros, verificaciones de estado e información de versión.

El proceso de destilación de conocimiento ilustrado en la Figura 8-4 se traduce en el escenario del navegador en un ciclo de vida más concreto:

1. Captura de trayectoria: Registrar acciones como navegación, clics, entradas y selecciones desplegables, guardando los parámetros de la acción, la URL de ese momento y evidencias de localización de elementos como XPath, CSS, id, role, aria-label y data-testid. La información de localización solo sirve para volver a encontrar el elemento, no para probar que la tarea se haya completado.
2. Parametrización: Identificar los literales de la primera ejecución como variables de plantilla; por ejemplo, reemplazar test@example.com, el asunto y el cuerpo del correo por {recipient}, {subject} y {content}; manteniendo inalteradas las demás acciones estables. Las implementaciones didácticas utilizan expresiones regulares y reemplazo de plantillas, mientras que los sistemas de producción pueden usar entradas de tareas estructuradas o modelos de extracción restringidos.
3. Definición de verificaciones de estado: Agregar verificaciones previas y posteriores a la ejecución de las acciones; por ejemplo, "el botón de enviar está visible actualmente" o "la URL tras la navegación pertenece al sitio objetivo"; agregando para todo el flujo de trabajo una verificación de estado final, como "aparece un nuevo correo en la lista de enviados" o que los valores de estado en la página de prueba cambien según lo previsto. Que la ejecución de la acción sea exitosa y que la tarea sea exitosa son dos cosas distintas; la verificación del estado final debe leer la página real o el estado del backend.
4. Validación de candidatos: El primer éxito solo genera un candidate. El sistema debe restablecer la cuenta de sandbox o el sitio de prueba a un estado inicial independiente y volver a reproducir completamente el candidato; solo cuando se aprueban todas las verificaciones previas, posteriores y de estado final, se puede publicar como validated. Las tareas con efectos secundarios como enviar correos o realizar pedidos que no cuenten con callbacks de restablecimiento seguros solo pueden guardar el candidato para auditoría, sin poder ejecutarse repetidamente en cuentas de producción para su verificación.
5. Coincidencia y reproducción: Cuando llega una nueva tarea, se busca primero el flujo de trabajo en la biblioteca formal de capacidades por intención y palabras clave, se extraen los parámetros actuales y luego Playwright lo ejecuta directamente. La ruta de reproducción no requiere llamar paso a paso al LLM, pero aún debe esperar a que los elementos estén disponibles y completar todas las verificaciones de estado.
6. Invalidación y re-aprendizaje: Si no se encuentra el elemento objetivo, fallan las verificaciones de estado, cambia el esquema de la API o el estado final es incorrecto, el sistema detiene inmediatamente las acciones posteriores, traslada la versión antigua de la biblioteca recuperable a la zona invalid y retrocede al Agente completo para una nueva exploración. Los archivos antiguos se conservan para auditoría y comparación, sin poder seguir siendo activados silenciosamente.

Tomando como ejemplo el envío de correos, el resultado compilado no es simplemente "hacer clic en estos botones en orden", sino un programa pequeño con parámetros de destinatario, asunto y cuerpo: verifica la ventana de redacción y las casillas antes de enviar, comprueba el aviso de éxito tras enviar y finalmente confirma que el correo correspondiente aparece en la lista de enviados. En los experimentos de PreAct⁹, este tipo de programas logró una aceleración de extremo a extremo de 8.5 a 13 veces en tareas repetitivas, sin necesidad de llamar progresivamente al modelo de lenguaje durante la fase de reproducción; la conclusión más relevante es que la memoria de proceso debe contar simultáneamente con verificación previa a la acción, verificación posterior a la acción y verificación independiente previa al almacenamiento. De lo contrario, el sistema puede caer fácilmente en una ilusión peligrosa: la cobertura de reproducción es del 100% y se ha hecho clic en cada botón, pero un campo estaba realmente vacío y la tarea nunca se completó.

Experimento 8-4 ★★★: Generar flujos de trabajo verificables a partir de trayectorias del navegador

Objetivo del experimento: Verificar si un Agente web puede transformar una exploración costosa en un flujo de trabajo reutilizable y rechazar reproducciones erróneas cuando la página cambia, en lugar de reportar falsamente éxito solo porque "se ejecutaron todas las acciones".

Escenario en cuatro fases: La primera fase ejecuta en un sitio de correo de prueba o página de mensajes simulada la instrucción "enviar a test@example.com un mensaje con asunto 'Correo de prueba'", donde el Agente completo se encarga de explorar y la capa de encapsulamiento captura acciones, parámetros y estados de página para generar un candidate. La segunda fase llama a validation_reset para restaurar el sandbox y reproduce de forma independiente el flujo completo; solo si se aprueban las verificaciones previas, posteriores y de estado final, el candidato ingresa a la biblioteca formal de capacidades. La tercera fase ejecuta tareas similares con destinatarios, asuntos y cuerpos diferentes; el sistema debe coincidir con el flujo verificado, rellenar los nuevos parámetros y reproducir mediante Playwright sin ingresar al bucle gradual del LLM. La cuarta fase modifica la localización de botones, textos de la página o el estado final, verificando si el flujo antiguo pasa de inmediato a invalid y retorna fallback_required=True.

Diseño de contraste: La línea base simplificada solo contabiliza si acciones como clics o entradas no lanzaron excepciones; el grupo experimental verifica adicionalmente la página previa a la acción, la página posterior y el estado final de la tarea. Ambos grupos usan las mismas trayectorias y cambios de página, comparando la tasa de falsos positivos en escenarios de falso éxito como "campo vacío pero botón de enviar presionado" o "Save presionado pero datos no guardados en base de datos".

Indicadores y aceptación: Se registran los tiempos de extremo a extremo de la exploración inicial y reproducción, el número de llamadas a LLM, la tasa de éxito, la tasa de éxito erróneo, la tasa de coincidencia de flujos de trabajo, la tasa de detección de cambios en la página y el número de retrocesos para re-aprendizaje. Sin callback de restablecimiento, el flujo debe permanecer en la zona candidata; las versiones con fallos de validación no se pueden recuperar; la reproducción parametrizada no debe reutilizar los destinatarios o contenidos de la primera ejecución; tras cambios en la página se deben detener las acciones posteriores peligrosas. Solo al cumplir simultáneamente estas condiciones tienen sentido los resultados de aceleración.

La implementación correspondiente se encuentra en browser-use-rpa, ofreciendo tanto una demostración determinista de máquina de estados como una ruta de ejecución que llama al Agente de navegador real.

Que un Agente modifique su propio código no significa que el proceso en ejecución se sobrescriba directamente a sí mismo. Un sistema de producción debe crear una rama candidata a partir de la versión estable actual, donde un Coding Agent genera un parche mínimo que pasa sucesivamente por verificaciones estáticas, pruebas unitarias, escaneos de seguridad, reproducción de trayectorias fallidas y regresión de tareas antiguas, antes de generar una nueva versión desplegable de forma gradual. Esto convierte la "auto-modificación" en un proceso de publicación de software auditable, marcando la frontera entre el Capítulo 8 y el Capítulo 5: el Capítulo 5 proporciona la capacidad de modificar el sistema, mientras que este capítulo proporciona el método de auto-modificación activado por la experiencia y restringido por el bucle cerrado de verificación.

Contar únicamente con "parches lo más pequeños posible" no basta para respaldar una atribución confiable. Cada solicitud de modificación debe ser además un contrato de cambio falsable: detallando la evidencia de la falla, la causa raíz inferida, el componente del Harness perteneciente, la modificación candidata, el comportamiento que se espera reparar, el comportamiento existente que podría verse afectado y los casos de prueba para verificar ambos aspectos. Agentic Harness Engineering resume esta práctica como una observabilidad de tres capas: componentes, experiencia y decisiones: los componentes editables cuentan con representación a nivel de archivo; las trayectorias masivas se organizan en evidencia profundizable paso a paso; y cada edición declara su predicción de impacto antes de la ejecución, siendo verificada por los resultados de la siguiente ronda¹⁹. De este modo, el aumento de puntuación puede vincularse a un mecanismo específico en lugar de ser un ensayo y error ininterpretable.

Las entradas del generador de candidatos tampoco deben limitarse a casos fallidos. El enfoque de Self-Harness proporciona además los comportamientos exitosos que deben conservarse y el historial de modificaciones rechazadas previamente²⁰. Los primeros indican al Agente qué propiedades no deben destruirse durante la reparación, mientras que los segundos evitan que vuelva a presentar soluciones fallidas redactadas de otra forma. La evidencia de fallas, las restricciones de éxito y los intentos históricos constituyen conjuntamente un espacio candidato acotado, siendo más propenso a generar cambios locales y verificables que entregar todo el código fuente y registros originales sin distinción al Agente modificador.

La creación de herramientas sigue el mismo protocolo. El caso presentado por Alita¹⁰ es el siguiente: el Agente debía encontrar el número mencionado inmediatamente después de la primera aparición de un dinosaurio en un video de YouTube 360 VR narrado por el actor de doblaje de Gollum en El Señor de los Anillos. Al descubrir que carecía de capacidad para leer subtítulos, buscó y probó youtube-transcript-api, encapsulándola como una nueva herramienta de subtítulos y obteniendo finalmente la respuesta 100000000 a partir de los subtítulos. Solo tras pasar escaneos de seguridad, pruebas funcionales y reutilización en tareas posteriores, la nueva herramienta ingresa a la biblioteca de capacidades. El descubrimiento activo de herramientas del Capítulo 4 resuelve "cuál de las herramientas existentes es adecuada", el Capítulo 5 resuelve "cómo escribir herramientas", mientras que este capítulo se ocupa de "qué evidencia operativa activa la creación y cómo la nueva herramienta se convierte en una capacidad a largo plazo verificada".

Experimento 8-5 ★★★: Auto-modificación del Agente activada por trayectorias de falla

Objetivo del experimento: Dado un conjunto de trayectorias donde errores de tipo retryable=false siguen siendo invocados continuamente, verificar si el sistema puede ubicar la causa raíz en el código de reintento e interruptor de circuito, generando un arreglo candidato sin destruir la capacidad de reintento ante fallos temporales.

Proceso: El módulo de diagnóstico agrupa primero los mismos fallos en diferentes tareas, creando una solicitud de modificación solo al alcanzar el umbral de soporte entre trayectorias y fijando el objetivo en la versión estable de retry_policy.py. El generador de candidatos lee el diagnóstico de fallas, los comportamientos de recuperación de fallos temporales que deben conservarse, las modificaciones rechazadas previamente y el código fuente estable, enviando primero una predicción de impacto ("las llamadas por errores no reintentables deben reducirse y la tasa de recuperación de timeouts temporales no debe disminuir") antes de emitir un diff de código mínimo; independientemente de si se usa un generador determinista o un LLM Coding Agent real, los resultados solo pueden escribirse en el directorio candidato aislado. A continuación, el Harness de verificación compila el candidato, reproduce las trayectorias fallidas originales, comprueba si los errores no reintentables se detienen de inmediato y abren el interruptor de circuito, y vuelve a probar si los timeouts temporales se reintentan según el umbral original.

Contraste de diagnóstico e indicadores: Se utiliza "añadir simplemente una instrucción en el Prompt de no repetir llamadas" como contraste conceptual de localización en la capa de error, explicando por qué las restricciones de reintento ejecutables de forma determinista deben ingresar al programa. El experimento ejecutable compara el generador de parches determinista con el generador LLM, compartiendo ambos el mismo umbral de publicación; se registran el número de invocaciones no reintentables, la tasa de recuperación de errores temporales, el número de regresiones en tareas antiguas, el tamaño del parche y la tasa de aceptación de candidatos.

Criterios de aceptación: Tras aprobar todas las comprobaciones solo se genera release_to_canary; si falla cualquier verificación estática, reproducción de fallos o regresión de tareas antiguas, se retorna reject_candidate. release_manifest.json debe registrar el clúster de fallos, las trayectorias de origen, la causa raíz inferida, los componentes y archivos objetivo, el diff de código, la reparación esperada, los posibles retrocesos, los resultados de las verificaciones, la versión candidata y la versión de reversión; los candidatos rechazados también deben conservar sus razones de falla para consulta en la siguiente ronda de generación. El Agente que genera los parches no puede modificar el código estable, los verificadores, los registros de auditoría ni los umbrales que aprueban su propia publicación.

La implementación correspondiente se encuentra en self-modifying-agent, pudiendo elegir un generador candidato determinista o un LLM Coding Agent real, compartiendo ambas rutas el mismo umbral de publicación.

Codificación de la Experiencia en Parámetros

El conocimiento, las instrucciones y los programas se basan en una premisa: la capacidad objetivo se puede expresar de forma relativamente completa mediante símbolos externos. Sin embargo, capacidades como la comprensión de imágenes médicas, la prosodia natural de la voz, la eliminación del tono estandarizado de "sabor a IA" en textos y la planificación a largo plazo son difíciles de comprimir en unas pocas reglas o flujos de trabajo. Este tipo de capacidades se debe incorporar en los parámetros del modelo a través del post-entrenamiento.

La decisión de parametrizar no depende únicamente de si "la tarea es estable a largo plazo". Los sesgos de dominio provocados por nuevos equipos de imágenes aún pueden requerir LoRA o ajuste fino continuo; mientras que estilos de lenguaje de rápido cambio también pueden adaptarse mediante entrenamiento periódico de preferencias. La estabilidad afecta la frecuencia de actualización y los costos, pero la naturaleza de representación de la capacidad determina su soporte principal. De manera inversa, una regla de aprobación de transferencias estable a largo plazo tampoco debe depender únicamente de la memoria de parámetros, requiriendo que el código del servidor siga proporcionando garantías deterministas.

El Capítulo 7 discutió exhaustivamente SFT, destilación y RL, por lo que no se repiten en esta sección. Para la evolución continua, la clave radica en transformar las trayectorias de producción evaluadas en datos de entrenamiento: las demostraciones de alta calidad pueden ingresar a SFT, las preferencias claras pueden formar datos en pares, y las interacciones con recompensas ambientales confiables se pueden utilizar para RL. Antes de ingresar al entrenamiento se deben eliminar datos de privacidad, filtrar trayectorias erróneas y reservar conjuntos de regresión independientes; tras el entrenamiento se debe verificar que no se hayan olvidado las capacidades generales ni el alineamiento de seguridad.

El aprendizaje de parámetros suele colaborar con métodos externos. Un modelo de imágenes médicas utiliza parámetros para aprender representaciones visuales, usa una base de conocimientos para ofrecer las guías más recientes y emplea código para medir lesiones y calcular riesgos; el tono natural en atención al cliente puede moldearse en su distribución general mediante entrenamiento de preferencias, utilizando luego el Prompt para fijar la identidad de marca actual y la memoria de usuario para adaptarse a las preferencias de comunicación personales. La evolución continua no consiste en elegir una única respuesta entre los cuatro métodos, sino en situar cada capacidad en la posición más adecuada para su expresión y gobernanza.

De los Artefactos de Actualización a la Actualización del "Método de Actualización"

Los cuatro métodos anteriores abordaron dónde se escribe finalmente la experiencia, pero la evolución continua posee otro eje ortogonal: si lo que el sistema está optimizando es el contenido de un artefacto específico o los métodos para generar, gestionar y verificar dichos artefactos. A lo largo de este eje, los objetos de optimización se pueden ampliar progresivamente en: regla individual o memoria → contexto estructurado → flujo de trabajo → código de Harness → código del optimizador que genera soluciones candidatas¹⁴. No se trata de cinco nuevos soportes de actualización, sino de cinco escalas de búsqueda distintas; el conocimiento, los Prompts, las Skills y los programas pueden aparecer en múltiples de estos niveles.

La capa más interna solo modifica el contenido del artefacto. Por ejemplo, agregar una regla local al prompt del sistema basándose en trayectorias fallidas, o complementar una condición de excepción en un documento de experiencia. Esta modificación tiene un alcance pequeño, es fácil de atribuir y revertir, por lo que debe ser la opción predeterminada. Sin embargo, hacer que el modelo reescriba repetidamente todo el Prompt o la memoria genera otro tipo de degradación: en pos de la concisión, pequeños detalles importantes de versiones antiguas pueden desaparecer paulatinamente tras múltiples rondas de reescritura; asimismo, condiciones que se restringen mutuamente pueden combinarse en un principio excesivamente abstracto. Agentic Context Engineering (ACE) mantiene el contexto como un conjunto de elementos con identificadores estables, donde los módulos de generación, reflexión y sistematización proponen actualizaciones incrementales que luego se fusionan y desduplican mediante lógica determinista, en lugar de reescribir en cada ronda un bloque de texto cada vez más corto¹⁵. Esto proporciona un ejemplo de investigación concreto para el principio de "diff mínimo y conservación de fuentes" expuesto anteriormente.

Una capa más hacia afuera, el objeto de optimización deja de ser únicamente "qué hay en el contexto" para pasar a ser "cómo debe construirse el contexto". Meta Context Engineering (MCE) divide ambos aspectos en dos bucles, interno y externo: el bucle interno optimiza los artefactos de contexto de la tarea actual bajo un método de gestión determinado, mientras que el bucle externo modifica las operaciones de búsqueda, selección, filtrado y formateo del contexto basándose en los resultados de múltiples rondas de ejecución y verificación¹⁶. Esta distinción es muy importante: modificar una regla de recuperación es cambiar el mecanismo de gestión de contenidos; hacer que el sistema compare múltiples mecanismos de recuperación y sistematización conservando la versión con mejor efecto de transferencia es aprender "cómo gestionar el contexto".

La misma idea se puede extender a los flujos de trabajo y a todo el Harness. AFlow representa los flujos de trabajo compuestos por múltiples llamadas a LLM como grafos de código, buscando combinaciones de nodos y flujos de control mediante retroalimentación de ejecución¹⁷; mientras que Meta-Harness permite que un Coding Agent lea el código fuente, las puntuaciones y las trayectorias de Harness candidatos, buscando el código que decide cómo se almacena, recupera y presenta la información¹⁸. El Capítulo 5 explicó que el código es el lenguaje universal del Agente para expresar la estructura del sistema; la novedad aquí radica en que el código no es solo el producto de una generación puntual, sino que puede convertirse en un objeto de búsqueda continua junto con el historial de evaluación.

Los niveles de optimización no son mejores cuanto más altos sean. Buscar una regla local solo requiere unos pocos casos límite, mientras que buscar un flujo de trabajo completo o un Harness enfrenta un espacio candidato más amplio, mayores costos de evaluación y dificultades de atribución más severas. Un fallo claro, recurrente y localizable en un solo componente debe abordarse prioritariamente mediante un parche local auditable; solo cuando las modificaciones locales no logren resolver problemas entre componentes a largo plazo, o cuando el método de gestión existente se convierta en un cuello de botella, valdrá la pena ascender a las capas de flujo de trabajo, Harness e incluso optimizador. Independientemente del nivel al que se ascienda, el evaluador, los límites de permisos y las pruebas de retención deben situarse fuera del alcance modificable: cuanto mayor sea el espacio de búsqueda, más relevante resulta esta raíz de confianza.

Experimento 8-6 ★★★: Dale este libro a Hermes: ¿puede mejorarse a sí mismo?

Objetivo: Comprobar si un Agent puede convertir conocimiento externo en una actualización real de sus propias capacidades. El experimento no plantea un problema ni ofrece una lista de funciones: entrega a Hermes los diez capítulos y su código, y le pide entender los principios, revisar su implementación y elegir por sí mismo una mejora valiosa.

Diseño: El libro y el código forman el contexto legible, mientras que la versión estable, el Reviewer independiente y las pruebas de aceptación quedan fuera del alcance editable de Hermes. Debe completar leer → comparar → elegir → cambiar → verificar. Si un candidato es rechazado, la revisión pasa a ser la señal de aprendizaje de la ronda siguiente; Hermes no puede saltarse la puerta y declarar éxito.

Ejecución real: Tras leer el libro, Hermes detectó por sí mismo que sus trayectorias guardadas carecían de evidencia estructurada que el aprendizaje posterior pudiera usar directamente. Eligió convertir los resultados de ejecución en señales de aprendizaje conservadoras, modificó su código y añadió pruebas. Las tres primeras revisiones independientes hallaron diferencias con los formatos reales, las rutas de persistencia y la semántica del conteo. Cada hallazgo volvió a la sesión original de Hermes; la cuarta revisión aceptó el candidato.

Límite de la conclusión: La ejecución demuestra que un Agent puede extraer principios de conocimiento extenso, llevarlos a su propio código y completar una autoactualización bajo verificación externa. No demuestra que la actualización ya mejore las tareas posteriores; eso requiere otro experimento de ablación. La lectora Grace aportó la idea del experimento.

Construcción de un Bucle Cerrado de Evolución Continua para Operaciones a Largo Plazo

Los cuatro métodos de actualización se convierten en una evolución continua solo al ingresar en el mismo bucle autónomo. La Figura 8-5 muestra una estructura de doble bucle más sólida en sistemas de producción: el bucle de ejecución en línea únicamente completa tareas y registra evidencias, sin reescribir directamente el Agente formal; el bucle de evolución fuera de línea agrega trayectorias, diagnostica causas raíz, genera modificaciones candidatas y publica nuevas versiones tras superar umbrales de validación. Ambos se conectan a través de bases de experiencia e historiales de evaluación versionados.

Voyager¹³ muestra un bucle de evolución continua relativamente completo. En Minecraft, selecciona nuevos objetivos basándose en sus capacidades actuales, itera programas mediante retroalimentación del entorno, guarda el código en la biblioteca de habilidades tras una verificación exitosa y luego combina habilidades antiguas para resolver tareas más difíciles. El currículo automático, las habilidades ejecutables y la verificación del entorno son indispensables: sin currículo, el Agente no sabe qué aprender a continuación; sin verificación del entorno, la biblioteca de habilidades acumularía errores; sin persistencia, cada tarea tendría que empezar desde cero. Aunque el conocimiento, los Prompts, las herramientas y los parámetros de los Agentes reales son más complejos, el proceso básico de aprendizaje es similar.

En concreto, Voyager se compone de tres mecanismos interconectados. El generador automático de currículo propone el siguiente objetivo de dificultad adecuada según los objetos actuales, el entorno y las habilidades dominadas, evitando que la exploración sea un paseo aleatorio; la biblioteca de habilidades guarda los programas exitosos como código recuperable y combinable, permitiendo por ejemplo que una habilidad de recolección avanzada invoque habilidades básicas como movimiento y fabricación; el mecanismo de prompting iterativo lleva las observaciones del entorno, los errores de ejecución y los resultados de auto-verificación a la siguiente ronda de generación de código, hasta que la tarea se apruebe realmente. El artículo reporta que, en comparación con las líneas base de su momento, Voyager obtuvo 3.3 veces más objetos únicos, exploró 2.3 veces más distancia y desbloqueó hitos clave del árbol tecnológico hasta 15.3 veces más rápido, pudiendo además transferir su biblioteca de habilidades a nuevos mundos de Minecraft; estos indicadores miden la curva de crecimiento de capacidad con la experiencia, en lugar de la puntuación de un examen puntual con el Agente congelado.

De la Localización de Problemas a la Consolidación de la Experiencia

Un mismo problema superficial puede requerir diferentes formas de modificación. Las alucinaciones en las que un Agente de atención al cliente inventa hechos pueden deberse a falta de datos en la base de conocimientos o a que el Prompt no exigió citas; las falsas promesas de estar "completado" cuando la tarea no se ha finalizado pueden corregirse mediante instrucciones o comprobarse forzosamente en el Harness mediante verificaciones entre respuesta y estado de herramientas. El módulo de evolución debe localizar primero la causa raíz y luego elegir el objeto de modificación mínimo, más fácil de verificar y revertir. Las fallas ocasionales con evidencia insuficiente no deben activar el aprendizaje de inmediato, sino continuar acumulando muestras.

Esta elección también puede cambiar con el aumento de la experiencia. Una estrategia recién descubierta sirve primero como documento de experiencia para recuperación; tras ser verificada repetidamente en múltiples casos, se puede promocionar a conocimiento. El conocimiento cuenta con tres formas de expresión: las reglas que se pueden describir claramente en lenguaje natural se consolidan como Skills; si los pasos son estables y no requieren capacidad de comprensión de lenguaje natural, se pueden compilar como código de herramienta; si en realidad reflejan amplias capacidades de toma de decisiones implícitas, pueden ingresar al post-entrenamiento.

Validación, Despliegue y Reversión

Todas las modificaciones producen primero capacidades candidatas o Agentes candidatos, en lugar de sobrescribir directamente la versión de producción. Los documentos de conocimiento deben verificar si tras su recuperación mejoran el rendimiento en nuevas tareas, los Prompts y Skills deben comprobar casos límite y regresiones en tareas antiguas, los programas deben ejecutar pruebas en sandboxes y entornos restablecidos, y las actualizaciones de parámetros deben comprobar olvidos, seguridad y tareas fuera de distribución. Tras aprobar la validación, se debe utilizar un despliegue gradual (canary) para observar el tráfico real; si los indicadores clave se deterioran, se revierte automáticamente a la versión segura conocida.

La validación requiere además distinguir entre dos capacidades que suelen confundirse. La capacidad de actualización del Harness (harness-updating) consiste en generar modificaciones duraderas y valiosas a partir de trayectorias; la capacidad de beneficio del Harness (harness-benefit) es la capacidad del Agente de tareas para encontrar, activar y utilizar correctamente dichas modificaciones en ejecuciones posteriores. Una Skill en sí misma puede estar redactada de forma impecable, pero un modelo de tareas más débil podría no cargarla en el escenario adecuado, o ser incapaz de seguirla a largo plazo tras cargarla, haciendo en cualquiera de los casos que el resultado final parezca "sin evolución". Por lo tanto, no se debe utilizar únicamente la puntuación de extremo a extremo para deducir la calidad del actualizador. Los experimentos de reemplazo de modelos de Lin et al. demostraron que la relación entre estas dos capacidades y la capacidad del modelo base no es idéntica²¹; la relación de fortaleza específica requiere mayor verificación en tareas, pero evaluar ambas de forma separada constituye un método de aplicación general.

Tabla 8-3 Métricas de evaluación por capas para la evolución continua

Métrica	Pregunta respondida	Evidencia principal
Validez de modificaciones candidatas	¿El actualizador propuso modificaciones valiosas?	Tasa de aceptación y ganancia de los candidatos en validación independiente
Tasa de activación de artefactos	¿El Agente cargó la nueva Skill, memoria o herramienta en el escenario correcto?	Trayectorias de recuperación, enrutamiento y llamadas a herramientas
Tasa de cumplimiento exitoso	¿Tras la activación se ejecutó según la nueva regla o proceso?	Secuencia de acciones y verificador de procesos
Ganancia en tareas retenidas	¿Mejoró globalmente en tareas que no participaron en la evolución?	Tasa de éxito en held-out, calidad y costo

Durante el diagnóstico se puede fijar el mismo Harness candidato y reemplazar únicamente el modelo de tareas: si un modelo fuerte logra beneficiarse mientras que uno débil nunca activa los nuevos artefactos, el cuello de botella está en la recuperación o enrutamiento; si ambos pueden activarlos pero solo el modelo fuerte los ejecuta correctamente, el cuello de botella reside en el seguimiento de instrucciones o la planificación a largo plazo; si todos los modelos se degradan, se cuenta con mayores razones para dudar de la modificación en sí. Inversamente, también se puede fijar el modelo de tareas y cambiar el modelo encargado de proponer modificaciones, comparando individualmente la calidad del actualizador. Este reemplazo bidireccional de modelos permite ubicar el presupuesto de capacidad de forma más precisa que observar un simple "puntaje total tras la evolución".

La evaluación no es un examen tras finalizar el aprendizaje, sino una parte indispensable del proceso de auto-evolución. La evaluación a largo plazo observa al menos cinco tipos de resultados simultáneamente:

• Regresión (regression): si la nueva experiencia entra en conflicto con otras experiencias existentes y si casos que originalmente se aprobaban sufren retrocesos;
• Capacidad de generalización: la mejora de efectos aportada por la nueva experiencia en escenarios no cubiertos por el conjunto de pruebas;
• Eficiencia de tokens: el costo de tokens consumido para completar la tarea;
• Seguridad: si las reglas, la privacidad y los límites de rechazo derivan a lo largo de la evolución;
• Calidad de ingeniería a largo plazo: si se deterioran la complejidad de mantenimiento, la consistencia arquitectónica, los límites de propiedad, la compatibilidad hacia atrás y la carga futura de migración y depuración.

Resolver únicamente los problemas del caso fallido actual pero sufrir degradaciones en otros casos existentes o nuevos dominios no constituye un aprendizaje continuo exitoso.

Límites del Bucle Cerrado Verificable: Cuando "Completar" No Equivale a "Progresar"

El bucle cerrado anterior se establece más fácilmente en tareas de programación, llamadas a herramientas y cambios de estado de negocio, ya que las pruebas, el estado ambiental o las reglas deterministas pueden entregar retroalimentación rápida. La investigación científica abierta, la planificación estratégica y el diseño de productos complejos son distintos: las señales de evaluación llegan despacio, las respuestas correctas no son únicas y los objetivos realmente relevantes (gusto por la investigación, valor a largo plazo, mantenibilidad) resultan difíciles de traducir en un puntaje instantáneo. En estos casos, el Harness puede ejecutar el proceso de forma impecable pero limitarse a producir de manera estable "cosas que se parecen a resultados", sin impulsar los objetivos reales.

La investigación científica automatizada constituye una prueba de estrés representativa. Trehan y Chopra registraron cuatro intentos de extremo a extremo para pasar de ideas de investigación a artículos finales, en los cuales tres fallaron en las fases de implementación o evaluación y solo uno completó toda la línea de producción²². Los problemas expuestos por estos casos se pueden agrupar en tres categorías. En primer lugar, la deriva de implementación: cuando el plan original se vuelve difícil, el Agente retrocede gradualmente a implementaciones comunes más familiares en los datos de entrenamiento pero alejadas de la hipótesis de investigación. En segundo lugar, el exceso de optimismo epistemológico: cuando la señal sigue siendo simple ruido, el sistema comienza a interpretar resultados, agregar parches y anunciar descubrimientos; mientras que los fallos y resultados negativos se ignoran con mayor facilidad. En tercer lugar, la insuficiencia de juicio implícito: el Agente puede ejecutar experimentos, pero no necesariamente sabe qué línea base es realmente importante, qué anomalía vale la pena rastrear o cuándo se debe abandonar una hipótesis.

Este tipo de tareas no se puede resolver completamente cambiando a un modelo que redacte mejor artículos, sino alterando la estructura de evidencia y supervisión:

• Separación de conclusiones y evidencia: Registrar las fuentes de evidencia por separado para citas, números, métodos y conclusiones; el borrador final es simplemente una forma de presentación del grafo de evidencia. El diseño Chain-of-Evidence de ScientistOne vincula cada tipo de declaración a fuentes auditables, siendo un ejemplo en esta dirección; este enfoque mejora la trazabilidad pero no garantiza automáticamente que el problema de investigación sea valioso²³.
• Conservación de resultados negativos: Los experimentos fallidos, los candidatos rechazados y las razones de parada se escriben en registros inmutables, contando con el mismo estatus recuperable que los resultados exitosos. De lo contrario, el módulo de evolución solo observa soluciones sobrevivientes, explorando repetidamente rutas ya falsadas y aprendiendo a interpretar resultados ambiguos como éxitos.
• Mantenimiento de la diversidad de búsqueda: La búsqueda abierta no debe conservar únicamente la cadena con la puntuación más alta en el momento. El banco de candidatos debe conservar varias ramas temporalmente de baja puntuación pero no homogéneas según diferencias de mecanismo, novedad de código o tipo de hipótesis, evitando que todas las soluciones converjan en una misma plantilla fácil de puntuar.
• Intervención humana en niveles superiores: El papel del ser humano no debe limitarse a hacer clic en "aprobar" antes de invocaciones de herramientas peligrosas, sino incluir la definición de problemas, la revisión de criterios de evaluación, la interpretación de resultados anómalos y la decisión de cuándo detenerse. En tareas con retroalimentación ambigua, estos juicios de alto nivel resultan más difíciles de automatizar y más valiosos que asumir la ejecución paso a paso.

Las mismas limitaciones existen en la ingeniería de software ordinaria: que todas las pruebas unitarias pasen solo demuestra que el comportamiento observable actual satisface las pruebas, pero no garantiza que la base de código siga siendo fácil de mantener meses después. Por ello, la sección anterior incluyó la calidad de ingeniería a largo plazo como un indicador independiente, en lugar de esperar que la tasa de éxito de la tarea actual cubra fortuitamente estas externalidades diferidas. El límite superior de la evolución continua depende en última instancia de si el sistema puede evaluar los objetivos que realmente le importan, y no solo los indicadores sustitutos más fáciles de medir.

Límites de Seguridad de la Evolución Continua

La capacidad de auto-evolución del Agente tiene el potencial de convertir un error puntual en un riesgo a largo plazo. Si las inyecciones de prompts en páginas web, correos u salidas de herramientas se resumen como experiencia, podrían surtir efecto repetidamente a través de sesiones; si paquetes de software maliciosos buscados automáticamente se encapsulan como herramientas, su impacto se propagará desde una ejecución en sandbox a todas las tareas posteriores; mientras que un verificador defectuoso podría aprobar continuamente versiones candidatas que aparentan progreso pero presentan degradación real. Por ende, los sistemas de auto-evolución de Agentes deben limitar "quién puede modificar qué y de dónde provienen los criterios", además de verificar "si es más fuerte".

La primera frontera es la aislación entre evidencia e instrucciones. Las páginas web originales y las salidas de herramientas son evidencias no confiables que no se pueden escribir directamente en Skills u otros componentes, requiriendo un resumen por parte del LLM antes de su escritura. La escritura debe emplear métodos de control de versiones, enviando solicitudes de extracción (pull request) y requiriendo la revisión por parte de un LLM revisor de fuente distinta antes de su integración.

La segunda frontera es la aislación entre capacidades candidatas y capacidades formales. El nuevo conocimiento, Prompts, Skills, programas y parámetros ingresan primero a una zona candidata incapaz de atender tráfico real. El código recién generado y las dependencias externas deben superar además verificaciones de seguridad como sandboxes, inspecciones de permisos, escaneos de cadena de suministro y pruebas de comportamiento. Solo tras aprobar las comprobaciones de seguridad y pruebas de regresión pueden atender tráfico real y convertirse en capacidades formales.

La tercera frontera es que los mecanismos de seguridad no son auto-modificables. El Agente de negocio puede modificar Prompts, Skills, bases de conocimiento y herramientas, pero no puede modificar los verificadores, casos de prueba, umbrales de publicación, registros de auditoría ni copias de respaldo estables que aprueban su propia actualización. De lo contrario, a un Agente le bastaría con reducir los umbrales de prueba o eliminar casos fallidos para disfrazar una degradación como un avance.

Aprendizaje Durante el Sueño: Consolidación, Olvido y Preservación de Capacidades

El "aprendizaje durante el sueño" es una analogía cognitiva de la consolidación fuera de línea y no exige que las tareas se ejecuten realmente por la noche. La responsabilidad principal del Agente en línea es completar la tarea actual y agregar evidencia inmutable; mientras que el proceso de aprendizaje en segundo plano lee un lote de nuevas experiencias durante periodos de inactividad o al cumplir condiciones de control, comparando conclusiones nuevas y antiguas, fusionando duplicados, resolviendo conflictos, proponiendo actualizaciones candidatas y ejecutando regresiones. Separar la recolección de la sistematización evita que un éxito fortuito, un fallo de red o una entrada maliciosa alteren de inmediato las capacidades a largo plazo, permitiendo además al sistema utilizar lotes más grandes y modelos más económicos para completar la sistematización.

Un ciclo típico de aprendizaje durante el sueño consta de cinco pasos:

1. Desencadenamiento: Alcanzar el intervalo de tiempo, la cantidad de nuevas trayectorias, la capacidad de almacenamiento o el umbral de frecuencia de errores, confirmando que no hay tareas en línea de alta prioridad en ejecución;
2. Orientación: Leer la base de conocimiento formal, Prompts, directorios de Skills y sus versiones, comprendiendo las capacidades existentes y los límites inmodificables;
3. Recolección y consolidación: Buscar nuevas señales en las trayectorias evaluadas recientemente, fusionar contenidos duplicados, marcar conflictos y condiciones de aplicación, priorizando la generación de parches locales;
4. Validación y aprobación: Evaluar los candidatos en conjuntos de transferencia, retención y seguridad, registrando escrituras de alto riesgo a la espera de aprobación humana;
5. Poda e indexación: Actualizar los índices de búsqueda, marcando capacidades no utilizadas durante mucho tiempo o refutadas por nueva evidencia como expiradas, archivadas o eliminadas, conservando simultáneamente fuentes y versiones de reversión.

La memoria de usuario es el ejemplo más intuitivo, pero debe distinguirse de la experiencia de acción. La memoria automática de Claude Code mantiene un índice MEMORY.md y archivos detallados divididos por tema para cada proyecto; al iniciar la sesión solo se carga un prefijo acotado del índice, leyéndose el resto del contenido bajo demanda; cuando el índice se aproxima al límite superior, el sistema exige al Agente fusionar o retirar detalles. Esto demuestra que la memoria de texto plano también requiere restricciones de capacidad, carga por capas y sistematización activa, aunque los mecanismos públicos actuales escriben continuamente durante la sesión y no se pueden equiparar simplemente a una tarea fija de fondo nocturno¹¹.

Hermes ofrece un caso de evolución en segundo plano más completo. Divide la información a largo plazo en archivos acotados MEMORY.md y USER.md, búsqueda de conversaciones históricas basada en SQLite/FTS5, Skills cargadas bajo demanda y proveedores de memoria externa opcionales como Honcho. La búsqueda histórica devuelve mensajes originales en lugar de resúmenes previos del LLM, evitando confundir la recuperación y la generación en un paso inauditable. Cuando una tarea incluye múltiples llamadas a herramientas, recuperación tras errores o caminos sin salida, correcciones del usuario o el descubrimiento de flujos de trabajo no evidentes, la revisión en segundo plano puede crear o revisar localmente la Skill; las escrituras de memoria y Skills pueden pasar además por un control de aprobación. Un Curator independiente rastrea el uso, obsolescencia y estado de archivado de las Skills, ejecutando podas deterministas en periodos de inactividad con la opción de ejecutar fusiones por LLM; guardando capturas antes de cambios para poder revertir sistematizaciones erróneas¹². Este caso transforma el "registro - consolidación - validación - poda" de una metáfora en un ciclo de vida operativo de capacidad.

La evolución continua tampoco consiste en dejar crecer indefinidamente el conocimiento, los Prompts y las herramientas. La corrupción del contexto mencionada en el Capítulo 2 reaparece a una escala temporal más amplia: los documentos de experiencia entran en conflicto, los Prompts se ven desbordados por reglas límite, la biblioteca de Skills muestra capacidades duplicadas y múltiples ajustes finos provocan olvido catastrófico. El sistema requiere una sistematización fuera de línea periódica:

• Fusionar experiencias duplicadas, conservando fuentes y versiones;
• Trasladar reglas locales desde Prompts globales hacia Skills de dominio, manteniendo limpios los Prompts globales;
• Mantener Prompts y Skills con estructuras claras, semejantes a un libro de guía para nuevos empleados, evitando listas de reglas estilo "99 mandamientos";
• Volver a verificar herramientas no utilizadas durante mucho tiempo;
• Eliminar conocimiento refutado por nueva evidencia;
• Volver a entrenar LoRA a partir del modelo base original.

Experimento 8-7 ★★★: Evaluar si un Agente se encuentra en evolución continua

Objetivo del experimento: Distinguir entre tres comportamientos a largo plazo: "guardar una retroalimentación", "limitarse a añadir continuamente" y "ser capaz de actualizar, transferir y conservar capacidades", evitando simular un aprendizaje continuo mediante la ejecución repetida del mismo lote de preguntas.

Flujo de tareas en cuatro fases: La fase de aprendizaje entrega tareas con patrones subyacentes compartidos sobre reembolsos, verificación de identidad y políticas de equipaje; la fase de transferencia modifica redacciones, usuarios y entorno local, comprobando si la experiencia antigua sirve en nuevas tareas; la fase de cambio de reglas actualiza el límite de equipaje de 20 kg a 23 kg, exigiendo al sistema reemplazar o retirar el conocimiento antiguo; la fase de mantenimiento vuelve a probar capacidades sin cambios y reglas actualmente válidas, midiendo si las actualizaciones causaron olvido. Se permite actualizar la memoria externa únicamente al finalizar cada tarea con retroalimentación, sin filtrar por adelantado las acciones esperadas de la pregunta actual al Agente.

Grupos de contraste: static no deforma la retroalimentación; append_only recuerda la primera versión de la regla pero no maneja conflictos ni retiros; evolving conserva versiones y reemplaza reglas antiguas con nueva evidencia. Las implementaciones de referencia sirven para verificar si el Harness de evaluación distingue estos comportamientos; los experimentos reales permiten que un LLM recorra el mismo flujo ordenado de 14 tareas, calculando los resultados forzosamente mediante el Harness externo al modelo.

Indicadores y aceptación: Se reportan la precisión y la curva de aprendizaje fase por fase, calculando de forma independiente la precisión de transferencia, el número de tareas requeridas para recuperar la exactitud tras recibir nuevas reglas, la tasa de retención de capacidades antiguas, la tasa de transferencia negativa, la tasa de aprobación de la Rubric de seguridad y los costos de tokens, latencia y almacenamiento. Para sistemas reales que emplean actualizaciones de Prompt, Skill o Harness, se deben registrar por separado la validez de modificaciones candidatas, la tasa de activación de artefactos y la tasa de cumplimiento exitoso, evitando diagnosticar erróneamente un fallo de actualización cuando esta fue correcta pero no se cargó. Un Agente no se considerará en evolución continua si cita reglas derogadas, completa tareas mediante atajos violatorios o sufre olvidos de capacidades previas tras actualizarse, aun si su precisión final es alta.

La implementación correspondiente se encuentra en self-evolution-eval, comparando por defecto tres Agentes de referencia: actualizable, solo adición y estático; con --profile llm un LLM real puede recorrer el mismo flujo de tareas a largo plazo.

Resumen del Capítulo

El aprendizaje continuo se está convirtiendo en una de las capacidades más importantes para los Agentes, pero los modelos actuales aún no pueden llevar a cabo un aprendizaje continuo confiable por sí mismos. La adaptación en contexto durante la inferencia no se consolida automáticamente de forma permanente, mientras que las actualizaciones de parámetros en línea no verificadas amplifican el ruido, las amenazas y la deriva de capacidades. Por ello, la ruta más viable en la etapa actual consiste en construir un sistema de aprendizaje verificable en la periferia del modelo.

El Agente obtiene señales de aprendizaje a partir de la interacción con el entorno y su evaluación, actualizando posteriormente conocimientos, Prompts, Skills, programas o parámetros del modelo según la naturaleza de representación de la capacidad. El sistema puede optimizar además los métodos para gestionar y generar estos artefactos, debiendo priorizar modificaciones locales atribuibles, verificables y reversibles.

La evolución continua requiere separar la ejecución en línea del aprendizaje fuera de línea: registrar evidencias en línea, generar y verificar actualizaciones candidatas fuera de línea y publicar, sistematizar o revertir gradualmente. Este bucle cerrado resulta más confiable en tareas cuyos resultados se pueden verificar automáticamente; para tareas abiertas con objetivos ambiguos y retroalimentación diferida, la intervención humana sigue siendo necesaria en la definición de problemas y en el establecimiento de criterios de evaluación.

Preguntas de Reflexión

1. ★★ Un documento de conocimiento de experiencia cuenta con el respaldo de tres trayectorias exitosas y una fallida. La falla ocurrió en una versión de API más reciente. ¿Cómo debe determinar el sistema si la experiencia fue refutada o si cambiaron sus condiciones de aplicación?
2. ★★ La satisfacción del usuario de un Agente de atención al cliente aumentó, pero también se incrementó la tasa de infracción de reglas. ¿Por qué no se puede tomar la satisfacción como única señal de aprendizaje? ¿Cómo diseñaría los indicadores de salvaguarda (guardrails)?
3. ★★★ Un mismo problema de "falsa promesa" se puede mitigar mediante Prompts, verificaciones en el Harness o entrenamiento de parámetros. ¿En qué evidencias se basaría para elegir la ubicación de la modificación?
4. ★★★ Un Agente puede modificar herramientas y verificadores, pero no debe modificar la raíz de confianza que aprueba sus propias actualizaciones. ¿Cómo dividiría los permisos y las fronteras de código entre ambas partes?
5. ★★ A medida que la base de conocimientos de experiencia crece continuamente, los errores de recuperación y los conflictos de conocimiento anulan las ganancias del aprendizaje. ¿Cómo diseñar mecanismos de versión, vigencia y retiro?
6. ★★★ El aprendizaje de parámetros destaca en estilos de lenguaje natural, pero le cuesta garantizar reglas de negocio rígidas. Diseñe un esquema de evolución continua para atención médica que coordine la colaboración entre parámetros, conocimientos, Skills y restricciones de código.

---

1. Shinn, N., et al. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366, 2023. ↩

2. Mialon, G., et al. GAIA: a benchmark for General AI Assistants. arXiv:2311.12983, 2023. ↩

3. Yu, C., et al. AWorld: Orchestrating the Training Recipe for Agentic AI. arXiv:2508.20404, 2025. ↩

4. Khattab, O., et al. DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv:2310.03714, 2023. ↩

5. Yang, C., et al. Large Language Models as Optimizers. arXiv:2309.03409, 2023. ↩

6. Agrawal, L., et al. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning. arXiv:2507.19457, 2025. ↩

7. Karpathy, A. “We’re missing (at least one) major paradigm for LLM learning … system prompt learning?” X, 11 de mayo de 2025. https://x.com/karpathy/status/1921368644069765486 ↩

8. Anthropic. Skill Creator. 2026. https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md ↩

9. Li, Bojie. PreAct: Computer-Using Agents that Get Faster on Repeated Tasks. arXiv:2606.17929, 2026. ↩

10. Qiu, J., et al. Alita: Generalist Agent Enabling Scalable Agentic Reasoning with Minimal Predefinition and Maximal Self-Evolution. arXiv:2505.20286, 2025. ↩

11. Anthropic, “How Claude remembers your project”, 2026. https://code.claude.com/docs/en/memory ↩

12. Nous Research, Hermes Agent Documentation: Persistent Memory, Skills System, and Curator, 2026. https://hermes-agent.nousresearch.com/docs/user-guide/features/memory ; https://hermes-agent.nousresearch.com/docs/user-guide/features/skills ; https://hermes-agent.nousresearch.com/docs/user-guide/features/curator ↩

13. Wang, G., et al. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291, 2023. ↩

14. Weng, Lilian. “Harness Engineering for Self-Improvement.” Lil’Log, 2026. https://lilianweng.github.io/posts/2026-07-04-harness/ ↩

15. Zhang, Qizheng, et al. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. ICLR 2026. arXiv:2510.04618. ↩

16. Ye, Haoran, et al. Meta Context Engineering via Agentic Skill Evolution. arXiv:2601.21557, 2026. ↩

17. Zhang, Jiayi, et al. AFlow: Automating Agentic Workflow Generation. ICLR 2025. arXiv:2410.10762. ↩

18. Lee, Yoonho, et al. Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv:2603.28052, 2026. ↩

19. Lin, Jiahang, et al. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses. arXiv:2604.25850, 2026. ↩

20. Zhang, Hangfan, et al. Self-Harness: Harnesses That Improve Themselves. arXiv:2606.09498, 2026. ↩

21. Lin, Minhua, et al. Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents. arXiv:2605.30621, 2026. ↩

22. Trehan, Dhruv and Paras Chopra. Why LLMs Aren't Scientists Yet: Lessons from Four Autonomous Research Attempts. arXiv:2601.03315, 2026. ↩

23. Meng, et al. ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence. arXiv:2605.26340, 2026. ↩