Comparteix via

Explora patrones de orquestación multiagente

La orquestación generativa también soporta sistemas multiagente, donde un agente llama a otro agente. Descomponer los problemas en múltiples agentes especializados puede mejorar la modularidad, la escalabilidad y la gestionabilidad.

Agentes en línea

Los agentes en línea, también conocidos como agentes hijos, son flujos de trabajo pequeños y reutilizables dentro del mismo agente. A menudo son solo temas que el agente principal usa como subrutinas. Por ejemplo, el agente principal puede llamar a un tema de "Traducir texto" como un paso más en un plan más amplio. Los agentes en línea comparten contexto con el agente principal, así que pasar datos entre ellos es sencillo.

Buenas prácticas: Mantén a los agentes en línea centrados en una sola responsabilidad y bien probados.

Agentes conectados

Los agentes conectados son agentes separados con su propia orquestación, herramientas y conocimientos. El agente principal delega parte de la solicitud a un agente infantil. Por ejemplo, un agente de TI llamando a un agente de ventas para pedir precios. Los agentes conectados permiten modularidad, separación de dominios y pueden saltarse los límites del plano. Pueden tener diferentes privilegios o conocimientos, así que aplica controles de gobernanza y auditoría.

Sin embargo, el uso de agentes conectados requiere una gobernanza cuidadosa:

  • Orquestación: El orquestador principal debe tener criterios claros sobre cuándo entregar el servicio a un agente conectado. Esta transferencia suele ocurrir cuando la intención del usuario coincide con el dominio del agente conectado. Para ayudar en este proceso, describe claramente el propósito del agente conectado en la configuración del padre. Trata todo el agente conectado como una "herramienta" con una descripción, desde la perspectiva del padre.

  • Transferencia de datos: Debes gestionar la transferencia de datos. Decide qué contexto del padre transmitir al agente conectado. Copilot Studio transmite el historial de conversaciones por defecto cuando un agente llama a otro, para que el agente conectado sepa lo que ya se ha discutido. Pero puede que también necesites cumplir ciertos parámetros. Por ejemplo, si el agente principal ya conoce el nombre del usuario de antes, podría enviarlo al agente conectado para evitar preguntar de nuevo.

  • Seguridad: El agente conectado podría tener acceso a cosas que el agente principal no tiene. Asegúrate de que llamar al agente conectado no se eluda las restricciones sin querer. Por ejemplo, si el agente padre no puede borrar registros pero el agente conectado puede, el agente padre no debería llamar al agente conectado en situaciones donde la eliminación pueda ocurrir sin la aprobación adecuada. Trata una llamada de agente conectado como cualquier otra acción poderosa. Si está haciendo algo delicado, someténlo a las comprobaciones necesarias o al consentimiento del usuario.

  • Auditoría y monitorización: Registrar cuándo se invocó un agente conectado y qué hizo. Como es un agente independiente, tienes expedientes distintos para él. Es importante para la depuración correlacionar las sesiones padre y las conectadas. Normalmente, los identificadores en la telemetría vinculan ambos.

Cuándo separar a los agentes

No crees un agente separado para cada subtarea. Utiliza agentes separados si la subtarea:

  • Es lo suficientemente complejo como para tener su propio conjunto de herramientas o conocimientos (de otro ámbito de especialización)
  • Requiere reglas de gobernanza o controles de acceso diferentes a los del agente principal
  • Planeas reutilizar esa capacidad en muchos agentes principales diferentes (así que es como un agente de servicio).

Si ninguna de esas condiciones se aplica, un tema simple (en línea) podría ser suficiente en lugar de un agente completamente conectado. Los agentes separados introducen sobrecarga: un tiempo de ejecución ligeramente mayor debido al cambio de contexto y la complejidad en mantener múltiples bots. Así que úsalos con criterio. Un enfoque práctico es empezar con un solo agente y solo dividirlo en varios agentes cuando se vea claramente una necesidad de modularidad o un límite que no debería ser cruzado por un solo agente.

  • Last updated on