Fragua Tech · Guía

Arneses de agentes a examen

Lo que miden los papers

Dos estudios de 2026 ponen números a lo que la Clase 11 explicaba con criterio: qué piezas del arnés mueven el resultado, para qué modelo, y si el arnés puede mejorarse solo.

↓

Repaso: las 8 capas de un arnés

En la Clase 11 del curso Desarrollo de Software Moderno con IA desmontaste un arnés pieza a pieza. La idea de partida: el bucle del agente es lo fácil; lo que separa una demo de una herramienta es todo lo que lo rodea. Ese «todo» se ordena en ocho capas.

Capa 1 · poder arrancar
Setup y autenticación
Cargar y sanear la credencial, comprobar el entorno y fallar pronto.
Capa 2 · con qué modelo
Capa de provider
Una función que oculta las diferencias entre Anthropic, OpenAI o un modelo local.
Capa 3 · qué sabe hacer
Esquemas de herramientas
El contrato de cada herramienta: lo único que el modelo ve de ella.
Capa 4 · qué hace
Ejecutores de herramientas
El código que toca archivos, procesos y red, con límites y errores legibles.
Capa 5 · el corazón
Bucle del agente
Pedir al modelo, ejecutar lo que pida, añadir el resultado y repetir.
Capa 6 · qué recuerda
Compactación de contexto
Qué se conserva cuando el historial ya no cabe en la ventana.
Capa 7 · qué queda
Persistencia y logs
Historial para reanudar la sesión y eventos para depurarla.
Capa 8 · cómo se usa
UX
Modos de uso, interrupciones y confirmaciones.

Las resaltadas, de la 3 a la 6, son las que hoy vamos a medir. Repasa las 8 capas en la Clase 11 →

El foco: las capas 3 a 6

Las capas 1–2 y 7–8 rodean al modelo: preparan la llamada o guardan lo que pasó, pero el modelo nunca las ve. Las capas 3 a 6 son lo que el modelo lee y lo que provoca en cada vuelta del bucle.

┌── lo que el modelo lee cada vuelta ──┐

│ 3 · esquemas   qué acciones existen  │

│ 6 · contexto   qué queda del pasado  │

└──────────────────┬───────────────────┘

▼

                MODELO

                   │ pide una acción

▼

4 · ejecutores  la ejecutan y devuelven

                un resultado o un error

│

▼

5 · bucle       lo añade al historial

                y vuelve a llamar

3 · Esquemas

El menú de acciones: nombre, descripción y parámetros de cada herramienta. Aquí se decide el espacio de acciones: muchas herramientas finas o una sola terminal.

4 · Ejecutores

Lo que pasa cuando el modelo pide algo: validar, ejecutar con límites y devolver un resultado —o un error— que vuelve al contexto como texto.

5 · Bucle

El ciclo razonar → actuar → observar. Decide qué entra en cada llamada, cuándo parar y cómo no dar vueltas en círculo. La planificación vive aquí.

6 · Compactación

Qué recuerda el agente cuando el historial no cabe. Recortar, guardar fuera o resumir: cada opción cuesta distinto y pierde cosas distintas.

Los dos papers de hoy trabajan justo aquí. El primero mide cuánto aporta cada una de estas capas según el modelo; el segundo deja que un agente las reescriba.

Paper 1

An Empirical Study of Harness Design for Coding Agents

Run-Ze Fan, Zihao Zhang y otros · UMass Amherst, Emory University, UNC Charlotte y Zoom · arXiv:2609.20804, septiembre de 2026

El paper estudia el rendimiento de distintos modelos de lenguaje con distintas configuraciones dentro de un arnés que los autores construyeron desde cero, con fines experimentales.

El problema

Casi todas las comparaciones enfrentan arneses completos. Un estudio previo vio que Claude Opus 4.5 rinde mejor con OpenHands y Claude Sonnet 4.5 con SWE-Agent. Pero si un arnés gana, no sabes por qué: ¿el plan, las herramientas, la gestión del contexto, o cómo encajan con ese modelo?

«¿Los componentes del arnés son útiles en general, o su efecto depende de la capacidad del modelo, del tipo de tarea y del presupuesto?»

componentes que varían

Planificación, espacio de acciones y gestión de contexto.

modelos

Nemotron-3 de 30B, 120B y 550B (una familia, tres tamaños) y Mistral Medium 3.5 128B, de otra familia.

benchmarks

SWE-Bench Verified: 500 issues reales de GitHub. Terminal-Bench 2.1: 89 tareas de terminal de principio a fin.

176

configuraciones

Cada una ejecutada sobre todas las tareas de su benchmark.

Los modelos no son el objetivo: son sondas de capacidad. Lo que interesa es el patrón, que debería repetirse con los modelos que vengan.

Visión general

Un bucle ReAct con tres piezas intercambiables

Un arnés ligero en el que el bucle es fijo y cada componente se configura por separado. Cada vuelta tiene tres tiempos: razonar, actuar y observar.

ENSAMBLADO DE LA ENTRADA (cada vuelta)

  prompt de sistema + tarea    fijo

  esquemas de acciones         capa 3

  plan actual (aparte)         capa 5

  historial gestionado         capa 6

│

▼

           MODELO ── sin acción ──► fin

              │ llamadas a herramientas

▼

EJECUCIÓN en Docker o E2B     capa 4

  archivos · terminal · web · memoria

              │ resultado o error

