Configuración, Estado, Almacenamiento, Prompt: Ingeniería de contexto en LangGraph

Los desarrolladores que utilizan LangChain o LangGraph eventualmente se encuentran con términos como Config, State, Store y Context Engineering. Es fácil suponer que “contexto” se refiere únicamente a la cadena de instrucciones más reciente. Esa suposición se desvanece en cuanto las aplicaciones crecen.

La calidad de un producto de IA depende menos del nombre de la marca del modelo y más de cuán cuidadosamente se selecciona, almacena y presenta la información al modelo. LangChain y LangGraph ofrecen el vocabulario y los mecanismos necesarios para ello, y estas ideas se corresponden perfectamente con la ingeniería de software tradicional.

Qué incluye realmente el contexto de un LLM

A menudo, al escuchar “contexto”, la gente imagina una sola oración del usuario, como “Explique los React Hooks”. Las aplicaciones reales también necesitan historial de conversaciones, preferencias, documentos recuperados, resultados de herramientas, metadatos de autenticación y configuraciones en tiempo de ejecución. Juntos, estos elementos forman el contexto que permite obtener respuestas precisas.

                    LLM
                     ▲
                     │
        ┌────────────┴────────────┐
        │                         │
   User Message             Additional Context
                                │
         ┌──────────────┬──────────────┬──────────────┐
         │              │              │
   Conversation     User Info     Retrieved Docs
      History

La instrucción es solo una capa de esa pila.

Por qué es importante la gestión

Una pregunta de soporte como “¿Dónde está el pedido más reciente?” necesita la identidad del usuario, las interacciones anteriores, los pedidos recientes, las políticas y los datos de envío. Incluir todo eso en una sola instrucción masiva en cada interacción genera cadenas enormes, costosas y difíciles de depurar. La ingeniería de contexto es la disciplina que determina qué ve el modelo, de dónde proviene, cuándo está disponible y cuánto tiempo dura su validez, incluyendo información confidencial que el modelo nunca debe ver.

Cuatro tipos de contexto

1. Config (contexto de ejecución inmutable)

La configuración son metadatos de la solicitud que no cambian mientras el agente está en ejecución: identificador del usuario, arrendatario, plan, configuración regional, zona horaria, indicadores de funcionalidad y autenticación. Pásela a través del objeto reservado configurable de LangChain:

await agent.invoke(
  {
    messages: [
      {
        role: "user",
        content: "Show my recent orders."
      }
    ]
  },
  {
    configurable: {
      userId: "123",
      tenantId: "companyA",
      plan: "premium"
    }
  }
);

Las herramientas pueden leerla de forma segura:

const getOrders = tool(async (_, config) => {
    const userId = config.configurable.userId;

    return database.orders.find({
        userId
    });
});

El usuario nunca escribe un id; la herramienta lo obtiene de la configuración en tiempo de ejecución.

2. Estado (memoria de trabajo)

El estado funciona como RAM durante la ejecución: mensajes, resultados de la herramienta, documentos recuperados, notas intermedias, resúmenes. A diferencia de la configuración, el estado cambia a medida que se ejecutan los nodos.

User asks question

↓Search tool runs↓Results added to State↓Model reasons↓Final answer generated

Los nodos del grafo leen y escriben en el estado, por lo que la colaboración no necesita variables globales.

3. Almacenamiento (memoria a largo plazo)

El estado desaparece cuando finaliza la ejecución. El almacenamiento persiste a lo largo de las conversaciones: preferencias, perfiles, interacciones anteriores, pila de herramientas favorita, tono de escritura. Ejemplo: si un usuario menciona que está creando aplicaciones con React, una semana después una pregunta sobre gestión de estado puede orientarse hacia opciones compatibles con React sin necesidad de preguntar nuevamente.

4. Contexto del prompt

Con el tiempo, las contribuciones de Configuración, Estado y Almacenamiento se integran en el prompt final del modelo: el texto más reciente del usuario, la historia filtrada, los documentos recuperados, los resultados de las herramientas y las preferencias memorizadas. Recuerde: el prompt es el producto de la gestión del contexto, no todo el contexto.

¿Por qué no incluirlo todo en el prompt?

