O que é a utilização do computador e porque é importante? A utilização do computador é uma ideia simples com implicações abrangentes: em vez de pedirmos aos modelos que respondam a perguntas, pedimos-lhes que operem software — navegando em sites, preenchendo formulários, percorrendo fluxos de trabalho e concluindo tarefas autonomamente, do início ao fim.
Isto viabiliza uma vasta categoria de tarefas do mundo real atualmente fragmentadas por várias interfaces, como reservas completas, processos de compra em comércio eletrónico, planeamento de viagens em várias etapas e fluxos administrativos sem um equivalente claro em API. Estes problemas não são novos. A novidade é ser viável resolvê-los com modelos de uso geral.
Sistemas recentes da Anthropic e da OpenAI demonstraram agentes que não se limitam a agir: raciocinam sobre o estado, recuperam de erros e criam de imediato soluções específicas para cada tarefa. Isto transforma o navegador num ambiente de execução geral para agentes, mas levanta de imediato uma questão de conceção: quanto desse ambiente devemos expor ao modelo?
Os primeiros sistemas responderam encapsulando o navegador num conjunto fixo de ações seguras e predefinidas. Como defenderemos neste artigo, essa abordagem está a chegar aos seus limites.
Ao criar agentes para navegadores, há um instinto comum: não confiar demasiado no modelo.
Por isso, encapsulamos o navegador. Disponibilizamos ferramentas predefinidas como click, type, scroll, select e read_text. Simplificamos o Document Object Model (DOM). Reduzimos o espaço de ações. Tentamos tornar o comportamento compreensível e controlável através das abstrações que concebemos.
É um ponto de partida sensato. Mas é também, cada vez mais, a arquitetura errada a longo prazo.
À medida que os modelos de fronteira melhoram, a limitação já não se resume à falta de ferramentas do modelo. A limitação está em obrigá-lo a operar através de abstrações que eliminam demasiado do sistema subjacente. Comprimimos um ambiente complexo e dinâmico numa interface de ações fixa e depois pedimos ao modelo que tenha um bom desempenho apesar dessa perda de informação.
Este compromisso é cada vez menos atrativo.
A mudança que temos vindo a explorar é fácil de descrever, mas tem consequências significativas. Em vez de tratarmos o agente como um seletor de ações predefinidas, tratamo-lo como um sintetizador de programas que opera num ambiente de execução condicionado.
Os modelos tornaram-se realmente bons e já não precisam das suas barreiras de proteção abstratas — precisam de todo o espaço de ações para conceber, executar e aperfeiçoar a tarefa até alcançarem o objetivo.
Este artigo aborda essa mudança, da automatização do navegador carregada de abstrações para uma utilização condicionada do computador, e o que muda quando os sistemas são concebidos desta forma.
O problema não é as interfaces de ações fixas estarem conceptualmente erradas. O problema é a Web não colaborar com elas.
As interfaces modernas são criadas com React, Vue e Angular e incluem atualizações assíncronas de estado, sistemas de eventos sintéticos e widgets de terceiros incorporados em iframes de origem cruzada, cada um com o seu próprio ciclo de vida. Um wrapper que diga «escrever neste campo» só está correto se a página concordar com a sua definição de escrita. Muitas não concordam. Definir diretamente um valor ignora muitas vezes por completo a deteção de alterações da framework. O campo parece preenchido. A validação nunca é acionada. O formulário continua sem funcionar.
É possível corrigir isto. É possível adicionar casos especiais para campos React, emitir eventos blur após o foco e aguardar pela inatividade da rede antes de ler o estado. Cada correção está certa no seu contexto. Em conjunto, acumulam-se e formam um sistema cada vez mais difícil de manter e cada vez mais específico para os sites já encontrados.
O problema mais profundo é codificar, na camada de abstração, pressupostos sobre como as interações devem funcionar e depois descobrir que a Web parte de pressupostos diferentes.
Considere um formulário de pagamento da Stripe ou da Adyen incorporado num iframe de origem cruzada. O seu wrapper não consegue aceder-lhe diretamente porque se encontra numa origem separada. A ferramenta read_text não consegue observar o respetivo estado interno. A ferramenta type não consegue aceder aos respetivos campos. Neste ponto, um agente baseado em wrappers fica bloqueado. A abstração foi concebida para o documento principal. A tarefa real encontra-se num local que a abstração não consegue ver.
Surge uma incompatibilidade semelhante em fluxos menos óbvios. Um menu pendente controlado por uma framework pode não responder de todo a cliques diretos, porque o elemento visível não é o controlo real. Pode exigir uma sequência de eventos de teclado para acionar a transição de estado subjacente. Vista do exterior, a interface parece responder a cliques. A abstração diz «clicar». Nada acontece.
Ou considere um fluxo modal com várias etapas em que as atualizações visíveis do DOM ficam atrasadas em relação às alterações do estado interno. A próxima ação correta depende de uma transição de estado que ainda não se reflete nos elementos que o wrapper consegue ver. Um agente baseado em wrappers acaba por agir demasiado cedo ou por ler um estado desatualizado, porque opera com uma visão incompleta do sistema.
Em cada caso, a abstração oculta os sinais de que o agente realmente precisa.
Um modelo que opere a um nível inferior — inspecionando o DOM ativo, raciocinando sobre os limites entre frames e sintetizando a sequência de interação para essa superfície específica — consegue lidar com estas situações. Não é que o modelo seja inerentemente mais inteligente. É que tem acesso às informações que tinham sido removidas.
A mudança que temos procurado concretizar é fácil de descrever: em vez de pedirmos ao modelo que escolha entre ações predefinidas, damos-lhe uma superfície de execução de nível inferior e condicionamo-la através de políticas de execução, em vez do desenho da abstração.
Esta escolha de conceção resulta de uma mudança mais ampla no setor, que começa a privilegiar ferramentas primitivas de nível inferior — ferramentas que tiram partido da capacidade inata do agente para corrigir durante a execução e produzir código de alta qualidade, em vez de ferramentas específicas e codificadas de forma rígida que são robustas, mas retiram ao modelo a capacidade de adaptação a diferentes ambientes.
Veja-se o êxito do Claude Code como uma das principais opções nas caixas de ferramentas de muitos programadores e a transição mais ampla do setor para agentes baseados no terminal. A maior vantagem do Claude Code não é o modelo em si, mas o harness de nível inferior. Dar ao modelo menos ferramentas, mais modulares e de nível inferior — ou seja, o terminal — melhora o desempenho na chamada de ferramentas, sobretudo porque o agente pode raciocinar e criar scripts personalizados para a tarefa em causa, em vez de tentar usar ferramentas generalizadas que sobrecarregam a janela de contexto.
Na prática, no caso da automatização do navegador, isto significa que o modelo pode inspecionar diretamente o estado atual da página, percorrer frames e criar código de interação à medida da interface atual, em vez de mapear tudo para um conjunto fixo de ações pré-criadas.
O modelo comporta-se menos como um seletor e mais como um autor em tempo de execução. Inspeciona o estado atual, raciocina sobre a interface e sintetiza a lógica de interação para essa situação específica. Pode criar sequências com várias etapas, adaptar-se a fluxos invulgares e validar os resultados antes de prosseguir. Quando uma ação falha, o modelo vê o erro subjacente e corrige-se. É mais poderoso e mais arriscado, mas está muito mais próximo da verdadeira natureza do problema.
Importa salientar que remover a camada de abstração não torna o sistema menos disciplinado. Apenas transfere essa disciplina para outro lugar.
O trabalho que antes residia na conceção dos wrappers e no tratamento de casos extremos passa para três áreas: o prompt (que se torna uma forma de formação operacional), o ambiente de execução (que impõe limites como o âmbito da navegação, as ações sensíveis e o comportamento das novas tentativas) e a camada de avaliação (que não avalia apenas se a tarefa foi bem-sucedida, mas também se as etapas intermédias estavam corretas). Menos abstrações frágeis. Sistemas envolventes mais robustos.
Um dos resultados desta mudança é que o código do produto se torna muitas vezes mais simples, mesmo quando o sistema, no seu todo, ganha capacidades. Em vez de codificar padrões de interação como wrappers reutilizáveis, o agente sintetiza o comportamento durante a execução. Mantém-se um pequeno conjunto de primitivas poderosas e um ambiente de execução condicionado, em vez de uma variedade crescente de ferramentas especializadas e lógica para casos extremos.
Isto também altera a forma como o sistema generaliza. Um agente baseado em wrappers generaliza bem para tarefas semelhantes às dos wrappers já criados. Um agente com um ambiente de execução condicionado generaliza para tarefas que partilham a mesma base de execução, mesmo quando a interface visível é diferente.
Por exemplo, interagir com um formulário de pesquisa, um processo de reserva ou uma página de definições pode parecer completamente diferente ao nível da interface. Mas, nos bastidores, partilham padrões: leitura do estado, acionamento de eventos, validação de resultados e gestão de atualizações assíncronas. Um sistema que opere a esse nível transfere-se de forma mais natural entre tarefas.
O componente reutilizável não é a lista de ações. É a capacidade do modelo para inspecionar o estado, agir em segurança e verificar os resultados.
A lição mais clara deste trabalho é que a fiabilidade não resulta de dar mais funções auxiliares ao modelo. Muitas vezes, resulta de lhe dar menos primitivas, mas mais poderosas, e de as condicionar da forma certa. A assistência excessiva incorpora pressupostos rígidos sobre a forma de realizar uma tarefa. As restrições definem limites de operação seguros e permitem que o modelo descubra melhores soluções locais.
Uma superfície de execução mais poderosa também exige um modelo de segurança mais rigoroso. Quando o agente deixa de estar limitado a um pequeno conjunto de ações predefinidas, passa efetivamente a operar diretamente em software real. Isso altera imediatamente o perfil de risco.
Há quatro questões a considerar na conceção:
Exposição de dados. Se o agente interagir com interfaces reais, irá muitas vezes encontrar informações sensíveis. Isto exige uma abordagem rigorosa à ocultação de dados e ao controlo de acesso. Os dados só devem ser revelados quando necessários para a execução, e os registos e rastreios têm de ser tratados com cuidado para que a observabilidade não se torne a parte mais sensível do sistema.
Âmbito de execução. Um agente poderoso não deve poder operar de forma arbitrária. Na prática, isto significa limitar os locais para onde pode navegar, os domínios a que pode aceder e os sistemas com que pode interagir. Estas restrições devem ser aplicadas ao nível do ambiente de execução, e não deixadas como meras convenções no prompting.
Confiança no ambiente. As interfaces modernas podem incluir instruções, conteúdos ou fluxos enganadores ou deliberadamente adversariais. A injeção de prompt através do conteúdo de uma página constitui uma superfície de ataque real. O sistema precisa de uma hierarquia clara de instruções, verificações de validação e condições de paragem para impedir que o agente siga orientações indevidas.
Espetro de autonomia. Nem todas as ações devem ser totalmente autónomas. Em muitos ambientes de produção, é importante tratar a autonomia como um espetro. O sistema pode ter um elevado grau de agência na forma como explora e executa, continuando a exigir aprovação para determinadas categorias de ações.
O princípio subjacente é simples: dar mais poder ao modelo exige reforçar o sistema que o rodeia. A autonomia sem políticas não está pronta para produção.
Deixámos de perguntar: quais são as ações certas do navegador que devemos disponibilizar?
Passámos a perguntar: como podemos dar ao modelo um espaço de ações completo — e como criamos políticas de execução em torno desse espaço que continuem a garantir a segurança?
Esta reformulação altera as prioridades. As taxonomias de ações e a abrangência dos wrappers tornam-se menos importantes. As políticas de execução, a observabilidade e a avaliação ao nível de cada etapa tornam-se mais importantes. A capacidade do modelo e a conceção do sistema não se substituem mutuamente. À medida que os modelos melhoram, o trabalho do sistema torna-se mais importante, não menos.
Os agentes para navegadores que funcionam em demonstrações têm muitas vezes êxito porque a tarefa é limitada e o ambiente é cooperante. Os sistemas de produção exigem algo diferente: execução condicionada, comportamento instrumentado e uma avaliação capaz de distinguir um resultado correto de um resultado obtido por sorte.
Menos conceção de wrappers. Mais engenharia de sistemas.
E, embora nos tenhamos concentrado em agentes para navegadores, isto aponta para uma forma mais abrangente de pensar na utilização do computador enquanto disciplina de sistemas.