2025-10-05 · Actualizado 2026-07-15

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Context Engineering para Agentes AI: Ventanas de contexto, memoria, herramientas y restricciones

Context engineering es el pipeline que determina qué información recibe un modelo antes de tomar cada decisión: instrucciones, ejemplos, conocimiento, memoria, definiciones de herramientas, observaciones y restricciones. Un agente no actúa sobre todo lo que conoce el sistema, sino únicamente sobre el conjunto de datos preparado para la siguiente llamada al modelo.

Es precisamente en esa selección donde comienzan muchos fallos. Una preferencia obsoleta se muestra como si estuviera actualizada. El texto recuperado contiene una instrucción. Un tool result muy largo oculta la condición previa que no se cumplió. Un resumen guarda la decisión tomada, pero no indica qué archivo fue modificado.

La tarea práctica consiste en compilar el conjunto de elementos mínimo y suficiente para que funcione en cada decisión, manteniendo al mismo tiempo el alcance, el origen y los permisos asociados. Este artículo explica los patrones que utilizo y las limitaciones que garantizan su fiabilidad.

TL;DR. Considere el contexto como un artefacto tipado que lleva consigo información sobre su procedencia, es decir, un runtime. Selecciónelo paso a paso, aplique restricciones basadas en el propietario y los permisos antes de realizar la recuperación, separe las instrucciones fiables de los datos no confiables, establezca un límite de recursos según la utilidad esperada, valide las acciones fuera del modelo y evalúe los resultados de la tarea en lugar de centrarse únicamente en la longitud del contexto.

El contexto es una entrada para la toma de decisiones, no la memoria

La ventana de contexto está formada por la entrada actual del modelo más los tokens generados. Puede contener turnos de conversación, pero no constituye un sistema de memoria persistente. La memoria a largo plazo, los índices de documentos, las bases de datos y los almacenes de artefactos se encuentran fuera de esta ventana; es la ventana de contexto pipeline la que decide qué elementos se copian dentro de ella.

El tamaño de la ventana representa un límite de capacidad, no una garantía de calidad. La investigación con contexto largo, como Perdido en el medio y RULEADOR Se observa que la recuperación y el razonamiento exitosos pueden variar en función de la posición, la tarea, el modelo y la longitud de la secuencia. La lección práctica no es que los tokens intermedios se ignoren siempre, sino que la inclusión de tokens que parecen relevantes puede seguir reduciendo el rendimiento en la tarea.

Utilice un manifiesto de contexto para cada llamada al modelo:

from datetime import datetime
from typing import Literal

from pydantic import BaseModel


class ContextItem(BaseModel):
    item_id: str
    kind: Literal["instruction", "task_state", "evidence", "memory", "tool"]
    source: str
    trust: Literal["trusted", "untrusted"]
    retrieved_at: datetime | None = None
    version: str | None = None
    token_count: int


class ContextManifest(BaseModel):
    request_id: str
    tenant_id: str
    items: list[ContextItem]
    total_input_tokens: int

El manifiesto permite que la falla sea reproducible. La afirmación “El modelo generó alucinaciones” se convierte en una pregunta verificable: ¿qué evidencias, versión, ámbito de permisos y tool schema recibió realmente?

El ciclo de vida del ensamblaje

Un pipeline fiable realiza estas operaciones en el siguiente orden:

1. Resolver el contexto de la solicitud de confianza. Autenticar al agente, al inquilino, a la zona horaria, a la hora actual y al estado de la tarea en curso fuera del modelo.
2. Elegir la siguiente decisión. Un paso de planificación, una búsqueda de evidencias, una selección de herramientas y la respuesta final requieren contextos diferentes.
3. Recuperar datos dentro del alcance permitido. Aplicar filtros de autorización e inquilinos antes del ranking semántico, y no después de que los documentos formen el conjunto de candidatos.
4. Clasificar y asignar recursos. Seleccionar elementos según su utilidad, actualidad, fiabilidad y diversidad, respetando un presupuesto de entrada definido.
5. Componer el resultado con límites de confianza. Mantener las políticas en los canales de instrucciones y citar el contenido recuperado como datos; las instrucciones obtenidas no se convierten en políticas del sistema.
6. Generar una propuesta estructurada. La salida restringida puede imponer una sintaxis y una forma específicas, pero no puede corregir los valores.
7. Validar y ejecutar. El código de la aplicación verifica la autorización, las reglas de negocio, los argumentos de las herramientas y las condiciones posteriores.
8. Registrar el origen y el resultado final. Guardar el manifiesto, los IDs de las fuentes seleccionadas, las referencias tool result, el resultado de la validación y el desenlace de la tarea.

