# Mid-Harness explicado: verificar cada comando antes de ejecutarlo Mid-Harness (NVIDIA, 2026) hace que un agente de terminal proponga varios comandos por paso y que un verificador elija uno antes de ejecutarlo; con TMAX-9B, Pass@1 sube de 50.00% a 68.03% en TerminalBench-Lite. **El paper:** Mid-Harness: Scaling Actions Between Model and Harness for Terminal Agents - Autores: Minki Kang, Ryo Hachiuma, Shaokun Zhang, Subhashree Radhakrishnan, Yonggan Fu, Jindong Jiang, Mingjie Liu, Ehsan Hosseini-Asl, Yi Dong, Yu-Chiang Frank Wang, Byung-Kwan Lee - Año: 2026 Revisado por Guillermo Izquierdo Colin (2026-11-09) ## 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. > Gráfica: Pass@1 (%) en TerminalBench-Lite con TMAX-9B como generador; todas las variantes de verificación usan ocho candidatos por paso. Fuente: Kang et al. (2026), Tabla 6. — Pass@1 en TerminalBench-Lite con generador TMAX-9B y N = 8 candidatos: agente base 50.00%; verificación listwise 51.02%; pointwise 52.38%; pairwise 54.76%; pairwise destilado 57.14%; verificador GPT-5.6 Sol 68.03%. 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. > Gráfica: Pass@1 (%) en TerminalBench-Lite con TMAX-9B. Mid-Harness usa verificación por pares destilada con ocho candidatos. Fuente: Kang et al. (2026), Tabla 7. — Pass@1 en TerminalBench-Lite con TMAX-9B: agente base 50.00%; Best-of-T con T = 3, 55.10%; Best-of-T con T = 7, 59.18%; Mid-Harness destilado con N = 8, 57.14%; Mid-Harness más Sequential Refine (una ronda) 60.20%; Mid-Harness más Best-of-T con T = 3, 66.33%. 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 > Gráfica: Pass@1 (%) en TerminalBench-Lite; Mid-Harness con verificación por pares y ocho candidatos. Fuente: Kang et al. (2026), Tabla 2. — Pass@1 en TerminalBench-Lite por tamaño de generador (agente base, Mid-Harness zero-shot, Mid-Harness destilado): TMAX-4B 38.78%, 41.50%, 43.88%; TMAX-9B 50.00%, 54.76%, 57.14%; TMAX-27B 71.09%, 73.13%, 76.19%. 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. ## Referencias Minki Kang, Ryo Hachiuma, Shaokun Zhang, Subhashree Radhakrishnan, Yonggan Fu, Jindong Jiang, Mingjie Liu, Ehsan Hosseini-Asl, Yi Dong, Yu-Chiang Frank Wang, Byung-Kwan Lee. Mid-Harness: Scaling Actions Between Model and Harness for Terminal Agents. 2026. https://arxiv.org/abs/2609.39982 ## Preguntas frecuentes ### ¿Mid-Harness reentrena el modelo que genera los comandos? No. Mid-Harness solo cambia la función que llama al modelo: pide varias acciones candidatas y un verificador elige una. El generador y el harness quedan intactos; lo único que se puede entrenar es el verificador. ### ¿Sirve generar más comandos candidatos si el verificador es el mismo modelo pequeño? Poco. En el paper, con verificación listwise de TMAX-9B, pasar de cuatro a ocho candidatos casi no cambió Pass@1; la mejora grande apareció con un verificador más capaz o con verificación por pares. ### ¿Qué es la verificación por pares en Mid-Harness? El verificador compara dos comandos candidatos con el mismo historial, les pone calificación a ambos y elige uno. Las preferencias se agregan en una tasa de victorias ponderada por el margen, y se ejecuta el candidato con la tasa más alta. ### ¿Mid-Harness reemplaza a Best-of-T o a Sequential Refine? No, se combina con ellos. En los experimentos del paper, generar las trayectorias de Best-of-T o de Sequential Refine con Mid-Harness dio más éxito que esos métodos solos, con estimaciones de costo menores que agregar más trayectorias. ### ¿Verificar cada acción hace seguro a un agente de terminal? No. Los autores aclaran que miden éxito en tareas, no seguridad de los comandos. Recomiendan mantener permisos restringidos, entornos aislados y aprobación humana para acciones irreversibles.