Patrones de diseño de sistemas de agentes

La creación de un sistema de agente implica la orquestación de cómo fluyen juntas las llamadas LLM, la recuperación de datos y las acciones externas. Piense en patrones de diseño para sistemas de agentes en un continuo de complejidad y autonomía: desde cadenas deterministas, a través de sistemas de agente único que tomen decisiones dinámicas (e impliquen varias llamadas a LLM internamente), hasta arquitecturas multiagente que coordinen varios agentes especializados.

Llamada a herramientas

Antes de profundizar en los patrones de diseño, es importante comprender las llamadas a herramientas como una funcionalidad fundamental que se puede usar en cualquier sistema de agente, de simple a complejo. La llamada a herramientas es un mecanismo que permite a un sistema de agente interactuar con funciones externas, orígenes de datos o servicios. Esto puede habilitar:

• Búsquedas de datos dinámicos, como consultas SQL, capturas de CRM o recuperación de índices vectoriales.
• Acciones como enviar un correo electrónico o actualizar un registro.
• Lógica arbitraria o transformaciones a través de funciones o API de Python.

Por lo tanto, la llamada a herramientas proporciona un mecanismo eficaz para hacer que los LLM "sean conscientes" de los datos externos o las API, independientemente del patrón de diseño que elija.

Para más información sobre las herramientas del agente de IA, consulte .

En las secciones siguientes se describen tres patrones de diseño del sistema del agente, cada uno de los cuales puede aprovechar las llamadas a herramientas en distintos grados.

Comparar patrones de diseño de aplicaciones de IA generativa

Los patrones de diseño de aplicaciones de IA generativa (agente) se presentan en orden de complejidad.

Patrón de diseño	Cuándo usar	Ventajas	Contras
Cadena determinista	Tareas bien definidas Canalizaciones estáticas, como RAG básico No es necesario tomar decisiones sobre la marcha	Muy simple Fácil de auditar	Rígido Requiere cambios de código para adaptarse
Sistema de agente único	Consultas moderadas a complejas en el mismo dominio Algunas decisiones dinámicas sin la sobrecarga de varios agentes especializados.	Flexible Más sencillo que multiagente "Valor predeterminado" correcto	Menos predecible Debe protegerse frente a llamadas a herramientas repetidas o incorrectas
sistema multiagente	Dominios grandes o entre funciones; varios agentes "expertos"; contextos de conversación o lógica distintos; patrones de reflexión avanzados.	Altamente modular Se escala a grandes dominios	Complicado de orquestar Más difícil realizar un seguimiento y depurar

sistema de agente único

Un sistema de agente único incluye un flujo coordinado de lógica (a menudo orquestando varias llamadas LLM) para controlar las solicitudes entrantes. El agente puede:

1. Acepte solicitudes como consultas de usuario y cualquier contexto relevante, como el historial de conversaciones.
2. Razona sobre la mejor manera de responder, opcionalmente decidir si llamar a herramientas para obtener datos externos o realizar acciones.
3. Iterar si fuera necesario, llamando a un LLM (y las mismas herramientas) repetidamente hasta que se logre un objetivo o se cumpla una determinada condición (por ejemplo: recibir datos válidos o resolver un error).
4. Integre las salidas de la herramienta en la conversación.
5. Devuelve una respuesta cohesiva como salida.

En muchos casos de uso, una sola ronda de razonamiento de LLM (a menudo, con llamadas a herramientas) es suficiente. Sin embargo, los agentes más avanzados pueden recorrer varios pasos hasta que lleguen a un resultado deseado.

Aunque solo hay un único agente, todavía puede haber varias llamadas de LLM y herramientas en segundo plano (para planear, generar, verificar, etc.), todas gestionadas por este único flujo unificado.

ejemplo de : asistente del departamento de soporte técnico

• Si el usuario hace una pregunta sencilla ("¿Cuál es nuestra política de devoluciones?"), el agente puede responder directamente a partir del conocimiento del LLM.
• Si el usuario desea conocer el estado de su pedido, el agente llama a una función lookup_order(customer_id, order_id). Si esa herramienta responde con "número de pedido no válido", el agente puede reintentar o pedir al usuario el identificador correcto, continuando hasta que pueda proporcionar una respuesta final.

Cuándo usar:

• Espera consultas de usuario variadas, pero aún dentro de un dominio o área de producto cohesiva.
• Algunas consultas o condiciones pueden garantizar el uso de herramientas, como decidir cuándo capturar datos de los clientes.
• Quiere más flexibilidad que una cadena determinista, pero no requiere agentes especializados independientes para diferentes tareas.

ventajas de :