El ciclo de vida está definido por cada decisión. Reutilizar un contexto amplio durante toda la ejecución de un agente genera evidencias obsoletas y permite que cada paso acceda a información que no necesita.

Asignar una tarea a cada fuente de contexto

Las instrucciones definen un comportamiento duradero

Las instrucciones definen el rol, la política, el contrato de salida y el comportamiento de escalada. Es necesario mantener estable el contenido para optimizar el caché de prefijos, pero no se deben congelar aquellos valores que cambian en runtime. El umbral de reembolso debe almacenarse en un servicio de políticas o en un registro de datos versionado, y no copiarse indefinidamente dentro de un prompt.

La jerarquía de instrucciones constituye un límite de control y no una medida de seguridad sandbox. Un modelo puede seguir aún así texto malicioso presente en un documento recuperado. Es necesario delimitar el contenido no fiable, indicar que se trata de evidencia y no de instrucciones, restringir las herramientas de forma independiente, y probar casos de inyección prompt.

Registros de estado de tarea: compromisos asumidos

Los ejemplos ilustran las decisiones en los bordes del dominio

Los ejemplos de few-shot resultan útiles cuando permiten aclarar un límite difícil, en lugar de simplemente repetir el esquema. Se deben seleccionar ejemplos que se ajusten a la decisión actual e incluir casos límite relevantes. La evaluación de la recuperación de ejemplos debe realizarse de forma similar a como se hace con la recuperación de documentos: un ejemplo aparentemente similar pero incompatible con la política puede ser incluso peor que no tener ninguno.

El conocimiento proporciona evidencia

La recuperación de información es adecuada para hechos recientes, privados o citables. No existe un método óptimo universal. top_k, el tamaño del chunk, el peso híbrido o el umbral de reranker. Se debe ajustar todo este conjunto de parámetros en función de las preguntas que cuenten con evidencia de apoyo conocida.

Un elemento de evidencia útil incluye:

• identificador del documento de origen y establecido
• versión o fecha de entrada en vigor
• ámbito de permisos
• rango citado y ubicación
• puntuaciones de recuperación y reranking para depuración

No solicites al modelo que cite una URL que nunca ha recibido. No registres documentos privados completos únicamente para depurar la selección.

Suministro de memoria que garantiza continuidad en el escopo definido

La memoria almacena datos recuperados que conllevan riesgos adicionales en su ciclo de vida. Cada registro debe incluir el sujeto al que se refiere, su procedencia, el propósito para el cual se utiliza, el consentimiento o la base legal aplicable, la fecha de creación, una política de vencimiento o revisión, así como un procedimiento para su eliminación.

Las reglas fijas como “las preferencias permanecen vigentes 365 días” no constituyen una política portátil. La retención de datos se determina en función de las necesidades del producto, las expectativas de los usuarios y la legislación aplicable. Antes de cargar una memoria, compruebe:

1. ¿Está dirigido a este sujeto autenticado y arrendatario?
2. ¿Es su finalidad relevante para esta decisión?
3. ¿Está lo suficientemente actualizado como para ser utilizado?
4. ¿Su fuente es fiable o se trata únicamente de una inferencia del modelo?

Trata las memorias inferidas como hipótesis. No conviertas de forma silenciosa una respuesta del modelo en un hecho permanente del usuario.

Los contratos de herramienta exponen sus capacidades

Las descripciones de las herramientas deben explicar las premisas, los efectos, el ámbito de autorización, el esquema de entrada, el esquema de salida, la idempotencia y los fallos con significado. Una llamada que cumpla con los requisitos del esquema puede seguir sin estar autorizada o resultar insegura.

