LongWoF-Bench: Evaluación de una orientación procedimental evolucionada para tareas verificables de flujo de trabajo largo

Capítulo 1: Introducción

A medida que los modelos grandes mejoran en el modelado de contexto largo, el uso de herramientas y la ejecución de código, sus aplicaciones se están expandiendo desde la respuesta a preguntas aisladas hasta escenarios complejos que requieren una secuencia de operaciones. En una tarea de Markdown-to-Repository, por ejemplo, un modelo debe leer un documento de requisitos y un código base existente, producir un plan de implementación y una lista de tareas, modificar el código y ejecutar pruebas para validar el resultado. En una tarea basada en reglas, el modelo debe mantener un estado intermedio, realizar un razonamiento de varios pasos y, en última instancia, devolver un resultado válido que satisfaga todas las restricciones.

A estas tareas las llamamos tareas de flujo de trabajo largo de un extremo a otro. Formalmente, dada una entrada inicial $(x)$, un entorno procesable $(E_0)$, un conjunto de restricciones $(C)$ y un verificador $(V)$, el modelo debe generar una secuencia de acciones interdependientes $a_1,a_2,\ldots,a_T$. Estas acciones impulsan transiciones de estado $E_t=f(E_{t-1},a_t)$ y, en última instancia, producen un resultado $(y)$. Una tarea es un flujo de trabajo largo de un extremo a otro cuando las acciones posteriores dependen del estado o de artefactos intermedios creados por acciones anteriores y el éxito está determinado uniformemente por la condición terminal verificable $V(x,E_T,y,C)=1$. Aquí, "flujo de trabajo largo" se refiere a la dependencia entre etapas y al estado en continua evolución, no simplemente a la longitud de entrada, la longitud de salida o el tiempo de ejecución.

Bajo restricciones explícitas de producción, el modelo debe convertir múltiples juicios u operaciones dependientes en un resultado final que un programa o regla pueda verificar con precisión. Un "flujo de trabajo" no siempre significa llamadas a herramientas externas. En las tareas de código y agente, puede incluir la lectura de archivos de entrada, obedecer un contrato CLI, producir artefactos JSON/TXT específicos y pasar pruebas ocultas. En tareas matemáticas y de reglas, puede implicar seleccionar una fórmula, manejar límites, aplicar prioridad de reglas y normalizar el formato de respuesta. En todos los casos, el éxito depende tanto de comprender la tarea como de implementar correctamente una serie de restricciones en un entregable verificable.

Para estudiar esta capacidad, recurrimos a tareas de programación de SkillsBench (Li et al., 2026) y al marco de recuperación de reglas de GuideBench (Diao et al., 2025). A partir de ambos, identificamos tipos comunes de flujos de trabajo largos y las dificultades que surgen al combinar restricciones, y presentamos LongWoF-Bench. Sus 778 tareas verificadas cubren generación de código (code_generation), razonamiento matemático (math_reasoning), seguimiento de reglas (rule_following) y orquestación de agentes (agent_env_synth). El código exige programas y pruebas ocultas; las matemáticas, respuestas breves exactas y normalización; las reglas, prioridades y decisiones discretas; y los entornos de agentes, interfaces de paquetes, múltiples archivos y verificación con pytest. Un manifiesto común, evaluadores ocultos y un protocolo estricto permiten comparar todas las tareas dentro del mismo marco de finalización de flujos de trabajo.

El punto de referencia aborda tres preguntas de investigación:

• RQ1: ¿Qué tan confiables son los modelos actuales en tareas de flujo de trabajo largo, verificables por máquina y entre vías?
• RQ2: ¿Cómo afectan las indicaciones auxiliares como Skill y Gene a la tasa de aprobación de tareas y al consumo de tokens?
• RQ3: ¿Qué tipos de tareas, tipos de modelos y fuente de construcción de Gene se benefician más de la orientación procedimental?

Estas preguntas examinan la capacidad de un modelo para completar tareas de forma independiente, utilizar conocimientos de procedimientos y compensar la aplicabilidad y el costo de diferentes métodos de asistencia.

Para responderlas, evaluamos varios modelos sobre las mismas tareas, entornos de ejecución y evaluadores ocultos bajo tres condiciones: sin contexto auxiliar (no_context), un manual de tareas predefinido (Skill) y un mensaje de procedimiento derivado de la experiencia, Gene (Wang et al., 2026). La Skill describe el flujo de trabajo, el uso de la interfaz, el procedimiento de ejecución de reglas y los errores comunes. Gene utiliza campos estructurados para representar el patrón de la tarea, las señales de aplicabilidad, la estrategia de ejecución, las comprobaciones previas y las restricciones críticas. Los Genes se construyen a partir de trayectorias modelo que pasaron la verificación o, cuando no existe una trayectoria exitosa, a partir de señales del maestro proporcionadas por una solución de referencia. Todos los activos auxiliares se someten a una auditoría de fugas para que las respuestas y otra información crítica no queden expuestas en el mensaje. Comparamos tasas de aprobación estrictas y uso de tokens bajo las tres condiciones, luego agrupamos los resultados por tipo de tarea, tipo de modelo y fuente de Genes.

