Cómo construir un flujo de trabajo multiagente con GPT-6 Astra
Diseñe un flujo de trabajo multiagente GPT-6 Astra con delegación limitada, flujos de trabajo paralelos, controles de estado compartido, síntesis, presupuestos, seguridad y evaluación.
Los sistemas multiagente son útiles cuando una tarea compleja contiene flujos de trabajo independientes que pueden ejecutarse en paralelo. Son ineficientes cuando cada paso depende del anterior. La función multiagente de la API de Respuestas de GPT-6 Astra permite que un agente raíz genere, envíe mensajes y espere a los subagentes, para luego sintetizar sus hallazgos.
En la fecha de verificación, los documentos de OpenAI describen Responses multi-agente como una función beta. Los inicios rápidos en JavaScript y Python utilizan el SDK beta de Responses; las integraciones HTTP sin procesar y WebSocket envían el encabezado OpenAI-Beta: responses_multi_agent=v1. Los esquemas de elementos pueden cambiar, por lo que se debe aislar el manejo beta detrás de un adaptador.
Elige trabajo que realmente se descomponga
Los candidatos fuertes incluyen explorar áreas separadas del código base, comparar documentos, investigar hipótesis independientes o implementar conjuntos de pruebas aislados. Los candidatos débiles incluyen un único cálculo ordenado, una tarea pequeña, un archivo compartido que cada trabajador debe editar o una llamada externa lenta que domina el tiempo de ejecución.
Los subagentes pueden reducir el tiempo de ejecución y la interferencia de contexto, pero aumentan el uso de tokens. Optimiza la latencia y la calidad de las tareas exitosas, no la cantidad de agentes.
Responsabilidades de la raíz y el subagente
Establece multi_agent.enabled para que la raíz sea elegible para generar un árbol de subagentes. Los subagentes comparten el modelo de la solicitud y las herramientas disponibles. La raíz debe:
- definir el resultado y los criterios de descomposición;
- asignar tareas delimitadas y sin superposición;
- pasar el contexto mínimo suficiente;
- resolver conflictos y brechas;
- sintetizar una respuesta final responsable.
Un informe de subagente debe indicar el alcance, el resultado esperado, los requisitos de evidencia, las restricciones y la condición de finalización. "Investigar competidores" es vago. "Comparar precios públicos y funciones de exportación de estos cuatro productos nombrados, citar páginas principales y marcar desconocidos" es comprobable.
Control de estado mutable compartido
Los agentes paralelos no deben editar el mismo registro o archivo sin coordinación. Prefiera una exploración de solo lectura seguida de un único commit propiedad de la raíz. Para el código, divida por módulo y ejecute una pasada de integración. Para sistemas empresariales, permita que los subagentes propongan acciones mientras la raíz o una transacción de la aplicación realiza la escritura.
En un flujo de trabajo creativo, agentes separados podrían revisar la continuidad del guion, la coherencia de los personajes y los requisitos de audio, con la raíz produciendo un único resumen de producción para Elser AI. No deben sobrescribir de forma independiente el mismo guion gráfico.
Presupuestar el árbol
Establece límites de aplicación para profundidad, agentes concurrentes, tokens totales, llamadas a herramientas, tiempo transcurrido y reintentos. La guía oficial señala que los subagentes pueden aumentar el uso de tokens. Un árbol acotado también evita que la delegación recursiva se convierta en una denegación de servicio accidental.
Dale a la raíz una instrucción explícita sobre cuándo se permite la delegación. Si el flujo de trabajo necesita una orquestación predecible, implementa el grafo en tu aplicación en lugar de pedirle al modelo que lo invente.
La síntesis es una tarea separada
No concatenes las salidas de los subagentes. Pide a la raíz que compare afirmaciones, verifique citas, identifique desacuerdos y determine qué evidencia prevalece. Conserva la procedencia mediante identificadores de fuente o campos de resultado estructurados.
Un contrato de síntesis puede requerir:
- hallazgos compartidos por todos los flujos de trabajo;
- desacuerdos y sus causas;
- falta de evidencia;
- acción recomendada y confianza;
- qué subagente/fuente respalda cada afirmación consecuente.
Si dos agentes dependen de la misma fuente defectuosa, el consenso aparente no es una confirmación independiente.
Seguridad y aprobaciones
Los subagentes heredan las herramientas disponibles, así que mantén el catálogo reducido. La autorización del lado del servidor se aplica a cada llamada, independientemente de qué agente la haya solicitado. Exige aprobación para acciones de gran impacto e identifica la acción real, no solo el nombre del subagente.
Trata los mensajes entre agentes como contenido de modelo no confiable. Valida los resultados estructurados y evita compartir secretos a menos que la tarea lo requiera. Un agente raíz no puede "supervisar" de manera segura permisos que la aplicación no logra hacer cumplir.
Evaluar el flujo de trabajo
Compara un sistema multiagente con una línea base de un solo agente en el mismo conjunto de prueba. Mide la calidad de las respuestas, la cobertura, la latencia, los tokens, las llamadas a herramientas, el trabajo duplicado, la tasa de conflictos y los fallos de integración. Introduce fallos: un subagente lento, un hallazgo incorrecto, una interrupción de herramienta y un trabajador que nunca regresa.
Adopta multiagente solo cuando la ganancia justifique la complejidad de la orquestación. Un árbol de agentes más pequeño con instrucciones más claras a menudo supera a un comité grande.
Patrón de referencia: investigación paralela, decisión serial
Considere una evaluación de migración. La raíz crea tres flujos de trabajo acotados: uno inventaria el uso de API, otro revisa las implicaciones de seguridad y uno más estima el costo operativo. Los tres son de solo lectura y devuelven un esquema común: hallazgos, evidencia, incertidumbre y acciones recomendadas. La raíz espera, identifica conflictos y escribe un plan. Solo después de la aprobación humana, el código de la aplicación crea tickets.
Este patrón funciona porque la exploración es independiente mientras que la decisión y la mutación permanecen en serie. También le da a la raíz la oportunidad de notar evidencia duplicada. Si cada agente cita la misma página desactualizada, la síntesis debería marcar la dependencia compartida en lugar de contar tres votos.
Establezca una política de tiempo de espera antes de la ejecución. La raíz debe poder finalizar con dos de tres informes mientras nombra explícitamente el flujo de trabajo faltante, o cancelar la ejecución cuando ese flujo sea obligatorio. Evite ciclos interminables de "espera". Almacene los IDs de los subagentes y los estados terminales para que un operador pueda diagnosticar la rama lenta sin leer toda la transcripción.
Para decisiones reguladas, exija que la raíz cite identificadores de evidencia estructurados en lugar de recuerdos libres. La acción final debe ser rastreable hasta la fuente, el resultado del agente, la síntesis de la raíz y la aprobación humana.
Preguntas Frecuentes
¿Está GPT-6 Astra multiagente generalmente disponible?
La guía oficial etiqueta la función de múltiples agentes de Responses como beta a partir del 7 de septiembre de 2026. Consulta la página del modelo y la guía antes de la implementación.
¿Los subagentes usan modelos diferentes?
La función documentada dice que los subagentes comparten el modelo de la solicitud y las herramientas disponibles.
¿Es siempre más rápido un sistema multiagente?
No. La coordinación y síntesis añaden sobrecarga, y una dependencia lenta puede dominar la ejecución.
¿Cuándo debería permanecer la orquestación en el código de la aplicación?
Cuando el gráfico debe ser determinista, los pasos están ordenados, las escrituras comparten estado mutable o el cumplimiento normativo requiere transiciones explícitas.
Conclusión
Un buen flujo de trabajo multiagente GPT-6 Astra es un sistema de descomposición controlado: instrucciones independientes, contextos delimitados, herramientas mínimas, sin escrituras compartidas no controladas y síntesis rigurosa. Comience con una línea base de un solo agente, agregue paralelismo solo donde el trabajo realmente se separe, y trate los esquemas beta y el mayor consumo de tokens como restricciones operativas.