Tras la ejecución, sustituya la salida bruta y detallada por una observación estructurada que conserve el resultado relevante para la toma de decisiones y incluya un enlace al artefacto completo:

{
    "tool": "check_api_key_status",
    "status": "revoked",
    "checked_at": "2026-07-15T09:30:00Z",
    "account_id": "A-123",
    "artifact_ref": "toolrun://req-42/step-3"
}

MCP estandariza la forma en que los clientes descubren herramientas, recursos y prompts; no autoriza su uso ni garantiza que el contenido devuelto sea fiable. Es necesario mantener las verificaciones relacionadas con las pasarelas, las credenciales y las políticas fuera de la descripción del modelo y del protocolo.

Cómo se degrada el contexto

Un contexto deficiente no provoca fallos de una sola forma. La versión original de esta guía separaba varios patrones que siguen siendo útiles durante la depuración:

• Pérdida por posición: la evidencia necesaria está presente, pero el modelo la utiliza de forma inconsistente debido a su posición y a la secuencia circundante. Las evaluaciones en contextos largos demuestran que esto varía según el modelo y la tarea; no existe un rango universal de “medio malo”.
• Envenenamiento: una memoria incorrecta, un documento desactualizado, una instrucción maliciosa o una observación de herramienta defectuosa ingresan al conjunto de trabajo e influyen en decisiones posteriores.
• Distracción: evidencias relevantes compiten con material reciente o semánticamente similar, pero innecesario para el paso actual.
• Confusión: instrucciones, ejemplos o descripciones de herramientas superpuestas hacen que el modelo tenga varias interpretaciones plausibles de la tarea.
• Choque: dos elementos que parecen ser fuentes autorizadas discrepan sobre un valor, una política o la acción siguiente, y el ensamblador no expone sus versiones ni su precedencia.

Estos fallos exigen soluciones distintas. Una mejor clasificación puede ayudar a reducir las distracciones, pero no puede reparar una fuente obsoleta. Los delimitadores pueden servir para separar los datos de las instrucciones, pero no pueden otorgar autorización a una herramienta. Una ventana de contexto más amplia permite conservar más material contradictorio sin resolver dicho conflicto.

Cuando una ejecución falla, inspeccione el manifiesto y determine qué patrón se produjo antes de modificar el prompt o de añadir otra fase de recuperación.

Presupuesto por servicio, no por cuota de componente

Un presupuesto de contexto reserva espacio para la salida y, a continuación, asigna la entrada correspondiente a la decisión actual. Se parte de la ventana de longitud soportada por el modelo, se resta la longitud máxima de la salida más la sobrecarga del protocolo, y los candidatos se agrupan dentro del espacio que queda disponible.

Puntuar a los candidatos con características que permitan cuestionar sus evaluaciones:

utility = relevance × authority × freshness × scope_match
          − redundancy_penalty − injection_risk

La fórmula constituye un diseño prompt, y no una formulación matemática universal. En las respuestas basadas en políticas, la autoridad puede tener prioridad sobre la similitud semántica. Durante la depuración, un registro de error reciente puede superar en importancia a la documentación general.

El orden también es importante. Mantenga primero las instrucciones estables y fiables cuando la semántica de caché del proveedor se beneficia de un prefijo compartido. Coloque la tarea y la decisión actual cerca de las pruebas a las que hacen referencia. Evite incluir marcas de tiempo o identificadores de solicitud en los prefijos estables cuando no sean necesarios allí.

Compresión sin pérdida de estado

La compresión es con pérdida a menos que el contenido original siga siendo accesible. Es necesario optimizar los tokens por tarea completada y no los tokens por solicitud: un resumen demasiado agresivo que obligue a realizar una nueva recuperación de datos o genere un tool call incorrecto no resulta más económico.

Utilice mecanismos independientes para cada tipo de material:

• Conversación: resumir las decisiones, las preguntas sin resolver y los compromisos.
• Observaciones de herramientas: conservar los hallazgos introducidos por teclado y las referencias a los artefactos; eliminar texto genérico y cargas repetidas.
• Evidencia recuperada: mantener los ID de origen, los segmentos de soporte y las fechas de vigencia para que el sistema pueda volver a obtenerla.
• Estado de la tarea: almacenarla de forma canónica fuera del resumen.
• Rastro de archivos o artefactos: mantener un índice explícito de lecturas, escrituras, hashes y resultados de pruebas.

