2026-05-26 · Atualizado 2026-07-22

[!NOTE] Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Agente AI de Execução Prolongada Runtime em 2026: Sessões, Sandboxes, Checkpoints e Ferramentas de Gestão

Parte 5 da série de engenharia da pilha Agentic

Os quatro artigos anteriores abordaram o design interno do agente: laços de raciocínio, memória, tool use, e segurança. Este artigo aborda o runtime que garante o funcionamento contínuo dessas componentes ao longo de sessões prolongadas e em caso de falhas no processo.

Uma execução de agente pode durar horas, enquanto o seu processo trabalhador pode ser reiniciado a qualquer momento. O modelo continua a escolher a próxima ação, mas o runtime deve preservar o estado, controlar a execução e recuperar de uma falha em pleno tool call. Este artigo define os limites do runtime. A Parte 6 analisará o harness existente dentro dele: a lógica de feedback, repetição, transferência e aceitação que determina se o agente continua a funcionar ou é interrompido.

O que é um agente AI runtime?

Um AI agente runtime representa a camada de infraestrutura responsável por manter um agente que utiliza ferramentas ativo, isolado, observável e capaz de ser retomado após o término da chamada ao modelo. Este componente gere o estado da sessão, a execução das ferramentas, checkpoints, as verificações de política, os segredos, os rastreios, os limites de custo e a estrutura de deploy. O modelo é responsável por escolher a próxima ação; já o runtime determina onde essa ação será executada, se é permitida, como será registrada e como a execução será retomada em caso de falha.

Utilize o runtime como unidade de projeto para agentes de execução contínua. Se não for possível indicar exatamente onde cada primitiva se encontra, o agente permanece um protótipo.

Execuções de longa duração quebram as premissas de processos estatais

Um endpoint de chat sem estado pode armazenar o estado da requisição num único processo e descartá‑lo após a resposta ser enviada. Uma execução prolongada de um agente abrange reinícios de workers, implantações, redefinições de contexto e pausas de aprovação. Nesse cenário, o processo worker já não pode ser considerado a fonte de verdade.

O time do OpenAI Codex informa o comprimento da sequência em seu harness engineering relatório técnico:

“Observamos regularmente que execuções únicas do Codex conseguem realizar uma única tarefa por mais de seis horas (geralmente enquanto os humanos estão a dormir).”

A equipa de engenharia da Anthropic descreve o problema de estado correspondente em Mecanismos eficazes para agentes em execução por longos períodos:

“O desafio principal dos agentes de execução prolongada reside no facto de eles terem de operar em sessões discretas, sendo que cada nova sessão começa sem qualquer memória do que ocorreu anteriormente.”

Ambas as observações indicam o mesmo design runtime: manter o estado fora do worker e tornar os workers substituíveis.

A sessão deve ser mantida fora do processo de trabalho. Um armazenamento duradouro regista as chamadas ao modelo, tool results, e as aprovações, para que outro processo de trabalho possa retomar a execução no último ponto seguro após uma falha. Os Checkpoints também permitem que o runtime inicie uma nova sessão do modelo quando a janela de contexto se enche, sem ser necessário reproduzir toda a história anterior. Em A forma de expressão da Anthropic, As harness tornam‑se descartáveis e passíveis de reinício; o estado duradouro é armazenado noutro local.

O modelo decide o que fazer a seguir. O runtime determina se a ação é permitida, onde ela é executada, como é registada e como a execução é retomada após uma falha. O resto deste artigo trata desse runtime.

As cinco primitivas runtime de que todo agente AI de execução contínua precisa

da Anthropic Escalar Agentes Geridos O documento descreve um vocabulário útil para as cinco responsabilidades de runtime. O harness faz com que o agente progrida, enquanto os registos da sessão registam o que foi feito e o sandbox executa comandos. O checkpoint fornece um ponto de retomada ao próximo processador; a trilha, por sua vez, conserva evidências para depurações futuras. Uma implementação pode fundir componentes, mas as responsabilidades e os limites de falha continuam a precisar de designações específicas.

Sessão. Um registo de apenas adição de tudo o que aconteceu: chamadas ao modelo, tool calls, resultados, erros, aprovações. A recuperação é wake(sessionId) → getSession(id) → resume from last event. Em LangGraph, isto é um thread_id plus um checkpointer do Postgres (ver Persistência do LangGraph). O OpenAI Agents SDK disponibiliza dez backends de sessão integrados, incluindo SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession, e EncryptedSession (ver o Documentação de sessões).

Harness. O ciclo de orquestração. Este ciclo chama o modelo, analisa tool calls, executa as ações correspondentes, grava os resultados de volta na sessão e aplica as regras de tentativa repetida. A Anthropic explica isso de forma direta:

“Cada componente num harness codifica uma premissa sobre o que o modelo não consegue fazer por si só.”

A equipa Codex da OpenAI chama a esta disciplina harness engineering: a escrita de software continua a exigir disciplina, mas agora mais esforço é dedicado à estruturação geral do projeto do que ao código em si. A LangGraph’s CompiledStateGraph, Agentes Profundos’ create_deep_agent, O próprio Claude Code é, nesse sentido, mais um desses mecanismos de aproveitamento.

Sandbox. O ambiente de execução isolado onde os comandos são efetivamente executados. Os SDK da OpenAI Agents sandbox conceitos A página delimita o contorno de forma limpa:

“O runtime externo continua a ser responsável pelas aprovações, rastreio, transferências de responsabilidade e registo de retomadas. A sessão sandbox é responsável pelos comandos, alterações de ficheiros e isolamento do ambiente.”

Sandboxes diferem quanto à duração da sua existência e ao que conseguem reter entre execuções. A forma mais simples é a de efêmeros frescos: cria-se um instância para uma única tarefa, elimina‑se‑a quando a tarefa termina, suportando assim o custo de inicialização em cada execução.

Persistent paused sandboxes permite manter o sistema de ficheiros e uma cópia de estado da memória entre execuções. A retoma seguinte pode evitar um arranque completo. As opções Snapshot ou fork criam uma imagem do tipo “copy-on-write” a partir de um pai pré-preparado, permitindo que várias tarefas compartilhem dependências instaladas e caches já carregados, sem precisar partilhar o seu estado gravável.

Per-worktree sandboxes garante que cada tarefa dispõe do seu próprio espaço de trabalho e conjunto de ferramentas de observabilidade. A separação entre registos, métricas e rastreios permite depurar uma execução sem que o seu estado afete outra. A tabela de fornecedores apresentada mais adiante neste artigo compara o comportamento em cenários de arranque a frio e de persistência.

Checkpoint. Estado resumível. do LangGraph PostgresSaver escreve um StateSnapshot em cada limite de super-etapa, com escritas por tarefa checkpoint_writes Assim, os resultados dos nós bem-sucedidos não são recalculados quando um nó irmão falha. O snapshot é um dicionário JSON-serializável.v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) documentado no langgraph-checkpoint-postgres página do PyPI e o LangGraph checkpoints de referência.

