00:00:00Obrigado ao HubSpot por patrocinar este vídeo.
00:00:03Algo realmente grande aconteceu em dezembro de 2025.
00:00:07E a maioria das pessoas nem percebeu.
00:00:09Andrew Cupsey tuitou sobre isso na semana passada.
00:00:10"É muito difícil comunicar o quanto a programação mudou devido à IA nos últimos dois meses,
00:00:15especificamente desde dezembro passado."
00:00:17E Greg, da OpenAI, também falou sobre isso.
00:00:20Desde dezembro, houve melhorias significativas no que o modelo e as ferramentas são capazes de fazer.
00:00:24Alguns engenheiros disseram a ele que o trabalho deles mudou fundamentalmente desde dezembro
00:00:28de 2025.
00:00:29Então, o que realmente aconteceu em dezembro de 2025?
00:00:32Em poucas palavras, o modelo mais recente lançado está finalmente pronto para tarefas
00:00:37totalmente autônomas e de longa duração.
00:00:38Com a IA, o sonho máximo é que, enquanto dormimos, a IA possa trabalhar em
00:00:43tarefas de forma totalmente autônoma, 24 horas por dia, 7 dias por semana.
00:00:46Mesmo em 2023, o projeto mais popular, se você se lembra, chamava-se AutoGPT.
00:00:50Foi a primeira vez que esses sistemas de agentes totalmente autônomos foram introduzidos.
00:00:54Eles tinham uma arquitetura básica e simples, usando o GPT-4 como modelo para
00:00:59decompor autonomamente uma lista de tarefas baseada no objetivo do usuário e possuíam uma memória simples para armazenar
00:01:03o resultado.
00:01:04As pessoas estavam fazendo coisas malucas, como dar um objetivo de "ganhar 100 mil dólares" e
00:01:08deixá-lo rodar em um loop de tarefas infinitamente até completar.
00:01:11Naquela época, o sistema simplesmente quebrava e falhava miseravelmente porque o modelo não estava pronto.
00:01:15Mas desde dezembro do ano passado, isso realmente mudou.
00:01:18Os modelos têm uma qualidade significativamente superior, coerência de longo prazo e podem lidar com
00:01:22tarefas muito maiores e mais longas.
00:01:24E vimos todos os tipos de experimentações surgirem na indústria.
00:01:28Primeiro, a partir de janeiro, tivemos esse conceito super popular chamado "rough loop", que é o
00:01:33loop de iteração de agente mais básico para forçar o modelo a trabalhar por mais tempo para que possa realizar
00:01:37tarefas complexas.
00:01:38Apenas colocamos o modelo em loop com algumas verificações de condição simples, mas já começamos a ver
00:01:42a diferença.
00:01:43Uma semana depois, o Cursor também lançou sua experimentação, onde usaram o GPT-5.2 para
00:01:49construir um navegador do zero de forma autônoma com 3 milhões de linhas de código.
00:01:52A Anthropic também lançou uma experimentação onde colocaram uma equipe de "cloud codes"
00:01:57para trabalhar autonomamente em um compilador C do zero por duas semanas.
00:02:01No final, entregou uma versão funcional com zero codificação manual.
00:02:05Pode até rodar Doom dentro desse compilador.
00:02:08Ao mesmo tempo, o OpenClaw começou a ganhar atenção e teve esse crescimento explosivo que
00:02:13nunca tínhamos visto antes.
00:02:14Era muito difícil entender o que estava acontecendo com o OpenClaw porque, de fora,
00:02:18é fácil categorizá-lo como apenas mais um sistema, mas ele vive dentro do seu próprio
00:02:23computador e também pode ser acessado pelo Telegram.
00:02:27Tipo, por que isso é tão popular?
00:02:29Só mais tarde, depois de usá-lo profundamente, percebi que a real diferença é que o OpenClaw representa
00:02:35esse tipo de agente sempre ligado, de longa duração e totalmente autônomo, que é muito diferente de
00:02:40todos os outros sistemas de agentes que usávamos antes, onde o humano é o principal motor para solicitar
00:02:45a próxima ação.
00:02:46O OpenClaw está sempre ligado e é proativo.
00:02:49Essa sensação autônoma é criada por uma arquitetura bastante simples, onde possui uma
00:02:53camada de contexto de memória com gatilhos e tarefas agendadas (cron jobs) para realizar ações automaticamente e tem
00:02:58acesso total ao computador, que é um ambiente poderoso no qual pode operar.
00:03:02Acredito que o OpenClaw foi o primeiro projeto que realmente iniciou a maior mudança de paradigma
00:03:06em 2026: estamos saindo de um sistema de agente simples baseado em tarefas (co-pilot) para esses agentes
00:03:13totalmente autônomos e de longa duração.
00:03:15Algo que está sempre ligado, sempre pronto, entregando trabalhos coordenados super complexos.
00:03:20Esta é uma mudança crítica que você precisa entender.
00:03:22O modelo hoje é, na verdade, muito mais poderoso do que você pensa, desde que você projete o sistema certo
00:03:27para desbloqueá-lo.
00:03:28E este é o ponto central do que quero falar hoje.
00:03:30A "Engenharia de Harness" (Harness Engineering) para viabilizar sistemas autônomos de longa duração.
00:03:34Se é a primeira vez que você ouve falar de Engenharia de Harness, saiba que é uma evolução do que
00:03:38falamos anteriormente, que é a Engenharia de Contexto ou Engenharia de Prompt.
00:03:41Anteriormente, focávamos muito em como otimizar os prompts dentro da janela de contexto eficaz
00:03:46para que o modelo tivesse o melhor desempenho em uma única sessão de loop de agente.
00:03:49Mas a Engenharia de Harness foca realmente nessas tarefas de longa duração, o que significa
00:03:53como projetar um sistema que possa trabalhar em diferentes sessões e com vários agentes diferentes.
00:03:57E como projetar o fluxo de trabalho correto para garantir que o contexto relevante seja recuperado
00:04:01para cada sessão, além do conjunto certo de ferramentas para extrair o máximo dos modelos.
00:04:05Este é um conceito bastante novo, mas o lado bom é que a indústria já convergiu para
00:04:09algumas melhores práticas que você pode usar da Anthropic, Vercel, LangChain e muitas outras.
00:04:14Vou passar por cada uma delas individualmente para que você veja os padrões.
00:04:16Mas antes de mergulharmos nisso, com essa mudança de paradigma para agentes totalmente autônomos, uma das maiores
00:04:21oportunidades para os próximos 6 a 12 meses é construir um "OpenClaw" para um nicho específico.
00:04:25O que significa investigar e entender profundamente o fluxo de trabalho de ponta a ponta de um determinado setor.
00:04:29E construir um agente autônomo com o ambiente e as ferramentas corretas para permitir o processo completo.
00:04:34É por isso que quero apresentar a você esta pesquisa incrível que o HubSpot fez sobre a adoção da IA
00:04:39no relatório de marketing por e-mail.
00:04:40É um relatório fascinante para você entender, em um setor como o marketing por e-mail, onde as pessoas
00:04:44realmente usam IA hoje e quais são as lacunas.
00:04:47Porque este relatório mostra um fluxo de trabalho claro e oportunidades no marketing por e-mail que você
00:04:51pode potencialmente automatizar.
00:04:52Eles entrevistaram centenas de profissionais de marketing por e-mail de grandes empresas para entender exatamente como a IA
00:04:57está remodelando seus fluxos de trabalho.
00:04:58Eles falam sobre por que os profissionais de marketing ainda fazem muita edição pesada, o que causou
00:05:03isso, bem como os maiores desafios que estão enfrentando hoje ao implementar IA no
00:05:06marketing por e-mail.
00:05:07E cada um deles é uma grande oportunidade para você construir um agente totalmente autônomo.
00:05:11Eles até mergulham nos KPIs específicos que mais importam e onde a IA mostrou resultados
00:05:15comprovados.
00:05:16Assim como o que exatamente os profissionais de marketing por e-mail realmente querem da IA.
00:05:20Portanto, se você é um desenvolvedor pensando no próximo grande produto de agente para construir, recomendo fortemente
00:05:24que confira este recurso incrível.
00:05:27Coloquei o link na descrição abaixo para você baixar gratuitamente.
00:05:30E obrigado ao HubSpot por patrocinar este vídeo.
00:05:32Agora, vamos voltar à engenharia de harness para sistemas de agentes de longa duração.
00:05:36Em alto nível, há três aprendizados que tirei disso.
00:05:39Primeiro, para agentes de tarefas de longa duração, a parte crítica do design do sistema é criar
00:05:44este ambiente legível onde cada sub-agente ou sessão possa realmente entender em que ponto
00:05:49as coisas estão.
00:05:50Muito provavelmente, existem alguns fluxos de trabalho que podem ser feitos para reforçar a legibilidade do ambiente.
00:05:54E explicarei um pouco mais sobre isso.
00:05:56O segundo é que a verificação é crítica.
00:05:58Você pode melhorar significativamente a saída do sistema permitindo que ele verifique seu trabalho de forma eficaz
00:06:03com um ciclo de feedback mais rápido.
00:06:04E o terceiro é que precisamos confiar mais no modelo em vez de construir ferramentas especializadas
00:06:08que envolvem muito raciocínio e lógica prematuramente.
00:06:11Devemos dar ao modelo o máximo de contexto com ferramentas genéricas que eles entendam nativamente e deixar
00:06:16que ele apenas explore como os humanos.
00:06:17E vou detalhar essas três coisas uma a uma conforme avançamos.
00:06:20Primeiro, o harness eficaz da Anthropic para blocos de agentes de longa duração.
00:06:24Eles experimentaram o uso do SDK cloud code para construir um agente especializado para tarefas de
00:06:29longa duração, como construir um clone do site cloud.ai.
00:06:32As primeiras falhas que observaram foram: primeiro, os agentes tendem a fazer demais de uma vez.
00:06:37Essencialmente, ele sempre tentará criar o aplicativo inteiro de uma só vez.
00:06:40E isso fez com que o modelo ficasse sem contexto no meio da implementação, deixando
00:06:45a próxima sessão para começar com o recurso metade implementado ou documentado.
00:06:49Então o agente teria que adivinhar o que realmente aconteceu e gastar um tempo substancial tentando
00:06:52fazer o aplicativo básico funcionar novamente.
00:06:55A segunda falha observada é que os agentes tendem a declarar o trabalho concluído prematuramente.
00:07:00Você provavelmente já experimentou isso algumas vezes.
00:07:02O cloud code ou o cursor simplesmente afirmam que o projeto ou recurso está concluído.
00:07:05Mas quando você testa, na verdade não funciona.
00:07:07A abordagem deles para resolver esses comportamentos de falha padrão do modelo foi: primeiro, configurar um
00:07:12ambiente inicial que estabeleça a base para todos os recursos que o prompt exigiu, o que
00:07:16prepara o agente para trabalhar passo a passo e recurso por recurso.
00:07:20Isso é semelhante à abordagem de plano ou PRD que normalmente usamos.
00:07:23O segundo ponto é que ele começa a orientar cada agente a fazer progresso incremental em direção ao seu objetivo,
00:07:27ao mesmo tempo em que deixa o ambiente em um estado limpo ao final de cada sessão.
00:07:32O que eles fizeram foi projetar esta solução de duas partes.
00:07:35Eles terão este agente inicializador que usa um prompt especializado para pedir ao modelo para configurar
00:07:40o ambiente inicial com o script init.sh, que configurará o servidor de desenvolvimento, por exemplo,
00:07:45para que o próximo modelo não precise se preocupar com essas coisas.
00:07:48E também um arquivo cloud progress.txt que mantém registros do que o agente fez, bem como um
00:07:53commit inicial do git que mostra quais arquivos foram adicionados.
00:07:55Depois, um agente de codificação para cada sessão subsequente para pedir ao modelo que faça progresso incremental
00:08:01e, então, deixe atualizações estruturadas.
00:08:02E todos esses esforços visam servir a um propósito: como eles podem definir um
00:08:07ambiente onde os agentes possam entender rapidamente o estado do trabalho ao começar com uma nova
00:08:11janela de contexto.
00:08:13O fluxo de trabalho é que o agente inicializador tentaria primeiro configurar um ambiente ou,
00:08:17podemos chamar, um sistema de documentação para rastrear e manter o plano geral.
00:08:21E o ambiente que eles projetam aqui é: primeiro, eles terão documentos de lista de recursos para
00:08:25evitar que o agente tente fazer tudo de uma vez ou considere prematuramente o projeto concluído.
00:08:30Eles farão com que o agente inicializador divida o projeto em mais de 200 recursos
00:08:34e os registre em um arquivo JSON local semelhante a este, onde cada tarefa tem especificações detalhadas,
00:08:39bem como o estado de aprovação ou falha.
00:08:41Por padrão, todas as tarefas serão marcadas como falha.
00:08:43Isso força o modelo a olhar sempre para o objetivo geral do projeto e o progresso, escolher a tarefa de maior
00:08:49prioridade e fazer a próxima coisa.
00:08:50Mas para fazer esse fluxo de trabalho funcionar, eles também precisam de uma maneira de forçar o modelo a deixar o ambiente
00:08:55em um estado limpo após fazer a alteração no código. Em seus experimentos, descobriram que a melhor maneira
00:08:59é pedir ao modelo para comitar o progresso no git com uma mensagem de comentário descritiva e escrever
00:09:05um resumo do seu progresso em um arquivo de progresso. No entanto, apenas documentação e ambiente
00:09:08de contexto não são suficientes, porque o modelo, por padrão, tem a tendência de marcar algo
00:09:13como concluído sem testes adequados. No início, eles estavam apenas instruindo o cloud code
00:09:17a sempre realizar os testes após a alteração do código, fazendo testes unitários ou de API para
00:09:22o servidor de desenvolvimento.
00:09:23Mas tudo isso muitas vezes falha em reconhecer que um recurso não está funcionando de ponta a ponta.
00:09:27As coisas realmente começam a mudar quando dão ao modelo ferramentas adequadas para fazer o teste de ponta a ponta
00:09:30sozinho, como o Puppeteer MCP ou o Chrome dev tool, onde o agente pôde
00:09:35identificar e corrigir bugs que não eram diretamente óbvios apenas pelo código.
00:09:39Basicamente, eles configuram a estrutura onde têm o agente inicializador para decompor
00:09:43o objetivo do usuário em uma lista de recursos ao lado do init.sh para poder rodar o servidor de desenvolvimento
00:09:47e os arquivos de progresso.
00:09:49Assim, o próximo agente de codificação pode apenas ler a lista de recursos para entender
00:09:53o plano geral do projeto, pegar as tarefas de alta prioridade e o arquivo de progresso para entender
00:09:57em que ponto as coisas estão.
00:09:59Em seguida, executa o init.sh para iniciar o servidor de desenvolvimento imediatamente e faz testes de ponta a ponta para verificar se o ambiente
00:10:04está limpo, para que possa ter uma visão completa e um ciclo de feedback mais rápido enquanto cada nova sessão
00:10:09e janela de contexto ocorrem.
00:10:10No blog da OpenAI, eles falam sobre coisas muito semelhantes.
00:10:13Você precisa garantir que o ambiente da sua aplicação seja legível.
00:10:16Eles tornam todo o repositório o sistema de conhecimento ou registro.
00:10:19Inicialmente, colocaram um arquivo agents.md gigantesco e ele falhou de maneiras previsíveis porque era
00:10:23muito contexto para qualquer agente gerenciar e manter.
00:10:27Então, o que fizeram foi projetar uma estrutura de ambiente de documentação adequada e trataram o arquivo agents.md como um
00:10:32índice.
00:10:33Configuraram este sistema de documentação abrangendo arquiteturas, documentos de design, o plano de execução,
00:10:37esquema de banco de dados, especificações de produto, plano de front-end, segurança e muito mais, e
00:10:42colocaram esse índice no arquivo agents.md para que o agente possa recuperar informações
00:10:47específicas quando necessário.
00:10:49Isso permite a revelação progressiva, e a OpenAI leva isso ainda mais longe.
00:10:53Eles tentarão incluir não apenas o conhecimento do código, mas também Google Docs, mensagens do Slack e todas essas
00:10:58outras informações fragmentadas, alimentando os dados no repositório como artefatos locais do repositório.
00:11:03Assim, o agente também pode recuperá-los, pois, do ponto de vista do agente, se algo não pode ser acessado
00:11:04no ambiente, efetivamente não existe.
00:11:09Mas, novamente, a documentação por si só não mantém um código gerado totalmente por agentes coerente.
00:11:11Eles também introduziram certos fluxos de trabalho programáticos para reforçar invariantes.
00:11:16Por exemplo, eles estruturam a arquitetura do domínio com limites transversais explícitos, o que
00:11:20permite reforçar essas regras com verificações personalizadas, linters e testes estruturais, que
00:11:25podem ser acionados e injetados automaticamente em cada pré-commit do git.
00:11:29Esse tipo de arquitetura você normalmente adiaria até ter centenas de engenheiros
00:11:33em uma empresa de software tradicional, mas com agentes de codificação, é um pré-requisito inicial.
00:11:37Dentro desses limites, você permite que equipes e agentes tenham liberdade significativa em como as soluções
00:11:41são expressas, sem microgerenciamento e sem medo de que a arquitetura se perca.
00:11:46Enquanto isso, eles também melhoraram muito a base de código.
00:11:49Por exemplo, tornaram o aplicativo inicializável por árvores de trabalho do git (work trees), para que os codecs possam lançar e
00:11:52conduzir muitas instâncias diferentes.
00:11:55E também conectaram o protocolo do Chrome dev tool no runtime do agente para que o agente possa
00:11:57reproduzir bugs e validar correções por meio de snapshots do DOM, capturas de tela e navegação.
00:12:01Com o ambiente e o fluxo de trabalho configurados, o repositório finalmente cruzou um limite mínimo
00:12:05onde os codecs podem conduzir um novo recurso de ponta a ponta.
00:12:09Assim, toda vez que os codecs recebem um único prompt, o agente começa validando o
00:12:13estado atual da base de código, reproduz um bug relatado, grava um vídeo para demonstrar
00:12:17a falha, implementa a correção, valida a correção navegando no aplicativo, grava um segundo
00:12:21vídeo demonstrando a resolução e, eventualmente, faz o merge da alteração.
00:12:25Esses dois blocos mostram aprendizados muito bons e os sistemas de harness necessários que você precisa colocar
00:12:29em prática para um sistema totalmente autônomo.
00:12:32Enquanto isso, também há outros aprendizados.
00:12:34Muitas vezes, ao construir agentes, especialmente agentes para nichos específicos, nossa tendência é
00:12:36construir ferramentas especializadas para realizar tarefas específicas de um domínio.
00:12:40O aprendizado é que modelos de linguagem grandes quase sempre funcionam melhor com ferramentas genéricas
00:12:43que eles entendam nativamente.
00:12:47A Vercel lançou este artigo incrível sobre como eles redesenharam seus agentes de tarefas para SQL.
00:12:49Eles passaram meses construindo agentes internos sofisticados de texto para SQL com engenharia de
00:12:53prompt pesada e gestão de contexto cuidadosa.
00:12:58Mas, como muitos de nós já experimentamos, esse tipo de sistema até funciona, mas é muito frágil,
00:13:02lento e requer manutenção constante.
00:13:06Porque a cada novo caso atípico que acontece, você precisa injetar um novo prompt no agente.
00:13:09Mas depois eles tentaram uma coisa que mudou totalmente a trajetória.
00:13:12Eles deletaram a maioria das ferramentas especializadas do agente, restando apenas uma ferramenta de comando em lote única.
00:13:15Com essa arquitetura muito mais simples, o agente teve um desempenho 3,5 vezes mais rápido, com
00:13:2037% menos tokens e a taxa de sucesso aumentou de 80% para 100%.
00:13:25Aprendizado semelhante foi compartilhado pela equipe da Anthropic, onde eles falam sobre como,
00:13:30em vez de ferramentas de execução de busca especializadas, eles têm apenas uma ferramenta de lote onde
00:13:34podem rodar grep, tail, npm, npm run linked.
00:13:38Fundamentalmente, acho que é porque o modelo de linguagem grande está muito mais familiarizado
00:13:41com essas ferramentas nativas de código, que possuem bilhões de tokens de treinamento, em comparação com ferramentas personalizadas
00:13:45em JSON que ele precisa gerar.
00:13:49Falei sobre isso no vídeo de chamada de ferramenta programática que lancei na semana passada.
00:13:51E acredito que os princípios fundamentais aqui são semelhantes, mas a base dessas arquiteturas simples
00:13:55é, novamente, o bom ambiente de contexto e documentação onde o modelo pode usar ferramentas genéricas
00:13:59para recuperar contexto progressivamente.
00:14:05E é o mesmo caso com o OpenClaw.
00:14:06Uma razão pela qual o OpenClaw é tão interessante é que eles têm um ambiente de contexto
00:14:09surpreendentemente simples, mas eficaz.
00:14:13Eles têm uma lista de documentação para armazenar informações principais e, com essa base,
00:14:15possuem apenas as ferramentas mais básicas como ler, escrever, editar arquivos, rodar comandos em lote
00:14:18e enviar mensagens.
00:14:23Todo o resto vem de dar ao agente o ambiente para recuperar o contexto relevante, além de uma grande biblioteca
00:14:24de habilidades para expandir as capacidades.
00:14:29Estes são três aprendizados práticos sobre como fazer a engenharia de harness para agentes
00:14:31complexos e de longa duração.
00:14:35Configurando um ambiente de contexto legível para permitir que cada sessão colete contexto de forma eficaz,
00:14:36com fluxo de trabalho e ferramentas corretas para que o modelo possa verificar seu trabalho efetivamente, gerando um
00:14:41ciclo de feedback mais rápido e confiando no agente com ferramentas genéricas que ele entende nativamente.
00:14:46Se você estiver interessado, compartilharei mais a fundo como pego esses aprendizados
00:14:50e os transformo em um processo de ciclo de vida de desenvolvimento.
00:14:54No AI Builder Club, temos cursos e orientações sobre "vibe coding" e construção de agentes para
00:14:58produção.
00:15:02E toda semana, eu e especialistas da indústria compartilhamos os aprendizados práticos mais recentes.
00:15:03Se você estiver interessado em aprender o que estou aprendendo todos os dias, clique no link
00:15:08abaixo para se juntar à comunidade.
00:15:12Espero que tenha gostado deste vídeo.
00:15:13Obrigado e nos vemos na próxima.
00:15:14Obrigado e nos vemos na próxima.