Se activa la compactación cuando se detecta una degradación medida o cuando se alcanza el umbral presupuestario definido para el modelo y la tarea. No se debe publicar una regla genérica como “comprimir al 70%”, como si todos los modelos fallaran en el mismo punto.

Evaluar la compresión mediante pruebas que requieren continuidad, y no superposición léxica:

• ¿Cuál es el objetivo actual y la siguiente acción?
• ¿Qué archivos o registros han cambiado?
• ¿Qué decisión fue rechazada y por qué?
• ¿Qué fuente respalda la reclamación actual?
• ¿Qué aprobaciones están aún pendientes?

Ejecuta la misma tarea con y sin compresión. Compara el éxito, las acciones incorrectas, las solicitudes de recuperación, la latencia y el número total de tokens.

Optimizar la ruta de contexto

La optimización debe preservar el contrato de decisión. Cuatro técnicas del guía original siguen siendo útiles cuando se aplican a un cuello de botella medido:

Historial completo compactado

Se deben reemplazar los antiguos turnos de conversación por una transferencia estructurada que registre las decisiones tomadas, las preguntas sin resolver, los artefactos modificados y el estado de las pruebas. De este modo, se mantiene la posibilidad de acceder al transcripción original o a los artefactos cuando sea necesario realizar una revisión o una recuperación.

Ocultar observaciones verbosas

Una herramienta puede devolver páginas completas de registros cuando el paso siguiente requiera un estado, un código de error y una referencia al artefacto correspondiente. Tras validar los datos brutos, es necesario convertirlos en observaciones tipadas, manteniendo todo el contenido adicional fuera de prompt. No se debe permitir que el modelo resuma y elimine la única evidencia disponible del fallo.

Mantener los prefijos cachebillables

Los proveedores y entornos de ejecución pueden reutilizar el trabajo cuando el inicio de una solicitud se mantiene estable. Es necesario conservar las instrucciones duraderas y tool schemas en un orden constante, mientras que las marcas de tiempo, los identificadores de solicitud, las pruebas obtenidas y el estado actual deben colocarse en el sufijo dinámico. Antes de diseñar cualquier solución basada en ellos, hay que verificar primero las semánticas de caché del proveedor.

Partición por decisión

Un paso de planificación, uno de recuperación, uno de llamada a herramientas y uno de respuesta final no requieren los mismos datos. Es necesario proporcionar a cada paso las instrucciones, el estado, las pruebas y las herramientas mínimas en las que pueda confiar. De este modo se reduce al mismo tiempo el consumo de tokens y la exposición de capacidades, pero solo las evaluaciones a nivel de tarea pueden determinar si dicha partición ha eliminado información esencial.

Asegurar la cadena de suministro de contexto

El envenenamiento de contexto puede producirse a través de documentos, memorias, tool results, habilidades o mensajes anteriores del asistente. Marcar el texto como “no fiable” ayuda al modelo, pero su implementación debe realizarse a nivel arquitectónico.

Utilice estos límites:

1. Autorizar la operación antes de realizar la recuperación de datos o ejecutar herramientas.
2. Separar los canales de datos de las instrucciones y delimitar el texto externo.
3. Definir una lista blanca de herramientas por paso y por agente; establecer como valor predeterminado la ausencia de capacidad para efectos secundarios.
4. Validar los identificadores de recursos en lugar de permitir que el modelo genere claves de usuario o rutas de archivo.
5. Requerir confirmación para operaciones de alto impacto basadas en políticas definidas, y no en la confianza del modelo.
6. Analizar y revisar las habilidades o conectores ejecutables antes de su instalación.
7. Impedir que datos confidenciales o información sensible cruda lleguen a los registros o a la memoria a largo plazo.

