Do Interpretador de Código ao Computador do Agente: Por Que os Agentes Precisam de Sandboxes com Estado

Os agentes precisam de sandboxes com estado quando uma tarefa requer arquivos persistentes, dependências instaladas, acesso a navegador ou pré-visualização, comandos de longa duração e revisão repetível de saídas além de uma única execução de código. Um interpretador de código ainda é útil para cálculos limitados, gráficos e scripts únicos. No momento em que um agente precisa editar um repositório, repetir um teste com falha, manter artefatos gerados, inspecionar uma interface web ou devolver o trabalho a um humano, ele precisa de algo mais próximo de um espaço de trabalho ou computador de agente.

O que mudou do interpretador de código para o computador do agente?

As primeiras funcionalidades de “interpretador de código” resolveram um problema restrito, mas importante: permitir que um modelo escreva e execute código, geralmente Python, em arquivos anexados a uma conversa. Isso é suficiente para muitas tarefas de dados. Um usuário pode enviar um CSV, pedir uma transformação, obter um gráfico e baixar a saída.

O trabalho de agente tem uma área de superfície maior. Um agente de codificação pode precisar clonar um projeto, instalar dependências, editar arquivos, executar testes, inspecionar logs, iniciar um servidor de desenvolvimento, abrir uma pré-visualização, corrigir o resultado e preservar o estado por tempo suficiente para um revisor verificar o que mudou. Um agente de navegador pode precisar de cookies, arquivos baixados, capturas de tela, estado do DOM e uma maneira de repetir uma etapa com falha. Um agente de pesquisa ou avaliação pode precisar de centenas de workers isolados que mantenham artefatos e logs para inspeção posterior.

É por isso que o vocabulário está mudando:

• Interpretador de código significa uma ferramenta de execução gerenciada para scripts curtos e saídas geradas.
• Sandbox significa um ambiente isolado onde trabalhos não confiáveis ou gerados por agente podem ser executados longe do sistema host.
• Espaço de trabalho significa um ambiente baseado em arquivos onde o estado da tarefa pode se acumular em várias etapas.
• Computador de agente significa um runtime mais completo com arquivos, comandos, pacotes, acesso a navegador ou interface do usuário, logs, pré-visualizações, artefatos, controles de ciclo de vida e opções de redefinição ou snapshot.

Esses termos se sobrepõem. A distinção útil não é de marca; é quanto estado e superfície de revisão o agente precisa.

O que significam os termos principais?

Conceito	Trabalho principal	Modelo de estado típico	Melhor ajuste
Interpretador de código	Executar código gerado e retornar saídas	Estado de sessão de curta duração	Cálculos, transformações de arquivos, gráficos, pequenos scripts
Sandbox	Isolar a execução do host e de outras sessões	Efêmero ou persistente	Execução de código não confiável, execução de comandos, automação de navegador
Espaço de trabalho	Manter arquivos e contexto do ambiente juntos	Sistema de arquivos persistente ou imagem restaurável	Agentes de codificação, projetos de dados, transferência de tarefas, revisão repetível
Computador de agente	Dar ao agente um ambiente de tarefas com ferramentas e controles de ciclo de vida	Runtime com estado com logs, artefatos, pré-visualizações e caminhos de redefinição/snapshot	Tarefas de software em várias etapas, agentes de navegador, avaliações, fluxos de trabalho de longa duração

O mesmo produto pode cobrir mais de uma caixa. Uma sandbox com estado pode se comportar como um espaço de trabalho. Um espaço de trabalho com terminal, navegador, artefatos e gerenciamento de ciclo de vida começa a parecer um computador de agente. A questão de avaliação é o que o agente pode fazer, que estado sobrevive e com que confiabilidade os humanos podem inspecionar ou redefinir o resultado.

Quando a execução de código efêmera é suficiente?

A execução efêmera ainda é o padrão correto quando a tarefa é pequena, limitada e fácil de verificar a partir da saída final.

Use um ambiente do tipo interpretador de código de curta duração quando:

• Os arquivos de entrada são fornecidos antecipadamente.
• A tarefa pode ser concluída em uma ou algumas execuções de script.
• A saída é um gráfico, tabela, arquivo transformado ou cálculo.
• Nenhuma instalação de pacote além do ambiente gerenciado é necessária.
• O usuário não precisa inspecionar um aplicativo em execução, estado do navegador ou log de comando longo.
• A sessão pode ser descartada assim que a resposta for entregue.

Por exemplo, um analista de suporte pedindo a um assistente para agrupar tickets por categoria não precisa de um espaço de trabalho persistente. Um analista de dados pedindo uma visualização única pode não precisar de acesso ao navegador ou snapshots. Adicionar mais infraestrutura do que o trabalho exige pode tornar o ciclo de vida, o custo e a revisão de segurança mais difíceis.

Quando os agentes precisam de uma sandbox com estado?

As sandboxes com estado se tornam importantes quando o agente não está apenas computando uma resposta, mas operando por meio de um fluxo de trabalho.

Os arquivos devem sobreviver a várias etapas

Os agentes frequentemente criam arquivos intermediários: dados de origem baixados, código gerado, fixtures de teste, artefatos de construção, capturas de tela, relatórios e logs. Se cada execução começa do zero, o agente tem que reconstruir o contexto repetidamente ou comprimir muito estado no prompt do modelo.

Um sistema de arquivos com estado dá ao agente uma memória de trabalho fora da janela de contexto. Também dá aos humanos algo concreto para inspecionar.

As dependências precisam ser instaladas ou reutilizadas

Muitas tarefas reais dependem de pacotes que não estão presentes em um runtime padrão. Um agente de codificação pode precisar de npm ci, pip install, um navegador Playwright, um compilador ou um binário específico do projeto. Um agente de dados pode precisar de uma versão de biblioteca que corresponda à produção.

Se essas dependências desaparecerem após cada comando, o agente perde tempo e cria mais pontos de falha. Modelos e snapshots ajudam as equipes a começar de um ambiente conhecido em vez de reconstruí-lo a cada execução.

Os comandos podem durar mais do que uma única rodada do modelo

Construções, testes, rastreadores, migrações, trabalhos de treinamento e harnesses de avaliação podem durar mais do que um único ciclo de resposta. Os agentes precisam iniciar um comando, observar a saída, recuperar-se de falhas parciais e capturar logs.

Isso requer estado de processo. Também requer controles de tempo limite, cancelamento e uma maneira de recuperar resultados depois que o modelo passou para a próxima etapa.

O acesso ao navegador e à pré-visualização se torna parte da tarefa

Muitos fluxos de trabalho de agente são visuais ou voltados para a web:

• Um agente de codificação inicia um aplicativo web local e verifica a página renderizada.
• Um agente de navegador navega em um site, baixa arquivos, preenche formulários ou captura capturas de tela.
• Um agente de revisão verifica se um gráfico, relatório ou página de demonstração realmente renderiza.

Para esses trabalhos, o ambiente precisa de mais do que stdout. Precisa de portas, URLs de pré-visualização, automação de navegador, capturas de tela ou algum outro caminho de artefato que permita ao agente e ao revisor ver o resultado.

A revisão humana precisa de evidências repetíveis

Um agente pode dizer “testes passaram” ou “o aplicativo parece correto”, mas as equipes de produção precisam de evidências repetíveis. Um bom runtime mantém logs, arquivos gerados, capturas de tela e links de pré-visualização por tempo suficiente para outra pessoa ou processo revisá-los.

É aqui que as sandboxes com estado mudam o modelo de colaboração. A sandbox não é apenas uma ferramenta para o modelo; é também um artefato de revisão.

O que uma sandbox de agente com estado deve preservar?

O estado é útil apenas quando é intencional. Uma sandbox com estado deve deixar claro o que sobrevive, o que é redefinido e o que pode ser transformado em um ponto de partida reutilizável.

Estado do sistema de arquivos

O sistema de arquivos é a unidade básica do trabalho do agente. Ele deve conter arquivos de origem, saídas geradas, artefatos de teste, logs, capturas de tela e entradas baixadas. Também deve ser fácil listar, ler, escrever, fazer upload e download de arquivos por meio de um SDK, CLI ou interface do usuário.

