Modelos de diseño de agentes AI: Elige por contención de fallas

Los patrones de diseño del agente AI deben ser elegidos por el límite de falla que pueda operar. Comience con una llamada de modelo directa o un agente con herramientas. Añadir etapas secuenciales, ramas paralelas, entregas especializadas o un bucle de revisión solo cuando un requisito de carga de trabajo medido justifique la nueva topologíay solo cuando pueda registrar la evidencia que la topología necesita. Esa respuesta es menos glamorosa que dibujar una flota de agentes colaboradores. También es más fácil de deshacer, más barato de ejecutar, y más difícil confundir con un sistema sano cuando parte del trabajo ha desaparecido. La regla central es simple: Cada nueva ejecución crea una deuda de evidencia. No agregues el borde hasta que puedas nombrar su estado falso verde y el recibo que lo refuta. Este artículo aplica esa regla a seis opciones comunes: una llamada de modelo directa, un único agente, una tubería secuencial, ventilación paralela, entrega especialista y un bucle de revisión limitado. Incluye un selector determinista reproducido contra seis cargas de trabajo. Comience por debajo de agent a menos que la tarea obtenga autonomía Un diagrama de arquitectura debe comenzar con el mecanismo menos potente que pueda satisfacer el contrato de tareas. Una clasificación o traducción en un solo paso generalmente no requiere ni herramientas ni un bucle de agentes. La cuestión de la salud es simplemente si la producción cumple con una afirmación definida. Un solo agente se vuelve útil cuando la tarea es lo suficientemente abierta como para requerir varias decisiones o llamadas a herramientas. Un agente de apoyo de pedidos, por ejemplo, puede interpretar una solicitud, recuperar una orden y componer una respuesta. Todavía tiene un propietario y un lugar para verificar el resultado. Esto es consistente con las directrices oficiales actuales. Guía de patrones de agentes de Google Cloud dice que definir la complejidad de la tarea, la latencia, el costo y los requisitos de participación humana antes de seleccionar un patrón. Se recomienda comenzar con un agente durante el desarrollo temprano y señala que los diseños de múltiples agentes añaden evaluación, seguridad, fiabilidad y preocupaciones de costo. El Centro de arquitectura de Azure también recomienda la menor complejidad que cumpla confiablemente con los requisitos; llama a la coordinación de gastos generales, latencia y modos de falla adicionales en sistemas multiagentes. Utilice este primer límite de decisión: Propiedad de carga de trabajo Default razonable Prueba de finalización Una transformación limitada, sin herramientas. Llamada de modelo directa La salida pasa la afirmación de tarea Varias decisiones dentro de un dominio Agente único con herramientas Se verifican los efectos requeridos de las herramientas y el resultado final Estadios fijos con dependencias estrictas Línea de tuberías secuencial Cada etapa consumió la versión predecesora esperada Subtareas independientes cuya latencia es importante Ventilador paralelo Todas las ramas requeridas se contabilizan antes de la agregación Enrutamiento dinámico entre dominios o autoridades distintos Entrega de especialistas Un receptor aceptó la propiedad y puede reanudar desde un cursor duradero La revisión debe continuar hasta que se mantenga una condición medible Circuito restringido El progreso cambió, el verificador pasó, y el presupuesto de iteración se mantuvo La mesa es por defecto, no un diseño automático. Una llamada directa puede seguir siendo insegura si su salida desencadena una acción irreversible. Un solo agente puede ser demasiado amplio si tiene docenas de herramientas con permisos incompatibles. El patrón sigue la carga de trabajo y el límite de autoridad. La restricción importante es evitar tratar la descomposición como fiabilidad libre. Dividir una tarea entre más componentes puede mejorar la especialización, la latencia o el aislamiento de seguridad. También crea estados más parciales. El operador debe ser capaz de determinar en qué estado ocupa la carrera sin leer un mensaje final persuasivo. Hacer que cada topología pague su deuda de evidencia Las instrucciones de AWS describe los patrones de agentes como bloques de construcción reutilizables y composibles. La reutilización es valiosa, pero la composición cambia lo que significa done. Un componente de la información de éxito es sólo la evidencia de actividad. La pregunta útil es si toda la topología produjo el resultado previsto. Secuenciales: prueba la cadena, no la última etapa Un patrón secuencial es apropiado cuando el orden de etapas es parte de la corrección: extraer, validar, aprobar y luego publicar. El caso falso verde aparece cuando una etapa posterior se ejecuta después de que una etapa anterior falló, se utilizó una salida obsoleta o se produjo una versión incompatible. Presentar a cada etapa un recibo que contenga al menos: la identificación de ejecución y la identificación de etapa; el recibo o hash de entrada del predecesor; el hash de salida o el ID de efecto duradero; estado terminal y tiempo de finalización; la afirmación que permite la siguiente etapa. La siguiente etapa debe rechazar un predecesor perdido o no igualado en lugar de adivinar. Un evento final publish completed no puede reparar un recibo de validación ausente. Paralelo: congelar la membresía antes de completar el conteo La extensión paralela se justifica cuando las ramas independientes reducen la latencia o recogen pruebas distintas. Su fallo característico es un colector que devuelve una respuesta pulida mientras que una rama requerida está ausente, duplicada, tardía o basada en entradas obsoletas. Congelar un manifiesto de la rama antes de enviar. Marque las ramas necesarias o opcionales. Entonces definen un quórum sobre el manifiesto congelado, no sobre las respuestas que llegaron. El coleccionista necesita la identidad de la rama, la versión de entrada, el estado terminal, la identidad del efecto y la frescura. Tres respuestas recibidas no son suficientes si se requieren cuatro. Transferencia: transferencia de propiedad, no sólo contexto Una entrega especialista es útil cuando el siguiente agente necesita un dominio diferente, un conjunto de herramientas o un límite de permisos. Se falla en silencio cuando el remitente informa transferido pero el receptor nunca aceptó el trabajoo lo aceptó sin el estado requerido para continuar. Una entrega duradera necesita dos lados: 1. el remitente registrará el receptor previsto, la identificación de trabajo, la versión contextual y el resultado restante; 2. el receptor registra la aceptación, su época de propiedad y un cursor de currículum. Hasta que exista la aceptación, el trabajo está esperando con el remitente. Después de la aceptación, sólo el receptor puede cometer el siguiente efecto. Esto evita una brecha ambigua y reduce el trabajo duplicado después de retrasos. Loop: progreso presupuestario, no sólo iteraciones Un generador crítico o un bucle de reparación verificación es apropiado cuando la calidad mejora a través de una evaluación repetida. No es apropiado simplemente porque el primer resultado pueda ser débil. El bucle debe tener una señal de progreso medible, un verificador y una condición de parada. Registro: el número de iteraciones y el máximo; plazo y el coste restante; las huellas dactilares de entrada y salida; un delta de progreso específico del dominio; el resultado del verificador; razón para continuar, detenerse o aumentar. Un bucle que repite diferentes formulaciones sin cambiar pruebas, restricciones o el artefacto esperado está activo pero no progresando. Detenerlo antes de que consuma el presupuesto final necesario para preservar la evidencia, retroceder, o preguntar a una persona. Reproduzca una regla de selección antes de adoptar el diagrama Convertí los límites anteriores en un pequeño selector determinista. Prefiere deliberadamente patrones más simples. La prioridad es explícita para que una carga de trabajo que necesita un verificador iterativo no caiga accidentalmente en la categoría secuencial simplemente porque sus pasos tienen un orden. El artefacto completo utiliza pattern cases.json , select agent pattern.mjs , y un informe esperado. Ejecutar con: La repetición de seis casos produjo la paridad exacta esperada: Carga de trabajo Modelo seleccionado Recibo requerido Clasificar un mensaje Llamada de modelo directa Aserción de entrada/salida Busca una orden y responde. Agente único Manifiesto de ejecución, recibos de efecto de herramienta, afirmación de resultado Extraer, revisar y publicar Secuencia Cadena de recepción de etapas, versión de entrada, estado de parada en fallo Investigación de cuatro fuentes independientes Ventilador paralelo Manifiesto de rama congelada, quórum requerido, afirmación agregada Apoyo de ruta para un especialista Entrega de especialistas Recibo de propiedad, cursor de continuación, afirmación final Revisar el código hasta que pasen las pruebas Circuito restringido Presupuesto de iteración, delta de progreso, veredicto del verificador Todas las seis recomendaciones coinciden y todas las seis emitían una obligación de prueba distinta. Ese segundo resultado es más importante que la exactitud del selector. Un nombre de modelo sin su contrato de recepción es una preferencia de diseño, no una decisión operativa. Tres observaciones salieron de la repetición. En primer lugar, la topología de la ambigüedad mapas para la evidencia de la ambigüedad. Las etapas secuenciales crean ambigüedad de finalización parcial; las ramas paralelas crean ambigüedad de membresía; las entregas crean ambigüedad de propiedad; los bucles crean ambigüedad de terminación. En segundo lugar, la misma afirmación final sigue siendo necesaria en cada patrón. Un manifiesto completo de la sucursal prueba la contabilidad de la sucursal, no que el informe reunido haya respondido a la pregunta del cliente. Un recibo de entrega prueba la propiedad, no la entrega. Un veredicto del crítico que pasa prueba sólo los criterios que el crítico realmente evaluó. En tercer lugar, los desencadenantes de la migración son más confiables que el entusiasmo por los patrones. Alejarse de un agente cuando la evidencia muestra una sobrecarga de herramientas, un límite de seguridad estricto, latencia independiente o un fallo recurrente que la topología más simple no puede contener. Multi agent es más escalable no es un gatillo medible. Tratar el patrón como un contrato operativo Antes de la implementación, escriba un contrato de una página para el patrón elegido: I Resultado previsto: ¿Qué artefacto o efecto observable debe existir? A Autoridad: ¿Qué componente puede hacer que cada cambio sea reversible o irreversible? Miembro: ¿Qué etapas, ramas o especialistas pertenecen a esta carrera? Progreso: ¿Qué cambia cuando el trabajo útil avanza? Esperando: ¿Qué dependencia o decisión humana detiene legítimamente el trabajo? Fallout: ¿Qué evidencia separa un error transitorio de una ejecución atascada? Completado: ¿Qué controles deterministas aclaran el trabajo? Presupuesto: ¿Qué limita el tiempo, los retemplazos, los tokens y los efectos secundarios? Luego inyecta el fallo característico de la topología antes del lanzamiento. Quita un recibo de fase secuencial. Dejar caer una rama paralela requerida. Retrasar la aceptación de las entregas. Regresa un artefacto sin cambios de una iteración de revisión. El sistema debe bloquearse, esperar o estar incierto. Hay una limitación práctica aquí. El selector no puede establecer que la descripción de la carga de trabajo es correcta. No mide la calidad del modelo, la disponibilidad del proveedor o la fiabilidad real de un marco. Un esquema de recibo tampoco puede demostrar que su implementación emite eventos verdaderos. Valida el patrón elegido con accesorios en forma de producción, inyección de fallas y controles de resultados a nivel de destino. Por lo tanto, la pregunta de revisión más segura no es ¿Cuál es el mejor patrón de diseño del agente AI? Es: ¿Cuál es el patrón menos complejo que satisface esta carga de trabajo, y podemos probar sus nuevos estados parciales sin inspeccionar el contenido privado? Si la respuesta es una llamada directa o un agente, guardala. Si la respuesta es una topología más compleja, haga de sus recibos parte del diseño en lugar de un proyecto de monitoreo posterior. El Sidewisp está destinado a añadir una capa de salud alrededor de los tiempos de funcionamiento de los agentes existentes, prestando atención a la accesibilidad, el progreso útil, el contexto, las herramientas, los resultados y el costo. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio web público y la demostración interactiva son en vivo, pero la colección de agentes de producción y la salud y los adaptadores de tiempo de ejecución no se envían en el repositorio actual del sitio web. Si este enfoque de prueba primero coincide con la forma en que desea operar a los agentes, puede unirse a la lista de espera de vista previa privada.