Le 5 août 2026, Hermes Agent a fusionné deux mises à jour coup sur coup qui comblent le dernier angle mort du desktop :

1. PR #77705 — le navigateur intégré (in-app browser) et le rail d’aperçu sont devenus de véritables onglets du layout tree
2. PR #79482 — un nouvel outil read_preview permet à l’agent de lire le contenu de la page actuellement ouverte dans le navigateur intégré

En une phrase : l’agent a toujours su « ouvrir » une page web, mais il ne pouvait pas voir la page qu’il ouvrait — désormais, il peut la lire. Pour tous ceux qui développent avec Hermes Desktop, cela boucle la boucle « générer l’UI → ouvrir l’aperçu → inspecter le résultat → corriger soi-même ».

Cet article ne répète pas les notes des PR. Il creuse les détails techniques des deux changements, les compromis de conception qui les sous-tendent et la façon de les utiliser concrètement.

Contexte : l’agent ouvrait les pages « à l’aveugle »

Un rapide coup d’œil à l’évolution des outils rend la valeur de ces deux PR évidente :

• 22 juillet (PR #69519) : open_preview(url[, label]) et focus_pane(...) sont arrivés. Pour la première fois, l’agent pouvait activement ouvrir une URL, un serveur de dev localhost ou un fichier local dans le volet d’aperçu du desktop. Mais notez bien : il ne pouvait qu’ouvrir — le contenu de la page restait une boîte noire.
• À peu près au même moment, read_terminal / close_terminal permettaient à l’agent de lire ce qui s’affichait dans le volet terminal intégré — mais le versant web n’a jamais eu son équivalent « lecture ».
• 5 août : les deux PR sont arrivées ensemble — le refactor UI des onglets navigateur plus l’outil read_preview.

Pour reprendre les mots du mainteneur : open_preview pouvait ouvrir une page et read_terminal pouvait lire le terminal, mais « qu’est-ce que dit cette page ? » restait sans réponse. read_preview comble cette lacune.

Mise à jour 1 : le navigateur intégré devient un onglet de première classe

Avant la PR #77705, le rail d’aperçu du desktop était un citoyen de seconde zone de l’UI :

• Il affichait sa propre barre d’onglets séparée, avec une hauteur différente, son propre menu de fermeture et sa propre casse de libellés
• Il avait son propre comportement ⌘W, soudé à la zone du navigateur de fichiers (⌘J emportait l’aperçu avec lui)
• Les boutons de bascule Console/DevTools étaient accrochés à la barre de titre, et leur état était piloté par des gestionnaires de clic — fermer directement la fenêtre DevTools laissait le bouton bloqué sur « on »

Le refactor l’intègre complètement dans le layout tree :

• Les onglets d’aperçu sont désormais des tuiles du layout tree : $previewTabs se répercute dans les contributions de panne via la même session paneMirror que les tuiles de route. Barre d’onglets, glisser-déposer, empilement, split, verbes de fermeture partagés, simple ⌘W — tout ce qu’a la zone principale, l’aperçu l’a aussi.
• Les onglets URL sont intitulés « Browser » — l’onglet nomme la surface, pas la page. Une sémantique plus propre.
• ⌘W / ⌃Tab fonctionnent désormais sur les zones d’aperçu et de page : auparavant, ⌘W sur un aperçu isolé vidait le chat principal à la place. Corrigé.
• Les glisser-déposer de sessions peuvent atterrir dans les zones d’aperçu/page — l’asymétrie du glisser-déposer a disparu.
• L’état DevTools est piloté par événements : le glyphe est alimenté par les événements devtools-opened/closed du webview, donc fermer directement la fenêtre DevTools ne laisse plus d’état « on » obsolète.
• Bonus : les clés i18n dupliquées et tout le code du rail indépendant ont été supprimés — une réduction nette de code.

Note technique : la barre d’onglets elle-même a été abstraite en un ensemble de primitives partagées (PaneTabStrip, PaneStripGlyph/PaneStripTool, paneTabCloseItems), les glyphes étant fournis comme données, à la manière des outils de la barre de titre. Les futurs types d’aperçu bénéficieront gratuitement de l’expérience d’onglets unifiée.

Mise à jour 2 : read_preview — les yeux de l’agent

La PR #79482 est le cœur fonctionnel : un nouvel outil read_preview qui reflète read_terminal de bout en bout. Pas de nouvelle machinerie — juste un deuxième consommateur de la forme existante :

Couche outil (tools/read_preview_tool.py) :

• Limitée au desktop via check_fn sur HERMES_DESKTOP — aucune empreinte de schéma hors de la GUI, exactement comme les autres outils de panne du desktop
• Lectures fenêtrées avec start/count (offsets de caractères) : les longues pages sont paginées au lieu d’inonder la fenêtre de contexte

Pont gateway :

• preview.read.request / preview.read.respond via le même pont de prompt bloquant que terminal.read
• Timeout de 45 s, allow_expired et .expire en cas de timeout — une réponse tardive du renderer se résout silencieusement au lieu de lever une erreur

Renderer (preview-reader.ts) :

• Le volet URL enregistre un lecteur de page : webview executeJavaScript → title + innerText visible
• readActivePreview résout l’onglet actif, plafonnant une lecture unique à 24k chars
• Les onglets fichier/artifact répondent avec leur identité plus un renvoi vers l’outil le plus approprié (read_file ou la conversation elle-même) — pas d’aller-retour webview pour du contenu pour lequel l’agent a déjà un meilleur outil

Le test manuel de la PR est un scénario d’acceptation parlant : ouvrez Reddit dans le Browser, demandez « quel est le post le plus populaire ? » — l’agent appelle read_preview et répond à partir de la page.

Comment l’utiliser concrètement

1. Boucle d’auto-vérification pour le développement local

Le cas le plus pratique : vous faites tourner une app React/Vue sur localhost:3000 et vous avez demandé à l’agent de modifier un composant. Il peut désormais :

open_preview(localhost:3000)     # open the preview
# …edit code, restart the dev server…
read_preview()                    # read the page's current content and verify the change

Avant, l’agent modifiait le code « à l’aveugle ». Désormais, il peut relire ce que la page rend réellement et confirmer la correction lui-même.

2. Recherche web avec maîtrise du contexte

Après avoir ouvert un long article ou une page de docs, l’agent la lit avec la pagination start/count, n’important dans le contexte que les paragraphes dont il a besoin — bien plus économique que d’y déverser toute la page.

3. En tandem avec les Artifacts de v0.20

Si vous utilisez les aperçus Artifacts sandboxés de Hermes v0.20, vous pouvez désormais faire lire à l’agent le contenu réellement rendu des apps HTML générées — transformant « générer → prévisualiser → revue humaine » en « générer → prévisualiser → lire → réviser ».

4. Limites et frontières (bon à savoir)

• Desktop uniquement : read_preview n’existe que dans Hermes Desktop (conditionné sur HERMES_DESKTOP) ; la CLI, la TUI et les plateformes de messagerie n’y ont pas accès. Idem pour open_preview/focus_pane.
• Texte visible uniquement : il renvoie title + innerText — pas l’arbre DOM, pas une capture d’écran. Pour « voir » à quoi ressemble une page, il vous faut toujours des outils de capture d’écran/vision.
• Sémantique de l’onglet actif : il lit l’onglet actuellement actif — avec plusieurs onglets ouverts, faites attention à la page que l’agent lit.
• Plafond de 24k chars : les lectures uniques sont plafonnées ; les longues pages nécessitent une pagination.

Ce que cela signifie pour les développeurs

Deux PR — « un refactor d’UI et un outil » — mais ensemble, elles marquent un tournant dans le modèle d’interaction :

Avant, le flux de travail de l’agent desktop était « je génère, tu regardes ». Il produisait du HTML ou ouvrait une page, puis attendait le retour humain. Désormais, c’est « je génère, j’ouvre, je lis, je corrige » — une boucle autonome. read_terminal couvrait le terminal ; read_preview couvre le web ; combinés aux outils de fichiers existants, le « sensorium » de l’agent sur Hermes Desktop est pratiquement complet.

La prochaine étape naturelle (et ce que la communauté guette) : associer read_preview à la vision pour que l’agent ne se contente pas de lire le texte mais voie réellement le résultat rendu — à ce moment-là, « lire une page web » devient indiscernable d’un humain qui pilote un navigateur.

Comment l’essayer

1. Mettez à jour vers la dernière build desktop : hermes update (ou installez depuis zéro via le guide d’installation)
2. Dans Hermes Desktop, demandez à l’agent d’appeler open_preview sur une URL
3. Demandez-lui « qu’est-ce que dit cette page ? » — regardez-le appeler read_preview pour répondre

Pour plus de capacités desktop, consultez la documentation Hermes Desktop, et pour la mise à jour v0.20 dans son ensemble, notre analyse approfondie de la Herald release.