Volver
Construa Agentes Autônomos com o Claude Code SDK: Um Guia Prático para Desenvolvedores
June 20, 2026
19 min de lectura
Comparte este artículo

Construa Agentes Autônomos com o Claude Code SDK: Um Guia Prático para Desenvolvedores

A biblioteca oficial que transforma o mecanismo agente do Claude Code em um componente programável para CI, automação e sistemas multiagente.

Construa Agentes Autônomos com o Claude Code SDK: Um Guia Prático para Desenvolvedores

O Claude Code SDK — oficialmente chamado de Agent SDK — é uma biblioteca Python e TypeScript que permite acionar o motor agêntico completo do Claude Code de forma programática: sem terminal, sem uma pessoa no teclado, apenas sua aplicação chamando uma função assíncrona query() e recebendo em streaming cada etapa do trabalho do agente. Se você já usou o Claude Code interativamente, o SDK oferece esse mesmo loop de ler arquivos / editar código / executar comandos como uma biblioteca componível que você pode incorporar em pipelines de CI, bots de revisão de código, orquestradores multi-agente ou qualquer serviço de backend.


O Que é o Agent SDK — e Por Que Ele Existe

O Claude Code é bem conhecido como uma ferramenta de terminal. Você digita um prompt, o agente raciocina sobre sua base de código, chama ferramentas integradas (Read, Edit, Bash, Grep e outras) e escreve os resultados de volta para você. Mas no momento em que você quer automatizar esse loop — acionar uma revisão em cada pull request, distribuir tarefas para múltiplos sub-agentes especializados ou construir um produto sobre ele — a CLI interativa é a abstração errada. Você precisa de uma biblioteca.

O Agent SDK preenche essa lacuna. De acordo com a documentação oficial da Anthropic, ele expõe "as mesmas ferramentas, o mesmo loop de agente e o mesmo gerenciamento de contexto que alimentam o Claude Code, programáveis em Python e TypeScript." Isso não é linguagem de marketing — é a arquitetura literal. O SDK inicia o binário da CLI do Claude Code como um subprocesso gerenciado, se comunica com ele via stdio e expõe tudo como um stream assíncrono de objetos de mensagem tipados que seu código pode consumir e reagir.

Essa distinção importa por alguns motivos:

Mesmo motor, interface diferente. Ao migrar da CLI para o SDK, você não está indo para uma ferramenta inferior ou mais simples. O SDK herda todas as capacidades da CLI — conectividade com servidores MCP, ciclo de vida de hooks, arquivos de skill, memória do CLAUDE.md, delegação a sub-agentes e o conjunto completo de ferramentas.

O SDK executa as ferramentas para você. Se você usa o Anthropic Client SDK (o pacote Python/JS de nível mais baixo anthropic) e quer que o Claude chame ferramentas, você mesmo precisa implementar o loop de ferramentas: chamar a API, detectar uma resposta de uso de ferramenta, executar a ferramenta, retornar o resultado e repetir até o Claude parar. O Agent SDK reduz esse loop inteiro a um único async for message in query(...) — o Claude decide quais ferramentas chamar, as executa dentro do seu subprocesso e continua o loop até a tarefa ser concluída. Você apenas consome o stream.

Headless por design. Os prompts de permissão da CLI — "permitir este comando bash?" — bloqueiam esperando entrada humana. O SDK os substitui por uma opção permissionMode e um conjunto de modos de permissão — por exemplo acceptEdits para aprovar automaticamente edições de arquivos e bypassPermissions para executar tudo sem solicitações em um ambiente de CI isolado — além de um callback de aprovação programático para fluxos personalizados. Os nomes exatos dos modos e comportamentos estão documentados na referência do SDK da Anthropic (consulte-a para a lista atual), mas o efeito é o mesmo: sua automação nunca fica travada esperando uma tecla ser pressionada.

