OpenEnv usa capture proxy para treinar coding agents em múltiplos harnesses com TRL

Um modelo de linguagem ajustado para programação pode atingir 62% de resolução sob o Mini-SWE-Agent e desabar para 33% se executado no Claude Code mantendo exatamente os mesmos pesos. Essa oscilação decorre de um vício metodológico: modelos de código são comumente treinados em scaffolds sintéticos desenhados para simplificar o loop de treinamento por reforço, mas distantes das interfaces operacionais reais que os desenvolvedores utilizam. Quando o modelo precisa manipular ferramentas com esquemas de chamada diferentes, gerenciar saídas de terminal ou processar buffers parciais de contexto, a fragilidade da política comportamental transparece.

A raiz dessa desconexão reside na própria engenharia dos pipelines de Reinforcement Learning (RL). Converter um harness de código complexo como Claude Code, Codex ou OpenCode em um ambiente padrão de aprendizado por reforço costumava exigir a reescrita integral da sua lógica interna. Cada harness gerencia seu próprio ciclo de parsing, invoca ferramentas locais e administra o histórico da conversa de maneira proprietária. Forçar esses agentes em APIs monolíticas criava abstrações artificiais e impedia que a política aprendesse a interagir com os padrões de rede e erros reais de execução.

A iniciativa de padronização liderada pela Hugging Face (abre em nova aba) e Meta PyTorch, sob a governança de um comitê conjunto formado por organizações como Prime Intellect, Modal, Unsloth, vLLM e Microsoft, atacou o gargalo estrutural por meio do OpenEnv. Sob licença BSD-3-Clause no repositório huggingface/OpenEnv, o projeto funciona como uma camada de interoperabilidade que transforma contêineres de tarefas em ambientes de RL padronizados. Em vez de exigir que desenvolvedores modifiquem o código-fonte de ferramentas de agente para integrá-las aos algoritmos de pós-treinamento, o ecossistema recorre a um proxy de captura transparente.

A mecânica do capture proxy e a preservação exata de tokens

Poder-se-ia supor que um wrapper em nível de linguagem seria suficiente para interceptar as ferramentas e calcular as recompensas do agente. Essa hipótese falha na prática porque reescrever os agentes para injetar ganchos de telemetria desfigura as particularidades de cada harness e consome meses de manutenção para acompanhar atualizações upstream. O proxy resolve.

Colocado entre o harness em execução e o motor de inferência, o proxy de captura do OpenEnv atua na camada de rede. O agente de código é executado sem qualquer modificação em seu código-fonte, configurado apenas para apontar sua variável de ambiente de API para o endpoint exposto pelo proxy. Para a ferramenta, o proxy responde como um provedor de inferência padrão compatível com quatro dialetos fundamentais de agentes: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages e Gemini.

Nos bastidores, o proxy encaminha as requisições para uma instância do vLLM (abre em nova aba), coletando simultaneamente os dados operacionais necessários para a otimização de política. Cada chamada é desmembrada em nível de token. O componente registra os IDs exatos de tokens de prompt e de completion, bem como as log-probabilidades calculadas pelo modelo amostrador durante o rollout.

Esse detalhe operacional elimina a etapa de retokenização. Em pipelines tradicionais de telemetria baseados em strings brutas, o texto retornado pelo harness é frequentemente retokenizado pelo framework de treino antes do cálculo do gradiente. Pequenas divergências no particionamento de espaços em branco, quebras de linha ou caracteres de escape geram discrepâncias que desalinham o tensor de log-probabilidades em relação à política original. Com a captura direta na camada de inferência, os tensores fornecidos ao otimizador representam fielmente os estados visitados pelo modelo.

A integridade do tráfego concorrente apoia-se em um esquema de isolamento via chave de API:

[ Agente no Sandbox ] --(Dialeto HTTP / API Key = Session ID)--> [ OpenEnv Capture Proxy ] 
                                                                         |
                                                                         +--> Registra Token IDs e Logprobs
                                                                         |
                                                                         v
                                                                  [ vLLM Server ]

A chave de API informada pelo harness identifica a sessão de rollout. Um único processo de proxy gerencia centenas de sessões simultâneas sem a necessidade de alocar portas dinâmicas de rede para cada contêiner em execução. Requisições que chegam sem uma sessão registrada ativa no registro interno são imediatamente recusadas, impedindo vazamento de dados entre sandboxes não confiáveis. À medida que o agente dispara chamadas subsequentes dentro do mesmo problema, o proxy conecta os turnos de diálogo em uma estrutura de grafo determinística baseada no casamento de prefixos exatos de tokens.

Essa abordagem técnica para o ecossistema de código aberto foi resumida por Clement Delangue, executivo e cofundador da Hugging Face, ao detalhar as capacidades da camada de transporte do OpenEnv:

Nós transformamos Claude Code, Codex, Hermes, Pi, @opencode e outros harnesses de codificação em ambientes de RL. Nenhuma alteração nos harnesses, nenhuma alteração no código de treinamento. Qualquer modelo aberto, qualquer conjunto de tarefas, totalmente open source, meus amigos! Mesmo modelo, mesmos pesos: 62% sob Mini-SWE-Agent, 33% sob Claude Code. Mas treinar dentro de um harness real normalmente significa reimplementá-lo como um ambiente, então a maioria dos modelos é treinada em um scaffold que ninguém realmente envia para produção. A solução é um proxy, não uma reescrita. O harness pensa que está falando com uma API de modelo. Na verdade, ele está falando com um proxy de captura que fala os 4 formatos que os agentes de codificação usam (OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, Gemini), encaminha para o @vllm_project, registra os IDs exatos de tokens e logprobs que o vLLM amostrou e entrega ao TRL sequências sobre as quais ele pode treinar. O harness se torna o ambiente. 10 harnesses rodam através dele hoje, nenhum modificado. E como você controla a recompensa, você pode moldar comportamentos que o harness nunca pediu.

— clem 🤗 (@ClementDelangue), 5 de out. de 2026, no X

Integração com TRL e a dinâmica do AsyncGRPO

A biblioteca TRL (abre em nova aba) (Transformer Reinforcement Learning) utiliza essas sequências capturadas para executar o AsyncGRPOTrainer (Group Relative Policy Optimization assíncrono). A arquitetura do GRPO dispensa o treinamento de um modelo de valor desacoplado (crítico), comum em abordagens PPO clássicas, estimando a linha de base de recompensa diretamente a partir da média obtida por um grupo de rollouts executados para o mesmo problema.

O isolamento e a escalabilidade dos rollouts decorrem do desacoplamento entre o agente e o nó de processamento de tensores. Cada rollout ocorre em sua própria sessão isolada por meio do Harbor (abre em nova aba), utilizando contêineres Docker em sandboxes remotas da infraestrutura Hugging Face ou provedores como E2B. O contêiner carrega as dependências do harness, os binários de sistema e um espaço de trabalho isolado. O agente opera sobre o sistema de arquivos local, cria arquivos, invoca interpretadores e obtém feedbacks de execução reais.

O ciclo assíncrono de atualização de política opera conforme o fluxo:

1. O orquestrador despacha uma tarefa do banco de problemas para um sandbox isolado, associando-a a um identificador de sessão.
2. O harness executa seu loop nativo de resolução de tarefas, gerando chamadas de inferência interceptadas pelo proxy.
3. Ao finalizar a tarefa ou atingir o orçamento máximo de tokens estipulado, o verificador embutido no sandbox avalia a resolução e emite uma recompensa binária de sucesso ou falha.
4. O OpenEnv agrupa os pares de tokens, logprobs de amostragem e a recompensa consolidada, enviando o pacote para o buffer do AsyncGRPOTrainer.
5. O otimizador calcula a vantagem relativa do grupo e atualiza os pesos da política por meio de gradientes distribuídos.

