Navegação principal

Execução de código intercambiável no OpenAI Agents SDK

O acesso antecipado ao OpenAI Agents SDK mostra como sandboxes intercambiáveis simplificam a execução de código entre provedores remotos.

Resumo executivo

  • Harnesses mais enxutos e agentes que executam código são mais adequados para tarefas abertas, nas quais uma orquestração rígida demais pode limitar o desempenho do modelo.

  • Com isso, a execução de código e o uso de sandboxes passaram a ser questões arquitetônicas centrais para sistemas com agentes de IA.

  • O Agents SDK reduz a complexidade e a quantidade de código necessárias para criar agentes que executam código — em até seis vezes nos nossos testes.

Por muito tempo, o avanço dos sistemas de agentes veio do aprimoramento da orquestração: prompts melhores, interfaces de ferramentas, gestão de contexto e fluxos de controle mais rigorosos. Mas, à medida que os agentes de programação se tornam mais capazes, esse equilíbrio começa a mudar.

Em muitos fluxos de trabalho abertos, o gargalo já não é o loop do agente, mas a camada de execução: a sandbox em que o modelo escreve código, executa comandos, inspeciona resultados e faz ajustes. À medida que mais raciocínio sobre a tarefa é transferido para esse ambiente, a orquestração ao redor precisa ficar mais simples para que o modelo expresse todo o seu potencial.

Essa mudança é exatamente o que a nova versão do Agents SDK possibilita. Nos testes que fizemos durante o acesso antecipado, constatamos que, em vez de acrescentar outra camada de lógica de framework, ela torna a camada de execução mais modular e combinável, permitindo que o restante do sistema continue enxuto.

A mudança

Na engenharia de harness, virou tendência reduzir o harness à sua forma mínima eficaz. Em linhas gerais, o harness é o software ao redor do modelo: a camada que gerencia contexto, ferramentas, fluxo de controle e ciclos de feedback para que o modelo trabalhe de forma confiável.

Nos últimos anos, muitos avanços no desempenho dos agentes vieram do fortalecimento dessa camada. Ferramentas melhores, memória e recuperação aprimoradas, decomposição mais explícita e orquestração mais rigorosa muitas vezes tornaram os sistemas mais confiáveis e capazes. Nesse paradigma, avançar significava, em grande medida, incorporar mais lógica da tarefa ao software ao redor do modelo.

Esse padrão agora perde força, pelo menos para uma categoria de tarefas abertas. Um número crescente de projetos e artigos indica que o desempenho nem sempre melhora quando o harness se torna mais prescritivo. Na programação assistida, em tarefas de longa duração, no uso do navegador e em tarefas com contexto longo, o mesmo padrão aparece repetidamente: quando o modelo já é inteligente o bastante, impor uma estrutura excessiva à tarefa por meio do software ao redor pode se tornar uma limitação, e não uma vantagem.

O papel do harness, portanto, está mudando. Em vez de tentar prever a tarefa por meio de uma orquestração rígida, o harness serve cada vez mais para oferecer uma superfície de execução limpa: uma sandbox em que o modelo possa inspecionar o estado, executar código, se recuperar de erros e adaptar sua abordagem, sempre dentro dos limites das interfaces e proteções do sistema. Isso se aproxima da mudança descrita por Andrej Karpathy em Software Engineer 3.0: parte da lógica que antes residia no software sobe para o "prompt".

A conclusão não é que os sistemas de agentes devam eliminar toda a estrutura. Muitas tarefas ainda se beneficiam de fluxos de trabalho explícitos, heurísticas e proteções determinísticas, especialmente quando são bem delimitadas, têm alto volume ou contam com um critério claro de sucesso. Como defendemos no artigo anterior sobre Heurísticas para projetar sistemas com agentes de IA, uma orquestração robusta continua importante quando um fluxo lógico confiável é possível e desejável.

Nas tarefas abertas, o foco está mudando. O desafio agora é menos projetar camadas de orquestração cada vez mais elaboradas e mais criar ambientes de execução simples, observáveis e modulares o bastante para que o modelo trabalhe neles com eficácia.

Transferindo a complexidade do harness para a camada de execução

Quando um agente consegue ler arquivos, escrever código, executar comandos de shell e iniciar tarefas de longa duração, o desafio de engenharia muda. A parte difícil já não se resume a otimizar prompts ou encaminhar ferramentas. Operar em um sistema real torna esses agentes muito mais poderosos, mas também mais sensíveis, pois amplia a superfície de segurança e proteção. Por exemplo, um agente capaz de executar código pode realizar ações prejudiciais se seu ambiente não estiver devidamente isolado (consulte o Sandbox Bench da AISI).