El experimento arroja tres conclusiones principales. En primer lugar, incluso el modelo más potente, Opus 4.8, alcanza sólo una tasa de aprobación estricta del 20,2% sin contexto auxiliar, lo que demuestra que los modelos actuales todavía no pueden completar estas tareas de largo flujo de trabajo de manera confiable. En segundo lugar, la asistencia procesal mejora el desempeño, pero sus beneficios y costos difieren según la forma. En general, Gene proporciona una guía de tareas más eficaz con menos tokens que Skill. En tercer lugar, el beneficio no es uniforme: cambia sustancialmente según el tipo de tarea, la capacidad del modelo y la fuente de construcción del Gene. Por lo tanto, el valor del conocimiento procedimental depende de qué tan bien coincida tanto con el modelo como con la tarea.

El informe hace tres contribuciones correspondientes a esas cuestiones.

• Primero, creamos un punto de referencia unificado para tareas de flujo de trabajo largo de un extremo a otro. LongWoF-Bench cubre cuatro tipos de tareas con 778 tareas verificables y utiliza evaluadores ocultos además de reglas de salida estrictas para medir la finalización de cada tarea.
• En segundo lugar, presentamos e implementamos Gene como un mensaje auxiliar estructurado. En comparación con un manual de Skills más completo, Gene representa experiencia procesal en campos más cortos y auditables. Bajo un proceso de evolución definido, extrae la información de mayor valor del flujo de ejecución de un modelo sólido y empaqueta esa información como un mensaje auxiliar. Esto convierte la asistencia de un mensaje largo y ordinario en una condición experimental que puede compararse y analizarse.
• En tercer lugar, comparamos sistemáticamente tres condiciones entre modelos y pistas de tareas: sin contexto auxiliar, Skill y Gene. Sin asistencia inmediata, incluso Opus 4.8 alcanza sólo una tasa de aprobación estricta del 20,2%, lo que confirma que el punto de referencia sigue siendo un desafío. Los Genes evolucionados son más valiosos que las Skills para resolver tareas de flujo de trabajo prolongado y consumen menos tokens.

Capítulo 2: Construcción de LongWoF-Bench

2.1 Diseño de tareas de referencia

2.1.1 Creación de tareas de flujo de trabajo largo de un extremo a otro

La unidad de tareas principal de LongWoF-Bench consta de una especificación de tarea pública, un espacio de entrega y un verificador oculto:

La especificación pública $(S)$ proporciona la entrada inicial $(x)$, el entorno procesable $(E_0)$ y el conjunto de restricciones $(C)$. El espacio de entrega $\mathcal{Y}$ describe lo que el modelo debe enviar, y $(V)$ es un verificador oculto al modelo. El modelo realiza una secuencia de acciones interdependientes $a_1,\ldots,a_T$, impulsando el entorno de $(E_0)$ a $(E_T)$ y produciendo un entregable final $y\in\mathcal{Y}$. La tarea pasa cuando $V(x,E_T,y,C)=1$.

Considere la tarea LongWoF-Bench que solicita a un modelo que cree un código de orquestación para un sistema de control de crucero adaptativo. Su especificación $(S)$ incluye archivos de parámetros del vehículo, 150 segundos de datos de sensores y requisitos de interfaz y rendimiento para los modos de crucero, seguimiento y frenado de emergencia. Su espacio entregable $\mathcal{Y}$ incluye archivos de código para el controlador PID, el sistema de control de crucero y el simulador, junto con resultados de ajuste, datos de simulación y un informe de análisis. El modelo debe implementar el controlador y la lógica de cambio de modo, ajustar los parámetros PID, ejecutar la simulación completa y mantener todos los resultados consistentes.

El verificador oculto $(V)$ comprueba la existencia del archivo y varias propiedades adicionales. Importa e invoca las clases enviadas, vuelve a ejecutar la simulación, verifica los modos de control, las interfaces y los formatos de salida, y verifica las medidas de rendimiento, incluidos el tiempo de subida, el sobreimpulso, el error de estado estable, la distancia de seguimiento segura y los límites de aceleración. También cambia los parámetros PID y verifica que el comportamiento del sistema cambie en consecuencia. Esto distingue un sistema de control en funcionamiento de una salida de simulación codificada.

Por lo tanto, un programa estructuralmente completo o superficialmente plausible es insuficiente. El código final y cada entregable derivado deben satisfacer conjuntamente $V(x,E_T,y,C)=1$.