Rastreio. A interface de reprodução e depuração. Cada chamada ao modelo, tool call, e cada passo do subagente torna‑se um intervalo que inclui informações sobre o tempo decorrido, entradas, saídas, contagens de tokens e custo. Quando uma execução de seis horas falha, é o rastreio que se analisa para determinar o que correu mal. Nessa altura, a saída do terminal da execução já desapareceu há muito tempo. OpenTelemetry’s Convenções semânticas de GenAI padronizar os nomes dos atributos (que modelo, que fornecedor, quantos tokens, que conversa, que fluxo de trabalho), de modo que o mesmo rasto seja exibido de forma clara em Tempo de processamento, Jaeger, Honeycomb, ou LangSmith sem necessidade de reinstrumentação.

A política e os segredos encontram‑se em domínios distintos runtime

Duas fronteiras atravessam todas as cinco primitivas e são mais fáceis de abordar como preocupações distintas. Trata‑se da versão runtime do argumento de segurança proveniente de Parte 4.

Mecanismo de políticas

Uma verificação de permissões é executada antes de cada tool call e decide se a operação será autorizada ou não. Existem dois padrões comuns em ambientes de produção. O Deep Agents permite que cada subagente declare quais caminhos de ficheiro pode ler ou escrever, sendo que o middleware bloqueia qualquer acesso fora dessas declarações. Já o Anthropic Managed Agents encaminha cada tool call através de um proxy MCP, de modo que é o proxy a aplicar as permissões em vez do código do agente. Quando uma chamada sensível requer aprovação humana, o LangGraph’s interrupt() E o gancho de aprovação dos Agentes Profundos pausa o grafo até que uma pessoa diga “sim”.

Agente secreto

O modelo não deve ter acesso a segredos de longa duração, e o sandbox também geralmente não deve. O padrão de Agentes Geridos é o que deve ser adotado:

“No Git, utilizamos o token de acesso de cada repositório para clonar o repositório durante a inicialização de sandbox e integrá‑lo no remoto local do git. Git” push e pull O processamento é realizado diretamente dentro do sandbox, sem que o agente tenha de lidar diretamente com o token em si. Para ferramentas personalizadas, suportamos MCP e armazenamos os tokens OAuth num repositório seguro. O Claude aciona as ferramentas MCP através de um proxy dedicado; este proxy recebe um token associado à sessão. … O harness nunca fica a par de quaisquer credenciais.”

Na market-analyst-agent pilha de referência, o sidecar MCP lê os tokens OAuth a partir de um segredo Docker (em produção, HashiCorp Vault) e expõe apenas a interface da ferramenta ao worker do LangGraph. O worker nunca vê o token. git push funciona corretamente cat ~/.ssh/id_rsa não.

Uma verificação prática de validade consiste em listar todos os componentes e indicar qual das cinco primitivas eles implementam. Postgres Pode abranger a sessão e o checkpoint. O contêiner de trabalho é o harness. Um serviço como Daytona, Modal, ou E2B fornece o sandbox, enquanto Tempo de processamento ou LangSmith armazena o rasto.

Agora, analisemos as falhas acopladas. Se duas primitivas residirem no mesmo processo, uma falha faz com que ambas parem de funcionar. Se elas partilharem uma credencial, uma fuga de dados pode ultrapassar as fronteiras de ambas. Exemplos comuns incluem um worker que também controla a durabilidade dos registos de rastreio ou um token sidecar que, simultaneamente, desbloqueia a base de dados checkpoint.

Modos de falha do agente runtime em produção AI

O runtime gere as tentativas de execução, recupera o trabalho anterior, isola os espaços de trabalho e aplica restrições orçamentais. As cinco primitivas mencionadas acima controlam o ciclo de vida das execuções, enquanto mecanismos de política e gestão de segredos atuam em conjunto com elas. À medida que as execuções se estendem por vários processadores e janelas de contexto, os problemas tendem a manifestar-se através de alterações de estado, efeitos colaterais duplicados, sandbox e violações das restrições orçamentais.

As falhas dividem-se em quatro grupos:

• Falhas de qualidade da saída: o agente declara vitória antes mesmo de o trabalho ser concluído, esquece o que fez após a redefinição da janela de contexto ou confia na sua própria autoavaliação, enviando assim uma saída defeituosa.
• Falhas de controle de custos: o agente fica preso num ciclo de tentativas repetidas ou esgota o orçamento de tokens ou chamadas de ferramentas sem produzir nada útil.
• Falhas relacionadas com o estado e travamentos: os espaços de trabalho sofrem alterações porque uma execução acede a ficheiros pertencentes a outra execução, tool calls é acionado mais de uma vez devido às repetidas tentativas, ou o trabalho é perdido quando um processo termina entre eventos.
• Falhas da janela de contexto: o modelo faz um resumo e encerra prematuramente por achar que está a esgotar o espaço disponível, mesmo quando ainda existe margem na janela.

A tabela associa cada falha a uma medida de mitigação, ao gancho runtime que a aplica, bem como à base que sustenta a recomendação. Como o comportamento específico de cada modelo pode variar, deve tratar as observações dos fornecedores como prompts, de modo a retestar as premissas em vez de as considerar regras permanentes.

Duas ideias são apresentadas em cada linha. A Anthropic, no que diz respeito à antiguidade de harness Harness design para o desenvolvimento de aplicações de execução contínua:

“Cada componente num harness codifica uma suposição sobre o que o modelo não consegue fazer por si só, e essas suposições merecem ser submetidas a testes de estresse, tanto porque podem estar incorretas, como porque podem tornar‑se rapidamente obsoletas à medida que os modelos evoluem.”

Vercel, no que diz respeito ao problema associado de demasiadas ferramentas que codificam um número excessivo de pressupostos, em Removemos 80% das ferramentas do nosso agente.:

“Eliminámos a maior parte do conteúdo e reduzimos o agente a uma única ferramenta: executar comandos Bash arbitrários. Chamamos a isto um agente de sistema de ficheiros.”

O resultado reportado pela Vercel para uma consulta representativa indica que a taxa de sucesso passou de 80% para 100%, enquanto o pior caso diminuiu de 724 s / 100 passos / 145.463 tokens (falhado) para 141 s / 19 passos / 67.483 tokens (bem-sucedido). A lição a tirar não é “excluir as suas ferramentas”. Trata-se de compreender que cada primitivo presente no seu runtime, incluindo a interface de utilização das ferramentas, possui um tempo de vida limitado. É necessário reavaliar essas premissas sempre que o modelo sofrer alterações.

Cognition observou o mesmo alvo em movimento em relação à duração da sessão com o Sonnet 4.5. Em Reconstruir o Devin para o Claude Sonnet 4.5 eles descrevem um modelo que escreve de forma proativa SUMMARY.md / CHANGELOG.md Dado que deteta o esgotamento do contexto, mas subestima a quantidade de tokens que ainda possui, a solução encontrada foi ativar a versão beta com 1 milhão de tokens e limitar a sua utilização a 200 mil, de modo a que o modelo continue a acreditar que ainda tem margem disponível. Contudo, essa medida de mitigação acabará também por se tornar um fator inútil.