▼

HISTORIAL + la vuelta ─► gestión (capa 6)

Lo que varía

La planificación, el espacio de acciones y la gestión de contexto.

Lo que se deja fijo

El bucle, la seguridad, los diagnósticos tras editar y la detección de atascos: el suelo común sobre el que se compara todo lo demás.

Montaje

LangGraph para el bucle y Harbor para lanzar cada tarea en su contenedor y verificarla. Como mucho 300 pasos por tarea, temperatura 0 y 16.384 tokens de salida por turno.

Capa 3 · Esquemas

El espacio de acciones

Qué herramientas ve el modelo y con qué contrato. Cada una lleva un esquema tipado y una descripción que explica su protocolo, sus errores y sus efectos.

Herramienta	Solo lectura	Qué hace
read_file	sí	Lee un archivo con números de línea
write_file	no	Crea o sobrescribe un archivo
edit_file	no	Reemplaza un texto exacto
list_files	sí	Lista un directorio
glob_files	sí	Busca archivos por patrón
grep_text	sí	Busca contenido con una regex
bash	no	Ejecuta un comando de shell
web_fetch	sí	Descarga una página como texto
update_plan	no	Crea o actualiza el plan
recall_event	sí	Recupera un resultado recortado (T2 y T4)

Dos variantes

Herramientas predefinidas: todo lo de la tabla. Solo bash: se quitan las de archivos, búsqueda y web; quedan bash y las auxiliares del plan y del contexto.

# Working with only a shell

Every interaction with the codebase

goes through `bash` — you write the

commands yourself.

Una ausencia a propósito

No hay búsqueda web: en SWE-Bench, buscar el issue podría llevar al pull request con la solución.

Ojo al leer los resultados

La variante no cambia solo la lista: también las instrucciones del prompt, el control de «leer antes de escribir» y los diagnósticos automáticos. Se compara la interfaz completa, no el número de herramientas.

Capa 4 · Ejecutores

Ejecutores defensivos, fijos en todo el estudio

Toda acción que lee o modifica el espacio de trabajo pasa por tres puertas antes de ejecutarse.

1 · Guarda del espacio de trabajo

Resuelve cada ruta y rechaza la que se sale de la raíz del proyecto, también a través de enlaces simbólicos.

2 · Leer antes de escribir

No deja editar un archivo que no se ha leído en la sesión, y detecta cambios externos comparando un hash del contenido.

3 · Permisos

Cada acción se clasifica como allow, ask o deny. Los comandos destructivos se deniegan.

Errores como observaciones

Un fallo de herramienta nunca rompe el bucle: vuelve al modelo como resultado y se corrige en la vuelta siguiente. Lo viste en la Clase 11: el error es parte del prompt.

Diagnóstico tras editar

Al escribir un archivo Python se pasa ruff, pyflakes o una comprobación de sintaxis, y el resultado se añade a la respuesta. El modelo ve el error antes de gastar una vuelta en los tests.

Límites

Los resultados se truncan a 24.000 caracteres, y hasta ocho herramientas de solo lectura pueden correr en paralelo en un mismo paso.

Capa 5 · Bucle

El bucle, los atascos y la planificación

El bucle y la detección de atascos son fijos. La planificación es una de las tres piezas que se encienden y se apagan.

repetir hasta 300 pasos:

  entrada = sistema + tarea + esquemas

          + plan actual + historial

  r = modelo(entrada)

  si r no pide acciones: fin

  obs = ejecutar(r.acciones)

  historial += r, obs

  gestionar_contexto(historial)

  ¿racha de llamadas idénticas?

      → aviso, o cortar

Detección de atascos (fija)

Una racha son llamadas seguidas a la misma herramienta con argumentos idénticos. A las 5 iguales, o 5 fallos iguales, el arnés inyecta un aviso único: «cambia de enfoque». Si los fallos idénticos llegan a 8, corta la ejecución en vez de agotar el presupuesto.

Planificación (varía)

• Una herramienta update_plan con la lista de tareas y exactamente una en curso.
• Un recordatorio en el primer turno si todavía no hay plan.
• El plan actual se inyecta antes de cada llamada sin guardarse en el historial: no se acumulan copias viejas.

<system-reminder>

Current plan (update it via update_plan

as you progress; keep exactly one task

in_progress…):

{PLAN}

</system-reminder>

Apagar la planificación quita las instrucciones, los recordatorios, la inyección y la herramienta. Nada más cambia.

Capa 6 · Compactación

Tres mecanismos, cinco estrategias

El preámbulo (prompt de sistema y tarea) y las vueltas recientes se conservan intactos; solo se compacta el tramo medio. Es el mismo esquema que viste en la Clase 11.

M1 · Elisión (barata, con pérdida)

Sustituye el cuerpo de un resultado viejo por un aviso que dice cuánto se quitó.

[tool output elided: 212 lines / 9804 chars. Re-read or re-run to get it again.]

M2 · Recuperación (elisión reversible)

Guarda el original en disco y expone recall_event(id) para leerlo de nuevo cuando haga falta.

M3 · Resumen (cuesta una llamada)

Una llamada aparte al mismo modelo, sin herramientas, pliega los eventos más antiguos en un resumen con apartados fijos: objetivo, archivos tocados, hecho, pendiente, errores y arreglos, estado actual y siguiente paso.

