Esta es la segunda nota de una serie sobre el diseño de agentes de largo horizonte, motivada por una lectura detenida de BEACON (Universidad de Zhejiang, arXiv:2605.06078).
La primera nota sostenía que la detección de bucles no puede detectar a un agente estancado, porque la repetición es una señal de entrada, mientras que el progreso es una señal de salida. Ese argumento solo funciona si hay algo con lo que medir el progreso. Esta nota trata sobre ese algo.
Plantear bien la pregunta
La pregunta no es "cómo sabe el agente que terminó un paso". Es "cómo sabe el sistema que realmente lo terminó, en lugar de limitarse a anunciar que lo hizo".
Solo hay una capa de diferencia, pero la credibilidad no es comparable.
Ya teníamos las dos mitades y nunca las conectamos
Al leer nuestra propia implementación, esta fue la parte sorprendente.
La primera mitad. Los hitos ya existen en el producto. Una herramienta mantiene un plan de tarea persistente: cómo se descompone una tarea larga y en qué estado está cada paso: pendiente, en curso, completado o bloqueado. Su propósito declarado es dar a una tarea larga una referencia estable de progreso. Pero ¿cómo pasa un paso a estar "completado"? El modelo lo declara.
La segunda mitad. Después de cada llamada a una herramienta, el sistema anfitrión registra un conjunto de hechos deterministas: si el hash del contenido de un archivo realmente cambió, cuál fue el código de salida de un comando y si se agotó el tiempo de espera. Estos hechos se registran del lado del sistema anfitrión y nunca entran en el contexto del modelo, precisamente por lo que no pueden inventarse.
Ahí está la brecha. Una línea dice terminé. La otra dice el hash de un archivo pasó de A a B. Nunca se han puesto una al lado de la otra.
Lo que falta no es una estructura de datos ni observabilidad. Es el puente entre ambas.
Lo más útil del artículo no es la fórmula
BEACON es más conocido por su ventaja de doble escala, pero la parte que vale la pena adoptar es cómo plantea el detector Φ.
Φ no necesita un modelo entrenado ni anotación humana. Solo lee cambios de estado observables en la información que devuelve el entorno: transiciones de estado de objetos en ALFWorld (recogido correctamente, calentamiento terminado), transiciones de página en WebShop y, en ScienceWorld, simplemente consume la señal de subobjetivo que el entorno ya emite.
Ningún modelo adicional, ningún costo adicional de muestreo. Compáralo con las alternativas: un modelo de recompensa del proceso necesita anotación costosa y se puede manipular, y la estimación del valor mediante Monte Carlo necesita trayectorias de ejecución adicionales en cada punto de decisión. Ese es el costo que Φ evita.
Quien construya un producto de agentes tiene una ventaja que los entornos del artículo no ofrecen: las llamadas a herramientas ya son estructuradas, con éxito y fallo explícitos. El artículo tuvo que extraer señales de un entorno. Las nuestras ya están ahí.
Tres capas, si fueras a construirlo
Primera capa: reunir pruebas deterministas en un solo flujo. Sin ningún juicio semántico, solo un registro mecánico de cambios irreversibles y verificables. El hash del contenido de un archivo cambió. Un comando terminó con código cero. Una llamada a una API externa devolvió un resultado satisfactorio. Se confirmó una fila. Todo esto existe hoy. Simplemente está disperso, nunca se ha reunido en un único registro de los hechos establecidos hasta el momento.
Segunda capa: conectar las dos mitades. El paso de mayor valor. Cuando el modelo declare que un paso está completado, deja de creerlo sin más y busca pruebas de la primera capa en ese intervalo. Si hay pruebas, márcalo como finalización verificada. Si no las hay, márcalo como finalización declarada. Esto no impide que el modelo declare nada; solo separa lo respaldado de lo que no lo está.
Tercera capa: definir Φ por tipo de capacidad. Los autores admiten que Φ requiere conocimiento del dominio y generaliza mal, así que no esperes un detector universal. Las tareas de programación observan los códigos de salida de las pruebas. Las tareas de análisis de datos observan si se generó el archivo de salida. Las tareas de mensajería observan la respuesta de la API. Esta capa se desarrolla poco a poco, una capacidad a la vez.
Un criterio que añadimos: irreversibilidad, no importancia
Este no aparece en el artículo.
Los hitos de BEACON funcionan porque marcan transiciones de estado que no se pueden deshacer. Una vez que tienes la llave, el mundo es distinto. Por tanto, el criterio debería ser si esta acción produjo un efecto externo irreversible, en lugar de si este paso fue importante.
Irreversible: escribir un archivo, confirmar cambios de código, enviar un mensaje, llamar a una API de pago, confirmar una transacción en una base de datos. Reversible: leer un archivo, buscar, obtener una página, pensar.
De ahí se desprenden dos cosas. Se puede determinar de forma mecánica, porque el tipo de acción lo resuelve: no hace falta comprensión semántica ni se introduce la subjetividad de que "el modelo pensó que este paso importaba". Además, coincide con los puntos de recuperación: reanudar desde un límite irreversible es la única forma de reanudación que tiene sentido, ya que las acciones reversibles pueden repetirse sin más.
Dos cifras: una para dar confianza y otra para ser prudentes
La que da confianza es la del experimento de degradación. Si se elimina aleatoriamente la mitad de los hitos, la puntuación sigue siendo 82.8, frente a una referencia de 72.8: diez puntos por encima. La degradación es gradual, no una caída abrupta. Para quien vaya a poner esto en producción, esa es la parte importante: no hace falta que Φ sea perfecto antes de atreverse a activarlo. Cubrir la mitad ya compensa.
La que invita a la cautela es la comparación de particiones.
| Partición | Puntuación | Frente a la referencia (72.8) |
|---|---|---|
| División aleatoria en 5 partes | 74.2 | +1.4 |
| Hitos reales | 91.4 | +17.2 |
La primera nota también citaba estas cifras, pero aquí la implicación es más directa. Si defines los hitos por intuición, equivalen aproximadamente a una división aleatoria y el trabajo se desperdicia. Los hitos tienen valor precisamente cuando coinciden con la estructura real de la tarea.
Dónde hay que matizar estos resultados
El propio apéndice del artículo enumera el descubrimiento automático de hitos como un problema abierto. Las tres pruebas de referencia obtienen sus hitos mediante reglas: coincidencia de patrones en las respuestas del entorno, transiciones de página o una señal que el entorno entrega directamente. Los entornos realmente abiertos —operación de navegadores, refactorización de bases de código, investigación profunda— no cuentan con una transición verificable ya disponible.
Por tanto, este es un paradigma validado en entornos estructurados, no una solución que puedas trasladar íntegramente. Lo que permite aplicarlo en un producto de agentes es el límite estructurado de la llamada a una herramienta, no una respuesta que el artículo ya haya proporcionado.
La otra trampa es la granularidad. Si los hitos son demasiado escasos, no has conseguido nada; si son demasiado densos, la señal a nivel de segmento se convierte en ruido. En términos de producto, esa es la granularidad de la descomposición de tareas, y aquí hay una ventaja que falta en los entornos del artículo. Los pasos del plan están diseñados para mostrarse al usuario, así que la granularidad puede basarse en si una persona puede comprender el paso, en lugar de ajustarse únicamente mediante un algoritmo.
Si solo haces una cosa
Implementa la segunda capa.
Es barata, porque los datos de la primera capa ya existen y la segunda solo los correlaciona con las declaraciones del modelo. Es verificable de forma independiente, porque la proporción de finalizaciones verificadas respecto de las declaradas es en sí misma una métrica que merece seguimiento. Y es la condición previa para todo lo demás: sin una noción de hito verificado, tanto la detección de estancamiento de la primera nota como el límite de compactación de la siguiente carecen de base.
También tiene una propiedad conveniente. Incorporarla no cambia ningún comportamiento: el modelo declara los pasos exactamente igual que antes, solo se añade una marca. Una vez que se acumulen los datos, puedes decidir si intervenir en las declaraciones que llegaron sin pruebas.
La siguiente nota trata sobre la compactación del contexto: por qué cortar al alcanzar un umbral de tokens tiene poco que ver con lo que se puede olvidar de forma segura, y una corrección a la manera más natural de ampliar esta nota, que consiste en suponer que, una vez verificado un hito, todo lo anterior puede compactarse.