A equipa da harness da OpenAI resume esta disciplina numa única frase: “Os humanos orientam. Os agentes executam.” Quando algo falha, a pergunta não é “tentar com mais esforço”, mas sim “qual capacidade está em falta e como a podemos tornar tanto compreensível quanto aplicável ao agente?”.

O ciclo de vida de uma execução saudável

Uma execução que se comporta de forma previsível é monótona. Trata‑se de uma sequência de pequenos passos recuperáveis, sendo que cada um deles grava o seu resultado num armazenamento duradouro antes que o próximo comece.

Essa fronteira contém danos causados por falhas. Quando ocorre uma falha, é perdido apenas o passo em curso da execução, sendo que o próximo agente retoma a partir do último passo concluído, em vez de reiniciar todo o processo.

1. Inicie a sessão tanto a partir de uma nova como de uma retomada. Ao retomar, monte o espaço de trabalho a partir do seu estado mais recente conhecido e leia quaisquer ficheiros de progresso deixados pela tentativa anterior (PROGRESS.md, feature-list.json), e carrega o último checkpoint da base de dados. É aqui que o harness transfere para o agente tudo o que o trabalhador anterior tinha em memória antes de falhar.
2. Planeie antes de iniciar qualquer tool calls. Defina como é que algo está “concluído”, quanto tempo a execução pode durar, quais ferramentas o agente pode utilizar e o que deve interromper a execução antecipadamente. Estes valores de plano tornam‑se verificações runtime; sem eles, a execução não tem nada contra o que se opor.
3. Execute um tool call de cada vez. A camada de política decide se permite a chamada. O harness executa‑a, regista o resultado e escreve um evento no registo de sessão. Um passo, um evento. Uma falha entre eventos é recuperável, pois o registo, e não a memória do trabalhador, é a fonte de verdade.
4. Faça Checkpoint nas fronteiras das super‑etapas, ou após cada evento num harness mais simples. Persista o estado do grafo, a diferença no espaço de trabalho e as referências a quaisquer artefatos produzidos. Este checkpoint é o que a etapa 1 lê na próxima retomada. Se o checkpoint estiver faltando ou desatualizado, a recuperação é reduzida à reprodução integral do registo de sessão desde o início, o que é muito mais lento.
5. Avalie os resultados face aos artefatos quando o agente considerar que a tarefa está concluída: testes, revisão com contexto atualizado, validação de esquema e verificações no navegador. Se a verificação for bem-sucedida, a execução termina com sucesso. Caso falhe, a execução é retomada a partir do último estado checkpoint válido, com a mensagem de erro adicionada ao contexto, para tentativa novamente.

Não existe nenhuma etapa nessa lista que exija que o agente se lembre de algo entre execuções. O estado permanece na sessão e no checkpoint, sendo que o agente o lê novamente em cada retomada.

Ferramentas que causam efeitos colaterais exigem propriedade de idempotência. Qualquer ferramenta com efeitos colaterais necessita de uma chave de idempotência, obtida a partir do ID da sessão e do ID da chamada à ferramenta, sendo armazenada antes de o efeito colateral ser ativado. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). A execução “pelo menos uma vez” é o padrão em filas e motores de fluxo de trabalho. Se a repetição de um tool call puder causar danos reais, a ferramenta ainda não está preparada para ser utilizada com agentes.

A avaliação deve incluir evidências provenientes de um contexto diferente daquele em que foi produzida. Um avaliador independente reduz o viés de contexto partilhado, enquanto testes, ferramentas de análise de código, verificações no navegador e validação de esquemas fornecem evidências determinísticas. A verificação pode retornar pass, fail, ou needs_human. Nos agentes de código, o revisor pode ser outra sessão de modelo equipada com ferramentas de apenas leitura. Nos agentes de dados e relatórios, deve‑se combinar a validação determinística com um modelo de revisor, já que ainda é necessário um julgamento humano.

Onze padrões de implementação de agentes AI e os fatores que os determinam

Assim que as cinco primitivas são nomeadas, surge a questão de qual formato de implementação as irá executar. Por “formato”, refiro-me a uma disposição dessas primitivas: onde se encontra o harness, onde o estado é armazenado e que tipo de sandbox realiza o processamento. Não se trata apenas de uma escolha feita por um único fornecedor. O gráfico abaixo indica em que ponto cada formato se enquadra no eixo de duração das execuções. O texto seguinte explica os fatores que determinam a escolha entre eles.

Se tiver de ler apenas um dos onze modelos apresentados, leia o modelo 2: fila + trabalhador + checkpoint DB. Trata‑se da configuração padrão que recomendo para a maioria das equipas, do modelo utilizado no repositório de referência e do esqueleto em torno do qual a maioria dos outros modelos se baseia: fila → trabalhador → estado duradouro, com a fonte sandbox, o proprietário harness ou o motor de estado a ser substituído. Ao ler primeiro o modelo 2, fica mais fácil analisar os restantes.

O gráfico compara as formas com base no comprimento da sequência de execução. A matriz abaixo compara‑as por propriedade: ou seja, indica onde cada uma das cinco primitivas se encontra fisicamente. As células verdes indicam os locais onde a forma fornece a primitiva; as cinzentas indicam os locais onde ela é conectada manualmente.

1. SDK dentro de um servidor de aplicações (síncrono, com escopo por requisição)

A forma original. O agente SDK é executado dentro de um manipulador de solicitações. É adequado para tarefas que levam menos de 30 segundos, demonstrações e ferramentas internas. Não é adequado para situações em que um cliente HTTP possa interromper a conexão. O tempo de espera HTTP do Cloud Run O tempo de execução atinge um limite máximo de 60 minutos, e qualquer erro crítico no layer da web interrompe imediatamente a execução. O SDK corresponde ao harness; o processo web funciona também como sandbox, sendo que o estado geralmente permanece na memória do processo, a menos que seja explicitamente transferido para outro local. Não utilize esta solução para tarefas que demandem várias horas de processamento.

2. Fila + worker + checkpoint de bases de dados

O padrão que recomendo para a maioria das equipas, e a forma em produção utilizada em market-analyst-agent: um worker em Python com um checkpointer do PostgreSQL, Streams do Redis (ou) RabbitMQ) Para a fila de entrada, existe ainda um MCP sidecar dedicado às ferramentas auxiliares. É adequado para execuções que vão de 10 minutos a várias horas, com passos idempotentes. O executor local permite contornar a fila durante o desenvolvimento síncrono, mas a fila torna-se essencial no ambiente de produção quando é necessária a submissão assíncrona e a gestão de backpressure.

A aplicação aceita um pedido, cria uma linha de sessão, envia um trabalho para processamento e devolve um ID de execução. O worker retira o trabalho, executa o harness, grava os resultados em checkpoints, transmite atualizações de status em tempo real e armazena os artefatos gerados ao longo do processo. O banco de dados Postgres permanece estável, os workers funcionam como recursos computacionais simples, e a profundidade da fila oferece mecanismos de controlo de carga. Os recursos de computação Spot/Preemptible funcionam desde que o mecanismo de verificação termine de gravar os dados no disco antes de reportar sucesso.