Esta definición también establece los criterios de admisión para las tareas de referencia. Primero, una tarea debe tener una especificación pública describible de la cual el modelo pueda obtener la información necesaria para resolverla, a través de entradas rápidas y accesibles, interfaces invocables o instrucciones de salida. En segundo lugar, la tarea debe admitir la ejecución automática o la coincidencia exacta para que el resultado no dependa de una calificación subjetiva. En tercer lugar, el evaluador debe separar la información visible y oculta del modelo. El modelo puede ver el mensaje, los archivos de entrada, las interfaces de paquetes accesibles, el protocolo de salida y la Skill o Gene inyectado bajo la condición relevante. No debe ver datos de pruebas ocultos, respuestas de oro, lógica de verificación interna, soluciones de referencia o constantes privadas disponibles solo para el evaluador. Este límite es necesario para que la comparación posterior sea justa.

2.1.2 Pistas de flujo de trabajo de LongWoF-Bench

La versión actual de LongWoF-Bench conserva 778 tareas verificadas. Las cuatro vías de evaluación se diferencian de la siguiente manera:

Las pistas producen diferentes tipos de resultados, pero todos requieren que el modelo convierta las restricciones de la especificación pública en un resultado verificable. Las fallas de código y agente aparecen durante la ejecución del programa y las comprobaciones de archivos. Las matemáticas y las fallas en las reglas aparecen a través de la normalización de respuestas y la coincidencia exacta. El marco compartido evita que esas diferencias desaparezcan en una puntuación agregada y permite que un análisis posterior revele qué tareas dependen más de una orientación procedimental externa.

2.1.3 Síntesis de tareas LongWoF-Bench

Las tareas siguen un diseño de “mensaje público más evaluación oculta”. A partir de una semilla predefinida, cada tarea recibe un task.md visible en el modelo que explica el objetivo, los formatos de entrada y salida, y los datos disponibles. El directorio de tareas también contiene datos de prueba, una solución de referencia, salida de oro oculta y un evaluador automático. Durante la evaluación formal, el modelo recibe solo el mensaje público y cualquier contexto auxiliar para su condición asignada. Después de producir una respuesta o programa, el evaluador oculto lo ejecuta, compara los resultados, registra si fue aprobado y mide el uso de tokens. Por lo tanto, el punto de referencia mide si un modelo realmente puede completar una tarea bajo reglas complejas, procesamiento de datos, ejecución de código y restricciones de formato, no si recuerda una respuesta de opción múltiple.

A diferencia de un punto de referencia convencional de formato único, LongWoF-Bench pregunta constantemente si el entregable de un extremo a otro funciona. Los programas de código y agente deben ejecutarse. Las respuestas de matemáticas y reglas deben analizarse y combinarse bajo un formato estricto. Experimentos posteriores pueden comparar de manera justa ningún contexto auxiliar, Skill y Gene porque las tres condiciones enfrentan las mismas tareas y verificadores; sólo cambia la información auxiliar suministrada al modelo.

2.2 Construcción de indicaciones auxiliares: Skill y Gene

Muchas fallas en flujos de trabajo complejos ocurren no porque el modelo carezca de todo el conocimiento relevante, sino porque no logra invocar el proceso de ejecución correcto de manera consistente. Es posible que sepa leer los datos pero pase por alto el protocolo de salida; comprende una regla pero no verifica primero una anulación de mayor prioridad; o elegir un algoritmo común sin darse cuenta de que una condición de contorno anula su estrategia predeterminada. El paso fallido exacto no se conoce de antemano, por lo que la ejecución de la tarea debe generar experiencia procesal genuinamente útil que pueda brindarse como ayuda.

Introducimos un nuevo mensaje auxiliar: un Gene basado en el protocolo GEP (EvoMap, 2026a). A diferencia de una Skill convencional, Skill se asemeja a un manual de tareas predefinido, mientras que Gene se asemeja a una experiencia de procedimiento destilada de una ejecución exitosa (EvoMap, 2026b). La Skill es un documento auxiliar escrito por humanos definido antes de que se ejecute la tarea y no puede adaptarse al proceso de ejecución del modelo. Gene resume la experiencia procesal que un modelo mismo destila bajo las reglas de Gene mientras ejecuta la tarea.

Gene tiene un objetivo diferente. No intenta cubrir toda la información básica. En cambio, comprime una ruta exitosa verificada en un mensaje de procedimiento estructurado: el patrón del problema, las señales que muestran cuándo se aplica la estrategia, los pasos críticos de ejecución, los límites que necesitan verificaciones previas y las verificaciones requeridas antes del envío. Los Genes de este experimento provienen de dos fuentes. Uno es una trayectoria de modelo exitosa que pasó la verificación de la tarea. El otro, que se utiliza cuando no existe una trayectoria exitosa, se deriva de una señal del maestro proporcionada por la solución de referencia. El primero representa más directamente la experiencia extraída del éxito real: conserva la parte que cambió la ruta de ejecución en lugar de escribir otro manual más extenso.

Las dos indicaciones también se sintetizan de manera diferente:

• Skill es un manual de tareas bastante completo que cubre el tipo de tarea, el proceso recomendado, las reglas de interfaz, los errores comunes y los requisitos de salida. En esta versión de referencia, las Skills son principalmente reescrituras de material de construcción de tareas y solución de referencia, seguidas de auditoría. Por lo tanto, son condiciones de instrucción sólidas, en lugar de Skills al estilo del mercado generadas únicamente a partir del estímulo público.
• Gene es más corto y puede entenderse como un mensaje de ejecución comprimido a partir de una experiencia exitosa. Cuando un modelo encuentra una solución satisfactoria utilizando el mensaje público y la retroalimentación del verificador, el Gene se destila de esa trayectoria. Si el primer intento falla, la siguiente implementación muta: el modelo recibe una tarea pública truncada, su intento anterior y comentarios de ejecución saneados, luego produce una solución corregida. El proceso se repite hasta que el verificador pasa o se agota el presupuesto de implementación. Si la exploración nunca tiene éxito, el proceso actual recurre a la destilación de la solución de referencia.

Considere un ejemplo sencillo. Una tarea pide al modelo que seleccione una acción de limpieza para el equipo después de producir una “pasta de girasol y sésamo”, utilizando reglas de riesgo de residuos para una línea de procesamiento de alimentos. La dificultad es el orden de las reglas, no el formato de salida. Ambos ingredientes son semillas y se coprocesan hasta obtener una pasta homogénea. El modelo debe aplicar prioridad de exención antes de calcular la puntuación de riesgo máxima y asignarla a un umbral.

El caso muestra la distinción. Skill ofrece un proceso completo y advierte al modelo que no omita exenciones, pero aún deja la decisión de prioridad crítica al modelo. Gene comprime la corrección aprendida después de dos fallas del modelo fuerte en una orden de ejecución más estricta: primero aplique la exención de coprocesamiento para que el recargo por alérgeno de sésamo no se agregue directamente al riesgo más alto; luego tome la puntuación máxima posterior a la exención y asignela al nivel medio. Gene no es simplemente un manual más breve. Convierte el paso más propenso a errores y su orden correcto en una guía de procedimiento disponible en una sola ejecución.

Así, Skill proporciona instrucción estática, mientras que Gene proporciona una estrategia de ejecución comprimida; La Skill es una señal, mientras que el Gene es un camino ya recorrido. Las tres condiciones experimentales ahora se pueden definir con precisión:

• no_context mide la finalización de un extremo a otro utilizando solo el mensaje público;
• with_skill mide si el modelo puede utilizar una descripción de tarea relativamente completa pero estática;
• with_gene mide si el modelo puede utilizar una guía de procedimiento más corta y estructurada derivada de una experiencia exitosa o una señal de un maestro.

Capítulo 3: Resultados experimentales

3.1 Configuración experimental y definiciones estadísticas.

Evaluamos siete modelos en las tareas 778 LongWoF-Bench. El juego contiene 127 agent_env_synth, 341 code_generation, 151 math_reasoningy 159 rule_following tareas. Cada modelo funciona bajo tres condiciones:

• no_context: el modelo recibe solo el mensaje público;
• with_skill: el mensaje público se complementa con una Skill completa para la tarea actual;
• with_gene: el mensaje público se complementa con un Gene procesal.

La métrica principal es la estricta tasa de aprobación de tareas. Una tarea cuenta como aprobada solo cuando pasan todos los puntos de control y el verificador regresa. passed=true. El coste de tokens es la suma de los tokens de entrada, salida y pensamiento registrables.

Distinguimos cuatro conjuntos de evaluación por fuente de Gene:

El modelo utilizado para construir Genes en este experimento es Claude Opus 4.8. La estrategia de evolución aumenta el esfuerzo de pensamiento de débil a fuerte a lo largo de los intentos de implementación en lugar de fijar un nivel de pensamiento y cambiar un coeficiente de temperatura convencional. El modelo fuerte resuelve primero la tarea pública. Después de una falla, revisa la solución utilizando comentarios de verificadores desinfectados, durante un máximo de tres implementaciones. Tan pronto como un lanzamiento pasa el verificador, se destila un Gene de esa trayectoria exitosa.

3.2 Resultados experimentales generales (RQ1: ¿Qué tan confiables son los modelos actuales en tareas de flujo de trabajo largo, verificables por máquina y transversales?)

La siguiente tabla informa los resultados completos del subconjunto evolucionado de Opus. Bajo no_context, el modelo más potente, Claude Opus 4.8, pasa sólo el 54,8% de las tareas; los demás modelos oscilan entre el 31,7% y el 47,6%. Por lo tanto, incluso el mejor modelo falla en casi la mitad de las tareas durante una ejecución sin ayuda. Los modelos actuales no manejan estos flujos de trabajo transversales verificables por máquina de manera confiable por sí solos y aún se benefician de indicaciones auxiliares.