Como o tempo de resolução varia expressivamente de acordo com o número de ferramentas acionadas pelo agente, a política pode sofrer com desatualização de pesos (staleness). O TRL controla essa divergência por meio de janelas máximas de passos de otimização permitidos entre a geração da trajetória e a aplicação do gradiente. A perda de sincronia controlada permite manter os nós de computação GPU constantemente saturados, desacoplando o throughput de inferência dos atrasos de I/O inerentes aos sandboxes.

from trl import AsyncGRPOConfig, AsyncGRPOTrainer
from openenv.environments.harbor import HarborEnv

# Configuração orientativa do treinamento assíncrono com harnesses de código
training_args = AsyncGRPOConfig(
    output_dir="./output-agent-rl",
    learning_rate=3e-6,
    per_device_train_batch_size=1,
    gradient_accumulation_steps=8,
    max_steps=500,
    max_staleness=4,
    rollouts_per_group=8,
)

# O ambiente Harbor gerencia o sandbox e aponta o agente para o capture proxy
env = HarborEnv(
    harness="opencode",
    task_dataset="FineEnvs/SmolDataEnvs",
    sandbox_backend="e2b"
)

Resultados empíricos e a regularização multi-harness

Treinar um agente para operar com múltiplos scaffolds de execução parece, à primeira vista, uma intervenção ineficiente. A divergência nas convenções de formatação de prompts e ferramentas entre harnesses como Claude Code, Codex, OpenCode e Mini-SWE-Agent deveria, em teoria, fragmentar a distribuição de gradientes e retardar a convergência do modelo.

Os dados experimentais documentados no ambiente FineEnvs (abre em nova aba) revelam o oposto. A alternância de scaffolds operou como um regularizador estrutural de alta eficácia. Ao ser forçada a navegar por padrões distintos de interação, a política deixou de se sobreajustar a idiossincrasias sintáticas de um único terminal ou parser, focando em estratégias semânticas de resolução de problemas e manipulação assertiva de ferramentas.

No benchmark SmolDataEnvs, voltado para tarefas de análise de dados com validação programática, o modelo LFM2.5-2.6B saltou de um índice de acurácia de 42,2% para 54,2% em pass@1 após a etapa de RL multi-harness. A elevação de desempenho ocorreu simultaneamente sob todos os quatro harnesses avaliados: OpenCode, Claude Code, Codex e Mini-SWE-Agent.

O reflexo mais nítido dessa aquisição de competência não foi apenas a taxa de acerto absoluto, mas a concisão operacional. Ao comparar tarefas retidas resolvidas tanto pelo modelo base quanto pelo modelo ajustado por RL multi-harness, o modelo otimizado utilizou 31% menos chamadas de ferramentas (tool calls) no checkpoint final. O agente treinado com o OpenEnv aprendeu a inspecionar arquivos com menor redundância, depurar saídas com comandos mais concisos e formular respostas sem encadear tentativas intermediárias fracassadas. A redução nas interações com o sistema refletiu-se em menores custos de latência e consumo de tokens por problema resolvido.

Para consolidar essas métricas, o ecossistema disponibilizou implementações e checkpoints de modelos no Hugging Face Hub, detalhados a seguir:

No caso do fine-tune completo do Qwen3.5-2B, o processo operou sob um orçamento rigoroso de 16.384 tokens por chamada no treinamento e 4.096 tokens durante a fase de avaliação. Os rollouts foram distribuídos em sandboxes E2B, alternando o harness designado a cada grupo de GRPO sob uma única tarefa. A política foi inicializada diretamente a partir do modelo base, demonstrando que o sinal de reforço derivado de verificação binária basta para moldar o comportamento agêntico quando a amostragem de dados reflete o ambiente final de produção.

Requisitos, arquitetura do Harbor e integração de novos agentes

A viabilidade técnica de rodar o OpenEnv repousa sobre a camada de abstração fornecida pela especificação de ambientes do ecossistema e pelo Harbor (abre em nova aba). Originalmente estruturado em colaborações técnicas via RFC 002 (especificação da interface de ambiente, empacotamento em Docker e isolamento de comunicação) e RFC 003 (encapsulamento de ferramentas via protocolos MCP), o OpenEnv encapsula a superfície de controle dos agentes.

Integrar um novo harness de código não demanda a reescrita do orquestrador de treinamento. Como a interface do Harbor no OpenEnv expõe a descoberta de conjuntos de dados pela Task API e gerencia os ciclos de vida por meio de uma ferramenta MCP run_rollout, o harness precisa apenas ser empacotado em uma imagem de contêiner e configurado para aceitar uma URL base de API padrão e uma chave de autenticação externa.

Os requisitos para a configuração dessa infraestrutura envolvem três pilares:

• Motor de Inferência Central: Uma instância vLLM com largura de banda suficiente para processar requisições concorrentes, capaz de exportar distribuições de probabilidades de tokens (logprobs) e operar em modo multi-turn com contexto estendido.
• Camada de Sandboxing Remoto: Um pool de execução conteinerizado suportado pelo Harbor (sendo homologados 23 backends, incluindo instâncias remotas da Hugging Face e sandboxes E2B), isolando permissões de rede, volumes efêmeros e processos locais.
• Roteamento de Dialetos: Compatibilidade do harness com um dos quatro formatos processados pelo capture proxy, cobrindo endpoints de mensagens da Anthropic, APIs de completions da OpenAI ou chamadas orientadas ao Gemini.

Como um harness é plugado ao ecossistema?

[Definição do Dataset / Tarefas]
             |
             v
[OpenEnv Task API: Descoberta e Verificação]
             |
             v
[Instanciação do Sandbox Docker (Harbor Backend)]
             |
             v
[Injeção de Variáveis: OPENAI_BASE_URL -> Capture Proxy]
             |
             v
[Execução do Loop Nativo do Harness sem Modificações]
             |
             v
[Coleta de Trajetória, Logprobs e Avaliação pelo Verificador]
             |
             v
[Exportação para o TRL AsyncGRPOTrainer]

O isolamento oferecido pelo proxy possibilita rodar matrizes de testes cruzados onde múltiplos modelos avaliam simultaneamente tarefas heterogêneas sem colisão de estado. Caso um harness exija variáveis de ambiente customizadas ou ferramentas de compilação peculiares, tais restrições permanecem estritamente circunscritas à sua respectiva imagem Docker, sem poluir os nós de treino do TRL.

Existe uma restrição operacional clara. Ambientes multi-harness acoplados a sandboxes remotas demandam infraestrutura de rede resiliente e tolerante a latência. A dependência de requisições de rede contínuas para cada token ou ação de ferramenta transforma nós de sandbox distantes geograficamente em gargalos diretos de throughput. Quando conexões falham de forma intermitente, sessões de rollout do proxy podem sofrer timeout, exigindo que o AsyncGRPOTrainer descarte a trajetória inteira para preservar a pureza matemática das amostras de gradiente.

A viabilidade do RL para agentes de código deixa de ser um privilégio de arquiteturas fechadas quando se elimina o abismo entre o scaffold de laboratório e a ferramenta de uso diário. O OpenEnv estabelece que a padronização não precisa ocorrer pela imposição de uma biblioteca de código rígida, mas pelo desacoplamento inteligente dos protocolos de rede que os modelos já utilizam. Ao transferir a complexidade para o proxy de captura e transformar harnesses arbitrários em ambientes observáveis sem alterar seu código interno, a engenharia de pós-treinamento ganha a capacidade de produzir modelos que operam com precisão, agilidade e rigor estrutural em qualquer interface de desenvolvimento.