Nesta estrutura, o agente responsável pela execução é o harness. O seu contêiner e o espaço de trabalho por thread criam uma fronteira de execução, mas o código não confiável ainda necessita de um sandbox ou VM reforçada. O Postgres gere o estado da sessão e de checkpoint. Os rastreios são enviados através de OpenTelemetry para qualquer stack de observabilidade que esteja em uso.

3. Motor de fluxo de trabalho duradouro (estilo Temporal)

O código de orquestração de agentes é executado dentro de um Fluxo de Trabalho Temporal; as chamadas ao modelo e os tool calls são processados como Atividades. O estado do fluxo de trabalho é armazenado num registo de histórico de eventos suportado por Cassandra, MySQL ou Postgres, permitindo assim a reprodução fiel do estado em diferentes implementações. A versão de pré-visualização pública Integração de Temporal com OpenAI Agents SDK envia um OpenAIAgentsPlugin e um activity_as_tool helper, e o descrição detalhada de agentic e sandboxes descreve o processo de bifurcação de um agente em execução para um fornecedor sandbox diferente durante uma conversa em curso. Os fluxos de trabalho ociosos consomem zero recursos de processamento. As restrições são reais: os agentes de transmissão em fluxo contínuo e de voz não são suportados na integração atual, e LocalShellTool e ComputerTool Estão desativados porque não se enquadram num modelo distribuído.

Utilize esta forma quando a execução apresentar pontos de espera reais: aprovações humanas, chamadas externas, períodos de inatividade prolongados, tentativas de repetição com regras de negócio e janelas de deploy. Uma aprovação humana transforma-se num período de inatividade duradouro que não consome recursos de processamento, ao contrário de um ciclo de polling.

O código do fluxo de trabalho é o harness. O sandbox encontra‑se normalmente fora do Temporal e é chamado a partir das Atividades. O estado da sessão e do checkpoint é integrado no registo de histórico de eventos do Temporal, enquanto a visibilidade das trilhas provém da interface do Temporal juntamente com os intervalos OpenTelemetry em cada Atividade.

4. Provedor Sandbox por sessão

Uma arquitetura mais recente. Cada execução de agente recebe a sua própria microVM ou contêiner proveniente de um fornecedor de sandbox como serviço. O harness fica armazenado num local duradouro; o sandbox representa o ambiente de execução descartável.

A tabela combina os Comparação entre E2B e Daytona, Daytona’s documentação sandboxes e fork/registro de alterações do snapshot, modal’s sandboxes e início em frio guias, o Descrição no AWS Marketplace para Runloop, e Vercel Sandbox – preços.

O Daytona regista uma ligação pai-filho para cada fork independente, o que permite preservar a linhagem dos sandboxes derivados. O harness do Codex da OpenAI utiliza a variante por worktree: “O Codex funciona numa versão totalmente isolada dessa aplicação, incluindo os seus registos e métricas, que são eliminados assim que a tarefa é concluída.”

Recorra a esta forma quando o agente executa código não fidedigno, automação de navegador, testes ou instalações de pacotes. O compromisso envolve custos e maior acoplamento com o fornecedor, valores ambos superiores aos observados ao utilizar workers partilhados.

O fornecedor é o proprietário do sandbox e de mais nada. O Harness, a sessão, o checkpoint e o rastreio permanecem do seu lado, geralmente organizados na estrutura de fila + trabalhador descrita em #2.

5. Agentes Geridos pela Anthropic (hospedados em harness)

A Anthropic lançou os Managed Agents em beta público a 8 de abril de 2026, de forma restrita. managed-agents-2026-04-01 Cabeçalho beta. O serviço oferece uma sessão hospedada, harness, sandbox, bem como um proxy com suporte de cofre MCP. wake(sessionId) É possível inicializar o harness num novo worker sem perder o estado da sessão persistente.

O Claude cobra pelos Managed Agents às taxas padrão de tokens, mais 0,08 $ por hora-sessão. A faturação é feita com precisão até ao nível dos milissegundos e aplica-se apenas enquanto o estado da sessão for “em execução”; o tempo ocioso não é cobrado. Por isso, um ciclo de tentativas descontrolado acaba por acrescentar um custo por hora-sessão, além do custo associado aos tokens.

Leia as ressalvas. O desconto em lote API não se aplica (“As sessões são com estado e interativas. Não existe um modo de lote.”). Os Agentes Geridos não estão disponíveis através de AWS Bedrock ou Google Vertex AI. Multi-agent Cooperação e autoavaliação ainda se encontram em fase de pré-teste na pesquisa. O risco de lock-in é elevado: você faz um compromisso de longo prazo. harness liberdade de não ter de executar o ciclo manualmente.

A Anthropic aloca todas as cinco primitivas: session, harness, sandbox, checkpoint e trace. Você fornece o runtime e recebe os resultados correspondentes.

6. Implantação de Agentes Avançados do LangChain (gerido de forma aberta harness)

deepagents deploy pacotes a deepagents.toml em uma implantação LangSmith com execução duradoura, gestão de memória, arquitetura multi-tenant, human-in-the-loop, capacidades de observabilidade, execução de código em ambiente isolado e execuções agendadas. São suportados modos de implantação em nuvem, híbrido e auto-hospedado. Os fornecedores de Sandbox (LangSmith Sandboxes, Daytona, Modal, Runloop ou soluções personalizadas) podem ser alternados através de um único valor de configuração. O estado é armazenado em um sistema de ficheiros virtual com backends intercambiáveis; a memória é atribuída por usuário, assistente ou ambos. O risco de dependência excessiva é menor em comparação com Agentes Geridos: o harness está licenciado sob a licença MIT, e as instruções utilizam recursos abertos. AGENTS.md padrão, e os agentes são expostos através de MCP, A2A e do Agent Protocol. Consulte o LangChain para mais detalhes. runtime – agentes profundos em ambiente de produção relatório técnico.

As cinco primitivas são alojadas por predefinição, mas cada uma pode ser substituída através da configuração. O sandbox encontra‑se associado a um valor de configuração específico. A sessão e o checkpoint residem num sistema de ficheiros virtual que suporta backends intercambiáveis. O rastreio é processado pelo LangSmith.

7. Serviço ou job do Google Cloud Run

O Cloud Run dispõe de dois modos runtime distintos, sendo que a escolha entre eles depende da forma como o agente é invocado. Os Services estão ligados ao protocolo HTTP e escalam para zero entre solicitações; o harness funciona como um processador de pedidos que termina a sua atividade assim que a execução é concluída. Já os Jobs são executados até ao fim sem necessidade de um ponto de entrada HTTP; o harness atua como um trabalhador de uso único que encerra a sua execução quando a tarefa é finalizada. Ambos podem alojar o harness, mas nenhum deles mantém estado entre execuções diferentes. As sessões e o checkpoints devem ser armazenadas no Postgres, no Spanner ou noutro repositório externo semelhante.

