Diferencias y métodos de diseño entre «prompt», «contexto», «harness», «agent-based» y «loop engineering»

Si se reduce todo el proceso de mejora de la calidad de la IA generativa a «escribir bien las indicaciones», resulta difícil diagnosticar con precisión las causas del fracaso. Las indicaciones, el contexto, el arnés, la agencia y la ingeniería de bucles no son términos de moda que se puedan sustituir entre sí, sino expresión de la solicitud, selección de información, entorno de ejecución, toma de decisiones autónoma y mejora iterativa, que abordan diferentes aspectos de control.

Definiciones clave de los cinco conceptos

Si unimos estos cinco conceptos en una sola línea, queda así:

Expresar la solicitud → Mostrar la información necesaria → Proporcionar un entorno de trabajo seguro → Dejar que la IA elija la siguiente acción → Verificar y mejorar hasta que el resultado cumpla los criterios.

Aspectos a tener en cuenta al interpretar los términos

Aunque «ingeniería de prompts» y «agente» son términos relativamente comunes, el uso de «ingeniería de harnesses» varía según el contexto. Algunos textos se refieren al «harness» como casi toda la capa de ejecución, excepto el modelo, mientras que otros lo definen de forma más restrictiva como la estructura de reglas, verificación y retroalimentación que los usuarios de agentes de codificación crean fuera del repositorio. En cuanto a la «ingeniería de bucles», es más preciso entenderla como un término práctico que hace referencia al diseño de la generación y la validación como un proceso de retroalimentación cerrado, más que como una clasificación formal establecida por un único estándar. ([OpenAI][1])

1. Ingeniería de prompts: diseñar la calidad de las instrucciones

La ingeniería de prompts es la tarea de hacer que las instrucciones que se transmiten al modelo sean claras y verificables. Aunque suele producir los efectos más notables en una sola solicitud y respuesta, también se aplica a los mensajes del sistema o a las reglas de los diálogos de varios turnos.

Un buen prompt suele separar los siguientes elementos:

• Objetivo: ¿qué hay que completar?
• Entrada: ¿cuál es el objeto de análisis y cuáles son los límites de la entrada?
• Restricciones: lo que no se debe hacer, el margen de tolerancia, la longitud y el formato
• Acuerdo de salida: estructura del resultado (JSON, tabla, parche de código, etc.)
• Criterios de éxito: ¿qué condiciones deben cumplirse para que se considere una respuesta correcta?
• Gestión de la incertidumbre: ¿qué hacer cuando la información es insuficiente o contradictoria?
• Ejemplos: entradas y salidas representativas que muestran el comportamiento esperado

Una plantilla práctica puede comenzar de forma sencilla, como se muestra a continuación.

Objetivo:
Entrada:
Restricciones:
Formato de salida:
Criterios de éxito:
Método de verificación:
Tratamiento en caso de incertidumbre:
Ejemplos representativos:

Es importante definir primero los criterios de éxito y los métodos de prueba empíricos antes de perfeccionar la indicación. No todos los fallos se resuelven modificando la indicación; los costes, los retrasos, los errores de las herramientas o la selección errónea de datos pueden ser problemas de otro nivel. ([Claude Platform Docs][2])

Problemas que la ingeniería de prompts resuelve eficazmente

• Problemas en los que el formato de los resultados se altera con frecuencia
• Problemas en los que la prioridad de las instrucciones es ambigua
• Problemas en los que la entrada y la salida son relativamente claras, como la clasificación, la extracción, la transformación o el resumen
• Problemas en los que el rendimiento se estabiliza al proporcionar ejemplos representativos

Problemas difíciles de resolver solo con el prompt

• Cuando los datos o archivos necesarios no se encuentran en la entrada
• Cuando hay una mezcla de documentos obsoletos o contradictorios
• Cuando es necesario consultar o modificar sistemas externos de forma segura
• Cuando se requieren varios pasos de ejecución y la recuperación ante fallos
• Cuando no hay forma de verificar objetivamente si el resultado es correcto

2. Ingeniería de contexto: diseñar la información que ve la IA

La ingeniería de contexto consiste en seleccionar, ordenar yy actualizar toda la información de la que dispone el modelo en el momento de generar la respuesta. El contexto puede incluir, además de la indicación, las instrucciones del sistema, las solicitudes del usuario, el historial de conversaciones, los documentos de búsqueda, la memoria, las descripciones de las herramientas, los resultados de la ejecución de las herramientas, la hora actual, el estado de los permisos y el estado de progreso de la tarea.

Dado que la ventana de contexto es finita, el objetivo no es «incluir mucha información», sino añadir la información necesaria en el momento oportuno. Anthropic describe el contexto como un recurso importante pero finito del agente y, en interacciones prolongadas, recomienda estrategias como un conjunto mínimo de herramientas, ejemplos representativos, búsquedas en tiempo de ejecución, compresión y memoria. ([Antropológico][3])

