2026-07-22 · Actualizado 2026-07-22

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Harness engineering para agentes AI: diseño del bucle que rodea al modelo

Parte 6 de la serie de ingeniería de la pila Agentic

El reasoning loop de un agente elige la acción siguiente. Su harness proporciona contexto, valida y autoriza las tool calls propuestas, envía las solicitudes aceptadas al runtime, registra los resultados y determina si la tarea está completada.

Los modelos proponen modificaciones y pueden declarar que las tareas están completas, mientras que el harness controla los permisos e interpreta las comprobaciones de aceptación que determinan si el bucle puede finalizar. Parte 5 Se abordó el runtime que mantiene el proceso en ejecución. Este artículo se centra en el código de control contenido dentro de ese runtime: cómo determinar si cada actualización es útil y cómo garantizar que los controles resultantes sigan siendo localizables a medida que el harness evoluciona.

Más allá de la primera comprobación de aceptación explícita, cada intento de reintentar, transferencia o evaluador adicional constituye una hipótesis sobre un fallo observado. Solo obtiene validez cuando una comparación controlada demuestra que resulta útil.

Para concretar esa ruta de control, utilizaré un pequeño repositorio de tienda ficticio. La tarea de programación consiste en reducir el umbral para aplicar un descuento automático del 10% de 100 $a 75$, src/checkout.py. El repositorio cuenta con dos comprobaciones obligatorias:

• pytest tests/test_checkout.py Verifica el cálculo del descuento. pnpm playwright test tests/checkout_discount.spec.ts Añade un artículo de 80 $en una tienda de prueba local y verifica que la página de pago muestre un descuento de 8$.

El ejemplo constituye un recurso didáctico, y no una aplicación real ni benchmark. Cada intento parte del mismo commit así como de los datos de prueba iniciales. El harness solo podrá aceptar el cambio cuando ambas comandos den resultado positivo y el rastreo relacione dichos resultados con el commit sometido a pruebas.

En las secciones posteriores se pasan deliberadamente a otros dos ejemplos. Un orden de puesta en producción API ilustra por qué las llamadas que modifican el estado requieren protección contra reproducciones no autorizadas, mientras que una migración de adaptador de pagos muestra qué es necesario para que una nueva sesión del modelo retome el trabajo inconcluso. El laboratorio complementario al final es nuevamente independiente: es ejecutable, pero contiene tareas simuladas genéricas en lugar de este repositorio de tiendas.

TL;DR: Comience con un único modelo, unas pocas herramientas especializadas y una verificación explícita de aceptación. Añada intentos repetidos cuando los registros muestren fallos transitorios en las llamadas. Implemente una transferencia de progreso cuando las sesiones reanudadas realicen el mismo trabajo. Al probar cualquier cambio, mantenga fijas la versión del modelo, las tareas, el evaluador y el presupuesto total. Elimine el componente cuando no mejore el resultado medido.

El diagrama muestra la evolución del descuento desde la propuesta hasta la evidencia. El harness proporciona la tarea y los archivos, y verifica la propuesta presentada. edit_file Los argumentos y permisos, y luego se envía la llamada aceptada. Una vez que runtime aplica la edición, harness ejecuta las pruebas unitarias correspondientes y las pruebas de aceptación en el navegador. Una orden fallida vuelve al modelo como evidencia para una nueva iteración; dos órdenes exitosas hacen que el cambio sea apto para su aceptación.

Qué posee el harness

de OpenAI Desglose paso a paso del bucle Codex Describe el ciclo básico. El harness reúne un prompt, solicita al modelo la acción siguiente, envía una tool call aceptada al runtime, agrega el resultado obtenido y vuelve a hacer la solicitud hasta que el harness apruebe dicho resultado o devuelva el control al usuario.

Las implementaciones pueden fusionar varias responsabilidades en un único proceso. Sin embargo, los límites de fallo siguen siendo distintos:

Cuando aparece una falla, se debe diagnosticar el límite que debería responder. Un plan deficiente podría requerir instrucciones más precisas o un razonamiento basado en modelos más adecuado. Si edit_file Dirige una ruta al exterior src/El harness debe rechazarlo, mientras que un proceso sandbox que muere antes de que se ejecute la edición pertenece al runtime, el cual debe reiniciar al trabajador o informar sobre la caída.

el propio de OpenAI harness-estudio de caso de ingeniería Describe una instancia de aplicación arrancable para cada worktree. El equipo también integró la automatización de navegadores en el entorno del agente y expuso los registros, métricas y trazas correspondientes.

Una tarea como “ningún intervalo en estos cuatro recorridos críticos del usuario debe superar los dos segundos” pasó a ser verificable gracias a que el agente podía ejecutar la aplicación y consultar las mismas señales que un ingeniero inspeccionaría. El estudio de caso es específico del producto. Lo que se transfiere es la condición subyacente al resultado: la aplicación y sus indicadores de rendimiento tenían que estar disponibles dentro del entorno del agente.

Lopopolo, el autor de ese caso de estudio, mantiene un Guía práctica para harness de ingeniería Ese enfoque identifica las dos estrategias fundamentales que aborda este artículo: tratar el modelo y el agente de programación como cajas negras inmutables, e ingenierizar el contexto y las herramientas que los rodean. Su planteamiento también explica por qué una gran parte del harness termina convirtiéndose en código ordinario.

La barra de calidad, los procedimientos, el historial de excepciones y las relaciones de autoridad de una organización se encuentran por debajo del nivel de conocimiento que puede alcanzar un modelo genérico. El harness los hace visibles como instrucciones de repositorio, reglas de permisos y comprobaciones de aceptación. Cada ejecución aceptada puede reinsertar sus aprendizajes en dichos artefactos, en lugar de depender de la siguiente sesión para redescubrirlos.

Seguir el cambio en el descuento desde la propuesta hasta la aceptación

Para la tarea de descuento definida anteriormente, el modelo propone realizar un cambio calculate_discount en src/checkout.py. Antes de eso ocurren varias cosas modificar el código se considera un avance:

1. El generador de contexto suministra la tarea, las instrucciones del repositorio, los archivos relevantes, los resultados anteriores de tool results, y el plan actual.
2. El modelo propone un edit_file llamada con una ruta y texto de reemplazo.
3. El límite de la herramienta (el código harness entre la propuesta y la ejecución) valida los argumentos, comprueba si la ruta pertenece al ámbito permitido y solicita aprobación si la operación la requiere.
4. El runtime aplica la edición en el sandbox y devuelve un resultado estructurado.
5. El harness se ejecuta pytest tests/test_checkout.py, seguido de pnpm playwright test tests/checkout_discount.spec.ts, y lee ambos códigos de salida. La prueba en el navegador verifica el descuento visible de $8 en el carrito inicializado con $80.
6. El harness determina qué significan los resultados. Una comprobación fallida se convierte en el nuevo contexto para la siguiente iteración del modelo, mientras que una ejecución exitosa hace que la tarea sea candidata a finalización.
7. Un resultado positivo solo se considera evidencia de finalización después de que el harness registre la orden, el código de salida y la versión del artefacto probado en el registro de trazas.

En la fase 2, ningún archivo ha sufrido cambios. El harness puede rechazarlo. ../../secrets.env, es necesario obtener aprobación para ejecutar una orden destructiva, o bien detener una ejecución que haya agotado su presupuesto. Una vez finalizados los tests, el harness lee por sí mismo sus códigos de salida. El modelo no puede marcar como exitoso su propia edición.

El rastro debe mostrar la ruta propuesta y el texto de reemplazo, la decisión de permisos, los archivos que se modificaron, el commit probado y los resultados de ambos comandos. Un paso final done Un mensaje que no incluye dichos registros no demuestra que este cambio haya superado las verificaciones requeridas.

Determine dónde se aplica cada regla

Poner tests/checkout_discount.spec.ts Dentro de la lógica habitual del programa, el harness envía la orden de Playwright al runtime, lee su código de salida y se niega a finalizar la ejecución mientras esta falla. Un prompt puede recordarle al modelo que ejecute la prueba, pero no puede impedir que este declare éxito sin contar con evidencias suficientes.

Otras reglas se aplican a capas diferentes:

Los contratos de herramienta separan la propuesta de la autorización