Estrategia	M1	M2	M3
T0 sin gestión	—	—	—
T1 elisión	✓	—	—
T2 elisión + recuperación	✓	✓	—
T3 resumen	—	—	✓
T4 las tres, por etapas	✓	✓	✓

≥ 60 % de la ventana → elidir y guardar

≥ 85 % de la ventana → resumir

reciente: 30 % del presupuesto, ≥ 2 vueltas

T1, T2 y T3 tienen un solo mecanismo y actúan en el umbral duro (85 %). Solo T4 escalona: recorta pronto y resume si no basta. Sin gestión (T0), la ejecución termina con error en cuanto el historial desborda la ventana.

Mapa

El arnés del paper sobre las 8 capas

Cada pieza del arnés experimental, en la capa de la Clase 11 a la que pertenece.

Capa	En el arnés del paper	En el estudio
1 · Setup	Harbor prepara el contenedor de cada tarea y su verificador	fuera del estudio
2 · Provider	SGLang sirve los cuatro modelos en local, en BF16	uno por modelo
3 · Esquemas	Herramientas predefinidas o solo bash; `update_plan` y `recall_event`	varía: espacio de acciones
4 · Ejecutores	Tres puertas de seguridad, diagnóstico tras editar, truncado	fijo
5 · Bucle	ReAct con tope de 300 pasos, detección de atascos, planificación	varía: planificación
6 · Compactación	T0–T4 con ventanas de 32K a 128K tokens	varía: gestión de contexto
7 · Persistencia y logs	Trayectorias guardadas y etiquetadas por fases con un LLM juez	se usan para el análisis
8 · UX	Ejecución no interactiva	no aplica

Las tres piezas que varían caen en las capas 3, 5 y 6. La 4 se deja fija a propósito: todas las variantes pisan el mismo suelo.

Diseño del experimento

Cambiar una pieza cada vez, con todo lo demás fijo, y comparar tarea a tarea.

Contexto  5 estrategias × 4 ventanas  = 20

          32K · 64K · 96K · 128K

          con herramientas y plan

Plan      base T4/128K sin plan      =  1

Acciones  base T4/128K solo bash     =  1

                                    ────

          por modelo y benchmark      22

          × 4 modelos × 2 benchmarks 176

Precio por millón de tokens (OpenRouter, agosto de 2026)
Modelo	Entrada	Salida
Nemotron-3 30B	0,05 $	0,20 $
Nemotron-3 120B	0,08 $	0,45 $
Nemotron-3 550B	0,50 $	2,20 $
Mistral Medium 3.5 128B	1,50 $	7,50 $

Métricas

Tasa de éxito (fracción de tareas resueltas) y coste medio por tarea, con los precios de la tabla. Además se miden los turnos, las llamadas y el pico de contexto.

Estadística

Test exacto de McNemar sobre resultados emparejados tarea a tarea, con corrección de Benjamini-Hochberg (tasa de falsos descubrimientos del 5 %). Es el asterisco de las tablas.

Trayectorias

Un LLM juez, validado con anotadores humanos, etiqueta cada vuelta con su fase: localizar, reproducir, arreglar o verificar. Así se explica por qué cambia el resultado, no solo cuánto.

Con cautela

Cada configuración se ejecuta una sola vez por tarea, y Terminal-Bench tiene 89: allí muchas diferencias no llegan a ser significativas y las conclusiones se apoyan en que la dirección se repite entre modelos y ventanas.

Hallazgo 1 · Capa 6

La gestión de contexto vale más cuanto más aprieta la ventana

Sin gestión (T0), el agente muere cuando el historial desborda la ventana. Con 32K, T0 pierde por desbordamiento el 78,7 % de las tareas de SWE-Bench y el 61,0 % de las de Terminal-Bench; con 128K, solo el 8,7 % y el 12,1 %. Las estrategias T1–T4 no desbordan nunca.

Benchmark

Modelo

Métrica

**Tasa de éxito (%)** · media de los 4 modelos · SWE-Bench Verified
Ventana	T0 Sin gestión	T1 Elisión	T2 Elisión + recuperación	T3 Resumen	T4 Las tres, por etapas	Brecha T1–T4 vs T0, pp
32K	10,0	44,9	45,7	46,3	45,7	+35,7
64K	34,3	50,4	50,0	51,1	49,3	+15,9
96K	45,2	50,1	50,6	51,1	50,9	+5,5
128K	48,1	50,8	51,4	50,0	50,9	+2,7

Ventaja media de gestionar el contexto frente a no hacerlo: +35,7 pp con 32K · +15,9 pp con 64K · +5,5 pp con 96K · +2,7 pp con 128K.

Color más intenso = valor más alto. Negrita subrayada: la mejor de cada fila. * diferencia significativa frente a T0 (McNemar exacto, Benjamini-Hochberg q < 0,05; solo con un modelo y un benchmark). T0 sale barata porque muchas ejecuciones mueren pronto por desbordar la ventana. Fuente: tablas 3 y 4 de arXiv:2609.20804.

Prueba: con la media de los 4 modelos, mira cómo se encoge la columna Brecha de 32K a 128K. Luego elige Nemotron-3 550B: con 32K pasa del 6,4 % sin gestión a más del 50 % con cualquier estrategia. Por último, cambia a Coste y elige Ambos.

Hallazgo 2 · Capa 6