Interactive CLI vs Agent SDK architecture — two ways to invoke Claude Code O mesmo motor do Claude Code, duas interfaces: a CLI interativa para trabalho com humano no loop, o Agent SDK para automação programática e headless em que sua aplicação controla o prompt e um modo de permissão substitui a caixa de diálogo de aprovação.


Instalando o SDK

A Anthropic publica dois pacotes:

  • TypeScript: @anthropic-ai/claude-agent-sdk (npm)
  • Python: claude-agent-sdk (pip; requer Python 3.10+)

O pacote TypeScript empacota um binário nativo do Claude Code para sua plataforma, então nenhuma instalação separada da CLI é necessária. A autenticação é feita por meio de uma variável de ambiente ANTHROPIC_API_KEY obtida no Anthropic Console. O SDK também suporta Amazon Bedrock, Google Vertex AI e Microsoft Azure AI Foundry — consulte a documentação da Anthropic para os padrões de variáveis de ambiente relevantes.


Conceitos Fundamentais

Entender quatro conceitos cobre a grande maioria do uso real do SDK.

1. A Função query() e o Stream Assíncrono de Mensagens

Toda interação com o SDK começa com query(). Você passa uma string de prompt e um objeto options; em troca, recebe um iterador assíncrono que emite objetos de mensagem tipados enquanto o agente trabalha. O loop termina quando o agente finaliza ou encontra um erro.

As mensagens que você recebe incluem:

  • AssistantMessage — o raciocínio do Claude em texto e descrições de chamadas de ferramentas
  • ToolResultMessage — a saída de cada execução de ferramenta
  • ResultMessage — o resultado final, com um campo subtype indicando sucesso ou falha
  • SystemMessage — eventos do ciclo de vida da sessão (o subtipo init carrega o session_id)

Na maioria do código de produção, você filtra por ResultMessage para extrair a saída final e, opcionalmente, registra os blocos de AssistantMessage para rastrear o que o agente fez.

2. Ferramentas e allowedTools

O conjunto de ferramentas integradas do SDK mapeia diretamente para as capacidades do Claude Code:

FerramentaO que faz
ReadLer qualquer arquivo no diretório de trabalho
WriteCriar novos arquivos
EditFazer edições precisas em arquivos existentes
BashExecutar comandos de terminal, operações git, scripts
GlobEncontrar arquivos por padrão (**/*.ts, src/**/*.py)
GrepBuscar conteúdo de arquivos com regex
WebSearchPesquisar na web
WebFetchBuscar e analisar uma página web
AskUserQuestionFazer uma pergunta de esclarecimento ao usuário (fluxos interativos)
AgentIniciar um sub-agente definido em suas opções

A opção allowedTools pré-aprova um subconjunto dessas ferramentas, concedendo efetivamente ao agente permissão para chamá-las sem nenhuma restrição adicional. Um agente de auditoria somente leitura pode listar apenas ["Read", "Glob", "Grep"]; uma automação completa pode incluir ["Read", "Edit", "Bash", "Glob", "Grep"].

3. Modos de Permissão

Os modos de permissão controlam o que acontece quando o agente quer usar uma ferramenta que não está pré-aprovada em allowedTools:

  • acceptEdits — aprova automaticamente edições de arquivos e operações comuns do sistema de arquivos; solicita aprovação para tudo o mais. Melhor para fluxos de trabalho de desenvolvimento confiáveis.
  • dontAsk — nega silenciosamente qualquer coisa que não esteja em allowedTools. Melhor para agentes headless travados.
  • bypassPermissions — executa todas as ferramentas sem restrição. Use apenas dentro de um ambiente isolado (sandboxed).

O SDK também expõe um callback de aprovação programático para que você possa implementar uma lógica de aprovação totalmente personalizada, e os nomes de modo disponíveis podem se expandir ao longo do tempo — consulte a referência do SDK da Anthropic para a lista atual e autoritativa e o comportamento exato de cada um. Em CI, você quase sempre usará uma configuração restrita e de negação por padrão, ou bypassPermissions dentro de um sandbox em contêiner que você controla.