Por isso, o uso de sandboxes está se tornando uma questão crítica nos frameworks de agentes. Nos sistemas anteriores, a execução costumava ser tratada como um complemento: uma ferramenta anexada ao harness. Mas essa abordagem começa a falhar quando a execução passa a preservar estado, durar muito tempo ou ocorrer remotamente. Gerenciar a própria sandbox — seu ciclo de vida, estado, interfaces e integração com o loop do agente — rapidamente se torna um problema específico de arquitetura de sistemas. Esse é um dos motivos pelos quais cada vez mais provedores oferecem ambientes gerenciados para execução de código, incluindo a API de contêineres e a ferramenta de shell da OpenAI, além de Modal, Cloudflare, Daytona, E2B etc.

Essa separação é importante porque a execução de código exige isolamento mais robusto e controle mais rigoroso do ambiente de execução do que o restante do harness. Na prática, agentes que executam código e são mal implementados podem gerar três riscos críticos para o negócio: gastos descontrolados com computação, ações destrutivas em sistemas internos e exposição de informações confidenciais. Com conteinerização, isolamento e proteções adequadas no ambiente de execução, esses riscos podem ser contidos em um nível aceitável para implantações reais.

Uma forma de entender isso é imaginar que o agente recebe um espaço de trabalho próprio e isolado, em vez das chaves do escritório inteiro. Ele ainda consegue realizar trabalho útil nesse espaço, mas somente dentro de limites claramente definidos. É possível limitar o volume de computação utilizado, restringir os sistemas e arquivos que ele pode acessar e controlar quais informações ficam disponíveis desde o início.

Isso não elimina completamente o risco, mas transforma o problema de "um agente solto na sua infraestrutura" em "um agente operando em um ambiente controlado". Se essa camada vai se tornar parte habitual dos sistemas de agentes, ela precisa de suporte nativo no próprio framework. Com isso, a sandbox se torna uma camada de execução modular, com recursos portáteis que os desenvolvedores podem adotar rapidamente, transferir entre provedores e dimensionar sem refazer constantemente a lógica do agente.

Por que isso exige um suporte melhor dos frameworks de agentes

Quando um agente executa código, a própria sandbox precisa de orquestração. Passar de uma prova de conceito local para execução remota, vários backends ou sessões de longa duração aumenta exponencialmente a carga operacional. É necessário ter uma maneira consistente de criar e encerrar ambientes, pausá-los e retomá-los, gerar snapshots do estado, reconectar depois e gerenciar tudo isso entre provedores.

Nada disso parece muito fascinante em termos conceituais, mas é importante na prática. Esse é exatamente o tipo de infraestrutura que gera problemas quando cada equipe recria do zero um pipeline com agentes de IA, sobretudo quando ele não está integrado ao framework de agentes…

É aqui que um suporte melhor do framework se torna importante. Tivemos acesso antecipado ao novo OpenAI Agents SDK e o usamos para criar nossos próprios agentes em sandboxes. O que mais chamou a atenção foi a mudança de ênfase arquitetônica: o SDK trata a execução como uma camada central, e não como uma ferramenta periférica. Na prática, isso permite iniciar um agente em uma sandbox, gerar um snapshot da sandbox ou retomar a execução com menos código — cerca de seis vezes menos em alguns dos nossos testes — e depois trocar de backend sem reescrever a lógica ao redor do agente.

Essa separação mais clara de responsabilidades permite que o harness continue focado em raciocínio, contexto e fluxo de trabalho. A camada de execução pode se concentrar em isolamento, portabilidade e estado do ambiente de execução. Essa abstração facilita a criação de agentes de programação mais capazes e fáceis de evoluir, que podem alternar entre execução local e remota, realizar tarefas mais longas e trocar de backend de execução sem exigir que todo o sistema seja reprojetado.

Principal conclusão

À medida que mais lógica da tarefa passa do harness para o modelo, parte da complexidade do sistema também se desloca para a camada de execução. A execução de código e o uso de sandboxes agora são questões arquitetônicas centrais para sistemas com agentes de IA, sobretudo em tarefas abertas ou com uso intensivo de programação. Projetar o pipeline com agentes de IA agora é tão importante quanto projetar o ambiente em que o agente possa atuar com segurança, confiabilidade e continuidade.

Por isso, abstrações de alto nível para execução em sandboxes são importantes. O novo OpenAI Agents SDK avança nessa direção ao tratar a execução como uma camada modular do sistema: portável entre backends, com estado persistente durante tarefas longas e simples o bastante para evitar a recriação da mesma infraestrutura a cada nova configuração.

A conclusão mais ampla é que a próxima geração de frameworks de agentes provavelmente será definida menos pela quantidade de lógica de orquestração que acrescenta e mais pela qualidade da estruturação dos ambientes de execução dos quais os agentes dependem cada vez mais.

Autor

Romain Bourboulou