CodeAct: Por que Código Python Executável Torna Agentes de LLM 20% Mais Precisos

Após ler o artigo sobre "incapacidade de autocorreção" na semana passada, uma pergunta natural surge: se os LLMs não conseguem auditar de forma confiável sua própria saída, qual formato de ação oferece aos agentes a melhor chance de detectar e recuperar erros automaticamente? O CodeAct, publicado por Xingyao Wang et al. e aceito no ICML 2024, argumenta que a resposta é o código Python — não porque o código seja mágico, mas porque um interpretador Python fornece exatamente o tipo de feedback externo e determinístico que a literatura sobre autocorreção mostra que os LLMs precisam desesperadamente.

O artigo

"Executable Code Actions Elicit Better LLM Agents" (arXiv:2402.01030) por Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng e Heng Ji propõe substituir os formatos de ação em JSON e texto, comuns em agentes de chamada de ferramentas, por código Python executável. A ideia central é que o código é uma língua franca melhor para ações de agentes do que instruções em linguagem natural ou JSON estruturado, porque o código já codifica o fluxo de controle, as dependências de dados e a composição em várias etapas — e porque os LLMs foram intensamente pré-treinados nele.

O artigo apresenta três contribuições: (1) um argumento conceitual para o código como um espaço de ação unificado; (2) M3ToolEval, um novo benchmark de 82 tarefas selecionadas por humanos que exigem composição multi-ferramentas; e (3) CodeActAgent, um modelo 7B ajustado treinado no CodeActInstruct, um conjunto de dados de 7.139 trajetórias baseadas em código de vários turnos abrangendo recuperação de informações, pacotes de software, memória externa e planejamento robótico.

Ideias principais

• No M3ToolEval, o GPT-4 com CodeAct atinge uma taxa de sucesso de 74,4% contra 53,7% com ações de texto — uma melhoria absoluta de cerca de 20 pontos percentuais no cenário multi-ferramentas mais exigente.
• O CodeAct requer cerca de 30% menos turnos de interação do que agentes baseados em JSON nas mesmas tarefas. Menos turnos importam: cada ida e volta extra é outra oportunidade para a propagação de erros.
• O interpretador Python atua como um sinal de erro automático e de custo zero. Um cálculo intermediário errado gera uma exceção imediatamente; o agente vê o traceback e pode revisar sem a necessidade de uma etapa de crítica separada.
• Modelos de código aberto se beneficiam mais do que os de código fechado. O CodeActAgent (Mistral 7B) atinge 12,2% no M3ToolEval contra 3,7% do agente de código aberto anteriormente mais forte (Lemur-70B com texto). A alavancagem é maior porque o Python é abundante em dados de pré-treinamento; formatos especializados de chamada de ferramentas JSON não o são.
• O CodeActInstruct treina em quatro domínios escolhidos especificamente para testar a composição sob estresse: busca de informações, chamadas de pacotes, manipulação de memória externa e planejamento robótico. Estas são todas tarefas de várias etapas e dependentes do estado — exatamente os modos de falha onde os agentes JSON quebram.

O que se sustenta — e o que não

A melhoria de 20% no M3ToolEval é real, mas o M3ToolEval tem apenas 82 tarefas. Essa é uma amostra pequena, e o artigo não relata intervalos de confiança. O benchmark também é organizado pela mesma equipe que propõe o método, o que é padrão na área, mas vale ressaltar. Eu gostaria de ver isso replicado em um benchmark totalmente independente antes de tratar 74,4% como um número confiável.

A alegação de eficiência — 30% menos turnos — é plausível, mas mistura duas coisas. Menos turnos podem significar que o agente é mais preciso por etapa, ou pode significar que as falhas terminam mais cedo. O artigo não decompõe isso claramente.

A lacuna reconhecida entre modelos de código aberto e fechado é grande e não é resolvida pelo CodeAct. O CodeActAgent (Mistral 7B) com 12,2% é muito melhor que o Lemur-70B com 3,7%, mas o GPT-4 com CodeAct está em 74,4%. O formato ajuda, mas não fecha uma lacuna de capacidade de 60 pontos. Qualquer pessoa que planeje implementar um agente Beancount de código aberto deve ler esse número com atenção.

A questão do sandboxing recebe apenas um parágrafo. A execução de código arbitrário em um contexto financeiro não é um caso isolado inconveniente — é a principal preocupação de segurança. O artigo não aborda o que acontece quando o agente gera um código que exclui arquivos, faz chamadas de rede ou importa bibliotecas inesperadas. Para um agente de contabilidade em produção, o design do sandbox é pelo menos tão importante quanto o formato da ação.

Por que isso importa para a IA nas finanças

O problema de gravação (write-back) no Beancount é essencialmente o problema para o qual o CodeAct foi projetado: um agente precisa compor várias operações (ler o saldo atual, validar a transação, escrever um novo lançamento, verificar a equação do saldo) em uma ordem específica, com dados fluindo entre as etapas. A chamada de ferramentas JSON lida mal com isso porque cada chamada é isolada. O Python lida com isso naturalmente.

Mais concretamente: um agente Beancount no estilo CodeAct poderia expressar todo um fluxo de trabalho de reconciliação como um único script Python — consultando o livro-razão via uma biblioteca, computando deltas, propondo novas entradas e executando o bean-check no resultado — tudo antes de confirmar qualquer alteração. O interpretador captura os erros óbvios; o LLM só precisa lidar com os erros semânticos. Essa é uma divisão de trabalho melhor do que pedir ao LLM para validar seu próprio JSON.

A preocupação com a segurança vai no sentido contrário. Um agente com execução irrestrita de Python sobre um livro-razão financeiro é uma superfície de ataque significativa. O design correto é quase certamente um sandbox fortemente restrito — sem gravação no sistema de arquivos fora de um diretório temporário designado, sem acesso à rede, sem comandos de shell — combinado com um portão obrigatório de bean-check antes que qualquer arquivo seja tocado. O CodeAct oferece o formato de ação; você ainda precisa construir a "gaiola".

O que ler a seguir

• OpenHands (anteriormente OpenDevin) — o sistema de agente de produção construído sobre o CodeAct pelo mesmo grupo de pesquisa; mostra como o sandboxing e o ambiente de execução são realmente implementados (arXiv:2407.16741)
• ToolBench / ToolLLM — benchmarks e dados de treinamento para agentes de chamada de ferramentas usando APIs REST em vez de Python; um contraste útil para a abordagem focada em código do CodeAct (arXiv:2307.16789)
• SWE-bench — avalia agentes em problemas reais do GitHub, o que exige execução de código em várias etapas e edição de arquivos; o benchmark existente mais próximo do que um agente de gravação Beancount precisaria passar (arXiv:2310.06770)