Cada resultado de with_opus_gene aquí utiliza un Gene destilado de una trayectoria de ejecución real verificada producida por Claude Opus 4.8, en lugar de una reescritura de la respuesta de referencia. El Opus Gene supera claramente a Skill en todos los modelos probados. Cuando un Gene comprime el proceso aprendido a través de una exploración exitosa del modelo, los modelos posteriores pueden usarlo de manera más confiable que una Skill descriptiva completa.

Realizamos un análisis contrastante para separar el efecto de la estructura genética del efecto de una evolución exitosa. En las tareas restantes destiladas de referencia, la conclusión es la inversa: Gene generalmente tiene un rendimiento inferior al de Skill. Este resultado refuerza la interpretación de que la ventaja no proviene simplemente de comprimir la información relacionada con las respuestas. Proviene de una estrategia evolucionada que resume un proceso de ejecución exitoso en una guía procesal reutilizable. La estructura del proceso evolucionada, en lugar de la simple compresión rápida, produce la ganancia.

3.3 Análisis del costo de los tokens (RQ2: ¿Cómo afectan las Skills y los Genes la tasa de aprobación y el uso de los tokens?)

El experimento compara dos formas en que Opus 4.8 resuelve las mismas tareas:

• Exploración convencional de modelo fuerte: un modelo capaz intenta la tarea, lee los comentarios del verificador desinfectados después del error y vuelve a intentarlo hasta el límite permitido hasta que se supera un intento. Esta es la línea de base.
• Ejecución asistida por EvoMap Gene: un Gene destilado de la experiencia de un modelo sólido se convierte en un contexto de procedimiento que cualquier modelo puede usar para uno. with_gene intentar. La tasa de aprobación es mucho mayor que sin Gene, mientras que el consumo de tokens es sustancialmente menor que el de la exploración de múltiples rondas. Este es nuestro modo.

Esta sección cuenta input_tokens + output_tokens + thoughts_tokens. Para Claude Opus 4.8, los tokens de salida del proveedor ya incluyen el pensamiento, por lo que "Salida incluido el pensamiento" denota el total recuperable del lado de finalización. La línea de base de múltiples rondas cuenta solo las tokens utilizadas en los lanzamientos de resolución/mutación que descubren una trayectoria de paso; no incluye el costo posterior de la destilación de Genes.

Conventional multi-round exploration:
252 tasks
  -> Round 1 solve, thinking off
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 2 mutate, thinking low
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 3 mutate, thinking high
     -> pass: distill Gene

Total: 404 model calls, 252 verified successful trajectories

Single-round Gene reuse:
252 tasks + Opus Genes
  -> one with_gene_opus attempt per task
  -> 252 model calls, 200 passed tasks

Este conjunto de evaluación contiene todas las tareas que finalmente produjeron una trayectoria verificada durante la exploración de múltiples rondas. La primera fila a continuación simula el proceso convencional de rondas múltiples y no es una tasa de aprobación de una sola llamada. Las filas restantes informan la resolución única de las mismas tareas con la condición auxiliar correspondiente.

La tabla apoya cuatro conclusiones directas:

1. no_context parece usar la menor cantidad de tokens, pero solo pasa 138 de 252 tareas. Ahorra contexto y al mismo tiempo descarta una gran cantidad de información procesal.
2. La Skill aumenta el recuento de pases de 138 a 161, pero el total de tokens llega a 803.099. Un manual de tareas estático ayuda, pero no necesariamente es económico.
3. Opus Gene supera 200 tareas en una ronda, 39 más que Skill, mientras usa 79.619 tokens menos, una reducción del 9,9%.
4. En comparación con la exploración de rondas múltiples de Opus, la reutilización de Genes de una ronda reduce las llamadas de 404 a 252, eliminando 152 llamadas exploratorias y reduce el total de tokens de 1.333.968 a 723.480, una reducción del 45,8%.

La eficiencia simbólica de Gene no proviene únicamente de un mensaje más breve. Convierte la retroalimentación de fallas, los pasos de corrección y el eventual flujo de trabajo exitoso de una exploración de múltiples rondas en una memoria de procedimiento inyectable. Un modelo posterior recibe la estrategia de ejecución resultante en lugar de comenzar la prueba y error desde cero. Gene no coloca la respuesta en el mensaje; hace que una ruta de ejecución que originalmente requería múltiples intentos esté disponible como contexto de procedimiento reutilizable.

3.4 Opus Gene versus Skill por tipo de tarea (RQ3: ¿Qué tipos de tareas, tipos de modelos y fuentes de Genes se benefician de la orientación procedimental?)

Dividir las 252 tareas evolucionadas de Opus por tipo produce una vista más detallada. Los cuatro grupos contienen 64, 62, 30 y 96 tareas, con un total de 252. Por lo tanto, estas tablas describen solo Genes evolucionados y excluyen Genes destilados de referencia. Opus Gene ofrece sus beneficios más consistentes en entornos de agentes y seguimiento de reglas, mientras que el código y las matemáticas dependen más fuertemente del modelo objetivo.