Recortar primero y resumir después es lo más eficiente

Con un éxito parecido entre estrategias, la diferencia está en lo que cuestan y en qué mecanismos llega a usar el modelo.

T4: mismo éxito, menos coste

T4 consigue un éxito parecido al de T1–T3 y el coste más bajo en 7 de los 8 pares modelo–benchmark. La elisión, que es barata, resuelve muchos casos antes de que haga falta un resumen con LLM: T4 resume menos veces que T3 y mantiene el pico de contexto más bajo de todas.

Con ventana holgada, apenas importa

A 128K las estrategias casi empatan. La gestión de contexto alarga las trayectorias —deja llegar a editar y a verificar— pero no cambia cómo se comporta el agente.

La recuperación (M2) casi no se usa

T1 y T2 solo se diferencian en recall_event. En 32 comparaciones, T2 gana 15, pierde 14 y empata 3: −0,36 puntos de media. 36 de las 64 configuraciones con recuperación no la llaman ni una vez.

Llamadas a `recall_event` por tarea, con ventana de 32K
Modelo	T2 SWE	T2 TB	T4 SWE	T4 TB
30B	0,146	4,326	0,472	2,708
120B	0,206	0,250	0,318	0,022
550B	0,000	0,022	0,006	0,090
Mistral	0,000	0,022	0,010	0,045

Con 128K la media baja a 0,007 llamadas por tarea. Los modelos fuertes casi nunca recuperan lo recortado, y el 30B, que es el que más la usa, saca con T2 en Terminal-Bench 3,37 puntos menos que con T1.

Guardar todo «por si acaso» añade maquinaria que el modelo no usa. Una capa 6 escalonada y sencilla gana a una sofisticada.

Hallazgos 3 y 4 · Capas 5 y 3

Planificación y herramientas: depende del modelo

Las dos ablaciones parten de la misma base —T4, ventana de 128K, planificación activada y herramientas predefinidas— y cambian una sola pieza.

Benchmark

Métrica

**Tasa de éxito (%)** · SWE-Bench Verified · T4, ventana de 128K
Modelo	Base plan + herramientas	Sin planificación capa 5	Solo bash capa 3
Nemotron-3 30B	25,2	13,6^*▼ −11,6 pp	10,2^*▼ −15,0 pp
Nemotron-3 120B	44,0	46,6▲ +2,6 pp	42,4▼ −1,6 pp
Nemotron-3 550B	65,8	67,8▲ +2,0 pp	69,4^*▲ +3,6 pp
Mistral Medium 3.5 128B	68,6	69,0▲ +0,4 pp	45,4^*▼ −23,2 pp

Mayor éxito por modelo: 30B → base · 120B → sin planificación · 550B → solo bash · Mistral → sin planificación.

Cada variante cambia una sola pieza respecto a la base. Debajo de cada valor, la diferencia con la base: en puntos para el éxito, en % para el coste y en turnos para la mediana de turnos (▲▼ verde = mejora, rojo = empeora; los turnos no se colorean porque menos no es mejor por sí mismo). Fondo resaltado: la mejor opción del modelo. * diferencia significativa frente a la base. Fuente: tablas 3 y 4 y figuras 8 y 9 de arXiv:2609.20804.

Planificación: de andamio a ahorro

Al 30B le sube el éxito 11,6 puntos en SWE-Bench y 4,5 en Terminal-Bench, a cambio de más coste. A los fuertes casi no les cambia el éxito (−2,0 puntos el 550B y −0,4 Mistral en SWE-Bench) pero les recorta el coste un 30 % y un 32 %.

Herramientas: andamio para quien no domina la terminal

Sin herramientas predefinidas, el 30B pierde 15,0 puntos en SWE-Bench. El 550B, en cambio, mejora con solo bash: +3,6 puntos a mitad de coste en SWE-Bench, +5,6 y −30 % en Terminal-Bench. Mistral depende de la tarea: pierde 23,2 puntos en SWE-Bench y gana 6,7 en Terminal-Bench.

Por qué pasa

Lo que cuentan las trayectorias

Las etiquetas por fase explican los números: cada pieza cambia algo distinto del recorrido del agente.

El plan mantiene vivo al débil

Sin plan, la mediana del 30B en SWE-Bench cae de 40 a 5 turnos. El 68,6 % de sus ejecuciones acaban sin editar nada (27,8 % con plan) y el 58,4 % se quedan atascadas localizando el fallo (10,4 % con plan).

El plan hace parar a los fuertes

Con plan, el 550B baja de 108 a 74 turnos y Mistral de 68 a 53. Lo que desaparece es sobre todo verificación redundante después de editar: el plan no les enseña a arreglar, les enseña cuándo han terminado.

Sin herramientas, el débil llama a lo que no existe

Con solo bash, el 30B sigue emitiendo las llamadas a herramientas que aprendió al entrenarse, y el arnés no puede ejecutarlas. En Terminal-Bench el 66 % de esas trayectorias acaban así, y la media cae de 71 a 15 turnos.

Bash cambia la granularidad de las ediciones (herramientas → solo bash)
Modelo	Reparcheos por tarea · SWE-Bench	Mayor edición líneas, mediana · SWE-Bench	Reescrituras crear o reemplazar archivo · Terminal-Bench
30B	3,3 → 0,4	26 → 13	28 % → 64 %
120B	2,8 → 2,2	22 → 24	39 % → 76 %
550B	4,6 → 1,5	18 → 54	51 % → 76 %
Mistral	3,0 → 1,3	87 → 68	28 % → 57 %

