Diferencias y métodos de diseño entre «prompt», «contexto», «harness», «agent-based» y «loop engineering» ========================================================================================================= La ingeniería de prompts, contexto, harnesses, agentic y bucles aborda, respectivamente, las instrucciones, la información, el entorno de trabajo, la ejecución autónoma y la mejora iterativa. Este artículo explica, desde un punto de vista práctico, los límites de estos cinco métodos, su estructura de combinación, el orden de aplicación, los indicadores de verificación y las medidas para evitar fallos. - La ingeniería de prompts consiste en definir con claridad los objetivos, las restricciones, los ejemplos, el acuerdo sobre los resultados y los criterios de éxito. - La ingeniería de contexto gestiona la relevancia, la actualidad y la procedencia de la información que la IA utiliza para tomar sus decisiones, así como la eficiencia de los tokens. - Harness Engineering crea un entorno en el que la IA puede funcionar de forma estable mediante herramientas, permisos, entornos de prueba, estructuras de documentación, verificadores y registros. - La ingeniería agentiva delega de forma limitada en la IA la elección de las acciones y herramientas necesarias para alcanzar los objetivos. - La ingeniería de bucles vincula la generación, la verificación, el análisis de causas, la corrección, la reejecución y las condiciones de finalización para hacer que los resultados converjan. 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 Categoría Pregunta clave Objeto principal de diseño Resultados típicos Criterios típicos de éxito Ingeniería de prompts ¿Cómo dar instrucciones a la IA? Instrucciones, restricciones, ejemplos, formato de salida Plantillas de prompts, ejemplos de entrada y salida Índice de cumplimiento de las instrucciones, precisión del formato, calidad de los resultados iniciales Ingeniería de contexto ¿Qué se le va a mostrar a la IA en este momento? Directrices del sistema, documentos de búsqueda, estado de la conversación, memoria, resultados de herramientas Reglas de ensamblaje de contexto, políticas de búsqueda y resumen Relevancia, actualidad, fundamentación, eficiencia de tokens Ingeniería de harness ¿Qué entorno de trabajo crearemos para que a la IA le resulte difícil cometer errores? Herramientas, permisos, entorno de pruebas, estructura de almacenamiento, verificadores, registros Reglas de trabajo, interfaces de herramientas, pruebas e integración continua (CI), manual de operaciones Reproducibilidad, seguridad, verificabilidad, recuperabilidad Ingeniería de agentes ¿Quién decidirá la siguiente acción y en qué ámbito? Objetivos, planificación, selección de herramientas, transición de estados, delegación Bucle del agente, orquestación, puntos de aprobación Índice de finalización de tareas, selección adecuada de herramientas, índice de intervención humana Ingeniería de bucles ¿Cómo se logrará la convergencia cuando el primer resultado sea erróneo? Generación, evaluación, clasificación de causas, corrección, reejecución, condiciones de finalización Evaluador, pruebas de regresión, política de reintentos, clasificación de fallos Tasa de aprobación en el primer intento, tasa de recuperación, número de repeticiones, tasa de aprobación final 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 Prioridad a la relevancia: solo se incluye la información necesaria para la fase actual. Fuente y actualidad: se gestionan conjuntamente la fecha de creación del documento, la versión, el propietario y la fiabilidad. 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. Jerarquización de la información: se distinguen las reglas fijas, las tareas actuales, los materiales de referencia y los resultados de las herramientas. Gestión de conflictos: si hay discrepancias entre varios materiales, se especifican las prioridades y la fuente de referencia. 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. 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» Componente Función Ejemplo Instrucciones de trabajo Especifican los procedimientos y las prohibiciones de las tareas repetitivas AGENTS.md, manual de operaciones, lista de comprobación Estructura de conocimientos Facilita a la IA la búsqueda de la información necesaria Mapa del repositorio, ADR, glosario, recopilación de ejemplos Interfaz de herramientas Limita claramente las entradas y salidas de las acciones Búsqueda de archivos, consulta de bases de datos, ejecución de código, API de despliegue Entorno de ejecución Aísla los fallos y aumenta la reproducibilidad Sandbox, contenedores, dependencias fijas Verificador Comprueba automáticamente si los resultados cumplen los criterios Verificación de esquemas, pruebas unitarias, linter, verificación de políticas Permisos y autorizaciones Limitar las acciones peligrosas Privilegios mínimos, separación de lectura y escritura, autorización humana Observabilidad Registrar qué se ha visto y qué acciones se han realizado Rastros, registros, historial de llamadas a herramientas, costes Estructura de recuperación Retroceder y reanudar de forma segura tras un fallo Puntos de control, reversión, presupuesto de reintentos 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 Observa el objetivo y el estado actuales. Planifica el siguiente subobjetivo o acción. Selecciona una herramienta y la ejecuta. Comprueba los resultados y los cambios en el entorno. 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 Generación de candidatos: se elaboran borradores, código, planes y resultados de la transformación de datos. Verificación: se ejecutan pruebas, esquemas, datos de referencia, políticas y comprobaciones de fundamentos. 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. Corrección: se aplican los cambios mínimos adecuados a la causa del fallo. Reejecución: No se repite todo desde el principio, sino que se reanudan los pasos necesarios. 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. 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 Síntoma Área que hay que comprobar en primer lugar El formato o el estilo de la salida suelen ser incorrectos Prompt Faltan datos o archivos necesarios para la respuesta Contexto Se elige una herramienta incorrecta o se ejecutan comandos peligrosos Diseño del harness y de los permisos Hay muchas variaciones difíciles de procesar con un orden fijo Diseño agéntico El primer resultado suele ser incorrecto, pero es posible la evaluación automática Bucles y evaluador Se desconoce la causa del fallo y es difícil reproducirlo Observabilidad del arnés Cuanto más se repite, más aumenta el coste y no mejora la calidad Clasificación de causas, señales de verificación, condiciones de finalización Cuanta más información hay, peor es la respuesta Organización del contexto y política de búsqueda 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. Indicador Significado Tasa de finalización de tareas Porcentaje que cumple los criterios finales de éxito Tasa de aprobación a la primera Porcentaje que supera la prueba desde el principio sin necesidad de correcciones repetidas Tasa de recuperación Porcentaje que logra el éxito tras el primer fallo mediante el ciclo de verificación y recuperación Número medio de repeticiones Número de ciclos necesarios hasta el éxito o la interrupción Tasa de errores en la selección de herramientas Porcentaje de llamadas a herramientas inadecuadas o innecesarias Exhaustividad de las fuentes Porcentaje de afirmaciones clave que cuentan con fuentes trazables Tasa de intervención humana Porcentaje de casos en los que se requirió aprobación, corrección o reorientación Coste y retraso por tarea completada Recursos empleados para completar una tarea con éxito Número de incidentes de seguridad Número de casos de violación de permisos, escrituras erróneas o acciones irreversibles Tasa de fallos de regresión Porcentaje de casos en los que un nuevo cambio ha invalidado casos de éxito previos Errores de diseño frecuentes Área Error Cómo mejorar Indicaciones Acumular todas las excepciones en una sola frase Estructurar las reglas y separar los ejemplos representativos de la evaluación Indicaciones Indicar «redactar bien» sin criterios de éxito Especificar el formato, el contenido obligatorio, las prohibiciones y los criterios de evaluación Contexto Incluir todos los documentos no relevantes Utilizar la búsqueda en tiempo de ejecución y el contexto por etapas Contexto Proporcionar políticas antiguas y actuales juntas Gestionar las versiones, las fechas de validez y las fuentes de referencia Arnés Se proporcionan muchas herramientas con funciones que se solapan Diseñar un conjunto mínimo de herramientas con parámetros claros Arnés No hay permisos de escritura ni función de reversión Establecer permisos mínimos, un entorno aislado y puntos de control Agente Crea múltiples agentes desde el principio Se verifica a partir de un único agente y un flujo de trabajo determinista Agente Permite que se ejecute continuamente sin condiciones de finalización Establece condiciones explícitas de finalización, presupuesto y transferencia Bucle Repite la misma solicitud tal cual Clasifica las causas de los fallos y cambia los puntos de corrección Bucle Autoevalúa todos los resultados con un único modelo generativo Combina comprobaciones deterministas, comparaciones con referencias y revisión de muestras humanas 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. FAQ Q. ¿Es obligatorio aplicar los cinco métodos de ingeniería en este orden? A. No se trata de una etapa de madurez fija. Sin embargo, una vez establecidos los criterios de éxito y una línea de referencia única para las llamadas, y tras organizar las indicaciones y el contexto, resulta fácil medir el efecto de la complejidad añadiendo, cuando sea necesario, un arnés, autonomía y un bucle de repetición. Q. ¿La ingeniería de contexto sustituye a la ingeniería de prompts? A. No se sustituyen. La indicación define la acción que hay que realizar y el acuerdo sobre el resultado, mientras que el contexto proporciona los hechos, el estado y los fundamentos necesarios para dicha acción. Un buen sistema diseña ambos elementos conjuntamente. Q. ¿Cuál es la diferencia entre la ingeniería de contexto y la ingeniería de arneses? A. La ingeniería de contexto se centra en la información que ve el modelo en un momento determinado. La ingeniería de harness incluye las herramientas, los permisos, el entorno de ejecución, la estructura de la documentación, los registros y los mecanismos de recuperación necesarios para buscar esa información, llevar a cabo acciones y comprobar los resultados. Q. ¿En qué se diferencia la automatización de agentes de la automatización de flujos de trabajo generales? A. Mientras que los flujos de trabajo generales siguen una secuencia y unas ramificaciones predefinidas, los agentes interpretan el estado actual para seleccionar de forma dinámica la siguiente acción y las herramientas que deben utilizar. En las tareas con reglas estables, los flujos de trabajo deterministas pueden resultar más económicos y predecibles. Q. ¿En qué se diferencia la ingeniería de bucles de un simple reintento? A. Un simple reintento solo consiste en volver a generar el resultado en las mismas condiciones. La ingeniería de bucles consiste en detectar el fallo mediante una señal de verificación externa, clasificar la causa y, a continuación, modificar los elementos necesarios —ya sea la indicación, el contexto, las herramientas o la implementación— y aplicar condiciones de finalización y pruebas de regresión. Q. ¿Cuándo se debe utilizar el modelo de agentes múltiples? A. Se tiene en cuenta cuando las herramientas y los permisos varían claramente según el rol, y cuando el contexto o el conjunto de herramientas de un agente se vuelve excesivamente amplio, lo que perjudica el rendimiento y la evaluación. Si se crean varios agentes con el único fin de repartir funciones, pueden aumentar los costes, los retrasos, la propagación de errores y la dificultad para depurar el código. Q. ¿Se puede dejar que la IA evalúe sus propios resultados? A. Aunque puede utilizarse como señal auxiliar, resulta arriesgado considerarlo como único verificador. Siempre que sea posible, se deben aplicar primero las pruebas, los esquemas, los datos de referencia y las reglas de política, y la evaluación del modelo debe complementarse con una rúbrica explícita y una revisión humana de las muestras. Q. ¿Qué hay que incluir en la documentación del arnés? A. Se incluirán los procedimientos de trabajo recurrentes, la estructura del repositorio y del sistema, las acciones permitidas y prohibidas, el uso de las herramientas, ejemplos positivos y negativos, los comandos de prueba, la gestión de incidencias, las políticas de aprobación y los criterios de finalización. La documentación debe ser breve, fácil de consultar y estar sujeta a control de versiones. Q. ¿Cuál es el principio de seguridad más importante a la hora de incorporar documentos externos al contexto? A. Los documentos externos deben tratarse como datos no fiables y mantenerse separados de las instrucciones del sistema. Se deben minimizar los permisos de las herramientas para evitar que se ejecuten las órdenes contenidas en dichos documentos, y se deben establecer comprobaciones de políticas independientes y la aprobación humana para las acciones críticas de escritura, eliminación, pago y distribución. Q. ¿Por dónde es mejor empezar en un equipo pequeño? A. Se recopilan un pequeño conjunto de evaluaciones representativas y casos de fracaso para medir la línea de referencia de una única llamada al modelo. A continuación, resulta más eficaz identificar cuál de los siguientes factores es la principal causa del fracaso —las instrucciones, la información, el entorno de herramientas, la planificación o la verificación— y realizar mejoras nivel por nivel. Sources - Introducción a la ingeniería de prompts - Documentación de la plataforma Claude: https://platform.claude.com/docs/ko/build-with-claude/prompt-engineering/overview - Ingeniería de contexto eficaz para agentes de IA: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - Ingeniería de arneses: cómo sacar partido a Codex en un mundo centrado en los agentes: https://openai.com/index/harness-engineering/ - Creación de agentes eficaces: https://www.anthropic.com/engineering/building-effective-agents - Guía práctica para la creación de agentes: https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ - Desmitificando las evaluaciones de los agentes de IA: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents - Ingeniería de arneses para usuarios de agentes de codificación: https://martinfowler.com/articles/harness-engineering.html Images - Núcleo central de IA conectado con módulos de instrucciones, contexto, herramientas, acción autónoma y validación: https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg0NywicHVyIjoiYmxvYl9pZCJ9fQ==--9f1b84d1d297642915a0d27477d3800017987668/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_12_32.webp - Flujo de creación de IA con instrucciones, filtrado de contexto, entorno seguro, acción autónoma y validación iterativa: https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg1NCwicHVyIjoiYmxvYl9pZCJ9fQ==--47acd549387f7a60f4c18de6ac673ca1b551dd36/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2004_36_26.webp --- Category: Comparativa Source: https://injoys.com/es/articles/prompt-context-harness-agentic-loop-engineering License: cc_by Translation-Status: reviewed