Os limites intrínsecos são bastante diferentes entre os dois. Tempo de espera excedido na solicitação ao serviço Cloud Run: Por predefinição, 300 s; no máximo, 3.600 s (60 min). WebSockets obter o mesmo tempo de espera. Tarefas Cloud Run: Por predefinição, são 10 minutos por tarefa, com um limite máximo de 168 horas (7 dias); para tarefas que utilizam GPUs, o limite máximo é de 1 hora. Os serviços são escalonados para zero, a menos que se ative o modo sempre ativo CPU; as tarefas não dispõem de interface HTTP e não são escalonadas automaticamente.

Utilize um serviço para execuções síncronas com duração até 60 minutos. Recorra a um job para tarefas únicas mais longas ou assíncronas. Os Cloud Run Jobs permitem que uma tarefa permaneça ativa durante dias, mas não oferecem capacidade de reprodução fiável entre diferentes implementações, alterações de versão ou substituição de workers. Acima de 7 dias, evite utilizar o Cloud Run.

O Cloud Run hospeda o harness. O estado das sessões e de checkpoint encontra-se armazenado no Postgres, no Spanner ou noutro repositório externo, sendo que os rastreios podem ser transmitidos através do Cloud Logging e de OpenTelemetry. O contêiner de serviço funciona como ambiente de execução; deve ser adicionado um sandbox separado sempre que o agente executar código não fidedigno.

8. AWS Lambda (porque é a ferramenta errada)

O tempo máximo de execução de uma função Lambda é de 900 s (15 minutos), o que é bastante difícil. Se o API Gateway ficar na frente da função, o limite de integração dependerá do tipo de API. O HTTP APIs permite um intervalo de 30 segundos; As integrações REST utilizam, por predefinição, um tempo de 29 segundos, enquanto Os endpoints REST regionais e privados APIs permitem definir um tempo de espera mais longo.. Nenhum desses caminhos transforma o Lambda num processo que permanece ativo por horas. Um processo em execução contínua harness ainda necessita de estado externo e de nova invocação, o que acaba por recriar a estrutura típica de fila + trabalhador. Utilize o Lambda para tarefas com tempo de execução limitado tool calls, como a recuperação de ficheiros ou o envio para o S3, sendo estas invocadas por um orquestrador que permanece ativo por mais tempo. Não coloque o orquestrador nesse contexto.

No máximo, o Lambda pode conter um tool call dentro do seu limite de 15 minutos. O harness, ou seja, a sessão, bem como o checkpoint e o sandbox, além do rastreamento, têm de ser armazenados noutro local.

9. Tarefa AWS ECS / Fargate por execução

Os documentos do Fargate não estabelecem um limite máximo para as tarefas runtime, ao contrário do Lambda. Quotas de limitação de Fargate Permite um pico de lançamento de 100 unidades, com reabastecimento a uma taxa de 20 unidades por segundo, dispondo de orçamentos separados para solicitações sob demanda e para operações spot. quotas de serviço ECS Capacitar os serviços através da descoberta via AWS Cloud Map para 1.000 tarefas por serviço, e de clusters suportados por EC2 para 5.000 instâncias de contêiner.

Fargate exige awsvpc Neste modo, cada tarefa recebe uma interface de rede e um IP privado. Essa estrutura é adequada para o acesso a dados dentro da VPC. O Fargate Spot introduz riscos de interrupção, sendo que a durabilidade dos dados continua a ser sua responsabilidade, já que a plataforma não dispõe de funcionalidades de reprodução semelhantes às do Temporal.

O Fargate hospeda o harness e atribui uma tarefa distinta a cada execução. Isso separa os espaços de trabalho das credenciais das tarefas, mas por si só não constitui uma proteção completa contra código malicioso, ou seja, um sandbox eficaz. A gestão de sessões, checkpoint, e o rastreamento são realizados através de serviços externos como RDS ou DynamoDB, além de CloudWatch/X-Ray.

10. Job do Kubernetes ou namespace por sessão

Útil quando já se trabalha com isso. Kubernetes e pretende-se sandbox-por sessão, com controlos em toda a cluster. Isso é problemático quando se precisa de um tempo de arranque inferior a um segundo, pois a transferência da imagem do contêiner e a inicialização do pod demoram demasiado tempo num arranque a partir do zero. O padrão consiste em um Job para cada agente executado, com activeDeadlineSeconds, um PersistentVolumeClaim para o espaço de trabalho, e um sidecar para o servidor MCP. A recuperação em caso de falha deve ser implementada por si. Adotar o Kubernetes apenas para hospedar agentes acarreta custos elevados em termos de sobrecarga de configuração e esforço operacional. Só faz sentido se já estiver a utilizar o K8s por outros motivos.

O Kubernetes aloja o harness e o ambiente de execução por execução, geralmente como um Job e, por vezes, com um namespace dedicado. Uma forte isolação continua a depender da classe runtime, das políticas de rede, da segurança dos pods, bem como das fronteiras dos containers ou VMs subjacentes. A sessão e o estado checkpoint são armazenados numa base de dados externa ou num PersistentVolumeClaim.

11. Docker Compose local (apenas para desenvolvimento)

Referência para a secção seguinte. O objetivo desta estrutura é refletir exatamente a topologia de produção – com as mesmas primitivas e a mesma configuração de rede –, mas executada numa única máquina. Leia a lista “não segura para produção” no final da próxima secção antes de enviar qualquer solução com este formato.

Componha a estrutura de mirrors #2 num único host. O Postgres gere a sessão e o estado checkpoint, enquanto o contêiner de trabalho atua como o harness. A montagem do espaço de trabalho partilhado é conveniente para desenvolvimento, mas não isola execuções não confiáveis. A pilha opcional OpenTelemetry regista os rastreios.

Pilha de referência: Docker Compose

A topologia de referência, utilizada em slavadubrov/market-analyst-agent, é um worker do LangGraph, um checkpointer do Postgres, Qdrant para a recuperação de dados, um sidecar MCP, uma fila Redis para execuções assíncronas semelhantes às em produção, e um opcional Prometheus / Grafana / Loki / Tempo / OTel stack de observabilidade. No local compose, o Redis é opcional apenas porque o executor síncrono consegue chamar diretamente o worker. docker compose up ativa toda a topologia localmente.

A única parte que vale a pena exibir de forma inline é o esquema de conexão canónico do LangGraph. Trata‑se do exemplo concreto mais pequeno da primitiva checkpoint:

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observabilidade que persiste durante a execução

Os manipuladores de solicitações de curta duração são fáceis de depurar: quando algo falha, basta ler a resposta e o registo em tempo real. Os agentes com execução prolongada não dispõem desse luxo. Quando uma execução de seis horas falha, o evento relevante já ocorreu há cinco horas, a saída do terminal em tempo real desapareceu e o processo que a gerou já foi substituído. Ninguém conseguirá reconstituir a execução apenas com base na memória. Por isso, a depuração é feita a partir de artefatos duradouros que foram gravados enquanto a execução ainda estava ativa.