4. Sessões, Retomada e Contexto

Cada chamada a query() cria (ou retoma) uma sessão. O session_id da sessão chega na primeira SystemMessage com subtype === "init". Você pode capturá-lo e passá-lo como resume: sessionId em uma chamada subsequente para continuar exatamente de onde a conversa parou — mesmas leituras de arquivo, mesmo histórico de raciocínio, mesma janela de contexto.

É assim que você constrói agentes de múltiplos turnos: uma chamada query() analisa um módulo, captura o session_id, e uma segunda query() (com resume) faz referência a "ele" ou "o arquivo que você acabou de ler" sem reexplicar. As transcrições de sessão são gravadas em disco local por padrão; para produção, você pode anexar um adaptador SessionStore apoiado por S3, Redis ou Postgres para que as sessões sobrevivam a reinicializações de contêiner.


Padrão de Construção 1: Um Bot de Revisão de Código em CI

Este é o caso de uso canônico de "automação headless". A cada pull request, um job de CI faz checkout da branch, executa um agente que lê os arquivos alterados e publica um comentário de revisão.

O fluxo:

  1. Um evento de PR aciona um workflow do GitHub Actions (ou um job do GitLab CI).
  2. O runner faz checkout da branch e executa seu script de revisão.
  3. Seu script chama query() com um prompt de revisão, allowedTools: ["Read", "Glob", "Grep", "Bash"] e permissionMode: "dontAsk".
  4. O Claude lê o diff, busca padrões, raciocina sobre as descobertas.
  5. A ResultMessage carrega o texto da revisão; seu script o publica no PR via API do GitHub.

A decisão de design principal é usar dontAsk com uma lista de ferramentas somente leitura. O agente não pode escrever arquivos nem fazer chamadas de rede além do que as ferramentas permitem, então seu job de CI não pode acidentalmente mesclar commits ou chamar APIs externas. Um limite de maxTurns (definido nas opções) restringe a profundidade do agente para que loops descontrolados não consumam orçamento.

Para a arquitetura ilustrada deste fluxo, veja o diagrama abaixo.

CI code-review bot: PR event → Agent SDK → findings → PR comment Um pipeline de revisão de código totalmente automatizado. O agente do SDK é executado dentro de um contêiner de CI com uma lista de ferramentas somente leitura; as descobertas retornam em streaming como uma ResultMessage e seu código as publica como um comentário de PR no GitHub. O agente nunca escreve arquivos, nunca sai do contêiner.

Você pode estender esse padrão com hooks — um recurso do SDK abordado em nosso artigo aprofundado sobre hooks do Claude Code — para registrar cada chamada de ferramenta em um arquivo de auditoria, bloquear caminhos de arquivo específicos de serem lidos ou emitir telemetria estruturada junto com a revisão.


Padrão de Construção 2: Cadeias de Ferramentas Multi-Agente

A opção agents do SDK permite definir sub-agentes nomeados, cada um com seu próprio system prompt, lista de ferramentas e permissões. Seu agente principal delega trabalho a eles por meio da ferramenta integrada Agent. As mensagens de sub-agentes incluem um campo parent_tool_use_id para que você possa rastrear exatamente qual delegação produziu cada parte da saída.

Um exemplo prático: uma cadeia de agentes de auditoria de segurança em que um sub-agente code-scanner encontra possíveis vulnerabilidades usando Grep e Glob, um sub-agente dependency-checker executa Bash para consultar os metadados dos seus pacotes, e um agente coordenador sintetiza ambos os relatórios em uma auditoria unificada. Cada sub-agente tem o acesso mínimo de ferramentas necessário para sua função, limitando o raio de impacto caso um sub-agente alucine um comando perigoso.