La tarea de descuento solo requiere ediciones en los archivos y comandos de prueba. Un API que modifica el estado presenta un modo de fallo distinto, por lo que se deben cambiar los ejemplos de esta sección. Supongamos que el agente puede llamar create_test_order ante un servicio de orden de preparación al configurar los datos de prueba. Esta herramienta no forma parte de las verificaciones de aceptación de la tarea de descuento. Resulta útil en este caso porque un tiempo de espera excesivo puede ocultar si el servicio creó o no un pedido.

El límite del herramienta requiere algo más que una descripción en lenguaje natural. Para create_test_order, el harness necesita un contrato con:

• argumentos validados, de modo que la entrada mal formada es rechazada antes de la ejecución
• un resultado estructurado como { "order_id": "123", "created": true }, por lo que las verificaciones posteriores no necesitan analizar texto libre.
• Una categoría de efecto que indica si la llamada solo obtiene información o modifica un archivo, una entrada de base de datos o un servicio externo. También registra si es seguro repetir la llamada. Esta etiqueta informa a harness si un intento automático de reintentar podría duplicar el trabajo: puede volver a intentarlo. get_order_status cuando el servicio define esa consulta como de solo lectura, pero no debe intentarla nuevamente de forma ciega create_test_order porque la primera llamada ya podría haber creado el pedido
• una política de tiempo de espera y reintentos, de modo que una respuesta perdida no genere una secuencia ilimitada de llamadas
• una regla de permisos que especifica qué tipo de aprobación se requiere. La lectura del estado del pedido puede realizarse automáticamente, mientras que la creación de un pedido puede necesitar confirmación

La descripción en lenguaje natural es el texto que se muestra al modelo. Puede decir algo como: “Crear un pedido de prueba para la verificación de pago”. Esa frase ayuda al modelo a decidir cuándo proponerlo. create_test_order. No autoriza la llamada. En este ejemplo, el cliente de harness’s MCP valida los argumentos, aplica sus propias reglas y comprueba la confiabilidad del servidor, los requisitos de aprobación y las condiciones de seguridad para volver a intentarlo antes de enviar cualquier solicitud.

Un servidor MCP publica descripciones de las herramientas y anotaciones opcionales sobre su comportamiento hacia el cliente. Un servidor defectuoso o malicioso podría describir una herramienta que modifica estados como inofensiva. Si el cliente aceptara automáticamente esa afirmación, es posible que la ejecutara o intentara ejecutarla de nuevo. create_test_order sin autorización y se crea un duplicado; por lo tanto, la especificación de MCP exige que los clientes lo traten como Las anotaciones de herramientas se consideran no fiables. a menos que se confíe en el propio servidor.

La especificación no establece un parámetro de confianza universal único. Por lo tanto, el cliente necesita una política de confianza explícita para su despliegue; un servidor no puede hacer que sus propias anotaciones sean fiables. Dicha política determina qué metadatos pueden influir en las decisiones relativas a permisos o intentos de reintentar, y cuáles anotaciones solo tienen carácter informativo.

Al intentar volver a ejecutar una llamada que modifica el estado, es necesario contar con protección contra reproducciones no autorizadas

Se presenta un problema de reintentos más complejo cuando create_test_order Se crea el pedido, pero su respuesta HTTP se pierde. El harness detecta un tiempo de espera y no puede determinar si el servidor completó la solicitud. Repetir la llamada podría generar un segundo pedido.

Una consulta de estado puede volver a intentarse cuando el servicio la define como de solo lectura. Una llamada de creación necesita protección, como una clave de idempotencia: el cliente adjunta un identificador único de solicitud, y el servicio devuelve el primer resultado en lugar de crear otro pedido al detectar ese mismo identificador. Sin esta protección, el harness debería verificar si el pedido ya existe o solicitar una decisión humana antes de realizar otro intento. AWS documenta este patrón en sus Guía para operaciones idempotentes API.

La aceptación requiere pruebas independientes.

un éxito create_test_order La respuesta solo confirma que la herramienta devolvió datos. No demuestra que una tarea de programación haya superado sus pruebas. Si una prueba en el navegador posterior depende del orden en que se ejecutan las etapas, el harness debe validar el esquema de la respuesta y seguir ejecutando dicha prueba antes de aceptar el cambio de código.

