Por Canuto  

Un nuevo trabajo académico propone que los agentes basados en modelos de lenguaje ya no solo dependan de ingenieros humanos para mejorar, sino que puedan ajustar por sí mismos el “harness” que guía su conducta. Las pruebas muestran avances relevantes en tres modelos distintos, sin tocar sus parámetros internos.
***

  • Self-Harness permite que un agente de IA modifique su propio “harness” mediante un ciclo de diagnóstico, propuesta y validación.
  • El sistema elevó la tasa de éxito en Terminal-Bench-2.0 para MiniMax M2.5, Qwen3.5-35B-A3B y GLM-5.
  • Los autores afirman que las mejoras no fueron genéricas, sino adaptadas a debilidades específicas de cada modelo.

La idea de que una inteligencia artificial mejore su rendimiento sin reentrenar el modelo base suele asociarse con mejores prompts, más herramientas o nuevas capas de orquestación. Sin embargo, un nuevo trabajo sugiere que el siguiente salto podría venir de otro lugar: permitir que el propio agente rediseñe el sistema que media su relación con el entorno.

Ese sistema recibe el nombre de “harness”, una capa que puede incluir prompt del sistema, herramientas, memoria, reglas de verificación, políticas de ejecución y mecanismos de recuperación de errores. En otras palabras, no cambia el cerebro del modelo, pero sí las reglas y piezas con las que ese cerebro opera.

En el estudio Self-Harness: Harnesses That Improve Themselves, Hangfan Zhang, Shao Zhang, Kangcong Li, Chen Zhang, Yang Chen, Yiqun Zhang, Lei Bai y Shuyue Hu plantean que un agente basado en LLM puede mejorar su propio harness sin ayuda de ingenieros humanos ni de un agente externo más potente.

La propuesta es relevante para un ecosistema donde los modelos cambian con rapidez y donde el rendimiento de un agente no depende solo del modelo subyacente. También depende de cómo se estructura su interacción con archivos, terminal, herramientas y verificadores.

Para lectores menos familiarizados con el término, el harness funciona como la capa operativa que decide qué debe revisar el agente, cómo ejecuta acciones, cuándo valida resultados y qué hace si una herramienta falla. Dos modelos similares pueden rendir de forma muy distinta si operan bajo harnesses diferentes.

Qué propone Self-Harness y por qué importa

El trabajo parte de una observación sencilla, pero con implicaciones amplias. Los harnesses siguen siendo diseñados en gran medida por expertos humanos, aunque los modelos modernos muestran hábitos, sensibilidades y errores muy distintos entre sí.

Según explican los autores, esa dependencia humana escala mal en un mercado donde aparecen nuevos LLM con rapidez. Un harness útil para un modelo puede ser subóptimo para otro, incluso si ambos compiten en la misma clase de tareas.

Self-Harness busca resolver ese cuello de botella con un bucle iterativo de tres fases. La primera es Weakness Mining, o minería de debilidades, donde el agente se ejecuta sobre tareas reales y luego se analizan sus trazas de ejecución para detectar patrones repetidos de fallo.

La segunda etapa es Harness Proposal. Allí, el mismo modelo, operando bajo su harness actual, propone cambios acotados y diversos que apunten a esos mecanismos de error, en vez de intentar reescribir toda la arquitectura del agente.

La tercera fase es Proposal Validation. Cada cambio candidato pasa por pruebas de regresión y solo se acepta si mejora el rendimiento en un conjunto de tareas sin degradar otro conjunto separado que el proponente nunca vio durante el proceso.

La importancia de este enfoque radica en que no intenta optimizar los pesos del modelo. En su lugar, trata el comportamiento del agente como una combinación entre un modelo fijo y una estructura externa ajustable, lo que podría abaratar y acelerar mejoras prácticas en despliegues reales.

Cómo funciona el ciclo de mejora del harness

En la fase de minería de debilidades, el sistema ejecuta el modelo con un harness inicial sobre un conjunto de tareas “held-in”. Cada intento produce una salida y una traza con mensajes, llamadas a herramientas y resultados del verificador.