Principios clave de diseño

1. Prioridad a la relevancia: solo se incluye la información necesaria para la fase actual.
2. Fuente y actualidad: se gestionan conjuntamente la fecha de creación del documento, la versión, el propietario y la fiabilidad.
3. Búsqueda inmediata: en lugar de introducir todo el material de antemano, se obtiene de archivos, bases de datos o sistemas de búsqueda cuando es necesario.
4. Jerarquización de la información: se distinguen las reglas fijas, las tareas actuales, los materiales de referencia y los resultados de las herramientas.
5. Gestión de conflictos: si hay discrepancias entre varios materiales, se especifican las prioridades y la fuente de referencia.
6. Compresión y conservación del estado: se resumen las conversaciones antiguas, pero no se pierden las decisiones, los problemas pendientes ni los enlaces de referencia.
7. Separación entre instrucciones y datos: se establece una distinción para que las frases de páginas web o documentos no se traten como órdenes del sistema.

Ejemplo

Cuando una IA de atención al cliente responde a una pregunta sobre la política de reembolsos, se llega a un límite si solo se refuerza la indicación de «responder con precisión». Una ingeniería de contexto adecuada permite consultar en el momento oportuno el país del cliente, la fecha de compra, el tipo de producto, la versión actual de la política, las cláusulas de excepción y el estado del pedido, y proporcionar toda esta información junto con la respuesta, además de hacer que las cláusulas de la política utilizadas en la respuesta sean rastreables.

3. Ingeniería de arneses: diseñar el entorno de trabajo de la IA

El arnés es el esqueleto de ejecución que conecta la inteligencia del modelo con el trabajo real. La ingeniería de arneses consiste en diseñar el entorno de trabajo para que la IA pueda prevenir o detectar de forma temprana los errores que comete con frecuencia mediante documentos, herramientas, permisos, estructuras, verificaciones automáticas y retroalimentación.

Componentes principales del «Harness»

El caso práctico de ingeniería de arneses de OpenAI describe el papel del ingeniero no solo como la simple escritura de código, sino como el diseño del entorno, la intención, el conocimiento del repositorio y el ciclo de pruebas, verificación, revisión y recuperación. La clave no está en volver a pedirle a la IA que «se esfuerce más», sino en añadir explícitamente al entorno las capacidades y señales que faltaban. ([OpenAI][1])

Ejemplo de estructura de datos

/ai
  /instructions   # Reglas comunes e instrucciones por rol
  /skills # Procedimientos para tareas repetitivas
  /examples # Resultados buenos y malos
  /evals # Datos de evaluación y reglas de puntuación
  /policies # Políticas de permisos, seguridad y autorización
  /runbooks # Respuesta ante fallos y excepciones

Esta estructura en sí misma no es la única respuesta correcta. Lo importante es que los datos se mantengan actualizados, que haya pocas duplicaciones y conflictos, que la IA pueda encontrarlos cuando los necesite y que las reglas den lugar a comprobaciones automáticas.

4. Ingeniería agentiva: proporcionar objetivos y herramientas, y delegar la siguiente acción

La ingeniería agentiva es un diseño en el que se proporcionan a la IA objetivos, herramientas, el estado de la tarea y las condiciones límite, y se le permite elegir por sí misma, dentro de un rango determinado, el siguiente paso para alcanzar el objetivo.

Anthropic distingue entre flujos de trabajo, que son sistemas que coordinan los LLM y las herramientas mediante rutas de código predefinidas, y agentes, que son sistemas en los que el modelo decide dinámicamente su propio proceso y el uso de las herramientas. OpenAI también describe el agente como un sistema en el que el LLM gestiona la ejecución del flujo de trabajo y selecciona dinámicamente las herramientas para interactuar con sistemas externos. ([Antropológico][4])

Bucle básico del agente

1. Observa el objetivo y el estado actuales.
2. Planifica el siguiente subobjetivo o acción.
3. Selecciona una herramienta y la ejecuta.
4. Comprueba los resultados y los cambios en el entorno.
5. Decide entre completar la tarea, modificarla, volver a intentarla o transferirla a un humano.

Casos en los que el agente es adecuado

• Cuando el orden de las tareas varía en función de cada entrada
• Cuando es necesario interpretar información no estructurada, como lenguaje natural, documentos o código
• Cuando es necesario utilizar varias herramientas de forma selectiva
• Cuando es necesario modificar el plan tras observar los resultados intermedios
• Cuando las causas de los fallos son diversas y es posible una recuperación hasta cierto punto

Cuándo el agente resulta excesivo