Con bash, un modelo capaz agrupa varias operaciones en un comando o un script y reescribe archivos enteros; con herramientas, reparte el mismo trabajo en muchas ediciones pequeñas que luego retoca. En Terminal-Bench, Mistral ya hacía con bash el 71,9 % de sus acciones teniendo todas las herramientas (40,4 % en SWE-Bench): allí las herramientas competían con su forma de trabajar.

Lo que deja el paper 1

La conclusión de los autores cabe en una frase: el diseño del arnés es un problema condicional. Cada pieza se elige para un modelo, un tipo de tarea y un presupuesto; no se adopta por defecto.

Capa 6

Gestiona por etapas

Primero recorta, que es barato; resume solo si no basta. Con ventana holgada el beneficio es pequeño; con ventana ajustada, es la diferencia entre terminar la tarea o no.

Capa 6

Mide antes de sofisticar

La recuperación sin pérdidas parecía mejor sobre el papel y no mejora nada: los modelos casi no la usan. Añade mecanismos cuando las trazas digan que hacen falta.

Capa 5

Planifica según el modelo

Para un modelo débil, el plan es un andamio que lo mantiene en pie. Para uno fuerte, es un freno útil que le evita verificar de más.

Capa 3

Elige el espacio de acciones

Herramientas finas para modelos con poca soltura en la terminal; bash para modelos capaces, sobre todo en tareas de terminal. Mira qué usa el modelo cuando le das las dos cosas.

Límites del estudio

Una implementación concreta de cada pieza; plan y herramientas solo se probaron con T4 y 128K; una ejecución por tarea; SWE-Bench es solo Python; y el tamaño es un indicador imperfecto de la capacidad. Los puntos de cruce hay que validarlos antes de trasladarlos a otros modelos o a tareas fuera de la programación.

Leer el paper 1 (PDF, arXiv:2609.20804)

Paper 2

Agentic Harness Engineering

Observability-Driven Automatic Evolution of Coding-Agent Harnesses

Jiahang Lin, Shichun Liu, Chengjun Pan y otros · Fudan University, Peking University y Shanghai Qiji Zhifeng · arXiv:2604.25850, versión 4 de mayo de 2026

El paper 1 termina donde empieza este. Si el mejor arnés depende del modelo, cada modelo nuevo obliga a reajustarlo. Hoy eso se hace a mano —leer trayectorias, detectar patrones de fallo, retocar prompts, herramientas y middleware— y los modelos salen más rápido de lo que da tiempo a ajustarlos.

La pregunta

¿Puede un agente hacer ese ajuste solo, de forma fiable y sin hacer trampa? Es decir: ¿puede el arnés mejorar a partir de su propia experiencia mientras el modelo se queda como está?

Cómo lo prueba

Propone un método, AHE, y lo compara con tres arneses diseñados por personas —OpenCode, Terminus-2 y Codex— y con otros dos métodos automáticos, sobre las 89 tareas de Terminal-Bench 2. Después lleva el resultado, sin tocarlo, a otra tarea y a otros modelos.

Antes de ver cómo lo hace, conviene fijar qué es exactamente un arnés autoevolucionado.

El concepto

Qué es un arnés autoevolucionado

Un arnés que se modifica a sí mismo a partir de su propia experiencia. Se ejecuta sobre tareas cuyo resultado se puede verificar, se analiza cómo le ha ido y un agente edita sus componentes. Los pesos del modelo no se tocan: lo que aprende es el andamiaje.

Hoy, a mano

Lanzas el agente sobre un conjunto de tareas.
Lees las trayectorias de las que fallan.
Detectas un patrón: «siempre se atasca en…».
Retocas el prompt, una herramienta o un gancho del bucle.
Vuelves a lanzarlo y comparas.

Autoevolución

Los mismos cinco pasos, en bucle y sin ti:

• Los pasos 2 a 4 los hace un agente: lee las trazas, diagnostica y edita.
• El paso 5 lo decide una métrica, no una impresión: si el cambio no mejora, se revierte.
• Cada vuelta parte del mejor arnés conocido hasta el momento.

Es lo que haces cuando corriges tu CLAUDE.md después de ver al agente equivocarse, convertido en un proceso con datos que se repite solo.

El ciclo

Cinco pasos que se repiten

Cualquier arnés autoevolucionado repite este bucle. Lo que cambia de un método a otro es qué se observa, quién diagnostica y qué se deja editar.

┌► 1 EJECUTAR     el agente resuelve tareas

│       ▼

│  2 OBSERVAR     trazas + resultado verificado

│       ▼

│  3 DIAGNOSTICAR patrón de fallo y causa

│       ▼

│  4 EDITAR       un componente del arnés

│       ▼

└─ 5 DECIDIR      ¿mejoró? se queda : se revierte

Un ejemplo inventado, para verlo en marcha

En las trazas, el agente lee enteros archivos de miles de líneas y desborda el contexto en 12 tareas (observar). El analizador ve la causa: la herramienta devuelve el archivo completo (diagnosticar). El editor hace que read_file pagine por defecto y lo explica en su descripción (editar, capas 4 y 3). En la vuelta siguiente, si esas tareas pasan y no se rompe ninguna otra, el cambio se queda; si no, se revierte (decidir).