La “reparación” automática solo es adecuada para cambios que preserven el significado, como el análisis de un formato de fecha conocido. Rellenar los argumentos de herramientas faltantes con “valores por defecto razonables” puede alterar el funcionamiento. Solicitar aclaraciones o rechazar la operación cuando el significado sea incierto.

Ejemplo práctico: una solicitud de soporte para una clave API

Para la pregunta “¿Por qué mi clave API no funciona?”, el siguiente paso consiste en recopilar pruebas diagnósticas, y no en generar una respuesta definitiva. El ensamblador podría incluir:

• política de soporte confiable y contrato de respuesta
• ID de cuenta autenticada y plan según el estado de la aplicación
• objetivo actual del ticket y acciones ya intentadas
• dos intervalos del runbook actuales seleccionados dentro del alcance del producto/versión
• una memoria delimitada que indica que la clave fue creada hace tres días, con información sobre su origen check_api_key_status y search_incidents, pero no las herramientas de eliminación o rotación de claves.

El modelo propone una comprobación de estado de solo lectura. El código de la aplicación autoriza la cuenta, llama a la herramienta y registra una observación escrita. Una segunda llamada al modelo recibe los fragmentos relevantes del manual de procedimientos junto con dicha observación. La respuesta final menciona la versión del manual de procedimientos, nunca muestra la clave, y ofrece la rotación únicamente como una acción que requiere autorización separada.

Tenga en cuenta qué se excluye: el historial de tickets no relacionados, cada ejemplo de soporte técnico, los datos brutos de las cuentas, las herramientas de mutación y los registros relacionados con otros usuarios.

Patrones anti que deben probarse explícitamente

• Llenar la ventana: cargar todos los documentos recuperados, el historial, los “memories” y las herramientas, ya que aún queda capacidad disponible.
• RAG en todas partes: emplear la recuperación semántica para aquellos valores que pertenecen a una base de datos, un servicio de políticas o al estado de una aplicación autenticada.
• Memoria ilimitada: conservar hechos inferidos sin aplicar conceptos de alcance, vencimiento, corrección ni eliminación.
• Una sola llamada por cada fase: solicitar a un prompt que realice tareas de recuperación, razonamiento, autorización, mutación e explicación, sin límites visibles.
• El esquema equivale a la corrección: considerar que los JSON válidos constituyen prueba de que los valores, permisos o decisiones empresariales son correctos.
• Sin evaluación de componentes: valorar únicamente el texto final, ignorando fallos en la recuperación, selección de contexto o uso de herramientas.

Convierta cada antipatrón en un contrejemplo dentro del conjunto de evaluación. Una directriz que nunca se aplica en una tarea o traza es fácil de incumplir sin darse cuenta.

Evalúe el ensamblador, no solo la respuesta

Cree un conjunto de tareas fijo que incluya etiquetas de evidencia, límites de permisos, los tool calls requeridos, y acciones prohibidas. Para cada cambio en la política de contexto, mida:

Utilice técnicas de ablación para determinar el valor causal: elimine la memoria, reranking, los ejemplos o la compresión de forma gradual. Un componente que añada tokens sin mejorar el subconjunto relevante no debe cargarse de forma predeterminada.

Conclusión

Un buen context engineering es selectivo y responsable. No ocupa una ventana amplia, ya que existe capacidad disponible. Construye un conjunto de trabajo específico para cada paso a partir de instrucciones fiables, el estado canónico de la tarea, evidencias delimitadas, memoria revisada y herramientas permitidas.

El ciclo duradero es sencillo: ensamblar, manifestar, proponer, validar, ejecutar y evaluar. Cuando una decisión falla, dicho ciclo indica si el elemento faltante era evidencia, actualidad, autoridad, estado o política, y proporciona una prueba para el siguiente cambio.

Referencias

• Perdido en el medio — uso dependiente de la posición del contexto largo RULEADOR — evaluación multitarea de la longitud de contexto efectiva
• Especificación del Protocolo de Contexto del Modelo — conceptos de protocolo y especificaciones actuales Evaluación de la compresión de contexto para agentes AI — enfoque de tokens por tarea y evaluación basada en pruebas Prompt injection ataques y defensas en LLMaplicaciones integradas — taxonomía de amenazas y medidas de defensa