Lectura ejecutiva · ~60 segundos
El contexto es una selección temporal; Las decisiones y consecuencias que necesitan sobrevivir deben convertirse en artefactos versionados.
Dar “todo el contexto” a un agente parece seguro. En la práctica, el exceso puede ocultar instrucciones, mezclar estados antiguos, aumentar costos y hacer que información irrelevante compita con lo que decide la tarea.
La ingeniería de contexto es la disciplina de ensamblar el conjunto más pequeño de señales capaces de guiar una ejecución y preservar lo que necesita sobrevivir fuera de la ventana.
Resumen ejecutivo
El contexto no es memoria total. Es una selección temporal.
| Operación | Pregunta |
|---|---|
| seleccionar | ¿Qué cambia la decisión ahora? |
| estructura | ¿En qué orden y autoridad entra esto? |
| recuperar | ¿Qué se puede buscar justo a tiempo? |
| comprimir | ¿Qué se puede resumir sin perder consecuencia? |
| subcontratar | ¿Qué debería convertirse en un artefacto versionado? |
| expirar | ¿Qué ya no es válido? |
El chat te ayuda a trabajar. El sistema de registro te ayuda a continuar.
Prompt es solo parte del contexto
El comportamiento de un agente puede depender de:
- instrucciones del sistema;
- objetivo y criterios de la tarea;
- archivos y documentos seleccionados;
- historial de mensajes;
- herramientas y descripciones;
- resultados intermedios;
- estado del medio ambiente;
- memoria recuperada;
- políticas y capacidades;
- retroalimentación de los verificadores.
Cambiar cualquiera de estas partes puede cambiar la salida, incluso con el mismo modelo y la misma frase inicial.
El presupuesto de atención
Las ventanas más grandes no transforman cada token en una señal. Quedan tres problemas:
Contaminación
La instrucción obsoleta o el ejemplo irrelevante ganan peso al estar presentes.
Competencia
Los hechos críticos están distantes o diluidos en material similar.
Ambigüedad de autoridad
El agente no distingue norma canónica, hipótesis, comentario e historia.
El objetivo no es minimizar los tokens por estética. Se trata de maximizar la señal útil y dejar una autoridad explícita.
Un paquete de contexto en capas
Reúna la tarea en el siguiente orden:
- intención: problema, destinatario y resultado;
- autoridad: quién decide y qué acciones están permitidas;
- contratos: requisitos, interfaces, riesgos y no objetivos;
- estado actual: rama, versión, ediciones y evidencia;
- fuentes: archivos o referencias necesarios;
- criterio: cómo comprobarlo y cuándo detenerlo;
- salida: formato de entrega y traspaso.
Esta estructura reduce la posibilidad de que el contexto histórico pase a través de la instrucción actual.
Recuperarse en el momento adecuado
No es necesario que todas las fuentes lleguen antes de la primera acción. En tareas largas, mantenga las etiquetas ligeras y recupere el contenido cuando el paso lo requiera.
Ejemplo:
índice de ADRs -> selecionar ADR relevante -> ler integralmente -> executar -> registrar decisãoEso es mejor que tirar cien ADR por la ventana. La recuperación, sin embargo, necesita:
- fuente confiable;
- búsqueda reproducible;
- versión o fecha;
- registro de lo que se utilizó;
- respaldo cuando la fuente no está disponible.
Los sistemas de agentes públicos diferencian entre historial, sesión, workspace y herramientas; Estas implementaciones refuerzan que el contexto y el entorno son capas, no un solo prompt. [HARNESS31-C2]
¿Qué debería sobrevivir a la sesión?
Si se necesita información para retomar, auditar o corregir, no debe depender únicamente del chat.
Exteriorizar:
- decisión y motivación;
- situación laboral;
- artefactos creados;
- comandos o pruebas relevantes;
- fallas aún abiertas;
- evidencia recopilada;
- próximos pasos y condiciones;
- límites de conclusión.
Utilice archivos versionados, problemas, ADR, manifiestos, puntos de control u otros registros apropiados. El formato depende del producto; El principio es que una consecuencia duradera merece una solución duradera.
Comprimir sin reescribir el historial
Un buen resumen de traspaso separa:
| Tipo | Contenido |
|---|---|
| objetivo | lo que aún queda por lograr |
| terminado | hechos y enlaces verificables |
| decisiones | elecciones y compensaciones |
| estado | rama, entorno y versión |
| cabellos | Condición concreta e intentos. |
| próximos pasos | acciones ordenadas |
| límites | lo que no ha sido probado |
Evite "bien" o "casi listo". Estas etiquetas borran la ruta de escaneo.
El contexto también caduca
El precio, la disponibilidad del modelo, el punto de referencia, la ley y el estado operativo envejecen. Registro:
- observado en;
- válido para;
- revisar después;
- fuente;
- decisión que depende del hecho.
Cuando expire la validez, el sistema deberá buscar nuevamente o bloquear el claim. No permitamos que un texto antiguo siga dictando una decisión actual por inercia.
Subagentes como aislamiento de contexto
Los subagentes pueden mantener investigaciones o especialidades separadas. Esto reduce la competencia detallada en el agente principal, pero crea un nuevo contrato:
- tarea delimitada;
- fuentes permitidas;
- salida estructurada;
- incertidumbres preservadas;
- sin efectos fuera de alcance;
- Síntesis final con atribución.
El paralelismo no soluciona las malas preguntas. Simplemente produce respuestas competitivas más rápido.
Una prueba de calidad del contexto
Antes de correr, pregunta:
- ¿El objetivo cabe en una frase?
- ¿Se distinguen reglas y ejemplos?
- ¿Existe una fuente de verdad para cada hecho material?
- ¿Se ingresó información confidencial innecesariamente?
- ¿Sabe el agente qué no hacer?
- ¿Es verificable el criterio de preparación?
- ¿Se puede retomar el Estado sin esta conversación?
Luego, ablación: retire un bloque y vea si la calidad, el costo o el riesgo cambian. La investigación pública de harness muestra que las capas adicionales pueden aumentar la capacidad y también el costo o la latencia según la tarea; el resultado no es universal. [HARNESS31-C3]
Lo que este artículo prueba y lo que no prueba
Las fuentes de los proveedores describen técnicas de selección, recuperación, compresión y aislamiento de contexto. Son una guía empírica, no un estándar independiente o una garantía de rendimiento para cada aplicación.
Este artículo propone un contrato de contexto para FORGE. El conjunto ideal debe probarse por tarea, modelo, riesgo y horizonte.
Conclusión
La ingeniería de contexto no se trata de acumular conocimientos. Se trata de decidir qué necesita percibir el agente ahora, qué puede buscar más adelante y qué necesita la organización preservar fuera de la sesión.
El mejor contexto no es el más grande. Es lo que hace que sea difícil confundir intención, autoridad, estado y verificación.
Lectura anterior: Agentes de larga duración. Siguiente lectura sugerida: La cola adecuada para la IA.
Nota editorial y de responsabilidad
- Corte de la investigación
- Última revisión
- Correcciones registradas
- No hay correcciones registradas.
El corte anterior corresponde a los claims canónicos. Las fuentes complementarias y sus fechas de consulta se identifican en el cuerpo del artículo.
Este artículo combina fuentes citadas, análisis y experiencia profesional del autor. Los datos verificables y las afirmaciones fácticas están vinculados a sus respectivas fuentes. Las interpretaciones, hipótesis, proyecciones, recomendaciones y opiniones representan el punto de vista profesional del autor en el momento de la publicación; no constituyen hechos probados, promesas de resultados ni asesoramiento jurídico, financiero o técnico aplicable a un caso concreto. Consulte las fuentes originales y a profesionales cualificados antes de tomar decisiones.
Claims y fuentes
HARNESS31-C2
Un harness duradero debe mantener el historial de sesiones, la política de orquestación y el aislamiento de ejecución como límites explícitos, mientras que los adaptadores y complementos evitan que la elección del modelo o canal se convierta en el límite de seguridad.
Límite: Las fuentes muestran dos implementaciones, no un estándar de interoperabilidad neutral. Los permisos reales deben aplicarse y probarse de forma independiente fuera de las opciones del modelo. Este es un input de diseño source-bound; no prueba la adopción del producto, la madurez operativa, la attestation independiente, la clasificación de búsqueda, la citación de IA o el resultado.
- Anthropic — Anthropic, términos de sitio propietario
- Software YC —Software YC, MIT
- Software YC —Software YC, MIT
HARNESS31-C3
Anthropic informa que las capas de planificador, generador y evaluador mejoraron el resultado de una aplicación de larga ejecución al tiempo que aumentaron materialmente el costo y la latencia; FORGE debería requerir evaluaciones y ablación específicas de la tarea antes de que dichas capas sean obligatorias.
Límite: Este es un experimento de proveedor vinculado a un modelo, punto de referencia y tarea de aplicación seleccionados; no puede probar la superioridad universal de las capas de múltiples agentes o evaluadores. Este es un input de diseño source-bound; no prueba la adopción del producto, la madurez operativa, la attestation independiente, la clasificación de búsqueda, la citación de IA o el resultado.
- Anthropic — Anthropic, términos de sitio propietario