Cómo usar los flujos de trabajo dinámicos de Claude para investigación profunda

Durante estos tres años, ya no puedo vivir sin usar IA para asistirme en la investigación del sector, y he construido una serie de habilidades y sistemas de apoyo para resolver la selección, síntesis, conexión, verificación y consolidación de la información.

Hasta que experimenté profundamente este semana el flujo de trabajo dinámico de Claude Code, entendí el verdadero significado de la frase: "No se debe oponerse a la gran era".

Vuelve a reflexionar: ¿qué tipo de investigación profunda debe realizar el ser humano en la era de la IA, y cómo construir una relación de colaboración y complementariedad con la IA?

Realizar investigación técnica es en realidad algo lleno de trampas (tanto para personas como para IA), ya que desde el inicio de la investigación se reciben una gran cantidad de información, las opiniones se multiplican y las conclusiones se vuelven cada vez más borrosas. Por lo tanto, siempre debes recordar volver al objetivo original.

Esto ha sido siempre una debilidad de la IA, ya que, desde la perspectiva de la atención y la asociación, tiende a quedar más atrapada por la cantidad de información actual y tiene asociaciones interdisciplinarias verdaderamente valiosas muy débiles.

The strength of AI lies in its execution, as it can systematically search, categorize, and summarize in layers, completely avoiding the loss of details.

Aunque no he publicado mucho en mi cuenta de WeChat en los últimos seis meses, he estado siguiendo y estudiando exhaustivamente todos los campos principales de la industria, y lo que sustenta esta entrada y salida es un sistema propio de investigación profunda.

Pero ante el lanzamiento la semana pasada de la función Dynamic Workflows en Claude Code, quiero ponerme a prueba para ver si su capacidad predeterminada puede superar completamente la mía.

Los flujos de trabajo dinámicos: su idea central es que, antes de ejecutar una tarea, la IA diseñe automáticamente qué flujo de trabajo se debe utilizar para completarla, y luego inicie la ejecución.

Esto difiere fundamentalmente del "modo de planificación" y la "habilidad" que usábamos antes. El modo de planificación divide las tareas en partes más pequeñas, pero no necesariamente se ajusta a un flujo de trabajo razonable; solo con la organización de tus prompts es posible añadir métricas de validación (esto es crucial para la investigación). De manera similar, solo tendrás la capacidad de predefinir ciertas reglas de harness cuando tengas prompts.

Pero el flujo de trabajo dinámico integrará automáticamente lógica de aprobación, convergencia de resultados y validación adversarial.

La forma de activarlo es sencilla: simplemente usa /deep-research en CC y proporciona algunas plantillas de investigación y materiales de entrada. Si deseas utilizar por separado la capacidad de flujos de trabajo dinámicos, utiliza el prompt o di directamente ultracode. Ten en cuenta antes de usarlo que el consumo de tokens es aproximadamente decenas de veces mayor que el normal.

En la base del flujo de trabajo dinámico se encuentran los seis patrones de programación principales resumidos por el equipo oficial, lo que explica por qué es más potente que las conversaciones/agentes/habilidades convencionales.

En realidad, detrás de estos seis modos solo hay dos problemas fundamentales: ¿cómo dividir la tarea? ¿y cómo combinar los resultados? Separarlos en seis es esencialmente una combinación de estos dos aspectos.

3.1 Modo de enrutamiento (Clasificar y actuar)

Primero, un agente identifica el tipo de tarea, luego la asigna al agente especializado más adecuado para realizarla. La lógica central es la selección de enrutamiento, no la ejecución en paralelo ni iterativa. Una tarea sigue solo una ruta, y las demás rutas no se ejecutan en absoluto.

Por ejemplo, puedo tener primero tres roles de subagentes preestablecidos: un agente de análisis que verifica datos estrictamente, un agente de salida experto en redacción y un agente de desafío especializado en encontrar vulnerabilidades. La capa de enrutamiento determina qué subtarea se asigna a quién, en lugar de que un solo agente lo haga todo.

El valor de este modelo radica en su precisión y eficiencia: las instrucciones de cada agente pueden ser altamente independientes, sin interferencia de otros objetivos, permitiendo una exploración con profundidad vertical. El consumo de tokens es mínimo y la velocidad de respuesta es la más rápida. Los límites de responsabilidad son muy claros.