• El agente puede adaptarse a consultas nuevas o inesperadas eligiendo a qué herramientas llamar (si fuera necesario).
• El agente puede ejecutar bucles de llamadas de LLM o invocaciones de herramientas para refinar los resultados, sin la necesidad de una configuración que sea totalmente multiagente.
• Este patrón de diseño suele ser el punto ideal para los casos de uso empresariales: más sencillo de depurar que las configuraciones de varios agentes, a la vez que permite una lógica dinámica y una autonomía limitada.

Consideraciones:

• En comparación con una cadena de codificado de forma rígida, es necesario protegerse frente a llamadas de herramientas repetidas o no válidas. (Los bucles infinitos pueden producirse en cualquier escenario de llamada a herramientas, por lo que se establecen los límites de iteración o los tiempos de espera).
• Si la aplicación abarca subdominios radicalmente diferentes (finanzas, devops, marketing, etc.), a un único agente puede resultarle complicado o sobrecargarse con los requisitos.
• Todavía necesita indicaciones y restricciones cuidadosamente diseñadas para mantener el agente centrado y relevante.

cadena determinista (pasos codificados de forma rígida)

En este patrón, el desarrollador define qué componentes se llaman, en qué orden y con qué parámetros. No hay ninguna toma de decisiones dinámica acerca de a qué herramientas llamar o en qué orden. El sistema sigue un flujo de trabajo predefinido para todas las solicitudes, lo que hace que sea muy predecible.

Normalmente se denomina "Cadena", el flujo es básicamente una cadena fija de pasos, como:

1. Siempre recupere la solicitud del usuario y recupere desde un índice vectorial para obtener el contexto pertinente.
2. Combine ese contexto con la solicitud del usuario en un mensaje LLM final.
3. Llame al LLM y devuelva la respuesta.

Ejemplo: cadena RAG básica

Una cadena RAG determinista siempre puede:

1. Recupere los resultados principales de un índice vectorial mediante la solicitud (recuperar) de un usuario entrante.
2. Dé formato a los fragmentos recuperados en una plantilla de indicación (aumento).
3. Pase la indicación aumentada al LLM (generar).
4. Devuelva la respuesta del LLM.

Cuándo usar:

• Para tareas bien definidas con flujos de trabajo predecibles.
• Cuando la coherencia y la auditoría son prioridades principales.
• Cuando quiera minimizar la latencia evitando varias llamadas de LLM para tomar decisiones de orquestación.

ventajas de :

• Mayor previsibilidad y auditabilidad.
• Normalmente, menor latencia (menos llamadas LLM para orquestación).
• Más fácil de probar y validar.

Consideraciones:

• Flexibilidad limitada para controlar solicitudes diversas o inesperadas.
• Puede ser complejo y difícil de mantener a medida que crecen las ramas lógicas.
• Puede requerir una refactorización significativa para dar cabida a nuevas funcionalidades.

sistema multiagente

Un sistema multiagente implica dos o más agentes especializados que intercambian mensajes o colaboran en tareas. Cada agente tiene su propio dominio o experiencia en tareas, contexto y conjuntos de herramientas potencialmente distintos. Un "coordinador" separado, que podría ser otro LLM o un enrutador basado en reglas, dirige las solicitudes al agente adecuado o decide cuándo pasar de un agente a otro.

ejemplo de : Asistente empresarial con agentes especializados

• agente de soporte al cliente: gestiona búsquedas, devoluciones y envíos de CRM.
• agente de Analytics: se centra en consultas SQL y resumen de datos.
• supervisor/enrutador: elige qué agente es mejor para una consulta de usuario determinada o cuándo cambiar.

Cada subagente puede realizar llamadas a herramientas dentro de su propio dominio (por ejemplo, lookup_customer_account o run_sql_query) que a menudo requieren avisos únicos o historiales de conversación.

Cuándo usar:

• Tiene áreas de problemas o conjuntos de aptitudes distintos, como un agente de codificación o un agente financiero.
• Cada agente necesita acceso al historial de conversaciones o a avisos específicos del dominio.
• Tiene tantas herramientas que es poco práctico ajustarlas todas en el esquema de un solo agente; cada agente puede tener un subconjunto.
• Desea implementar la reflexión, la crítica o la colaboración interactiva entre agentes especializados.

ventajas de :

• Este enfoque modular significa que cada agente se puede desarrollar o mantener por equipos independientes, especializados en un dominio estrecho.
• Puede controlar flujos de trabajo empresariales grandes y complejos que un solo agente podría tener dificultades para administrar de forma coherente.
• Facilita el razonamiento avanzado de varios pasos o de múltiples perspectivas; por ejemplo, un agente que genera una respuesta, y otro que la comprueba.

Consideraciones:

• Requiere una estrategia para el enrutamiento entre agentes, además del coste adicional del registro de logs, el seguimiento y la depuración en múltiples puntos de conexión.
• Si tiene muchos subagentes y herramientas, puede resultar complicado decidir qué agente tiene acceso a qué datos o API.
• Los agentes pueden pasar tareas indefinidamente entre ellos mismos sin resolución si no están restringidos cuidadosamente.
  • Los riesgos de bucle infinito también existen en el uso de herramientas de agente único, pero los entornos de varios agentes agregan otra capa de complejidad en la depuración.

Consejos prácticos

Independientemente del patrón de diseño que seleccione, tenga en cuenta los siguientes procedimientos recomendados para desarrollar sistemas de agentes estables y fáciles de mantener.

1. Iniciar sencillo: Si solo necesita una cadena sencilla, una cadena determinista es rápida de crear.
2. Agregar complejidad gradualmente: A medida que necesite consultas más dinámicas o orígenes de datos flexibles, vaya a un sistema de agente único con llamadas a herramientas.
3. Go multi-agent: Solo si tiene dominios o tareas claramente distintos, varios contextos de conversación, o un conjunto de herramientas demasiado extenso para el aviso de un solo agente.

Si tu caso de uso comienza pequeño, como una sencilla cadena RAG, comienza con una cadena con código fijo. A medida que evolucionan los requisitos, puede agregar lógica de llamada a herramientas para la toma de decisiones dinámicas o incluso segmentar tareas en varios agentes especializados. En la práctica, muchos sistemas de agentes reales combinan patrones. Por ejemplo, use una cadena principalmente determinista, pero permita que LLM llame dinámicamente a determinadas API en un solo paso si es necesario.

Mosaic AI Agent Framework es independiente de cualquier patrón que elija, lo que facilita la evolución de los patrones de diseño a medida que crece la aplicación.

Guía de desarrollo

• Indicaciones
  • Mantenga las indicaciones claras y mínimas para evitar instrucciones erróneas, distraer información y reducir las alucinaciones.
  • Proporcione solo las herramientas y el contexto que requiere el agente, en lugar de un conjunto sin enlazar de API o un contexto irrelevante grande.
• Registro y observabilidad
  • Implementación del registro detallado para cada solicitud de usuario, plan de agente llamada de herramientas. El seguimiento de MLflow puede ayudar a capturar registros estructurados para la depuración.
  • Almacene los registros de forma segura y tenga en cuenta la información de identificación personal (PII) en los datos de conversación.
• Actualizaciones de modelos y asignación de versiones
  • Los comportamientos de LLM pueden cambiar cuando los proveedores actualizan modelos en segundo plano. Use el anclaje de versiones y las pruebas de regresión frecuentes para asegurarse de que la lógica del agente sigue siendo sólida y estable.
  • La combinación de MLflow con la Evaluación del agente de Mosaic AI proporciona una manera simplificada de control de versiones y evaluación periódica de la calidad y el rendimiento de los agentes.

Guía de pruebas e iteración

• Control de errores y lógica de respaldo
  • Planee errores de herramientas o LLM. Los tiempos de espera, las respuestas con formato incorrecto o los resultados vacíos pueden interrumpir un flujo de trabajo. Incluya estrategias de reintento, lógica de respaldo o una opción de respaldo más sencilla cuando fallen las características avanzadas.
• Ingeniería de indicaciones iterativas
  • Espere refinar las indicaciones y la lógica de la cadena a lo largo del tiempo. Gestione versiones de cada cambio (mediante Git y MLflow) para que pueda revertirlos o comparar el rendimiento entre las versiones.
  • Considere frameworks como DSPy para optimizar programáticamente las indicaciones y otros componentes dentro del sistema de su agente.

Guía de producción

• latencia versus optimización de costos
  • Cada llamada de LLM o herramienta adicional aumenta el uso de tokens y el tiempo de respuesta. Siempre que sea posible, combine pasos o almacene en caché consultas repetidas para mantener el rendimiento y el costo administrables.
• Seguridad y espacios aislados
  • Si su agente puede actualizar registros o ejecutar código, ponga esas acciones en un entorno aislado o exija la aprobación humana cuando sea necesario. Esto es fundamental en entornos empresariales o regulados para evitar daños no deseados.
  • Databricks recomienda las herramientas de Unity Catalog para ejecución en un entorno aislado. Consulte Herramientas de función de catálogo de Unity frente a herramientas de código de agente. El catálogo de Unity habilita el aislamiento de la ejecución arbitraria del código y evita que los actores malintencionados engañan al agente para generar y ejecutar código que interfiera o intercepte las demás solicitudes.

Siguiendo estas instrucciones, puede mitigar muchos de los modos de error más comunes, como las llamadas incorrectas de herramientas, el desfase del rendimiento de LLM o los picos de costos inesperados, y crear sistemas de agente escalables y confiables.