agent_env_synth (64 tareas)

generación de código (62 tareas)

razonamiento_matemático (30 tareas)

rule_following (96 tareas)

En agent_env_synth, Opus Gene supera a Skill en los siete modelos, con ganancias de +15,6 a +29.7 pp. Las tareas ambientales aún requieren el comportamiento del paquete, múltiples archivos y restricciones de prueba, pero el orden de interfaz y ejecución extraído de trayectorias exitosas reduce consistentemente las omisiones.

El seguimiento de reglas también mejora para los siete modelos, entre +2,1 y +22.9 pp. Muchas fallas en las tareas de reglas provienen de un manejo inconsistente de la prioridad, anulaciones, límites de igualdad o restricciones de opciones discretas en lugar de una incapacidad para leer el mensaje. Gene hace explícitas esas comprobaciones de procedimiento y ayuda al modelo a tomar la decisión correcta.

La generación de código es mixta. Sonnet, Gemini Flash y Qwen Coder se benefician de Gene; Opus, Gemini Pro y Qwen 3.5 disminuyen ligeramente; MiniMax no ha cambiado. La orientación procedimental comprimida puede reducir las omisiones en la interfaz y el flujo de trabajo, pero no siempre reemplaza una Skill más completa. El efecto depende de cómo el modelo objetivo utiliza las dos formas de contexto.

El razonamiento matemático requiere mayor cautela. Opus 4.8 sube del 43,3% al 83,3%; Gemini Pro y los dos modelos al 0% se mantienen sin cambios; Sonnet, MiniMax y Qwen 3.5 disminuyen. Las matemáticas de respuestas cortas dependen en gran medida de la ejecución simbólica exacta, el cálculo de límites y la normalización de respuestas. La orientación procedimental puede sugerir un método, pero no puede reemplazar el cálculo y puede distraer a algunos modelos.

Estos resultados a nivel de pista explican por qué LongWoF-Bench abarca varias pistas. Una puntuación agregada puede mostrar que la asistencia ayuda, pero sólo el análisis a nivel de seguimiento revela qué tipos de tareas se benefician y dónde persisten los problemas.

3.5 Superposición evolucionada común: Gene Gemini versus Gene Opus

Los conjuntos de tareas evolucionadas para Gemini Gene y Opus Gene no son idénticos, por lo que comparar cada uno en su propio conjunto completo no sería válido. En su lugar, utilizamos las 180 tareas desarrolladas por ambos. Opus Gene sigue siendo consistentemente más fuerte que Gemini Gene en esta superposición, lo que demuestra que la capacidad del modelo de creación de Genes afecta la usabilidad del Gene resultante.

3.6 Estudios de caso

Caso 1: generación_código/T0161, composición del ensayo de sondaje

Tarea. Un canal de geociencia dice collars.csv y assays.csv. Las filas de ensayo pueden contener intervalos de profundidad superpuestos y marcadores por debajo de la detección, como '<0.01'. El programa debe: (1) convertir <x en x/2; (2) resolver intervalos de profundidad superpuestos en segmentos mutuamente excluyentes; (3) recomponer esos segmentos en contenedores fijos de dos metros desde la profundidad 0 hasta max_depth; (4) calcular un alteration_index para cada contenedor; y (5) calcular el valor de cada hoyo mineralization_score como la suma de los valores compuestos de Au/Cu por encima de la mediana de todo el prospecto, donde la mediana se calcula en cada compuesto de dos metros en el conjunto de datos.

Proceso convencional y cómo Opus evolucionó el Gene:

• Despliegue 1 (solución) → FALLO (pass_rate=0.875). Opus resolvió las superposiciones con una regla de “intervalo posterior gana”: la última fila sobrescribió la anterior dondequiera que se superpusieran.
• Lanzamiento 2 (mutación) → FAIL (pass_rate=0.875). Opus mantuvo la misma convención y solo fortaleció el manejo de NaN. La prueba de superposición aún falló.
• Despliegue 3 (mutación) → PASS (pass_rate=1.0). Opus cambió la semántica de superposición. En lugar de dejar que ganara el intervalo posterior, promedió los valores de cada intervalo que cubría el segmento y luego ponderó la longitud de esos segmentos en los contenedores de dos metros. Esto coincidió con la semántica de composición esperada y pasó.

El avance fue semántico: los intervalos de ensayo superpuestos deben promediarse en lugar de sobrescribirse. Eso es lo que captura el Gene.

Gene evolucionado (T0161.json, carga útil):

