Prompt, context, loop y graph engineering resultaron ser una pieza de la misma máquina. El harness es donde finalmente conviven todos.
Cada etapa de la construcción con IA tuvo su propio título de trabajo. Prompt engineering llegó primero, cuando todo el oficio consistía en encontrar la frase correcta.
Context engineering siguió, una vez que quedó claro que la frase importaba menos que todo lo cargado a su alrededor. Este verano fue el turno de los loops, y unas semanas después, de los graphs.
El nombre que se está extendiendo ahora es harness engineering, y es el primero que explica a todos los demás.
Un harness es todo lo que rodea al modelo: las herramientas que puede llamar, los archivos que lee antes que nada, los directorios a los que puede escribir, la verificación que debe pasar su salida, el cronograma que lo despierta y la regla que termina la ejecución.
Cada disciplina anterior resulta ser un único componente de ese marco, construido por separado y con su propio nombre.
Empecé a prestar atención por una razón práctica. El modelo subyacente sigue cambiando, a veces diecisiete puestos en una sola actualización del leaderboard, y el harness es la única parte del sistema que permanece bajo tu control.
1/ Siete Ingenierías, Una Máquina
Disciplina
La pregunta que responde
Dónde vive en el harness
Prompt engineering
Qué estoy pidiendo exactamente
SKILL.md, la especificación de tarea cargada primero
Context engineering
Qué ve el modelo en cada paso
El ensamblador de contexto: restricciones, esquemas, páginas recuperadas
Tool engineering
Qué puede tocar, y en qué formato
Definiciones de herramientas con entradas y salidas tipadas
Loop engineering
Qué inicia una ejecución y qué la termina
El runner: disparadores, condiciones de parada, presupuestos
Graph engineering
Qué recuerda y cómo se conectan las cosas
La capa de memoria: nodos, aristas tipadas, alias
Eval engineering
Cómo se rechaza un resultado
El verifier, fuera del control del agente
Harness engineering
Qué mantiene unido todo lo anterior
El marco, los permisos y los hooks
Lee la tabla de arriba hacia abajo y es una historia. Léela de abajo hacia arriba y es una arquitectura: harness engineering es el trabajo de decidir dónde vive cada una de las otras seis, para que ninguna termine escondida en un prompt.
Ese último punto tiene la mayor carga de importancia.
Un prompt es el lugar más fácil para poner cualquier cosa, así que todo deriva hacia él: el formato de salida, la regla de parada, las correcciones de la semana pasada, la lista de cosas que el agente nunca debe tocar. Funciona perfectamente con el modelo para el que lo escribiste, y luego el siguiente modelo lee el mismo párrafo de manera diferente.
2/ Anatomía de un Harness
El hábito más útil que he adoptado es escribir todo el harness como un solo archivo de configuración, para que nada importante quede implícito:
1# harness.yaml2model: kimi-k3 # una línea. todo lo de abajo sobrevive a un cambio3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # nocturno, mientras duermes12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/
Tres líneas en ese archivo hacen la mayor parte del trabajo.
model: es una línea a propósito. Todo lo demás está escrito para no importar qué dice esa línea. Esa es toda la historia de portabilidad.
permissions: importa más que tools:, aunque esté más abajo en el archivo. Escribir qué puede cambiar el agente y sobre qué debe preguntar primero es lo que separa un sistema que dejas corriendo durante la noche de uno que te sientas a vigilar.
verify: tiene dos entradas por una razón. El script no cuesta nada y atrapa cualquier cosa mecánica. El reviewer es un segundo agente que nunca vio trabajar al primero, porque un agente que califica su propia salida encuentra todas las razones para aprobarla.
En el disco, el harness es una carpeta, y cada ingeniería de la tabla obtiene su propia dirección dentro de ella.
3/ Por Qué Kimi K3 Es el Motor Que Pondría En Él
Lo que necesita el harness
Lo que aporta Kimi K3
Un runner que pueda expandirse
Agent Swarm: hasta 300 agentes en un problema al mismo tiempo, sin escribir un orquestador
Código lo suficientemente fuerte para escribir sus propias verificaciones
#1 en Frontend Code Arena con 1,679, por delante de Fable 5 (1,631) y GPT-5.6 Sol (1,618), liderando 6 de 7 dominios
Un motor que mejora debajo de ti
De #18 a #1 en una sola actualización de julio
La primera fila importa más de lo que parece. Casi todos los harness caseros desarrollan un orquestador hecho a mano en algún momento, y suele ser el archivo más frágil de la carpeta. Con el swarm, la expansión se convierte en una línea de presupuesto, agents: 300, y el harness solo tiene que manejar lo que regresa.
La segunda fila importa porque un harness es principalmente código que el modelo escribe para ti: scripts de hooks, verificaciones de esquema, el pequeño dashboard que lee 40-runs. Un motor que lidera la arena frontend acierta esas cosas a la primera mucho más a menudo.
La tercera fila es el argumento para harness engineering en un solo dato. Cuando un modelo sube diecisiete puestos de la noche a la mañana, un harness pone ese ascenso a trabajar el mismo día, porque la única línea que tiene que cambiar es model.
4/ Hooks: Los Reflejos
Un hook es un script corto que el harness ejecuta en un momento fijo, independientemente de lo que decida hacer el modelo. Los hooks son donde un harness deja de ser un diseño de carpetas y empieza a comportarse como un sistema de seguridad.
Hook
Cuándo se dispara
Qué hace
pre_tool
Antes de cualquier llamada a herramienta
Bloquea escrituras fuera de la lista de permisos
post_tool
Después de cada retorno
Ejecuta la verificación de esquema y rechaza la salida malformada en el acto
pre_send
Antes de que algo salga de la máquina
Lo retiene en una cola hasta que tú lo apruebes
on_fail
Después de un resultado rechazado
Adjunta la razón del fallo al reintento
post_run
Cuando se alcanza la condición de parada
Añade el registro de ejecución a 40-runs y muestra las diferencias en el graph
El hook pre_tool de la primera fila cabe en cinco líneas:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
Solo el hook on_fail cambia la economía de un loop. Un reintento que lleva la razón por la que falló el último intento es una corrección. Sin esa razón, el loop paga por el mismo error una segunda vez.
5/ Cómo Se Ve Una Noche
Junta todas las piezas y el harness se comporta como un turno de noche que sigue reglas. A las 02:00 se dispara el trigger y la consulta de lanzamiento selecciona cada nodo que necesita trabajo. El swarm se expande, un agente por nodo.
Los retornos que no cumplen el esquema son rechazados por post_tool antes de llegar al graph, y cada nodo rechazado se reintenta una vez con su razón de fallo adjunta. Cuando un agente intenta escribir fuera de su carpeta, pre_tool lo detiene sin despertar a nadie.
Los nodos fusionados y las aristas tipadas aterrizan en 20-graph. Un correo electrónico redactado llega a pre_send y espera. post_run añade el registro, y el loop se detiene por su propia condición, muy dentro del presupuesto de 45 minutos de la configuración.
A las 07:30 lees un archivo y tomas dos decisiones. Ese es el costo total de la mañana de ejecutar loop engineering y graph engineering de esta manera, y ese es el objetivo principal del harness: todo lo que podía funcionar sin ti funcionó, y las pocas cosas que te necesitaban están esperando en un solo lugar.
6/ La Prueba de Cambio
La auditoría más rápida de cualquier configuración de agente: cambia la línea del modelo y vuelve a ejecutarlo. Lo que se rompa era un harness viviendo en el lugar equivocado.
Qué se rompe después del cambio
Dónde estaba escondido
Dónde pertenece
El formato de salida deriva
"always answer as JSON" en el prompt
Un esquema de retorno más un script que rechaza cualquier otra cosa
Las ejecuciones dejan de terminar por sí solas
"keep going until it's thorough"
Una condición de parada hecha de conteos
Las correcciones de la semana pasada desaparecen
El historial del chat
CONSTRAINTS.md, cargado en cada ejecución
La misma empresa aparece tres veces
El juicio del modelo
aliases.csv, verificado antes de fusionar
Escribe en algún lugar donde no debería
Una frase educada en el prompt
Una lista de permisos y un hook pre_tool
Una configuración que pasa la prueba de cambio es portable, y portable es lo que la hace valiosa.
Lo Que Cuesta y Lo Que Paga
Las empresas invierten trimestres enteros en plataformas internas de agentes. Un harness funcional es una carpeta, un archivo de configuración y cinco scripts cortos, y funciona con una suscripción a Kimi. Esa brecha es la oportunidad.
Canal
Lo que paga
Lo que necesitas primero
Configuración de harness para un equipo pequeño
Una tarifa única de cuatro cifras por la configuración, hooks y verifier alrededor de su flujo de trabajo
Un harness propio, funcionando según un cronograma
Retainer de día de lanzamiento
Una tarifa mensual para ejecutar la prueba de cambio en cada lanzamiento importante de modelo y mover al equipo al que lidere
Un cliente cuyas ejecuciones ya registran en 40-runs
Una plantilla de harness de nicho
La carpeta y el yaml empaquetados para una industria: investigación, reclutamiento, cumplimiento normativo
El mismo harness probado en dos mercados diferentes
El segundo canal es el que yo construiría primero. Cada lanzamiento importante reordena el leaderboard, K3 solo subió diecisiete puestos en una actualización, y cada equipo con un harness necesita alguien cuyo trabajo sea ejecutar la prueba de cambio el día del lanzamiento.
La Versión Corta
Prompt, context, tool, loop, graph y eval engineering resultan ser componentes de una sola máquina, y harness engineering es decidir dónde vive cada uno de ellos.
Pon el modelo detrás de una línea, los permisos por delante de las herramientas y el verifier fuera del agente. Entonces, el próximo salto en el leaderboard es un cambio de configuración en lugar de una reconstrucción.
Y si encontraste esto útil:
- Guarda este artículo en favoritos. Los enlaces cambian y aparecen nuevos repos semanalmente, necesitarás esto como referencia
- Para análisis profundos semanales sobre arquitectura de IA, trading cuantitativo y la economía de agentes, sígueme: @polydao
- Únete al Canal de TG: Buzzoni Notes - aquí comparto mis prompts crudos, skills personalizados y alpha que es demasiado pronto para X
