Subagentes de diseño que evitan mensajes duplicados

Note

Este artículo describe características y comportamientos del arnés estándar. Descubre cómo acceder a las funciones estándar en Acceder a los agentes estándar y a los flujos de agentes.

Los mensajes duplicados provienen de lagunas de contexto. El diseño del agente debe tener en cuenta el contexto en cada paso.

Un subagente, ya sea un agente hijo o un agente conectado, se ejecuta en su propia capa de orquestación dentro del plan de un agente principal. Recibe una solicitud del padre y completa la tarea. El subagente produce tres tipos de salida: contenido que muestra al usuario, valores que devuelve a través de salidas definidas y una respuesta implícita que envía al agente que llama. El padre no puede ver el intercambio del subagente con el usuario y solo conoce el resultado a través de las salidas definidas y la respuesta implícita. Esta visibilidad limitada suele causar mensajes duplicados y respuestas perdidas.

Tip

Para orientarse sobre cuándo dividir el trabajo entre agentes y mejores prácticas generales para múltiples agentes, consulte los patrones y mejores prácticas de orquestación multiagente y patrones multiagente. Este artículo explica cómo las entradas y salidas alinean la respuesta de un subagente con el contexto del agente principal.

Este artículo se basa en el modelo de contexto descrito en Distribución de contexto en el arnés estándar y en las decisiones de diseño en las mejores prácticas de diseño para evitar mensajes duplicados.

Desactiva el contexto padre para un agente conectado

Un subagente que reciba el contexto de la conversación del padre puede actuar en consecuencia. Si ese contexto contiene una petición que el padre aún no ha respondido, el subagente podría responderla, repetir algo que el padre ya ha gestionado o asumir el rol equivocado. Estas acciones suelen causar mensajes duplicados.

Un agente conectado tiene una configuración, Pasar historial de conversaciones a este agente, que controla si recibe el contexto de conversación del padre. Esta opción está habilitada de manera predeterminada. Desselecciona la opción para que el agente conectado funcione solo con las entradas que envía el padre, no con toda la conversación.

Captura de pantalla de la opción 'Pasar historial de conversaciones a este agente' activada, señalando que desactivar impide compartir historial entre agentes.

Un agente secundario no tiene una configuración equivalente. Se ejecuta dentro del padre y siempre recibe el contexto de la conversación del padre.

Para los agentes conectados que necesitan mantener el contexto del trabajo que se les asigna, y para los agentes secundarios que disponen de contexto de forma predeterminada, utiliza un parámetro de ámbito para proteger el ámbito del subagente.

Utiliza una entrada para definir el alcance

A veces, un subagente necesita el contexto del agente padre para completar sus tareas. Cuando pases ese contexto, incluye una entrada de alcance: le indica al subagente exactamente en qué trabajar, para que las solicitudes persistentes y sin respuesta en el contexto no lo desvíen de la tarea. Si no pasas el contexto, no necesitas un input de delimitación porque el subagente solo tiene la solicitud que le redirigió el agente principal.

Para proteger el alcance del subagente, añade un parámetro de entrada llamado scopedRequest con una descripción como: The specific request this agent should fulfill. La capa de orquestación llena la entrada cuando llama al subagente. El agente padre identifica la parte relevante de la solicitud y solo pasa esa parte, incluso si su contexto contiene otra solicitud sin responder.

Una entrada con ámbito constituye un diseño sólido incluso cuando no se conserva el contexto principal. La entrada da al creador más control sobre el contenido de la petición que se envía al subagente.

Vincula las instrucciones del subagente a dicha entrada para que opere a partir de la solicitud delimitada e ignore cualquier otro contenido que pueda parecerse a una solicitud inicial.

Ejemplo de instrucciones para subagentes:

Fulfill the request in the scopedRequest input. 
Treat it as your initial request and ignore any other initial requests in the conversation.

Configuración de entradas y salidas