Las desventajas también son significativas, con capacidad limitada para manejar tareas con fronteras ambiguas (por ejemplo, "un problema que es tanto técnico como de cuenta").

3.2 División y combinación (Fan-out & Merge)

También es el modelo que uso con más frecuencia; la lógica central es paralelismo + combinación. Se divide la tarea en N subtareas independientes que se ejecutan simultáneamente, y una vez que todas terminan, se combinan de forma unificada.

La ventaja radica en la velocidad y la aislación. El tiempo total es aproximadamente igual al del subproceso más lento, no a la suma de todos los subprocesos. Cada subproceso tiene un contexto independiente, sin interferencias mutuas y sin que el ruido de un subproceso contamine a los demás.

La debilidad es que el costo del token es N veces serial, y la capa de síntesis también presenta dificultades: cómo fusionar salidas con estructuras no consistentes en N vías es un desafío de diseño. Una división inadecuada de las subtareas puede provocar omisiones o superposiciones repetidas.

3.3 Verificación adversarial

La lógica central consiste en verificar: para la misma conclusión, varios agentes deben desafiarla desde una perspectiva de refutación, y solo se aprueba si obtiene la mayoría de los votos.

La ventaja radica en que, al no conocer el Verifier el razonamiento del Worker y solo evaluar el resultado, se elimina estructuralmente el sesgo de autoevaluación presente al "pedirle al modelo que revise su propio código".

Este modelo resolvió un problema que me ha preocupado durante mucho tiempo: a menudo hablamos con la IA de manera coloquial, pero la IA tiende a responder según tus expectativas, lo que facilita el sesgo de confirmación. Al forzar la validación contraria, se obliga a la IA a buscar contraejemplos y a verificar basándose en datos y experimentos, en lugar de adaptarse a tus ideas.

Sin embargo, al verificar esto, si emite un juicio erróneo, desviará al Worker para que se ajuste al Verifier. Por lo tanto, es preferible basarse en hechos reproducibles, no en opiniones.

Dicho en broma, si le pides a una IA que encuentre problemas, podrá encontrarlos de forma infinita, por lo que debes limitar el ámbito en el que busca problemas.

3.4 Generar y filtrar

La lógica central es divergir y luego converger. Primero, generar intencionadamente una excesiva cantidad de candidatos, y luego filtrarlos mediante una rúbrica hasta quedarse con lo esencial, conservando únicamente los resultados de alta confianza para la salida.

En lugar de dejar que un agente genere una respuesta "aceptable", es mejor que genere diez y luego filtrarlas con una capa de validación. La ventaja radica en la diversidad. Múltiples generadores pueden emplear distintas estrategias y prompts para producir soluciones que resultan difíciles de prever para los humanos, y el paso de filtrado asegura que la calidad de la salida final sea altamente concentrada.

La debilidad es que la calidad del rubric de Filter determina directamente el resultado final; un diseño erróneo del rubric equivale a que todo el proceso quede inutilizado.

Los escenarios adecuados son aquellos en los que no se conoce la respuesta correcta de antemano, se necesita elegir entre varias posibilidades y se requiere diversidad explícita.

Solo son superficialmente similares a Fanout-And-Synthesize: ambos son "multiplexado paralelo → salida única", los más fáciles de confundir.

La diferencia clave radica en la intención: cada rama de Fanout procesa una parte diferente de la tarea, y los resultados son complementarios, con aportes de todas las ramas al fusionarlos; cada rama de Generate-And-Filter procesa la misma tarea, y los resultados son competitivos, con la mayoría descartados al fusionarlos. La primera es un "rompecabezas", la segunda es un "concurso de belleza".

3.5 Modo torneo (Tournament)

La lógica central es la competencia y la eliminación. N agentes realizan independientemente la misma tarea, y mediante comparaciones por pares se eliminan por rondas hasta seleccionar la mejor solución.

Antes lo hacía manualmente: ejecutar dos o tres versiones del mismo cambio de código y luego hacer que la IA comparara cuál era mejor. Ahora se puede integrar directamente en el flujo de trabajo.

La ventaja radica en la evaluación de la estabilidad. Las comparaciones por pares ("¿Cuál es mejor, A o B?") son mucho más estables que las puntuaciones absolutas ("Puntúa A"), ya que eliminan el problema de la deriva en los criterios de evaluación. Los resultados, tras múltiples rondas de competencia, tienen una alta confiabilidad para el ganador final.