{
  "type": "Gene",
  "summary": "Build a geoscience/interval pipeline that cleans below-detection markers, resolves overlapping depth intervals, composites into fixed-length bins, and emits per-row and per-entity aggregate CSVs.",
  "category": "innovate",
  "signals_match": [
    "drillhole assay compositing",
    "below-detection limit markers like '<0.01'",
    "overlapping depth intervals to mutually exclusive segments",
    "fixed-length 2-meter downhole composites",
    "alteration index / mineralization score formulas",
    "prospect-wide median threshold aggregation",
    "--input/--output directory CLI with named CSV outputs",
    "length-weighted interval averaging"
  ],
  "strategy": [
    "Parse CLI --input/--output dirs; read collars and assays CSVs by exact column names; create output dir with makedirs(exist_ok=True).",
    "Clean value columns: convert '<x' strings to x/2 (half detection limit), '>x' to x, blanks/'na' to NaN, else float; coerce depth columns to numeric.",
    "Per hole, resolve overlaps: collect breakpoints from all from/to bounds, for each adjacent segment use midpoint to find covering intervals and average their values into one exclusive segment.",
    "Composite into exact fixed-length bins from 0 to max_depth (ceil(max_depth/len) bins); for each bin length-weight each value by overlap length with segments, divide by total weight, NaN if none.",
    "Compute per-bin derived index per given formula guarding zero/NaN denominators; write one CSV with hole_id, bin from/to, and index using the required header order.",
    "Compute dataset-wide medians across ALL bins for threshold columns; per hole sum bin values exceeding their respective medians for the score and take per-hole max values; write the summary CSV with exact headers.",
    "Verify both output files exist, column names/order match the contract, and every hole appears even with empty or missing assays."
  ],
  "preconditions": [
    "Medians for scoring must be computed across the full composited dataset, not per hole.",
    "Bins must span exactly 0..max_depth and exist for holes with no assay coverage (values NaN).",
    "Overlap resolution must produce mutually exclusive segments before any compositing aggregation.",
    "String/NaN/empty assay cells must be sanitized before numeric ops to avoid type errors."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro sin Gene: falló. resolve_overlaps de Gemini ordenó los intervalos y truncó el intervalo anterior al inicio del siguiente intervalo, un método de “recortar, no combinar” que descartaba valores superpuestos:

prev = resolved[-1]
if row['depth_from'] < prev['depth_to']:
    if row['depth_from'] > prev['depth_from']:
        prev['depth_to'] = row['depth_from']   # trim only; discard overlap contribution
    else:
        resolved.pop()
resolved.append(row)

El resultado fue FAIL:L2_prospect_summary_adv_overlap - Mismatch in mineralization_score for key ('H003',): got 0.0, expected 202.0. El manejo de superposiciones eliminó la contribución que impulsó el puntaje.

Gemini Pro con Gene: aprobado. Guiado por la estrategia de Gene de “recopilar puntos de interrupción, promediar intervalos de cobertura, luego ponderar la longitud en contenedores”, Gemini construyó segmentos de puntos de interrupción, promedió cada intervalo de cobertura y luego ponderó la longitud de los segmentos en contenedores de dos metros:

boundaries = sorted(set(hole_assays['depth_from']).union(hole_assays['depth_to']))
for seg_from, seg_to in adjacent_pairs(boundaries):
    covering = hole_assays[(hole_assays.depth_from <= seg_from) & (hole_assays.depth_to >= seg_to)]
    seg_data[col] = np.average(vals[valid], weights=w[valid])   # average, not overwrite

Sin Gene, el modelo utilizó de forma predeterminada la heurística común de fusión de intervalos "más tarde gana / recorta el intervalo anterior". Parece razonable, pero es incorrecto para la composición de ensayos y la reducción. H003La puntuación de mineralización es cero. Opus había aprendido a través de dos implementaciones fallidas que la convención correcta es el promedio ponderado por longitud. Gene le dio a Gemini esa convención precisa, permitiéndole componer correctamente en el primer intento.

Caso 2: rule_following / T0659, código de despacho de emergencia

Tarea. Dado un escenario de 911 que involucra un disturbio doméstico en el interior, un sujeto sosteniendo un cuchillo de cocina (arma blanca), sin lesiones visibles y una geolocalización exactamente a 5 ZDU de distancia, elija el código de despacho correcto entre dispatch_omega, dispatch_sigma, dispatch_theta y dispatch_zeta. La decisión depende de dos reglas que interactúan: la comparación de distancia-umbral (¿excede exactamente 5 el límite estrictamente?) y la precedencia de arma/heridas (el arma presente sin lesiones se asigna al nivel armado sin lesiones).

Proceso convencional y cómo Opus evolucionó el Gene:

• Despliegue 1 (solución) → FAIL (pass_rate=0.667). Opus se negó a confirmar, argumentó que faltaba la tabla de reglas, emitió el marcador de posición dispatch_omega y dijo que la elección no se pudo verificar.
• Despliegue 2 (mutación) → FAIL (pass_rate=0.667). Opus seleccionó dispatch_theta, razonando que un arma intensificó la respuesta independientemente del umbral de distancia. Esto exacerbó el caso: ignoró la degradación sin lesiones y trató la distancia límite como un desencadenante de la escalada.
• Despliegue 3 (mutación) → PASS (pass_rate=1.0). Opus aplicó la precedencia correctamente. Exactamente 5 ZDU no exceden estrictamente el umbral, por lo que el aumento de distancia no se activa. Un arma sin lesiones se asigna al nivel armado sin lesiones: dispatch_sigma.

Gene evolucionado (T0659.json, carga útil):

{
  "type": "Gene",
  "summary": "Select a dispatch/response code by applying weapon and injury precedence rules combined with a strict ZDU/distance threshold comparison, emitting an exact two-line ANSWER/ANALYSIS contract.",
  "category": "other",
  "signals_match": [
    "dispatch code selection",
    "threshold comparison on distance units (ZDU)",
    "rule precedence for weapon-involved incidents",
    "ANSWER and ANALYSIS exact two-line output",
    "weapon present but no visible injuries",
    "911 / emergency dispatch scenario",
    "choose one of several action tokens",
    "case-insensitive exact-match grading"
  ],
  "strategy": [
    "Extract every decision factor from the prompt: weapon present?, injuries present?, distance value, and the exact stated threshold.",
    "Apply the threshold as written: treat 'exactly equal' as NOT exceeding unless rule says >= (strict vs non-strict matters most for boundary values).",
    "Resolve precedence order: injury-tier > armed-no-injury > distance-only codes; pick the highest-priority rule whose conditions are fully satisfied.",
    "When a weapon exists but injuries are explicitly denied, choose the armed-but-no-injury tier, not the injury escalation or plain distance code.",
    "Map the satisfied rule to its corresponding code token and verify it is one of the allowed options.",
    "Emit exactly two lines: 'ANSWER: <token>' then 'ANALYSIS: <one paragraph ≤80 words citing the rule>', with no extra output or whitespace lines."
  ],
  "preconditions": [
    "Confirm whether the boundary value triggers escalation (strict > vs >=) before deciding distance effect.",
    "Verify the chosen token is spelled exactly as an allowed option for case-insensitive exact match.",
    "Ensure precedence (weapon/injury rules) overrides distance-only codes when both apply."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gemini Pro sin Gene: falló. Gemini escaló demasiado el arma y manejó mal el límite, seleccionando dispatch_theta:

ANSWER: dispatch_theta
ANALYSIS: ... because the subject is exactly 5 ZDU away ..., the threshold comparison for a weapon-related incident indicates dispatch_theta ...

Este es el mismo error que cometió Opus en la implementación 2: tratar la distancia límite más el arma como si requiriese el nivel más alto e ignorar la degradación sin lesiones.

Gemini Pro con Gene: aprobado.

ANSWER: dispatch_sigma
ANALYSIS: ... a bladed weapon with no visible injuries at exactly 5 ZDU ... under the rule precedence, the combination of weapon and close distance ... no active injury indicates the dispatch_sigma code.

La tarea tiene dos trampas bien conocidas: un límite estricto versus no estricto (¿exceden exactamente 5 el umbral?) y un orden de precedencia (lesión > armado sin lesión > solo distancia). El modelo sin contexto falló en ambos, como lo había hecho Opus antes de converger. Gene establece ambas reglas explícitamente: trata la igualdad como si no se excede a menos que la regla diga >=, y asigna el arma presente con lesión negada al nivel armado sin lesiones en lugar de escalada de lesiones. Por lo tanto, Gemini aplica la precedencia correctamente y selecciona dispatch_sigma.

Lo que comparten los dos casos

Ambos casos muestran el mismo patrón: una heurística predeterminada razonable incumple un contrato específico de la tarea.

• T0161: tratar el intervalo posterior como sustituto del anterior elimina las contribuciones superpuestas.
• T0659: asumir que un arma siempre eleva la respuesta ignora la reducción por ausencia de lesiones y el umbral estricto de distancia.

Opus necesitó dos o tres rollouts para aislar la regla correctiva de cada caso. El Gene evolucionado la resume en unas pocas líneas de strategy y preconditions, lo que permite que Gemini la aplique en el primer intento.

El caso de código muestra cómo Gene evita depuración repetida y grandes reescrituras. El caso de reglas muestra cómo evita errores de prioridad y de frontera. En conjunto explican por qué la orientación procedimental puede reducir el coste de exploración, sin afirmar que produzca la misma mejora en todos los tipos de tareas.

Referencias

• Diao, L., Xu, X., Sun, W., Yang, C., & Zhang, Z. (2025). GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents. ACL 2025, 11361-11399.
• EvoMap. (2026a). GEP Protocol Deep Dive: Genetic Engineering for AI Agent Self-Evolution.
• EvoMap. (2026b). Agent Skill vs GEP Gene: The Fundamental Divide Between Tools and Evolution.
• Li, X., et al. (2026). SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks. arXiv:2602.12670.
• Wang, J., Ren, Y., & Zhang, H. (2026). From Procedural Skills to Strategy Genes: Towards Experience-Driven Test-Time Evolution. arXiv:2604.15097.