Ingeniería de IA
agent-browser 0.41.1 corrige esperas que podían aparentar éxito
Una corrección en MCP distingue un selector inválido de una pausa. Qué comprobar al actualizar una automatización de navegador y sus permisos.
Una espera que no comprobaba lo esperado
agent-browser 0.41.1, publicado el 1 de noviembre, corrige un caso en el que una espera enviada por MCP podía devolver éxito sin haber comprobado un elemento de la página. Un selector formado solo por un entero se interpretaba como una pausa. El cambio resulta útil para equipos que automatizan navegadores con agentes, porque separa dos resultados que pueden parecer iguales en un registro: ha terminado un comando y se ha cumplido la condición buscada.
La herramienta de Vercel Labs permite que un agente abra una página, lea una representación textual de sus elementos y actúe sobre ellos. Esa representación, o snapshot, asigna referencias que ayudan a elegir un botón o un campo. El modelo decide el siguiente paso; el programa ejecuta la interacción. Un fallo en ese límite puede alterar el recorrido aunque el razonamiento del modelo parezca correcto.
El caso del selector numérico
La corrección de MCP describe un ejemplo concreto: el selector 7 podía convertirse en una espera de siete milisegundos. Al acabar ese tiempo, la operación se daba por completada. Esto no demostraba que hubiera aparecido un elemento identificado por ese número. En la versión corregida, ese parámetro se rechaza con un error y orientación para seleccionar identificadores numéricos. Es el comportamiento descrito por los mantenedores en la propuesta de cambio; aquí no se ha ejecutado una reproducción independiente.
La diferencia afecta al contrato entre el agente y la herramienta. Una operación que espera un selector debe recibir una forma válida de identificar el objetivo. Una operación que duerme durante un intervalo solo acredita que ha transcurrido ese tiempo. Que ambas acepten texto parecido no las convierte en intercambiables.
Un ejemplo al comprobar un formulario
Un agente que envía un formulario de prueba puede seguir tres pasos: localizar el botón, activarlo y comprobar que aparece la confirmación esperada. Una pausa entre los dos últimos puede ayudar a observar una carga, pero no demuestra que el envío haya funcionado. También podría haber terminado con un error de validación, una sesión caducada o una pantalla distinta.
Para revisar una actualización, prepararía un caso que deba terminar bien y otro cuyo selector sea inválido. El primero debe alcanzar el estado previsto; el segundo debe devolver un fallo reconocible que el agente pueda corregir o comunicar. Si ambos salen como éxito, el registro no permite distinguir una comprobación de una espera vacía. Es una propuesta de prueba sobre un entorno controlado, no el resultado de un ensayo realizado con esta versión.
También conviene volver a observar la página después de una interacción y siempre tras navegar. La documentación distingue los elementos que permanecen, cuyas referencias pueden conservarse, de los reemplazados o de una página nueva, cuyas referencias se invalidan. Renovar el snapshot permite comprobar cuál es el estado actual antes de continuar.
La actualización también toca los permisos de la skill
La misma entrega retira de la skill instalada un permiso predeterminado para ejecutar un paquete mediante npx sin fijar su versión. La propuesta mantiene el permiso del comando agent-browser ya instalado. El alcance es esa configuración de permisos de la skill; el cambio no implica que cualquier uso de npx esté prohibido ni convierte por sí solo una sesión de navegador en un entorno aislado.
Esto plantea una revisión adicional para quien haya copiado instrucciones a su propio catálogo. Actualizar el ejecutable y actualizar una copia de la skill son tareas distintas. Comprobaría cuál usa el agente, qué versión del programa invoca y qué acciones puede ejecutar sin otra intervención. La publicación de un cambio en el repositorio original no demuestra que una copia local lo haya recibido.
Qué conviene validar antes de dar la actualización por terminada
Priorizaría la revisión de los flujos que usan esperas por MCP o permisos copiados de versiones anteriores. Guardaría la versión del ejecutable y de las instrucciones junto al resultado esperado del recorrido. Después comprobaría el caso normal, el fallo de selector y la lectura de la página tras una transición. Así se puede atribuir un resultado al conjunto que realmente se ha probado.
Esta entrega corrige comportamientos concretos. No aporta en estas fuentes una medición independiente de más tareas completadas ni una garantía de que cualquier automatización vaya a funcionar. Su interés práctico es más preciso: un parámetro inválido puede dejar de parecer una condición satisfecha. Para evaluar un agente, esa distinción vale más que contar comandos terminados.