Respuesta corta: qué logra Mid-Harness en agentes de terminal
Mid-Harness hace que un agente de terminal genere varios comandos candidatos en cada paso y que un verificador elija uno antes de ejecutarlo, sin tocar el modelo ni el harness. En TerminalBench-Lite, con TMAX-9B como generador y GPT-5.6 Sol como verificador, Pass@1 sube de 50.00% a 68.03% (Kang et al., 2026, NVIDIA).
Motivación de Mid-Harness: un comando malo arruina toda la trayectoria
Un agente de terminal es un modelo de lenguaje que resuelve tareas escribiendo comandos de shell: instala paquetes, edita archivos, corre pruebas. Alrededor del modelo vive el harness, el programa que le pasa el historial, interpreta su respuesta, ejecuta el comando y le devuelve la salida. OpenHands y SWE-agent, que el paper cita, son ejemplos de este patrón.
El problema que atacan Kang y sus coautores de NVIDIA y KAIST es sencillo de describir. El modelo genera cada acción de forma estocástica, y cada comando ejecutado cambia el entorno. Un comando malo, como instalar el paquete equivocado, deja un estado que estorba todos los pasos siguientes. Eso pasa aunque el mismo modelo pudiera haber propuesto una alternativa mejor si se le pedía otra vez.
Los autores llaman a esto confiabilidad de las acciones (action reliability): generar de forma consistente acciones que acercan la tarea a su fin. Por eso el mismo modelo con el mismo harness a veces resuelve una tarea y a veces no.
La respuesta habitual es gastar más cómputo en inferencia (test-time compute) a nivel de trayectoria. Best-of-T genera varias corridas completas y un juez elige una. Sequential Refine resume una corrida fallida y arranca otra con ese resumen. Ambos métodos necesitan entornos nuevos para cada corrida, algo difícil fuera de un benchmark si no puedes guardar y restaurar el estado.
Mid-Harness propone otro eje: gastar el cómputo antes de ejecutar cada acción, en la frontera entre el modelo y el harness. La pregunta del paper es cuándo ese gasto mejora el éxito de la trayectoria y qué lo hace efectivo. Spoiler: generar más candidatos sirve de poco si el verificador es débil.
Cómo funciona Mid-Harness: muestrear, verificar y ejecutar una sola acción
Mid-Harness no modifica los pesos del modelo ni el harness. Vive dentro de la función que llama al modelo: en vez de pedir una respuesta, pide varias y devuelve la que elige un verificador. El harness recibe una sola acción, como siempre.
# Esquema simplificado (nuestro, no es el código del paper)
async def generate(messages):
# Antes: return await llm.generate(messages)
candidatos = await llm.generate(messages, n=N) # N comandos posibles
return await verificar(llm_verificador, messages, candidatos) # se ejecuta solo uno
Formalmente, en el paso $t$ el agente tiene un historial $h_t$ con la instrucción de la tarea, las acciones previas y las salidas de la terminal. La ecuación (1) del paper define el procedimiento:
$$\mathcal{A}_t = (a_t^1, \ldots, a_t^N), \qquad a_t^i \sim \pi(\cdot \mid h_t), \qquad a_t^\star = \mathrm{Verify}_\psi(h_t, \mathcal{A}_t) \in \mathcal{A}_t$$
- $\pi$: el modelo generador (aquí TMAX-9B), que propone acciones a partir del historial.
- $a_t^i \sim \pi(\cdot \mid h_t)$: cada candidato se muestrea de forma independiente con el mismo historial.
- $N$: el ancho de candidatos, cuántas acciones se proponen por paso.
- $\mathrm{Verify}_\psi$: el mecanismo de verificación con el modelo verificador $\psi$; siempre devuelve uno de los candidatos.
- $a_t^\star$: la acción que sí se ejecuta. Los demás candidatos se descartan y el historial pasa a $h_{t+1} = (h_t, a_t^\star, o_t)$.
La intuición: si $N$ crece, hay más probabilidad de que exista un buen comando entre los candidatos, pero solo sirve si $\mathrm{Verify}_\psi$ lo reconoce. Con un verificador que eligiera al azar, Mid-Harness se comportaría, en esencia, como el agente base.
Tres formas de verificar los candidatos
El paper compara tres mecanismos. En la verificación listwise, el verificador ve todos los candidatos en un solo prompt y elige uno. En la pointwise, califica cada candidato por separado y gana el de mayor calificación, como un modelo de recompensa de procesos. En la pairwise, compara dos candidatos a la vez con el mismo historial y da una preferencia con calificaciones para ambos.
La verificación por pares es la más cara. Con ocho candidatos, comparar todos los pares requiere 28 llamadas; por eso, con ocho, los autores usan un torneo de anillo con cuatro pivotes. Cada comparación $e$ produce calificaciones $s_{A,e}$ y $s_{B,e}$ de $1$ a $10$, y los resultados se agregan con la ecuación (3) del paper:
$$w_e = \max\!\left(\frac{|s_{A,e} - s_{B,e}|}{9},\, 0.1\right), \qquad q_i = \frac{\sum_{e \in E_i} w_e\, p_{i,e}}{\sum_{e \in E_i} w_e}$$
- $w_e$: el peso de la comparación $e$. Crece con la diferencia de calificaciones; el $9$ normaliza el margen máximo posible.
- $0.1$: un piso para que una preferencia con calificaciones iguales siga contando un poco.
- $p_{i,e}$: vale $1$ si el candidato $i$ gana la comparación, $0$ si pierde y $1/2$ en empate.
- $E_i$: las comparaciones válidas en las que participa $i$.
- $q_i$: la tasa de victorias ponderada por margen. Se ejecuta el candidato con mayor $q_i$.
La intuición: una victoria por paliza pesa más que una por poco. Dividir entre la suma de pesos corrige que unos candidatos aparezcan en más comparaciones que otros.
Destilar al verificador sin tocar al generador
Cuando el verificador es el mismo TMAX-9B sin ajustes (zero-shot), queda lejos de GPT-5.6 Sol. Para cerrar parte de esa brecha, los autores entrenan con LoRA un verificador que imita al modelo frontera: usan 117k respuestas por pares de GPT-5.6 Sol, recolectadas de 732 trayectorias en 244 tareas difíciles. El adaptador LoRA solo se activa al verificar; el generador sigue siendo el TMAX-9B original.
Ejemplo visual de Mid-Harness: cómo verificas importa más que cuánto muestreas
La primera gráfica fija el generador (TMAX-9B) y el ancho ($N = 8$), y cambia solo la forma de verificar. La métrica es Pass@1, el promedio de éxito exacto en tres corridas por tarea, sobre 98 tareas de TerminalBench-Lite.
Con el mismo generador y los mismos candidatos, Pass@1 va de 51.02% a 68.03% según quién y cómo verifica. La verificación por pares es la mejor de las que usan TMAX-9B como juez, y destilarla suma más. La brecha con GPT-5.6 Sol muestra que el generador ya produce buenas alternativas; el cuello de botella es reconocerlas.
Resultados de Mid-Harness frente al agente base y al escalamiento de trayectorias
Todas las cifras son de TerminalBench-Lite con el harness Vanillux2, salvo que se diga otra cosa. El agente base ejecuta una acción por paso, sin verificación ni corridas extra.
Más candidatos no compensan un verificador débil
Con verificación listwise zero-shot, pasar de cuatro a ocho candidatos mueve Pass@1 solo de 49.32% a 51.02%. Con el mismo mecanismo listwise pero GPT-5.6 Sol como juez, Pass@1 llega a 64.63% con cuatro candidatos y a 68.03% con ocho. Los autores leen este contraste como evidencia de que el verificador débil no distingue las acciones útiles cuando compara el conjunto completo a la vez.
Pares y destilación
Con ocho candidatos, la verificación por pares zero-shot alcanza 54.76% de Pass@1 y 71.43% de Pass@3 (la fracción de tareas resueltas en al menos una de las tres corridas). La destilación sube esas cifras a 57.14% y 75.51%. En el análisis fuera de línea, la destilación lleva el acuerdo con el verificador frontera en la elección final de 38.52% a 57.79%.
El precio es cómputo. Con ocho candidatos, la verificación por pares zero-shot agrega unos 26.6k tokens de salida en paralelo por corrida, contra a lo más 1.3k de listwise y pointwise.
Combinar acciones y trayectorias
Mid-Harness no compite con Best-of-T ni con Sequential Refine: se suma. Best-of-T con tres trayectorias da 55.10%; si esas tres trayectorias se generan con Mid-Harness destilado, Pass@1 sube a 66.33%, con las mismas tres ejecuciones del entorno.
Según la Figura 5 del paper, Mid-Harness destilado iguala a Best-of-T con cinco trayectorias (57.14%) a cerca de un tercio de su costo estimado en tokens. Combinado con Sequential Refine o con Best-of-T de tres trayectorias, supera a Best-of-T con siete (59.18%) y cuesta menos. Ese costo usa precios de referencia por token, no un costo medido en producción.
Otros tamaños, benchmarks y harnesses
La mejora aparece en los tres tamaños de TMAX. En Terminal-Bench 2.1, la verificación zero-shot sube TMAX-9B de 21.72% a 27.34%. En FeatureBench-Mini, donde el agente base de TMAX-9B solo tiene éxito en 1.45% de las corridas, las dos variantes suben a 5.80% y 7.25%. Los autores reportan además mejoras con modelos Nemotron y con Qwen3.5 en otro harness (Terminus-2).
Limitaciones de Mid-Harness: qué no demuestra el paper
- No hay etiquetas de la acción correcta. Los autores lo admiten: sin ellas no pueden medir directamente si el verificador acierta ni cuántos buenos candidatos hay. Todo se infiere del éxito final de la trayectoria.
- Muestra pequeña e incertidumbre amplia. TerminalBench-Lite tiene 98 tareas evaluadas con tres corridas cada una. En los intervalos de confianza de 95% por bootstrap, solo las versiones destiladas con TMAX-9B y TMAX-27B quedan por encima de cero. Por ejemplo, la verificación zero-shot con TMAX-9B mejora 4.76 puntos, con un intervalo de -0.68 a +10.20.
- No mejora en todo. Las ganancias varían por dominio: en cómputo científico, la verificación destilada baja el Pass@1 de TMAX-27B en 10.0 puntos.
- Brecha y costo. El verificador destilado (57.14%) sigue lejos de GPT-5.6 Sol (68.03%), y la verificación por pares multiplica la decodificación. Los costos son estimaciones con precios de referencia, no latencia medida.
Qué significa para ti Mid-Harness si construyes agentes
Si tienes un agente propio que ejecuta comandos, Mid-Harness es un patrón que puedes probar sin reentrenar nada. La pieza clave es el envoltorio de la llamada al modelo: pide varias respuestas con el mismo historial y deja que un juez elija antes de ejecutar. Tu harness no se entera.
Tres lecciones del paper se aplican directo. Primero, invierte en el verificador antes que en el número de candidatos: más muestras con un juez débil casi no ayudan. Segundo, comparar pares funcionó mejor que calificar uno por uno o elegir de una lista, aunque cuesta más llamadas. Tercero, si un modelo grande es caro para verificar en cada paso, destilar sus juicios a un modelo chico recuperó parte de la ganancia.
También conviene usarlo junto con lo que ya tengas. Si ya haces varias corridas y eliges la mejor, verificar acciones dentro de cada corrida sumó en sus experimentos. Pero no lo trates como una garantía: los propios autores dicen que la verificación no establece la seguridad de los comandos. Mantén permisos restringidos, entornos aislados y aprobación humana para acciones irreversibles.
Por último, mide en tus tareas. Los resultados vienen de benchmarks de terminal con modelos específicos y tres corridas por tarea; tu dominio puede comportarse distinto, como pasó con las tareas de cómputo científico.