Algunos criterios no pueden traducirse a un código de salida. En el caso de tareas de diseño visual por separado, un evaluador nuevo puede comparar una página o diagrama renderizado con una rúbrica escrita. Los equipos deben contrastar dicha evaluación con las revisiones hechas por humanos antes de utilizarla como umbral para considerar la tarea completada.

Se necesita una transferencia de responsabilidades para la migración del adaptador de pagos

Cambia de tarea nuevamente, pero permanece en el repositorio del establecimiento ficticio. Ahora el agente debe migrar el proceso de pago desde el adaptador v1 hasta v2. Esta tarea abarca al manejador de pagos, al cliente de pago, la configuración y las pruebas, por lo que es posible que dure más de una sesión del modelo.

Antes de que la primera sesión alcance su límite de contexto, ya ha modificado varios archivos, iniciado un pago local sandbox, y se ha ido tests/payment_migration.spec.ts Está fallando. Ese test de aceptación del navegador completa un pago a través del adaptador v2 y verifica el ID del proveedor registrado. Un resumen de la conversación puede servir de guía para la siguiente sesión del modelo, pero no puede reiniciar el sandbox ni demostrar qué archivos están modificados en ese momento.

La próxima sesión debe recuperar tres elementos:

La compactación sustituye los mensajes antiguos por un resumen más breve para que la sesión actual pueda continuar. Una transferencia de progreso registra lo que necesita la siguiente sesión: la rama actual, los archivos modificados, la última orden de prueba y sus resultados, así como el siguiente paso sin resolver. Si la conversación anterior contiene suposiciones obsoletas, el harness puede iniciar una nueva sesión del modelo utilizando dicha transferencia y el espacio de trabajo actual. Sustituir un trabajador que ha fallado y restaurar sus procesos constituye un trabajo de recuperación independiente, denominado runtime.

Una pequeña edición en la documentación podría no requerir ninguno de estos mecanismos. En cambio, la migración de pagos necesita una transferencia de responsabilidades una vez que el trabajo trasciende sesiones distintas, ya que la siguiente sesión del modelo debe reconstruir tanto el espacio de trabajo como el estado de la tarea.

los experimentos de Anthropic con agentes de programación de ejecución prolongada utilizaba el historial de Git y un archivo de progreso entre sesiones, mientras que en versiones posteriores harness-informe de diseño Separa la compactación del traspaso de contexto fresco y muestra la orquestación adicional, el consumo de tokens y el tiempo de ejecución necesario para dichos traspasos.

Utilizar trazas para diferenciar tres tipos de fallos

Las tres filas siguientes son bocetos ilustrativos de trazas, y no representan ejecuciones medidas ni resultados provenientes del laboratorio asociado. Cada fila muestra un tipo de fallo distinto y, por lo tanto, una respuesta diferente de harness.

Esta distinción es importante porque un 503 Esto no garantiza que todas las llamadas puedan reintentarse de forma segura. La primera fila corresponde a una consulta de solo lectura. La segunda fila representa una solicitud que modifica el estado, por lo que la clave de idempotencia y el estado en el servidor determinan si se permite otro intento de creación. La tercera fila no se debe a ninguna falla del herramienta; el harness aún no ha recopilado la evidencia necesaria para aceptar el cambio en el descuento.

Un registro de conversación guarda lo que el modelo procesó. No es posible determinar si el servicio de pedidos envió la solicitud antes de que la respuesta desapareciera. El rastro debe incluir la llamada realizada por el cliente, la decisión de aprobación, la clave de idempotencia, el resultado del servidor o la consulta de estado, la confirmación de la transacción probada, y el resultado de las pruebas de aceptación. Dichos campos indican al harness por cual de los tres caminos se encuentra en ese momento.

Antes de añadir un componente, debe especificarse el fallo recurrente que dicho componente está destinado a reducir y el valor que se monitorizará. Es necesario eliminar el componente si una comparación controlada no logra disminuir ese valor lo suficiente como para compensar su costo.

Medir un cambio a la vez

Un análisis de ablación mide si un componente harness genera el efecto esperado al modificarlo o eliminarlo, manteniendo constante el resto del experimento. Por ejemplo, ¿ayuda la verificación gramatical del editor a este modelo en este conjunto de tareas?

