Vercel a présenté agent-browser pour les agents IA — accès léger au navigateur sans MCP

Vercel a présenté agent-browser — un outil qui donne aux agents IA un accès au navigateur sans les couches MCP encombrantes. L'idée est simple : montrer aux modèles non pas l'ensemble du DOM de la page, mais seulement une courte liste d'éléments interactifs avec lesquels on peut immédiatement travailler.

Pourquoi MCP Patine

Playwright et Puppeteer ne disparaissent nulle part : ce sont des outils puissants pour les tests e2e, CI/CD et le parsing prédictible. Les problèmes commencent au moment où un navigateur est remis au contrôle du LLM via MCP. Pour qu'un modèle comprenne où cliquer, il a besoin de voir la page.

Normalement, soit le HTML brut, soit un arbre d'accessibilité est envoyé au contexte. Sur les SPA modernes, cela se transforme rapidement en milliers de tokens supplémentaires à chaque étape et consomme la mémoire de l'agent avant même qu'il atteigne son objectif. Selon les données citées par l'auteur de l'analyse, un clic et une capture d'écran d'une page complexe peuvent coûter entre 15 à 200 mille tokens par étape.

Ce n'est pas seulement coûteux, mais aussi instable : le modèle dépense du contexte en lisant l'arbre de la page, commence à se confondre dans les sélecteurs CSS et échoue plus souvent sur les boutons nécessaires. Pour les scénarios déterministes, cette approche est encore tolérable, mais pour un agent autonome qui doit s'orienter rapidement sur le web, elle est trop lourde.

Ce Que Vercel A Fait

La tâche de Vercel était pratique : si un agent écrit lui-même l'interface, il doit être capable d'ouvrir une page, de vérifier un composant et d'effectuer des actions basiques du navigateur. Pour ce faire, l'équipe a simplifié agent-browser et supprimé la connexion précédente avec le daemon Node. La version actuelle est construite comme une CLI légère en Rust qui fonctionne directement avec Chrome DevTools Protocol. En conséquence, l'outil est plus simple à exécuter localement, plus commode à mettre en conteneurs et ne nécessite pas d'infrastructure Node supplémentaire.

• Binaire unique en Rust
• Communication directe avec CDP sans couches supplémentaires
• Zéro dépendance pour Docker et les environnements locaux
• Références courtes au lieu du DOM complet

L'idée clé est une capture d'écran des éléments interactifs. Au lieu d'un arbre géant, l'agent reçoit une liste compacte comme button "Sign In" [ref=e1] ou textbox "Email" [ref=e2], puis fonctionne avec des commandes courtes : ouvrir la page, cliquer @e1, remplir @e2. Ce format ne prend pas des dizaines de milliers mais des centaines de tokens. Pour le LLM, cela réduit considérablement la charge et diminue simultanément le risque qu'une action échoue en raison d'un sélecteur fragile.

Nouvelle Interface pour les Agents

La différence est clairement visible dans un scénario simple : ouvrir un site web et cliquer sur le premier article. Dans le schéma MCP classique, l'agent reçoit d'abord un énorme arbre d'accessibilité, puis cherche le titre nécessaire et essaie d'assembler un sélecteur CSS précis. Tout changement dans la mise en page, une modale de cookies ou un conteneur supplémentaire rend un tel clic fragile. Dans agent-browser l'itinéraire est plus court : ouvrir, puis capture d'écran, puis cliquer par référence courte. Le modèle ne s'appuie pas sur des suppositions sur la structure du DOM, mais sur une carte pré-préparée d'éléments interactifs.

« N'utilisez pas MCP pour le navigateur — économisez vos fenêtres de

contexte et votre argent d'API. »

Il est significatif que Microsoft pousse déjà une idée similaire avec @playwright/cli. Là, l'agent fonctionne aussi par commandes courtes, et l'état du navigateur est stocké en dehors du contexte du modèle. C'est un changement important pour toute la catégorie des outils agentic : le marché s'éloigne de l'idée de diffuser les entrailles du navigateur directement dans le LLM et passe à un schéma où un outil local maintient l'état lui-même, et le modèle ne reçoit que la couche de contrôle minimalement nécessaire. La différence entre les solutions est maintenant plutôt dans l'écosystème : Playwright reste plus lourd, l'approche Rust de Vercel est plus minimaliste.

Ce Que Cela Signifie

L'automatisation du navigateur pour les agents IA commence à se diviser en deux classes. Playwright et Puppeteer classiques restent la base pour les tests complexes et le scraping, mais pour la codification d'agents et la validation rapide d'interfaces, la demande de wrappers CLI légers est de plus en plus visible. La conclusion principale est simple : pour un LLM, il est plus rentable de donner non pas l'ensemble du navigateur, mais une couche compacte de commande et de référence d'éléments. C'est moins cher, plus stable et plus pratique dans le travail réel.