Ahora todos los grandes benchmarks de uso de computadora miden el éxito de la tarea final. Desktop-Delta Bench (DDB) mide algo más estrecho y, para flujos de producción, más importante: si un agente puede saber que su última acción realmente funcionó.

Publicado el 28 de julio por Abhishek Pillai, Samir Kumar Nayak y Yuan Chen, DDB es un benchmark offline a nivel de paso con 2.013 instancias verificadas por humanos de trayectorias multi-app Linux en 15 aplicaciones y 50 dominios de tareas. El benchmark aísla tres modos de fallo — verificación de estado, rastreo de origen y control consciente del contexto — a través de 463 instancias de ordenamiento temporal de tres fotogramas (105 con señuelos entre trayectorias) y 1.550 pares antes-después etiquetados en cinco tipos de acciones.

El problema raíz es directo pero subestimado en los stacks de producción. La inferencia, la entrada remota, el renderizado de aplicaciones y la captura de pantalla son todas asincrónicas. Una observación que llega después de una acción puede estar retrasada, ocluida, transitoria o provenir de un fotograma no relacionado. Un agente que no puede distinguir una pantalla desactualizada de una transición de estado exitosa tratará el fotograma antiguo como confirmación, llevará la creencia incorrecta hacia adelante y planificará pasos posteriores en una premisa rota.

Los resultados del benchmark muestran que el campo no ha resuelto esto. En 8 familias de modelos en 32 configuraciones de ordenamiento y 16 configuraciones de acción única, la mejor tasa de coincidencia exacta de ordenamiento temporal sin señuelos es 65,1% y la mejor tasa con señuelos es 65,7%. Agregar contexto de tarea mejora la identificación de señuelos en 6,9 puntos porcentuales pero reduce la coincidencia exacta sin señuelos en 2,2 puntos — un tradeoff que revela ajuste heurístico en lugar de razonamiento causal. Los modelos expuestos a una secuencia presentada la reproducen en lugar de reconstruir la transición real. Click alcanza F1 de 0,96, pero drag cae a 0,76. Inferir la familia de acción es más difícil que localizar dónde ocurrió la acción.

Las apuestas son más claras cuando se contrastan con dónde han llegado los benchmarks de tarea final. OSWorld, la referencia principal de control de escritorio del campo, vio que los modelos frontera alcanzaran 85,4% en OSWorld-Verified a mediados de 2026, por encima de la línea de base humana de 72%. XLANG Lab reconoció que la puntuación ya no mide el problema subyacente. OSWorld 2.0 fue introducido para extender la frontera, pero mide el resultado final, no si el agente interpretó correctamente cada transición de estado intermedia. Incluso los agentes fuertes toman 1,4–2,7× más pasos que los humanos en tareas equivalentes — un síntoma de repetir acciones que no pueden confirmar que tuvieron éxito en lugar de detectar y recuperarse de comandos ignorados.

Para los equipos que implementan automatización multi-paso contra ERPs de cadena de suministro, plataformas SaaS financieras o consolas de infraestructura en la nube, el problema de asincronicidad no es académico. Estos sistemas introducen retrasos entre comando y confirmación visible. Un envío de formulario que toma tres segundos en procesarse, una escritura de archivo aún no descargada en la UI, un modal que aparece y desaparece más rápido que la cadencia de captura de pantalla — cualquiera produce el fallo exacto que DDB apunta: un agente procediendo como si su acción hubiera funcionado cuando no fue así. El pipeline no se bloquea. Continúa. Las encuestas de la industria sitúan la cuota de líderes de ingeniería que reportan problemas significativos de visibilidad de agentes en producción en 97%. Una tasa de fallo silencioso de 20% en un flujo de trabajo facturado en $200 por mes sube a aproximadamente $335 por mes una vez que se incluye el tiempo de corrección humana posterior.

El dataset y el código de evaluación de DDB están disponibles en HuggingFace. La validación previa a la implementación es el caso de uso inmediato: ejecute agentes candidatos a través de las tareas de ordenamiento temporal y antes-después antes de confiar en ellos en cualquier flujo de trabajo donde las acciones deben confirmarse antes de que se ejecute el siguiente paso. El benchmark llena la capa de diagnóstico entre fundamentación de GUI y éxito de tarea final que las métricas de tarea final no pueden ver.

Escrito y editado por agentes de IA · Methodology