Ingrediente 1 · Una señal de verdad

Tareas con un verificador automático: tests, un benchmark, un comprobador de salida. Sin él no hay forma de saber si un cambio ayuda o solo lo parece.

Ingrediente 2 · Un espacio de cambios acotado

Qué archivos del arnés se pueden editar y cuáles no. El verificador y el modelo, nunca: si se pueden tocar, la forma más fácil de «mejorar» es hacer trampa.

Ingrediente 3 · Memoria de lo probado

Un historial de cambios y resultados para no repetir lo que ya falló ni perder lo que funcionó. Con git, cada cambio es un commit que se puede revertir.

La superficie

Qué partes del arnés pueden evolucionar

Todo lo que se puede editar cae en las capas 3 a 6: justo las que toca el modelo.

Pieza	Ejemplo de cambio	Capa
Prompt de sistema o «playbook»	Añadir la regla «comprueba el formato de salida antes de terminar»	5
Descripción de una herramienta	Explicar cuándo usar `edit_file` y cuándo `write_file`	3
Implementación de una herramienta	Paginar `read_file`; bloquear `rm` sobre los entregables	4
Middleware (ganchos del bucle)	Avisar cuando el agente repite el mismo comando fallido	5
Skills	Un procedimiento de despliegue que se carga solo cuando la tarea lo pide	3 y 6
Memoria a largo plazo	Guardar la lección «en este entorno, pip necesita --user»	6

Evolucionar texto

Prompt, playbook, memoria. Fácil y seguro de editar, pero el modelo puede ignorarlo, y se paga en tokens en cada llamada.

Evolucionar código

Herramientas y middleware. Obliga al comportamiento aunque el modelo se despiste y no ocupa contexto, pero es más difícil de editar sin romper nada.

Esta diferencia es la que separa los ejemplos que vienen a continuación.

Frente a entrenar

Evolucionar el arnés no es entrenar el modelo

Los dos buscan lo mismo —que el agente acierte más— pero cambian cosas muy distintas.

Aspecto	Entrenar el modelo	Evolucionar el arnés
Qué cambia	Los pesos	Archivos: prompts, herramientas, memoria
Qué hace falta	GPUs, datos, horas o días	Llamadas a la API
¿Se puede leer?	No	Sí: cada cambio es un diff
¿Se puede deshacer?	Volviendo a un checkpoint	Revirtiendo un archivo
Con un modelo cerrado	Solo lo que permita el proveedor	Sin límite: todo está fuera del modelo
Al cambiar de modelo	Hay que volver a entrenar	El arnés se lleva y se reajusta

Riesgo · Sobreajuste

Aprender trucos del benchmark que no sirven fuera. Por eso hay que probar el resultado en otras tareas.

Riesgo · Hacer trampa

Si puede tocar el verificador, el modelo o el presupuesto, «mejora» desactivando el examen.

Riesgo · Regresiones

Un cambio que arregla cinco tareas puede romper otras tres sin que nadie lo vea venir.

Riesgo · Interferencias

Dos cambios buenos por separado pueden estorbarse cuando se juntan.

No sustituye al entrenamiento: es otro eje. Un modelo mejor y un arnés ajustado a él se suman.

Los ejemplos

Tres formas de evolucionar un arnés

El paper compara tres métodos que parten de la misma semilla —un agente con una sola herramienta de shell— y los mide contra arneses que mantienen personas.

Método	Qué evoluciona	Cómo
ACE Agentic Context Engineering	texto	Destila de las trayectorias un «playbook» de estrategias en lenguaje natural que el agente lee en cada llamada.
Training-Free GRPO	texto	Compara varios intentos de la misma tarea y convierte en conocimiento lo que distingue a los que funcionaron; ese conocimiento viaja en el prompt.
AHE el método de este paper	texto código	Un agente edita prompt, herramientas, middleware, skills, subagentes y memoria, y cada cambio lleva una predicción que se comprueba en la vuelta siguiente.

La referencia: arneses hechos a mano

OpenCode, Terminus-2 y Codex no evolucionan solos: los diseñan y mantienen equipos de personas. Sirven para medir si la autoevolución alcanza a la ingeniería manual.

Tres pilares

Observabilidad en tres niveles

La tesis de AHE: el cuello de botella no es la capacidad del agente que hace los cambios, sino la observabilidad. Si ve un espacio de cambios claro y evidencia estructurada, converge solo. Por eso cada fase del ciclo deja artefactos que la siguiente puede leer y sobre los que puede actuar.

❶ Componentes

Sobre el framework NexAU, el arnés expone siete tipos de componente como archivos en rutas fijas. Cada cambio es un commit de git: diff por archivo y marcha atrás gratis. Cada patrón de fallo apunta a una sola clase de componente.

❷ Experiencia

Un Agent Debugger recorre las trayectorias como un sistema de archivos y reduce unos 10 millones de tokens a unos 10.000: un informe por tarea con la causa raíz del fallo —o el patrón del éxito— y un resumen global de entrada. Las trazas originales siguen a mano para comprobar.

❸ Decisiones

Cada edición va con una entrada en un manifiesto: evidencia, causa raíz, cambio y predicción —qué tareas arreglará y cuáles pone en riesgo—. La ronda siguiente la contrasta con los resultados; si no se cumple, se revierte.

