Ventana de contexto de un agente LLM: qué entra en ella y por qué el agente olvida las reglas

Qué es la ventana de contexto de un LLM

La ventana de contexto de un LLM es todo el texto que el modelo recibe como entrada para generar la siguiente respuesta. El modelo no tiene memoria en el sentido humano: todo lo que «sabe» sobre su tarea en este momento está dentro de esa ventana. Lo que no está en la ventana, para el modelo no existe.

El tamaño de la ventana se mide en tokens, es decir, en trozos de palabras. En español un token suele cubrir menos texto que en inglés, así que la misma instrucción cuesta más tokens en nuestro idioma. Los modelos actuales tienen ventanas de cientos de miles de tokens y parece que cabe todo. En la práctica, el espacio del agente se agota antes de lo que se espera, y empieza a trabajar peor incluso antes.

Qué entra en la ventana de contexto de un agente

Un agente de programación tiene exactamente tres fuentes de información: el prompt del sistema con la descripción de la tarea, el contenido de los archivos que ha leído y la salida de las herramientas que ha llamado. Las tres viven en la misma ventana y compiten por el espacio.

Lo clave: nada de esto desaparece por sí solo. El log de pruebas fallidas que hacía falta hace veinte pasos sigue en la ventana y resta atención al paso actual. Una sesión larga es una pila que crece sin parar, en la que cada vez cuesta más encontrar la aguja.

Por qué el agente olvida las reglas en una sesión larga

Una queja frecuente: al principio de la sesión el agente cumple con cuidado las reglas de CLAUDE.md, pero una hora después empieza a infringirlas. No las «olvidó» en sentido literal: el texto de las reglas sigue en la ventana. El problema está en cómo el modelo reparte la atención a lo largo de un texto extenso.

Lost in the middle

Un estudio de Liu y coautores de 2023 mostró que los modelos de lenguaje aprovechan bastante mejor la información del principio y del final de un contexto largo que la que está en medio. El archivo de instrucciones se carga al inicio de la sesión, pero a medida que avanza el diálogo se acumula más texto encima y debajo. La regla que estaba a la vista acaba en la zona donde el modelo «ve» peor.

La proporción de reglas en la ventana disminuye

En una sesión recién iniciada, las instrucciones son una parte notable del contexto. Tras cien llamadas a herramientas se convierten en un fragmento pequeño entre logs, diffs y código leído. La señal es la misma, pero el ruido alrededor es decenas de veces mayor.

Los ejemplos recientes pesan más que las reglas antiguas

El modelo se apoya mucho en lo que pasó hace poco en la conversación. Si el agente hizo varias veces algo saltándose una regla y no hubo consecuencias, ese patrón del historial empieza a pesar más que una línea de instrucción escrita al principio.

Context rot: la degradación de la calidad antes del límite

Context rot («podredumbre del contexto») es el nombre del efecto por el que la calidad de las respuestas cae a medida que la ventana se llena, aunque el límite técnico esté todavía lejos. El modelo acepta formalmente 200 mil tokens, pero con 150 mil trabaja peor que con 20 mil: se equivoca más en los detalles, repite soluciones ya descartadas y pierde instrucciones.

Señales de que la sesión «se pudrió»:

• el agente propone un enfoque que ustedes descartaron juntos hace media hora;
• confunde nombres de archivos y funciones que ya se comentaron;
• deja de ejecutar las comprobaciones que al principio sí ejecutaba;
• las respuestas se alargan y se vuelven más vagas, aparecen «de paso también arreglé» innecesarios.

Curar esto añadiendo otra regla no sirve de nada: la nueva regla se perderá en el mismo ruido. Hay que reducir el ruido.

Compactación del contexto

La compactación es la compresión del historial de la sesión: el modelo escribe un resumen de lo ocurrido y a partir de ahí la conversación continúa con ese resumen en lugar de con el historial completo. La ventana se libera y la esencia del trabajo, en teoría, se conserva.

En Claude Code para esto existe el comando /compact, al que se le puede pasar una indicación sobre en qué centrarse al comprimir. Cuando la ventana se acerca al límite, Claude Code también ejecuta la compactación automáticamente. El comando /clear borra el historial por completo y empieza de cero, y /context muestra qué ocupa la ventana en ese momento.

/context
/compact conserva: objetivo de la tarea, decisiones tomadas con sus motivos, lista de archivos modificados, qué queda por comprobar
/clear

Qué tiene de peligroso la compactación

Un resumen siempre pierde detalles. En la síntesis puede no aparecer la variante descartada y el motivo del rechazo, la formulación exacta de un requisito o un matiz que se acordó de pasada. Después de la compactación, el agente trabaja con un resumen ajeno de su propia sesión. Por eso lo importante conviene guardarlo no en el historial de la conversación, sino en archivos que sobrevivan a cualquier compactación.

Compactar o empezar una sesión nueva

Cómo ahorrar la ventana de contexto

Ahorrar contexto no va de precio de tokens, sino de calidad del trabajo. Cuanto menos ruido hay en la ventana, más atención reciben la tarea y las reglas.

1. Un archivo de instrucciones corto que sirva de router

El CLAUDE.md o AGENTS.md de entrada se lee completo en cada sesión. Un archivo de 600 líneas son del orden de 10 a 20 mil tokens de coste permanente. Guarde en él los comandos de verificación, las restricciones estrictas y el mapa del proyecto, y deje los detalles por tema en documentos separados que el agente abre solo cuando los necesita.

2. Conocimiento que se carga bajo demanda

Los skills de Claude Code están diseñados de forma que al contexto llega primero solo su descripción corta, y el texto completo de la instrucción se carga cuando el skill hace falta para la tarea. Es una forma cómoda de tener a mano procedimientos poco frecuentes —despliegue, migraciones, publicación de versiones— sin pagarlos en cada sesión.

3. Subagentes para el trabajo ruidoso

Un subagente trabaja en su propia ventana de contexto y devuelve a la sesión principal solo el resultado. La búsqueda en un código grande, el análisis de un log largo, el estudio de un módulo desconocido: todo eso puede encargarse a un subagente, y a cambio recibir unos párrafos con conclusiones en lugar de miles de líneas de salida en bruto.

4. Salida de herramientas silenciosa

La salida de los comandos es el principal consumidor de la ventana. Configure los comandos de verificación para que, si todo sale bien, impriman una sola línea, y si hay errores, solo lo esencial: la prueba que falló y su mensaje, no el log completo de la compilación.

# ruidoso: miles de líneas en la ventana en cada ejecución
pytest -v

# silencioso: con éxito, una línea; con fallos, solo las pruebas caídas
pytest -q --tb=short

# un log no completo, sino solo la cola y los errores
tail -n 50 app.log | grep -i error

5. Una tarea, una sesión

No arrastre una sola sesión a través de tres tareas sin relación. El historial de la primera tarea no sirve para la tercera, pero ocupa espacio y confunde al agente. Terminó, dejó registrado el resultado, abrió una sesión nueva.

6. El estado en archivos, no en el historial

Todo lo que deba sobrevivir a la compactación y a la sesión nueva, anótelo en el repositorio: el objetivo, las decisiones con sus motivos, las variantes descartadas, lo hecho y cómo se comprobó, el siguiente paso. Por ejemplo, en PLAN.md y PROGRESS.md. Así la sesión nueva no empieza por un resumen, sino por un documento exacto, y el historial se puede borrar sin miedo.

# PROGRESS.md
## Objetivo
Pasar el cálculo de descuentos a céntimos enteros

## Hecho (comprobado)
- app/payments/discount.py: float → int, make test en verde
- Migración 041 añadida, aplicada en local

## Decisiones
- Redondeo bancario, igual que en el proveedor de pagos

## Descartado
- Decimal en el modelo: rompe la serialización de los webhooks

## Siguiente paso
Actualizar el escenario e2e de la compra y ejecutar make e2e

Las reglas críticas no deben vivir solo en la ventana

Incluso un contexto perfectamente organizado no garantiza que se cumplan las reglas: el texto en la ventana influye en el modelo, pero no es una prohibición ejecutable. Si una infracción no es admisible, la regla debe comprobarse mecánicamente. En Claude Code para eso existen los hooks, comandos que se ejecutan en los eventos del agente y pueden bloquear una acción, y la configuración de permisos, que prohíbe determinadas herramientas o comandos. Los linters, las pruebas y el CI funcionan con independencia de lo que esté ocurriendo en la ventana del agente.

Buena regla del harness: todo lo que se puede comprobar automáticamente se comprueba automáticamente, y en el contexto solo queda lo que requiere juicio.

Resumen

La ventana de contexto de un LLM es el único lugar donde el agente ve su tarea, y se llena más deprisa de lo que parece: las instrucciones, el historial, los archivos leídos y la salida de los comandos se acumulan hasta el final de la sesión. La calidad cae mucho antes del límite técnico, las reglas del medio de un contexto largo se pierden y la compactación salva espacio al precio de los detalles. Mantenga las instrucciones cortas, cargue el conocimiento poco frecuente bajo demanda, delegue el trabajo ruidoso en subagentes, guarde el estado en archivos y refuerce las reglas críticas con hooks y comprobaciones. El trabajo con el contexto del agente se explica en la práctica dentro del curso de harness engineering.