Weng Li, ex vicepresidenta de Seguridad de OpenAI y cofundadora de Thinking Machines Lab, ha publicado una nueva entrada en su blog.
Esta vez discute la autoevolución de la IA y propone una ruta realista:
No necesariamente comenzar con el modelo reescribiendo directamente sus propios pesos, sino empezar primero con el Harness.

Esta entrada del blog se titula «Harness Engineering for Self-Improvement» (Ingeniería de Harness para la Automejora).

Aquí, Harness puede entenderse simplemente como el sistema de ejecución externo al modelo, que determina cómo el modelo llama a herramientas, gestiona el contexto, lee/escribe archivos, divide tareas, llama a subagentes, verifica resultados y reflexiona sobre los fracasos.
El investigador de DeepSeek, Cui Tianyi, también lo compartió de inmediato, destacando:
La autoevolución en la dirección del Harness es una dirección tan prometedora como la autoevolución en la dirección del modelo.

También propuso que Skill es una forma bastante básica de autoevolución del Harness: autoevolución a nivel de prompt.
El blog original contiene una cantidad inmensa de información, ¡así que prepárense mentalmente!

La autoevolución podría ocurrir primero en la capa del Harness
El concepto central discutido por Weng Li en este blog es RSI (Recursive Self-Improvement), Automejora Recursiva.
Este concepto inicialmente tenía una fuerte connotación de AGI, refiriéndose a un sistema inteligente capaz de mejorar los mecanismos que generan su propia inteligencia, produciendo así sistemas sucesores más fuertes.
Pero Weng Li, en esta entrada, desglosa el problema de una manera más ingenieril.
En los sistemas de IA actuales, la automejora no necesariamente significa solo que el modelo reescriba directamente sus propios pesos.
También puede significar que el modelo mejore los flujos de entrenamiento, investigación y despliegue, ayudando así a que la siguiente generación de sistemas se desempeñe mejor en tareas reales.

△
Y el Harness es la capa más crítica dentro del sistema de despliegue.
Al hablar de Agent en el pasado, la fórmula común era «LLM + memoria + herramientas + planificación + acción».
Pero en la opinión de Weng Li, el Harness ya no son solo unos pocos módulos dentro de los primeros marcos de Agent, sino que se acerca más al diseño de sistemas de software y tiempo de ejecución.
Determina cómo el modelo observa el entorno, cómo actúa, cómo gestiona el contexto, cómo guarda el estado, cómo evalúa resultados, y también determina si el modelo puede iterar continuamente dentro de una tarea larga.
Por lo tanto, su juicio es: la ruta de autoevolución más factible a corto plazo puede no ser que el modelo reescriba directamente su propio cerebro, sino que el modelo comience a optimizar la forma en que obtiene respuestas.
De la Ingeniería de Contexto al Self-Harness, la optimización avanza capa por capa
Weng Li revisa una serie de investigaciones recientes, mostrando una tendencia clara:
El objeto de optimización está pasando del contexto, al flujo de trabajo, y profundizando gradualmente en el propio Harness.
La cadena de progresión es: prompt → contexto estructurado → flujo de trabajo → código del harness → código del optimizador.
A medida que los modelos se vuelven más fuertes, los objetos que pueden ser optimizados también se vuelven más abstractos y generales.
La primera capa es Context Engineering (Ingeniería de Contexto).
El problema más básico es: cuando un Agent realiza tareas largas, el contexto se acumula cada vez más y rápidamente se sale de control.
Weng Li menciona aquí dos trabajos representativos: ACE y MCE.
ACE (Agentic Context Engineering) trata el contexto como un «manual de operaciones» que se actualiza continuamente, en lugar de un prompt que se alarga más y más.

Funciona con tres roles coordinados: el Generator genera trayectorias de tareas, el Reflector extrae puntos clave de trayectorias exitosas y fallidas, y el Curator organiza estos puntos en entradas estructuradas y las actualiza de manera incremental en el manual.
MCE (Meta Context Engineering) va un paso más allá.
Divide «cómo gestionar el contexto» y «qué poner específicamente en el contexto» en dos niveles de optimización: el nivel externo evoluciona las habilidades para gestionar el contexto, y el nivel interno usa esta habilidad para optimizar el contexto de tareas específicas.

Weng Li cree que, comparado con ACE que aún requiere diseñar reglas de actualización manualmente, MCE da otro paso hacia una «memoria autogestionada».
La segunda capa es Workflow Design (Diseño de Flujo de Trabajo), que resuelve «cómo debe trabajar el modelo».
Weng Li da varios ejemplos:
AI Scientist construyó una línea de producción completa para investigación científica, desde proponer ideas, escribir código, ejecutar experimentos, analizar resultados, hasta escribir artículos y revisión por pares.

ADAS va aún más lejos, tratando el «diseño del flujo de trabajo del Agent» como un problema de optimización que puede ser buscado, permitiendo que un meta-agente proponga continuamente nuevos diseños de flujo de trabajo y sea evaluado.

AFlow representa el flujo de trabajo como un grafo y usa búsqueda de árbol Monte Carlo para encontrar estructuras de grafo mejores.

La progresión en esta línea es: inicialmente los humanos ingenierizan el flujo de tareas, luego el modelo participa en el diseño del flujo, y finalmente, la estructura del flujo misma entra en el espacio de búsqueda.
Es decir, el objeto de optimización ya no es solo un prompt individual, sino cómo todo el Agent organiza sus acciones.
La tercera capa es Self-Improving Harness (Harness de Automejora).
En este nivel, el modelo no solo usa el Harness para completar tareas, sino que comienza a analizar dónde falla el Harness y propone modificaciones al mismo.
Weng Li destaca especialmente trabajos como Self-Harness, cuyo ciclo es muy claro.

El primer paso es Weakness Mining (Minería de Debilidades).
El sistema primero recopila las trayectorias dejadas por el Agent al ejecutar tareas, incluyendo llamadas a herramientas, registros de errores, resultados fallidos, retroalimentación del validador, etc. Luego extrae patrones de fallo recurrentes de estos datos.
Por ejemplo, el modelo siempre omite archivos en cierto tipo de tareas, siempre repite intentos de reparación ineficaces tras cierto tipo de fallos en pruebas, o siempre pierde restricciones clave cuando el contexto se alarga.
El segundo paso es Harness Proposal (Propuesta de Harness).
Basándose en estos patrones de fallo, el modelo propone modificaciones de pequeño alcance al Harness.
El énfasis está en «pequeño alcance» y «verificable».
La información que el modelo puede ver incluye: qué partes del Harness actual pueden modificarse, los patrones de fallo específicos, qué «comportamientos correctos» deben preservarse y el registro de modificaciones ya intentadas previamente.
Las propuestas deben enfocarse en problemas reproducibles que puedan resolverse con cambios de pequeño alcance, y deben mantenerse diferenciadas entre sí.
El tercer paso es Proposal Validation (Validación de Propuestas).
Las modificaciones candidatas no pueden integrarse directamente; deben pasar por pruebas de validación. Solo después de confirmar que realmente mejoran el rendimiento y no introducen regresiones evidentes, se convierten en parte de la siguiente versión del Harness.
Weng Li menciona que este proceso, ejecutado en modelos como MiniMax M2.5, Qwen3.5, GLM-5 en Terminal-Bench-2, efectivamente aprendió configuraciones de Harness diferentes, específicas para los puntos débiles de cada modelo.
Sin embargo, también señala directamente el riesgo: una vez que se permite al programa modificar el código a nivel de sistema, el límite abstracto corre el riesgo de romperse. El control de permisos y las capas de seguridad deben permanecer fuera de este ciclo, y el viejo problema del reward hacking persiste.
Además, Weng Li menciona aún más Evolutionary Search (Búsqueda Evolutiva).
Si Self-Harness se parece más a reparar su propio sistema de trabajo a partir de fallos, la búsqueda evolutiva convierte directamente al Harness en un objeto buscable.
Su lógica se parece más a la selección natural:
Primero se generan múltiples Harness candidatos, permitiendo que el modelo los modifique basándose en versiones existentes. Luego se evalúa el rendimiento usando benchmarks o validadores, se retienen las mejores versiones, se eliminan las peores, y se continúa con la siguiente ronda.
Ella menciona especialmente DGM (Darwin Gödel Machine): un coding agent que modifica directamente su propio repositorio de código del Harness.

En los experimentos, usando Claude 3.5 Sonnet como modelo base y partiendo de una configuración inicial simple, el agente evolucionado por DGM tuvo un efecto sorprendente:
El rendimiento en SWE-bench Verified mejoró del 20% al 50%;
En Polyglot, pasó del 14,2% al 30,7%;
Alcanzando e incluso superando a agentes diseñados manualmente.