Cadeias multi-agente funcionam bem para tarefas que se decompõem naturalmente: um agente por preocupação, cada um com uma lista de ferramentas restrita, orquestrados por um coordenador que só precisa de Read e Agent. Para uma visão mais ampla de como arquiteturas multi-agente se combinam com recursos do Claude Code como a memória do CLAUDE.md e arquivos de skill, veja nosso guia de engenharia de harness.


Padrão de Construção 3: Pipelines de Automação Headless

Além da revisão de código, o SDK se destaca em qualquer automação recorrente em que o agente é uma etapa de um pipeline maior:

Auditorias noturnas de dependências. Um cron job chama query() com um prompt para verificar pacotes desatualizados, executar scanners de segurança e produzir um relatório estruturado. A ferramenta Bash executa npm audit ou pip check; Read inspeciona arquivos de lock. A ResultMessage alimenta uma notificação no Slack.

Tradução e i18n ao mesclar PR. Quando um PR é mesclado, um webhook aciona um agente que lê os arquivos de string alterados com Glob e Read, produz versões traduzidas com Write e abre um novo PR via Bash (executando gh pr create).

Detecção de anomalias em logs. Envie a saída de log recente para um prompt query(). O agente lê arquivos de contexto adicionais se necessário, raciocina sobre os logs e emite uma descoberta estruturada. Nenhuma escrita de arquivo é necessária; uma lista de ferramentas somente leitura basta.

Sincronização de documentação. Após a mesclagem de PRs, um agente lê os arquivos-fonte atualizados e reescreve as páginas de documentação correspondentes, depois faz commit das alterações. O permissionMode: "acceptEdits" lida com as escritas de arquivo sem solicitações.

O fio condutor: query() substitui uma integração LLM sob medida. Você não implementa um loop de ferramentas, não gerencia janelas de contexto manualmente, nem analisa a saída do modelo para decidir o que executar em seguida. O agente lida com a orquestração; você fornece o prompt e consome o resultado.


Um Exemplo Ilustrativo Completo: Um Agente de Correção de Bugs

O quickstart oficial demonstra esse padrão de forma clara (o código abaixo segue a API documentada — verifique a sintaxe exata na documentação de quickstart da Anthropic):

Python ilustrativo (verifique a API exata na documentação oficial):

# Illustrative — confirm exact import paths and option names in official docs
import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AssistantMessage, ResultMessage

async def run_bug_fixer(file_path: str):
    async for message in query(
        prompt=f"Review {file_path} for bugs that would cause crashes. Fix any issues.",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Edit", "Glob"],
            permission_mode="acceptEdits",
        ),
    ):
        if isinstance(message, AssistantMessage):
            for block in message.content:
                if hasattr(block, "text"):
                    print(block.text)
        elif isinstance(message, ResultMessage):
            print(f"Completed: {message.subtype}")

asyncio.run(run_bug_fixer("src/utils.py"))

TypeScript ilustrativo (verifique a API exata na documentação oficial):

// Illustrative — confirm exact import paths and option names in official docs
import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt: "Review src/utils.ts for crash-causing bugs and fix them.",
  options: {
    allowedTools: ["Read", "Edit", "Glob"],
    permissionMode: "acceptEdits",
  },
})) {
  if (message.type === "assistant" && message.message?.content) {
    for (const block of message.message.content) {
      if ("text" in block) console.log(block.text);
    }
  }
  if (message.type === "result") console.log("Done:", message.subtype);
}

O que acontece quando isso é executado: o Claude lê utils.py (ou .ts) usando a ferramenta Read, raciocina sobre o código, identifica casos extremos e então chama Edit para inserir tratamento defensivo. Você vê o raciocínio e as chamadas de ferramentas passando em streaming como objetos AssistantMessage; a ResultMessage final sinaliza a conclusão. O loop completo do agente — incluindo reler o arquivo para verificar a edição — é gerenciado pelo SDK.

Isso é o que torna o SDK diferente de chamar diretamente a API de modelos da Anthropic: você não implementa a camada de execução de ferramentas. O Claude decide quando chamar Read, o chama, recebe o conteúdo do arquivo de volta e continua raciocinando. O loop é autônomo.