Estado do runtime e dos pacotes

O runtime deve suportar as linguagens e gerenciadores de pacotes que a tarefa requer. Para agentes de codificação, isso geralmente significa comandos de shell, dependências no nível do projeto e a capacidade de reutilizar um ambiente preparado. Para agentes de navegador, pode incluir binários de navegador e estruturas de automação.

Acesso à rede e à web

O acesso à rede precisa de uma política cuidadosa, não de uma abertura vaga. Alguns agentes precisam de downloads de pacotes de saída, chamadas de API ou navegação na web. Outros devem ser executados com regras de egresso mais restritas. As equipes devem avaliar se o runtime permite que elas decidam o que a sandbox pode alcançar e como essas escolhas são registradas.

Captura de pré-visualização e artefatos

A saída do agente geralmente inclui mais do que texto. Procure suporte para arquivos, capturas de tela, sessões de navegador, portas expostas, pré-visualizações web e logs de comando. Esses artefatos são como os revisores passam de confiar na afirmação do agente a verificar o resultado real.

Controles de ciclo de vida

Com estado não significa permanente. O runtime deve suportar criação, tempo limite, pausa ou retomada quando disponível, término e limpeza. Também deve suportar modelos ou snapshots para que um ambiente preparado possa ser reutilizado sem preservar todas as sessões para sempre.

Caminhos de redefinição e snapshot

Agentes cometem erros. Um computador de agente prático precisa de um caminho de redefinição limpo e uma maneira de capturar um bom estado antes de trabalhos arriscados. Snapshots são úteis após a configuração, após a instalação de dependências ou antes de uma longa execução de avaliação.

Como as equipes devem avaliar um runtime de agente?

Os critérios de avaliação devem ser separados das alegações do fornecedor. O runtime certo depende do fluxo de trabalho, perfil de risco e processo de revisão.

Critério	O que perguntar	Por que é importante
Ciclo de vida	Como os ambientes são criados, pausados, retomados, com tempo limite e excluídos?	Evita sessões abandonadas e custo descontrolado
Sistema de arquivos	O agente e o revisor podem inspecionar arquivos e artefatos?	Torna o trabalho em várias etapas revisável
Instalação de pacotes	As dependências podem ser instaladas, armazenadas em cache, modeladas ou snapshotadas?	Reduz a repetição de configuração e a deriva
Execução de comandos	Logs, códigos de saída, tempos limite e trabalhos em segundo plano são acessíveis?	Torna as falhas depuráveis
Acesso ao navegador ou pré-visualização	O agente pode inspecionar a saída renderizada ou automatizar um navegador?	Suporta aplicativos web, tarefas de interface do usuário e revisão visual
Política de rede	Que acesso de saída é permitido e como é controlado?	Reduz o risco de buscas de pacotes, navegação na web e chamadas externas
Isolamento	Que fronteira separa as sandboxes umas das outras e do host?	Determina para que tipo de código e dados o runtime é adequado
Modelos e snapshots	As equipes podem reutilizar ambientes conhecidos como bons?	Melhora a reprodutibilidade
Transferência humana	Um revisor pode ver os mesmos arquivos, logs, capturas de tela ou pré-visualização?	Transforma o runtime em um artefato revisável
Modelo de custo	O faturamento está vinculado ao tempo de sessão, CPU, memória, armazenamento ou concorrência?	Evita custos surpresa quando os agentes são executados em paralelo

Perguntas sensíveis à segurança merecem documentação exata e revisão do produto. Evite tratar qualquer sandbox como proteção mágica. Isolamento, acesso à rede, tratamento de segredos e logs precisam de escolhas de design explícitas.

Onde o Novita Agent Sandbox se encaixa?

O Novita Agent Sandbox foi projetado para fluxos de trabalho de agente que precisam de ambientes de execução isolados e com estado. A visão geral do Agent Sandbox descreve as sandboxes como ambientes onde os agentes podem executar comandos, ler e escrever arquivos, instalar dependências e usar fluxos de trabalho baseados em navegador. Também define modelos para ambientes iniciais preparados e snapshots para salvar o estado configurado da sandbox.

