Un equipo de la Universidad de Ciencia y Tecnología de China y la Universidad Bautista de Hong Kong publicó EvolveNet el 5 de agosto de 2026—un framework que mejora agentes LLM evolucionando el harness ejecutable que rodea un modelo fijo en cinco dominios de benchmark, sin retrenar pesos.
El harness es el programa ejecutable que construye contexto, invoca herramientas, verifica resultados y se recupera de fallos. EvolveNet argumenta que esta capa—no el modelo base—es el objetivo principal de optimización. Las pruebas en text-to-SQL, codificación de ciencia de datos, programación competitiva, ingeniería de software y flujos de trabajo con agentes mostraron mejora en los cinco, con las mayores ganancias en cargas de trabajo heterogéneas.
Los sistemas anteriores de evolución de harness—Darwin Gödel Machine, Meta-Harness, GEPA—asumen que toda la experiencia de ejecución fluye hacia un único optimizador que evoluciona un harness secuencialmente. Eso funciona en laboratorios. Se rompe cuando la experiencia proviene de usuarios, organizaciones y entornos distintos que no pueden agrupar datos de carga de trabajo. La mayoría de las implementaciones empresariales encajan en esta restricción. EvolveNet distribuye el harness compartido a implementaciones de agentes locales de datos, permite que cada una lo evolucione contra su propia carga de trabajo, y luego recopila solo las adaptaciones de programa resultantes para agregación. Las cargas de trabajo sin procesar permanecen locales.
Fusionar programas modificados de forma independiente no es promediado de parámetros—las adaptaciones entran en conflicto a nivel de alcance. EvolveNet introduce agregación de programa tipada por alcance y guiada por evidencia para resolver conflictos. Los resultados de ablación muestran que las ganancias provienen de componer adaptaciones entre agentes, no de seleccionar entre ellas. Para plataformas multi-tenant, la federación de diffs de programa—no la selección de la mejor variante—impulsa la mejora colectiva.
Un artículo paralelo (arXiv:2605.30621) revela dónde EvolveNet se amortiza: la capacidad de actualización del harness es plana en todos los niveles de modelo. Las actualizaciones Qwen3.5-9B producen ganancias comparables a Claude Opus 4.6. Pero el beneficio del harness es no monótono. Los modelos de nivel medio se benefician más; los modelos de nivel débil no logran activar o seguir artefactos actualizados; los modelos de nivel fuerte se benefician menos que el nivel medio. Para decisiones de stack: el evolucionador no necesita ser su modelo más fuerte, pero el agente que resuelve la tarea sí.
Otro artículo relacionado (arXiv:2605.27276) plantea la restricción claramente. Los sistemas solo harness mejoran "higiene de ingeniería de software—análisis, reintentos, despacho"—y rara vez entregan razonamiento específico de dominio que el modelo base no puede producir. Los agentes de producción pierden desempeño significativo por recuperación de error frágil e invocaciones de herramientas mal estructuradas mucho antes de alcanzar el techo de lo que el modelo base puede razonar. Arreglar el harness primero es lo correcto.
La evolución del harness se entrega como diffs de programa, no pasos de gradiente. Sin cluster GPU, sin retreno, sin intercambio de servicio. Para equipos que ejecutan agentes en modelos API de terceros—donde las actualizaciones de pesos son imposibles—la evolución del harness estilo EvolveNet es toda la superficie de optimización.
Instrumente las implementaciones para capturar adaptaciones de programa por dominio de carga de trabajo. Construya la capa de agregación que las compone. Trate ese pipeline como la palanca principal para mejora de producción antes de programar un fine-tune.