Permissões, Sandboxing e Segurança em Produção

Executar agentes autônomos em produção exige pensar cuidadosamente sobre o que eles podem acessar. O SDK fornece diversos controles em camadas.

A restrição de ferramentas é a primeira linha de defesa. Se um agente não precisa de Bash, não o inclua em allowedTools. Um agente com apenas ["Read", "Glob", "Grep"] não pode modificar arquivos, executar comandos de shell ou fazer chamadas de rede, independentemente do que seu prompt diga.

Os modos de permissão fornecem uma segunda barreira. dontAsk garante que qualquer coisa fora de allowedTools seja silenciosamente negada, em vez de solicitar aprovação. Isso é crítico em ambientes headless — um prompt que fica travado esperando entrada do usuário vai paralisar seu pipeline.

A opção cwd restringe o acesso do agente ao sistema de arquivos a um diretório específico. Em ambientes multi-tenant, passe um diretório de trabalho por sessão para que agentes de tenants diferentes não possam ler os arquivos uns dos outros.

O isolamento de tenants exige etapas adicionais: definir settingSources: [] para que nenhuma configuração de sistema de arquivos vaze entre tenants; definir CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 para impedir que a memória automática seja carregada; apontar CLAUDE_CONFIG_DIR para um caminho por tenant. Esses pontos estão documentados em detalhes no guia de hospedagem da Anthropic.

O sandboxing em contêiner é a camada externa. Para agentes de produção que precisam de acesso a Bash, execute o SDK dentro de um contêiner com o tráfego de saída de rede restrito aos domínios que você explicitamente permitir. Provedores como Modal, E2B, Cloudflare Sandboxes, Fly Machines e Vercel Sandbox são citados na documentação da Anthropic como opções para implantações isoladas do SDK.

maxTurns limita o número de idas e vindas de uso de ferramentas, restringindo tanto o custo quanto loops descontrolados. Defina-o com base na complexidade esperada da sua tarefa — uma revisão simples de leitura de arquivo pode precisar de 5 a 10 turnos; uma refatoração complexa de múltiplos arquivos pode precisar de 30 a 50.

Para equipes que constroem hooks e fluxos de permissão em produção, nosso guia de hooks do Claude Code cobre o ciclo de vida dos hooks PreToolUse e PostToolUse em detalhes, incluindo como escrever callbacks de hook que bloqueiam, transformam ou registram chamadas de ferramentas antes de serem executadas.


MCP: Conectando o Agente a Sistemas Externos

O SDK suporta totalmente o Model Context Protocol (MCP), que permite conectar seu agente a qualquer sistema externo que exponha um servidor MCP: bancos de dados, automação de navegador, Jira, Slack, GitHub e centenas de servidores construídos pela comunidade.

Você configura servidores MCP na opção mcpServers — cada entrada especifica um comando a ser executado e argumentos opcionais. O SDK inicia esses servidores como subprocessos, e o agente pode chamar suas ferramentas da mesma forma que chama ferramentas integradas. É assim que você dá a um agente de revisão de código acesso ao seu rastreador de issues, ou conecta um agente de documentação à base de conhecimento da sua empresa.

O modelo de permissões também se aplica a chamadas de ferramentas MCP — allowedTools pode incluir nomes de ferramentas MCP, e permissionMode rege o que acontece para ferramentas não listadas.


Armadilhas e Problemas Comuns

As sessões são locais ao subprocesso por padrão. As transcrições de sessão vivem no disco local do host em ~/.claude/projects/. Em implantações em contêiner ou escaladas horizontalmente, isso significa que o estado da sessão é perdido ao reiniciar ou ao ser reatribuído a outro nó. Use um adaptador SessionStore para qualquer sessão que você precise retomar entre contêineres.

