Comprender en orden la ingeniería de arneses, bucles y grafos de agentes de IA

A medida que los agentes de IA empiezan a asumir tareas de larga duración, resulta difícil obtener resultados estables solo con buenos prompts. Esto se debe a que también hay que diseñar qué información consulta el agente, qué herramientas utiliza, cuándo repite una acción, qué ruta sigue y en qué puntos debe obtener la aprobación de una persona.

Para explicar este problema suelen aparecer los términos ingeniería de arnés, ingeniería de bucles e ingeniería de grafos. No son estándares internacionales ni categorías académicas estrictamente consensuadas. Se solapan entre sí y su significado puede variar según el producto y el equipo de desarrollo. Por tanto, en lugar de memorizarlos como términos de moda de cada año, resulta más útil distinguirlos por la pregunta de control a la que intenta responder cada uno.

Comparación de los tres conceptos de un vistazo

En pocas palabras, el arnés define el entorno y los límites, el bucle define las reglas de repetición y el grafo define la estructura de las rutas posibles. En un sistema real, puede haber un bucle dentro de un nodo del grafo y todo el grafo puede ejecutarse dentro de un mismo arnés.

Cómo han evolucionado los métodos de control de agentes

Agentes iniciales: los flujos de trabajo predefinidos complementaban la autonomía

Los primeros agentes de IA generativa solían olvidar sus objetivos durante las tareas largas, repetir llamadas incorrectas a herramientas o generar resultados sin fundamento. Como respuesta, los desarrolladores dividieron las tareas grandes en pasos pequeños y fijaron las entradas y salidas de cada paso.

Con este método, una persona redacta todo el procedimiento en forma de cadena, diagrama de flujo o máquina de estados, mientras que el LLM se encarga de tareas limitadas como la clasificación, la extracción, el resumen o la redacción de borradores. Los frameworks como LangGraph se utilizan para representar bifurcaciones, ciclos, checkpoints e intervención humana manteniendo el estado.

Sin embargo, la orquestación basada en grafos no es un método obsoleto que terminara en un año concreto. Los grafos explícitos siguen siendo adecuados para tareas en las que son importantes la capacidad de auditoría, la reproducibilidad, el cumplimiento normativo o unos procedimientos de recuperación precisos.

Mejora del rendimiento de los modelos: de rutas fijas al uso dinámico de herramientas

A medida que mejoraron el uso de herramientas y la capacidad de razonamiento, un solo agente pudo seleccionar acciones como buscar, editar código, ejecutar pruebas y leer archivos según la situación. Los enfoques de la familia ReAct constituyen una estructura representativa que alterna razonamiento, acción y observación.

Este cambio redujo la carga de tener que definir por adelantado todas las bifurcaciones. Por otro lado, adquirió mayor importancia gestionar la información que lee el agente, los permisos que posee, el coste de ejecución y el método de recuperación ante errores. En este contexto, la ingeniería de contexto y la ingeniería de arnés pasan al centro del trabajo práctico.

Tareas largas y múltiples agentes: recombinación de bucles y grafos

En las tareas largas, la planificación, ejecución y verificación repetitivas son más importantes que una sola llamada al modelo. Cuando participan varios agentes, también hay que especificar los roles, el formato de los entregables, los permisos y las condiciones de finalización. Al mismo tiempo, dejar los bucles autónomos completamente desatendidos puede provocar una explosión de costes, reintentos infinitos, manipulación de recompensas y optimización de objetivos incorrectos.

Por eso, los sistemas de agentes modernos se diseñan para combinar los tramos en los que se permite la autonomía con aquellos que se controlan de forma determinista, en lugar de eliminar la autonomía. No se trata de un simple regreso a las cadenas fijas del pasado, sino de rodear una ejecución flexible con estados, transiciones y políticas.

Este cambio es más una modificación del énfasis del diseño que una cronología exacta. Los grafos, los bucles y los arneses han coexistido desde el principio y siguen utilizándose conjuntamente.

Qué aborda la ingeniería de arnés

El arnés no es el propio modelo base, sino el sistema de ejecución que rodea al modelo para que realice tareas reales. Incluso utilizando el mismo modelo, la tasa de éxito, el coste, la seguridad y la reproducibilidad pueden variar considerablemente en función del arnés.