También es superficialmente similar a Generate-And-Filter: ambos seleccionan la mejor opción entre múltiples candidatos. La diferencia clave radica en el mecanismo de selección: Tournament utiliza un juicio por pares para comparar candidatos dos a dos, es decir, "hacer que los candidatos compitan entre sí". Es más confiable cuando la rúbrica es difícil de cuantificar y el juicio es inherentemente relativo.

3.6 Modo de bucle (Loop)

La lógica central es la iteración adaptativa: intentar constantemente, recopilar información de errores al encontrarse con obstáculos, complementar el contexto y volver a intentarlo hasta cumplir con los criterios de aceptación.

En esencia, se trata de contrarrestar la aleatoriedad de la IA: intenta varias veces y eventualmente lograrás un mejor resultado. Pero un enfoque más maduro es combinarlo con validación adversarial, para que cada iteración se realice con más información, en lugar de depender únicamente del azar.

La ventaja radica en la capacidad para manejar tareas con esfuerzo desconocido. Las otras cinco modalidades asumen que los límites de la tarea son determinados; Loop Until Done es la única que puede manejar el caso de "no saber cuántas rondas se deben realizar".

La debilidad es el riesgo potencial de pérdida de control: un mal diseño de las condiciones de parada puede provocar un bucle infinito. Cada ronda del agente es un contexto nuevo y no puede acumular estado entre rondas (a menos que se escriba explícitamente en un archivo).

Antes de que saliera el flujo de trabajo dinámico, diseñé específicamente mi propia deep-research. La lógica de mis habilidades era más o menos así:

1. Solo proporciona una información simple (por ejemplo, un proyecto ha lanzado una nueva función).
2. Haz que la IA busque toda la información relevante: documentación oficial, código fuente, opinión del mercado
3. Compactar la información en un resumen significativo
4. Varios agentes realizan análisis de contrarresto y generan un informe
5. Deduplicación automática, ya que la tasa de repetición del contenido de múltiples agentes es muy alta

Lo he estado usando durante un tiempo y me parece bastante útil. Pero tiene un defecto fundamental: falta de convergencia orientada a objetivos.

Y muchas veces, incluso con el paso cinco de eliminación de duplicados, a menudo se eliminan información valiosa; si no se realiza la eliminación de duplicados, es muy fácil que Skill te proporcione un artículo de diez mil palabras con toda la información, pero sin decirte directamente: "¿Qué tiene que ver esto contigo? ¿Qué deberías hacer?".

Sin embargo, la investigación está al servicio de la "toma de decisiones", por eso muchos skill se quedan solo en la investigación, alcanzando 80 puntos, pero faltan los 20 puntos más cruciales.

Por lo tanto, después de completar inicialmente la investigación, la IA aún necesita realizar diez iteraciones adicionales de pensamiento y diálogo para llegar a una conclusión satisfactoria y bien considerada.

¿Qué más hizo el flujo de trabajo de actualizaciones oficiales?

A través de los experimentos con varias tareas de investigación complejas esta semana, descubrí que el flujo de trabajo de investigación profunda incorporado en Claude Code (nótese que no se trata solo de una habilidad, sino de un módulo compilado e integrado en cc), en comparación con mis propias habilidades, incluye varios componentes clave:

• Capa de desglose de preguntas: No comienza directamente la búsqueda, sino que primero hace preguntas para descomponer mi consulta en múltiples subpreguntas: ¿Qué es lo que realmente quieres entender? ¿Cómo te afecta esto? ¿Qué dimensiones merecen un análisis más profundo? Antes, yo saltaba este paso.
• Evaluación de credibilidad: Evalúe la falsabilidad de cada información, similar a la puntuación de autoridad en SEO tradicional: ¿es confiable la fuente? ¿Cuántas veces se ha citado? Este es un paso que nunca antes consideré agregar.
• Eliminación cruzada en lugar de fusión promedio: Anteriormente, yo promediaba todas las conclusiones, por lo que el documento era muy grande. El flujo de trabajo dinámico realiza una votación múltiple entre agentes para cada conclusión y elimina las que no obtienen suficientes votos, en lugar de fusionarlas simplemente.
• La salida orientada a objetivos: el informe final no es una acumulación de información, sino un juicio y propuestas de solución basados en tu objetivo original. La clave para lograr esto radica en su capacidad para coordinar las funciones preestablecidas de múltiples subagentes. Anteriormente, mis habilidades solían carecer de orientación hacia el objetivo final porque, tras una gran cantidad de información, disminuía el peso de las instrucciones.

