El patrón Reflexion: agentes que aprenden de sus errores

El patrón Reflexion es una arquitectura de agentes en la que un agente LLM reflexiona de forma sistemática sobre sus propios intentos anteriores y mejora gracias a ello. En lugar de dar una única respuesta, el agente pasa por varios intentos: un Actor genera una solución, un Evaluator la evalúa y un modelo de Self-Reflection redacta una crítica verbal a partir de la evaluación y del historial. Esa crítica va a parar a un búfer de memoria y guía el siguiente intento. Lo llamativo: no se modifica ningún peso del modelo. La mejora es puramente lingüística.

El procedimiento se remonta al artículo de Shinn, Cassano, Berman, Gopinath, Narasimhan y Yao: Reflexion: Language Agents with Verbal Reinforcement Learning (arXiv:2303.11366, marzo de 2023, NeurIPS 2023). Fue la primera demostración ampliamente citada de que el análisis de errores que un LLM verbaliza por sí mismo es una señal de aprendizaje más potente para la mejora in-context que una simple recompensa numérica.

Lo esencial en tres frases

• Qué es: un bucle de Actor, Evaluator y Self-Reflection con memoria episódica. El agente aprende de sus errores in-context a lo largo de varios intentos, sin fine-tuning.
• Cuándo compensa: en tareas iterativas con una señal de verificación clara y automatizable, como la generación de código con tests unitarios. Ahí aumenta la tasa de éxito de forma medible.
• Dónde está el límite: costes altos (del orden de 10 a 30 veces una llamada CoT), ejecución estrictamente secuencial e inutilidad sin un Evaluator fiable. No sustituye a un entrenamiento real.

Cómo funciona el bucle de Reflexion

El patrón consta de tres componentes que interactúan en un bucle:

1. Actor: genera la solución o el camino hacia ella. Normalmente es a su vez un agente ReAct o Chain-of-Thought.
2. Evaluator: evalúa el intento. La evaluación puede ser binaria (aprobado/suspendido), escalar o realizarse mediante una suite de tests externa.
3. Modelo de Self-Reflection: convierte la evaluación más el historial en feedback verbal: un párrafo de crítica en lenguaje natural. Ese texto se guarda en un búfer de memoria episódica.

En el siguiente intento, el texto de reflexión se antepone al contexto del Actor. La «actualización de la política» es, por tanto, puramente lingüística: no cambia ningún peso. La memoria se mantiene pequeña a propósito; normalmente se conservan de una a tres reflexiones.

El proceso, resumido:

```
Intento_k: Actor → Evaluator → Self-Reflect → [añadir a la memoria]
Intento_k+1: el Actor ve la memoria → nuevo intento
... hasta el éxito o hasta alcanzar el máx. de intentos
```

La ventaja conceptual frente al aprendizaje por refuerzo clásico: el RL estándar necesita muchas muestras y un fine-tuning costoso para aprender del feedback. Reflexion aprende in-context en pocos intentos, lo que resulta órdenes de magnitud más barato y más rápido de poner en marcha.

Cuándo el patrón Reflexion aumenta la tasa de éxito

El beneficio depende por completo de la calidad de la señal del Evaluator. El ejemplo mejor documentado es la generación de código, porque ahí existe un oráculo automático: los tests unitarios.

La constelación ideal para Reflexion queda así bien delimitada: la tarea es iterativa, un intento fallido se puede repetir a bajo coste y existe una señal de verificación automatizable. Eso se cumple en la generación de código y la corrección de bugs, en tareas con resultados intermedios verificables y en entornos textuales de búsqueda y acción como ALFWorld. En la matriz de decisión de la investigación de base figura expresamente, para agentes de generación de código y corrección de bugs, la combinación «Reflexion + ReAct» con la nota: necesita tests unitarios como oráculo.

Los límites: costes, falacias y ausencia de aprendizaje real

Reflexion no funciona por sí solo. Sus principales debilidades, todas documentadas en el artículo y en la práctica:

• El caso MBPP (sección 4.3 del artículo): en MBPP, Reflexion quedó por debajo de la línea base de GPT-4 porque los tests unitarios que él mismo había generado tenían una alta tasa de falsos positivos. El agente daba el intento por bueno antes de tiempo. Es la advertencia canónica contra la suposición de que «Reflexion siempre mejora el rendimiento».
• Reflexiones confabuladas: si el modelo diagnostica mal por qué ha fallado, el siguiente intento hereda la corrección equivocada. Así que la autocrítica también puede llevar al agente por el mal camino.
• Reward hacking: el agente puede aprender a engañar al Evaluator en lugar de resolver la tarea real.
• Reflexiones vagas sin oráculo: en la escritura creativa o la investigación abierta falta una señal de verificación clara. Las reflexiones se diluyen entonces en tópicos generales.
• Costes y latencia: por intento, aproximadamente una ejecución completa de ReAct más una llamada al Evaluator y otra a la Self-Reflection, multiplicado por K intentos. Los intentos son obligatoriamente secuenciales, porque cada uno necesita la reflexión anterior. Los casos de uso en tiempo real suelen quedar descartados.

La cuestión conceptual de fondo para quien toma decisiones: Reflexion no es aprendizaje real. No cambia ningún peso; lo «aprendido» vive en la ventana de contexto del episodio actual. El conocimiento duradero solo aparece cuando las reflexiones se persisten externamente.

Comparación de costes

Los siguientes valores son orientativos (órdenes de magnitud), sintetizados a partir de los datos del artículo y de informes de campo. No sustituyen una medición con tu propia carga de trabajo.

Reflexion se sitúa, por tanto, deliberadamente en la franja alta de costes. Si lo usas sin un límite estricto de iteraciones, te arriesgas a que el bucle dispare los costes.

Ejemplo práctico: agente de código que se autocorrige

Un escenario concreto del campo de aplicación documentado. Una agencia tiene que construir un agente que, a partir de una descripción de función, entregue código Python ejecutable. El pseudocódigo del bucle de Reflexion:

```text
intento = 0
reflexiones = []
mientras intento < MAX_INTENTOS (p. ej. 3):
código = Actor.generar(tarea, contexto=reflexiones) # Actor
resultado = Evaluator.ejecutar_tests_unitarios(código) # Evaluator = oráculo de tests
si resultado.todos_superados:
devolver código # salir si hay éxito
crítica = SelfReflect.analizar(código, resultado.errores) # crítica verbal
reflexiones.append(crítica) # limitar la memoria a 1–3 entradas
intento += 1
```

Siguiendo la lógica del resultado de HumanEval: un primer borrador falla en dos de diez tests. La Self-Reflection anota, en esencia, «caso límite de lista vacía no tratado, off-by-one en el bucle». El segundo intento lee esa nota, corrige ambas cosas y supera todos los tests. Es justo este patrón el que sostiene la mejora en HumanEval de alrededor del 80 % al 91 % pass@1.

Dos lecciones de producción innegociables que deja la investigación:

• Limita siempre las iteraciones. En CrewAI mediante max_reasoning_attempts, en LangGraph mediante una condición revision_number ≤ N. De lo contrario, el bucle puede descontrolarse.
• Usa una señal externa de ground truth siempre que sea posible: tests unitarios, evaluador RAG, coincidencia por regex. La autoevaluación pura no es fiable; el caso MBPP sirve de advertencia.

Si tienes tipos de tareas recurrentes, también puedes guardar las reflexiones en una base de datos vectorial, indexadas por tipo de tarea. Así surge una biblioteca de habilidades emergente que actúa más allá de episodios individuales, el puente hacia enfoques de skill library como Agent Workflow Memory (arXiv:2409.07429).

Encaje en el ecosistema de frameworks (a fecha de 2026)

• LangGraph: tutorial oficial con tres variantes: Basic Reflection (par generador-reflector), Reflexion (Draft-Responder → ejecución de herramientas → bucle de Revisor con memoria de reflexiones explícita) y LATS (Reflexion más búsqueda en árbol). Un patrón de producción sólido es la salida estructurada que reúne answer, reflection (qué falta, qué sobra) y las search_queries de seguimiento.
• CrewAI: en dos niveles. A nivel de agente mediante Agent(reasoning=True, max_reasoning_attempts=N), a nivel de crew mediante un Critic Agent dedicado en el Hierarchical Process.
• AutoGen: documentado como patrón de diseño «Reflection» con un agente Coder y un agente Reviewer que iteran hasta converger o hasta max_iterations. Nota: AutoGen está oficialmente en modo de mantenimiento; Microsoft remite los proyectos nuevos a Microsoft Agent Framework, el sucesor común de AutoGen y Semantic Kernel.
• n8n: no hay nodo Reflexion nativo. Se puede implementar como bucle de workflow: agente generador → agente crítico → nodo IF sobre el veredicto → vuelta al generador o fin. Adecuado para tareas por lotes y de back office, no para chat de baja latencia.

Para agencias y B2B

Para las agencias de marketing en Europa, Reflexion es la herramienta adecuada para tareas por lotes acotadas, verificables y con exigencia de calidad: generación automatizada de código o de configuraciones, enriquecimiento de datos con reglas de validación claras, contenidos estructurados con un esquema estricto. La regla general: úsalo solo si puedes definir una señal de verificación automatizable y la latencia no se nota en la conversación con el cliente. Para chatbots en tiempo real, un patrón ReAct reactivo es mejor opción. En Blck Alpaca incorporamos justo esta decisión de arquitectura a la estimación de costes: primero medimos qué modos de fallo aparecen y después escalamos de forma selectiva de un ReAct sencillo a Reflexion, con un límite estricto de iteraciones y un oráculo externo. Así el agente sigue siendo fiable y el presupuesto de tokens, calculable.