Principales componentes de un arnés

1. Sistema de instrucciones: instrucciones del sistema, reglas del repositorio, estándares de codificación, prioridades y acciones prohibidas
2. Suministro de contexto: búsqueda, selección de archivos, resúmenes, memoria e incorporación de documentos en el momento necesario
3. Interfaz de herramientas: edición de archivos, terminal, navegador, base de datos y API externas
4. Permisos y aislamiento: alcance de lectura y escritura, acceso a información secreta, restricciones de red y sandbox
5. Mecanismos de verificación: pruebas, linter, comprobación de tipos, validación de esquemas y verificación de hechos
6. Aprobación humana: aprobación de acciones difíciles de revertir, como despliegues, pagos, eliminaciones y transmisiones externas
7. Observabilidad: historial de llamadas, costes, latencia, errores, historial de cambios y fundamento de las decisiones
8. Política de recuperación: reintentos, restauración del estado anterior, interrupción de tareas y derivación a una persona responsable

Los archivos de instrucciones de proyecto o los hooks de Claude Code pueden considerarse ejemplos de componentes de un arnés. Sin embargo, una sola función de un producto concreto no representa todo el arnés.

Diferencia respecto a la ingeniería de contexto

La ingeniería de contexto optimiza qué información e instrucciones se introducen en la llamada actual al modelo. Incluye recuperar mediante búsquedas solo los documentos relevantes, resumir conversaciones antiguas, guardar el estado de la tarea en archivos externos y separar el contexto de cada subtarea.

La ingeniería de arnés tiene un alcance más amplio. Además del contexto, abarca los permisos de las herramientas, el entorno de ejecución, las aprobaciones, la verificación, el registro y los límites de coste. Por tanto, la ingeniería de contexto es una parte esencial del arnés, pero no es preciso utilizar ambos términos como si significaran exactamente lo mismo.

La clave de la ingeniería de bucles son las condiciones de finalización

Un bucle hace que el agente compruebe el resultado después de generarlo y vuelva a intentarlo si es insuficiente. Lo importante no es la repetición en sí, sino la definición del progreso y las condiciones de interrupción.

Tipos representativos de bucles

• Bucle de verificación: después de crear un borrador, lo comprueba mediante pruebas o criterios de evaluación y corrige los elementos que hayan fallado.
• Bucle basado en eventos: inicia una tarea cuando se produce un evento externo, como un correo electrónico, una notificación, un cambio de código o datos de sensores.
• Bucle de exploración: investiga varias hipótesis o fuentes y ajusta el alcance de la exploración hasta reunir pruebas suficientes.
• Bucle de mejora: selecciona la siguiente estrategia a partir de resultados y evaluaciones anteriores. Optimizar una única puntuación puede provocar manipulación de recompensas, por lo que se necesitan varios criterios de evaluación y revisión humana.
• Bucle de recuperación: clasifica la causa del error, reintenta dentro del alcance permitido y, si no logra resolverlo, lo deriva a una persona.

Contratos necesarios para un bucle seguro

Un contrato entre agentes no es un contrato legal, sino una especificación de ejecución que define las entradas, las salidas y las responsabilidades. Conviene incluir los siguientes elementos.

Si las condiciones de finalización son ambiguas, el agente puede considerar que la tarea está progresando aunque solo esté modificando frases o repitiendo la misma búsqueda. En lugar de establecer únicamente un número máximo de iteraciones, es mejor considerar conjuntamente la calidad del resultado, el aumento de información nueva, la evolución de los errores y el coste.

La ingeniería de grafos estructura los límites de la autonomía

Un grafo representa una tarea mediante nodos y conexiones. Un nodo puede corresponder a una llamada al modelo, la ejecución de una herramienta, una aprobación humana o un proceso de verificación, mientras que las conexiones indican la siguiente acción en función del estado.

Diferencia entre cadenas y grafos

