Você já deve conhecer a história: um executivo da Meta pediu à ferramenta viral OpenClaw AI para fazer a triagem de sua caixa de entrada e sugerir mensagens para excluir, depois assistiu com horror quando o agente se tornou desonesto e detonou mais de 200 e-mails, seu frenético prompt “STOP OPENCLAW” perdido em meio ao enorme empreendimento do bot.
A reviravolta? O executivo era o principal oficial de segurança de IA da Meta, Summer Yue.
O apocalipse do e-mail de Yue destacou uma maneira de evitar histórias semelhantes de terror de IA.
Sim, Yue involuntariamente se tornou uma cobaia para o OpenClaw e suas automações descontroladas – e de fato, praticamente qualquer pessoa que usa o OpenClaw agora é uma cobaia.
Mas o apocalipse do e-mail de Yue também destacou uma maneira de evitar histórias semelhantes de terror de IA, e é um método com o qual a maioria dos programadores – e até mesmo muitos vibers – já estão familiarizados.
Tem nomes diferentes; Já ouvi isso ser chamado de “fluxo git do agente” e “ramificação de recursos do agente”, por exemplo. Mas, principalmente, trata-se de aplicar a metodologia “git” – o utilitário de linha de comando essencial para rastrear alterações no código – aos agentes de IA.
A melhor parte desta solução? Isso nos permite pegar nosso bolo (o bolo é uma coisa super legal que os agentes de IA podem fazer) e comê-lo também.
Frango, peixe e OpenClaws
Primeiro, um experimento mental. Finja que você está em um restaurante e há dois itens no cardápio: frango ou peixe. O frango com certeza parece bom, mas o peixe – salmão! Escolha difícil.
Imagine que, em vez de arriscar um erro caro ao escolher o frango em vez do peixe (e se o frango estiver estragado!), você poderia criar um “ramo” do seu futuro imediato – uma cópia temporária da sua linha do tempo que lhe permite testar uma escolha antes de tomá-la permanentemente.
Então, vá em frente e crie (ou “confira”) um novo ramo de sua linha de vida “principal” – vamos chamá-lo de “ramo de frango” – e então peça e experimente o frango. Eca! É nojento.
Sem problemas; descartamos o galho do frango, voltamos para o galho “principal” e verificamos um novo segundo galho – o galho “peixe”. Agora provamos o salmão – uma delícia! Gostamos deste ramo de peixe, por isso agora fundimo-lo com o nosso ramo “principal” da vida e começamos com uma refeição que com certeza será saborosa.
No mundo de rastreamento de código do git, chamamos essa funcionalidade (que descrevi apenas de maneira grosseira) de ramificação de recursos, e é uma maneira engenhosa e testada em batalha de testar grandes mudanças e novos recursos em nosso código antes de enviá-los para nosso projeto principal.
Um branch de recurso no git é na verdade apenas uma cópia do branch “principal”. Verificamos como se fosse um livro da biblioteca, fazemos todas as alterações que desejamos, testamos, encontramos bugs, fazemos mais alterações e assim por diante. Enquanto isso, o ramo “principal” do nosso projeto está seguro e intocado.
Somente depois de termos submetido nosso ramo de recursos a uma bateria de testes – alguns automatizados, alguns realizados pelo usuário humano – e determinarmos que ele está em ótima forma é que pensamos em fundir nosso ramo de “recursos” com o ramo principal. E se não gostarmos do andamento do ramo de recursos, podemos descartá-lo – sem danos, sem problemas.
Meu ponto? Essa metodologia de ramificação de código também pode funcionar com agentes de IA. (E não, não sou a primeira pessoa a considerar essa ideia.)
Como isso poderia ter sido melhor
Vamos voltar a Summer Yue e testar nosso cenário de “ramificação” para ver o tamanho. Desta vez, Yue se senta com o OpenClaw e pergunta: “Acesse minha caixa de entrada e sugira exclusões”. (Seu outro prompt na história do mundo real – “aguarde aprovação” – provavelmente foi retirado da janela de contexto do OpenClaw devido ao grande número de mensagens de e-mail que ele estava percorrendo.)
Versões mais – e potencialmente mais assustadoras – do terrível, horrível, nada bom e muito ruim dia de e-mail de Summer Yue acontecerão novamente se não dermos uma resposta justa a essa ideia.
Agora, em vez de o OpenClaw mergulhar na caixa de entrada ao vivo, ele cria um branch – chame-o de branch de “triagem” – que permite simular os resultados de peneirar, organizar e selecionar sua caixa de entrada, tudo em um ambiente de área restrita e tudo sem tocar nas mensagens de e-mail reais.
O OpenClaw faz o seu trabalho, talvez se empolgue e comece a excluir mensagens quer queira quer não. Se isso acontecesse, Yue poderia simplesmente olhar para o ramo de triagem, decidir que não está satisfeita com os resultados e então descartar o ramo ou continuar trabalhando com ele, testando diferentes iterações do prompt do OpenClaw ou adicionando documentos de “andaime” formatados em markdown que regem as ações do OpenClaw desde o início. Enquanto isso, sua caixa de entrada real está sã e salva.
Agora, essa “ramificação de recursos” funcionará para todos os cenários de agente de IA? Provavelmente não. É fácil colocar código de computador ramificado em uma sandbox e testar a segurança de qualquer número de ações e resultados. Mas assim como você não pode realmente colocar em sandbox a escolha frango versus peixe, há muitas ações e funções de IA de agente no mundo real (como, digamos, agentes de IA focados em RH) que não podem ser facilmente simuladas.
Dito isso, mais versões – e potencialmente mais assustadoras – do terrível, horrível, nada bom e muito ruim dia de e-mail de Summer Yue acontecerão novamente se não dermos um tratamento justo a essa ideia de “ramificação de recursos de agente”.
Fonte: PC World
