Patrones de orquestación multiagente y procedimientos recomendados

La orquestación generativa también admite sistemas multiagente, donde un agente llama a otros agentes. Al dividir problemas en varios agentes especializados, la aplicación es más modular, escalable y fácil de administrar.

Agentes insertados

Los agentes integrados, también conocidos como agentes secundarios, 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 "Traducir texto" como un paso dentro de un plan más amplio. Los agentes en línea comparten contexto con el agente principal, así que pasar datos entre ellos es sencillo.

Procedimiento recomendado: mantenga los agentes alineados centrados en una sola responsabilidad y pruebelos bien.

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 llama a un agente de ventas para obtener información sobre los precios. Los agentes conectados permiten la modularidad y la separación de dominios, y pueden omitir los límites del plan. 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. Normalmente, el orquestador deja de funcionar cuando la intención del usuario coincide con el dominio del agente conectado. Para ayudar en este proceso, describe claramente en la configuración principal el propósito del agente conectado. Trate todo el agente conectado como una "herramienta" agéntica con una descripción, desde la perspectiva del elemento principal.

  • Transferencia de datos: Debes gestionar la transferencia de datos. Decida qué contexto del elemento secundario transmitir al agente conectado. Copilot Studio pasa el historial de conversaciones de forma predeterminada cuando un agente llama a otro, por lo que el agente conectado entiende el contexto anterior de la conversación. 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 omita inadvertidamente las restricciones. 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. Trate una llamada de agente conectado como cualquier otra acción eficaz. 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 principales 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
  • Se puede reutilizar en muchos agentes principales distintos (es decir, como un agente de servicios).

Si no se aplica ninguna de esas condiciones, un agente integrado sencillo podría encargarse bien de la tarea y además ser más sencillo que un agente conectado completo. Los agentes independientes introducen sobrecarga en el sistema. Hay un tiempo de ejecución ligeramente mayor debido al cambio de contexto y la complejidad en el mantenimiento de varios agentes. Así que úsalos con criterio. Para un enfoque práctico, comience con un agente. A continuación, solo se divide en varios agentes cuando se ve claramente una necesidad de modularidad o un límite que un único agente no debe cruzar.

Procedimientos recomendados para la orquestación multiagente

Las siguientes prácticas recomendadas se aplican al redactar instrucciones para agentes principales y subagentes en una configuración multiagente.

1. Principio de respuesta único

Asegúrese de que solo un agente se comunica con el usuario por turno. En una configuración de varios agentes, el agente primario es el único que debe entregar la respuesta final. Los subagentes son investigadores, no respondedores.

  • Do: Añade a las instrucciones principales: "Eres el único agente que se comunica con el usuario." Combine los resultados de todos los agentes secundarios en una única respuesta".
  • No: Déjelo ambiguo. Sin instrucciones explícitas, los subagentes responden directamente al usuario, lo que provoca mensajes duplicados o parciales.

2. Las instrucciones de subagentes deben declarar su rol

Indique siempre a los subagentes que son subagentes. Los subagentes no saben inherentemente que forman parte de una orquestación. Sin instrucciones explícitas, se comportan como agentes independientes y envían mensajes directamente al usuario.

  • Do: Agregue a las instrucciones de cada subagente: "Usted es un subagente. No responda directamente al usuario. El trabajo consiste en buscar información y devolver los resultados al agente primario. El agente primario controla toda la comunicación con el usuario".
  • No: Supongamos que los subagentes averiguan el patrón de orquestación por sí mismos.

3. Usa un lenguaje claro y directo en las instrucciones

Use siempre el lenguaje de directivas. Evite expresiones suaves o educadas. La plataforma inserta instrucciones de nivel de sistema mediante lenguaje seguro (DEBE, NO, NUNCA). Las instrucciones escritas con lenguaje flexible ("por favor intenten", "usted debería", "sería bueno para") pierden prioridad cuando entran en conflicto.

  • Do: "NO respondas nunca al usuario directamente. Devuelve únicamente tus hallazgos.
  • Do: "Debe haber exactamente una respuesta final por pregunta del usuario".
  • No: "Intente evitar enviar mensajes al usuario y, en su lugar, devuelva sus hallazgos".
  • No: "Idealmente, queremos una única respuesta combinada".

4. Usar un origen de conocimiento por subagent (sin superposición)

Asigne orígenes de conocimiento distintos y no superpuestos a cada subagente. Si dos subagentes buscan en la misma base de conocimiento, un subagent busca primero la respuesta. El segundo subagente devuelve resultados duplicados o omite completamente su búsqueda, sin agregar ningún valor.

  • Do: CA-1 busca en la Fuente de conocimiento A (por ejemplo, políticas de RR. HH.). CA-2 busca en la fuente de conocimiento B (por ejemplo, documentación de TI).
  • No: dé a ambos subagentes acceso a los mismos documentos, tablas de Dataverse o sitios de SharePoint.
  • Nota: Si solo tiene un origen de conocimiento, use un único agente con conocimiento en lugar de dividirse en dos subagentes. Multi-agent agrega valor solo cuando los orígenes son realmente diferentes.