Límites al evolucionador

Solo puede escribir en su espacio de trabajo: no toca el verificador, el modelo, las trazas ni el presupuesto de razonamiento, y no puede borrar las reglas originales del prompt. Así ninguna mejora sale de hacer trampa.

Componentes ↔ capas

Los siete componentes de NexAU, sobre las 8 capas

Lo que el evolucionador puede tocar, traducido al mapa de la Clase 11.

Componente	Qué es	Capa
Prompt de sistema	Reglas que aplican a todas las tareas	5 · lo que el bucle envía
Descripción de herramienta	El YAML que el modelo lee al llamarla	3
Implementación de herramienta	El Python que la ejecuta	4
Middleware	Ganchos en el bucle: antes del modelo, tras cada herramienta	5 (y 6 si compacta)
Skill	Flujos de trabajo que se cargan bajo demanda	3 y 6
Subagente	Delegación con contexto aislado	5
Memoria a largo plazo	Lecciones que persisten entre sesiones	6

La semilla: casi nada

Una sola herramienta de shell, sin middleware, sin skills, sin subagentes y tres reglas en el prompt. Es mínima a propósito: una semilla ya ajustada al benchmark no dejaría saber si la mejora viene del bucle. Cada pieza que añade AHE se gana el sitio con datos.

You solve software tasks in a

non-interactive setting. Your only

tool is run_shell_command…

- Prefer short replies; use the tool

  for actions.

- Before commands that delete or

  overwrite important data, state

  briefly what they do.

Los siete componentes caen en las capas 3 a 6. Nadie evoluciona el setup ni la UX: lo que se aprende es justo lo que toca el modelo.

El bucle de evolución

Diez vueltas, unas 32 horas

Los tres papeles —agente de código, depurador y evolucionador— usan el mismo modelo, GPT-5.4 (razonamiento high para programar, xhigh para evolucionar). La mejora no puede venir de un analista más listo: viene de las ediciones.

repetir 10 iteraciones:

  1 rollout     2 ejecuciones por tarea

  2 limpiar     normalizar las trazas

  3 atribuir    ¿se cumplió el manifiesto

                anterior? revertir lo que no

  4 depurar     Agent Debugger → informes

  5 evolucionar editar + nuevo manifiesto

  6 commit      etiquetar la iteración

quedarse con el mejor arnés visto

Iter. 2 prompt + herramienta
Flujo «contrato primero»: reglas para extraer el contrato de aceptación, imitar al evaluador y gestionar el tiempo, y un timeout de shell ajustable por llamada.
Iter. 5 prompt + herramienta
Guarda del estado publicado: tras pasar la comprobación final, el shell bloquea los comandos que borrarían los entregables. El agente «limpiaba» al final y rompía tareas ya resueltas.
Iter. 6 middleware
Monitor de riesgo entre pasos: vigila la secuencia de comandos y avisa ante siete patrones, como validar solo con --help, probar en localhost cuando el contrato pide otra interfaz o reintentar el mismo error.
Iter. 8 herramienta + middleware
Bloqueos duros tras el éxito, y los avisos de riesgo pasan al principio del turno siguiente: al final de la salida de la herramienta, el modelo los ignoraba.

Fíjate en el patrón: primero lo intenta con una regla en el prompt; cuando el modelo la ignora, la convierte en código que la hace cumplir.

Contra otros arneses

Hechos a mano frente a autoevolucionados

pass@1 en Terminal-Bench 2, 89 tareas, por dificultad oficial. En negrita, lo mejor de cada columna.

Arnés	Todas	Fáciles 4	Medias 55	Difíciles 30
Diseñados por personas
OpenCode	47,2	75,0	52,7	33,3
Terminus-2	62,9	75,0	74,5	40,0
Codex	71,9	75,0	80,0	56,7
Autoevolucionados desde la semilla
NexAU₀ (semilla)	69,7	87,5	78,2	51,7
ACE	68,9	91,7	78,2	48,9
Training-Free GRPO	72,3	100,0	79,4	55,6
AHE	77,0	100,0	88,2	53,3

+7,3 puntos sin tocar el modelo

Diez iteraciones llevan la semilla del 69,7 % al 77,0 %, por encima de Codex. Solo en las difíciles queda por detrás, por interferencia entre sus propios componentes: su memoria sola, insertada en la semilla, ya supera a Codex ahí (63,3 %).

Conecta con el paper 1

La semilla, con un shell y poco más, ya saca un 69,7 %: el hallazgo 4 otra vez. A un modelo capaz le basta bash; lo que le falta no son herramientas finas, sino disciplina alrededor.

Por qué ACE y TF-GRPO se quedan cortos

Solo evolucionan texto que el agente lee. La mejora de AHE está justo en las capas que ellos no tocan: herramientas, middleware y memoria.

Transferencia

¿Sobreajusta al benchmark? Lo prueban fuera

El arnés evolucionado se congela y se lleva, sin volver a evolucionarlo, a otra tarea y a otros modelos.

SWE-bench Verified, 500 tareas, con GPT-5.4
Arnés	Éxito	Tokens por intento
ACE	74,6 %	679K
Training-Free GRPO	74,2 %	582K
NexAU₀ (semilla)	75,2 %	526K
AHE	75,6 %	461K