• Automatización simple con reglas y secuencias fijas
• Tareas que se resuelven de forma segura con una única llamada a la API o mediante SQL
• Tareas para las que no existen medios de verificación y en las que el coste de los errores es muy elevado
• Estructuras en las que se realizan acciones difíciles de revertir —como pagos, eliminaciones o implementaciones— sin autorización
• Estructuras con múltiples agentes en las que basta con un único agente, pero se han multiplicado las funciones

La autonomía no es una cuestión dicotómica. Se puede dividir en: el tipo auxiliar, que solo ofrece recomendaciones; el tipo ejecutivo, que solo permite lecturas y escrituras limitadas; el tipo supervisado, que requiere autorización en cada paso clave; y el tipo de alta autonomía, que opera durante largos periodos de tiempo en un ámbito de bajo riesgo. Debe ampliarse de forma gradual, en función del riesgo de la tarea y de la capacidad de verificación.

5. Ingeniería de bucles: diseñar un proceso de mejora verificable

La ingeniería de bucles no consiste simplemente en volver a intentarlo. Se trata de convertir el proceso generación → verificación → análisis de las causas del fallo → selección de la estrategia de corrección → reejecución → decisión de finalización en un sistema de retroalimentación cerrado y explícito.

Estructura de un bucle adecuado

1. Generación de candidatos: se elaboran borradores, código, planes y resultados de la transformación de datos.
2. Verificación: se ejecutan pruebas, esquemas, datos de referencia, políticas y comprobaciones de fundamentos.
3. Clasificación de causas: se distinguen los errores de instrucciones, la falta de contexto, los fallos de herramientas, los defectos de implementación y los defectos del evaluador.
4. Corrección: se aplican los cambios mínimos adecuados a la causa del fallo.
5. Reejecución: No se repite todo desde el principio, sino que se reanudan los pasos necesarios.
6. Finalización: Se detiene al alcanzar uno de los siguientes criterios: superación de la prueba, número máximo de repeticiones, límite de costes, límite de tiempo o umbral de incertidumbre.
7. Protección contra regresiones: se comprueba que la nueva corrección no haya afectado a los casos de éxito anteriores.

La evaluación de un agente es más compleja que una evaluación de un solo turno, en la que solo se tienen en cuenta la entrada y la salida. Dado que el agente invoca la herramienta varias veces y modifica el estado del entorno, es necesario examinar no solo el resultado final, sino también el proceso y los cambios en el entorno. La clave de la evaluación automática consiste en proporcionar una entrada y aplicar la lógica de puntuación a la salida o al estado modificado. ([antropológico][5])

Prioridades del verificador

• Verificación determinista: compilación, pruebas unitarias, esquemas, restricciones matemáticas, comprobación de permisos
• Verificación basada en referencias: datos de referencia, citas del texto original, cotejo con bases de datos
• Verificación basada en reglas: palabras prohibidas, campos obligatorios, condiciones de las políticas
• Evaluación basada en modelos: aspectos difíciles de regularizar, como el estilo, la conservación del significado y la calidad general
• Evaluación humana: juicios de alto riesgo, validez del objetivo en sí mismo, aprobación de excepciones

Siempre que sea posible, se debe utilizar primero la verificación determinista y no dejar que el modelo se autoevalúe basándose únicamente en su propia evaluación. Cuando se utilice la evaluación del modelo, se deben incluir criterios de evaluación, ejemplos, comprobación de sesgos y revisión humana de muestras.

Los cinco métodos forman una jerarquía, no son alternativas entre sí

En los sistemas reales, los cinco métodos funcionan conjuntamente.

• La indicación establece el acuerdo sobre la acción actual.
• El contexto proporciona el estado y los fundamentos necesarios para la toma de decisiones.
• El arnés proporciona un entorno en el que se puede actuar y mecanismos de seguridad.
• El diseño agencial distribuye la capacidad de elegir la siguiente acción.
• El diseño de bucles detecta errores y garantiza la convergencia de la calidad.

Por lo tanto, es inexacto entender que «la ingeniería de contexto ha sustituido a la ingeniería de prompts» o que «si se utiliza un agente, no se necesita un flujo de trabajo». Simplemente, el nivel más amplio incluye o aprovecha al nivel más específico, y en problemas sencillos, un diseño sencillo puede resultar más estable.

Ejemplo práctico: un sistema de codificación con IA que corrige errores

Supongamos que una IA corrige un error del tipo «solo determinados usuarios reciben un error 500 tras iniciar sesión».

Ingeniería de prompts

• Verifica las condiciones para reproducir el error.
• No modifiques la API pública.
• Resuélvelo con el mínimo cambio posible.
• Informa de los resultados de las pruebas tras la corrección y de los riesgos restantes.

Ingeniería de contexto

• Descripción del problema y registro de errores
• ID de seguimiento de la solicitud correspondiente
• Archivos relacionados con la autenticación y el modelo de usuario
• Historial de cambios recientes
• Reglas de arquitectura y estándares de codificación
• Pruebas fallidas e información del entorno de ejecución

