Os primeiros agentes de codificação revelaram algo surpreendentemente poderoso: dar a um agente acesso ao Bash, e pode fazer quase tudo – desde escrever código e recolher contexto até gerir fluxos de trabalho Git completos.
Esta perceção ajudou a alimentar um movimento mais amplo em direção ao software CLI-first. As interfaces de linha de comandos começaram a parecer a forma padrão de tornar aplicações complexas acessíveis aos agentes de IA, dando origem a um slogan familiar:
CLI é tudo o que precisa.
Mas há um custo escondido. Os agentes utilizam frequentemente um terminal da mesma forma que um ser humano faria: executar um comando curto, inspecionar o resultado e decidir o que fazer a seguir. À medida que as tarefas se tornam mais complexas, isto cria mais idas e vindas entre o modelo e as suas ferramentas, o que significa mais chamadas LLM, mais desperdício de contexto e mais tempo gasto em espera.
Em vez de pedir aos agentes que montassem scripts de shell complicados, preferíamos que coordenassem as tarefas numa linguagem de programação que já compreendessem. Isto leva a uma arquitetura ligeiramente diferente:
Mantenha a CLI como ponto de entrada universal, mas utilize o código como a forma real de interagir com o software.
O agente envia um bloco de código que contém as operações, decisões e processamento de dados que, de outra forma, estariam espalhados por várias rondas de interação. O tempo de execução local executa o fluxo de trabalho.
ego-browser foi construído em torno desta ideia. A sua CLI lança um ambiente programável, o navegador expõe as suas capacidades através de um pequeno conjunto de funções, e o agente utiliza as suas competências de programação existentes para compor essas funções e orquestrá-los.
Neste artigo, comparamos heredoc e REPL, duas formas de executar código através de uma CLI e partilhar os resultados experimentais de ego-browser. Com o heredoc, o agente concluiu as mesmas tarefas em menos 44% de rondas de execução, com menos 35,5% de chamadas de ferramentas, a um custo 21,6% inferior.
“CLI é tudo o que precisa” - e então?
A afirmação de que “CLI é tudo o que precisa” pressupõe que o modelo já sabe como utilizar essa CLI.
Para ferramentas conhecidas como Git, Docker e FFmpeg, isto não costuma ser um problema. Os modelos viram inúmeros comandos, tutoriais, scripts e mensagens de erro durante o treino e já conhecem os argumentos e como os comandos se encaixam.
Mas quando construímos uma CLI totalmente nova para os agentes, o cenário muda de figura. Cada CLI tem os seus próprios subcomandos, argumentos, formatos de saída e semântica de erro. Para o modelo, é essencialmente uma nova mini-linguagem. Mesmo com a documentação completa, o modelo ainda tem de aprender primeiro as regras e depois descobrir, através de chamadas repetidas, como os comandos se encaixam.
Exponha as mesmas características de uma API JavaScript ou de uma API em qualquer outra linguagem, e o modelo ainda terá de aprender os novos conceitos de domínio, mas já não terá de reaprender o fluxo de controlo, as estruturas de dados ou a composição. Os loops, condições, tratamento de exceções e processamento de dados permanecem numa linguagem de programação que ele já conhece.
Faça uma tarefa simples: abra uma página web e leia o seu título principal. Se ego-browser tiver exposto uma interface de estilo de comando tradicional, o agente poderá necessitar de vários passos para a completar:
# First call: open the page
ego-browser open https://example.com
# Tool response: the page is open
# Second call: locate the main heading
ego-browser find --role heading
# Tool response: a heading was found
# Third call: read the heading
ego-browser read --role headingApós cada etapa, o agente aguarda a ferramenta, lê o resultado e decide o que fazer a seguir.
A interface de código que ego-browser utiliza realmente permite expressar todo o fluxo de trabalho de uma só vez:
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);Ambas as abordagens realizam a mesma coisa. A interface de estilo de comando divide o processo em múltiplas rondas de interação modelo-ferramenta; a interface de código permite que o agente escreva o processo completo uma vez e o entregue ao tempo de execução local.
Esta é exatamente a ideia de design mencionada anteriormente: manter a CLI como ponto de entrada universal, mas usar o código como interface real para o software. Mantém a vantagem da CLI de ser fácil de chamar e integrar, ao mesmo tempo que permite que o modelo utilize as competências de programação que já possui para composição e orquestração.
Quando a CLI se torna uma porta de entrada para o código
Depois de uma CLI aceitar o código, a questão seguinte é como deve o agente entregar esse código ao ambiente de execução?
Em rigor, heredoc é a sintaxe de entrada da shell e REPL é o modo de execução de um interpretador; os dois não estão na mesma camada de abstração. O que este artigo realmente compara é a execução de código único inserida através de um heredoc em ego-browser, versus uma sessão interativa persistente construída num REPL. Por questões de brevidade, iremos chamar-lhes apenas heredoc e REPL daqui em diante.
Uma opção é o heredoc. Em ego-browser, o agente envia um bloco inteiro de JavaScript de uma só vez:
ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOFO shell passa o código para ego-browser, espera que este termine, recebe o resultado e sai. Para o agente, isto comporta-se como uma chamada de ferramenta convencional:
Submit command → wait for process → receive resultUm REPL funciona de forma diferente. O interpretador permanece ativo, permitindo que o agente insira o código repetidamente enquanto retém as variáveis e o estado da sessão:
> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}
> await page.getByRole("heading").textContent()
< "Example Domain"Em termos de poder expressivo, os dois são essencialmente equivalentes. Um REPL pode executar um programa completo com loops, condições e tratamento de exceções de uma só vez, e um heredoc só pode enviar uma única linha.
A diferença clara é o ciclo de vida do processo. Com um heredoc, o processo é terminado assim que a execução do código termina; um REPL mantém o processo do interpretador ativo, aguardando novas entradas. Isto também significa que os dois impõem exigências diferentes às ferramentas dos agentes. Um heredoc é executado diretamente no modelo familiar de pedido-resposta:
submit the command → wait for the process to exit → get the resultO REPL exige mais da ferramenta: processos persistentes, gestão de sessões, entrada contínua, interrupção e recuperação. A maioria das ferramentas Bash integradas dos agentes não possui estas características. Entre os produtos convencionais de hoje, apenas o Codex os suporta razoavelmente bem. E o suporte da ferramenta é apenas uma condição necessária para utilizar um REPL. Não decide como o modelo realmente usará um. Mesmo quando ambos os ambientes podem executar o mesmo código, o modelo pode ainda escrever código de forma diferente em cada um.
Como os modelos escrevem código em cada ambiente
Em teoria, um modelo tem a mesma capacidade de programação em ambos os ambientes. Na prática, observamos uma diferença comportamental consistente:
- Num REPL, o modelo tende a inserir o código de forma incremental.
- Num heredoc, é mais provável gerar um programa completo de uma só vez.
O software para humanos deve ter em conta a ergonomia. O software para agentes necessita de uma disciplina semelhante: chame-lhe engenharia de experiência de modelos. Uma interface deve funcionar com os modelos de padrões comportamentais desenvolvidos durante a formação.
O contraste entre o REPL e o Heredoc reflete a distribuição dos seus dados de treino.
Os exemplos de REPL provêm normalmente de tutoriais, sessões de depuração e trocas de perguntas e respostas. O seu padrão típico é exploratório:
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the textOs blocos de código Heredoc parecem mais com scripts ou ficheiros de origem. Têm limites iniciais e finais explícitos, o que incentiva o modelo a produzir um fluxo de trabalho contínuo:
const page = await openPage();
const element = await findElement(page);
const text = await readText(element);
console.log(text);Isto não significa que um REPL seja incapaz de executar programas completos. O modelo poderia enviar o mesmo bloco de código para um REPL num único passo.
A distinção é contextual. Um REPL incentiva um executar, observar, continuar padrão. Um heredoc encoraja uma organize primeiro e depois execute padrão.
Esta tendência também determina onde reside o fluxo de controlo. Num REPL, é mais provável que o modelo divida a tarefa em várias fases e decida o que fazer após cada resultado. Num heredoc, é mais provável colocar loops, condições, filtragem e processamento de dados diretamente no programa e deixar o tempo de execução local lidar com eles.
O que as experiências mostraram
Entre as principais ferramentas de agentes que poderíamos integrar de forma fiável, o Codex forneceu as capacidades de execução que um REPL persistente requer. Assim, criámos um benchmark automatizado no Codex SDK: o mesmo agente concluiu quatro tipos de tarefas reais do navegador através do REPL e do heredoc, e agregámos os resultados em execuções repetidas para comparação.
As tarefas eram:
- Análise de pós-tendência X: Recolha as publicações originais de OpenAI dos últimos sete dias, apague as publicações fixadas, as republicações e as respostas, classifique as cinco primeiras por visualizações e calcule as suas taxas de engagement e a média geral.
- OpenAI formulário de emprego: Encontre a posição correta de infraestrutura de nuvem em São Francisco, carregue um currículo, preencha o formulário de candidatura e pare antes do envio final.
- Redfin cálculo da hipoteca: Filtre as propriedades em Austin por tipo de casa e preço, abra o primeiro resultado após a classificação, altere o pagamento inicial para 20% e recupere o pagamento mensal estimado atualizado.
- Expedia pesquisa de voos: Encontre um voo de ida sem escalas de JFK para MIA, selecione a opção mais barata de uma companhia aérea específica, introduza as informações do passageiro e pare antes do pagamento.
Estas tarefas abrangiam mais do que abrir páginas e ler textos. Incluíam extração estruturada, filtragem condicional, navegação entre páginas, carregamentos de ficheiros, preenchimento de formulários, alterações no estado da página e cálculos, cobrindo a maioria das operações comuns realizadas pelos agentes do navegador.
Ambas as abordagens completaram a maioria das tarefas. O Heredoc obteve uma taxa de sucesso de 77,5%, em comparação com os 75,0% do REPL. A diferença na fiabilidade foi modesta.
A maior diferença foi a eficiência:
- O tempo médio de conclusão desceu 35.0%.
- O tempo médio de conclusão desceu 30.7%.
- As chamadas de ferramentas caíram 35.5%.
- O consumo de tokens caiu 29.8%.
- O custo médio desceu 21.6%.
Embora um REPL possa reutilizar o estado de tempo de execução, esta vantagem não produziu menos interações. Na prática, o agente heredoc fez menos chamadas de ferramentas.
Os resultados corresponderam às nossas observações anteriores. Uma vez dentro de um REPL, o agente geralmente executava um pequeno trecho de código, examinava o resultado e depois decidia o que fazer a seguir. Os loops, filtros e decisões que poderiam ter sido tratados dentro de um único programa foram distribuídos por várias trocas modelo-ferramenta.
Os dois ambientes oferecem um poder expressivo semelhante. A sua diferença de eficiência vem principalmente da forma como os seus padrões de interação moldam o comportamento do agente. Pelo menos para estas quatro tarefas do agente do navegador, o heredoc encorajou de forma mais consistente o modelo a organizar um programa completo, empurrar loops, filtragem e decisões no código, e evitar as viagens extra de ida e volta da tomada de decisões passo a passo.
Também examinámos se o mesmo padrão se mantinha numa escala maior, comparando ego-browser com um produto de automatização de navegador baseado em REPL semelhante no conjunto de dados Odysseys. Ao contrário da experiência controlada acima, esta comparação envolveu dois produtos completos, em vez do mesmo modelo a operar através de duas interfaces. É, portanto, útil como uma comparação global de eficiência, mas as suas diferenças não podem ser atribuídas inteiramente ao Heredoc versus REPL.
Esta não é uma vitória permanente para Heredoc
Não acreditamos que o Heredoc seja inerentemente superior ao REPL.
A nossa conclusão depende das capacidades dos modelos, da distribuição dos seus dados de treino e do design das ferramentas dos agentes tal como existem em 2026.
Os agentes de hoje são geralmente melhores na produção de um bloco completo de código numa única passagem. As suas ferramentas shell também são concebidas em torno de um ciclo de vida simples: enviar um comando, aguardar pela sua saída e devolver o resultado. Nestas condições, o heredoc facilita a redução das rondas de interação e a movimentação do fluxo de controlo para o código executado localmente.
Estas condições podem mudar rapidamente.
As futuras ferramentas de agentes poderão fornecer sessões persistentes fiáveis, resultados estruturados e recuperação robusta de estados. Os agentes podem já não ter de lidar com prompts REPL, estado de processo e sessões interrompidas. O treino direcionado também poderia ensinar os modelos a enviar programas completos de forma proativa dentro de um REPL, em vez de cair numa interação passo a passo desnecessária.
Se isto acontecer, os REPL poderão preservar os benefícios da reutilização do estado e do feedback imediato sem exigir mais chamadas de modelo. Podem até tornar-se a melhor escolha para tarefas com arranque dispendioso, estado de longa duração ou fluxo de trabalho genuinamente exploratório.
É por isso que o título especifica 2026. Não estamos a afirmar ter descoberto uma lei permanente. Este é um juízo de engenharia pontual baseado nos modelos e ferramentas de agentes atualmente disponíveis.