OpenHands: Plataforma Aberta para Agentes de Software de IA e o que Isso Significa para a Automação Financeira

Continuo encontrando o OpenHands como a camada de estrutura subjacente ao TheAgentCompany, InvestorBench e uma lista crescente de artigos de avaliação — no entanto, ainda não li o artigo principal. Esta é a infraestrutura sobre a qual o resto da área está sendo construída silenciosamente, portanto, entender o que ela realmente oferece, e onde falha, importa mais do que qualquer resultado individual de benchmark construído sobre ela.

O artigo

OpenHands (Wang et al., 2024; ICLR 2025) é uma plataforma de código aberto para construir e avaliar agentes de LLM que atuam como desenvolvedores de software generalistas. Liderado por Xingyao Wang e Graham Neubig em uma equipe de 24 autores, a principal alegação do artigo é que a maioria dos frameworks de agentes existentes é muito limitada para pesquisa (loops de tarefas codificados rigidamente) ou muito limitada para produção (código fechado ou propósito único) para servir como uma base compartilhada para a comunidade de pesquisa. O OpenHands tenta resolver isso fornecendo um runtime padronizado, uma abstração de agente limpa e 15 benchmarks de avaliação integrados sob um único repositório com licença MIT.

O runtime é um ambiente isolado em Docker (sandbox) contendo um shell bash, um servidor Jupyter IPython e um navegador Chromium controlado pelo Playwright. Os agentes interagem por meio de três tipos principais de ação: IPythonRunCellAction para Python, CmdRunAction para comandos de shell e BrowserInteractiveAction para navegação na web. Uma primitiva de coordenação multi-agente, AgentDelegateAction, permite que um agente principal crie sub-agentes especializados. A base padrão é o CodeAct — originalmente publicado como um artigo independente argumentando que o código é o espaço de ação unificado ideal para agentes de LLM — e a plataforma inclui várias implementações de agentes, incluindo um CodeActAgent geral e um BrowsingAgent especializado.

Ideias-chave

• Código como espaço de ação universal: O CodeAct consolida todas as ações do agente (edições de arquivos, chamadas de API, transformações de dados) em Python ou bash, permitindo que o LLM raciocine no mesmo meio em que foi mais intensamente treinado. Isso contorna a fragilidade dos esquemas JSON que assola agentes baseados em chamadas de função (function-calling).
• Runtime Docker em sandbox: Cada agente é executado em um contêiner isolado, para que os agentes possam executar livremente códigos arbitrários sem comprometer a máquina hospedeira — um pré-requisito para qualquer agente financeiro de produção que possa receber credenciais reais.
• 15 benchmarks em um único suporte: SWE-Bench Lite (reparação de código), HumanEvalFix (correção de bugs), WebArena (navegação na web), GPQA (raciocínio de nível de pós-graduação), GAIA (resolução de tarefas gerais) e mais dez. Ter esses benchmarks no mesmo local evita avaliações enviesadas (cherry-picked).
• CodeActAgent + claude-3.5-sonnet atinge 26% no SWE-Bench Lite e 79,3% no HumanEvalFix; o BrowsingAgent atinge 15,5% no WebArena — resultados competitivos zero-shot sem qualquer treinamento específico para a tarefa.
• Desempenho no GAIA: 32,1% com GPTSwarm, bem abaixo do baseline humano de 92% — consistente com todos os outros benchmarks de agentes gerais que mostram uma lacuna de 60–70 pontos entre humanos e agentes.
• Escala da comunidade: 71,4 mil estrelas no GitHub e mais de 188 contribuidores no momento da submissão ao ICLR; o TheAgentCompany adotou o OpenHands como seu suporte de avaliação, conferindo-lhe o status de infraestrutura de benchmark de fato.

O que se sustenta — e o que não se sustenta

O design do runtime em sandbox é uma engenharia sólida. Isolar a execução do agente no Docker é o padrão correto para qualquer sistema que possa vir a ter acesso de escrita em livros-razão financeiros reais, e é genuinamente útil que os benchmarks estejam co-localizados em vez de espalhados por repositórios incompatíveis.

A cobertura dos benchmarks, no entanto, é mais aspiracional do que sistemática. Os 15 benchmarks abrangem tipos de tarefas e níveis de dificuldade vastamente diferentes, sem um framework claro de como os resultados devem ser agregados ou comparados. Relatar 26% no SWE-Bench Lite ao lado de 79,3% no HumanEvalFix no mesmo artigo corre o risco de criar a impressão de que o mesmo agente é simultaneamente medíocre e excelente — as tarefas simplesmente não são comparáveis. Os autores não fornecem uma metodologia fundamentada para agregação de múltiplos benchmarks.

A premissa do CodeAct — de que o código é o formato de ação universal correto — é contestada. Funciona bem para tarefas de desenvolvimento, mas impõe uma camada de mediação Python/bash em cada ação, o que adiciona latência e falha quando a semântica da ação não mapeia de forma limpa para o código (instruções ambíguas do usuário, APIs apenas em linguagem natural). O artigo não faz benchmark contra espaços de ação que não sejam baseados em código para demonstrar que a vantagem é real e não confundida pela base do LLM.

Talvez a lacuna mais importante seja a divisão entre avaliação e implantação. O número de 26% no SWE-Bench vem de um benchmark relativamente limpo e bem especificado. Relatórios da comunidade e tópicos de problemas no GitHub descrevem consistentemente uma confiabilidade muito menor em tarefas complexas ou de longo prazo no mundo real — o mesmo modo de falha documentado pelo TheAgentCompany. O artigo não aborda como medir ou melhorar a robustez sob ruído realista de especificação de tarefas.

Por que isso importa para a IA financeira

O OpenHands é o que há de mais próximo de um substrato de agente compartilhado para a comunidade. Se o Bean Labs construir uma infraestrutura de avaliação para agentes Beancount, a arquitetura do runtime aqui — sandbox Docker, ações Python/bash, backends de LLM plugáveis — vale a pena ser adotada em vez de reconstruída. A primitiva AgentDelegateAction mapeia-se naturalmente para um pipeline de agente financeiro, onde um orquestrador de alto nível delega para sub-agentes especializados: um para leitura do livro-razão, um para sinalização de anomalias e um para propostas de atualização (write-back) que um humano revisa.

Os números do SWE-Bench e do TheAgentCompany, lidos em conjunto, estabelecem uma base sóbria: mesmo os melhores agentes disponíveis concluem cerca de 26–30% de tarefas de software realistas e inequívocas. A automação de livros-razão financeiros é mais difícil — as transações são frequentemente ambíguas, o raio de impacto dos erros é real e a intenção do usuário é frequentemente subespecificada. A conclusão correta não é que os agentes não estão prontos, mas que as primeiras implantações produtivas serão fluxos de trabalho de escrita única estritamente delimitados (sugestões de categorização, sinalização de conciliação) em vez de edições autônomas de livros-razão em múltiplas etapas.

O que ler a seguir

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — combina um modelo barato com um caro e adia para o modelo caro apenas quando a incerteza é alta; aborda diretamente como um agente no estilo OpenHands deve decidir quando encaminhar uma atualização do Beancount para revisão humana.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 sequências de tarefas anotadas por especialistas em 34 cenários financeiros; a metodologia de avaliação que o OpenHands carece para o uso de ferramentas financeiras de longo prazo.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 amostras em 65 ferramentas financeiras MCP reais, diretamente relevante para como um agente Beancount construído no runtime do OpenHands seria avaliado em uma implantação MCP real.