Esto indica que, incluso sin tocar los pesos del modelo, el Harness en sí mismo ya puede ser un espacio de búsqueda para mejorar las capacidades.
Sin embargo, este tipo de método es más adecuado para tareas con evaluación automática, como código, algoritmos o kernels de GPU.
Si la tarea involucra criterio de investigación, calidad de producto a largo plazo o colaboración organizacional compleja, la evaluación será mucho más lenta y ambigua.
El Harness se volverá más fuerte, pero aún tiene límites
Weng Li no cree que el Harness sea una ruta sustitutiva del entrenamiento del modelo; su juicio es más bien que ambos se refuerzan mutuamente.
Un Harness lo suficientemente maduro puede hacer funcionar el ciclo de investigación de automejora del modelo; y modelos más inteligentes pueden prevenir el sobre-diseño del Harness, manteniendo la sostenibilidad del sistema.
A largo plazo, muchas mejoras del Harness podrían terminar «internalizadas» en el comportamiento mismo del modelo, de manera similar a cómo las técnicas manuales de ingeniería de prompts se han vuelto menos importantes a medida que mejoran las capacidades de seguimiento de instrucciones y razonamiento de los modelos.
Pero el acto de «especificar claramente objetivos, restricciones, contexto y criterios de evaluación» nunca ha desaparecido.
Sin embargo, tampoco elude las limitaciones actuales en el camino hacia la RSI:
Los evaluadores son demasiado débiles y ambiguos. Los ciclos de automejora que actualmente funcionan son básicamente tareas con retroalimentación clara, rápida y objetiva, como escribir código o resolver problemas matemáticos. El criterio de investigación, la innovación o el valor científico a largo plazo son casi imposibles de cuantificar.
Problemas del ciclo de vida del contexto y la memoria. Cuanto más autónoma e independiente es la tarea, más memoria necesita gestionar. Weng Li cree que esto podría convertirse en parte de la inteligencia misma en el futuro, no solo quedar en el nivel del sistema de software.

△
Los resultados negativos se pasan por alto fácilmente. Los investigadores naturalmente prefieren publicar resultados exitosos. Los modelos entrenados en datos masivos basados principalmente en casos de éxito pueden no ser muy hábiles para juzgar cuándo abandonar una hipótesis o reportar honestamente un fracaso.
Colapso de la diversidad. Los ciclos de tipo evolución y aprendizaje por refuerzo tienden a reutilizar repetidamente patrones de alta recompensa conocidos. Sin mecanismos adicionales para prevenirlo, la población puede colapsar gradualmente en variantes de la misma solución.
Reward hacking. Los ciclos de automejora optimizarán cualquier señal dada: si la recompensa proviene de pruebas unitarias, el modelo puede sobreajustarse a las pruebas; si proviene de un modelo juez, puede aprender a «complacer» específicamente al juez; si proviene de puntuaciones de rankings, puede aprender a explotar las vulnerabilidades del ranking mismo.
La contradicción entre salud a largo plazo y éxito a corto plazo. Tomando como ejemplo a un agente de codificación: ya pueden mejorar sustancialmente la productividad diaria en ingeniería de software, pero el objetivo de optimización sigue siendo mayormente a corto plazo: poder completar la tarea inmediata, más que poder proteger la salud a largo plazo de un repositorio de código mantenido conjuntamente por cientos o miles de ingenieros.
La mantenibilidad, los límites de responsabilidad, los costos de migración, la carga futura de depuración: estos estándares aún no se consideran en el entrenamiento básico en un entorno controlado.
El papel de los humanos. La opinión de Weng Li es: los humanos no serán expulsados del ciclo, sino que se moverán hacia «fuera del ciclo» — proporcionando supervisión en el momento adecuado y al nivel de abstracción adecuado, lo cual es también un problema que debe considerarse claramente en el diseño del sistema.
En el pasado, la competencia entre modelos grandes dependía principalmente de parámetros, datos, potencia de cálculo y capacidad de razonamiento.
Pero ahora, otra variable es cada vez más difícil de ignorar: el Harness.
Un mismo modelo, colocado en diferentes Harness, puede mostrar capacidades completamente diferentes — esto ya ha pasado de ser una observación de unos pocos a un consenso de la industria.
Como se puede ver en el blog de Weng Li, «¿Cuál es la entrada de ingeniería más realista para la autoevolución de la IA?» será un punto clave de discusión en la próxima etapa.
Blog original: https://lilianweng.github.io/posts/2026-07-04-harness/
Enlace de referencia: https://x.com/tianyi/status/2074475185957380379
Este artículo proviene del WeChat Official Account "Qubit", autor: Ting Yu