O modelo de subprocesso tem implicações de memória. Cada sessão em execução é um subprocesso separado. Executar cinquenta sessões simultâneas significa cinquenta processos do Claude Code. A orientação oficial é de aproximadamente 1 GiB de RAM por agente como ponto de partida, mas o uso real de memória depende da duração da sessão e da atividade das ferramentas. Dimensione seus contêineres adequadamente e defina maxTurns para limitar a profundidade da sessão.

Grandes distribuições de sub-agentes atingem limites de taxa. Se seu orquestrador delega para vinte sub-agentes simultaneamente, você provavelmente vai atingir os limites de taxa da API da Anthropic. Divida distribuições amplas em lotes e adicione um pequeno atraso entre os envios.

bypassPermissions exige um sandbox de verdade. Este modo pula todas as barreiras de permissão. Ele foi projetado para ambientes totalmente controlados, como contêineres de CI onde você é dono de todo o contexto de execução. Usá-lo na máquina de um desenvolvedor — onde o agente tem acesso a chaves SSH, credenciais de nuvem e caminhos de sistema de arquivos arbitrários — é um risco de segurança.

O SDK TypeScript empacota o binário do Claude Code; o Python não exige isso separadamente. Mas ambos os SDKs fixam uma versão específica da CLI. Ao atualizar o pacote do SDK, você atualiza a CLI subjacente. Revise o changelog antes de atualizações menores — mudanças de comportamento que quebram compatibilidade são anunciadas ali.

O texto do prompt e as entradas de ferramentas não são incluídos nas exportações OTEL por padrão. Esse é um comportamento de privacidade intencional. Se você precisar de rastreamento em nível de prompt para depuração, precisa habilitá-lo explicitamente por meio de variáveis de ambiente documentadas no guia de observabilidade da Anthropic.

Versões mais antigas do SDK podem não suportar modelos mais novos. A documentação da Anthropic observa que modelos recentes podem exigir uma versão recente do SDK devido a mudanças na API do parâmetro de thinking, então um SDK desatualizado pode falhar com um modelo novo. Sempre confira o changelog e fixe uma versão conhecida como estável ao adotar novos modelos.


O SDK vs. a CLI: Qual Você Precisa?

Para a maioria dos desenvolvedores, a resposta é ambos — e isso é intencional.

A CLI interativa é a ferramenta certa para o desenvolvimento do dia a dia: explorar uma base de código desconhecida, trabalhar interativamente em um bug complexo ou executar uma refatoração pontual. O SDK é a ferramenta certa para qualquer coisa que precise rodar sem uma pessoa presente: CI, tarefas agendadas, recursos de aplicação e pipelines multi-agente.

O SDK e a CLI não são produtos concorrentes. Os fluxos de trabalho que você desenvolve interativamente com a CLI se traduzem diretamente em automação via SDK — mesmas ferramentas, mesmos conceitos de permissão, mesma memória do CLAUDE.md e sistema de skills. Um fluxo de revisão que você prototipa com claude no seu terminal hoje se torna um bot de CI baseado no SDK amanhã.

Para equipes que usam a versão web do Claude Code (abordada em nosso guia do Claude Code na web), o SDK abre a porta para combinar sessões web com orquestração programática — inicie uma tarefa de longa duração pela web e depois se conecte a ela programaticamente a partir do seu backend.


Perguntas Frequentes

O que é exatamente o Claude Code SDK (Agent SDK)? É uma biblioteca Python (claude-agent-sdk) e TypeScript (@anthropic-ai/claude-agent-sdk) que expõe o motor agêntico completo do Claude Code — ferramentas, permissões, gerenciamento de sessão, sub-agentes, MCP — como uma API assíncrona programável. Você chama query(), passa um prompt e opções, e recebe em streaming o trabalho do agente como objetos de mensagem tipados.

Eu preciso ter o Claude Code instalado para usar o SDK? Para o SDK TypeScript, não — o pacote empacota um binário nativo do Claude Code. Para o SDK Python, o pacote claude-agent-sdk cuida da dependência. Você precisa de uma chave de API da Anthropic obtida no Anthropic Console.

