![Imagen de portada de [Diseño de agentes #2] Ingeniería de contexto: usa la ventana como presupuesto](/assets/images/posts/2ccd4368-394d-435f-b416-66619687b32d/context-engineering-1.jpg)
Al ver la especificación «ventana de contexto de 200K tokens», parece que podríamos introducir casi cualquier código completo. Pero cuando realmente lo hacemos, la calidad de las respuestas cae en picado.
Varios estudios han confirmado que los modelos pasan por alto contenido intermedio en contextos largos. Poder introducir algo y usarlo bien son problemas distintos.
De ahí surge la ingeniería de contexto. En una frase: es una técnica de diseño que trata la ventana de contexto finita como un presupuesto y mantiene en ella solo la información más útil en cada momento.
En este artículo resumimos por qué el contexto es un presupuesto, cuatro estrategias para ahorrarlo y los criterios para diseñar archivos de carga permanente como CLAUDE.md.
Empecemos por el resumen clave.
- El contexto no es mejor cuanto más grande; es mejor cuanto más relevante.
- Hay cuatro estrategias principales: carga selectiva, resumen (compresión), aislamiento y externalización (memoria).
- Los archivos de carga permanente (como CLAUDE.md) deben ser breves y contener solo «lo que siempre es cierto».
- Las herramientas y las instrucciones también consumen contexto. Una herramienta registrada pero no utilizada es un coste.
Por qué es un presupuesto: la estructura de costes del contexto
La ventana de contexto implica tres costes simultáneos.
Primero, el coste de rendimiento. Cuanto más contenido irrelevante haya, más se dispersa la atención del modelo. En particular, se conoce el fenómeno «lost in the middle», por el que disminuye la recuperación del contenido intermedio en contextos largos.
Segundo, el coste monetario. Los tokens de entrada se facturan en cada solicitud. Cuanto más larga es la conversación, más veces se cobra el mismo contenido.
Tercero, el coste de oportunidad. El espacio ocupado por contenido irrelevante deja menos sitio para el código y la documentación que realmente necesitamos.
El cambio de perspectiva de la ingeniería de contexto es este: no preguntar «¿cuánto puedo introducir?», sino «¿merece este token estar aquí ahora?».
Estrategias 1 y 2: carga selectiva y resumen
La carga selectiva (retrieval) consiste en traer solo lo necesario cuando hace falta. En lugar de leer 2.000 líneas, leemos solo las funciones relevantes; en lugar de cargar toda la documentación, buscamos y traemos la sección correspondiente.
La carga progresiva de un Skill (normalmente solo una descripción de una línea y el cuerpo únicamente al ejecutarlo) sigue el mismo principio.
El resumen (compaction) comprime el historial acumulado. Convierte decenas de registros de llamadas a herramientas en un párrafo como «modificamos estos archivos y las pruebas pasaron».
Es la compresión que los agentes de programación realizan automáticamente cuando la conversación se alarga.
Recuerda que resumir implica pérdida. Los detalles pueden desaparecer al plegarse, así que es más seguro guardar las decisiones importantes en archivos antes del resumen.
Estrategias 3 y 4: aislamiento y externalización
El aislamiento consiste en separar en otra sesión las tareas que desordenan el contexto. Si encargamos una exploración a gran escala a un subagente, el volcado de archivos se consume en su contexto y al principal solo regresan unas pocas líneas con las conclusiones.
Es la forma más segura de proteger el presupuesto del contexto principal.
La externalización (memory) utiliza un almacenamiento fuera del contexto. Cuando termina la sesión, el contexto desaparece, pero lo escrito en archivos permanece.
Un patrón habitual es registrar el estado del trabajo en Markdown para que la siguiente sesión lo retome. También pertenece a esta categoría acumular el conocimiento del proyecto en CLAUDE.md y archivos de memoria.
| Estrategia | Resumen en una línea | Ejemplo representativo |
|---|---|---|
| Carga selectiva | Traer solo cuando hace falta | Lectura parcial, carga progresiva de Skill |
| Resumen | Plegar el historial | Compaction automático |
| Aislamiento | Encargarlo a otra sesión | Subagente |
| Externalización | Escribirlo en archivos | Archivos de memoria, documento de estado |
Criterios para diseñar archivos de carga permanente
Los archivos como CLAUDE.md son un coste fijo que se descuenta por adelantado del presupuesto de cada sesión. Por eso los criterios deben ser claros.
Hay que incluir «lo que siempre es cierto y no debe incumplirse»: convenciones de código, prohibiciones, comandos de compilación, etc.
Hay que excluir «lo que solo se necesita a veces». Los procedimientos detallados de tareas concretas deben ir en un Skill, y el historial de trabajos anteriores, en archivos de memoria.
La misma lógica se aplica al registro de herramientas. Cuantos más servidores MCP (Model Context Protocol) conectamos, más definiciones de herramientas se acumulan como costes fijos.
Diez servidores que no se usan ya son un factor de degradación del rendimiento. Vale la pena revisarlos periódicamente.
Conclusión
En última instancia, la ingeniería de contexto consiste en gestionar la relevancia. No se trata de llenar una ventana grande, sino de mantener en el escritorio del modelo solo lo relacionado con el trabajo actual.
Cuando el bucle de ejecución tratado en la parte sobre ingeniería de harness se combina con la gestión presupuestaria de este artículo, se completa la visión general del diseño de agentes. En el próximo artículo veremos un caso de una canalización ensamblada en la práctica.