Em 5 de agosto de 2026, o Hermes Agent juntou duas atualizações consecutivas que preenchem o último blind spot do desktop:

1. PR #77705 — o navegador integrado e a preview rail viraram abas reais da layout tree
2. PR #79482 — uma nova ferramenta read_preview permite que o agente leia o conteúdo da página atualmente aberta no navegador integrado

Em uma frase: o agente sempre conseguiu “abrir” uma página web, mas não conseguia ver a página que abria — agora ele consegue ler. Para quem desenvolve com o Hermes Desktop, isso completa o ciclo de “gerar UI → abrir preview → inspecionar o resultado → corrigir você mesmo”.

Este artigo não repete as notas dos PRs. Ele mergulha nos detalhes técnicos das duas mudanças, nos trade-offs de design por trás delas e em como usá-las na prática.

Contexto: o agente abria páginas “no escuro”

Uma olhada rápida na evolução das ferramentas torna óbvio o valor desses dois PRs:

• 22 de julho (PR #69519): open_preview(url[, label]) e focus_pane(...) foram lançados. Pela primeira vez, o agente podia abrir ativamente uma URL, um servidor de desenvolvimento localhost ou um arquivo local no painel de preview do desktop. Mas repare: ele só conseguia abrir — o conteúdo da página era uma caixa-preta.
• Mais ou menos na mesma época, read_terminal / close_terminal permitiam que o agente lesse o que era exibido no painel do terminal embutido — mas o lado web nunca ganhou sua contraparte de “leitura”.
• 5 de agosto: os dois PRs chegaram juntos — o refactor da aba do navegador mais a ferramenta read_preview.

Nas palavras do próprio mantenedor: open_preview abria uma página e read_terminal lia o terminal, mas “o que esta página diz?” não tinha resposta. read_preview fecha essa lacuna.

Atualização 1: o navegador integrado vira uma aba de primeira classe

Antes do PR #77705, a preview rail do desktop era uma cidadã de segunda classe na UI:

• Ela renderizava sua própria barra de abas separada, com altura diferente, menu de fechar próprio e capitalização própria nos rótulos
• Tinha comportamento próprio de ⌘W, soldado à zona do file browser (o ⌘J arrastava a preview junto)
• Os toggles de Console/DevTools ficavam pendurados na titlebar, e o estado deles era dirigido por click handlers — fechar a janela do DevTools diretamente deixava o botão preso em “ligado”

O refactor a traz completamente para dentro da layout tree:

• As abas de preview agora são tiles da layout tree: $previewTabs espelha as contribuições de painel pela mesma sessão paneMirror que os route tiles usam. Barra de abas, arrastar, empilhar, dividir, verbos de fechar compartilhados, ⌘W simples — o que a área principal tem, a preview também ganha.
• Abas de URL são intituladas “Browser” — a aba nomeia a superfície, não a página. Semântica mais limpa.
• ⌘W / ⌃Tab agora funcionam nas zonas de preview e de página: antes, ⌘W sobre uma preview isolada esvaziava o chat principal. Corrigido.
• Arrastes de sessão podem agora cair nas zonas de preview/página — a assimetria do drag-in acabou.
• O estado do DevTools é dirigido por eventos: o glyph é dirigido pelos eventos devtools-opened/closed da webview, então fechar a janela do DevTools diretamente não deixa mais um estado “ligado” obsoleto.
• Bônus: as chaves i18n duplicadas e todo o código independente da rail foram deletados — redução líquida de código.

Nota técnica: a própria barra de abas foi abstraída em um conjunto de primitivas compartilhadas (PaneTabStrip, PaneStripGlyph/PaneStripTool, paneTabCloseItems), com os glyphs contribuídos como dados, do mesmo jeito que as ferramentas da titlebar. Tipos futuros de preview ganham a experiência unificada de abas de graça.

Atualização 2: read_preview — os olhos do agente

O PR #79482 é o núcleo funcional: uma nova ferramenta read_preview que espelha o read_terminal de ponta a ponta. Nenhuma maquinaria nova — apenas um segundo consumidor da forma existente:

Camada de tool (tools/read_preview_tool.py):

• Restrita ao desktop via check_fn em HERMES_DESKTOP — pegada zero no schema fora da GUI, exatamente como as outras ferramentas de painel do desktop
• Leituras em janelas com start/count (offsets de caracteres): páginas longas paginam em vez de inundar a janela de contexto

Ponte do gateway:

• preview.read.request / preview.read.respond pela mesma ponte de prompt bloqueante do terminal.read
• Timeout de 45s, allow_expired e .expire no timeout — uma resposta atrasada do renderer resolve silenciosamente em vez de gerar erro

Renderer (preview-reader.ts):

• O painel de URL registra um leitor de páginas: webview executeJavaScript → title + innerText visível
• readActivePreview resolve a aba ativa, limitando uma leitura única a 24k chars
• Abas de arquivo/artifact respondem com a identidade mais um ponteiro para a ferramenta mais adequada (read_file ou a própria conversa) — sem round-trip pela webview para conteúdo para o qual o agente já tem uma ferramenta melhor

O teste manual do PR é um cenário de aceitação vívido: abra o Reddit no Browser e pergunte “qual é o post mais votado?” — o agente chama read_preview e responde a partir da página.

Como usar na prática

1. Ciclo de autoverificação para desenvolvimento local

O caso mais prático: você está rodando um app React/Vue em localhost:3000 e pediu ao agente para alterar um componente. Agora ele consegue:

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

Antes, o agente alterava código “no escuro”. Agora ele pode reler o que a página realmente renderiza e confirmar a correção por conta própria.

2. Pesquisa web com segurança de contexto

Depois de abrir um artigo longo ou uma página de docs, o agente a lê com paginação start/count, trazendo para o contexto apenas os parágrafos de que precisa — muito mais barato do que despejar a página inteira.

3. Combinando com os Artifacts da v0.20

Se você usa as previews de Artifacts em sandbox do Hermes v0.20, agora você pode fazer o agente ler o conteúdo realmente renderizado dos apps HTML gerados — transformando “gerar → preview → revisão humana” em “gerar → preview → ler → revisar”.

4. Limites e fronteiras (vale a pena saber)

• Somente desktop: o read_preview existe apenas no Hermes Desktop (restrito a HERMES_DESKTOP); o CLI, a TUI e as plataformas de mensageria não o têm. O mesmo vale para open_preview/focus_pane.
• Somente texto visível: ele retorna title + innerText — não a árvore DOM, não um screenshot. Para “ver” a aparência de uma página, você ainda precisa de ferramentas de screenshot/visão.
• Semântica de aba ativa: ele lê a aba atualmente ativa — com várias abas abertas, preste atenção em qual página o agente está lendo.
• 24k char cap: leituras únicas são limitadas; páginas longas precisam de paginação.

O que isso significa para desenvolvedores

Dois PRs — “um refactor de UI e uma ferramenta” — mas juntos marcam um ponto de virada no modelo de interação:

Antes, o fluxo do agente no desktop era “eu gero, você olha”. Ele produzia HTML ou abria uma página e esperava o feedback humano. Agora vira “eu gero, eu abro, eu leio, eu corrijo” — um loop autônomo. O read_terminal cobria o terminal; o read_preview cobre a web; combinados com as ferramentas de arquivo existentes, o “sensorium” do agente no Hermes Desktop está praticamente completo.

O próximo passo natural (e o que a comunidade está de olho): combinar read_preview com visão, para que o agente não apenas leia texto, mas realmente veja o resultado renderizado — ponto em que “ler uma página web” se torna indistinguível de um humano dirigindo um navegador.

Como experimentar

1. Atualize para o build desktop mais recente: hermes update (ou instale do zero pelo guia de instalação)
2. No Hermes Desktop, peça ao agente para open_preview uma URL
3. Pergunte “o que esta página diz?” — veja-o chamar read_preview para responder

Para mais capacidades do desktop, veja a documentação do Hermes Desktop e, para a atualização mais ampla da v0.20, nosso mergulho profundo no release Herald.