Los agentes de Large Language Model (LLM) han revolucionado la forma en que abordamos tareas complejas de varios pasos al combinar las capacidades de razonamiento de los modelos básicos con herramientas especializadas y experiencia en el dominio. Si bien los sistemas de agente único que utilizan marcos como ReAct funcionan bien para tareas sencillas, los desafíos del mundo real a menudo requieren que varios agentes especializados trabajen en coordinación. Piense en la planificación de un viaje de negocios: se necesita un agente para buscar vuelos en función de las limitaciones de horario, otro para encontrar alojamiento cerca de los lugares de reunión y un tercero para coordinar el transporte terrestre; cada uno de ellos requiere diferentes herramientas y conocimientos del dominio. Este enfoque de múltiples agentes introduce un desafío arquitectónico crítico: orquestar el flujo de información entre agentes para garantizar resultados confiables y predecibles. Sin una orquestación adecuada, las interacciones de los agentes pueden volverse impredecibles, lo que dificulta la depuración, el seguimiento y la ampliación de los sistemas en entornos de producción. La orquestación de agentes aborda este desafío definiendo flujos de trabajo explícitos que rigen cómo los agentes se comunican, cuándo ejecutan y cómo sus resultados se integran en soluciones cohesivas. En lugar de permitir que los agentes interactúen ad hoc, la orquestación crea vías estructuradas que hacen que el razonamiento sea transparente y el flujo de información sea intencional.
Strands Agents es un SDK de código abierto diseñado específicamente para crear sistemas de inteligencia artificial (IA) orquestados. Proporciona abstracciones de agentes flexibles, integración perfecta de herramientas, observabilidad integral y componentes de orquestación como GraphBuilder que permiten a los desarrolladores conectar agentes en flujos de trabajo dirigidos con precisión y control.
En esta publicación, exploramos dos poderosos patrones de orquestación implementados con Strands Agents. Utilizando un conjunto común de herramientas de planificación de viajes, demostramos cómo diferentes estrategias de orquestación pueden resolver el mismo problema a través de distintos enfoques de razonamiento: ReWOO (Razonamiento sin observación), que separa la planificación, ejecución y síntesis en etapas discretas, y Reflexion, que implementa un refinamiento iterativo a través de ciclos estructurados de crítica y mejora. Estos ejemplos le mostrarán cómo Strands permite un control preciso sobre los flujos de trabajo de múltiples agentes, lo que da como resultado sistemas de IA más confiables, transparentes y fáciles de mantener.
Primeros pasos con los agentes de Strands
Strands Agents es un marco de código abierto lanzado recientemente por AWS para crear agentes de IA listos para producción. Simplifica el desarrollo del agente al abstraer el bucle del agente en tres componentes principales:
Proveedor de modelo: el motor de razonamiento (como Claude en Amazon Bedrock). Mensaje del sistema: instrucciones que dan forma al rol y las restricciones del agente. Cinturón de herramientas: el conjunto de API o funciones que el agente puede llamar.
Este diseño modular permite a los usuarios comenzar con sistemas simples de un solo agente y ampliarlos hasta sofisticadas arquitecturas de múltiples agentes. Strands incluye soporte integrado para operaciones asíncronas, gestión del estado de sesión e integraciones con múltiples proveedores, incluidos Amazon Bedrock, Anthropic y Mistral. También se integra perfectamente con servicios de AWS como Lambda, Fargate y AgentCore.
Lo que hace que Strands sea particularmente poderoso son sus capacidades de orquestación multiagente. Los usuarios pueden componer agentes de varias maneras: usar un agente como herramienta para otro, pasar el control entre agentes mediante transferencias o coordinar varios agentes que trabajan en paralelo. La función GraphBuilder del SDK permite a los usuarios conectar agentes en flujos de trabajo estructurados, permitiéndoles colaborar en tareas complejas de una manera controlada y predecible.
Para implementaciones de producción, Strands proporciona observabilidad de nivel empresarial a través de la integración de OpenTelemetry. Esto proporciona seguimiento distribuido en todo un sistema de agente, lo que facilita la depuración de problemas y el seguimiento del rendimiento a medida que los usuarios escalan desde prototipos hasta cargas de trabajo de producción.
Fundamentos de la orquestación de agentes con hebras
El patrón ReAct es el enfoque predeterminado para la mayoría de los agentes de IA en la actualidad. Combina planificación, invocación de herramientas y síntesis de respuestas en un único bucle de agente. Si bien esto funciona para tareas simples, crea problemas para escenarios complejos. El agente puede recurrir a herramientas repetidamente sin una estrategia clara, mezclar la recopilación de evidencia con conclusiones o apresurarse a dar una respuesta sin verificación. Estos problemas se vuelven críticos en aplicaciones que requieren razonamiento estructurado, comprobaciones de cumplimiento o validación de varios pasos. Aquí es donde brilla la orquestación.
En lugar de que un agente haga todo, Strands permite la creación de agentes especializados con distintas funciones para resolver el problema. Por ejemplo, un agente podría planificar el enfoque, otro ejecutar el plan y un tercero sintetizar los resultados. Los usuarios conectan estos agentes en flujos de trabajo controlados que cumplen con los requisitos exactos. En Strands, los patrones de orquestación utilizan un modelo de ejecución de gráficos. Piense en ello como un diagrama de flujo donde:
Cada nodo es un agente especializado. Los bordes definen cómo fluye la información entre los agentes. La estructura hace que los pasos de razonamiento sean visibles y depurables.
A diferencia de la toma de decisiones oculta de ReAct, los gráficos exponen cada paso. Los usuarios pueden rastrear qué agente produjo qué resultado, cuándo estuvo disponible y cómo lo utilizó el siguiente agente. Esta transparencia es crucial para construir sistemas confiables. Strands proporciona cuatro componentes fundamentales para cualquier patrón de orquestación:
Nodos: Agentes que encapsulan lógica o experiencia específicas. Bordes: Conexiones que definen el orden de ejecución y el flujo de datos. AgentResult: Formato de salida estandarizado de cada agente. GraphResult: Seguimiento de ejecución completo con tiempo, salidas y rutas tomadas.
La API GraphBuilder permite a los usuarios conectar estos componentes para definir qué agentes participan, cómo fluyen los datos entre ellos y dónde ingresan las entradas del usuario al sistema. En tiempo de ejecución, el gráfico se ejecuta de forma determinista y devuelve resultados estructurados.
Considere un canal de preguntas y respuestas sobre documentos:
El Retriever busca documentos relevantes. El Summarizer los condensa. Cada agente sólo ve los datos que necesita, cuando los necesita. El flujo es explícito, predecible y fácil de depurar. Este mismo enfoque se adapta a patrones complejos. Los usuarios pueden agregar ramas para diferentes rutas de razonamiento, bucles para un refinamiento iterativo o ejecución paralela para explorar múltiples estrategias. La clave es que se mantiene el control sobre cómo fluye la información a través del sistema.
En las secciones siguientes, implementamos nuestro primer patrón: ReWOO, que separa la planificación de la ejecución para crear flujos de trabajo de agentes más confiables.
Conjunto de datos y orquestación predeterminada
Detalles del conjunto de datos
Evaluamos nuestro sistema en el conjunto de datos de dominio de aerolíneas τ-Bench (Yao et al., 2024), que presenta más de 300 entradas de vuelos, 500 perfiles de usuario sintéticos, más de 2000 reservas pregeneradas, políticas aéreas detalladas, API simuladas para operaciones de reserva y 50 escenarios estructurados del mundo real. Este punto de referencia integral proporciona un banco de pruebas controlado pero realista para evaluar cómo los agentes interpretan las políticas, ejecutan llamadas API apropiadas y mantienen la coherencia en operaciones aéreas complejas, incluidas actualizaciones, cambios de itinerario y cancelaciones. Si bien el conjunto de datos original presenta cada tarea como una conversación de varios turnos, las hemos simplificado en consultas de un solo turno en este tutorial para mostrar mejor los patrones de orquestación.
Arquitectura de un vistazo: orquestación predeterminada con ReAct
ReAct (Razonamiento + Actuación) entrelaza dos fases dentro de un único bucle de agente. El agente razona en lenguaje natural para decidir el siguiente paso, invoca una herramienta si es necesario, observa el resultado de la herramienta y continúa razonando con esa observación hasta que puede producir una respuesta final.
En Strands Agents, la línea de base de ReAct se asigna claramente a un único Agente que posee el cinturón de herramientas de la aerolínea τ-Bench: una lista de herramientas de la aerolínea (buscar vuelos, reservar/modificar/cancelar reservas, buscar perfiles, etc.). Las herramientas son las funciones de Python proporcionadas en el conjunto de datos Tau-Bench, convertidas a herramientas Strands usando @tool decorador.
No hay ningún planificador o crítico explícito; la política que gobierna “pensar → actuar → observar → pensar…” vive dentro del mensaje del agente y del bucle interno del modelo. Esto convierte a ReAct en una base natural para los sistemas mejorados con herramientas porque requiere una orquestación mínima (un agente 'ejecutor de herramientas' con un cinturón de herramientas) y tiende a ser rápido en tareas simples.
Arquitectura de un vistazo: ReWOO (Razonamiento sin observaciones)
ReWOO replantea “cómo se utilizan las herramientas” en lugar de “qué herramientas existen”. Mantenemos un único ejecutor de herramientas para todas las API de las aerolíneas, pero aplicamos un plan → ejecutamos → sintetizamos la separación a su alrededor. En Strands, esto se convierte en un gráfico pequeño y explícito donde cada nodo devuelve un resultado escrito (AgentResult) y el tiempo de ejecución reenvía esos resultados de forma determinista. Esto conduce a la gobernanza, la observabilidad y la repetibilidad.
Planificador (solo plan). Produce un plan estrictamente formateado. Trabajador (solo ejecutar). Analiza el plan, resuelve argumentos, llama a herramientas y acumula evidencia en una estructura normalizada. Desacoplar la ejecución de la planificación hace que el uso de herramientas sea predecible y aplicable mediante políticas (el trabajador sólo puede ejecutar lo que el plan autoriza). Solver (solo sintetizar). Lee la evidencia (resultados de las herramientas, no directamente de las herramientas) y luego redacta la respuesta final. Mantiene auditables los efectos de las herramientas y la toma de decisiones; evita llamadas de seguimiento “ocultas” en el último paso.
Construido con GraphBuilder de Strands (nodos, bordes, punto de entrada), esto se convierte en un DAG determinista. El tiempo de ejecución entrega a cada nodo descendente la tarea original más la salida del nodo ascendente, capturada en AgentResult.
Planificador: agente exclusivo de planificación con una gramática estricta
El planificador genera un programa declarativo que describe el uso de la herramienta, no una respuesta. Las siguientes son las características importantes para diseñar un mensaje de planificación eficaz:
Enumere el conjunto permitido de nombres de herramientas con argumentos. Ejemplos breves para demostrar al LLM cómo planificar la respuesta a una consulta de usuario determinada. Aplicar la forma de salida. Usamos esto:
El plan se devuelve como AgentResult. Un plan estricto está listo para ser auditado y minimiza la ambigüedad. También permite realizar comprobaciones estáticas (por ejemplo, "solo se permiten estas herramientas; una por paso") antes de que se ejecute algo.
Ejemplo de un plan creado por el agente planificador para la consulta del usuario:
"Mi identificación de usuario es mia_li_3668. Quiero volar de Nueva York a Seattle el 20 de mayo (solo ida). No quiero volar antes de las 11 a.m. EST. Quiero volar en clase económica. Prefiero vuelos directos, pero una escala también está bien. Si hay varias opciones, prefiero la que tiene el precio más bajo. Tengo 3 equipajes. No quiero seguro. Quiero usar mis dos certificados para pagar. Si solo se puede usar un certificado, prefiero usar el más grande y pago el resto con mi tarjeta 7447”.
Trabajador: ejecutor determinista con argumento y resolución de bucle.
El trabajador ejecuta sólo lo que el plan autoriza; La resolución de argumentos se basa en datos. Esto hace que el comportamiento sea reproducible entre ejecuciones y versiones del modelo. El trabajador trata el plan como una especificación ejecutable.
Analizador de planes unificado: analiza tanto los pasos regulares como los bloques REPETIR, los ordena por ID de evidencia y los ejecuta en orden. Analiza tanto los pasos regulares como los bloques REPETIR, los ordena por ID de evidencia y los ejecuta en orden. Libro mayor de evidencia: cada paso produce un registro estructurado (#E{id} con descripción + resultados). Los errores se capturan como evidencia en lugar de fallar silenciosamente.step_evidence[f'#E{eid}'] = {
Resolución dinámica de argumentos consciente del contexto: cree un contexto a partir de (a) la tarea original y (b) N evidencias anteriores. Complete los marcadores de posición (por ejemplo, códigos de aeropuerto, ID de reserva) desde ese contexto, sin expresiones regulares frágiles en cadenas sin formato. Esto se puede hacer de dos maneras diferentes. Una forma es utilizar un LLM para inferir los valores de los argumentos a partir del contexto creado. El segundo método consiste en utilizar una coincidencia de expresiones regulares para resolver los valores de los argumentos. Envío dinámico de herramientas con casos especiales: las herramientas se invocan directamente mediante getattr.
Ejemplo de un paso ejecutado:
Solver: crea la respuesta final y la presenta al usuario.
Solver combina evidencia de ejecución de Worker con la consulta original del usuario para generar la respuesta final. Recibe el diccionario de evidencia estructurado y lo sintetiza en una respuesta en lenguaje natural. El solucionador nunca llama a las herramientas. Hace lo siguiente:
Análisis de evidencia: lee la tarea original y la evidencia del trabajador, desde el nodo del agente trabajador. Reconstrucción del plan: normaliza la evidencia en un bloque de texto compacto y ordenado “plan + evidencia”. Generación de respuesta final: utiliza LLM con un mensaje apropiado para producir la respuesta final, abordando explícitamente las limitaciones y las compensaciones.
Separar la síntesis de la ejecución produce registros de decisiones claros y una latencia estable. También facilita el intercambio de indicaciones de síntesis o modelos sin tocar la lógica de planificación/ejecución.
Arquitectura de un vistazo: Reflexión (Autocrítica)
La reflexión es un patrón de orquestación en el que un agente genera una respuesta candidata y una crítica de esa respuesta, luego usa la crítica para revisar la respuesta en un bucle acotado. El objetivo no es “intentar de nuevo” a ciegas, sino apuntar a revisiones basadas en comentarios explícitos y analizables por máquina (por ejemplo, restricciones violadas, controles faltantes, fundamentos débiles). En otras palabras, Reflexion convierte la retroalimentación del modelo en una señal de control estructurada que gobierna uno o más pases adicionales y se detiene tan pronto como la respuesta cumple con los criterios establecidos.
Reflexion envuelve la herramienta-ejecutor de vuelo existente con un bucle deliberado de borrador → crítica → revisión (opcional). En lugar de aceptar el primer resultado, el sistema genera una respuesta candidata, la evalúa según criterios explícitos y solo la revisa cuando la crítica dice que debería hacerlo. La motivación es que este método daría una mayor calidad de respuesta. El gráfico Reflexion tiene 2 nodos creados con GraphBuilder.
Borrador (solo plano). Produce una respuesta inicial y una reflexión inicial. Revisor (solo ejecutar). Bucles entre mejorar la consulta, revisar y reflexionar sobre la respuesta.
Aunque la orquestación se modela como un DAG, el nodo revisor encapsula hasta tres ciclos de revisión e invoca herramientas según sea necesario. Cada nodo devuelve un AgentResult; el tiempo de ejecución reenvía el resultado ascendente al nodo descendente y registra el seguimiento completo en GraphResult.
Borrador: Genera respuesta inicial y crítica
El nodo borrador utiliza la misma herramienta ejecutora de línea aérea que utilizan los otros patrones para producir una respuesta inicial. Inmediatamente después, ejecuta un pase de “reflexión” enfocado invocando LLM con un mensaje de reflexión que señala brechas (restricciones violadas, controles faltantes, justificación débil) y genera una carga útil compacta y etiquetada que el revisor puede analizar de manera determinista:
Carga útil formateada después de la revisión:**Respuesta**: …**Autorreflexión**: …**Necesidades-Revisión**: Verdadero|Falso**Consulta de usuario**: …
Revisor: recorre la fase de revisión y generación.
El revisor lee el borrador de la carga útil, analiza las etiquetas (Respuesta, Autorreflexión, Necesita revisión, Consulta del usuario) y decide si se justifica la revisión. Si es así, mejora la consulta original del usuario utilizando la crítica (por ejemplo, “límite de salidas ≥ 11:00, ≤ 1 parada, escala mínima 70 m”) y vuelve a invocar al ejecutor de la herramienta para producir una respuesta revisada. Luego se refleja nuevamente usando las mismas etiquetas. Este ciclo está limitado (por ejemplo, hasta 3 pases) y se detiene tan pronto como la crítica devuelve Necesita revisión: Falso. Un LLM mejora la consulta mediante un mensaje especialmente diseñado.
Resultados: respuestas de diferentes patrones de orquestación
En esta sección, analizamos algunos ejemplos del conjunto de datos y cómo se comporta cada patrón de orquestación.
Ejemplo 1:
"Consulta de usuario: Soy Lucas Brown (la identificación de usuario es lucas_brown_4047). Necesito cambiar la fecha de mi reserva de vuelo EUJUY6 y posponerla 2 días debido a una emergencia familiar".
Ganador: ReWOO (28s): rechazo alineado con las políticas sin cambios inseguros
Resumen
ReAct (17s): Rápido pero incorrecto: cambio de fecha de reclamos + cargo en una tarifa de Economía Básica. ReWOO (28s): Correcto: modificación de bloques; apunta a cancelar/volver a reservar la ruta. Reflexión (años 60): Política incorrecta: reconoce la Economía Básica pero dice que puede proceder con el cambio; se autoevalúa como “ACEPTAR” en lugar de detectar la infracción.
Ejemplo 2:
Consulta de usuario: "Mi identificación de usuario es mohamed_silva_9265. Quiero saber la suma de los saldos de mis tarjetas de regalo y la suma de los saldos de mis certificados… Luego quiero cambiar mi reserva reciente al viaje de ida y vuelta de negocios más barato sin cambiar las fechas… Si no se puede cambiar la economía básica, cancele y reserve una nueva… Utilice certificados, luego tarjetas de regalo, luego Mastercard; dígame cuánto se cobrará a mi Mastercard".
Ganador: Reflexion (116s): sigue la ruta “cancelar → volver a reservar” autorizada previamente por el usuario, conserva las fechas, proporciona los totales y calcula el resto exacto de Mastercard.
Resumen
ReAct (67s): Plan de pago y búsqueda detallado, pero cambia una fecha (29 de mayo) y muta antes de una confirmación limpia; entra en conflicto con las restricciones del usuario. ReWOO (43s): Plan sólido, identifica correctamente Economía Básica y totales, sugiere cancelar → volver a reservar; precios inconsistentes para la devolución completa y sin cifra final de Mastercard. Reflexión (116s): De extremo a extremo: totales → verificación de restricciones → RT más barato en las mismas fechas → cancelar (autorizado) → calcular Mastercard = $1,286. El más lento, pero más alineado con las instrucciones exactas del usuario.
Ejemplo 3:
Consulta de usuario: "Mi identificación de usuario es james_taylor_7043. Quiero cambiar mi próximo vuelo de una escala de LAS a IAH a un vuelo sin escalas. Mi identificación de reserva es 1N99U6. También quiero retirar mi equipaje facturado y quiero que el agente me reembolse el mismo".
Ganador: Reflexion (27s): ofrece opciones válidas sin escalas y niega correctamente el reembolso por retiro de equipaje según la póliza, sin cambios prematuros.
Resumen
ReAct (9s): seguro pero poco especificado: no surgieron opciones; propone una acción que viola la política. ReWOO (25 años): mutación excesivamente ansiosa: actualiza la reserva con dos vuelos y emite reembolsos por elección previa; Transferencia innecesaria de equipaje. Reflexión (27s): Alineada con las políticas y centrada en el usuario: presenta opciones concretas e ininterrumpidas, explica que no se reembolsará el equipaje y espera la selección.
Ejemplo 4:
Consulta de usuario: "Soy Anya García (ID: anya_garcia_5901). Reservé un vuelo (3RK2T9) y quiero cambiar el nombre del pasajero de Mei Lee a Mei García. Realice este cambio".
Ganador: ReAct (8s): ruta mínima y correcta: muestra una vista previa precisa de la actualización y espera un único sí o no.
Resumen
ReAct (8s): Vista previa correcta → confirmar con un toque; más rápido y fiel a la intención del usuario. ReWOO (14s): Buena descomposición (verificación de identidad + llamada de actualización) pero evidencia inconsistente (el pasajero permaneció "Lee" en #E4). Reflexión (40 años): piensa demasiado en una edición sencilla; no se ejecutó ningún cambio.
Cuándo usar qué patrón
ReAct (“hacer lo obvio” rápido y lineal) Úselo cuando: Una actualización o búsqueda simple e inequívoca con 1 o 2 llamadas a herramientas y sin concesiones (por ejemplo, cambiar nombre, alternar, buscar → responder). Fuerza: Latencia más baja; Planificación mínima, sin embargo, la latencia podría aumentar si sobrepasa las herramientas. Cuidado: puede saltarse las comprobaciones de políticas/elegibilidad y mutar de forma insegura si no tiene cuidado. ReWOO (planificar → ejecutar → sintetizar con gobernanza) Úselo cuando: necesita dependencias ordenadas y puertas de políticas antes de cualquier mutación (por ejemplo, verificar la clase de tarifa, luego buscar y luego actualizar). Fortaleza: Flujo de datos transparente; resultados auditables de Gráfico/Agente; más seguro por diseño. Cuidado (argumentos): si no utiliza un LLM, el análisis/validación de argumentos debe ser meticuloso (tipos/enumeraciones/obligatorio). Si utiliza un LLM para la resolución de argumentos, pase contexto enriquecido (esquemas + ejemplos) para vincularlos correctamente: agrega latencia pero mejora la confiabilidad en parámetros complejos. Reflexión (analizar opciones, luego actuar) Úselo cuando: Las decisiones con restricciones múltiples, las compensaciones o los matices de las políticas requieren comparar opciones (itinerario más barato según las reglas de pago, etc.). Fortaleza: Mejor razonando sobre alternativas y produciendo elecciones justificadas. Cuidado: más lento; Puede preguntar demasiado en ediciones triviales a menos que se limite la reflexión.
Arquitectura de un vistazo: orquestación híbrida: ReAct guiado por ReWOO
Teniendo en cuenta los pros y los contras de ReWOO (gobernanza y auditabilidad), ReAct (velocidad y flexibilidad) y Reflexion (calidad a través de la crítica), utilizamos un híbrido que toma la disciplina del plan de ReWOO y la agilidad de los pasos de ReAct. Un ReWOO Planner primero emite un programa estricto indexado por pasos (#E1…#En) que nombra las herramientas y su orden. Luego, la ejecución cambia a un bucle ReAct guiado por un plan que se ejecuta dentro de cada paso: el agente piensa → valida los argumentos de la evidencia previa → llama a la herramienta autorizada → observa y (si es necesario) realiza una ligera pasada de refinamiento. Esto preserva las garantías globales (sin nuevas herramientas, sin reordenamiento, puertas políticas antes de las mutaciones) al tiempo que mantiene la flexibilidad local para la vinculación de argumentos y las microdecisiones. En Strands, este híbrido se asigna a un gráfico de dos nodos:
Planificador (ReWOO): genera solo el programa de pasos (no hay llamadas a herramientas en este nodo). La salida es un artefacto de plan escrito con #E-pasos (por ejemplo, obtener saldos → buscar la reserva más reciente → opciones de búsqueda → comparar costos → mutar condicionalmente).
Trabajador ReAct guiado por planes: consume el plan y la tarea del usuario; para cada paso #E, realiza un bucle ReAct local pero nunca reordena los pasos ni llama a herramientas que no están en el plan. Valida argumentos, aplica barreras políticas (por ejemplo, Economía básica ⇒ cancelar → volver a reservar) y sintetiza la respuesta final. Tanto el planificador como el ejecutor utilizan el mismo conjunto de herramientas de la aerolínea τ-Bench (buscar/reservar/modificar/cancelar, búsquedas de usuarios/reservas, matemáticas, etc.), expuestas como herramientas de Strands.
Bucle ReAct local (por paso #Ek, acotado):
En comparación con ReAct básico, el plan proporciona gobernanza e idempotencia: el agente no puede deambular ni mutar prematuramente. En comparación con ReWOO puro, el bucle en paso maneja el desorden del mundo real (vinculación de argumentos, reintentos menores) sin volver a planificar. A diferencia de Reflexion, evita la sobrecarga de críticas de varias pasadas en tareas sencillas y, al mismo tiempo, produce un seguimiento auditable (plan + evidencia por paso). En la práctica, lo vemos brillar en solicitudes de varios pasos que necesitan verificaciones ordenadas (por ejemplo, totales → reglas de tarifas → buscar → cancelar/volver a reservar → división de pagos) pero se benefician de un pequeño razonamiento local dentro de cada llamada de herramienta.
Conclusión
En esta publicación, mostramos cómo la orquestación personalizada en Amazon Strands ayuda a los usuarios a ir más allá de un único agente monolítico y a diseñar un control explícito sobre el razonamiento, el uso de herramientas y el flujo de información. Utilizando el mismo conjunto de herramientas de la aerolínea τ-Bench, comparamos tres patrones (ReAct, ReWOO y Reflexion) bajo restricciones reales y observamos distintas compensaciones en latencia, costo y calidad de respuesta. ReAct sigue siendo la ruta con los gastos generales más bajos para búsquedas simples y actualizaciones de un solo campo. ReWOO es el valor predeterminado correcto cuando la corrección depende de una buena planificación y dependencias ordenadas: los usuarios pueden preparar puertas de políticas antes de las mutaciones, resolver argumentos con un contexto más rico y mantener un rastro de evidencia escrita para auditoría. La reflexión añade autocrítica para manejar opciones con múltiples restricciones y compensaciones entre pago/itinerario, a costa de una deliberación adicional. El modelo de ejecución de gráficos de Strands proporciona transferencias escritas, seguimientos de ejecución y contratos de herramientas ejecutables para que los usuarios puedan ajustar estos patrones por caso de uso (bucles ajustados para CRUD, planificar → ejecutar → sintetizar para actualizaciones gobernadas, reflexionar → revisar para análisis de opciones) mientras limita los efectos secundarios y la deriva del modelo.
Para crear agentes de producción, trate la orquestación como el plano de control: elija el patrón que coincida con su estructura de dependencia y perfil de riesgo, luego instrumentelo. Visite este repositorio de GitHub para obtener ejemplos, indicaciones y gráficos ejecutables de un extremo a otro.
Sobre los autores
Baishali Chaudhury es científica aplicada en el Centro de innovación de IA generativa de AWS, donde se centra en el avance de soluciones de IA generativa para aplicaciones del mundo real. Tiene una sólida experiencia en visión por computadora, aprendizaje automático e inteligencia artificial para la atención médica. Baishali tiene un doctorado en Ciencias de la Computación de la Universidad del Sur de Florida y un postdoctorado del Moffitt Cancer Center.
Rahul Ghosh es científico aplicado en el Centro de innovación de IA generativa de Amazon, donde trabaja con clientes de AWS en diferentes sectores verticales para acelerar el uso de la IA generativa. Rahul tiene un doctorado. en Ciencias de la Computación de la Universidad de Minnesota.
Isaac Privitera es científico de datos principal en el Centro de innovación de IA generativa de AWS, donde desarrolla soluciones personalizadas basadas en IA generativa para abordar los problemas comerciales de los clientes. Su principal objetivo es construir sistemas de IA responsables, utilizando técnicas como RAG, sistemas multiagente y ajuste de modelos. Cuando no está inmerso en el mundo de la IA, se puede encontrar a Isaac en el campo de golf, disfrutando de un partido de fútbol o caminando por senderos con su leal compañero canino, Barry.