Distribución del contexto en el arnés estándar

El harness estándar distribuye el contexto entre los componentes que gestionan una petición. Cada componente funciona desde su propio contexto, y el arnés no reconcilia automáticamente el contexto a nivel superior. Esta separación proporciona flexibilidad, pero puede causar mensajes duplicados o respuestas perdidas si la información no es devuelto explícitamente por componentes independientes.

Este artículo explica por qué el contexto está distribuido, cómo difiere el harness de GitHub Copilot, cómo el contexto se mueve entre la capa de orquestación de agentes y un componente, y qué puede ver y devolver cada componente. Utiliza esta información para identificar lagunas de contexto y diseñar agentes que gestionen el contexto de forma deliberada.

El siguiente diagrama ilustra cómo fluyen el contexto y la comunicación entre la capa de orquestación, los componentes individuales y el usuario en el arnés estándar.

Diagrama que muestra el contexto y las comunicaciones pasadas entre la capa de orquestación, cada componente y el usuario en un agente de harness estándar.

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.

Un arnés alimenta todo lo que se fabrica en Copilot Studio, y el modelo seleccionado proporciona razonamiento y generación. El orquestador es un entorno de ejecución que existe entre ambos: determina cuándo llamar al modelo, qué componentes enviarle, interpreta lo que devuelve e invoca las herramientas adecuadas. Descubre más sobre los arneses Copilot Studio.

Por qué el arnés estándar distribuye el contexto

El arnés estándar está diseñado para ser flexible:

  • Orquesta tareas y soporta casos de uso transaccionales.
  • Equilibra el control determinista y la IA mediante variables, disparadores y características especializadas.
  • Distribuye el control entre componentes como temas, conocimiento, agentes hijos, agentes conectados y herramientas.
  • Soporta múltiples opciones de autenticación, canal e integración.

Distribuir el trabajo entre componentes independientes proporciona flexibilidad, pero puede crear lagunas en el contexto:

  • La capa de orquestación de agentes cede el control durante determinadas llamadas a componentes.
  • Mientras un componente se ejecuta, la capa de orquestación no puede ver los mensajes que el componente envía al usuario.
  • La capa de orquestación no reconcilia el contexto a nivel superior.

Si el diseño no gestiona el contexto del agente, se desarrollan lagunas y las solicitudes pueden quedar sin respuesta. Estos vacíos pueden causar respuestas duplicadas o que se pierdan.

Cómo difiere el arnés de GitHub Copilot

La capa de orquestación del arnés GitHub Copilot evita la descoordinación de contexto al ser el único comunicador con el usuario. Nunca permite que un agente conectado tome el control de la comunicación:

  • El bucle de razonamiento y comunicación funciona sin una gestión deliberada del contexto.
  • Los mensajes de los agentes conectados pasan por la capa de IA del agente principal en cada turno.

La capa de orquestación del arnés GitHub Copilot también trata el tamaño del contexto de forma diferente, lo que hace que su contexto sea órdenes de magnitud mayor que el arnés estándar:

  • Tiene acceso directo al contexto del modelo.
  • Puede usar la compactación.
  • Puede escribir datos y archivos en su contenedor sandbox Bash.

Cómo el contexto pasa a los componentes y regresa a la capa de orquestación

Para gestionar el contexto eficazmente en el arnés estándar, considera tanto lo que la capa de orquestación pasa a un componente como lo que el componente devuelve.

El contexto pasa a los componentes de dos maneras:

  • Entradas explícitas y peticiones: La capa de orquestación rellena las entradas de cada componente desde su contexto activo y pasa una petición tal como está diseñada.

  • Contexto de conversación implícito: La capa de orquestación también pasa un contexto de conversación más largo a componentes como el conocimiento y a subagentes sin una configuración explícita. Ten en cuenta que un agente infantil siempre recibe el contexto de la conversación parental. Un agente conectado tiene una configuración que lo incluye o excluye. Una herramienta o flujo recibe solo sus entradas.

Un componente envía la información de vuelta a la capa de orquestación de dos maneras:

  • Salidas explícitas y respuesta tal como se diseñaron.
  • Contexto implícito de ciertos componentes.

Lo que un componente solo muestra al usuario, o solo mantiene en sus propias variables, puede que nunca llegue a la capa de orquestación a menos que vuelva a pasar por uno de esos dos canales.

La transmisión implícita de información provoca que aproximadamente la mitad de los casos tengan respuestas duplicadas o fallidas porque un componente puede actuar sobre una petición que nunca se le ha pasado explícitamente.

Cómo varía el contexto entre componentes

La conversación visible para el usuario y el contexto de la capa de orquestación se solapan, pero no son lo mismo. Los siguientes principios se aplican a lo que llega al contexto de la capa de orquestación desde una llamada a componentes:

  • Lo que un componente se guarda para sí mismo permanece oculto. Existen variables temáticas y conversaciones de varios turnos dentro de los subagentes dentro del componente. La capa de orquestación solo los ve si se devuelven como salidas.

  • Solo dos tipos de información retornan. La capa de orquestación recibe las salidas explícitas que están diseñadas y el contexto implícito de un componente. Un componente que sí funciona pero no devuelve nada puede dejar la capa de orquestación sin saber qué ha pasado.

Cada componente tiene su propio contexto o punto de vista. La capa de orquestación utiliza su contexto activo para seleccionar pasos y generar entradas. Un agente conectado tiene su propia capa de orquestación, sus propias instrucciones y sus propias herramientas internas y llamadas de conocimiento.

Utiliza la siguiente tabla para plantear una pregunta precisa: ¿Qué componente tiene un hecho dado en su contexto activo?

Punto de vista Tiene en su contexto activo Puede escribir en el panel de chat Puede regresar como contexto
Capa de orquestación Solicitud del usuario, contexto de conversación, descripciones de componentes, descripciones de entrada, descripciones de salida, estado del plano, respuestas implícitas (pero no si la información implícita se ha mostrado al usuario) Sí. Sus propias preguntas y respuestas. Sus propias preguntas, respuestas, razonamientos y plan.
Tema Variables temáticas, estado actual del nodo Sí. A través de nodos de mensaje, nodos de preguntas y Pregunta con tarjeta adaptativa. Salidas de temas e intercambios implícitos de mensajes que aún pueden provocar duplicación.
Herramienta o flujo Entradas generadas por la capa de orquestación No. Salidas de herramienta o de flujo.
Etapa de conocimiento Solicitud del usuario más el contexto activo de su agente No. Escribe a su propio agente, no al panel de chat. Su respuesta.
Nodo de respuestas generativas (dentro de un tema) Lo que se envía como entrada junto con el contexto de su agente Sí. Directamente, o a una variable temática. No de forma explícita, puede repetirse.
Subagente (hijo o agente conectado) Su solicitud inicial, más las entradas proporcionadas por el padre y cualquier contexto de padre incluido, dentro de su propio contexto de capa de orquestación Sí, si está configurado o se le indica responder directamente. Una respuesta y sus salidas.

Importante

Temas: El contexto implícito devuelto por los temas solo incluye información en texto plano, pero no si el usuario la vio. La información en texto plano puede provenir de nodos de mensaje, nodos de pregunta, contenido de la Adaptive Card y respuestas escritas por el usuario. Sin embargo, los botones de acción de la Adaptive Card y las interacciones del usuario con ellos no alcanzan el contexto estándar del arnés. El manejo adaptativo de tarjetas causa la mayoría de las discrepancias de contexto. No te fíes del contenido de las cartas como contexto. En su lugar, devuelva cualquier información que necesite un paso posterior como salida de tema y establezca una salida de estado respondido. Aprende más sobre temas de diseño como mini-agentes que evitan mensajes duplicados.

Subagentes: Cuando el contexto padre se pasa a un agente conectado, puede influir en cada herramienta, tema y llamada de conocimiento que realice el agente. Si el contexto incluido sigue conteniendo una solicitud que parece no haber sido respondida, el agente conectado podría intentar compensar y responderla de nuevo. Un agente infantil tiene el mismo riesgo pero con menos control. Se ejecuta dentro del padre y siempre recibe el contexto de conversación del padre, sin ninguna opción de configuración para excluirlo. Aprende más en Subagentes de Diseño que evitan mensajes duplicados.

Paso siguiente

Teniendo en cuenta este modelo de contexto, el siguiente artículo de esta serie explica por qué este modelo provoca mensajes duplicados y sugiere patrones de diseño para evitarlos.

Mejores prácticas de diseño para evitar mensajes duplicados

  • Last updated on