ADHD: cómo curar la convergencia prematura de los agentes de código con razonamiento divergente paralelo

Dale a un agente un problema abierto y tiene un defecto predecible: se queda con el primer plan que parece plausible y sigue escribiendo por ese único camino. El README tiene un ejemplo real. Un CLI llama a un LLM y a veces se cuelga 90 segundos, y se le pide al agente diseñar una estrategia de retry y timeout. Un agente de un disparo da una respuesta muy estándar: timeout de primer token a 15 segundos, timeout entre tokens a 30 segundos, tope absoluto a 90 segundos, más un retry automático, citando el capítulo 22 del libro de Google SRE. Nada que objetar, pero ni una sola vez pregunta si se eligió el modelo equivocado para este problema, donde la llamada lenta no debería reintentarse en absoluto, sino relanzarse contra un modelo más rápido.

Esa es la brecha que ADHD viene a llenar. Es el paquete npm adhd-agent, con licencia MIT, construido sobre el Agent SDK de Claude y Codex. Abre un problema en paralelo a través de varios frames cognitivos aislados en decenas de ideas, y luego usa una sola llamada critic separada para puntuar, agrupar, podar las trampas y profundizar las mejores. En esta serie sobre LLM locales juega un papel inusual: no resuelve «dónde corre tu modelo», resuelve «si tu agente piensa lo bastante amplio en un punto de decisión clave».

La conclusión primero: cura la convergencia prematura

La convergencia prematura (premature convergence) es un problema estructural de los modelos autorregresivos. El modelo genera token a token, y cada nuevo token va arrastrado por lo que ya ha escrito. Por eso su primer plan suele ser el más típico, el más de manual de los datos de entrenamiento. Esa respuesta suele ser correcta, pero suele ser poco original y, peor, a menudo es una trampa que parece correcta precisamente porque resulta familiar.

¿Cuándo te muerde esto de verdad? En decisiones de arquitectura como capas de almacenamiento, sharding, modelos de auth y topología de colas; al nombrar funciones, productos y variables de entorno; y ante un bug difuso sin causa raíz clara, donde primero hay que listar unas cuantas clases de hipótesis. Lo que comparten es que no hay respuesta estándar, y perderse la opción no obvia pero viable puede costar una reescritura meses después.

Al revés, todo lo que tiene respuesta clara no debería usarlo. Buscar cómo llamar a una API, arreglar un bug cuya causa ya encontraste, cualquier cosa a una búsqueda de distancia: aquí desperdicia dinero y tiempo. Una prueba en una línea: lo que un junior resolvería con Google, deja que lo responda la baseline; el momento en que un senior se pararía a decir «esto tengo que pensarlo de otra manera un minuto» es cuando ADHD se gana su sitio.

El mecanismo: un muro duro entre dos fases

ADHD es un bucle de dos fases con un tabique duro entre las fases. El autor insiste en que mezclar divergencia y revisión es justo lo que destruye la calidad de las ideas, porque el critic estrangula al generador en el sitio.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Divergencia: N ramas que no se ven entre sí

La primera fase elige N frames cognitivos y dispara N llamadas Agent SDK concurrentes, cada una una sesión nueva y sin estado. Cada rama solo ve tres cosas: el problema original, el prompt de perspectiva de un frame y un system prompt que prohíbe evaluar y rankear. La clave: las ramas no pueden verse entre sí. La rama con la perspectiva de «regulador» nunca lee lo que escribió la rama «speedrunner». Sin contexto compartido, el anclaje no se reprime con el prompt; simplemente no existe por construcción.

Foco: una sola llamada critic separada

El critic solo entra en la segunda fase y hace tres cosas. Primero puntúa cada idea de 0 a 10 en novedad, viabilidad y encaje, y etiqueta cada trampa con una razón mecanicista, por ejemplo «shelve no es thread-safe bajo carga multi-escritura» en vez de un vago «esto es arriesgado». Luego agrupa por ángulo subyacente en lugar de por palabras clave de superficie, para que veas la forma de todo el espacio de diseño. Por último profundiza el top-K, 3 por defecto, con un boceto, el riesgo de carga, el primer paso concreto y de 3 a 5 ideas hijas.

Aquí hay una decisión de diseño fácil de pasar por alto: la separación entre generador y critic es mecánica, hecha de dos llamadas API distintas con dos system prompts opuestos, no una promesa a la misma sesión de «primero diverge, luego converge». La llamada de una rama aislada se ve más o menos así:

const branches = await Promise.all(
  frames.map(frame => withSemaphore(concurrency, () => callLLM({
    systemPrompt: `${frame.vantage}\n\nFORBIDDEN: evaluation, ranking, hedging. JSON array out.`,
    userPrompt:   `${problem}\n\n${context ?? ""}`,
  })))
);

El coste de tokens crece linealmente con el número de ramas, no de forma cuadrática, porque las ramas posteriores nunca releen lo que escribieron las anteriores. La concurrencia la gobierna un semáforo, 4 por defecto.

Lo que obtienes de una ejecución no es un muro de texto, sino un resultado estructurado: el conjunto completo de ideas agrupadas, una lista corta de 2 a 4 candidatos, una opción «no obvia pero viable» señalada de forma explícita, una lista de trampas con una razón para cada una, las ramas profundizadas y una provocación comodín. De vuelta al problema del retry, el disparo único solo daba el híbrido de manual; la opción que ADHD sacó de entre más de 30 ideas fue «un botón que se calienta cuanto más esperas, un clic cancela y reenvía a un modelo más rápido de la familia Haiku», a la vez que marcó temprano ideas que suenan divertidas pero son trampas, como «emitir los tokens en orden inverso» y «cobrar por paciencia», antes de que costaran tiempo de ingeniería.

En qué se diferencia de Chain-of-Thought y Tree-of-Thought

Estos tres son los más fáciles de confundir, pero son estructuralmente distintos.

Tres diferencias de carga merecen destacarse. Primera, es aislamiento, no búsqueda. Las ramas de CoT y ToT comparten una ventana de contexto, así que para el paso cuatro el modelo está anclado en sus primeros tres pasos; las ramas de ADHD no pueden verse durante la divergencia, así que el anclaje se elimina por construcción. Segunda, varía el frame, no el siguiente paso. Las ramas de ToT suelen variar el siguiente movimiento (prueba este número, prueba aquel), mientras que ADHD varía la perspectiva sobre todo el problema, pidiéndole en efecto al modelo «replantea esto como un problema de hardware», lo que produce ideas estructuralmente distintas en vez de ajustes cercanos. Tercera, la separación generador-critic es mecánica en vez de prometida.

Una aclaración: ADHD es en sí una variante de Tree-of-Thought, y la fase de profundización sí despliega nodos top-K. Lo nuevo es que la ramificación la guían frames y que la separación de la revisión descansa en dos llamadas de verdad distintas.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Qué es un frame: cambiar la perspectiva sobre todo el problema

Un frame no es role-play. Es un «operador de perspectiva», un system prompt que replantea todo el problema desde una posición cognitiva concreta. A diferencia de la investigación sobre prompts de persona con su «eres un ingeniero de 34 años llamado Alex», un frame no hace que el modelo interprete un personaje; lo empuja a un rincón de pensamiento al que no derivaría por sí solo.

El proyecto trae 15 frames, y con codeMode activado (por defecto) se inclina hacia perspectivas de ingeniería. Unos cuantos concretos: el ingeniero de hardware piensa en latencia, disposición de memoria y restricciones físicas; el on-call de las 3 de la madrugada piensa «qué diseño evitaría que me despierten»; el frame de «quitar la suposición de carga» pregunta «qué es posible si el framework, la base de datos y la red ya no están». Cada ejecución elige frames de forma determinista según una seed y siempre reserva un wild slot, para que la divergencia se mantenga un poco rara.

Unos cuantos frames de varios dominios son especialmente buenos para sacar ideas trasplantables: la biología recurre al sistema inmune, la plasticidad neuronal y la señalización celular; la logística piensa en colas, lotes, entrega justo a tiempo y radial; el diseño de juegos piensa en bucles, recompensas, fricción, puntos de guardado y trucos de speedrun. La respuesta de verdad buena a un problema abierto suele vivir fuera del manual de un solo dominio y hay que trasplantarla de otra parte, que es justo la razón de ser de los frames de varios dominios.

Escribir tu propio frame cuesta unas 5 líneas de código. Un buen frame cumple al menos dos de tres requisitos: un vocabulario que ningún otro frame use, una postura distinta de las demás (adversaria, constructiva, ingenua, maximalista) y una distorsión reproducible que saque ideas que los demás frames pierden. Solo renombrar el dominio diciendo lo mismo no pasa.

Cuándo usarlo y cuándo no

Trátalo como una herramienta de punto de decisión, no de cada pulsación. La tabla de abajo se puede aplicar directamente.

Ten claro el coste. Una ejecución por defecto son unas 10 llamadas LLM: 5 llamadas de divergencia por defecto, más 1 de puntuación, 1 de agrupación y 3 de profundización, que suman alrededor de 5 a 10 veces un disparo único, con 30 a 90 segundos de tiempo real. El encuadre del autor es práctico: gastar alrededor de 0,30 dólares para ampliar una decisión de arquitectura de 50.000 dólares, no ejecutarlo en cada pulsación, ejecutarlo en los puntos de decisión. Una salvedad honesta: dentro de una sesión de Claude Code que carga un CLAUDE.md grande y contexto de herramientas, cada rama recarga ese sustrato base, así que el coste real de tokens se acerca más a «ramas por base más rama», mayor que el coste algorítmico puro.

Cómo instalarlo y activarlo

Instalar es un comando que detecta automáticamente tu agente entre Claude Code, Cursor, Antigravity, Codex, Cline, Gemini CLI, Windsurf y unos 50 más.

🔥 ¡No pierdas meses en productos sin demanda! Valida los puntos fuertes de tu SaaS con Adsterra y poco presupuesto ➡️

Probar ahora →Anuncio

npx skills add UditAkhourii/adhd

Una vez instalado, actívalo de forma explícita con /adhd "tu problema", o deja que se active automáticamente en intenciones de ideación. Codex tiene su propia ruta de descubrimiento; cuando el comando universal no se registra, fuerza el destino:

npx skills add UditAkhourii/adhd -a codex -g

También puedes copiar SKILL.md a mano en el directorio de skills de Codex, ~/.codex/skills/adhd/; tras reiniciar, /adhd "design a rate limiter" pasa por este skill. También existen los usos de CLI y de biblioteca: npm install -g adhd-agent para la CLI, npm install adhd-agent para usarlo como biblioteca.

Antes de instalar cualquier skill de terceros, lee su SKILL.md para ver qué le pide al agente, sobre todo si llama a comandos externos. La guía práctica de revisión de seguridad de skills de OpenClaw es una referencia útil aquí; dedicar 5 minutos a los límites de permisos sale más a cuenta que arreglarlo después.

Sobre los modelos locales, con franqueza: ADHD está construido sobre el Agent SDK y usa por defecto modelos de la familia Claude, así que no es una herramienta local lista para usar. Conectar un modelo local, por ejemplo servido por Ollama, implica escribir tú mismo un adaptador en la capa de llamada, y el proyecto no promete que ese camino sea fluido. Su sitio en esta serie sobre LLM locales tiene que ver con su forma de pensar en la capa de razonamiento de agentes, no con la idea de que puedas dárselo tal cual a un modelo local pequeño.

Conclusión

Trata a ADHD como una herramienta que sacas en un punto de decisión, no como algo que se apodera de todo tu flujo de trabajo. Su valor no es «pensar más», sino «pensar distinto», más una pasada de revisión separada que señala las trampas. Ejecútalo una vez en una decisión de arquitectura para la que ya tienes respuesta, compara la opción no obvia que devuelve con tu propio plan, y luego decide si lo conectas a tu bucle de agente.

Para seguir leyendo, mira el panorama de herramientas de programación con IA 2026 para ubicar su lugar en el mapa de herramientas, o el análisis de la arquitectura de DeepAgents para entender cómo los subagentes y las herramientas de planificación organizan el razonamiento.