• Una cadena es adecuada para procedimientos lineales que van de A a B y de B a C.
• Un grafo es adecuado para tareas que requieren bifurcaciones condicionales, repeticiones, ejecución paralela, recuperación ante fallos y guardado intermedio.
• Un grafo dinámico permite que el modelo proponga la siguiente subtarea o ruta durante la ejecución.
• Un grafo restringido hace que, aunque el modelo elija, solo pueda moverse entre los nodos y las transiciones permitidos.

El propósito del diseño moderno de grafos no consiste en que una persona decida de antemano todas las acciones. Consiste en incorporar a la estructura condiciones invariantes que deben respetarse, como obligar a pasar por un nodo de aprobación antes de eliminar datos o impedir la transición al estado de despliegue cuando las pruebas se encuentran en estado fallido.

Indicadores de que se necesita un grafo

Si se cumplen varias de las siguientes condiciones, merece la pena considerar un grafo explícito.

• Existe un punto claro de recuperación al que volver después de un fallo.
• Hay una etapa que requiere obligatoriamente la aprobación de una persona.
• Hay que ejecutar varias tareas en paralelo y después combinar los resultados.
• Las herramientas o los permisos disponibles varían según el estado.
• Es necesario auditar o reproducir toda la ruta de ejecución.
• Un bucle de un solo agente repite el mismo fallo.

Crear un grafo incluso para resumir un documento sencillo o realizar una única transformación de datos puede limitarse a aumentar la complejidad.

Orden de aplicación práctica: empezar por el arnés y ampliar según sea necesario

Para la mayoría de los equipos, el siguiente orden es realista.

1. Definir una sola tarea y sus criterios de éxito. Primero se recopilan las entradas, los resultados esperados y los casos de fallo.
2. Crear un arnés mínimo. Se proporcionan únicamente el contexto y las herramientas necesarios, y se establecen permisos, pruebas, registros y límites de coste.
3. Construir un conjunto de evaluación. Además de casos normales, debe incluir solicitudes ambiguas, documentos incorrectos, errores de herramientas e intentos de exceder los permisos.
4. Convertir en bucles los puntos que necesitan repetición. Solo se permiten reintentos en los tramos donde la verificación y la corrección mejoran realmente la calidad.
5. Elevarlo a grafo cuando las bifurcaciones y la recuperación sean complejas. Se especifican los estados y las transiciones, y se colocan nodos de aprobación antes de las acciones peligrosas.
6. Utilizar múltiples agentes solo cuando la división del trabajo resulte beneficiosa. Si no son necesarios la exploración paralela o diferentes roles especializados, un solo agente puede ser más sencillo y económico.

Diferencias de aplicación en codificación e investigación

No puede afirmarse que los flujos de trabajo dinámicos sean siempre ineficientes para la codificación y siempre ventajosos para la investigación. Una migración a gran escala que pueda probarse puede ser adecuada para un agente autónomo, mientras que un procedimiento fijo de investigación puede ser más eficiente para consultar un hecho cuya respuesta está clara. Las variables clave, más que el ámbito, son la claridad del objetivo, la posibilidad de verificación automática, el espacio de exploración y el coste de los errores.

La revisión de código no desaparece: cambia la unidad de revisión

Cuando un agente escribe código, el desarrollador pasa a desempeñar en mayor medida la función de supervisar los requisitos, el diseño, los resultados de las pruebas, el alcance de los cambios y los riesgos, en lugar de introducir directamente cada línea. Los resúmenes de Pull Request y los informes de los agentes pueden acelerar la revisión.

Sin embargo, leer únicamente el resumen y aprobar no constituye una opción predeterminada segura. Los cambios que el agente haya omitido o la lógica que haya entendido incorrectamente pueden no aparecer tampoco en el resumen. En las siguientes situaciones, es necesario revisar directamente el diff original y el código relacionado.

• Cambios en autenticación, pagos, datos personales, cifrado o control de acceso
• Cambios en el esquema de la base de datos o migraciones irreversibles
• Código sensible al rendimiento y la concurrencia
• Refactorizaciones a gran escala fuera del alcance de las pruebas
• Cambios en dependencias externas, configuración de despliegue o tratamiento de información secreta
• Casos en los que la explicación del agente no coincide con el diff real

