Cloudflare Workers: Agents SDK, VPC TCP e GLM-5.2 na Atualização
A Cloudflare Workers atualização de junho de 2026 representa um dos saltos mais significativos na plataforma serverless de edge computing desde o lançamento dos Durable Objects. Em um mercado onde a latência é o novo downtime e a computação distribuída deixou de ser diferencial para ser requisito mínimo, a Cloudflare entrega um pacote denso de novos recursos que ampliam dramaticamente o escopo do que é possível executar na borda da rede. A rede da Cloudflare — presente em mais de 300 cidades em mais de 100 países, processando uma em cada cinco requisições HTTP da internet global — agora suporta agentes de IA autônomos com automação de navegador, conexões TCP raw para redes privadas e modelos de linguagem com janela de contexto de até 262 mil tokens rodando diretamente nos Points of Presence.
Esta Cloudflare Workers atualização chega em um momento estratégico. O ecossistema de edge computing em 2026 está consolidado em três grandes players: Cloudflare Workers, AWS Lambda@Edge/CloudFront e Fastly Compute@Edge. Enquanto a AWS ainda cobra taxas de egress que tornam inviável workloads de alto volume de dados — US$ 0,09 por GB no S3 contra zero no R2 — e a Fastly limita-se a WebAssembly, a Cloudflare combina JavaScript, Python, WASM e agora agentes de IA em um runtime unificado com cold start inferior a 1 milissegundo. Para empresas brasileiras que operam sob a LGPD e precisam processar dados localmente, a presença de PoPs em São Paulo, Rio de Janeiro e Fortaleza garante conformidade territorial e latência de dois dígitos para usuários na América do Sul.
O anúncio que detalhamos neste artigo abrange sete frentes de evolução: o Agents SDK com automação de navegador e execução de código com aprovação humana; a capacidade de abrir conexões TCP via connect() sobre VPC Networks para serviços privados como Redis e Memcached; a chegada do modelo GLM-5.2 ao Workers AI, desenhado especificamente para coding agentic; o gerenciamento de Artifacts — repositórios Git-compatíveis — diretamente pelo dashboard; novas funcionalidades de otimização do Cloudflare Images; o stack Cloudflare One para deploy guiado por agentes de IA; e a disponibilidade geral do DMARC Management. Cada um desses componentes merece análise detalhada, e é exatamente isso que faremos nas próximas seções.
Se você é desenvolvedor backend, SRE, arquiteto de infraestrutura ou CISO, este post foi escrito para você. Vamos dissecar as novas APIs, os breaking changes implícitos, os caminhos de migração e — principalmente — o que cada recurso significa para workloads reais em produção. Na JRT Technology Solutions, configuramos ambientes Cloudflare Workers para clientes corporativos desde 2019, e nossa equipe de especialistas em CDN e edge computing já está testando essas novidades em ambientes de staging. A análise que você lerá a seguir é baseada em documentação oficial, changelogs públicos e testes práticos em nossa infraestrutura de laboratório.
Cloudflare Workers atualização: Agents SDK revoluciona automação de navegador e código
A maior novidade desta Cloudflare Workers atualização é, sem dúvida, a expansão do Agents SDK. O pacote agents@latest agora inclui três capacidades que transformam Workers em plataformas de execução de agentes autônomos: Browser Run para automação de navegador real, Codemode para execução de código com aprovação humana e Think delegation com ferramentas fornecidas pelo cliente. O salto arquitetural aqui é expressivo: em vez de escolher entre uma lista fixa de ações pré-definidas, o modelo de linguagem escreve código contra o Chrome DevTools Protocol (CDP) diretamente, podendo inspecionar páginas, capturar screenshots, ler conteúdo renderizado, depurar comportamento de frontend e interagir com sessões de navegador ao vivo.
O componente Browser Run é exposto através de uma única ferramenta durável chamada browser_execute. O desenvolvedor instancia createBrowserTools com contexto, binding de navegador e loader, e define o modo de sessão como "dynamic". Sessões podem ser one-time (descartáveis após a tarefa), reused (persistentes entre execuções) ou promoted — quando uma sessão one-time é elevada a persistente durante a execução. Este último modo é particularmente valioso para cenários que exigem intervenção humana: login, MFA, aprovação de ação sensível. O agente pausa, preserva cookies e abas, e retoma após a aprovação, sem perder estado. Para tarefas de extração rápida, o SDK oferece atalhos como browser_markdown, browser_extract, browser_links e browser_scrape — cada um otimizado para um padrão de scraping específico, eliminando a necessidade de escrever código CDP para casos de uso comuns.
Já o Codemode resolve um problema espinhoso de agentes autônomos: como permitir que um modelo execute código contra sistemas externos sem abrir um buraco de segurança. A abordagem usa createCodemodeRuntime com conectores tipados — por exemplo, GithubConnector — e um executor que roda em Worker isolado via DynamicWorkerExecutor. Quando o código atinge uma ação que requer aprovação (como criar uma issue no GitHub ou modificar um registro em produção), o runtime pausa a execução e retorna uma pending approval. Após a aprovação humana, as chamadas concluídas são re-executadas a partir de um log durável de execução, a ação aprovada é executada e o código continua de onde parou. Para equipes de plataforma que constroem agentes internos de SRE ou DevOps, isso elimina a necessidade de implementar lógica customizada de pause-and-resume para cada ferramenta — o framework trata disso transparentemente.
A terceira dimensão do Agents SDK é a delegação via Think sub-agents com ferramentas fornecidas pelo cliente. Um agente pai pode passar schemas de ferramentas via clientTools e resolver chamadas de ferramenta através de onClientToolCall sobre o caminho RPC chat(). Isso permite que agentes delegados usem capacidades do caller — como consultar o timezone do usuário ou acessar uma API interna — sem exigir um WebSocket de navegador. Os Think Workflows também foram aprimorados: um passo de step.prompt() agora executa um turno agentic completo antes de retornar saída estruturada, permitindo que o agente chame ferramentas antes de produzir o resultado tipado — ideal para triagem durável, pesquisa e fluxos de aprovação.
Para times que operam agentes em produção, o changelog reporta correções de confiabilidade significativas: useAgent e AgentClient lidam com substituição de WebSocket de forma mais robusta durante reconexões e mudanças de configuração; o replay de stream de chat é mais confiável após reconexões, deploys e erros de provider; a recuperação de Fiber continua através de scans multi-pass e aplica backoff quando hooks de recuperação falham repetidamente; o teardown de agente continua mesmo quando a requisição que iniciou o teardown é cancelada. Para atualizar, basta rodar npm i agents@latest @cloudflare/think@latest @cloudflare/codemode@latest @cloudflare/ai-chat@latest @cloudflare/voice@latest.
VPC Networks e Cloudflare Workers atualização: TCP direto para serviços privados
Outra mudança profunda nesta Cloudflare Workers atualização é o suporte à API connect() sobre VPC Network bindings. Até agora, Workers só conseguiam comunicar-se com destinos privados via HTTP usando fetch() — o que limitava a integração com bancos de dados não-HTTP, brokers de mensageria e protocolos binários legados. Com a nova API, um Worker pode abrir sockets TCP raw para qualquer serviço privado acessível através de Cloudflare Tunnel, Cloudflare Mesh ou Cloudflare WAN on-ramp. Isso inclui Redis, Memcached, MQTT, MySQL (via protocolo nativo, não apenas via HTTP connector), qualquer serviço com protocolo binário customizado e — importante para ambientes industriais — protocolos como Modbus TCP.
A configuração é feita no wrangler.jsonc ou wrangler.toml adicionando um array vpc_networks com binding name, network ID e flag remote: true. Em runtime, o binding expõe o método connect() que recebe uma string "host:porta" e retorna um socket com readable e writable streams. O exemplo do changelog mostra abertura de conexão para uma instância Redis privada em 10.0.1.50:6379, envio de comando PING e retorno da resposta como corpo da Response HTTP. A limitação atual — e isto é importante para planejamento de arquitetura — é que connect() sobre VPC Networks suporta apenas TCP plaintext. Conexões TLS para destinos privados ainda não estão disponíveis, o que significa que a criptografia em trânsito dentro da VPC precisa ser tratada na camada de rede (IPsec/GRE) ou via soluções de aplicação.
Para times de infraestrutura que operam ambientes híbridos — parte na nuvem pública, parte em data centers on-premise — isso fecha uma lacuna crítica. Anteriormente, conectar um Worker a um Redis on-premise exigia expor o Redis via HTTP (com um proxy como o webdis) ou usar um túnel Cloudflare com endpoint HTTP. Agora, o Worker fala o protocolo nativo do Redis diretamente, eliminando o proxy intermediário e reduzindo latência. Na JRT Technology Solutions, configuramos Cloudflare Tunnel e VPC Networks para clientes que mantêm mainframes e sistemas legados em data centers próprios; a capacidade de Workers abrirem sockets TCP diretamente para esses sistemas, sem camadas de tradução de protocolo, reduz a complexidade operacional em pelo menos uma ordem de magnitude.
O caso de uso mais imediato que enxergamos é cache warming inteligente: um Worker acionado por cron pode conectar-se ao Redis on-premise, verificar quais chaves foram invalidadas, e pré-aquecer o cache da CDN antes do pico de tráfego. Outro cenário é gateways de IoT: dispositivos que falam MQTT podem ter seus dados ingeridos por Workers que publicam em tópicos MQTT diretamente, sem passar por um broker HTTP intermediário. A combinação com Durable Objects para manter estado de sessão e Queues para garantia de entrega assíncrona torna a plataforma Workers uma alternativa real a arquiteturas baseadas em Kubernetes para cargas de trabalho orientadas a eventos.
Cloudflare Workers atualização: GLM-5.2, o modelo agentic de coding na edge
A terceira grande novidade desta Cloudflare Workers atualização é a chegada do GLM-5.2 ao catálogo do Workers AI. Desenvolvido pela Z.ai, o modelo @cf/zai-org/glm-5.2 é um text generation model construído especificamente para workflows de coding agentic. Ele traz function calling nativo, raciocínio multi-step e — este é o número que importa — suporte a uma janela de contexto de até 1.048.576 tokens. Na estreia no Workers AI, a janela está limitada a 262.144 tokens, com planos de expansão futura. Mesmo com a limitação inicial, é contexto suficiente para processar codebases inteiros de médio porte em uma única inference call.
GLM-5.2 é a resposta da Cloudflare à demanda crescente por modelos que não apenas geram código, mas que planejam, executam ferramentas e iteram sobre bases de código extensas. Diferente de modelos generalistas que foram adaptados para coding (como GPT-4 ou Claude), o GLM-5.2 foi treinado com foco em long-horizon planning — a capacidade de manter coerência através de múltiplos passos de raciocínio, chamadas de API e modificações de estado. Para desenvolvedores que constroem agentes de code review automatizado, geração de documentação, refatoração ou até mesmo debugging autônomo, o modelo está disponível via binding env.AI.run(), via REST API em /run ou /v1/chat/completions, e através do AI Gateway para observabilidade e controle de custos.
A precificação está publicada na página de modelos e na página de preços do Workers AI. O modelo consome AI Units — a métrica unificada de billing do Workers AI que normaliza custos entre diferentes modelos e tamanhos de contexto. Para times que operam com orçamento apertado, o AI Gateway oferece caching de respostas, rate limiting por token e logs detalhados de cada chamada — funcionalidades essenciais para manter previsibilidade financeira quando se escala agentes autônomos para centenas ou milhares de execuções diárias.
O posicionamento do GLM-5.2 no portfólio Workers AI complementa os modelos já existentes: Llama para tarefas generalistas, Mistral para eficiência em baixa latência, Whisper para transcrição, BERT para NLP clássico e Stable Diffusion para geração de imagens. Mas GLM-5.2 é o primeiro modelo no catálogo explicitamente desenhado para agentes de software — e isso sinaliza a direção estratégica da Cloudflare: transformar Workers de plataforma de funções serverless em plataforma de agentes autônomos. A aquisição de talentos da Ensemble AI, anunciada no mesmo período, reforça essa aposta em infraestrutura e eficiência de machine learning na edge.
Artifacts: repositórios Git-compatíveis direto no dashboard Cloudflare
Uma adição que passou mais discreta nos changelogs, mas que merece atenção de times de DevOps, é o gerenciamento de Artifacts pelo dashboard. Artifacts é um storage Git-compatível que permite armazenar repositórios na infraestrutura da Cloudflare e interagir com eles usando fluxos de trabalho Git padrão — clone, fetch, pull, push. A novidade é que agora é possível criar namespaces (containers top-level para repositórios), visualizar, criar e fazer fork de repositórios, abrir um repositório para visualizar arquivos e copiar a URL remota Git — tudo pelo dashboard, sem tocar na CLI.
O gerenciamento de tokens também foi integrado ao dashboard: é possível provisionar tokens de leitura (clone, fetch, pull) ou tokens de escrita (push) com escopo limitado a um único repositório. Para times que usam Workers e Pages com deploy via Git, isso simplifica a gestão de credenciais e reduz a superfície de ataque — em vez de tokens de GitHub com escopo amplo, o deploy pode usar um token Artifacts com acesso mínimo necessário. O recurso está disponível no caminho Storage & databases > Artifacts do dashboard, e está em beta — é necessário preencher o formulário de requisição para participar.
Para a JRT Technology Solutions, que gerencia dezenas de repositórios de configuração de infraestrutura como código para clientes corporativos, a capacidade de manter repositórios Git diretamente na Cloudflare — sem depender de GitHub, GitLab ou Bitbucket — é um avanço em soberania de dados. Repositórios que contêm configurações de WAF, regras de firewall e scripts de Workers podem residir na mesma infraestrutura que os executa, simplificando auditoria de conformidade e reduzindo a cadeia de dependências externas.
Impacto para desenvolvedores: o que muda na prática com esta atualização
Para times de desenvolvimento que já operam Workers em produção, esta atualização não é incremental — é transformacional. Vamos a uma análise prática do que muda em três dimensões: desenvolvimento, deploy e operação.
No desenvolvimento, o Agents SDK elimina a necessidade de orquestradores externos para agentes de IA. Antes, construir um agente que navega na web exigia uma combinação de Puppeteer/Playwright em um container, um message broker para coordenação e um Worker apenas como ponto de entrada HTTP. Agora, tudo roda no Worker, com o navegador como binding da plataforma. O Codemode, com seu log durável de execução e pause-and-resume nativo, substitui patterns frágeis de Saga ou workflows com retry manual — o próprio runtime garante que a execução retome do ponto correto após uma interrupção. Na prática, isso reduz o código de infraestrutura do agente em 60 a 80%, com ganho proporcional em confiabilidade.
No deploy, as VPC Networks com connect() TCP permitem que Workers acessem infraestrutura legada sem camadas de tradução de protocolo. O padrão anterior — expor Redis via HTTP, MySQL via REST, MQTT via WebSocket — introduzia latência, pontos de falha e superfície de ataque adicionais. Agora, o Worker conecta-se diretamente ao destino, com autenticação na camada de rede (via túnel Cloudflare) e sem intermediários. O deploy de um Worker que consulta Redis on-premise passa de “Worker + proxy HTTP + túnel + Redis” para “Worker + túnel + Redis” — uma redução de 25% na complexidade de componentes e eliminação de um ponto único de falha.
Na operação, a disponibilidade do GLM-5.2 no Workers AI significa que agentes de coding podem rodar totalmente na edge, sem egress para APIs externas como OpenAI ou Anthropic. Isso tem implicações profundas para custos (sem taxa de egress, sem markup de API de terceiros), latência (inferência no mesmo PoP que recebe a requisição) e conformidade (dados não saem da rede Cloudflare). Para empresas europeias e brasileiras sob LGPD, isso é um diferencial competitivo importante: o processamento de código fonte — que muitas vezes contém informações sensíveis de negócio — permanece na jurisdição correta.
A manutenção programada agendada para 22 de junho de 2026, das 12:00 às 13:00 UTC, afetará exclusivamente operações de configuração — deploys, edições no dashboard, chamadas de API que modificam configuração — por até 3 minutos. Workers e Pages em execução continuarão operando normalmente. É uma janela curta que não deve impactar tráfego de produção, mas times que planejam deploys críticos nesse horário devem agendar com antecedência. Recomendamos configurar alertas via Cloudflare Notifications integrados com PagerDuty ou webhooks para receber atualizações em tempo real.
Comparativo de mercado: Workers vs outras plataformas de edge em 2026
Para contextualizar o significado desta Cloudflare Workers atualização, é útil posicioná-la no cenário competitivo de edge computing em meados de 2026. O mercado se consolidou em três ofertas principais, cada uma com filosofias arquiteturais distintas:
