1.
Durante la mayor parte de 2024 y 2025, la respuesta predeterminada fue simple: asignar la tarea a un agente, utilizar la ventana de contexto más grande disponible y esperar. A veces funcionó. A menudo, el modelo perdía silenciosamente el hilo a medio camino.
Anthropic describió el problema directamente: las tareas de largo plazo requieren que los agentes se mantengan coherentes en muchos pasos, a menudo más allá de lo que una ventana de contexto puede soportar de manera confiable. Las ventanas más grandes ayudaron, pero no solucionaron el problema.
Anthropic ya había enviado herramientas para ayudar. Los subagentes permiten que el agente principal delegue tareas secundarias a trabajadores aislados, cada uno con su propio contexto nuevo, recopilando resúmenes en la conversación principal. Skills empaquetó flujos de trabajo repetibles en archivos Markdown, una receta que Claude podría seguir bajo demanda. Los equipos de agentes fueron aún más lejos: múltiples sesiones de Claude independientes, cada una con su propia ventana de contexto, coordinándose a través de una lista de tareas compartida y enviándose mensajes entre sí directamente.
Todo esto fue un verdadero progreso. Pero cada herramienta todavía tenía el mismo techo estructural.
Con los subagentes, la sesión orquestadora de Claude todavía mantiene el plan. Cada resultado que proviene de un trabajador llega a la ventana de contexto de la conversación principal. Con subagentes, habilidades y equipos de agentes, Claude es el orquestador: decide paso a paso qué generar o asignar a continuación, y todos los resultados se acumulan en el contexto. Esto significa que el contexto orquestador se expande a medida que aumenta el número de agentes, llegando eventualmente a sus límites. Como resultado, la orquestación se degrada y aparecen los mismos modos de falla.
Anthropic identificó tres modos de falla que aparecen consistentemente cuando una ventana de contexto, ya sea que pertenezca a un solo agente o a un líder que orquesta un equipo pequeño, es responsable de una tarea demasiado grande para realizar un seguimiento limpio. Ahí es donde aparecen los tres modos de falla comunes (Figura 1).
Primero, la pereza agente: inicia la tarea pero no la termina por completo. Puede detenerse antes de tiempo, omitir algunos archivos o asumir que el trabajo restante es bastante similar. Luego dice con confianza que toda la tarea está hecha. Esto es como si una persona revisara solo una parte de una hoja de cálculo larga pero marcara toda la hoja de cálculo como revisada. En segundo lugar, el sesgo de preferencia hacia uno mismo. La IA no es muy estricta a la hora de juzgar su propia producción. Si le pregunta: "¿Seguiste las instrucciones?" a menudo dice que sí, porque tiende a concederse el beneficio de la duda. Puede pasar por alto sus propios errores o sobrevalorar la calidad de su respuesta. En tercer lugar, la deriva de objetivos. Durante una tarea larga, la IA pierde lentamente la noción del objetivo original. Puede que recuerde la tarea principal, pero olvide detalles importantes como “no incluir X”, “no omitir ningún archivo” o “usar sólo este formato”. Cuanto más larga sea la conversación o la tarea, más probable será que se produzca esta deriva.
Estos no son errores. Son lo que sucede cuando el plan es un pensamiento y los pensamientos se degradan.
El costo se volvió difícil de ignorar a principios de 2026, cuando Jarred Sumner, creador de Bun, necesitaba portar, archivo por archivo, alrededor de 750.000 líneas de Zig a Rust. En el pasado, una tarea como esta habría llevado a un equipo meses. El patrón de Sumner era simple: hacer una unidad de trabajo, ejecutar una revisión contradictoria y luego aplicar los cambios. Más tarde llamó a Dynamic Workflows “lo último en tecnología actual para utilizar agentes de manera confiable para completar proyectos medianos y grandes”. El resultado: 750.000 líneas de Rust, el 99,8% del conjunto de pruebas existente pasó y solo 11 días desde el primer compromiso para fusionarse.
La idea clave es que Claude no tiene que tener todo el plan en la cabeza. El flujo de trabajo traslada el plan al código. El script contiene el bucle, las ramas y los resultados intermedios. Claude solo necesita manejar el paso actual y la síntesis final. El plan se convierte en un archivo JavaScript. No se olvida, no se desvía ni se detiene a medio camino y da por terminado el trabajo.
Ese es el problema para el que se crearon los flujos de trabajo dinámicos. Y eso es lo que cubre este artículo.
Al final, comprenderá exactamente dónde los subagentes, las habilidades y los equipos de agentes alcanzan sus límites y por qué, no como una intuición vaga, sino como un argumento estructural que puede aplicar a sus propias tareas. Conocerá los seis patrones de composición que cubren la mayoría de los problemas de flujo de trabajo del mundo real, cómo escribir un mensaje de flujo de trabajo que realmente produzca un arnés útil y cómo evitar los dos errores más costosos que comete la gente al comenzar. También sabrá cuándo un flujo de trabajo es la herramienta equivocada, porque los flujos de trabajo dinámicos consumen sustancialmente más tokens que una sesión estándar, y utilizarlos en la tarea equivocada es su propio tipo de fracaso.
2. Qué es un flujo de trabajo dinámico
Un flujo de trabajo dinámico es como reemplazar a una persona exhausta por un equipo pequeño y concentrado.
En lugar de pedirle a una IA que lleve a cabo todo el proyecto de principio a fin, divide el trabajo en partes limpias. Un agente maneja una tarea. Otro comprueba el resultado. Otro hace avanzar el trabajo. Como resultado, nadie se cansa en el medio y comienza a tomar atajos. Nadie se da una puntuación perfecta sólo porque escribió la respuesta. Y nadie olvida el encargo original, porque cada agente sólo tiene que cumplir una parte clara del trabajo.
El flujo de trabajo dinámico de Claude le ayuda a conseguirlo. Divide el trabajo entre un equipo de Claudes de nuevo contexto. Cada uno maneja una pieza más pequeña, otra capa verifica el trabajo y los resultados se fusionan en una respuesta para usted.
La palabra clave aquí es arnés. Un arnés es el andamiaje que rodea el modelo: la parte que decide cómo se planifica, divide, verifica y ejecuta una tarea. El arnés predeterminado de Claude Code está diseñado principalmente para tareas de codificación. El equipo de Anthropic descubrió que estos arneses dinámicos son "a veces incluso más útiles para trabajos no técnicos". Luego lo crearon en el acto, dándole forma en función de la tarea que le asignaste.
Antes de continuar, conviene separar un flujo de trabajo de algunas otras palabras que a menudo se mezclan. Las herramientas, los agentes, los arneses y los flujos de trabajo a menudo se utilizan como si significaran lo mismo. No es así. La forma más clara de separarlos (tomo prestado este marco de AlphaSignal) es hacer una pregunta: ¿quién tiene el plan? (Figura 2)
Un subagente es un ayudante que el jefe Claude envía para un trabajo específico. El plan aún permanece en el Claude principal. El subagente hace su parte, envía el resultado y ese resultado aparece en su chat. Es principalmente disparar y olvidar. Como muestra la siguiente tabla, un subagente no puede crear sus propios ayudantes ni hablar con otros subagentes. Un equipo de agentes es diferente. Es un grupo de Claudes trabajando codo a codo, coordinándose como pares. El plan no se encuentra dentro de un solo Claude. Vive entre ellos. Pueden enviarse mensajes entre sí, adaptarse a medida que se desarrolla el trabajo y continuar en una tarea compartida más amplia. Es más como darle un proyecto a un equipo pequeño. Un flujo de trabajo dinámico vuelve a ser diferente. Claude escribe un pequeño programa JavaScript para la tarea en sí. En este caso, el plan vive en código. Los agentes hacen su trabajo a un lado, sus resultados se almacenan en variables y solo le llega la respuesta final fusionada.
Un equipo de agentes y un flujo de trabajo dinámico parecen ser parecidos. Sin embargo, son totalmente distintos. Consulte la siguiente tabla para comprobarlo.
Y podrías hacer otra pregunta. ¿Qué es dinámico? ¿Cuáles son las diferencias entre dinámico y estático?
Siempre puedes construir un arnés tú mismo. Puede conectar el SDK del agente o ejecutar claude -p en un bucle y crear un sistema fijo que utilice una y otra vez. Ése es un arnés estático: útil, repetible, pero diseñado de antemano.
Un arnés dinámico es lo contrario. Claude escribe el arnés en el momento, dándole forma a la tarea que le acabas de encomendar. Planifica la estructura, divide el trabajo, ejecuta los agentes, verifica los resultados y luego descarta el arnés cuando el trabajo está terminado, a menos que presione s para guardarlo.
Los arneses estáticos son de uso general; los dinámicos están hechos a medida y desechables.
Claude ahora es capaz de crear flujos de trabajo dinámicos porque Opus 4.8 ahora es lo suficientemente capaz de construir el arnés correcto sobre la marcha; como dijo el equipo de Anthropic, "lo suficientemente inteligente como para escribir un arnés personalizado hecho a medida para su caso de uso".
3. La verdadera prueba
3.1 Patrones que hacen útiles los flujos de trabajo dinámicos
Hay 6 flujos de trabajo que presenta Anthropic e hice algunas pruebas con ellos para mostrarte intuitivamente cómo funcionan. Ellos son:
Distribuya y sintetice: divida el trabajo y luego combínelo. Cada pieza tiene su propio agente y contexto limpio; un sintetizador final los espera a todos antes de combinar los resultados. Verificación contradictoria: para cada hallazgo, genere un agente independiente cuyo único trabajo sea refutarlo. Un escéptico controlando al optimista. Clasificar y actuar: utilice un agente clasificador para ordenar cada elemento primero y luego enrutarlo al controlador adecuado. Una recepción. Generar y filtrar: realizar una lluvia de ideas amplia y luego filtrar según una rúbrica: deduplicar, verificar y conservar solo lo que sobrevive al escrutinio. Torneo: genera N agentes, cada uno de los cuales intenta la misma tarea de manera diferente, luego haz que un agente juez los compare en pares hasta que uno gane. Bueno para el gusto y el nombre. Bucle hasta terminar: para trabajos de tamaño desconocido, siga generando agentes hasta que se cumpla una condición de detención (sin nuevos hallazgos, sin más errores) en lugar de un número fijo de pasadas.
Distribuir y sintetizar es probablemente uno de los patrones más vistos. Una tarea se divide en varios agentes, cada uno con su propio contexto limpio para que no puedan contaminarse entre sí, y luego un paso de síntesis (un paso que espera a todos) fusiona su trabajo en un solo resultado (Figura 3).
Y la verificación adversarial también es otro patrón común (Figura 4).
3.2 Flujo de trabajo dinámico en problemas no técnicos
La forma más rápida de comprender los flujos de trabajo dinámicos es utilizar uno en un problema que no tiene nada que ver con el código.
Así que le di a Claude un sencillo plan de negocios para un modelo de suscripción de restaurante y le pedí que separara la idea desde tres ángulos hostiles a la vez: un inversor reacio al riesgo, un cliente exigente y un competidor establecido. Cada agente trabajó de forma independiente. Luego, un sintetizador final reunió los resultados y arrojó las tres objeciones más fuertes, además de cómo podía responderlas.
Aquí está esa ejecución (Figura 5), acelerada:
Este es el patrón de distribución y síntesis: tres agentes analizan el mismo problema desde diferentes puntos de vista y luego un agente sintetiza los resultados. Todo el recorrido duró unos trece segundos.
Lo importante no era la velocidad. Fue la separación. Como los agentes no compartían la misma ventana de contexto, no se influyeron mutuamente ni suavizaron sus conclusiones. Cada uno regresó con un tipo de visión diferente.
Aquí están las respuestas:
El inversor atacó las matemáticas: la economía es demasiado débil para sobrevivir a la deserción. A 29 dólares al mes y aproximadamente un margen del 40 %, el producto genera sólo unos 11,60 dólares de beneficio bruto por cliente al mes. Con un costo de adquisición de clientes de $35, la empresa necesita que los clientes permanezcan el tiempo suficiente para que el valor de por vida supere claramente el costo de adquisición. Pero las suscripciones de alimentos generalmente enfrentan una pérdida de clientes, y un mes de retención débil puede hundir el modelo. Respuesta: corregir la economía unitaria antes de escalar: aumentar los ingresos por usuario a través de planes anuales o complementos, demostrar una baja rotación de cohortes y modelar LTV a CAC explícitamente. El cliente atacó el valor: el discurso se apoyaba demasiado en ideas como menús rotativos y entrega neutra en carbono. Puede que suenen bien en una terraza, pero puede que no sean lo que más les importa a los clientes a la hora de elegir la cena. La mayoría de los clientes quieren velocidad, flexibilidad y menos toma de decisiones diarias. Respuesta: haga que el valor sea más práctico: lidere con el ahorro de tiempo, la conveniencia y cómo el servicio facilita las comidas entre semana. El competidor atacó el foso: un menú rotativo y una entrega neutra en carbono se pueden copiar rápidamente. Ninguno de los dos genera muchos costos de cambio. Un competidor más grande podría imitar las características superficiales, rebajar el precio o agrupar la oferta en una red de entrega existente. Respuesta: construir un foso más sólido: densidad logística por ciudad, personalización, cambio de créditos o hábitos que hagan que el servicio sea más difícil de reemplazar.
Eso es lo que hizo que el flujo de trabajo fuera útil. No sólo me dio “retroalimentación sobre el plan de negocios”. Me dio tres objeciones diferentes desde tres puntos de presión diferentes: economía, valor para el cliente y defendibilidad. Una sola charla probablemente los habría combinado en una crítica educada y ligeramente útil. El flujo de trabajo agudizó el desacuerdo. Y lo mejor: no escribí ni una línea de código.
3.3 Habilitar flujos de trabajo dinámicos
La configuración es pequeña. Cambias el modelo a Opus 4.8 (lo explicaré más adelante) y activas el flujo de trabajo de tres maneras. La forma confiable es simplemente poner la palabra flujo de trabajo en el mensaje. La otra forma es esforzarse en ultracódigo, lo que activa un razonamiento extra alto y permite a Claude decidir por sí mismo si desea crear un flujo de trabajo. Sin embargo, tenga cuidado con el ultracódigo: cuesta más tokens, así que úselo cuando desee una orquestación automática.
El tercero se puede activar si ya ha tenido un buen flujo de trabajo anteriormente, y se puede activar nuevamente a través de /. Hay dos ubicaciones para guardar: .claude/workflows/ (Proyecto compartido; accesible para todos los que clonaron el repositorio) ~/.claude/workflows/ (Uso personal; accesible para todos los proyectos, pero solo para usted)
La razón por la que Opus 4.8 es importante es que el orquestador tiene el trabajo más duro. No se trata sólo de responder la pregunta. Se trata de decidir cómo dividir la tarea, escribir el guión del flujo de trabajo, asignar trabajo a los subagentes, elegir herramientas, realizar un seguimiento de los resultados y sintetizar el resultado final. Entonces, el patrón es: usar el modelo más inteligente para la orquestación, luego usar modelos más pequeños o más baratos para los agentes trabajadores cuando las subtareas sean más limitadas.
3.4 Probémoslos
3.4.1 Enfoque predeterminado
El objetivo: uso un repositorio de múltiples archivos y le pido a Claude que ejecute flujos de trabajo para auditar este repositorio mediante Fan-out-and-synthesize y verificación Adversarial.
Aviso: audite el repositorio con un flujo de trabajo: distribuya los buscadores y verifique cada hallazgo, sintetice un informe clasificado por gravedad. usar ficha de 200k
Como en la Figura 5, Claude crea un flujo de trabajo con 3 fases: Buscar –> Verificar –> Síntesis; y utiliza 6 buscadores para 6 dimensiones: seguridad, corrección, integridad de los datos, accesibilidad, calidad del código e higiene del repositorio. Como no especificé el aspecto que Claude debe examinar, automáticamente sugiere estos 6.
Comenzó a ejecutar el flujo de trabajo. Para verificar el progreso, use el comando /workflows
Dentro de /workflows (Figura 7), se están ejecutando 6 agentes, y lo malo es que todos son Opus 4.8 y están consumiendo ~50k tokens cada uno. Mi billetera se acabará pronto.
Después de 2 minutos, los buscadores terminaron y encontraron 50 problemas candidatos (Figura 8). Como resultado, se deben ejecutar 50 agentes de verificación en cada problema para verificar si el problema era real o simplemente un falso positivo. Y todos están usando Opus 4.8.
Esto suele ser innecesario. El orquestador se beneficia del modelo más sólido porque tiene que diseñar el flujo de trabajo, dividir la tarea, gestionar los agentes y sintetizar el resultado. Pero muchas tareas de verificación son más limitadas: verificar este tema, inspeccionar la evidencia y decidir si se sostiene. Para ese tipo de trabajo enfocado, un modelo más económico suele ser suficiente.
Por lo tanto, en la siguiente prueba, cambié los agentes trabajadores a Sonnet. El objetivo no era debilitar el flujo de trabajo. Era mantener Opus donde más importaba (orquestación y síntesis) mientras se usaba un modelo más barato para el trabajo de verificación repetida.
3.4.2 Modelo más económico para agentes
Otro intento con Sonnet como agentes y Opus como orquestador y sintetizador.
Aviso: audite el repositorio con un flujo de trabajo: distribuya los buscadores y verifique cada hallazgo, sintetice un informe clasificado por gravedad. use token de 200k. Utilice Sonnet para todos los agentes y Opus como orquestador y sintetizador.
En la Figura 9, Claude proporcionó Sonnet 4.6 a 7 agentes buscadores y tomó 254.000 tokens para encontrar 71 problemas candidatos después de casi 5 minutos y 17 segundos. Sonnet definitivamente tarda más que Opus en ejecutarse.
Puede verificar los detalles de verificación de cada problema en la ventana de flujos de trabajo como en la Figura 10.
El proceso de verificación de 71 emisiones consume aproximadamente casi 1,5 millones de tokens. Cuesta mucho menos que Opus, pero el tiempo de ejecución es significativamente mayor para los agentes buscadores.
Aquí está el resultado del sintetizador (Opus 4.8) en la Figura 11.
Lo importante es que debes leer el informe que produjo, revisarlo y revisarlo antes de poner a Claude a trabajar revisando el código.
El agente buscador aún detecta varios problemas, y los agentes de verificación los validaron como válidos más tarde. Sin embargo, esos problemas son la naturaleza de la aplicación, lo que significa que tienen que ser así, y detectarlos no significa más que crear más trabajo de verificación para nosotros. Por lo tanto, quiero agregar algunas restricciones al flujo de trabajo antes de que se ejecute para que estos problemas no se detecten durante el escaneo.
3.4.3 Revisar el flujo de trabajo antes de ejecutarlo
Aviso: audite el repositorio con un flujo de trabajo: distribuya los buscadores y verifique cada hallazgo, sintetice un informe clasificado por gravedad. use token de 200k. Utilice Sonnet para todos los agentes y Opus como orquestador y sintetizador. Escribe el flujo de trabajo y dame el enlace para acceder y revisarlo antes de ejecutarlo.
Perfecto. Claude me da el script del flujo de trabajo para revisarlo y revisarlo antes de decirle a Claude que lo ejecute (simplemente ejecutando el flujo de trabajo) (Figura 12)
Utilicé una base de código más corta y un mensaje más simple para demostrar los componentes del archivo de flujo de trabajo JavaScript en la Figura 13.
Para mi código base de prueba, aquí está el alcance que quiero revisar:
{ clave: 'corrección', mensaje: `Auditoría para errores de CORRECCIÓN/LÓGICA. Enfoque: selección diaria determinista basada en fechas, comportamiento de reproducción aleatoria, lógica histórica de "últimos 5 usados excluidos" (desactivado por uno, envolvente, aislamiento por guardarropa), cambio de género de guardarropa, filtro de 2/3 piezas, cambio automático de tema por hora (límites de 6 a. m. a 6 p. m.), manejo de claves de almacenamiento local. Seguimiento de casos extremos (armario masculino vacío, todos los conjuntos usados recientemente). Lea app.js y collection.js.`, }, { clave: 'docs-accuracy', mensaje: `Auditar la PRECISIÓN DE LA DOCUMENTACIÓN. Compare las afirmaciones de README.md y docs/*.md con el comportamiento real del código. Enfoque: características descritas que no coinciden con la implementación, claves de almacenamiento local incorrectas, configuración obsoleta, pasos de implementación que no funcionan, recuentos obsoletos ("los 40 conjuntos"). Lea README.md, docs/codebase-summary.md, docs/deployment-guide.md, luego verifique con el código.`, },
Eliminé: comportamiento aleatorio, cambio automático de tema por hora (límites de 6 a. m. a 6 p. m.). Seguimiento de casos extremos (armario masculino vacío, todos los conjuntos usados recientemente) y toda la 'precisión de documentos'. También revisé otros lugares en el archivo js para asegurarme de que se eliminen los puntos anteriores.
También puedes pedirle a Claude que excluya eso, pero esto es simple, así que prefiero hacerlo yo mismo.
Entonces, de 7 aspectos que buscarán los agentes buscadores, se reduce a 6, y un aspecto tiene un alcance menor (Figura 14).
Seis agentes buscadores encontraron 44 problemas candidatos distintos y confirmaron 40 problemas. Todo el proceso, llamado 51 agentes, tomó 9 minutos y 52 segundos y consumió ~1,66 millones de tokens.
3.4.4 Comparar con un único agente en ejecución
Ejecuté el mismo código base con un solo agente en una sola pasada, sin equipo, sin verificación. Encontró 47 problemas (más que los 44 del flujo de trabajo) en un tercio de los tokens. Sin embargo, debido a que no ejecutó la verificación, entre 47, hay los mismos 2 hallazgos incorrectos que los agentes verificadores en el flujo de trabajo habían detectado y eliminado. Muestro las diferencias en el siguiente cuadro para facilitar la comparación (Figura 15).
Si se concentra en la cobertura bruta y no le importa la autoevaluación, el agente único es una opción más económica con una compensación en calidad.
4. Cuándo utilizar el flujo de trabajo
Los flujos de trabajo dinámicos utilizan muchos más tokens que una sesión normal de Claude Code. Esto se debe a que ejecutan varios subagentes en segundo plano y cada uno funciona en su propia ventana de contexto independiente. Por lo tanto, no deberías usarlos para todas las tareas. Si lo hace, podrá completar su plan en tan solo unas horas. El mejor enfoque es utilizarlos sólo cuando la tarea realmente necesite que varios agentes trabajen en paralelo. Algunas señales clave que pueden ayudarle a decidir cuándo vale la pena utilizar un flujo de trabajo se encuentran en la Figura 16.
La primera es que la tarea se puede dividir en partes independientes. Si cada agente depende de la producción de otro agente, en su mayoría terminan esperándose el uno al otro. En ese punto, no tiene mucho valor iniciar un flujo de trabajo, porque se pierde el principal beneficio: el trabajo paralelo. Cuanto menos dependan las tareas unas de otras, más útil será el flujo de trabajo. Obtiene un mejor paralelismo y los resultados llegan más rápido. La segunda señal es si la tarea es lo suficientemente grande como para necesitar más de una ventana de contexto. Los flujos de trabajo ejecutan varios subagentes y cada subagente tiene su propia ventana de contexto nueva. Eso sólo tiene sentido cuando la tarea es lo suficientemente grande como para beneficiarse de estar dividida en partes. De lo contrario, simplemente estarás gastando más tiempo y tokens sin obtener ninguna ganancia real. Esto también es útil porque cada subagente devuelve solo su resultado final. Su razonamiento detallado permanece dentro de su propio archivo de trabajo y no ingresa a la ventana contextual principal a menos que usted lo solicite. Eso mantiene la conversación principal más limpia y deja más espacio para la síntesis final. La siguiente señal es si la tarea necesita verificación. En algunos casos, una respuesta incorrecta sale cara. No querrás avanzar basándose en un hallazgo de seguridad débil, un informe de error falso o un plan de migración riesgoso. Para tareas como esa, puede valer la pena utilizar agentes adicionales para verificar el resultado antes de confiar en él. Pero la verificación no es gratuita. Más agentes significan más tokens y más tiempo. Por lo tanto, la tarea debería merecer ese nivel de verificación. No genere cinco agentes solo porque recientemente escuchó a un director ejecutivo de tecnología de inteligencia artificial decir que más tokens significa más dinero. La última señal es si la tarea es determinista. Un flujo de trabajo utiliza código para llamar a agentes en una estructura fija. Entonces, si la tarea tiene una forma clara y se puede dividir en pasos conocidos, un flujo de trabajo funciona bien. Pero si la tarea necesita que un agente decida qué hacer a continuación durante el tiempo de ejecución, entonces un flujo de trabajo probablemente no sea la herramienta adecuada. Una forma útil de pensar en esto es si la tarea es amplia o profunda. Una tarea amplia se puede dividir en muchas tareas más pequeñas que se ejecutan al mismo tiempo. Ahí es donde brillan los flujos de trabajo. Llaman a varios agentes en paralelo, dejan que cada uno trabaje por su parte y luego reúnen los resultados. Una tarea profunda avanza paso a paso. Cada paso depende de lo que sucedió antes. Para ese tipo de tarea, el comando objetivo suele ser más adecuado. Se necesita una tarea a la vez y sigue avanzando, en lugar de intentar ejecutar muchas cosas en paralelo.
5. ¿Podemos utilizar Dynamic Workflow de forma económica?
Los flujos de trabajo dinámicos son caros, pero quiero probar si el modelo más barato, Haiku, puede ahorrarnos tokens y costes o no. No podemos cambiar el orquestador y el sintetizador; deben ser Opus, eso no es negociable. Por lo tanto, intentemos cambiar los subagentes a Haiku.
Sorprendentemente, el flujo de trabajo finalizó en aproximadamente 7,5 minutos: 37 agentes. Usó 37 agentes y 1,35 millones de tokens. Encontró 23 temas candidatos, que es mucho menos que el Soneto analizado anteriormente, y los 23 sobrevivieron a la verificación.
Pero la cuestión de los costos no fue tan simple como “modelo más barato, flujo de trabajo más barato”. Haiku encontró sólo 23 emisiones con 1,35 millones de tokens. La versión Sonnet encontró 40 problemas con 1,66 millones de tokens. Entonces, aunque Haiku es más barato por token, la eficiencia del token fue peor. Se necesitaban más turnos para hacer el mismo tipo de trabajo analítico, y cada turno adicional significaba releer más contexto. La lección es simple: un modelo más pequeño no es automáticamente más barato en la práctica. Si toma más pasos para pensar en la tarea, puede quemar su ventaja de precio muy rápidamente.
Haiku cuesta aproximadamente un tercio de lo que cuesta Sonnet por token. Sobre el papel, parece una victoria fácil. Pero en esta prueba, Haiku utilizó aproximadamente 1,5 veces más fichas. Esos dos números casi se anulan entre sí. Al final, el despliegue de Haiku tuvo aproximadamente el mismo costo que Sonnet, tal vez alrededor de un 10% más barato y solo un poco más rápido en tiempo real. Por lo tanto, “simplemente dirigir todo al modelo más pequeño” no es una regla confiable. Un modelo más pequeño puede perder su ventaja de precio si necesita más tokens para realizar el trabajo.
Una nota más sobre la calidad, que creo que es bastante importante. Hubo 14 números que aparecieron en ambas versiones. Esto fue bastante sorprendente y sugiere que los agentes en realidad estaban haciendo un trabajo útil cuando estaban aislados unos de otros. Sin embargo, también hubo dos cuestiones en las que las dos versiones no estaban de acuerdo. Sorprendentemente, Haiku tenía razón en ambos, mientras que Sonnet estaba equivocado. Esto no muestra cuál es el mejor modelo, pero es más bien como si el modelo no funcionara de manera 100% consistente como se esperaba. Una de las razones es que le di a Claude un mensaje vago y amplio. Por lo tanto, en cambio, probaré con un aspecto más específico.
Nuevo mensaje: audite el repositorio en términos de vulnerabilidades de seguridad, incluidos secretos, autenticación, inyección, dependencias, manejo de datos, con un flujo de trabajo: distribuya los buscadores y verifique cada hallazgo, sintetice un informe clasificado por gravedad. use token de 200k. Utilice Haiku para todos los agentes y Opus como orquestador y sintetizador. Escribe el flujo de trabajo y dame el enlace para acceder y revisarlo antes de ejecutarlo.
Cómo fue la ejecución de Haiku:
15 agentes, ~572.000 tokens de subagente, ~3,5 minutos de reloj de pared 5 buscadores de Haiku → verificadores adversarios de Haiku → sintetizador de Opus 9 hallazgos sin procesar → 3 confirmados, 6 refutados. Se eliminaron todas las calificaciones "altas".
Y para los agentes de Sonnet:
23 agentes, ~1,3 millones de tokens en ambos pases. ~ 2,51 min 5 buscadores de sonetos → verificadores adversarios de sonetos → sintetizador de Opus 18 hallazgos sin procesar → 13 confirmados, 5 rechazados → deduplicados en 8 temas distintos. Ninguna verificación adversaria crítica/alta sobrevivió.
Un detalle importante: los 3 problemas confirmados en la ejecución de Haiku también se encontraron en la ejecución de Sonnet. Esto es más consistente que la ejecución anterior. Una posible razón es que esta vez el mensaje les dio a los agentes un ángulo específico para investigar, en lugar de pedirles que observaran todo el sistema desde una perspectiva amplia. Eso tiene sentido. El flujo de trabajo utilizó cinco agentes y cada agente se centró solo en un aspecto de la seguridad. Debido a que el alcance era más limitado, los agentes podían profundizar en el mismo tipo de problema en lugar de distribuir su atención entre demasiadas categorías de problemas posibles. Cuando un agente no se ve obligado a priorizar en una amplia superficie, naturalmente gasta más de su presupuesto de razonamiento en el problema específico que se le asignó, y eso conduce a hallazgos más completos y reproducibles.
Por lo tanto, incluso si utiliza flujos de trabajo dinámicos con subagentes aislados, su mensaje debe ser lo más específico posible. Las indicaciones más específicas reducen esa variación y empujan a los agentes a llegar a las mismas conclusiones, que es exactamente lo que se desea cuando la coherencia y la confiabilidad son importantes.
6. Conserva el bueno después de ejecutarlo.
Un flujo de trabajo guardado útil debería parecer la automatización de un proyecto, no la transcripción de una ejecución afortunada. Debe estar lo suficientemente limpio como para que otro compañero de equipo pueda abrirlo y comprender rápidamente: quién es el propietario, qué entradas espera, qué herramientas puede usar, de qué es responsable cada subagente y qué nivel de prueba se requiere antes de que el flujo de trabajo pueda dar por terminada la tarea.
Si el flujo de trabajo funcionó bien y desea reutilizarlo, presione s en el menú del flujo de trabajo para guardarlo en ~/.claude/workflows. También puede mover el script a una habilidad si el objetivo es compartir el método con su equipo y facilitar su reutilización en tareas similares.
Pero no guarde un flujo de trabajo sólo porque la primera ejecución fue exitosa. Una ejecución exitosa sólo demuestra que funcionó una vez. Guárdelo cuando la orquestación en sí sea valiosa: cuando el script sea más fácil de inspeccionar, reutilizar y mejorar que escribir un mensaje normal de Claude Code nuevamente desde cero.
A continuación se presentan algunas sugerencias de indicaciones para su referencia. Añade tus datos cuando quieras utilizar uno de ellos:
Haga una prueba de estrés de un plan: "Tome el plan a continuación y ejecute un flujo de trabajo en el que agentes separados lo desmenucen (un inversionista escéptico, un cliente difícil de complacer, un competidor actual), cada uno independiente. Luego sintetice las tres objeciones más agudas y la respuesta más sólida para cada una".
Auditar un repositorio: "Ejecute un flujo de trabajo para auditar este repositorio. Distribuya agentes en busca de errores lógicos, rutas inseguras, autenticación débil, autorización faltante, secretos expuestos, dependencias riesgosas y fugas de datos. Para cada hallazgo, genere un agente independiente para verificarlo de forma adversaria; intente demostrar que no es real. Sintetice un informe clasificado por gravedad con rutas de archivos y correcciones. Utilice 200.000 tokens".
Hágalo barato: "Constrúyalo para que los agentes buscadores se ejecuten en el modelo: 'haiku' mientras el orquestador permanece en Opus 4.8 y hace la síntesis final. Informe los tokens y la hora del reloj de pared".
Reproduzca una prueba inestable: "Esta prueba falla quizás en 1 de cada 50 ejecuciones. Configure un flujo de trabajo para reproducirla: forme teorías y pruébelas de manera adversa en árboles de trabajo. /objetivo no se detenga hasta que una teoría funcione".
Verificar un borrador: "Revise este borrador y utilice un flujo de trabajo para verificar cada afirmación técnica con respecto al código base y las fuentes. No quiero enviar nada incorrecto".
Clasificar por prioridad real (torneo): "Tengo una lista de hallazgos/opciones. Utilice un flujo de trabajo para clasificarlos por [explotación real/impacto/lo que importa], pero en lugar de puntuar cada uno, organice un torneo por parejas y clasifique según quién gana. Luego muéstreme los tres primeros y por qué".
Causa raíz de un heisenbug: "Este error es intermitente y la causa obvia parece incorrecta. Utilice un flujo de trabajo: divida la investigación por evidencia (un agente en los síntomas, uno en el código, otro en los datos/registros) y luego haga que agentes separados intenten refutar cada teoría y sinteticen la causa que sobrevive".
Clasifique un trabajo pendiente de forma segura: "Utilice un flujo de trabajo para clasificar este trabajo pendiente: clasifique cada elemento (arreglar ahora / escalar / necesita una decisión), deduplicar en familias y enrutar. Todo lo que lea entradas que no sean de confianza debe ser de solo lectura; manténgalo separado de cualquier cosa que proponga cambios".
Ruta por forma de tarea: "Utilice un flujo de trabajo con un clasificador que analice cada tarea y la enrute al modelo más barato y capaz (modelos pequeños para trabajo mecánico, Opus para el razonamiento ambiguo y crítico para la seguridad) y luego ejecute cada una en el modelo elegido".
Verifique las reglas de la casa: "Utilice un flujo de trabajo para verificar este código con nuestras reglas en CLAUDE.md: un verificador por regla, más un escéptico que busca falsos positivos. Me importa más no llorar que atrapar cada liendre".
Fuentes
Thariq Shihipar y Sid Bidasaria (Anthropic), “Un arnés para cada tarea: flujos de trabajo dinámicos en Claude Code”: el por qué, los patrones, los consejos, guardar/compartir. Factory.ai, "El problema de la ventana de contexto: escalar agentes más allá de los límites de los tokens". Ingeniería en Anthropic, “Ingeniería de contexto efectiva para agentes de IA”. Informe técnico de Chroma, “Context Rot: How Increasing Input Tokens Impacts LLM Performance” Anthropic, “Construcción de agentes efectivos”: antecedentes sobre los patrones de orquestación subyacentes. Anthropic, "Presentación de flujos de trabajo dinámicos en Claude Code".