Las entradas y salidas son el contrato entre el agente principal y el subagente. La entrada define en qué trabaja el subagente, y las salidas le cuentan al padre lo que ha pasado para que pueda orquestar el resto de la conversación. El padre no puede ver el intercambio del subagente con el usuario, así que este contrato es la única señal fiable que tiene.

Importante

Un subagente que no devuelve salidas es una señal de alerta. Sin resultados, el padre no tiene constancia de lo que respondió el subagente ni de lo que queda pendiente. Puede repetir una respuesta que el subagente ya había dado, o eliminar la parte de la solicitud que el subagente no gestionó.

Configura las siguientes entradas y salidas, y escribe la descripción de cada una para que la capa de orquestación principal las lea:

Entrada o salida Description Cómo usar
scopedRequest (entrada) La solicitud específica que este agente debe cumplir. El padre lo rellena solo con la parte relevante de la solicitud del usuario. Protege al subagente de responder a la pregunta equivocada cuando el contexto del padre aún contiene otras peticiones sin respuesta. Ancla las instrucciones del subagente a esta entrada.
answered (salida) Verdadero cuando el usuario ya ha recibido una respuesta a scopedRequest. Configúralo en cada subagente, ya sea que envíe mensajes al usuario o que permanezca en silencio. La instrucción de primer nivel, que se muestra a continuación, la lee para que el padre no responda a la misma petición otra vez.
scopedRequest (salida) La petición en la que trabajó este agente. Repite la solicitud con alcance definido para que llegue a la capa superior de orquestación, que no conserva de forma fiable los datos de entrada que crea en su propio contexto. En interacciones de intención múltiple que requieren más de un subagente, esta capacidad permite que el nivel superior planifique correctamente y evita asignar el subagente equivocado a la pregunta equivocada.
interactionSummary (salida) Un breve resumen de la respuesta que se dio al usuario. Devuélvelo cuando el subagente envíe un mensaje directo al usuario, para que el padre sepa lo que se comunicó y no lo repita.
findings (salida) La respuesta a ScopedRequest, para que el elemento padre la entregue al usuario. Devuélvelo cuando el subagente permanezca en silencio, para que el padre tenga el contenido para entregar.
openQuestions (salida) Cualquier parte de la petición del usuario que quede sin respuesta. Devuélvelo desde cualquier subagente que solo pueda atender una parte de la solicitud, o si ha surgido una nueva petición en la conversación del subagente, para que el agente principal pueda completar el resto y seguir encadenando herramientas. El subagente no debería adivinar qué agente se encarga del resto.

Elige qué componente se comunica con el usuario

Decide si el agente padre o el subagente se comunica con el usuario. En la mayoría de los casos, permite que el agente padre se comunique con el usuario para que pueda combinar los resultados en una sola respuesta. Deja que el subagente comunique directamente cuando necesite dar una respuesta larga o mantener una conversación de varios turnos. Devolve suficiente información para que el padre pueda gestionar el resto de la conversación con contexto.

Sea cual sea el componente que comunique, añade una instrucción de nivel superior para que la capa de orquestación compruebe las salidas de cada subagente antes de responder.

Esta instrucción de primer nivel funciona en todos los casos, ya sea que un subagente envíe mensajes directos al usuario o permanezca en silencio. Edítalo y personalízalo según sea necesario.

Siempre que se llame a cualquier tema o agente, comprueba siempre el valor booleano de salida 'answered' antes de decidir qué responder. Los temas y agentes tienen su propio canal de comunicación con el usuario. Si 'respondido' es cierto, siempre asume que la petición ha sido respondida adecuadamente usando al menos una de las variables de salida y comprueba cuáles basándose en la descripción de salida. No des un reconocimiento incómodo del contenido respondido. Proporciona solo los resultados pendientes y continúa la conversación de forma natural con el siguiente paso.