Utiliza el siguiente protocolo:

1. Congelar la versión del modelo, las instancias de tarea, el entorno, el evaluador y prompts que se encuentran fuera del componente bajo prueba.
2. Asignar a ambas variantes el mismo presupuesto total en términos de tokens, tiempo y coste económico.
3. Elegir el número de pruebas o la regla de parada antes de ejecutar la comparación.
4. Ejecutar las mismas instancias de tarea en ambas variantes. Dado que las salidas del modelo varían, repetir cada tarea varias veces.
5. Informar tanto del valor medio como de la dispersión o intervalo de confianza.
6. Contar todas las pruebas iniciadas, incluyendo los tiempos de espera, las interrupciones por política, los fallos harness y los errores del evaluador.

La tasa de éxito por sí sola puede ocultar la existencia de un componente costoso. Como mínimo, se debe hacer seguimiento de las tareas fallidas que se hayan marcado como completas, del costo y del tiempo invertido por tarea completada, de los errores en las herramientas, de los pedidos duplicados, de los minutos dedicados a las revisiones y de las anulaciones manuales de permisos. Es necesario elegir la métrica que refleje realmente el coste asociado al producto. Un aumento de dos puntos en el número de tareas completadas representa una mala inversión si esto hace que la cola de revisiones se duplique.

Un experimento de migración de pagos emparejado permite hacer medible la transferencia de progreso. Cada par de grupos de control y tratamiento parte del mismo commit del repositorio e incluye checkpoint, así como el mismo modelo, tarea, evaluador y presupuesto total. La transferencia constituye el único cambio aplicado. La métrica principal cuenta las acciones repetidas de las herramientas tras reanudar el proceso: se considera una acción duplicada aquella cuya operación y su resultado coinciden con un paso que ya había sido completado en la sesión anterior.

El Artículo sobre SWE-agent Corrige los problemas de GPT-4 Turbo en la subconjunto de 300 tareas de SWE-bench Lite y reporta un 18,0 % de casos resueltos con su interfaz completa, frente al 11,0 % del agente que solo utiliza la consola. El artículo también modificó algunas características específicas de la interfaz:

Estas cifras corresponden a dicho modelo, benchmark, y al límite de 4 dólares por tarea. El without linting, full file, y full history Las filas corresponden a las pruebas útiles de un solo parámetro: en cada una se modificaba una característica de la interfaz, manteniendo fijos el modelo y la configuración de evaluación.

LangChain ha publicado una versión más amplia comparación de modelos fijos para deepagents-cli. Indica un aumento según Terminal-Bench 2.0, pasando del 52,8 % al 66,5 %. gpt-5.2-codex Se corrigió mientras su equipo modificaba el system prompt, las herramientas y el middleware. La publicación agrupa varias modificaciones y omite el intervalo de confianza, la comparación del presupuesto total corregido y la tabla de ablación por cambio. Ese resultado no permite identificar cuál es la modificación realmente útil.

Anthropic’s informe de aplicación de ejecución prolongada Se trata de un estudio de caso cualitativo y específico del producto, y no de un experimento controlado benchmark. Su evaluador verificó 27 criterios del editor de niveles en la Sprint 3. El equipo informa que las llamadas realizadas por el evaluador supusieron una carga adicional en tareas que Opus 4.6 podía completar de forma fiable por sí solo, aunque aún resultaban útiles cerca de los límites del modelo; por ello, se eliminaron los componentes harness uno a uno tras la actualización del modelo. Este ejemplo sirve como motivo para volver a validar la estructura existente cuando hay cambios en el modelo, pero no permite estimar un tamaño de efecto general.

Mantener harness editable una vez que ocupe su posición en el sistema

La ablatión mantiene un harness reducido, pero su código puede seguir existiendo más allá de la vida útil del modelo para el que fue ajustado. Una solicitud como “enmascarar secretos en cada ruta de captura” se refiere a un comportamiento, no a un archivo concreto. En un harness en producción, dicho comportamiento puede abarcar distintas fases de ejecución así como estados compartidos. Por lo tanto, un humano o un agente de programación debe localizar todos los puntos de implementación antes de poder modificarlos de forma segura.

