Brief IA : OpenAI et Playwright : transformer les LLM en navigateurs autonomes

OpenAI et Playwright : transformer les LLM en navigateurs autonomes

Brief IA
Tom Levy·7 min·1 vues

OpenAI et Playwright permettent aux agents LLM d'interagir directement avec les navigateurs, révolutionnant les flux de travail. Un agent LLM peut désormais résoudre des demandes de support client via une console web, grâce à une boucle d'interaction continue. Playwright MCP offre une lecture structurée des pages web, facilitant l'automatisation précise des tâches par les agents.

En bref
1OpenAI et Playwright permettent aux agents LLM d'interagir directement avec les navigateurs, révolutionnant les flux de travail.
2Un agent LLM peut désormais résoudre des demandes de support client via une console web, grâce à une boucle d'interaction continue.
3Playwright MCP offre une lecture structurée des pages web, facilitant l'automatisation précise des tâches par les agents.
💡Pourquoi c'est importantCette avancée renforce l'autonomie des LLM, ouvrant la voie à des applications plus complexes et interactives dans divers secteurs.
Le brief IA que lisent les pros

Tu codes avec l’IA ?

Outils, agents et nouveautés dev IA décryptés, chaque soir en 5 min. Gratuit.

Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.

Choisis ton rythme

Gratuit · Pas de spam · Désabonnement en 1 clic

📄
L'analyse en français

Applications des modèles de langage étendu (LLM)

L'intégration d'un agent LLM avec un navigateur web représente une avancée significative dans l'amélioration des flux de travail automatisés. En utilisant le OpenAI Agents SDK et Playwright MCP, nous pouvons créer un agent capable de naviguer et d'interagir avec des pages web de manière autonome. Cet article explore comment cette technologie fonctionne et présente une étude de cas pratique pour illustrer son application.

1. Comprendre le modèle mental

Un agent LLM qui utilise un navigateur fonctionne essentiellement en boucle continue d'interaction. Cette boucle débute avec une tâche donnée et l'état actuel du navigateur. L'agent évalue cet état, choisit une action à entreprendre, et transmet cette action au navigateur. Le navigateur réagit, modifiant son état, ce qui devient alors la nouvelle entrée pour l'agent. Ce processus se répète jusqu'à ce que l'agent juge la tâche accomplie.

Pour que cette boucle fonctionne, deux types de connexions sont nécessaires entre l'agent et le navigateur :

  • Un canal d'observation, qui permet à l'agent de recevoir l'état actuel du navigateur.
  • Un canal d'action, qui permet à l'agent d'interagir avec le navigateur.

Les canaux d'observation peuvent inclure des captures d'écran ou des informations structurées sur la page, telles que le Document Object Model (DOM) ou l'arbre d'accessibilité. Pour le canal d'action, l'agent peut utiliser des commandes de souris et de clavier, cibler des éléments spécifiques de la page, ou émettre des commandes de navigateur de niveau supérieur.

Bien que les choix d'observation et d'action soient généralement indépendants, deux associations courantes sont observées :

  • Capture d'écran avec actions de souris et clavier basées sur des coordonnées.
  • État de page structuré avec actions ciblées sur des éléments.

Dans cet article, nous nous concentrons sur l'utilisation des observations de page structurées avec des actions de navigateur ciblées sur des éléments.

2. Étude de cas : Résolution d'une demande de support client

Pour illustrer l'application pratique de cette technologie, nous avons développé un agent utilisant un navigateur pour résoudre une demande client via une console de support web.

2.1 Préparation de la console de support

Nous avons conçu une console de support client simple, construite avec HTML, CSS, et JavaScript. Cette application web statique ne nécessite pas de backend ou de base de données, car toutes les données résident dans le navigateur. La console peut être servie localement à l'aide du serveur HTTP intégré de Python :

python -m http.server 8000 --bind 127.0.0.1

Cela rend la console accessible à l'adresse http://127.0.0.1:8000, que nous transmettrons à l'agent sous le nom de APP_URL.

La console est divisée en deux parties : une boîte de réception de support à gauche, et une section affichant la commande associée, le contexte client, et les politiques de résolution à droite. L'agent doit examiner une demande de support entrante et la résoudre entièrement via cette interface.

2.2 Configuration de l'agent utilisant un navigateur

Pour configurer l'agent, nous utilisons le OpenAI Agents SDK pour l'exécution et Playwright MCP pour la connexion au navigateur. Voici comment se présente notre agent configuré :

# pip install openai-agents
from agents import Agent, ModelSettings
from openai.types.shared import Reasoning