Human-in-the-loop no significa que una persona pulse un botón como mera formalidad. También implica proporcionar pruebas de los cambios, resultados de las pruebas, posibles fallos y procedimientos de reversión para que la persona pueda tomar una decisión.

Errores frecuentes

Múltiples agentes sin propósito

Aumentar el número de agentes genera costes de coordinación de roles, llamadas duplicadas, transferencia de contexto y combinación de resultados. Si no existe la necesidad de explorar en paralelo desde distintas perspectivas o de separar el contexto, es mejor utilizar un solo agente.

Flujos de trabajo dinámicos sin límites

Si se permite que un agente siga creando subtareas, el coste de los tokens y las llamadas a herramientas aumenta rápidamente. El coste está determinado aproximadamente por la suma del coste de los tokens de entrada y salida de cada etapa, el coste de las herramientas, el número de agentes paralelos y la cantidad de iteraciones. El número de llamadas, la cantidad de ejecuciones simultáneas, el presupuesto total y el tiempo máximo de ejecución deben limitarse por separado.

Optimizar un solo indicador de evaluación

Si el único objetivo es la tasa de superación de las pruebas, puede producirse una optimización incorrecta, como debilitar las pruebas u ocultar el tratamiento de excepciones. Es necesario utilizar conjuntamente la calidad, la seguridad, el alcance de los cambios, el coste, la latencia y la evaluación humana.

Confundir la incorporación de documentos con el fine-tuning

Los resultados pueden cambiar de forma persistente mediante la búsqueda de documentos o las instrucciones del proyecto, pero eso no significa que cambien los pesos del modelo. En un sentido amplio, puede describirse como un efecto de aprendizaje del sistema, pero, estrictamente hablando, es una adaptación mediante memoria externa y contexto. Hay que conservar los documentos o el índice de búsqueda para que los cambios se mantengan también en la siguiente ejecución.

Evaluación, seguridad y economía que suelen pasarse por alto durante la operación

El diseño de agentes no termina con un diagrama de arquitectura. En la operación real es importante contar con un sistema que mida lo que realmente ocurrió, más que aquello que se permitió.

Indicadores operativos mínimos

• Tasa de éxito de las tareas y tasa de correcciones humanas
• Coste de modelos y herramientas por tarea y tiempo total de ejecución
• Número de iteraciones y proporción de llamadas consumidas sin progreso
• Número de solicitudes de aprobación, rechazos e intentos de exceder los permisos
• Llamadas incorrectas a herramientas y tasa de éxito de la recuperación
• Proporción de resultados entregados sin fuentes ni pruebas
• Grado de variación de los resultados ante una misma entrada

Condiciones invariantes necesarias para la seguridad

• Las instrucciones de documentos externos no tienen mayor prioridad que las políticas del sistema.
• La información secreta no se expone innecesariamente en las entradas del modelo ni en los registros.
• Los permisos de lectura se separan de los permisos de escritura, eliminación y despliegue.
• Las transmisiones externas y las acciones irreversibles están sujetas a una aprobación adicional o una comprobación de políticas.
• Se impide que el agente modifique arbitrariamente sus propios criterios de evaluación, pruebas o registros de auditoría.

Es más seguro imponer estas condiciones invariantes mediante un sandbox, controles de acceso, transiciones de grafos y verificadores independientes que mediante una sola frase en un prompt. La gestión de riesgos de la IA generativa debe abarcar no solo la precisión del modelo, sino también el entorno operativo, la supervisión humana y la respuesta ante incidentes.

Qué concepto se debe aprender primero

En el trabajo práctico actual, lo primero que debe aprenderse es la ingeniería de arnés. Contar con un contexto preciso, privilegios mínimos, verificación automática, registros, aprobaciones y límites de coste puede reducir muchos de los fallos de un solo agente.

Después, se añaden bucles con condiciones de finalización a las tareas en las que la repetición mejora la calidad. Cuando las bifurcaciones, el procesamiento paralelo, la recuperación y los procedimientos de aprobación se vuelven complejos, se especifican mediante un grafo. Antes que adoptar términos complejos, la prioridad es expresar de forma medible los objetivos, permisos, pruebas, costes y condiciones de interrupción del agente.