Un preprint de 2026 de Wang y colaboradores, el Harness Manual de instrucciones, Este paso se denomina behavior localization. La guía crea un mapa centrado en el comportamiento a partir de la base de código harness. El análisis estático extrae un grafo del programa sin llamadas a modelos, y posteriormente un LLM organiza sus unidades en fases de ejecución.

El mantenedor o agente de codificación comienza con una visión general del sistema, abre la fase de ejecución correspondiente y desciende hasta las entradas basadas en el código fuente de una función o archivo. Una vista de registro registra dónde se escribe y se lee el estado compartido entre las distintas fases. Esta jerarquía mantiene la visión general compacta al mismo tiempo que conserva un camino directo hacia el código fuente.

La actualidad es una regla independiente. Cada localizador debe resolverse contra el repositorio en tiempo real. La guía excluye las entradas obsoletas en lugar de hacer conjeturas, y cada diferencia no nula vuelve a sincronizar las entradas que afecta.

El diagrama resume el ciclo de modificación: una solicitud que contiene únicamente información sobre comportamientos desciende por los niveles del manual; cada localizador candidato se verifica contra el repositorio en tiempo real antes de que se redacte el plan, y cada diferencia aplicada vuelve a sincronizar el mapa.

El Evaluación de manuales sigue el protocolo que defiende este artículo. En dos plataformas de código abierto (Terminus-2, seis archivos en Python y el monorepo Codex con 2.267 archivos en Rust), un planificador de solo lectura impulsado por DeepSeek-V4-Pro exploró el repositorio directamente o lo hizo a través del manual. Las solicitudes, los permisos del repositorio y de la herramienta, así como el proceso de decodificación, fueron idénticos en ambos escenarios. Tres evaluadores (GPT-5.5, Opus 4.8 y DeepSeek-V4-Pro) calificaron cada plan de edición en función de la localización, el control del alcance y el razonamiento:

El planificador asistido por manual logró más éxitos con mayor frecuencia y empleó menos tokens de planificación en ambos repositorios. Las condiciones asociadas a dicho resultado fueron las siguientes: tres LLM jueces evaluaron los planes de edición generados por un modelo de planificador en dos entornos de integración. El estudio se centró en la evaluación de los planes, sin analizar las diferencias efectivamente aplicadas ni las tasas de defectos en la producción.

Las secciones anteriores utilizan trazas para explicar por qué existe un componente. Este mapa responde a la siguiente pregunta: ¿dónde se encuentra ese componente cuando es necesario modificarlo?

Pruebe el método en el laboratorio complementario

El harness: proyecto de demostración en el commit 517353f3 es un ejercicio pequeño y determinista que incluye 12 tareas sintéticas genéricas que abarcan cambios en el código como fix-parser-edge-case, split-large-module, y wire-browser-test. No implementa el repositorio de tiendas ficticio.

Cada fixture de tarea declara un nivel de dificultad además de cuatro condiciones booleanas: una herramienta inestable, progreso perdido, una brecha en la implementación no cubierta y una condición de finalización ambigua. El simulador deriva una quinta condición para las tareas difíciles que también requieren un archivo de progreso: la ausencia del mismo. context_reset, la compactación conserva las suposiciones obsoletas. Un evaluador determinista marca una tarea como aprobada únicamente cuando la configuración seleccionada gestiona todas las condiciones aplicables. No se ejecuta ningún modelo ni servicio externo.

Los comandos responden a diferentes consultas:

• make check Ejecuta Ruff y siete pruebas unitarias, entre las que se encuentra el validador que rechaza cualquier par de ablaciones que modifique más de un componente. make run Imprime una matriz de enseñanza acumulativa y, a continuación, cinco comparaciones válidas de tipo “dejar un componente fuera”. make failures asigna un nombre a la condición no manejada para cada tarea fallida. El harness completo debe finalizar con all synthetic tasks pass.

make check
make run
make failures

La sección de causalidad make run Parece ser esto:

component                 control  treatment  delta
retry_policy              8/12     12/12       +4
progress_handoff          7/12     12/12       +5
evaluator                 8/12     12/12       +4
fail_closed_acceptance    7/12     12/12       +5
context_reset            10/12     12/12       +2