As pilhas de produção costumam abranger quatro tipos de artefatos, divididos em dois grupos. Dois deles são lidos depois de a execução terminar, para fins de pós-mortem e reprodução: um registo de eventos consultável com todos os passos realizados, e os rastreios OpenTelemetry que indicam para onde foram gastos tempo e tokens. Os outros dois são consultados durante a execução, para acompanhar o processo em tempo real: um histórico em tempo real do que o agente está a gerar no espaço de trabalho, e uma pilha de observabilidade por worktree que o próprio agente pode consultar enquanto ainda está em funcionamento.

Registo de eventos estruturado (a ser lido após a execução)

Cada chamada de modelo, tool call, resultado, erro e aprovação é gravado em armazenamento duradouro, indexado por ID de sessão e data/hora. Assim que a execução termina, pode consultá‑lo como se fosse uma tabela de base de dados normal. Addy Osmani estabelece um padrão claro nesse aspecto. Agentes de execução prolongada: “Se não for possível reconstituir o que o agente realizou nas últimas 24 horas a partir de armazenamento duradouro, o que se tem é um script shell em execução contínua que, por acaso, chama um LLM, e não um agente em execução contínua.”

OpenTelemetry Registos da GenAI (a serem lidos após a execução)

O mesmo tipo de dados passo a passo, mas emitidos como spans utilizando os atributos padrão do gen_ai.* convenções semânticas: nome do modelo, fornecedor, contagem de tokens de entrada e saída, ID da conversa, nome do fluxo de trabalho (estado de desenvolvimento até a versão v1.36.0). Os campos específicos do fornecedor encontram‑se em subespaços de nomes.anthropic.*, openai.*) desativado por chave gen_ai.provider.nameA razão para utilizar o padrão é a portabilidade: o mesmo rasto é exibido corretamente no Tempo, Jaeger, Honeycomb ou LangSmith, sem ser necessário reinstrumentar o código de cada vez que se muda de backend.

Cronologia das chamadas de ferramenta e diferenças no espaço de trabalho (a serem lidas durante a execução)

O modo mais rápido de saber o que um agente está a fazer neste momento é seguir o que ele produz na área de trabalho, em vez de procurar nos registos da sessão. A Anthropic’s Harness Primitivas para Agentes Claude de Execução Prolongada O quick-start fornece dois ganchos para isso: watch -n 5 'git log --oneline -8' exibe os últimos commits que o agente realizou, e watch -n 5 'find screenshots -name "*.png" | tail -5' Exibe as últimas capturas de ecrã que foi gerando. Duas abas de terminal a atualizarem-se a cada cinco segundos são suficientes para determinar se uma execução está a fazer progresso real ou se está apenas a girar sem resultado.

Pilha efêmera por worktree (lida pelo próprio agente, durante a execução)

Por O artigo da OpenAI sobre harness: “Os registos, métricas e rastreios são expostos ao Codex através de uma pilha de observabilidade local que é efémera para cada worktree específico.” Cada agente worktree dispõe da sua própria instância temporária de Loki + Prometheus + Tempo, limitada apenas àquela execução em particular. O agente consulta esses sistemas enquanto está em funcionamento. É isso que permite que uma prompt como “nenhum período de tempo nestas quatro jornadas do utilizador excede dois segundos” se torne algo que o agente pode verificar diretamente, em vez de algo que tenha de adivinhar.