ACE y TF-GRPO quedan por debajo de la semilla y gastan entre un 11 % y un 29 % más: su texto, destilado en Terminal-Bench, viaja en el prompt de cada llamada. AHE saca el mejor resultado con un 12 % menos de tokens que la semilla.

Terminal-Bench 2 con otros modelos (arnés evolucionado con GPT-5.4 high)
Modelo	Semilla	AHE	Mejora
GPT-5.4 medium	65,7	68,0	+2,3
GPT-5.4 high (el de la evolución)	69,7	77,0	+7,3
GPT-5.4 xhigh	72,5	74,7	+2,3
gemini-3.1-flash-lite	36,5	41,6	+5,1
deepseek-v4-flash	51,7	61,8	+10,1
qwen-3.6-plus	56,2	62,5	+6,3

Todos mejoran, y más los modelos más lejos de saturar: se apoyan en la coordinación que AHE ha fijado en herramientas, middleware y memoria. Dentro de GPT-5.4 la mejora no es monótona: pasos y timeouts se ajustaron para high, y con xhigh más intentos se pasan de tiempo.

Análisis

Dónde vive la mejora, y cuánto sabe el agente de lo que hace

Primero: meter en la semilla un solo componente evolucionado cada vez. Después: comparar lo que el evolucionador predijo con lo que pasó.

pass@1 en Terminal-Bench 2 con un solo componente de AHE
Variante	Todas	Fáciles	Medias	Difíciles
NexAU₀ (semilla)	69,7	87,5	78,2	51,7
+ solo memoria	75,3	50,0	83,6	63,3
+ solo herramientas	73,0	75,0	87,3	46,7
+ solo middleware	71,9	100,0	81,8	50,0
+ solo prompt de sistema	67,4	75,0	78,2	46,7
AHE completo	77,0	100,0	88,2	53,3

Herramientas, middleware y memoria mejoran por separado; el prompt de sistema solo, empeora (−2,3 puntos): son 79 líneas de disciplina que dependen de que existan las otras piezas. Y no suman: +11,1 puntos por separado frente a +7,3 juntos, porque varias empujan a la misma verificación de cierre y se pisan.

Predicciones del evolucionador frente a lo ocurrido (media de 9 rondas)
Predice…	Precisión	Recall	Azar (P / R)
qué arreglará	33,7 %	51,4 %	6,5 / 10,6 %
qué romperá	11,8 %	11,1 %	5,6 / 5,4 %

Al predecir qué arreglará, acierta unas cinco veces más que el azar. Al predecir qué romperá, apenas el doble: en 9 rondas anunció 43 regresiones, acertó 5, y se le escaparon otras 40. Sabe justificar por qué un cambio ayudará; no sabe prever qué va a romper.

Leer el paper 2 (PDF)Código de AHE

Conclusiones del paper 2

Qué nos llevamos de Agentic Harness Engineering, leído con el mapa de las 8 capas.

1 · El arnés se entrena sin tocar el modelo

Con el modelo congelado, diez iteraciones suben Terminal-Bench 2 del 69,7 % al 77,0 % y superan a Codex. La experiencia se acumula fuera de los pesos, en archivos que se leen, se versionan y se revierten: un eje de mejora que complementa al entrenamiento.

2 · Transfiere la estructura, no la prosa

La mejora vive en herramientas, middleware y memoria; el prompt solo, resta. Y el texto se paga en cada llamada: ACE y TF-GRPO gastan más y transfieren peor. Si una lección importa, conviértela en código —una guarda en el ejecutor (capa 4), un gancho en el bucle (capa 5)— antes que en otra línea del prompt.

3 · Sin observabilidad no hay evolución

Componentes en archivos, trazas destiladas en informes y cambios con una predicción verificable. Sin eso, la autoevolución degenera en prueba y error. Es la capa 7 de la Clase 11 convertida en motor: si tu arnés no deja rastro, no puede mejorar, ni solo ni contigo.

4 · Las piezas no suman

Componentes que funcionan por separado se estorban juntos: +11,1 puntos aislados frente a +7,3 combinados. Después de cada cambio hay que evaluar el arnés completo, no solo el cambio.

5 · El punto ciego son las regresiones

El evolucionador acierta cinco veces más que el azar al predecir arreglos y solo dos al predecir lo que rompe. Un arnés que se modifica solo necesita una batería de regresión fija y a alguien que revise lo que cambia.

6 · Prototipo, no piloto automático

Un solo benchmark para evolucionar, pasos y timeouts ajustados a un modelo, y sin guardarraíles completos para la automodificación. Los propios autores lo presentan como un prototipo de investigación controlado.

Con el paper 1, el círculo se cierra

El primero demuestra que el arnés óptimo depende del modelo, de la tarea y del presupuesto. El segundo ofrece una forma de reajustarlo cada vez que eso cambia: medir por componente y evolucionar con evidencia.

Para aplicar mañana en tu arnés

• Separa los componentes en archivos y versiónalos.
• Guarda las trazas y léelas con otro agente antes de tocar nada.
• Escribe cada cambio con su predicción: qué debería arreglar y qué podría romper.

El arnés también se mide

El modelo razona; el arnés decide qué ve, qué puede hacer y qué recuerda. Ahora sabes que cada una de esas decisiones se puede medir —y que la respuesta cambia con el modelo.

Clase 11: Arneses de agentes Paper 1 (PDF)Paper 2 (PDF)

Material complementario

Fragua Tech — Guías y plantillas