Para cada fila, el control corresponde a la configuración completa con un componente eliminado; el tratamiento, por su parte, restablece únicamente dicho componente. La matriz acumulativa anterior resulta útil para la orientación, pero algunas de sus filas adyacentes añaden varios componentes a la vez y, por lo tanto, no permiten identificar una causa concreta.

El laboratorio valida cada par declarado antes de ejecutarlo. Sus pruebas de regresión también incluyen un par intencionadamente inválido que modifica simultáneamente la política de reintentos y el evaluador; el validador lo rechaza.

El esquema de configuración del laboratorio verifica los cinco campos de componente. Este fragmento ejecutable muestra la misma protección en una pareja válida de transferencia de progreso:

from dataclasses import dataclass, fields


@dataclass(frozen=True)
class Config:
    progress_handoff: bool = False
    evaluator: bool = False
    retry_policy: bool = False
    fail_closed_acceptance: bool = False
    context_reset: bool = False


def changed_components(control: Config, treatment: Config) -> tuple[str, ...]:
    return tuple(
        field.name
        for field in fields(control)
        if getattr(control, field.name) != getattr(treatment, field.name)
    )


control = Config(progress_handoff=False, evaluator=True, retry_policy=True)
treatment = Config(progress_handoff=True, evaluator=True, retry_policy=True)
assert changed_components(control, treatment) == ("progress_handoff",)

Comience con un bucle y una comprobación de aceptación

Comenzaría creando un agente de programación harness que incluya un modelo capaz, instrucciones para el repositorio, unas pocas herramientas especializadas, un sandbox, y una prueba de aceptación explícita. Registraría los tool calls, los resultados, los costes y dicha prueba final en un único registro de trazabilidad, de modo que los primeros fallos útiles queden visibles sin necesidad de reconstruirlos a partir de los registros de la terminal o las transcripciones de chats. Se trata de una línea base propuesta, y no de datos provenientes de un sistema ya desplegado.

A partir de ahí, solo se debe añadir aquello que esté justificado por el seguimiento del rendimiento. Se debe registrar quién mantiene cada componente, cuántos tokens o segundos añade, y qué prueba de regresión justificaría su eliminación tras una actualización del modelo.

Seis meses después, alguien que lo vea progress_handoff=True Debe ser capaz de localizar las trazas fallidas que justificaron dicho estado y los casos de regresión que siguen manteniéndolo en esa condición. Dichas trazas explican por qué el componente existe; por su parte, un mapa del comportamiento actual indica dónde intervenir.

Referencias

• OpenAI, Despliegue del Codex agent loop.
• OpenAI, Harness engineering: aprovechar Codex en un mundo orientado a los agentes.
• Lopopolo, Harness engineering: antología, guía de campo y paquete de contexto del agente.
• Ingeniería Anthropic, Mecanismos eficaces para agentes de ejecución prolongada.
• Ingeniería Anthropic, Harness diseño para el desarrollo de aplicaciones de ejecución prolongada.
• LangChain, Mejora de agentes profundos mediante harness engineering.
• Yang et al., SWE-agent: Las interfaces agente-computadora permiten la ingeniería de software automatizada.
• Wang y colaboradores, Harness Manual: Cómo hacer que los frameworks de agentes en evolución sean legibles, navegables y editables, arXiv:2607.13285, 2026.
• AWS, Hacer que las reintentos sean seguros mediante operaciones idempotentes APIs.
• Protocolo de contexto del modelo, Especificación de herramientas.

Serie: Ingeniería de la pila Agentic

• Parte 1: AI Bucles de razonamiento de agente en 2026: ReAct, ReWOO y Plan-and-Execute Parte 2: AI Arquitectura de memoria de agente en 2026: checkpoints, almacenes vectoriales y memoria de documentos Parte 3: AI Agente Tool Use en 2026: MCP, CLI, habilidades, ejecución de código y ACI
• Parte 4: AI Seguridad de agentes en 2026: restricciones, permisos, sandboxes, HITL y delimitación de alcance de MCP Parte 5: Agente AI de ejecución prolongada Runtime en 2026: sesiones, sandboxes, checkpoints, mecanismos de aprovechamiento y formas de despliegue
• Parte 6: Harness Engineering para agentes AI (esta publicación)