Posso usar o SDK com modelos diferentes do Claude na API da Anthropic? Sim. O SDK suporta Amazon Bedrock, Google Vertex AI, Microsoft Azure AI Foundry e Claude Platform na AWS por meio de variáveis de ambiente. Você também pode rotear requisições por meio de um proxy personalizado definindo ANTHROPIC_BASE_URL.

Como uso o SDK em um workflow do GitHub Actions? Adicione sua ANTHROPIC_API_KEY como um secret do GitHub Actions, faça checkout da branch do PR no seu workflow, instale o pacote do SDK e execute seu script de agente. Use permissionMode: "dontAsk" com uma lista allowedTools somente leitura para que o agente não possa modificar arquivos no seu ambiente de CI. A documentação da Anthropic também cobre uma integração dedicada com o GitHub Actions que automatiza a revisão de PR e a triagem de issues sem escrever código de SDK personalizado.

Qual é a diferença entre o Agent SDK e os Managed Agents? O Agent SDK é uma biblioteca que executa o loop do agente dentro do seu próprio processo e infraestrutura. Managed Agents é uma API REST hospedada em que a Anthropic executa o agente e o sandbox — você envia eventos e recebe resultados em streaming. O SDK é melhor para prototipagem local e agentes que trabalham diretamente no seu sistema de arquivos; Managed Agents é melhor para produção quando você não quer operar infraestrutura de contêineres.

Como limito o que o agente pode acessar? Use allowedTools para restringir quais ferramentas estão disponíveis, permissionMode: "dontAsk" para negar qualquer coisa fora dessa lista, e cwd para restringir o acesso ao sistema de arquivos a um diretório específico. Para implantações multi-tenant, defina também settingSources: [] e CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

O SDK suporta saída em streaming? Sim — o iterador assíncrono de query() transmite mensagens em tempo real. Se você não precisar de saída ao vivo (para jobs em segundo plano ou pipelines de CI em que você só se importa com o resultado final), a documentação da Anthropic descreve um modo de turno único que coleta todas as mensagens antes de retornar. Veja Streaming vs. single-turn mode na documentação oficial.

Posso executar múltiplos agentes em paralelo? Sim. Cada chamada query() inicia um subprocesso independente. Você pode executar N sessões simultâneas — mas cada uma é um processo separado, então provisione memória adequadamente e fique atento aos limites de taxa da API. Para distribuições concorrentes de sub-agentes a partir de um único orquestrador, divida seus envios em lotes para evitar atingir limites de taxa.

O que acontece se a sessão travar no meio da tarefa? Por padrão, as transcrições de sessão são locais ao contêiner e perdidas ao reiniciar. Para sobreviver a reinicializações, configure um adaptador SessionStore (S3, Redis ou Postgres) e o passe nas opções. Você pode então retomar a sessão pelo session_id em um contêiner novo.


Executando Agentes Sem Configuração Local

A proposta de valor do SDK é a automação — mas colocar essa automação em funcionamento exige infraestrutura real: um runtime Python ou Node, uma chave de API, uma estratégia de contêiner, uma decisão de sandboxing e tempo dedicado à modelagem de permissões antes da sua primeira implantação em produção.

Para desenvolvedores que querem iterar sobre ideias de agentes sem essa sobrecarga de configuração, o Happycapy executa agentes no estilo Claude Code diretamente no navegador. Não há instalação local, gerenciamento de subprocessos nem provisionamento de contêiner. Você traz um prompt, o Happycapy cuida do ambiente de execução — com acesso a mais de 150 modelos e um sandbox de nuvem seguro. É um caminho rápido para prototipar o comportamento do agente que você posteriormente colocará em produção com o SDK.

Comece grátis em happycapy.ai

Guias relacionados

Publicado el June 20, 2026
Más artículos
Claude Code SDK: Automação Headless em TypeScript e Python | HappyCapy | Happycapy