Luego, los fallos no se leen como anécdotas aisladas. El sistema los agrupa mediante firmas de error que combinan la causa final detectada por el verificador, el papel causal de la conducta del agente y el mecanismo abstracto que quedó expuesto en la traza.

Esa agrupación busca separar síntomas de mecanismos. Dos fallos pueden terminar en un mismo resultado, como un archivo faltante, pero requerir cambios distintos en el harness si el origen real fue una mala validación, un bucle improductivo o una recuperación deficiente tras un error de herramienta.

Con esas evidencias estructuradas, el modelo entra en modo proponente. En lugar de recibir logs crudos, se le entrega un paquete con patrones de fallo, superficies editables del harness, ejemplos de comportamientos exitosos que deben preservarse y un resumen de propuestas ya intentadas.

El sistema genera varias propuestas en paralelo. Cada una debe ser materialmente distinta, estar asociada a una debilidad concreta y modificar solo la superficie necesaria, como instrucciones de verificación, políticas de runtime, manejo de errores o apoyo a subagentes.

Después llega la validación. Un cambio solo se promueve si mejora al menos una partición de prueba sin empeorar la otra, una regla conservadora que intenta impedir que el agente gane en tareas vistas a costa de romper comportamientos en tareas no vistas.

Las pruebas: tres modelos, mismo benchmark, mejoras consistentes

Los experimentos se realizaron sobre Terminal-Bench-2.0, un benchmark de interacción por terminal en entornos contenedorizados. Los autores usaron un subconjunto fijo de 64 tareas y excluyeron casos dependientes de recursos web inestables o de entradas multimodales no soportadas por el harness inicial.

El punto de partida fue un harness mínimo basado en DeepAgent. Ese harness incluía un prompt breve orientado al benchmark, herramientas básicas de lectura, escritura y edición de archivos, ejecución de shell y unas pocas instrucciones para inspeccionar el entorno, editar de forma concreta y verificar antes de concluir.

Sobre esa base, Self-Harness trabajó con tres modelos de familias distintas: MiniMax M2.5, Qwen3.5-35B-A3B y GLM-5. En todos los casos, se mantuvieron fijos el modelo, el evaluador, el presupuesto, el entorno y el set de herramientas, de modo que el único objeto de cambio fue el harness.

En tareas held-in, MiniMax M2.5 pasó de 43,0% a 50,0%. Qwen3.5-35B-A3B avanzó de 15,1% a 36,0%, mientras GLM-5 subió de 47,7% a 57,0%.

En tareas held-out, donde las trazas nunca fueron mostradas al sistema proponente, MiniMax M2.5 mejoró de 40,5% a 61,9%. Qwen3.5-35B-A3B aumentó de 23,8% a 38,1%, y GLM-5 pasó de 42,9% a 57,1%.

Los autores destacan que eso implica ganancias absolutas de hasta 21,4 puntos porcentuales y mejoras relativas de hasta 138%. También subrayan que ningún harness promovido degradó alguna de las dos particiones bajo la regla de aceptación definida.

Qué cambió en cada modelo y por qué no fue solo un prompt más largo

Uno de los argumentos centrales del trabajo es que Self-Harness no se limitó a agregar instrucciones genéricas. Las modificaciones aceptadas fueron pequeñas, auditables y, sobre todo, distintas para cada modelo.

En MiniMax M2.5, los cambios promovidos incentivaron la creación temprana de archivos de salida requeridos, un manejo más cuidadoso de salidas estructuradas de herramientas y la interrupción de bucles largos de uso improductivo de herramientas. En la práctica, eso ayudó a que el agente concretara artefactos antes de agotar tiempo o presupuesto.

Para Qwen3.5-35B-A3B, el sistema reforzó la verificación temprana de dependencias, la evitación de comandos fallidos repetidos, la ruptura de ciclos de exploración interminable y recordatorios para producir los artefactos exigidos después de errores de herramientas. El énfasis estuvo en la recuperación disciplinada y en evitar insistencias inefectivas.