name="Support Console Browser Agent",
model="[gpt](/glossaire/gpt)-5.4",
model_settings=ModelSettings(
reasoning=Reasoning(effort="medium"),
instructions=AGENT_INSTRUCTIONS,
mcp_servers=[playwright_server],

Trois éléments sont essentiels ici : le client LLM, l'instruction de l'agent, et les outils du navigateur.

Nous connectons d'abord le Agents SDK à Azure OpenAI :

from openai import AsyncAzureOpenAI
from agents import (
set_default_openai_api,
set_default_openai_client,
azure_client = AsyncAzureOpenAI(
api_key=os.environ["OPENAI_API_KEY"],
api_version=os.environ["OPENAI_API_VERSION"],
azure_endpoint=os.environ["OPENAI_API_BASE"],
set_default_openai_client(azure_client)
set_default_openai_api("responses")

Nous enregistrons le client avec le Agents SDK et le configurons pour utiliser l'API Responses.

Ensuite, nous définissons l'instruction de l'agent de manière minimale :

AGENT_INSTRUCTIONS = """
Vous êtes un agent qui peut interagir avec un navigateur web.
"""

Nous avons seulement défini le rôle de l'agent. La tâche réelle sera précisée dans l'invite envoyée à l'agent.

Nous devons ensuite configurer Playwright MCP. Playwright est une bibliothèque d'automatisation de navigateur qui contrôle un navigateur réel pour effectuer des actions comme des clics et des saisies. MCP (Model Context Protocol) expose ces capacités comme des outils que l'agent peut utiliser.

Playwright MCP utilise Node.js. Pour l'installer sur Windows :

winget install OpenJS.NodeJS.LTS
brew install node
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
\. "$HOME/.nvm/nvm.sh"
nvm install --lts

Ensuite, vérifiez l'installation. Nous configurons le Agents SDK pour démarrer le serveur MCP via la commande npx suivante :

from agents.mcp import MCPServerStdio
playwright_server = MCPServerStdio(
name="Playwright MCP",
"command": "npx",
"@playwright/mcp@latest",

Ici, npx récupère et exécute le dernier package Playwright MCP. Le drapeau -y accepte automatiquement l'invite de confirmation de npx, tandis que --browser chrome indique à Playwright quel navigateur lancer. Chrome est le navigateur par défaut de Playwright MCP, et s'il est déjà installé, aucune installation séparée n'est requise.

MCPServerStdio configure le Agents SDK pour lancer Playwright MCP en tant que processus local. Lorsque l'agent appelle pour la première fois un outil de navigateur, Playwright MCP ouvre une fenêtre Chrome visible et exécute l'action de navigateur demandée.

2.3 Exécution de l'agent

Nous pouvons maintenant donner à l'agent une tâche concrète :

APP_URL = "http://127.0.0.1:8000"
Open {APP_URL} and resolve the support case for order ORD-1042.
The customer says they received the wrong item. Use the information available in the
application to determine and apply the appropriate resolution. Add a concise internal
note and [make](/outil/make) sure the resolution was successfully recorded.
Report what you did when the task is complete.

Dans l'invite de tâche, nous avons décrit comment accéder à l'application et le résultat souhaité.

Nous exécutons ensuite l'agent avec :

from agents import Runner
async with playwright_server:
result = await Runner.run(
print(result.final_output)

Le bloc async with démarre le processus Playwright MCP et le maintient connecté pendant que l'agent s'exécute. Nous utilisons max_turns pour définir une limite supérieure sur le nombre de tours que l'agent peut prendre.

Une fois démarré, Chrome s'ouvrirait, et nous pourrions observer l'agent travailler à travers la console de support.

La réponse finale résume correctement le résultat :

Resolved CASE-4107 for order ORD-1042 with Replacement.

Le cas montre maintenant Résolu, l'action enregistrée est Replacement, et le journal d'audit contient l'entrée de résolution correspondante.

Si vous le souhaitez, vous pouvez également inspecter les appels d'outils du navigateur et leurs sorties de cette manière :

for item in result.new_items:
print(type(item).__name__, item)

Lors de mon exécution, l'agent a trouvé le cas associé à ORD-1042 et a inspecté la commande, la demande du client, l'état de l'inventaire et la politique de résolution pertinente. Il a ensuite conclu qu'un remplacement était approprié, ajouté une note interne et soumis la résolution. Enfin, il a vérifié le cas mis à jour et le journal d'audit pour confirmer que l'action avait été enregistrée.

C'est exactement le comportement agentique que nous souhaitons.

3. De l'utilisation du navigateur à l'utilisation de l'ordinateur

Ce que nous avons construit dans cette étude de cas est un agent utilisant un navigateur. Cependant, le modèle sous-jacent, c'est-à-dire la boucle observer, décider, agir et répéter, s'étend naturellement à l'utilisation générale de l'ordinateur.

Ce qui change, ce sont les canaux d'observation et d'action.

Dans notre cas, Playwright MCP fournit à l'agent des informations structurées sur la page et lui permet de cibler des éléments web individuels. Un agent d'utilisation plus général de l'ordinateur pourrait plutôt fonctionner à partir de captures d'écran et contrôler la souris et le clavier par coordonnées.

Vous pouvez trouver le dépôt de notre étude de cas ici : https://github.com/ShuaiGuo16/llm-browser-agent/tree/main

Suivez Brief IA

L'actu IA du jour, aussi dans votre fil.

Commentaires