(O avaliador de contexto fresco da tabela de modos de falha lê estes artefatos para determinar se o processo está “concluído”. Ele faz parte da avaliação, e não da observabilidade; consulte § Ciclo de vida de execução saudável.

Uma pilha de observabilidade auto-hospedada mínima

Para algo do tipo market-analyst-agent:

1. OpenTelemetry Collector, equipado com o processador GenAI e um filtro de atributos gen_ai.*.
2. Tempo (ou Jaeger) para rastreios, indexado por gen_ai.conversation.id / thread_id.
3. Loki para entradas estruturadas de logs de eventos.
4. Prometheus para gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (ver o Convenções de métricas de GenAI).
5. Painéis Grafana baseados em gen_ai.agent.name e gen_ai.request.model.

Alternativas hospedadas (escolha uma, não três):

• LangSmith: Integração nativa com o LangGraph; também é o alvo de deploy para o Deep Agents Deploy. equipa de especialistas: A opção mais adequada caso os conjuntos de regressão com avaliação em primeiro lugar sejam a prioridade.
• Arize Phoenix: OSS, nativo OTLP, funciona em parceria com OpenInference Instrumentação.
• O painel de rastreio da OpenAI: ativa-se automaticamente quando se utiliza os OpenAI Agents SDK ou a sua integração Temporal.
• O rastreio do Claude da Anthropic: destinado a sessões executadas dentro de Managed Agents.

Instrumentar o nó LangGraph

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.response.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

nomes de atributos retirados literalmente do OpenTelemetry Registo de convenções semânticas de GenAI.

Consultas relativas a três falhas comuns

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

O padrão de bundle de depuração

Quando uma execução falhar, o worker deve ser interrompido. /workspaces/${THREAD_ID}/_debug/ contendo os artefatos que solicitaria num postmortem:

• session.jsonl: exportação completa do registo de eventos do PostgresSaver (checkpointer.list({"thread_id": ...})).
• last_state.json: StateSnapshot.values a partir do último super-passo bem-sucedido. trace.json: Intervalos exportados em OTLP para a execução.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: o diretório da área de trabalho, além de git diff em oposição ao commit de inicialização. screenshots/*.png: o que o agente observou.
• PROGRESS.md, feature-list.json, e quaisquer outros ficheiros de progresso criados pelo agente. env.txt: etiquetas de imagem, versão do modelo, SHA do commit harness.

Este conjunto fornece a um agente humano ou de revisão evidências suficientes para reconstituir a falha. A expressão “O agente ficou preso” é vaga. Um relatório ilustrativo é concreto: sessão s_123 Gastou 71 por cento dos seus tokens a repetir três comandos consecutivamente após npm install Falhou.

Escolher a forma correta: um guia de decisão

A maior parte da comparação apresentada resume‑se a um pequeno número de decisões a tomar.

Comece com o comprimento de execução

Utilize o comprimento de sequência como o primeiro filtro:

• Menos de 30 segundos, idempotente: ciclo de vida da requisição SDK num servidor de aplicações.
• De 30 s a 60 min, sem necessidade de recuperação em caso de falha: fila + worker + base de dados checkpoint.
• De 60 min a 24 h: mesma fila + worker, ou um Cloud Run Job para tarefas únicas. Utilize um motor de fluxos de trabalho duradouro se também precisar de funcionalidades de versionamento e reprodução.
• Mais de 24 h, deve sobreviver a novas implementações: motor de fluxos de trabalho duradouro (no estilo Temporal). Os Cloud Run Jobs conseguem armazenar trabalhos de longa duração até ao limite definido para as tarefas, mas não oferecem suporte a semânticas de reprodução.
• Laços de treino de RL de vários dias: K8s Job + volume de armazenamento + Temporal.

Após esse filtro grosseiro, verifique os efeitos colaterais, a capacidade de recuperação, a funcionalidade de reprodução, o isolamento, a localização dos dados, bem como a equipa que irá operar o sistema.

Adequação da plataforma por caso de uso

A matriz é densa porque nenhuma única célula verde determina a arquitetura. Uma ampla cobertura de cargas de trabalho é útil, mas não reflete a residência dos dados, as semânticas de reprodução, a dependência em relação ao fornecedor, o nível de maturidade operacional, nem o custo associado à movimentação do estado posteriormente.

O Deep Agents Deploy abrange todos os tipos de carga de trabalho registados na matriz, o que o torna uma opção adequada quando se precisa de uma única plataforma para executar tarefas de curta duração, trabalhos que duram várias horas, agentes de código, agentes de investigação e tarefas agendadas. Contudo, essa abrangência resulta num histórico de produção mais curto em comparação com uma arquitetura baseada em filas + workers + Postgres. Trate as células verdes como afirmações de capacidade a serem validadas e, em seguida, compare-as com as restrições operacionais que a matriz não consegue refletir.

Os Agentes Geridos da Anthropic ou se adaptam na totalidade ao seu volume de trabalho ou não se adequam de todo. O produto apresenta três restrições estritas: é exclusivamente hospedado, utiliza apenas o Claude e tem duração inferior a 24 horas por sessão. Se o seu volume de trabalho cumprir todas estas condições, como, por exemplo, um agente de programação interno que funciona em períodos de 2 a 6 horas e para o qual prefere não gerir o harness manualmente, os Agentes Geridos são uma solução ideal, pois eliminam uma grande parte do trabalho relacionado com a plataforma da sua equipa. Caso alguma restrição seja violada — devido à necessidade de um modelo diferente do Claude, de uma implementação auto-hospedada ou de sessões com duração de 48 horas — os Agentes Geridos não são adequados. Nenhuma alteração de configuração consegue contornar isso.

A definição de preços deve ser modelada antes de se tomar uma decisão final, e não depois. A taxa por hora de sessão é de $0,08/hora, além dos custos padrão dos tokens. Se uma única sessão decorresse continuamente, o custo seria de aproximadamente$58 por mês por sessão. Com 100 sessões em execução contínua, o valor chega a cerca de $5.800 por mês _antes dos custos com tokens_. Multiplique$0,08 pelas horas estimadas de sessões simultâneas, adicione esse valor à sua fatura de tokens e compare com o custo de uma estrutura de fila e workers na sua própria infraestrutura. Faça isso antes de se comprometer, pois migrar para soluções fora dos Managed Agents posteriormente implica um processo de replateamento, e não apenas uma alteração de configurações.

Soluções hospedadas harness versus soluções próprias harness

A distinção aqui é de natureza operacional, e não relacionada com a pessoa que escreveu o código harness. Hospedado significa que o fornecedor executa o ciclo harness na sua infraestrutura, sendo que o utilizador aciona um API. Propriedade própria significa que o ciclo é executado na própria infraestrutura do utilizador, mesmo que o código harness em si tenha sido fornecido por um terceiro.

O LangChain aparece em ambos os lados desta linha, o que confunde as pessoas. Eles disponibilizam o LangGraph, uma biblioteca licenciada pelo MIT que pode ser hospedada e controlada pelo utilizador, e o Deep Agents Deploy, um produto gerido que executa agentes Deep Agents. harness na implementação do LangSmith no seu modo cloud padrão (hospedado). Mesma empresa, dois modelos operacionais diferentes. É o utilizador que escolhe o modelo, e não o fornecedor. (O Deep Agents Deploy também dispõe de um modo auto-hospedado para equipas que desejam isso) harness ergonomia sem o componente baseado na nuvem; esse modo é armazenado no bucket próprio.)

Escolha um harness hospedado sempre que o suporte ao modelo, os limites de dados, o comportamento de recuperação e os pontos de extensão já se encaixem nas suas necessidades. Opte por um harness próprio quando essas restrições forem condições que pretende modificar posteriormente. A migração entre os dois tipos altera o estado do sistema, a capacidade de observabilidade e os limites de execução; portanto, teste cuidadosamente o processo de transição antes de os dados em produção passarem a depender dele.

Ambiente hospedado sandbox versus ambiente de execução próprio

Escolha um sandbox hospedado quando a isolamento oferecido pelo fornecedor, as funcionalidades de pausa/reinício ou as semânticas de fork se adequarem ao modelo de ameaças e ao orçamento disponível para inicialização. O Docker ou o Fargate podem ser adequados para cargas de trabalho internas confiáveis que necessitam de acesso à VPC ou de uma residência estrita de dados, mas um contêiner padrão não constitui uma barreira suficiente contra código malicioso. Adicione o gVisor, o Kata, uma microVM ou outro runtime reforçado sempre que o agente instalar pacotes não confiáveis ou executar programas gerados.

Armazenamento de estado: Git, BD e armazenamento de objetos lado a lado

Os agentes de execução prolongada costumam utilizar três armazenamentos de estado em simultâneo, uma vez que cada um deles guarda um artefato distinto.

O Git armazena o estado do espaço de trabalho: o código, os documentos e os ficheiros de progresso que o agente modifica. Cada commit fornece ao harness um ponto de recuperação estável e, na sessão seguinte, uma história compacta.

A base de dados checkpoint armazena o estado do grafo: o que foi decidido, quais nós foram executados, quais resultados foram retornados e o que deve ser executado a seguir. O repositório de artefatos contém saídas finais de grande volume, como ficheiros PDF, ficheiros Parquet e capturas de ecrã. Esses artefatos não devem ser guardados no Git nem na base de dados checkpoint.

Quando utilizar o git como estado

Utilize o git quando o volume de trabalho tem formato de código (edição em vários ficheiros, refatorações, geração de aplicações) ou é suficientemente documental para que o histórico dos ficheiros seja relevante. O padrão é simples: crie uma ramificação de execução, faça um commit inicial e, em seguida, efetue commits em marcos significativos: após a configuração, após cada funcionalidade, após a aprovação dos testes e após a limpeza final. Armazene o SHA do último commit do espaço de trabalho ao lado da linha checkpoint. Ao retomar o trabalho, o próximo colaborador faz checkout da ramificação e lê git log --oneline -8, inspeciona git status e a diferença mais recente, e depois lê PROGRESS.md ou qualquer ficheiro de transferência que a sessão anterior tenha gravado.

Isso faz com que o git funcione como uma superfície de recuperação para o artefato em edição, e não como um substituto para a base de dados checkpoint. O git consegue responder a duas perguntas: o que mudou e qual versão passou nos testes. No entanto, ele não é capaz de indicar ao harness qual nó do grafo deve ser executado a seguir, qual tool call está aguardando aprovação ou qual tentativa já utilizou a sua chave de idempotência. O harness da Anthropic utiliza commits iniciais, além de commits por funcionalidade, como fonte de verdade para a recuperação do espaço de trabalho; o modelo lê git log --oneline -8 para recuperar o estado. Ignore o Git quando o resultado do trabalho for apenas uma resposta de conversação; o custo adicional não compensa.

Quando utilizar o checkpointing de BD

Utilize PostgresSaverO uso de checkpoints no estilo planner → researcher → writer → verifier, quando o agente possui uma estrutura de grafo com vários nós cujo estado intermediário é relevante. O repositório de referência utiliza este método exatamente por esse motivo. Não coloque artefatos de ambiente de trabalho em escala de terabytes no checkpoint; esses devem ser armazenados em sistemas de armazenamento de objetos.

Quando utilizar um repositório de artefatos (S3 / GCS)

Utilize armazenamento de objetos quando:

• A saída é maior do que o tamanho que a base de dados checkpoint deve suportar;
• Os consumidores finais necessitam de um artefato acessível por URL, sem precisar passar pelo agente; ou
• O resultado final e o estado de execução possuem períodos de retenção diferentes.

Por exemplo, pode eliminar o registo da sessão após 30 dias, mas manter o relatório final durante anos. Defina a estrutura com base nisso. (thread_id, checkpoint_id, artifact_name) Assim, a execução de produção permanece reconstituível.

Quando adicionar gateways de aprovação humana

Adicione portas de controle sempre que o tool call for destrutivo e irreversível (escrevimentos em bancos de dados, movimentações financeiras, envio de comunicações externas), quando o tool call sair do raio de influência do agente (implantações em produção, publicações voltadas para clientes) ou quando os reguladores exigirem uma revisão. O LangGraph’s interrupt() Tanto o mecanismo de aprovação dos Agentes Profundos como o middleware correspondente dispõem de suporte integrado para estas portas de controle. Parte 4 Explicou por que estas portas representam um problema de permissões, e não um problema relacionado com prompt.

Uma lista de verificação prática para produção

Antes de um agente de execução prolongada ser lançado, responda a estas questões utilizando termos concretos relacionados com a infraestrutura.

1. Qual loja é responsável pelos eventos de sessão e por checkpoints?
2. O que acontece se o worker falhar a meio de um tool call?
3. É possível que um processo corrompa o espaço de trabalho de outro processo?
4. Quais ações exigem aprovação?
5. O modelo ou sandbox consegue ler credenciais em formato bruto?
6. Qual tool calls pode ser retentado com segurança?
7. O limite de custo por execução é aplicado onde?
8. Qual verificação de contexto atual decide quando um processo está “concluído”?
9. Onde são armazenados os resultados finais após o fim do sandbox?
10. Podemos explicar um processo que falhou amanhã sem tê-lo de executar novamente?

Se a resposta para qualquer uma destas questões for “o prompt indica ao agente que deve ter cuidado”, o sistema ainda não foi implementado. Trata‑se ainda de uma versão de demonstração.

A camada seguinte é o ciclo harness

Este runtime consegue manter uma execução ativa e recuperável, mas a durabilidade não comprova que o trabalho esteja correto. Parte 6, Harness Engineering para Agentes AI, abrange o ciclo em torno do modelo: como um rastreio se transforma num caso de teste, onde residem as regras de tentativa e interrupção, o que uma transferência deve preservar, e como uma verificação externa de aceitação determina que uma execução foi concluída.

Referências

Documentação de engenharia

• OpenAI, Harness engineering: a utilização do Codex num mundo orientado para agentes.
• Engenharia Anthropic, Mecanismos eficazes para agentes em execução por longo período de tempo.
• Engenharia Anthropic, Harness design para o desenvolvimento de aplicações de execução contínua.
• Engenharia Anthropic, Escalar Agentes Geridos: Desacoplar o “cérebro” das “mãos”, 8 de abril de 2026.
• Cognição AI, Reconstrução do Devin para o Claude Sonnet 4.5: Lições e Desafios.
• Vercel, Removemos 80% das ferramentas do nosso agente..
• Addy Osmani, Agentes de execução contínua.

LangGraph e Agentes Profundos

• Documentação do LangGraph, Persistência.
• Referência LangGraph, Checkpoints.
• langgraph-checkpoint-postgres na PyPI.
• Documentação da LangChain, Visão geral de Agentes Profundos.
• Blog da LangChain, O runtime por trás dos Agentes Profissionais em produção.

Agentes OpenAI SDK

• Agentes OpenAI SDK, Sessões.
• Agentes OpenAI SDK, Sandbox conceitos.

Temporal

• Blog temporal, Apresentamos o Temporal e o agentic sandboxes: os SDK de OpenAI.
• Blog temporal, Agentes prontos para produção com o OpenAI Agents SDK + Temporal.
• Temporal × OpenAI Agents SDK contrib README (temporalio/sdk-python).

Plataforma Anthropic

• Anthropic, Preços da plataforma Claude: Taxas por hora de sessão dos Agentes Geridos. anthropics/cwc-long-running-agents: Código para levar para casa com o Claude 2026, incluindo subagente de avaliação e padrões de ficheiro de progresso.

Sandbox fornecedores

• ZenML, E2B vs Daytona: comparação sandbox para engenheiros de plataforma.
• Documentação da Daytona, Sandboxes.
• Histórico de alterações da Daytona, Sandbox fork e endpoints de instantâneo.
• Documentação modal, Sandboxes.
• Documentação modal, Guia de arranque a frio.
• Runloop no AWS Marketplace.
• Preços e limites da Vercel Sandbox.

Tempo de espera e cotas da plataforma cloud

• Google Cloud, Configurar o tempo de espera para solicitações aos serviços.
• Google Cloud, Utilização de WebSockets.
• Google Cloud, Definir o tempo de espera para tarefas em trabalhos.
• AWS, Configurar o tempo de espera da função Lambda.
• AWS, Cotas Lambda.
• AWS, Quotas de limitação de Fargate.
• AWS, Cotas de serviço ECS e limites de throttling de API.

Observabilidade

• OpenTelemetry, Convenções semânticas para sistemas gerativos AI.
• OpenTelemetry, Registo de atributos Gen AI.
• OpenTelemetry, Convenções semânticas para agentes de GenAI e spans de framework.
• OpenTelemetry, Convenções semânticas para métricas gerativas de AI.

Séries

• Parte 1: AI Laços de Raciocínio de Agente em 2026: ReAct, ReWOO e Plan-and-Execute. Parte 2: AI Arquitetura de Memória de Agente em 2026: checkpoints, armazenamentos vetoriais e memória de documentos. Parte 3: AI Agente Tool Use em 2026: MCP, CLI, competências, execução de código e ACI.
• Parte 4: AI Segurança de Agentes em 2026: regras de segurança, permissões, sandboxes, HITL e delimitação de escopo por MCP.
• Parte 5: Agente AI de execução contínua Runtime em 2026 (este artigo) Parte 6: Harness Engineering para Agentes AI: verificações de aceitação, rastreios, tentativas repetidas, transferências de responsabilidade e o ciclo de iteração em torno do modelo.

O código do Agente Analista de Mercado (worker LangGraph, checkpointer Postgres, memória Qdrant, sidecar MCP, e a topologia Docker Compose descrita acima) encontra-se em GitHub._