El término canal no se refiere a un canal de integración. Es un dispositivo de indicaciones que indica a la capa de orquestación que el usuario podría haber visto ya la respuesta a través de otro componente.

Escribe la descripción del subagente para la capa de orquestación principal, para que sepa cuándo usar el subagente y cómo leer sus salidas. Por ejemplo:

Handles payroll questions. 
If its answered output is true, the user has already received their response and it should not be answered again.

Establece las salidas de estado de respuesta y de valor para cada subagente, tanto si el subagente envía un mensaje al usuario como si permanece en silencio, y dale al agente principal una instrucción para leerlas. Con este enfoque, un agente puede mezclar subagentes silenciosos y subagentes que envían mensajes directos al usuario, distinguidos solo por sus salidas. Aprende más en Diseñar una instrucción robusta de nivel superior para evitar mensajes repetidos.

Delegar la comunicación del usuario al padre

Considera enrutar toda la comunicación del usuario a través del agente padre en lugar de un subagente. Recoge lo que el subagente necesita como entradas antes de empezar, lee lo que ha producido como salidas cuando termine, e indícale que no envíe mensajes directos al usuario. Un subagente que nunca escribe al usuario no puede responder algo que el padre ya ha respondido.

Dile al subagente que guarde silencio y devuelva sus hallazgos. Por ejemplo:

Do NOT reply or communicate with the user directly. 
Only fulfill the scopedRequest provided in the input and respond with the result.

Un subagente silencioso devuelve findings y openQuestions, ambos descritos en Configure entradas y salidas, para entregar su respuesta al padre y marcar cualquier trabajo que quede.

Devuelve una salida openQuestions. Permite que la capa de orquestación termine el resto de la solicitud del usuario y continúe encadenando herramientas cuando un subagente solo puede cumplir con parte de lo solicitado.

Mantener el subagente en silencio requiere una instrucción explícita. Por defecto, un subagente puede enviar mensajes al usuario por sí solo mientras se ejecuta. La opción de finalización Después de la ejecución no evita estos mensajes porque solo le indica al padre qué hacer cuando el subagente termina.

Note

Decirle al agente principal: "Eres el único agente que habla con el usuario" no funciona. El agente padre no puede detener un subagente en ejecución, y el subagente aún puede enviar mensajes al usuario por sí solo. En su lugar, indica al subagente que guarde silencio y luego prueba para confirmarlo.

Algunos subagentes deben comunicarse directamente

Un subagente que envía mensajes directos al usuario es una elección válida, no una violación de una regla, pero requiere un diseño deliberado para evitar mensajes repetidos del padre.

Algunos casos de uso requieren que el subagente responda directamente al usuario, ya sea para entregar una respuesta larga sin copiarla al contexto principal o para mantener una conversación. Para evitar mensajes repetidos y pérdida de contexto, pasa el contexto al padre en las salidas.

Haz que el subagente dé una respuesta larga y devuelva un resumen

El subagente proporciona su respuesta completa directamente al usuario y solo devuelve un breve resumen o una nota de que ha dado la respuesta. Utiliza este enfoque para respuestas largas, como análisis detallados, y limita la información devuelta al contexto del padre. El objetivo es mantener el contexto de los padres pequeño pero informado.

Return answered y interactionSummary, ambos descritos en Configurar entradas y salidas.

Haz que el subagente mantenga una conversación con el usuario

El subagente intercambia múltiples mensajes con el usuario a lo largo de varios pasos para completar la solicitud con alcance definido. El principal riesgo es que el padre no sea consciente de los pasos intermedios de la conversación, del trabajo del subagente y de las respuestas dadas, ni de las nuevas peticiones que han surgido. Como resultado, el padre no puede actuar ante nuevas solicitudes ni responder correctamente en los pasos posteriores.

Devuelve answered, scopedRequest, y interactionSummary, como se describe en Configurar entradas y salidas.

La instrucción de nivel superior también cubre este caso de uso.

  • Last updated on