Tu agente llega al 80% de su ventana de contexto. Se activa la compactación y se descartan los turnos más antiguos. Diez minutos después, vuelve a leer un archivo que ya había leído y vuelve a hacer una pregunta que ya había respondido.
El umbral sabía que te quedabas sin espacio. No sabía qué se podía perder sin consecuencias.
Esta es la tercera entrega de una serie sobre el diseño de agentes de largo horizonte, motivada por una lectura detallada de BEACON (Universidad de Zhejiang, arXiv:2605.06078). La primera trató la detección de estancamientos; la segunda, el diseño de hitos.
Empecemos por nuestra propia implementación
Orkas es un cliente de escritorio multiagente. Las tareas largas son lo habitual aquí, así que la compactación surge a diario. Nuestra implementación se activa al alcanzar un umbral de tokens y compacta cuando el contexto ocupa aproximadamente el 80% de la ventana. Hasta que escribimos este texto, ninguno de nosotros pensaba que hubiera nada malo en ello.
En la práctica, hay unos tres criterios de corte habituales: un porcentaje de la ventana, un número de turnos o dejar que el modelo escriba un resumen que abarque el contenido antiguo. El nuestro es del primer tipo.
Los dos primeros no examinan el contenido en absoluto. El tercero sí, pero deja enteramente en manos del modelo la decisión sobre qué importa.
Los tres responden a cuándo tengo que descartar algo. La pregunta que realmente te haces es qué puedo descartar sin consecuencias. Cortar al llegar al umbral elimina el contenido más antiguo, no el menos importante.
El hito como límite y el supuesto que lo sustenta
Los hitos de la entrega anterior podrían ofrecer un mejor criterio de corte que cualquiera de los tres. Pero aquí hay una trampa, y la entrega anterior pasó por ella con demasiada ligereza.
BEACON incluye un supuesto llamado propiedad de Markov de los hitos. En términos sencillos: una vez que alcanzas un hito, lo que ocurre después depende solo de los subobjetivos pendientes, no de cómo llegaste hasta allí. Una vez que tienes la llave, lo que importa es qué puerta abres, no cómo la encontraste.
Eso parece dar permiso para compactar: una vez superado un hito, se puede condensar y apartar el tramo anterior.
Pero es un supuesto, no un hecho. El artículo escribe ≈, no =, y los autores analizan dónde falla.
Adecuado para el entrenamiento, insuficiente para la compactación
El mismo supuesto, dos usos, con un orden de magnitud de diferencia en cuanto a exigencia.
En el entrenamiento solo tiene que cumplirse estadísticamente. Si unas pocas decenas de entre varios miles de trayectorias de ejecución lo incumplen, el sesgo se compensa al promediar. El entrenamiento también incorpora una señal a nivel de trayectoria como respaldo; al eliminar esa capa, ALFWorld cae de 91.4 a 23.4, muy por debajo de no hacer nada.
En la compactación tiene que cumplirse en cada caso individual, para la única ejecución que tienes delante. Descarta lo equivocado una sola vez y esa tarea queda perdida. No hay nada sobre lo que promediar.
Así que el hecho de que el artículo se apoye en este supuesto no significa que puedas trasladarlo a la compactación. Los dos usos no le exigen lo mismo.
Cuatro casos en los que falla
Los usamos como lista de comprobación al evaluar una política de compactación.
1. Conocimiento implícito acumulado por el camino. En algún momento inicial, un paso establece que cierta API devuelve las marcas de tiempo en UTC. Ese dato no pertenece a ningún hito, y todos los pasos posteriores lo necesitan.
2. Recursos ya consumidos. Presupuesto de tokens, cuota de llamadas, tiempo restante. Un hito no registra he gastado el 60% del presupuesto, pero esa cifra determina si aún se puede costear un reintento.
3. Efectos secundarios que dependen del recorrido. El hito dice refactorización completada. En cuanto empieza la depuración, necesitas saber qué cinco archivos se modificaron realmente.
4. El propio hito no está suficientemente definido. Este es el peor de los cuatro. En el artículo, un hito es un estado completo del entorno: tienes la llave o no la tienes, sin ambigüedad. Un paso del plan es una frase en lenguaje natural. «Terminar la limpieza de datos» está muy lejos de abarcar lo que ocurrió durante ese tramo.
Qué conservar en su lugar
No conserves solo un resumen. El resumen lo escribe el modelo, que decide por intuición qué fue importante.
Conserva un conjunto fijo de campos, elegidos por una persona. Como mínimo, cuatro:
- Cómo está el espacio de trabajo ahora: qué archivos se modificaron y en qué estado quedaron.
- Qué presupuesto queda: tokens, cuota de llamadas, tiempo.
- Qué se ha establecido: el dato sobre UTC y todos los similares que condicionarán las decisiones posteriores.
- Qué sigue sin resolverse: aquello que bloqueó el avance una vez, se sorteó y podría volver a aparecer.
Compáralos con los cuatro casos de fallo anteriores y verás que se corresponden uno a uno. Esa correspondencia es la forma más sencilla de juzgar si una política de compactación es suficiente.
La mitad de esto tiene un costo casi nulo. Como describía la entrega anterior, el sistema anfitrión ya registra hechos deterministas después de cada llamada a una herramienta: si un archivo se reescribió de verdad, si un comando se ejecutó realmente. Esos datos se recopilaron para verificar hitos, pero son la instantánea del espacio de trabajo, así que la compactación puede conservarlos directamente sin pedirle a un modelo que vuelva a resumirlos.
La mitad difícil son los otros dos campos. Actualmente, lo que se ha establecido y lo que sigue sin resolverse solo existe si el modelo lo anota, y por eso es lo primero que se pierde con la compactación.
Esto se mide, no se debate
Si después de la compactación el agente vuelve a leer un archivo cuyo contenido se descartó, o vuelve a hacer una pregunta ya respondida, el supuesto falló en esa tarea y la evidencia está ahí mismo.
La instrumentación es sencilla: cruza las rutas de los archivos leídos después del punto de compactación con las registradas antes.
Con esa cifra, qué tipos de tareas admiten una compactación agresiva y cuáles no pasa a ser una consulta de datos en lugar de un debate de diseño. Es el mismo enfoque que en la primera entrega de esta serie: primero medir, luego cambiar algo.
Qué salvedades hay que tener en cuenta
Nada de esto se ha lanzado todavía. Estamos en la fase de diseño e instrumentación.
Qué campos conservar y con qué nivel de detalle debe determinarse a partir de datos sobre lo que realmente se vuelve a recuperar. Decidirlo ahora es una buena forma de equivocarse.
Y este es un enfoque entre varios. Dónde se sitúa el límite y cómo se definen los campos podría ser completamente distinto en otro tipo de producto. La lista de comprobación de cuatro casos es transferible; la respuesta concreta, no.
La siguiente y última entrega de esta serie trata la autorreflexión: por qué las lecciones que extrae un agente siguen siendo tan genéricas como «tener más cuidado», y un aspecto realmente sorprendente sobre lo que contienen y lo que no contienen sus entradas.