Ingeniería de harnesses

• Herramientas para buscar en el repositorio, leer y editar archivos, y ejecutar pruebas
• Ramas aisladas y entornos de pruebas (sandbox)
• Formateadores, linters, pruebas unitarias y de integración
• Áreas de cambio prohibido y políticas de permisos
• Registro de todos los comandos y cambios en los archivos
• Reversión y puntos de control en caso de fallo

Ingeniería de agentes

La IA selecciona, según la situación, el orden de los pasos: reproducción, formulación de hipótesis, búsqueda del código relevante, aplicación de parches, pruebas y resumen de resultados. No obstante, las implementaciones o los cambios en los datos requieren la aprobación humana.

Ingeniería de bucles

Si una prueba falla, en lugar de repetir el mismo comando, se clasifica el tipo de fallo. Si se trata de un fallo de reproducción, se complementa la recopilación de contexto; si es un fallo de regresión, se aplica un parche; y si es un error de entorno, se restauran las dependencias y la configuración. Se da por finalizado el proceso cuando se superan todas las pruebas obligatorias y quedan justificados los cambios.

Cómo determinar qué tipo de ingeniería se necesita en función de los síntomas del problema

Orden de implementación recomendado

Etapa 1: Crear primero los criterios de éxito y el conjunto de evaluación

Recopilar tareas representativas, casos difíciles y casos prohibidos, y definir cómo se evaluarán los resultados. Si no se dispone de datos de respuestas correctas, crear al menos un esquema, los fundamentos esenciales, el cumplimiento de las políticas y los criterios de evaluación humana.

Etapa 2: Establecer una línea de referencia para una sola llamada

Medir el rendimiento, el coste y el tiempo de latencia con el prompt más sencillo y el contexto mínimo necesario. Si se implementa el agente sin una línea de referencia, resulta difícil distinguir el efecto de la complejidad.

Etapa 3: Medir el suministro de contexto

Se registra qué documentos y resultados de herramientas se han incluido, cuánto tiempo hace que se recopilaron y si se han utilizado en la respuesta real. Se distingue entre fallos de búsqueda y exceso de contexto.

Paso 4: Crear un entorno de prueba mínimo

Reducir el número de herramientas y definir claramente sus nombres y entradas. Dar prioridad al entorno de pruebas (sandbox), a los privilegios mínimos, a las pruebas automáticas, a los registros y a los puntos de control.

Etapa 5: Conceder autonomía limitada

Hacer que un único agente realice tareas de bajo riesgo centradas en la lectura. Especificar las condiciones de finalización y de transferencia a un humano, y aprobar por separado los permisos de escritura, eliminación, pago y distribución.

Etapa 6: Cerrar el ciclo de verificación y recuperación

Vincular la clasificación de fallos, la estrategia de corrección, el número máximo de repeticiones, el límite de costes y las pruebas de regresión. Solo ampliar las herramientas y el alcance de la autonomía una vez que la tasa de éxito se haya estabilizado.

Indicadores operativos

Dado que no existen valores objetivo universales, los criterios deben establecerse en función del riesgo y el coste de las tareas.

Errores de diseño frecuentes

Lista de comprobación de la implementación

• ¿Son las condiciones de éxito verificables mecánicamente, no solo mediante frases, sino en la medida de lo posible?
• ¿Están separadas las prioridades de las indicaciones, los materiales de referencia y los resultados de las herramientas?
• ¿Se puede rastrear la fuente, la versión, la fecha de validez y el propietario de los documentos?
• ¿Son claros y no se solapan los nombres de las herramientas y sus parámetros?
• ¿Están separados los permisos de lectura, escritura, eliminación, pago y distribución según su nivel de riesgo?
• ¿Existe un entorno de pruebas (sandbox) para aislar los fallos y medios para revertirlos?
• ¿Se registran todas las acciones importantes y las llamadas a herramientas de forma reproducible?
• ¿Existen verificadores externos, como pruebas, esquemas o comprobaciones de políticas?
• ¿Están definidos el número máximo de iteraciones, el coste, el tiempo y las condiciones de traspaso a personal humano?
• ¿Existe una evaluación de regresión que garantice que las nuevas mejoras no rompan los casos existentes?

Conclusión

Un buen sistema de IA no es aquel que tiene las indicaciones más largas. Es aquel que distingue en qué de los siguientes aspectos se ha producido el fallo: instrucciones, información, entorno, toma de decisiones o verificación y recuperación, y que aplica la solución más sencilla en el nivel correspondiente. Un enfoque estable consiste en establecer primero los criterios de éxito y una línea de referencia para cada llamada individual, reforzar el contexto y el entorno de pruebas solo en la medida necesaria y, a continuación, ampliar la autonomía y los bucles de iteración dentro de un ámbito verificable.