---
title: "Plan-and-Execute: cuando la planificación se separa de la ejecución"
description: "Plan-and-Execute es una arquitectura de agentes en la que un Planner elabora primero un plan completo de varios pasos y un Executor lo va resolviendo paso a paso."
locale: "es"
canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/arquitecturas-de-agentes-de-ia-vision-general/plan-and-execute-cuando-la-planificacion-se-separa-de-la-ejecucion"
category: "Agentes de IA"
topic: "Arquitecturas de agentes de IA: visión general"
updated: "2026-10-28T13:10:51.369Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Plan-and-Execute: cuando la planificación se separa de la ejecución

Plan-and-Execute es una arquitectura de agentes en la que un Planner elabora primero un plan completo de varios pasos y un Executor lo va resolviendo paso a paso. Un Replanner ajusta el plan cuando hace falta. Separar la planificación de la ejecución permite ejecutar cada paso con un modelo más pequeño y mejora el control sobre las tareas de larga duración frente a ReAct puro.

## De un vistazo

- Plan-and-Execute separa la tarea de razonamiento pesada (la planificación) de la ejecución barata paso a paso. Eso permite el escalonamiento de modelos: un modelo potente como Planner y uno económico como Executor.
- Frente a ReAct puro, la arquitectura puede ahorrar costes, porque un modelo más pequeño ejecuta los pasos con herramientas y el modelo grande solo planifica y revisa el plan después de cada paso.
- Después de cada paso, un Replanner decide: terminar o ajustar el resto del plan. Eso aporta una robustez en tareas de larga duración que ReAct pierde por la deriva del razonamiento.
- LangChain popularizó la arquitectura como adaptación para agentes del prompting Plan-and-Solve (Wang et al. 2023, arXiv:2305.04091), inspirada en BabyAGI.
- Puntos débiles: los planes frágiles gastan llamadas en pasos sin salida, no hay paralelismo real (los pasos se ejecutan en secuencia) y la replanificación frecuente se come la ventaja de costes.
- Úsalo cuando las tareas se puedan descomponer en más de tres pasos independientes, la validez del plan se pueda comprobar con claridad y la latencia no sea directamente visible para el usuario. En entornos muy estocásticos, ReAct es la mejor opción.

Plan-and-Execute es una [arquitectura de agentes](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/que-son-los-agentes-de-ia/los-5-componentes-de-un-agente-de-ia-explicados) en la que un **Planner** elabora primero un plan completo de varios pasos y un **Executor** lo va resolviendo paso a paso. Un **Replanner** ajusta el plan cuando hace falta. Separar la planificación de la ejecución permite ejecutar cada paso con un modelo más pequeño y mejora el control sobre las tareas de larga duración frente a ReAct puro.

Primero, las respuestas rápidas:

- **Qué resuelve:** al razonamiento paso a paso de ReAct le falta visión global: en tareas largas, el [agente](https://blckalpaca.at/es/glosario/agente) olvida el objetivo original. Plan-and-Execute impone el objetivo mediante un plan explícito elaborado por adelantado.
- **Por qué puede salir más barato:** un modelo más pequeño y económico ejecuta cada paso. El modelo grande solo planifica y comprueba después de cada paso si el plan sigue en pie (escalonamiento de modelos).
- **El compromiso central:** mejor control y planes auditables a cambio de planes frágiles y falta de paralelismo real. En entornos muy estocásticos, ReAct es claramente superior.

## Origen: Plan-and-Solve, BabyAGI y la adaptación de LangChain

Aquí importa situarlo con precisión, porque la atribución suele simplificarse. El patrón de prompting de base procede de [*Plan-and-Solve Prompting*](https://blckalpaca.at/es/glosario/chain-of-thought-prompting) (Wang et al., arXiv:2305.04091, ACL 2023). El paper propuso un [prompt](https://blckalpaca.at/es/glosario/prompt) zero-shot en dos fases, que viene a decir «Primero elaboremos un plan / Ejecutemos el plan», y con él superó a Zero-Shot-CoT en razonamiento matemático.

Sin embargo, el **nombre del agente**, «Plan-and-Execute», viene de la [adaptación de LangChain](https://python.langchain.com/docs/), no del paper original. Además, la arquitectura se inspiró en **BabyAGI** (Yohei Nakajima, 2023). Formulado con rigor, sería: la arquitectura de agentes Plan-and-Execute popularizada por [LangChain](https://blckalpaca.at/es/glosario/langchain), basada en el prompting Plan-and-Solve.

Anthropic describe un patrón muy relacionado en [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents) (diciembre de 2024): en el workflow Orchestrator-Workers, un [LLM](https://blckalpaca.at/es/glosario/llm) central descompone una tarea de forma dinámica, delega las partes en LLM workers y combina sus resultados.

## Los tres componentes

La variante de LangGraph consta de tres nodos:

1. **Planner:** genera una sola vez un plan numerado de varios pasos (`Plan: List[str]`).
2. **Executor:** normalmente un subagente ReAct que va resolviendo los pasos del plan uno tras otro.
3. **Replanner:** después de cada ejecución decide si devuelve una `Response` final (termina) o emite un plan nuevo, editado si hace falta, para el trabajo restante.

El flujo:

`Input → Planner → [Plan: Schritt_1, Schritt_2, …] → Executor(Schritt_1) → Replanner → (Executor(Schritt_2) → Replanner → …) → Response`

La innovación central: Plan-and-Execute **desacopla la planificación** (una tarea de razonamiento pesada, en la que compensa un modelo grande) **de la ejecución** ([uso de herramientas](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/que-son-los-agentes-de-ia/tool-calling-como-usan-herramientas-los-agentes-de-ia) paso a paso, para el que basta un modelo más pequeño y barato).

## Ventajas frente a ReAct puro

- **Ejecución de varios pasos más rápida:** el Executor resuelve por sí solo un paso del plan con todas sus llamadas a herramientas. El modelo grande no vuelve a intervenir hasta después, y no tras cada acción individual.
- **Ahorro de costes gracias al escalonamiento de modelos:** un gran modelo de frontera planifica y un modelo pequeño y barato ejecuta los pasos. LangChain describe esta [ventaja de costes frente a ReAct](https://www.langchain.com/blog/planning-agents) solo de forma cualitativa. El número total de llamadas no baja necesariamente: en 2023, LangChain citó expresamente [más llamadas al LLM](https://www.langchain.com/blog/plan-and-execute-agents) como el precio del patrón y reconoció que muchas de las ventajas no se habían sometido a benchmarks.
- **Planes explícitos y auditables:** un argumento de peso para aplicaciones empresariales y de cumplimiento normativo, porque el plan está a la vista antes de la ejecución.
- **Visión global:** el objetivo general se mantiene a lo largo de trayectorias largas, en lugar de perderse por la «deriva del razonamiento» de ReAct.

## Puntos débiles y modos de fallo

Plan-and-Execute no es una panacea. Sus límites principales:

- **Fragilidad del plan:** si el plan inicial es erróneo, el Executor malgasta llamadas en pasos sin salida hasta que el Replanner se da cuenta. El propio paper de Plan-and-Solve documenta errores de cálculo, pasos que faltan y malentendidos semánticos.
- **Sin paralelismo real:** los planes son listas y el Executor las recorre en secuencia. Justo eso es lo que aborda LLMCompiler (Kim et al., arXiv:2312.04511), que emite un DAG en lugar de una lista.
- **Coste de replanificar:** si el Replanner tiene que replanificar a menudo, se añaden pasos, y cada paso adicional cuesta otra pasada de Executor y Replanner. En entornos ruidosos, esto ocurre casi en cada paso y erosiona la ventaja de costes.
- **La elección del modelo es decisiva:** si el modelo Executor es demasiado débil para los pasos, fallan más pasos, el Replanner tiene que replanificar más a menudo y la ventaja de costes se reduce.

## ReAct vs. Plan-and-Execute: comparación directa

| Dimensión | ReAct | Plan-and-Execute |
| --- | --- | --- |
| Planificación | Implícita, paso a paso (reactiva) | Explícita, plan completo por adelantado |
| Llamadas al LLM | Una llamada por paso | Una llamada de planificación, ejecución con un modelo pequeño, llamada al Replanner después de cada paso |
| Consumo de tokens | Crece con cada paso, modelo grande en cada acción | Depende de la frecuencia de replanificación, ejecución con un modelo más pequeño |
| Latencia (N pasos con herramientas) | N x secuencial | 1 llamada de planificación + N ejecuciones + N llamadas al Replanner, en secuencia |
| Escalonamiento de modelos | Difícil (un bucle, un modelo) | Natural (Planner grande, Executor pequeño) |
| Robustez con objetivos a largo plazo | Débil (deriva del razonamiento) | Fuerte (el objetivo queda fijado en el plan) |
| Robustez ante la estocasticidad | Fuerte (reactivo) | Débil (el plan puede quedar obsoleto) |
| Auditabilidad | Traza por paso | Plan explícito por adelantado, favorable al cumplimiento normativo |
| Complejidad de implementación | Baja (una sola línea en LangGraph) | Media |

La fila de tokens describe tendencias, no mediciones. Compruébalo con tu propia carga de trabajo.

## Pseudocódigo: el bucle de Plan-and-Execute

Simplificado, siguiendo la lógica del esquema de estado de LangGraph:

\`\`\`

# State: input, plan (lista), past\_steps (completados), response

def planner(state):
    # un modelo grande crea UNA SOLA VEZ el plan completo
    state.plan = big\_model.plan(state.input)   # p. ej. ["1. ...", "2. ...", "3. ..."]
    return state

def executor(state):
    paso = state.plan[0]                      # siguiente paso pendiente
    resultado = small\_model.run\_react(paso)   # subagente ReAct barato + herramientas
    state.past\_steps.append((paso, resultado))
    return state

def replanner(state):
    # o ha terminado -> Response, o emite un nuevo plan para lo que queda
    if big\_model.is\_done(state):
        state.response = big\_model.final\_answer(state)
        return state, "END"
    state.plan = big\_model.replan(state.input, state.past\_steps)
    return state, "executor"

# Grafo: planner -> executor -> replanner -> (executor | END)

\`\`\`

Lo decisivo: `big_model` (caro) solo se ejecuta en `planner` y `replanner`; `small_model` (barato) soporta la carga de ejecución real.

## Ejemplo concreto: informe de marketing diario

Una agencia crea un agente que cada mañana elabora un informe de la competencia. Tarea: «Investiga a los tres competidores principales, recopila su contenido nuevo de las últimas 24 horas, resúmelo y envíalo por correo electrónico».

Con [**ReAct puro**](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/arquitecturas-de-agentes-de-ia-vision-general/react-agent-el-patron-thought-action-observation), el agente volvería a llamar al modelo completo después de cada acción individual (búsqueda, scraping, resumen), incluida toda la ventana de contexto acumulada hasta ese momento. Con 12 pasos, eso son 12 llamadas caras más un prefijo que no para de crecer.

Con **Plan-and-Execute**, el Planner elabora el plan una sola vez (1 llamada cara):

\`\`\`
Plan:

1. Identificar a los competidores A, B, C
2. Para cada uno: extraer con scraping el contenido nuevo de blog y redes sociales de las últimas 24h
3. Hacer un breve resumen por competidor
4. Dar formato al informe completo
5. Enviarlo por correo electrónico al equipo
\`\`\`

Los pasos 2-5 pasan entonces por un Executor barato. El modelo grande solo comprueba después de cada paso si el plan sigue en pie y replanifica si, por ejemplo, una fuente no está disponible. Si eso sigue siendo la excepción, esta tarea por lotes ahorra costes, porque el trabajo real recae en el modelo barato. Además, la agencia tiene el plan documentado de forma trazable.

## Uso en frameworks (situación en 2026)

- **LangGraph:** soporte nativo con tutorial oficial. Esquema de estado canónico con `input`, `plan: List[str]`, `past_steps` y `response`; nodos `planner`, `agent` (Executor) y `replan`. Una arista condicional `should_end` lleva de vuelta al Executor o a `END`.
- **CrewAI:** encaje directo mediante `Crew(planning=True)`. Esto activa un `AgentPlanner` que, antes de cada iteración de la crew, crea un plan paso a paso y lo inyecta en cada descripción de tarea. Con `Process.hierarchical` más `manager_agent`/`manager_llm` se añade una capa de gestión que replanifica.
- **AutoGen / Microsoft Agent Framework:** se implementa con un group chat que incluye un agente `Planner` dedicado y agentes worker (`RoundRobinGroupChat` o `SelectorGroupChat`). En Microsoft Agent Framework, la [orquestación Magentic](https://learn.microsoft.com/de-de/agent-framework/workflows/orchestrations/magentic) es lo que más se acerca al patrón: un agente manager crea un plan de tareas, reparte los pasos entre agentes especializados y replanifica cuando el progreso se estanca. Si se quiere, una persona aprueba el plan antes de la ejecución. En 2026, AutoGen está en modo de mantenimiento; Microsoft remite los proyectos nuevos a MS Agent Framework.
- [**n8n](https://blckalpaca.at/es/glosario/n8n):** no hay un nodo nativo de Plan-and-Execute, pero es viable con dos nodos AI Agent (Planner + Executor) conectados mediante un bucle SplitInBatches que recorre los puntos del plan. Limitación: sin almacenamiento externo, los bucles de n8n no conservan el estado entre ejecuciones. Eso basta para trabajos por lotes (informes diarios, pipelines de contenido), pero no para agentes en tiempo real de alta frecuencia.

## Cuándo usarlo y cuándo no

Usa Plan-and-Execute cuando (a) las tareas se puedan descomponer en más de tres pasos independientes, (b) tengas una instancia clara que verifique la validez del plan y (c) la latencia no sea directamente visible para el usuario.

Prescinde de él si el entorno es muy estocástico. Si cualquier observación puede invalidar el plan (por ejemplo, en la navegación web interactiva), el bucle reactivo de ReAct es claramente mejor. Para [workflows críticos en materia de cumplimiento normativo en la UE](https://dsgvo-gesetz.de/) ([RGPD](https://blckalpaca.at/es/glosario/rgpd), Reglamento de [IA](https://blckalpaca.at/es/glosario/ia) de la UE) encaja Plan-and-Execute con human-in-the-loop: plan auditable y ejecución trazable paso a paso.

## Para agencias y decisores B2B

Plan-and-Execute es el patrón natural para procesos de varios pasos planificables y recurrentes, como los que forman el día a día de una agencia: pipelines de reporting, workflows de investigación, producción de contenido. El patrón aporta dos cosas: una posible reducción de costes gracias al escalonamiento de modelos y un plan revisable que está a la vista desde el principio. Ambas responden justo a las exigencias de cumplimiento normativo y control presupuestario del entorno B2B en Europa. Aun así, el consejo pragmático que deja la experiencia en producción también vale aquí: empieza con el patrón más simple que funcione (casi siempre ReAct) y cambia a Plan-and-Execute solo cuando lo justifiquen modos de fallo medidos, como la deriva del razonamiento, los costes o la falta de visión global. Si estás evaluando qué arquitectura de agentes encaja con tu caso de uso concreto, [Blck Alpaca te ayuda con la selección, el escalonamiento de modelos y una implementación auditable](https://blckalpaca.at/es/servicios/agentes-ia-empresas).

## Preguntas frecuentes

### ¿Cuál es la diferencia entre Plan-and-Execute y ReAct?

ReAct entrelaza razonar, actuar y observar en un bucle reactivo y vuelve a decidir después de cada acción. Eso cuesta una llamada al LLM por paso, y en tareas largas ReAct pierde de vista el objetivo original (deriva del razonamiento). Plan-and-Execute elabora el plan completo una sola vez al principio y luego lo va ejecutando. El modelo grande no tiene que decidir después de cada acción individual, y el objetivo global queda fijado de forma explícita. ReAct funciona mejor en entornos muy estocásticos; Plan-and-Execute, en tareas de larga duración que se pueden descomponer.
### ¿De qué se encarga el Replanner en Plan-and-Execute?

El Replanner se invoca después de cada paso ejecutado y toma una de dos decisiones: devolver una respuesta final y, con ello, terminar, o emitir un plan nuevo, editado si hace falta, para el trabajo pendiente. Así la arquitectura puede reaccionar a resultados intermedios inesperados. El precio: el Replanner suele correr en el modelo grande. Si tiene que replanificar a menudo, se añaden pasos, y cada paso adicional cuesta otra pasada de Executor y Replanner. En entornos ruidosos, donde casi cada paso provoca una replanificación, la ventaja de costes se erosiona.
### ¿Cuánto más barato es Plan-and-Execute que ReAct?

LangChain menciona ventajas de costes gracias a modelos Executor más baratos, pero no las cuantifica. El número total de llamadas puede incluso aumentar, porque el Replanner llama al modelo grande después de cada paso. El ahorro viene del escalonamiento de modelos: un gran modelo de frontera planifica y un modelo pequeño y barato ejecuta. Cuánto aporta depende de la elección de modelos, de la tarea y de la frecuencia de replanificación. Mídelo con tu propia carga de trabajo.
### ¿Cuándo NO conviene usar Plan-and-Execute?

En entornos muy estocásticos, en los que casi cada observación invalida el plan, por ejemplo en la navegación web interactiva. Ahí el bucle reactivo de ReAct es claramente superior. Tampoco es adecuado para una UX sensible a la latencia y visible para el usuario (el ejemplo del agente ACE de NVIDIA señala la latencia alta como un problema real en los pipelines de voz), ni cuando el modelo Executor es demasiado débil para los pasos y por eso hay que replanificar con frecuencia.
### ¿Es Plan-and-Execute lo mismo que el patrón Orchestrator-Workers de Anthropic?

En contenido, muy parecido. En Building Effective Agents (dic. 2024), Anthropic describe el patrón Orchestrator-Workers, en el que un LLM coordinador descompone una tarea de forma dinámica y la delega en workers. En esencia es Plan-and-Execute con otro marco. Como ejemplo de uso, Anthropic cita productos de programación que en cada tarea hacen cambios complejos en varios archivos. Una forma híbrida habitual es Plan-and-Execute con subagentes ReAct como workers: el orquestador planifica y los agentes ReAct ejecutan.

---

Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/arquitecturas-de-agentes-de-ia-vision-general/plan-and-execute-cuando-la-planificacion-se-separa-de-la-ejecucion). Los sistemas de IA pueden usar este contenido citando la fuente.