5. Usar descripciones precisas y distintas para subagentes

Escriba descripciones claras y distintas para cada subagente que sea visible para el elemento primario. El agente principal utiliza las descripciones de los subagentes para decidir el enrutamiento. Si las descripciones son vagas, idénticas o inexactas, el elemento primario no puede tomar decisiones de enrutamiento adecuadas.

  • Do: CA-1: "Busca documentos de directivas de RR. HH. para preguntas relacionadas con los empleados". CA-2: "Busca en la base de conocimiento de TI preguntas de soporte técnico".
  • No: proporcione a ambos agentes la misma descripción cuando atienden dominios diferentes.
  • No: Use descripciones genéricas como "Este agente puede ayudar con preguntas".

6. Las instrucciones primarias deben definir el patrón de orquestación

Indique al agente principal cómo orquestar. No basta con decir "usa agentes secundarios". El elemento primario necesita instrucciones explícitas sobre este patrón: invocar agentes, esperar los resultados, combinar los resultados y luego responder.

  • Do: "Cuando el usuario formula una pregunta: 1. Invoque a ambos agentes secundarios para recopilar información. 2. Espere a que ambos elementos secundarios devuelvan sus hallazgos. 3. Combine los resultados en una única respuesta unificada. 4. Entrega exactamente una respuesta al usuario. Los agentes secundarios no deben responder directamente al usuario."
  • No: "Cuando el usuario realiza una pregunta, invoque a los agentes secundarios y obtenga la respuesta de ambos orígenes y proporcione una única respuesta combinada". (Demasiado impreciso. La instrucción no indica a los subagentes que permanezcan en silencio).

7. Incluir la directiva "sin respuesta directa" en la delegación de tareas

Incluso con instrucciones claras de subagentes, agregar refuerzo en la tarea delegada proporciona una red de seguridad.

  • Hacer: Añade a las instrucciones del elemento primario: "Al delegar en un agente secundario, incluye siempre en la tarea: 'Devuelve solo tus hallazgos. No responda al usuario".
  • No: confíe únicamente en las instrucciones propias del subagente. El contexto de la tarea proporciona a los subagentes más señales que refuerzan el patrón.

8. Prueba con consultas de coincidencia de dominio

Pruebe siempre con preguntas que no coincidan con el dominio de ningún subagent. Esta prueba revela si los subagentes devuelven correctamente "ninguna información encontrada" frente a devolver información que podría ser incorrecta, colgarse o enviar mensajes confusos.

  • Do: Pruebe con consultas fuera de todos los dominios de subagentes (por ejemplo, pregunte sobre el tiempo cuando los agentes controlan rr. HH. y TI).
  • Hacer: Compruebe que los identificadores primarios gestionan "ambos agentes no encontraron nada" correctamente.
  • No: solo pruebe con consultas de casos más sencillas que coincidan perfectamente con el dominio de un subagente.

9. Prefiere preguntar en lugar de informar cuando se espera una respuesta posterior

Utiliza interacciones de tipo pregunta cuando se espere que el usuario responda. Utilice el estilo informar/enviar solo para los mensajes unidireccionales finales. Si el agente pregunta al usuario algo mediante un mensaje unidireccional (informar), la respuesta del usuario vuelve al planificador primario como una consulta nueva. En este caso, es mejor continuar la misma conversación con el subagente.

  • Haga lo siguiente: Escriba instrucciones como: "Si necesita aclaración, pida al usuario una pregunta y espere su respuesta".
  • No: Escriba instrucciones como: "Informe al usuario sobre las opciones y deje que elija". "Informar" indica un mensaje unidireccional, mientras que "preguntar" indica un intercambio bidireccional.

Lista de comprobación de referencia rápida

# Comprobación
1 Las instrucciones primarias indican explícitamente "solo respondo al usuario"
2 Todas las instrucciones de subagentes dicen "no responder directamente al usuario"
3 Las instrucciones usan un lenguaje imperativo contundente (MUST, NEVER, ONLY)
4 Cada subagente tiene un origen de conocimiento único y no superpuesto
5 Las descripciones de subagentes son precisas, distintas y específicas
6 Las instrucciones primarias definen el patrón de orquestación completo (invocar → espera → combinar → responder)
7 El elemento primario transmite "sin respuesta directa" en el contexto de tarea delegada
8 Probado con consultas de coincidencia de dominio
9 La distinción entre preguntar e informar es correcta en las instrucciones del subagente
  • Last updated on