Am 5. August 2026 hat Hermes Agent zwei Updates direkt hintereinander zusammengeführt, die den letzten blinden Fleck auf dem Desktop schließen:

1. PR #77705 — der In-App-Browser und die Preview-Leiste wurden zu echten Layout-Tree-Tabs
2. PR #79482 — ein neues read_preview-Tool erlaubt dem Agenten, den Inhalt der aktuell im In-App-Browser geöffneten Seite zu lesen

In einem Satz: Der Agent konnte schon immer eine Webseite „öffnen“, aber er konnte die geöffnete Seite nicht sehen — jetzt kann er sie lesen. Für alle, die mit Hermes Desktop entwickeln, schließt das den Kreislauf „UI erzeugen → Vorschau öffnen → Ergebnis prüfen → selbst beheben“.

Dieser Artikel wiederholt nicht die PR-Notizen. Er geht auf die technischen Details beider Änderungen ein, auf die Design-Entscheidungen dahinter und darauf, wie man sie tatsächlich einsetzt.

Hintergrund: Der Agent öffnete Seiten „blind“

Ein kurzer Blick auf die Entwicklung der Tools macht den Wert dieser beiden PRs deutlich:

• 22. Juli (PR #69519): open_preview(url[, label]) und focus_pane(...) sind erschienen. Zum ersten Mal konnte der Agent aktiv eine URL, einen localhost-Dev-Server oder eine lokale Datei im Desktop-Vorschaufenster öffnen. Aber Achtung: Er konnte nur öffnen — der Seiteninhalt war eine Blackbox.
• Etwa zur gleichen Zeit erlaubten read_terminal / close_terminal dem Agenten, den Inhalt des eingebetteten Terminal-Panes zu lesen — aber die Web-Seite bekam nie ihr Pendant zum „Lesen“.
• 5. August: Beide PRs kamen zusammen — das Browser-Tab-UI-Refactoring plus das read_preview-Tool.

In den Worten des Maintainers: open_preview konnte eine Seite öffnen und read_terminal den Terminal lesen, aber „Was steht auf dieser Seite?“ blieb unbeantwortet. read_preview schließt diese Lücke.

Update 1: Der In-App-Browser wird zum First-Class-Tab

Vor PR #77705 war die Desktop-Preview-Leiste ein Bürger zweiter Klasse der UI:

• Sie rendert eine eigene, separate Tab-Leiste mit anderer Höhe, eigenem Schließen-Menü und eigener Label-Schreibweise
• Sie hatte ein eigenes ⌘W-Verhalten, das an die Zone des Datei-Browsers geschweißt war (⌘J zog die Vorschau gleich mit weg)
• Die Console/DevTools-Umschalter hingen an der Titelleiste, und ihr Zustand wurde von Click-Handlern gesteuert — das direkte Schließen des DevTools-Fensters ließ den Button im Zustand „an“ hängen

Das Refactoring holt sie vollständig in den Layout-Tree:

• Preview-Tabs sind jetzt Layout-Tree-Kacheln: $previewTabs spiegelt sich über dieselbe paneMirror-Session in die Pane-Beiträge, die auch die Route-Kacheln nutzen. Tab-Leiste, Drag, Stack, Split, gemeinsame Schließen-Befehle, einfaches ⌘W — was der Hauptbereich hat, bekommt auch die Vorschau.
• URL-Tabs heißen „Browser“ — der Tab benennt die Oberfläche, nicht die Seite. Sauberere Semantik.
• ⌘W / ⌃Tab funktionieren jetzt über Preview- und Seiten-Zonen hinweg: Vorher leerte ⌘W über einer einzelnen Vorschau stattdessen den Haupt-Chat. Behoben.
• Session-Drags können jetzt in Preview-/Seiten-Zonen landen — die Asymmetrie beim Hineinziehen ist weg.
• DevTools-Zustand ist ereignisgesteuert: Das Glyph wird von den devtools-opened/closed-Events des Webviews gesteuert, sodass das direkte Schließen des DevTools-Fensters keinen veralteten „an“-Zustand mehr hinterlässt.
• Bonus: Die doppelten i18n-Keys und der gesamte unabhängige Rail-Code wurden gelöscht — unterm Strich weniger Code.

Technische Anmerkung: Die Tab-Leiste selbst wurde zu einem Satz gemeinsamer Primitive abstrahiert (PaneTabStrip, PaneStripGlyph/PaneStripTool, paneTabCloseItems), wobei Glyphen als Daten beigesteuert werden, genau wie die Titelleisten-Tools. Zukünftige Preview-Typen bekommen die einheitliche Tab-Erfahrung gratis.

Update 2: read_preview — die Augen des Agenten

PR #79482 ist das funktionale Herzstück: ein neues read_preview-Tool, das read_terminal durchgängig spiegelt. Keine neue Maschinerie — nur ein zweiter Konsument der bestehenden Struktur:

Tool-Ebene (tools/read_preview_tool.py):

• Per check_fn auf HERMES_DESKTOP auf den Desktop begrenzt — kein Schema-Fußabdruck außerhalb der GUI, genau wie bei den anderen Desktop-Pane-Tools
• Fensterweise Lesevorgänge mit start/count (Zeichen-Offsets): Lange Seiten werden paginiert, statt den Kontext zu fluten

Gateway-Bridge:

• preview.read.request / preview.read.respond über dieselbe Blocking-Prompt-Bridge wie terminal.read
• 45s-Timeout, allow_expired und .expire bei Timeout — eine verspätete Renderer-Antwort löst sich still auf, statt einen Fehler zu werfen

Renderer (preview-reader.ts):

• Das URL-Pane registriert einen Page-Reader: Webview executeJavaScript → Titel + sichtbares innerText
• readActivePreview ermittelt den aktiven Tab und begrenzt einen einzelnen Lesevorgang auf 24k Zeichen
• Datei-/Artifact-Tabs antworten mit ihrer Identität plus einem Verweis auf das passendere Tool (read_file oder das Gespräch selbst) — kein Webview-Roundtrip für Inhalte, für die der Agent bereits ein besseres Tool hat

Der manuelle Test der PR ist ein anschauliches Abnahmeszenario: Reddit im Browser öffnen, fragen „Was ist der Top-Beitrag?“ — der Agent ruft read_preview auf und antwortet von der Seite aus.

So setzt du das tatsächlich ein

1. Selbst-Verifikations-Schleife für die lokale Entwicklung

Der praktischste Fall: Du betreibst eine React-/Vue-App auf localhost:3000 und hast den Agenten gebeten, eine Komponente zu ändern. Jetzt kann er:

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

Vorher änderte der Agent Code „blind“. Jetzt kann er zurücklesen, was die Seite tatsächlich rendert, und den Fix selbst bestätigen.

2. Web-Recherche mit Kontextsicherheit

Nach dem Öffnen eines langen Artikels oder einer Doku-Seite liest der Agent sie mit start/count-Paginierung und holt nur die Absätze in den Kontext, die er braucht — deutlich günstiger, als die ganze Seite hineinzukippen.

3. Zusammen mit den v0.20-Artifacts

Wenn du die Sandbox-Artifact-Vorschauen aus Hermes v0.20 nutzt, kannst du den Agenten jetzt den tatsächlich gerenderten Inhalt generierter HTML-Apps lesen lassen — aus „generieren → Vorschau → Mensch prüft“ wird „generieren → Vorschau → lesen → überarbeiten“.

4. Grenzen und Einschränkungen (wissenswert)

• Nur Desktop: read_preview existiert nur in Hermes Desktop (per HERMES_DESKTOP begrenzt); CLI, TUI und Messaging-Plattformen bekommen es nicht. Gleiches gilt für open_preview/focus_pane.
• Nur sichtbarer Text: Es liefert Titel + innerText — nicht den DOM-Tree, kein Screenshot. Um zu „sehen“, wie eine Seite aussieht, brauchst du weiterhin Screenshot-/Vision-Tools.
• Active-Tab-Semantik: Es liest den aktuell aktiven Tab — bei mehreren offenen Tabs solltest du im Blick behalten, welche Seite der Agent gerade liest.
• 24k-Zeichen-Limit: Einzelne Lesevorgänge sind begrenzt; lange Seiten brauchen Paginierung.

Was das für Entwickler bedeutet

Zwei PRs — „ein UI-Refactoring und ein Tool“ — aber zusammen markieren sie einen Wendepunkt im Interaktionsmodell:

Vorher war der Workflow des Desktop-Agenten „Ich generiere, du schaust zu.“ Er erzeugte HTML oder öffnete eine Seite und wartete dann auf menschliches Feedback. Jetzt wird daraus „Ich generiere, ich öffne, ich lese, ich behebe“ — eine autonome Schleife. read_terminal deckte den Terminal ab; read_preview deckt das Web ab; zusammen mit den bestehenden Datei-Tools ist das „Sensorium“ des Agenten auf Hermes Desktop praktisch vollständig.

Der natürliche nächste Schritt (und worauf die Community wartet): read_preview mit Vision zu kombinieren, damit der Agent nicht nur Text liest, sondern das gerenderte Ergebnis tatsächlich sieht — ab dann ist „eine Webseite lesen“ kaum noch von einem Menschen zu unterscheiden, der einen Browser bedient.

So probierst du es aus

1. Aktualisiere auf den neuesten Desktop-Build: hermes update (oder frisch installieren über die Installationsanleitung)
2. Bitte den Agenten in Hermes Desktop, mit open_preview eine URL zu öffnen
3. Frag ihn „Was steht auf dieser Seite?“ — und sieh zu, wie er read_preview aufruft, um zu antworten

Weitere Desktop-Funktionen findest du in der Hermes-Desktop-Dokumentation, und für das größere v0.20-Update unseren Deep Dive zum Herald-Release.