Las ventanas de contexto son finitas. Cada token adicional aumenta el costo y la latencia. Los tokens de autenticación y las claves API nunca deben ser visibles para el modelo. Por lo tanto, separar la configuración en tiempo de ejecución del texto dirigido al modelo es una medida de seguridad y ahorro, no una cuestión de pedantería.

Relación con la ingeniería de software

Config se asemeja a los ajustes del ámbito de la solicitud. State recuerda a la memoria de trabajo por solicitud. Store se parece a una base de datos o un servicio de perfiles. El ensamblaje de prompts se asemeja a la generación de una vista a partir de múltiples fuentes de datos. Pensar de esta manera ayuda a los ingenieros de backend a adoptar LangGraph sin tratarlo como magia artificial ajena.

Hábitos prácticos

• Mantenga Config pequeño y estructurado.
• Escriba reducidores/nodos de State que sean fáciles de probar.
• Trate las escrituras en Store como eventos intencionales del producto, no como efectos secundarios accidentales.
• Registre qué capas contribuyeron a cada prompt para facilitar la depuración.
• Prefiera la recuperación y las búsquedas en Store a pegar historiales completos.

Los equipos que gestionan explícitamente estas capas crean asistentes que resultan más económicos, seguros y fáciles de explicar cuando ocurre un problema a las 2 a.m.

Patrones que aparecen en las aplicaciones de LangGraph

Muchos grafos comienzan con un nodo de enrutador que inspecciona Config (inquilino, configuración regional) y State (última intención del usuario) antes de elegir una rama. Los nodos de recuperación escriben documentos en State; los nodos de generación leen State y nunca acceden a los secretos de autenticación en bruto de Config, salvo a través de envoltorios de herramientas. Los nodos de memoria deciden si una preferencia merece ser escrita en Store después de que la acción tenga éxito.

Incoming Request

El control de puntos de verificación (cuando está habilitado) mantiene el State entre pasos para que los agentes de ejecución prolongada puedan reanudarse. Esto es distinto de Store: los puntos de verificación ofrecen durabilidad dentro del ámbito de ejecución; Store es la memoria del producto entre sesiones.

↓Middleware↓Load Memory↓Update State↓Generate Prompt↓Call LLM

Al depurar una respuesta incorrecta, pregúntese qué capa falló. ¿ID de usuario incorrecto? Config. ¿Se perdió el resultado de una herramienta? State. ¿Se olvidó alguna preferencia? Store. ¿Tokens excesivamente grandes? Ensamblaje de solicitudes. Esa taxonomía convierte los informes vagos como “el modelo generó alucinaciones” en tickets accionables.

User
↓Agent.invoke()↓Config
(User ID, Tenant ID)↓Middleware↓State
(Chat History)↓Retriever
(Knowledge Base)↓Store
(Long-Term Memory)↓Prompt↓LLM↓Final Response

Por lo tanto, el ingeniería de contexto se trata menos de crear prompts ingeniosos y más de un flujo de datos disciplinado: la misma habilidad que permite mantener los backends web comunes funcionales. LangChain y LangGraph simplemente nombran los contenedores para que las funciones de IA dejen de meter todo en una sola cadena de texto.

Patrones a evitar

Incluir todo el historial de conversaciones en cada prompt “por si acaso” consume recursos innecesariamente y dispersa la atención. Incluir claves API en los prompts del sistema “por comodidad” genera riesgos de fuga de datos. Usar Store como cajón de basura para elementos temporales contamina las sesiones futuras. Permitir que cada nodo modifique la Configuración durante su ejecución destruye la garantía de inmutabilidad en la que dependen las herramientas.

Preferir esquemas explícitos para el Estado, rutas de escritura auditadas para el Almacén, y plantillas de prompts que solo acepten los campos necesarios. Medir el uso de tokens por capa. Revisar los registros semanalmente hasta que el equipo pueda predecir qué nodo agrega qué tokens.

Con esas prácticas, Config, Estado, Almacén y Contexto de Prompt dejan de ser términos de moda para convertirse en el sistema operativo del agente: una infraestructura silenciosa que hace que el modelo parezca más inteligente de lo que sería por sí solo.