¿Qué problemas resuelven estos mecanismos?

Los problemas típicos que aborda la IA en tareas largas:

Deriva de objetivo: al inicio de la tarea, el estado es bueno, pero en el medio ya no se sabe qué se está haciendo, y al final se recupera el ritmo nuevamente — similar a cómo los humanos se distraen en clase. Cuanto más larga sea la tarea, más notable se vuelve.

Detención prematura: al correr y encontrarse con dificultades, la IA cree que "ha terminado" y se detiene, cuando en realidad no ha cumplido los criterios de aceptación.

Contaminación de contexto: realizar tareas complejas con un solo agente comprime el espacio de ejecución posterior debido a la gran cantidad de prompts previos. Una mejor aproximación es limitar los prompts previos a unos pocos KB y distribuir el contexto entre múltiples agentes.

El sesgo de salida: la IA tiende a responder según tus expectativas; hacer preguntas coloquiales activa más fácilmente este problema.

El flujo de trabajo dinámico resuelve estos cuatro problemas de manera estructurada: incorpora automáticamente métricas de validación para evitar la detención prematura; aísla contextos en paralelo; contrarresta la validación para compensar el sesgo en las salidas; y descompone los problemas con restricciones progresivas, obligando a la IA a comprender primero el objetivo antes de actuar.

Finalmente, como investigador con años de experiencia, me maravillo ante este nuevo mecanismo de CC, cuyos seis modos integrados — selección de ruta, división y fusión, validación adversarial, generación y filtrado, competencia por trofeos, bucle Loop — cubren la mayoría de las necesidades de programación para tareas de investigación complejas.

Ya no necesito diseñar manualmente la programación de agentes ni realizar yo mismo la deduplicación y la validación cruzada; todo esto está integrado en el flujo de trabajo.

Y es especialmente adecuado para pensar en la exploración de preguntas abiertas con escasa información, ya que su programación natural de múltiples agentes y la descomposición de objetivos de tarea elevan aún más su versatilidad. De hecho, ya hace tres años, la IA lograba un excelente desempeño en problemas pequeños y muy claros con restricciones múltiples, pero el verdadero cambio cualitativo de la IA radica en su versatilidad: esto es lo que distingue a sus competidores, al pasar de simples códigos a convertirse realmente en agentes, de resolver de forma fija un solo problema a adaptarse a cualquier problema.

Por lo tanto, los Dynamic Workflows no son "una sola conversación más inteligente", sino que estructuran el propio proceso de investigación.

Antes necesitaba realizar entre diez y quince conversaciones independientes para la investigación, ahora se ha reducido a 3-4. Aunque el consumo de tokens correspondiente ha aumentado decenas de veces.

¿Por qué aún se necesitan 3-4 veces más? Creo que la causa raíz radica en las diferencias de estos requisitos.

En primer lugar, la rigurosidad del mecanismo de verificación; yo me enfoco principalmente en investigar nuevas tecnologías en la blockchain, y muchas veces la documentación oficial está desactualizada, existiendo códigos abiertos, transacciones en la cadena y otros datos más valiosos como referencia. Actualmente, la IA sigue por defecto la documentación oficial en lugar de basarse en la verificación factual.

En segundo lugar, está el pensamiento profundo completamente interdisciplinario. Aunque esto puede abordarse en cierta medida mediante flujos de trabajo preestablecidos (definiendo previamente varios subAgentes en diferentes dimensiones) para analizar el mismo problema, lo que mejor hace la IA son los modelos de pensamiento convencionales; resulta un poco deficiente frente a ideas muy nuevas, profundas y que carecen de base empírica.

Tercero, el diseño y la validación de la solución; el valor de la solución no radica en proponerla, sino en validarla y respaldarla, basándose en la evaluación de los mecanismos, inversiones y costos existentes. Si se entrena bien la IA, ciertamente se puede lograr un mejor resultado, pero esto entra en conflicto con la universalidad.

Por último, la máxima concentración de información requiere comprender el nivel de conocimiento de la audiencia: algunos no tienen ninguna base y necesitan una explicación con una imagen humanizada, mientras que otros necesitan solo una frase que los conmueva.