En GLM-5, las modificaciones se orientaron a preservar configuraciones del entorno entre comandos de shell y a empujar una transición más rápida desde exploración hacia implementación y pruebas. Según los autores, el modelo tendía a desperdiciar presupuesto en exploración o cambios de entorno que no persistían.

El trabajo también señala que Self-Harness puede introducir mecanismos más estructurales. Entre ellos figuran la descomposición basada en subagentes y la creación de middleware, lo que abre la puerta a cambios más organizativos en la forma de resolver problemas, más allá de parches locales a un fallo puntual.

Ese punto es especialmente relevante porque sugiere que el harness podría convertirse en un espacio de optimización tan importante como el prompt. Para sectores como desarrollo asistido por IA, automatización empresarial o agentes Web3, eso implicaría nuevas formas de adaptar sistemas sin tocar el modelo central.

Casos concretos observados en las trazas

El estudio acompaña los resultados con ejemplos antes y después. En una tarea de conteo de tokens para MiniMax M2.5, el harness inicial llevaba al agente a seguir explorando datos incluso después de hallar la configuración relevante, hasta agotar tiempo sin crear el archivo de respuesta requerido.

Con el harness editado, el flujo cambió. El agente identificó el artefacto necesario, localizó el subconjunto correcto, calculó el total, escribió el archivo /app/answer.txt y luego lo leyó de nuevo para verificarlo antes de terminar.

En otra tarea, extract-elf, Qwen3.5-35B-A3B bajo el harness inicial creó un script extractor, pero quedó atrapado entre errores de sobrescritura y edición. Antes de detenerse, incluso eliminó /app/extract.js, lo que provocó el fallo del verificador por ausencia del archivo exigido.

Tras la edición del harness, una instrucción disparada por error de herramienta reorientó la conducta del agente. Entonces recreó el extractor, corrigió la lógica de parsing, produjo el JSON de salida, validó el resultado y dejó el artefacto presente para el verificador.

En GLM-5, una tarea de compilación mostró otro patrón. El harness inicial consumía mucho presupuesto en descargas externas largas y luego racionalizaba comprobaciones fallidas, mientras que el editado introducía operaciones más acotadas, verificaba evidencia de archivos externos y reparaba fallos de validación antes de cerrar.

Estos ejemplos ayudan a entender que la mejora no fue abstracta. Cambió la conducta observable del agente en terminal, algo clave para cualquier empresa que evalúe agentes de software, automatización de procesos o sistemas de soporte técnico basados en LLM.

Alcances, límites y por qué este trabajo puede influir más allá de la IA académica

El estudio no afirma que haya resuelto la auto-mejora abierta de agentes. Los autores remarcan que Self-Harness trabaja sobre cambios acotados, dentro de benchmarks fijos y con reglas de aceptación relativamente conservadoras.

También advierten que los cambios aceptados podrían reflejar patrones específicos del benchmark. Además, el método depende de la calidad de los verificadores y de las trazas registradas, por lo que no cualquier entorno real ofrecería de inmediato la misma claridad para diagnosticar y promover ediciones.

Aun así, la señal es potente. Si un modelo fijo puede traducir sus propios errores recurrentes en cambios útiles de harness, la ingeniería de agentes podría desplazarse desde la intuición manual hacia ciclos más automáticos, medibles y reversibles.

Para industrias vinculadas con IA, software y automatización, eso puede tener consecuencias prácticas. Un despliegue corporativo no siempre necesita un modelo más grande o más costoso si antes puede obtener avances ajustando reglas de verificación, recuperación, memoria y uso de herramientas.

La idea también dialoga con debates más amplios sobre agentes autónomos. En vez de imaginar una IA que se reescribe sin control, el trabajo propone una vía más delimitada: mejorar el andamiaje operativo bajo evidencia conductual, con registro auditable y pruebas de no regresión.

Ese matiz importa. En un momento en que los mercados siguen de cerca cualquier avance en agentes de IA, herramientas de programación y automatización inteligente, Self-Harness sugiere que parte de la ventaja competitiva futura podría no venir solo del modelo, sino de la capacidad del agente para aprender a rediseñar su propio entorno operativo.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados