Skip to main content

Plan-and-Solve Prompting

Arquitectura de agente en dos etapas que separa la descomposición estratégica de la tarea en un plan global de su ejecución táctica secuencial con replanteamiento dinámico.

1. Visión general del concepto y problema sistémico

Cuando un desarrollador plantea una gran tarea de ingeniería a la inteligencia artificial (por ejemplo, "reescribir el módulo de autorización de JWT a sesiones en la base de datos"), la reacción impulsiva del agente consiste en editar de inmediato el primer archivo aleatorio.

Este enfoque puramente reactivo provoca fallos críticos:

  1. Ruptura del orden de dependencias: El agente modifica un componente de la interfaz antes de actualizar el esquema de la base de datos o crear los tipos necesarios de TypeScript.
  2. Correcciones cíclicas: El modelo corrige un error, rompiendo otro archivo relacionado, y se queda atrapado en un ciclo interminable de corrección de sintaxis sin entender el panorama general.
  3. Pérdida del objetivo inicial: Después de 10 pasos de búsqueda de errores, el contexto se satura con mensajes del compilador, y el modelo olvida la tarea inicial del usuario.

Plan-and-Solve elimina este problema a través del principio clásico de la ingeniería: Separación del diseño estratégico (Planning) y la implementación táctica (Execution).

2. Taxonomía arquitectónica y modelo mental

El patrón se implementa a través de tres fases complementarias:

  • 1. Fase de descubrimiento y planificación (Discovery & Planner Phase): El agente analiza la solicitud, lee previamente el sistema de archivos (Read-Only) y genera un gráfico de acciones claramente estructurado: un array de pasos con la designación de objetivos, criterios de éxito y archivos necesarios.
  • 2. Fase de ejecución de pasos (Solver / Execution Phase): Un ejecutor especializado toma el primer punto abierto del plan, invoca las herramientas necesarias (edición de archivos, ejecución de compilación), se asegura de que la subtarea se complete y marca el punto como finalizado.
  • 3. Fase de replanteamiento dinámico (Replanning & Feedback Phase): Si durante la ejecución de un paso ocurre un error que no se puede resolver con una simple repetición (por ejemplo, se detecta la falta de un módulo necesario en el sistema), el replanteador revisa el resto de los puntos del plan, añadiendo un paso para la instalación de dependencias.

3. Pipeline técnico y mecánica interna

El ciclo de vida del trabajo bajo el patrón Plan-and-Solve:

  1. Plan Generation (Generación de plan estructurado): El modelo forma un objeto JSON válido con un array de tareas: tasks: [{ id: 1, title: "DB Schema", status: "pending" }, { id: 2, title: "API Route", status: "pending" }].
  2. State Injection (Inicialización del rastreador): El plan se registra en el estado del agente. El usuario ve el progreso visual de la ejecución en forma de una lista de verificación interactiva.
  3. Execution Loop (Iteración): El orquestador elige la siguiente tarea con estado pending. El contexto se limpia de detalles antiguos de depuración, enfocándose solo en la tarea actual y el objetivo final.
  4. Invariant Check & Status Transition (Control de invariantes): Después de completar un paso, se ejecuta un linter o una prueba unitaria. Si la verificación es exitosa, el estado cambia a completed. Si no, se invoca el método replan(), que corrige los pasos no ejecutados.

4. Escenarios prácticos de ingeniería en producción

01. Migración compleja de la base de código

Transición del proyecto de Next.js Pages Router a App Router:

  • Paso 1: Auditoría de la estructura de la carpeta pages/ y extracción de Layouts comunes.
  • Paso 2: Creación del app/layout.tsx raíz y estilos básicos.
  • Paso 3: Transferencia gradual de páginas estáticas.
  • Paso 4: Reescritura de rutas dinámicas y API Routes en route.ts.
  • Paso 5: Compilación completa del proyecto y eliminación de archivos obsoletos.

02. Creación de nuevas funciones según especificación (Spec-Driven Development)

El agente recibe un requisito comercial. Primero redacta la documentación y los esquemas de Zod, los valida con el usuario, y solo después de recibir aprobación, genera paso a paso el backend, los hooks del cliente y los componentes de UI.

03. Despliegue de infraestructura de servidores

Endurecimiento gradual de Linux VPS:

  • Generación de un plan de 6 etapas (claves SSH, firewall UFW, fail2ban, actualización de paquetes, creación de usuario no root, desactivación del acceso por contraseña).
  • Cada punto se ejecuta por separado con verificación obligatoria del estado del puerto antes de desactivar el método de conexión anterior.

5. Errores comunes, trampas y seguridad

  • Planificación a ciegas (Premature Planning): Elaboración de un plan sin un análisis previo de los archivos del repositorio. El modelo puede planificar el uso de bibliotecas que no están en el proyecto. Solución: paso obligatorio de "Descubrimiento" (Discovery) antes de iniciar el planificador.
  • Rigidez excesiva del plan (Plan Rigidity): El agente intenta obstinadamente ejecutar el Paso 3 cuando en el Paso 1 se ha determinado que la arquitectura requiere un enfoque fundamentalmente diferente. Asegúrese de implementar ganchos de replanteamiento dinámico.
  • Microgestión en 30 pasos: Pasos demasiado pequeños (por ejemplo, un paso separado para importar cada tipo) consumen tiempo y dinero. Mantenga el nivel de abstracción en bloques funcionales lógicos.
/ Preguntas frecuentesSchema.org FAQPage

FAQ: Plan-and-Solve Prompting

El ReAct puro actúa de manera 'codiciosa' (Greedy / Myopic): elige la siguiente acción únicamente en función de la observación del paso anterior. En tareas complejas (refactorización de 20 archivos), este enfoque lleva al agente a óptimos locales y callejones sin salida. Plan-and-Solve primero construye un mapa global de dependencias, garantizando la integridad de la arquitectura.
/ Enlaces internos
Todos los términos