Isso torna o Novita uma opção a ser avaliada quando sua carga de trabalho de agente precisar de:

• execução de código dentro de um ambiente isolado;
• acesso a arquivos em várias etapas;
• instalação de dependências e ambientes preparados reutilizáveis;
• fluxos de trabalho orientados a navegador;
• artefatos gerados que humanos possam inspecionar;
• controles de ciclo de vida por meio de SDK ou CLI;
• uma direção de plataforma que combina APIs de modelo e infraestrutura de sandbox de agente.

Isso não significa que todo agente precise de uma sandbox com estado. Se sua aplicação precisa apenas de execução única de Python em um arquivo enviado pelo usuário, um padrão de interpretador de código pode ser mais simples. Se sua equipe já possui um runtime interno com egresso restrito, tratamento de segredos, auditoria e fluxos de revisão, a questão é se uma sandbox externa melhora a velocidade do desenvolvedor sem enfraquecer esses controles.

Use o Novita Agent Sandbox como parte de uma decisão arquitetural, não como uma substituição genérica para todos os caminhos de execução.

Uma regra prática de decisão

Faça uma pergunta antes de escolher o runtime:

Uma segunda pessoa ou agente poderia retomar, inspecionar ou reproduzir este trabalho a partir do ambiente após o primeiro turno do modelo?

Se a resposta for não e a saída ainda for útil, a execução efêmera provavelmente é suficiente. Se a resposta precisa ser sim, a tarefa está se movendo em direção a uma sandbox com estado ou computador de agente.

Para sistemas de agente em produção, isso geralmente se torna o padrão:

1. Comece de um modelo ou snapshot limpo.
2. Permita que o agente trabalhe dentro de um runtime isolado.
3. Capture arquivos, logs, capturas de tela, pré-visualizações e resultados de comandos.
4. Preserve o ambiente por tempo suficiente para revisão.
5. Redefina, exclua ou faça snapshot com base no resultado.

Esse fluxo de trabalho dá ao modelo espaço para agir enquanto mantém o resultado inspecionável.

Artigos recomendados

• Construindo um Agente de Codificação com o Novita Agent Sandbox
• Hospede o Clawdbot com o Novita Sandbox Template
• Qual Provedor de Inferência é o Certo para Agentes de IA

FAQ

Um interpretador de código é o mesmo que uma sandbox de agente?

Não. Um interpretador de código geralmente se concentra em executar código gerado e retornar saídas dentro de uma sessão gerenciada. Uma sandbox de agente é um ambiente isolado mais amplo para comandos, arquivos, dependências, fluxos de trabalho de navegador, controle de ciclo de vida e artefatos revisáveis.

Todos os agentes de IA precisam de sandboxes com estado?

Não. Transformações simples de dados, cálculos e scripts únicos podem funcionar bem em execução efêmera. Os agentes precisam de sandboxes com estado quando o fluxo de trabalho depende de arquivos persistentes, pacotes instalados, processos de longa duração, acesso a navegador ou pré-visualização, ou revisão humana de artefatos.

O que é um computador de agente?

Um computador de agente é um ambiente de tarefa que dá a um agente de IA ferramentas semelhantes a computador: sistema de arquivos, shell, pacotes, acesso a navegador ou interface do usuário, logs, artefatos, controles de ciclo de vida e opções de redefinição ou snapshot. É um conceito útil para trabalhos de agente de longa duração e revisáveis.

Por que os snapshots são importantes para fluxos de trabalho de agente?

Os snapshots permitem que as equipes salvem um ambiente configurado e o reutilizem posteriormente. Eles reduzem o trabalho repetitivo de configuração, melhoram a reprodutibilidade e fornecem um ponto limpo para retornar antes que o agente execute ações arriscadas ou experimentais.

Como as equipes devem pensar sobre a segurança da sandbox?

Trate a segurança da sandbox como uma decisão arquitetural. Revise o modelo de isolamento, acesso à rede, tratamento de segredos, logs, limpeza do ciclo de vida e processo de revisão humana antes de executar cargas de trabalho sensíveis ou código não confiável.