- O Que um Interpretador de Código Realmente Faz
- O Que um Agent Runtime Adiciona
- Principais Dimensões de Decisão
- Onde Interpretadores de Código se Encaixam Melhor
- Onde Agent Runtimes se Encaixam Melhor
- Padrões Híbridos: Usando Ambos em um Único Aplicativo
- Avaliando Infraestrutura de Sandbox para Cada Modelo
- FAQ
- Artigos recomendados
Interpretadores de código lidam com tarefas de execução isoladas e de curta duração — executar um script, retornar um resultado, descartar tudo. Agent runtimes lidam com fluxos de trabalho de várias etapas que exigem estado persistente, acesso a ferramentas, controle de navegador, E/S de arquivos ou sessões de longa duração. A escolha certa depende da sua carga de trabalho, não do rótulo que um produto usa para se descrever.
O Que um Interpretador de Código Realmente Faz
Um interpretador de código dá a um modelo de linguagem uma maneira de executar código e ver a saída. O modelo escreve um script Python, o interpretador o executa em isolamento, e o resultado retorna como texto, um arquivo ou um gráfico renderizado. Quando a sessão termina — ou mesmo entre turnos em algumas implementações — o ambiente é redefinido. Nada é mantido.
Esse design é intencional. Interpretadores de código priorizam segurança e simplicidade em vez de continuidade. O limite de isolamento é restrito porque a única coisa que precisa acontecer é: executar este código, retornar este resultado.
A pegada prática é pequena: um runtime Python (ou similar) em sandbox, um sistema de arquivos com escopo na sessão, acesso de rede suficiente para buscar bibliotecas ou dados externos, se o caso de uso precisar, e um mecanismo para retornar artefatos. A sessão pode durar 30 segundos ou 10 minutos, mas o aplicativo a trata como fundamentalmente efêmera.
Isso se alinha claramente a várias cargas de trabalho de alto valor:
- Execução de script único: um usuário pede ao modelo para calcular algo, e o resultado retorna como um número, tabela ou arquivo.
- Análise de dados: enviar um CSV, gerar um resumo, produzir um gráfico. O trabalho começa e termina em uma interação.
- Computação rápida: matemática, transformações de dados, conversões de formato e tarefas semelhantes cabem em um único bloco de código.
- Ambientes educacionais: onde cada exercício é isolado e não há expectativa de continuidade de sessão.
O que os interpretadores de código não lidam bem é qualquer coisa que exija que o ambiente se lembre de algo, execute uma ação fora da sandbox ou continue trabalhando depois que o usuário parar de observar.
O Que um Agent Runtime Adiciona
Um agent runtime é um ambiente de execução projetado para trabalho que abrange várias etapas, envolve ferramentas externas e pode levar minutos ou horas, em vez de segundos. A sessão não é descartada entre as etapas — é um workspace que o agente usa para progredir em direção a um objetivo.
As adições práticas em relação a um interpretador simples são significativas:
Workspace persistente: arquivos escritos em uma etapa ainda estão lá na próxima. Um agente de codificação pode criar um branch, editar arquivos, executar testes, corrigir falhas e fazer um push de commit — tudo dentro de uma sessão, sem começar do zero.
Pacotes instalados e ferramentas do sistema: um agent runtime normalmente suporta instalação de dependências, execução de comandos shell, chamada a CLIs, inicialização de processos em segundo plano e trabalho com um ambiente de desenvolvimento real, em vez de uma sandbox Python restrita.
Acesso a navegador e web: agentes que precisam ler documentação, interagir com aplicativos web, preencher formulários ou automatizar fluxos de trabalho web precisam de um navegador no ambiente de execução. Um interpretador de código não tem conceito de sessão de navegador persistente.
Armazenamento de arquivos e persistência de artefatos: saídas que precisam sobreviver a uma única execução — código gerado, dados intermediários, arquivos baixados, capturas de tela — precisam de um sistema de arquivos que persista entre etapas e, em alguns casos, entre sessões.
Sessões de longa duração: algumas tarefas de agente levam 20 minutos. Algumas levam mais. Um agent runtime é projetado para permanecer ativo durante a duração de um fluxo de trabalho, não para iniciar e encerrar a cada chamada de função.
Orquestração de múltiplas ferramentas: fluxos de trabalho reais de agentes envolvem chamar várias ferramentas em sequência — uma pesquisa na web, seguida por uma edição de arquivo, seguida por uma execução de teste, seguida por um git push. Um agent runtime é construído para coordenar essa cadeia de forma confiável.
A compensação é real: agent runtimes são mais complexos de operar, custam mais por sessão do que um interpretador leve e expõem uma superfície de ataque maior que requer configuração cuidadosa de políticas. Para cargas de trabalho que se encaixam no modelo de interpretador, adicionar toda essa complexidade é desperdício.
Principais Dimensões de Decisão
A tabela abaixo mapeia os critérios práticos de decisão. A maioria dos aplicativos cai claramente de um lado; padrões híbridos são abordados na próxima seção para casos que abrangem ambos.
| Dimensão | Interpretador de Código | Agent Runtime |
|---|---|---|
| Tempo de vida da sessão | Segundos a minutos, efêmero | Minutos a horas, persistente |
| Estado entre etapas | Descartado ou limitado | Preservado |
| Acesso a ferramentas | Apenas execução de código | CLI, navegador, E/S de arquivos, APIs, subprocessos |
| Instalação de pacotes | Imagem fixa ou restrita | Dinâmico, com controles de política |
| Interação com navegador/web | Não disponível | Suportado |
| Armazenamento de arquivos | Apenas escopo de sessão | Persistente entre etapas |
| Custo por sessão | Baixo | Mais alto |
| Complexidade da infraestrutura | Baixa | Mais alta |
| Pontos de verificação com intervenção humana | Não típico | Comum — aprovar antes de implantar, mesclar ou ação externa |
| Modelo de concorrência | Muitas sessões curtas paralelas | Menos sessões mais longas |
O tempo de vida da sessão e os requisitos de estado são os filtros mais rápidos. Se sua carga de trabalho é redefinida entre turnos, use um interpretador. Se sua carga de trabalho progride em direção a um objetivo em múltiplos turnos, use um runtime.
A amplitude de ferramentas é o segundo filtro. Controle de navegador, operações git, ferramentas CLI e chamadas de API externas exigem um runtime. Se sua única ferramenta é execução de código, um interpretador é suficiente.
Pontos de verificação com intervenção humana quase sempre indicam um runtime. Pausar uma sessão para aguardar aprovação e depois continuar requer estado persistente e uma sessão que possa ser retomada. Interpretadores não são projetados para isso.
Onde Interpretadores de Código se Encaixam Melhor
Interpretadores de código são a escolha certa quando a execução é limitada e autocontida. Os casos de uso mais fortes:
Assistentes de análise de dados: o usuário envia um arquivo, faz uma pergunta, recebe gráficos e resumos. O trabalho termina quando o modelo retorna a saída. Não há próxima etapa que dependa da memória da anterior.
Ferramentas de matemática e computação: calculadoras, conversores de unidades, análise estatística, simulações numéricas. São de passagem única: a entrada vai, a saída vem.
Relatórios automatizados: trabalhos agendados que geram um relatório a partir de uma fonte de dados e o enviam por e-mail ou o salvam. O trabalho é executado, produz um artefato e termina.
Geração de gráficos e visualizações: o modelo escreve código matplotlib ou similar, o interpretador o executa e o usuário recebe uma imagem. Não há necessidade de um ambiente persistente.
Uso de ferramentas LLM em sandbox: quando um modelo precisa de uma ferramenta code_interpreter para raciocinar sobre dados, verificar cálculos ou formatar a saída — e nada mais — um interpretador de código é precisamente o que a API foi projetada para fazer.
O apelo dos interpretadores nesses cenários é prático: eles são mais baratos por sessão, mais fáceis de operar e mais simples de proteger. Não há estado persistente para gerenciar, nenhum ciclo de vida de sessão para rastrear, e a superfície de ataque é estreita porque o código é executado uma vez e o ambiente desaparece.
Onde Agent Runtimes se Encaixam Melhor
Agent runtimes são a escolha certa quando uma tarefa não pode ser concluída sem coordenar múltiplas ferramentas ao longo do tempo, manter estado entre etapas ou executar ações fora da sandbox de execução de código.
Agentes de codificação: um agente que lê uma base de código, escreve alterações, executa a suíte de testes, corrige falhas e abre um pull request precisa de um workspace persistente com git, um terminal e um sistema de arquivos. Isso é arquiteturalmente incompatível com um interpretador efêmero.
Agentes de automação de navegador e web: raspar conteúdo dinâmico, preencher formulários, navegar em fluxos web de várias etapas, extrair dados estruturados de interfaces visuais — tudo isso requer uma sessão de navegador real que persista o tempo suficiente para concluir o fluxo de trabalho.
Pipelines de pesquisa e coleta de dados: agentes que recuperam documentos de várias fontes, cruzam informações, escrevem resultados intermediários em disco e produzem uma saída final sintetizada precisam de um workspace que persista em todas essas etapas.
Cargas de trabalho de avaliação e RL: executar muitos episódios de agente em paralelo, cada um mantendo seu próprio estado, rastreando pontuações e escrevendo checkpoints, requer um runtime projetado para concorrência e isolamento de sessão em escala.
Agentes de infraestrutura de longa duração: agentes que provisionam recursos, executam implantações, monitoram saídas e reagem a mudanças ao longo de uma janela de vários minutos ou horas precisam de um modelo de sessão que possa pausar, retomar e fazer checkpoint.
Ferramentas de codificação agentivas como agentes estilo Codex ou agentes conectados a IDE que executam ações em um projeto real precisam de toda a superfície de um ambiente de desenvolvimento — não de um interpretador em sandbox.
O custo de um runtime é justificado quando a alternativa é conectar manualmente gerenciamento de estado, coordenação de ferramentas e persistência de sessão. O runtime fornece essa infraestrutura; você configura a política.
Padrões Híbridos: Usando Ambos em um Único Aplicativo
Muitos aplicativos reais incorporam ambos os padrões. Um assistente de codificação pode usar um agent runtime para a sessão geral — mantendo o contexto do repositório, rastreando quais arquivos foram alterados, gerenciando um branch — enquanto chama um interpretador de código especificamente para executar testes ou executar scripts fornecidos pelo usuário em sandbox como uma suboperação dentro do fluxo de trabalho maior do agente.
Um produto de análise de dados pode usar um agent runtime para orquestrar todo o fluxo de trabalho — baixar dados, limpar, juntar múltiplas fontes — enquanto usa invocações de interpretador isoladas para as etapas de computação individuais onde o isolamento rigoroso da sandbox é importante e o estado não precisa persistir.
O padrão se parece com isto na prática:
- A camada externa é um agent runtime: ela mantém a sessão, coordena ferramentas e gerencia o estado.
- Operações internas que exigem isolamento rigoroso usam invocações de interpretador de código de curta duração como uma ferramenta entre muitas.
- O agent runtime decide quando invocar o interpretador, quais entradas passar e o que fazer com a saída.
Este não é um padrão arquitetural complexo; é apenas usar cada camada para o que foi projetada. O agent runtime gerencia o fluxo de trabalho; o interpretador lida com a execução em sandbox quando necessário.
Avaliando Infraestrutura de Sandbox para Cada Modelo
Esteja você avaliando um provedor de sandbox gerenciado ou projetando o seu próprio, as perguntas que você precisa responder diferem significativamente com base no modelo para o qual você está construindo.
Para cargas de trabalho de interpretador de código, os critérios de avaliação são relativamente estreitos:
- Qual é a latência de inicialização? Inicialização abaixo de um segundo é importante para uso interativo.
- Quais linguagens e pacotes estão disponíveis na imagem padrão?
- Os usuários podem instalar pacotes adicionais, e isso é permitido pelo seu modelo de segurança?
- Quais são os limites de recursos (CPU, memória, tempo de execução)?
- Como os artefatos da sessão são retornados — resposta síncrona, download de arquivo ou URL pré-assinada?
- Existe uma opção de sistema de arquivos persistente, ou tudo é descartado ao sair?
Para cargas de trabalho de agent runtime, os critérios se expandem consideravelmente:
- O ambiente suporta sistemas de arquivos persistentes que sobrevivem entre etapas em uma sessão?
- A sessão pode ser pausada e retomada — para fluxos de trabalho com intervenção humana ou gerenciamento de custos?
- Há suporte a navegador, e como ele é configurado?
- Quais ferramentas shell e CLIs estão disponíveis?
- Como o acesso à rede é controlado — políticas de egresso, filtragem DNS, listas de permissão de saída?
- Qual é o modelo de concorrência de sessão e como ele escala?
- Como os segredos são injetados e com escopo?
- Que observabilidade existe — logs de comandos, rastreamento de alterações de arquivos, métricas de recursos?
- Como a plataforma lida com sessões de longa duração que excedem ciclos típicos de requisição-resposta?
Novita Agent Sandbox foi projetado para cargas de trabalho de agent runtime — agentes de codificação, automação de navegador, pipelines de análise de dados e cargas de trabalho de avaliação/RL que precisam de estado persistente, acesso a ferramentas e controle de sessão. Ele usa isolamento microVM, suporta Pause/Retomar e se integra à plataforma de API de modelos da Novita, para que equipes que usam a Novita para inferência de LLM possam executar cargas de trabalho em sandbox na mesma plataforma. Para equipes avaliando infraestrutura de sandbox para fluxos de trabalho de agentes, a documentação do Novita Agent Sandbox cobre o modelo de isolamento, a API de ciclo de vida e a configuração de recursos.
Para cargas de trabalho que são genuinamente apenas de interpretador — script único, efêmero, sem estado — um agent runtime completo é uma sobrecarga que você não precisa. Use a ferramenta mais simples.
O teste prático: seu fluxo de trabalho pode ser concluído corretamente se o ambiente de execução for destruído e reconstruído entre cada turno do modelo? Se sim, um interpretador provavelmente é suficiente. Se não — porque estado, acesso a ferramentas ou continuidade de sessão são importantes — você precisa de um runtime.
FAQ
Qual é a principal diferença entre um interpretador de código e um agent runtime?
Um interpretador de código executa código em um ambiente em sandbox e descarta o ambiente quando a sessão termina. Um agent runtime mantém um workspace persistente — com arquivos, ferramentas instaladas, acesso a navegador e estado de sessão — em várias etapas de um fluxo de trabalho. O interpretador responde “execute este código e retorne o resultado”; o runtime responde “trabalhe em direção a este objetivo em quantas etapas forem necessárias”.
Um interpretador de código pode usar ferramentas como pesquisa na web ou acesso a arquivos?
Algumas implementações de interpretador de código suportam uso limitado de ferramentas — upload de arquivos, chamadas de rede dentro da sandbox ou retorno de artefatos. O que elas não suportam é um workspace persistente que carrega estado entre turnos ou uma sessão de navegador que sobrevive a uma única chamada de função. Se seu aplicativo precisa ler uma página web, escrever um arquivo e depois referenciar esse arquivo em uma etapa posterior, você precisa de um runtime.
Um agent runtime é sempre mais caro que um interpretador de código?
Por sessão, sim. Agent runtimes envolvem mais infraestrutura — sistemas de arquivos persistentes, processos de vida mais longa, acesso a navegador ou CLI — e esses componentes custam mais do que uma sandbox de interpretador de curta duração. Para cargas de trabalho que exigem genuinamente coordenação de várias etapas, o custo do runtime é justificado. Para tarefas de passagem única, é sobrecarga.
Quando devo usar ambos no mesmo aplicativo?
Quando o fluxo de trabalho externo requer estado persistente, mas suboperações individuais se beneficiam de isolamento rigoroso. Um agente de codificação que executa a suíte de testes em um interpretador em sandbox, ou um pipeline de dados que delega etapas de computação a interpretadores efêmeros enquanto a camada de orquestração mantém o estado geral, são padrões híbridos comuns.
O Novita Agent Sandbox suporta ambos os modelos?
O Novita Agent Sandbox foi projetado para cargas de trabalho de agent runtime — workspaces persistentes, Pause/Retomar, acesso a navegador e controle de sessão de várias etapas. Para invocações de interpretador isoladas e efêmeras, uma execução mais leve pode ser mais apropriada dependendo do seu caso de uso. Consulte a documentação do Novita Agent Sandbox para obter detalhes atuais de capacidade.
Como saber se minha carga de trabalho precisa de um runtime?
O teste prático: seu fluxo de trabalho pode ser concluído corretamente se o ambiente de execução for destruído e reconstruído entre cada turno do modelo? Se sim, um interpretador é suficiente. Se a resposta for não — porque estado, acesso a ferramentas, controle de navegador ou continuidade de sessão são importantes — você precisa de um runtime.
