Harness² — Acoplamiento de Tareas Recurrentes
Adaptado de Harness²: Acoplamiento Recursivo de Agentes para un Mundo Abierto, reducido al caso donde una ejecución ya ha sido aceptada y el objetivo es repetirla.
Resumen
Tener éxito una vez no es lo mismo que ser repetible. La ejecución aceptada es tu único punto de referencia confiable: tiene un entregable real, una trayectoria real y los lugares que el usuario editó personalmente.
El objetivo de la optimización es el proceso de la próxima ejecución, no el entregable de esta ejecución. Por lo tanto, la salida no es un mejor informe, sino un arnés, un SOP y una lista de verificación de regresión.
Cuándo Usarlo
- El usuario dice "haremos esto cada semana de ahora en adelante" o "consolidemos este proceso"
- El mismo tipo de tarea se ha realizado al menos una vez, y ese resultado fue aceptado
- El proceso vive en la cabeza de alguien: quién ejecuta qué script primero, qué paso necesita una verificación humana, dónde están las trampas
- La misma clase de tarea sigue fallando de la misma manera: atribuciones de fuentes faltantes, definiciones inconsistentes, retrabajo constante
Cuándo NO Usarlo
- Tarea única → simplemente hazla
- Existe un calificador real, prueba unitaria o criterio de aceptación computable → úsalo; supera por mucho al contraste conductual
- El usuario solo quiere cambiar un formato o definición, y ha dicho cuál → edita el arnés directamente, omite el ciclo de contraste
- El proceso ya es estable y el costo o la latencia son ajustados
Qué es un arnés
Todo lo que rodea al modelo que se puede editar. Cuatro son suficientes para ejecutar; ocho es el conjunto completo:
| Componente | Rol | Mínimo |
|---|---|---|
| prompt del sistema | rol, contrato de salida | ✅ |
| guía de herramientas | cuándo usar cada fuente de datos, cómo llenar argumentos | ✅ |
| habilidades | juicio y procedimientos reutilizables | ✅ |
| barreras de protección | restricciones duras (nunca inventar números, siempre citar fuentes) | ✅ |
| memoria | notas de dominio transportadas entre instancias | |
| scripts | trabajo determinista (conversión, deduplicación, agregación) | |
| subagentes | verificación o recuperación paralela separada | |
| plugins | middleware (forzar una auto-verificación cada N pasos) |
Un arnés debe existir como archivos para poder ser diferenciado y reutilizado. "Normalmente lo hacemos así", dejado dentro de un chat, no puede ser consolidado.
El ciclo: Proponer → Sondear → Componer
0. Congelar la línea base
Archivar la última ejecución por completo: instantánea del arnés, trayectoria completa (secuencia de llamadas a herramientas + artefactos intermedios), entregable final, el diff de edición del usuario, criterios de aceptación, instantánea de datos o ventana de tiempo.
Los lugares que el usuario editó personalmente son ubicaciones de defectos de alta confianza, más confiables que cualquier suposición.
1. Proponer
Leer la línea base, luego proponer dos candidatos, cada uno con una frase que nombre el defecto al que apunta:
- invariante: defectos de proceso — sin verificación cruzada, resultados intermedios nunca persistidos, fallos no reintentados, fuentes sin etiquetar, contexto desbordado
- de dominio: restricciones profesionales de esta clase de tarea — definiciones consistentes, conversión de moneda o unidades, ventanas de tiempo alineadas
Necesitas ambos para separar "enfermedad general" de "enfermedad específica de esta clase de tarea". Con un solo candidato no puedes atribuir el resultado.
2. Sondear
Reproducir con la misma entrada, controlando variables: mismo modelo, mismo conjunto de herramientas, misma instantánea de datos. Solo el arnés cambia.
Comparar dos cosas:
- Delta conductual contra la línea base: conjunto y orden de herramientas, número de pasos, llamadas repetidas, errores y reintentos, si los puntos de parche humano desaparecieron, si los intermedios se persistieron, si las fuentes están completamente atribuidas
- Consistencia de reproducción: ejecútalo de nuevo — ¿la estructura es la misma? La métrica central de la consolidación es la estabilidad, no el mejor resultado en una sola ejecución
El contraste muestra "el comportamiento cambió". No muestra "el resultado es correcto". Nunca confundas los dos.
3. Componer
Conservar solo los cambios que (a) aún cumplen los criterios de aceptación después de la reproducción y (b) reducen el retrabajo o el parcheo humano. Mantener el original está permitido — un cambio sin evidencia es ruido.
Registrar cada decisión en una línea: cambio | defecto objetivo | evidencia observada | adoptado / revisado / descartado.
4. Consolidar
Tres artefactos; faltar cualquiera significa que no está consolidado:
harness/— los archivos editablesSOP.md— pasos, puntos de control, cuándo se debe preguntar a un humano, trampas conocidas (más de diez elementos y nadie lo lee)REGRESSION.md— la lista de verificación de aceptación para repasar después de la próxima ejecución
Si un cambio se adopta en varias rondas, promuévelo a un script o habilidad independiente.
Jerarquía de evidencia
diff de edición del usuario > comparación contra el entregable aceptado > consistencia de reproducción > delta de trayectoria > intuición
No es evidencia: un informe más largo o más detallado, "el usuario no se quejó esta vez", el modelo afirmando que lo hizo mejor.
Presupuesto
Por defecto k=1 más una reproducción. La consolidación se amortiza con el tiempo, así que distribúyela en varias rondas: sondea un candidato durante cada ejecución recurrente, en lugar de gastar 3× una vez para ejecutar todas las ramas paralelas.
Banderas rojas — detente cuando veas una
- Heredar el arnés anterior por completo sin leer el diff de edición del usuario
- Reproducir con una entrada, modelo o instantánea de datos diferentes y aún así afirmar "es mejor"
- Concluir a partir de una sola reproducción sin descartar la aleatoriedad
- Cambiar cinco componentes a la vez, haciendo imposible la atribución
- Un SOP de 20 elementos que nadie seguirá la próxima vez
- Escribir un truco suerte de una sola vez como una entrada invariante
Errores comunes
| Error | Consecuencia | Solución |
|---|---|---|
| Optimizar antes de archivar | línea base perdida, cambios no atribuibles | congela la línea base primero |
| "Se lee mejor" como evidencia | consolidas una preferencia, no un proceso | vincúlalo a una observación concreta |
| Cambios solo en el prompt, sin puntos de control | los humanos siguen parcheando a mano la próxima vez | empareja cada defecto con un punto de control |
| SOP escrito como un relato de viaje | nadie lo lee, así que nada se consolida | escribe solo puntos de decisión y trampas |