Harnesses mais leves e agentes que executam código são mais adequados para tarefas em aberto, nas quais uma orquestração demasiado rígida pode limitar o desempenho do modelo.
Assim, a execução de código e o isolamento em sandboxes são agora preocupações arquitetónicas centrais nos sistemas de agentes.
Nos nossos testes, o Agents SDK reduziu até seis vezes a complexidade e a quantidade de código necessárias para criar agentes que executam código.
Durante muito tempo, o progresso nos sistemas de agentes resultou de melhorias na orquestração: prompts mais eficazes, melhores interfaces de ferramentas e gestão de contexto, bem como fluxos de controlo 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 em aberto, o principal obstáculo já não é o ciclo do agente, mas sim a camada de execução: a sandbox onde o modelo escreve código, executa comandos, examina resultados e faz iterações. À medida que mais raciocínio ao nível da tarefa passa para esse ambiente, a orquestração envolvente tem de se tornar mais simples, para que o modelo possa expressar todo o seu potencial.
É precisamente esta mudança que a nova versão do Agents SDK permite. Nos testes que realizámos durante o acesso antecipado, constatámos que, em vez de acrescentar mais uma camada de lógica da framework, esta versão torna a camada de execução mais modular e combinável, permitindo que o resto do sistema permaneça leve.
Na engenharia de harnesses, tornou-se habitual reduzir o harness à sua forma mínima eficaz. Em termos gerais, o harness é o software que envolve o modelo: a camada que gere o contexto, as ferramentas, o fluxo de controlo e os ciclos de feedback, para que o modelo possa trabalhar de forma fiável.
Nos últimos anos, muitas melhorias no desempenho dos agentes resultaram do reforço dessa camada. Melhores ferramentas, memória e recuperação de informação, uma decomposição mais explícita e uma orquestração mais rigorosa tornaram muitas vezes os sistemas mais fiáveis e capazes. Nesse paradigma, progredir significava, em grande medida, incorporar mais lógica da tarefa no software em torno do modelo.
Este padrão começa agora a perder força, pelo menos numa categoria de tarefas em aberto. Um número crescente de projetos e artigos sugere que o desempenho nem sempre melhora quando o harness se torna mais prescritivo. Na programação assistida, nas tarefas de longa duração, na utilização do navegador e nas tarefas de contexto longo, o mesmo padrão repete-se: quando o modelo é suficientemente inteligente, impor demasiada estrutura à tarefa através do software envolvente pode tornar-se uma limitação, em vez de uma vantagem.
O papel do harness está, por isso, a mudar. Em vez de tentar antecipar a tarefa através de uma orquestração rígida, o harness serve cada vez mais para disponibilizar uma superfície de execução limpa: uma sandbox onde o modelo pode examinar o estado, executar código, recuperar de erros e adaptar a sua própria abordagem, sem deixar de respeitar as interfaces e salvaguardas do sistema. Esta mudança aproxima-se da que Andrej Karpathy descreveu em Engenheiro de software 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 continuam a beneficiar de fluxos de trabalho explícitos, heurísticas e mecanismos de proteção determinísticos, sobretudo quando são específicas, de grande volume ou têm um critério de sucesso claro. Como defendemos no artigo anterior sobre Heurísticas para a conceção de sistemas de agentes, uma orquestração sólida continua a ser importante quando um fluxo lógico fiável é possível e desejável.
Nas tarefas em aberto, o foco está a mudar. O desafio consiste menos em conceber camadas de orquestração cada vez mais elaboradas e mais em criar ambientes de execução suficientemente simples, observáveis e modulares para que o modelo trabalhe eficazmente no seu interior.
Quando um agente consegue ler ficheiros, escrever código, executar comandos da shell e iniciar tarefas de longa duração, o desafio de engenharia muda. A dificuldade já não reside apenas na otimização do prompt ou no encaminhamento das ferramentas. O facto de o agente passar a operar num sistema real torna estes agentes muito mais poderosos, mas também mais sensíveis, pois aumenta a superfície de risco e de ataque. Por exemplo, um agente capaz de executar código pode realizar ações prejudiciais se o seu ambiente estiver mal isolado (consulte o Sandbox Bench da AISI).
O isolamento em sandboxes está, assim, a tornar-se uma preocupação crítica nas frameworks de agentes. Nos sistemas anteriores, a execução era muitas vezes tratada como um complemento: uma ferramenta acrescentada ao harness. Contudo, quando a execução passa a manter estado, a ser prolongada ou remota, essa abordagem começa a falhar. Gerir a própria sandbox — o seu ciclo de vida, estado, interfaces e integração com o ciclo do agente — rapidamente se torna, por si só, um problema de conceção de sistemas. Esta é uma das razões pelas quais cada vez mais fornecedores disponibilizam ambientes geridos para execução de código, incluindo a Container API e a ferramenta de shell da OpenAI, Modal, Cloudflare, Daytona e E2B, entre outros.
Esta separação é importante porque a execução de código exige um isolamento mais forte e um controlo mais rigoroso em tempo de execução do que o resto do harness. Na prática, agentes que executam código e estão mal implementados podem introduzir três riscos críticos para o negócio: custos de computação descontrolados, ações destrutivas nos sistemas internos e exposição de informações sensíveis. Com uma contentorização e um isolamento adequados, bem como salvaguardas em tempo de execução, estes riscos podem ser contidos a um nível aceitável para implementações reais.
Uma forma de compreender esta abordagem é imaginar que se dá ao agente o seu próprio espaço de trabalho selado, em vez das chaves de todo o escritório. O agente pode continuar a realizar trabalho útil nesse espaço, mas apenas dentro de limites claramente definidos. É possível limitar os recursos de computação que utiliza, restringir os sistemas e ficheiros a que pode aceder e controlar as informações que lhe são disponibilizadas desde o início.
Isto não elimina totalmente o risco, mas transforma o problema de «um agente à solta na sua infraestrutura» em «um agente a operar num ambiente controlado». Para que esta camada se torne uma componente habitual dos sistemas de agentes, precisa de suporte nativo na própria framework. Deste modo, a sandbox torna-se uma camada de execução modular, com componentes portáteis que os programadores podem adotar rapidamente, trocar entre fornecedores e dimensionar sem terem de reformular constantemente a lógica dos agentes.
Quando um agente executa código, a própria sandbox também 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ária uma forma consistente de criar ambientes, pará-los, suspendê-los e retomá-los, guardar instantâneos do estado, voltar a estabelecer ligação mais tarde e gerir tudo isto entre diferentes fornecedores.
Nada disto é conceptualmente fascinante, mas tem importância prática. É precisamente este tipo de infraestrutura que se torna difícil de gerir quando cada equipa reconstrói de raiz um pipeline de agentes, sobretudo quando não está integrado na framework de agentes…
É aqui que um melhor suporte da framework se torna importante. Tivemos acesso antecipado ao novo OpenAI Agents SDK e utilizámo-lo para criar os nossos próprios agentes isolados em sandboxes. O que mais se destacou foi a mudança de ênfase arquitetónica: o SDK trata a execução como uma camada de primeira ordem, em vez de uma ferramenta periférica. Na prática, isto permite iniciar um agente numa sandbox, criar um instantâneo da sandbox ou retomar a execução com menos código — cerca de seis vezes menos em alguns dos nossos testes — e depois mudar de backend sem reescrever a lógica envolvente do agente.
Esta separação mais clara de responsabilidades permite que o harness permaneça centrado no raciocínio, no contexto e no fluxo de trabalho. A camada de execução pode concentrar-se no isolamento, na portabilidade e no estado em tempo de execução. Esta abstração facilita a criação de agentes de programação mais capazes e mais fáceis de desenvolver, que podem alternar entre execução local e remota, suportar tarefas mais longas e mudar de backend de execução sem obrigar a reformular todo o sistema.
À medida que mais lógica ao nível da tarefa passa do harness para o modelo, parte da complexidade do sistema acompanha-a e desce para a camada de execução. A execução de código e o isolamento em sandboxes são agora preocupações arquitetónicas centrais nos sistemas de agentes, sobretudo em tarefas com muita programação e em aberto. Conceber o pipeline de agentes é agora tão importante como conceber o ambiente no qual o agente pode atuar de forma segura, fiável e prolongada.
É por isso que as 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átil entre backends, com estado persistente em tarefas de longa duração e suficientemente simples para evitar a reconstrução da mesma infraestrutura em cada nova configuração.
A conclusão mais abrangente é que a próxima geração de frameworks de agentes será provavelmente definida menos pela quantidade de lógica de orquestração que acrescenta e mais pela forma como estrutura os ambientes de execução dos quais os agentes dependem cada vez mais.