Microsoft Abre o Orchard, mas o Treinamento Reutilizável de Agentes Ainda Enfrenta um Problema de Escala

A Microsoft Research abriu o Orchard com três receitas de treinamento de agentes, desafiando a ideia de que todo projeto de agente precisa de sua própria infraestrutura especializada. O framework abrange engenharia de software, interação com navegadores e tarefas de assistente pessoal. Sua promessa central é a reutilização: uma camada de ambientes pode oferecer suporte à coleta de dados, ao treinamento supervisionado, ao aprendizado por reforço e à avaliação.

Isso importa porque a pesquisa aberta sobre agentes enfrenta um problema de infraestrutura. Pesquisadores podem examinar muitas bibliotecas de orquestração, mas reproduzir os sistemas de treinamento por trás de agentes capazes continua sendo difícil. Sandboxes, interfaces de ferramentas, funções de recompensa e trajetórias de longa duração frequentemente ficam fortemente acoplados a uma única tarefa.

O Microsoft Orchard tenta separar essas partes. Em vez de apresentar mais um framework de aplicações, ele se concentra no ambiente em que os agentes agem e aprendem. Essa distinção o aproxima mais de uma plataforma experimental de treinamento do que do Microsoft Agent Framework ou do AutoGen, que ajudam principalmente desenvolvedores a construir e operar aplicações de agentes.

Os resultados reportados são expressivos. No entanto, continuam sendo resultados de pesquisa da equipe do projeto, e não confirmações independentes de desempenho ou acessibilidade. O lançamento também traz uma tensão prática: softwares reutilizáveis podem reduzir a duplicação de engenharia, enquanto o treinamento de agentes em grande escala ainda exige modelos, capacidade computacional, ambientes de tarefas e expertise operacional.

Orchard Transforma o Ambiente do Agente em Infraestrutura Compartilhada

A mudança importante não é mais uma interface de agente. É uma camada de ambiente reutilizável que acompanha um agente durante todo o seu ciclo de treinamento.

O projeto se concentra no Orchard Env, um serviço nativo de Kubernetes para gerenciar ambientes isolados. Um sandbox é um espaço de trabalho controlado onde um agente pode executar comandos, modificar arquivos, navegar em aplicações e receber observações sem acesso irrestrito ao sistema hospedeiro.

Segundo o framework de modelagem agêntica do projeto, esse serviço expõe operações comuns por meio de uma interface REST. Essas operações incluem criar e excluir sandboxes, executar comandos, ler ou gravar arquivos e aplicar políticas de rede.

O ambiente permanece separado do harness do agente, o software que traduz saídas do modelo em ações de ferramentas. Ele também permanece separado do sistema de inferência e do algoritmo de treinamento. Assim, pesquisadores podem trocar um modelo ou harness sem reconstruir todos os componentes de gerenciamento de ambientes.

Essa separação aborda uma fonte recorrente de atrito. Um agente de programação pode precisar de um snapshot de repositório, ferramentas de compilação e testes ocultos. Um agente de navegador precisa de uma interface visual e do estado de um site. Um assistente pessoal precisa de APIs de ferramentas e verificação específica para cada tarefa.

Esses cenários parecem diferentes na camada de aplicação. Por baixo, cada um exige um ambiente isolado, um gerenciador de ciclo de vida, um canal de observação e um método para pontuar resultados. O framework tenta tornar esses requisitos compartilhados explícitos.

A Microsoft afirma que o serviço teve uma média de 0,28 segundos para execução de comandos em seus testes. O artigo que acompanha o lançamento também relata um teste de estresse envolvendo 1.000 sandboxes com taxa de sucesso de 100%. Essas medições descrevem a configuração dos pesquisadores e não devem ser tratadas como garantias universais de produção.

A arquitetura usa injeção de agente em tempo de execução, permitindo que imagens de contêiner específicas de tarefas permaneçam separadas do serviço de controle. Ela também direciona operações de execução e arquivos diretamente aos endereços dos pods de sandbox. O artigo argumenta que isso evita parte da sobrecarga associada aos canais de execução do Kubernetes.

Outros detalhes operacionais revelam quanta infraestrutura o treinamento de agentes exige. O sistema inclui criação assíncrona de sandboxes, monitoramento de prontidão, limpeza baseada em heartbeat, isolamento de rede, tentativas de repetição e escalonamento de recursos. Esses não são recursos glamorosos, mas falhas em qualquer um deles podem invalidar ou interromper uma execução de treinamento.

Essa amplitude explica o valor do projeto para pesquisa. Equipes que estudam diferentes tarefas de agentes podem reutilizar a mesma camada de controle, preservando seus próprios modelos, ferramentas e sistemas de recompensa. Em princípio, os experimentos se tornam mais fáceis de comparar porque menos variáveis de infraestrutura mudam entre eles.

O framework não elimina o desenho especializado de tarefas. Pesquisadores ainda precisam criar ambientes válidos, definir ações permitidas, proteger os sandboxes e desenvolver avaliadores significativos. Ele reduz a engenharia repetida em torno dessas decisões, em vez de fazer as decisões desaparecerem.

A Pressão Real Recai Sobre Stacks de Treinamento Específicos para Cada Tarefa

O Orchard questiona a premissa de que agentes de programação, navegador e assistente exigem sistemas de treinamento completos e separados.

A maioria dos frameworks públicos de agentes concentra-se na orquestração. Eles ajudam modelos a chamar ferramentas, trocar mensagens, seguir fluxos de trabalho ou coordenar múltiplos agentes. Essas capacidades são importantes para aplicações, mas não produzem automaticamente os dados e o feedback necessários para aprimorar um modelo.

O treinamento adiciona outra camada. Um agente precisa tentar tarefas em um ambiente controlado, gerar trajetórias de múltiplas etapas, receber recompensas confiáveis e converter essas interações em atualizações do modelo. Cada estágio pode depender de softwares e infraestrutura diferentes.

Uma trajetória é a sequência completa de raciocínio, ações, respostas de ferramentas e estados do ambiente gerada durante uma tarefa. Esses registros podem se tornar exemplos de treinamento, mas apenas quando o sistema preserva sua estrutura e determina quais comportamentos ajudaram.

Esse desafio se torna mais acentuado em tarefas de longo horizonte. Um agente de programação pode inspecionar vários arquivos, tentar um patch, executar testes, revisar sua abordagem e ainda falhar no final. Um simples rótulo de sucesso ou fracasso não explica quais decisões intermediárias foram úteis.

A resposta do projeto é reutilizar tanto ambientes quanto trajetórias entre as etapas do pipeline. O mesmo serviço de ambientes oferece suporte à coleta de dados com modelos professores, ao ajuste fino supervisionado, aos rollouts de aprendizado por reforço e à avaliação final. Pesquisadores não precisam de sistemas de sandbox separados para cada etapa.

Esse desenho contrasta com a orquestração voltada à produção. O framework de aplicações de agentes separado da Microsoft tem como alvo a construção e a implantação de agentes em Python e .NET. O AutoGen também estabeleceu padrões comuns para conversas entre múltiplos agentes e uso de ferramentas.

A nova stack de pesquisa aborda uma pergunta diferente: como as equipes podem treinar a política subjacente que decide o que um agente deve fazer em seguida? Essa diferença impede uma comparação direta de produtos. Um framework de aplicações e um ambiente de treinamento podem se complementar.

A pressão recai, em vez disso, sobre pipelines de pesquisa fechados e verticalmente integrados. Se a mesma camada aberta de ambientes funciona em vários domínios, as equipes têm menos motivos para aceitar um pacote inseparável de modelo, harness, sandbox e avaliador.

Em teoria, grupos de pesquisa menores se beneficiam mais. Eles podem começar com primitivas compartilhadas de ambiente e receitas publicadas, em vez de desenvolver um serviço inteiro de sandbox distribuído. Também podem testar modelos menores em tarefas antes associadas a sistemas muito maiores.

Ainda assim, “menores” é relativo. Executar sandboxes de Kubernetes, servidores de inferência, modelos professores e trabalhos de aprendizado por reforço continua exigindo profundidade técnica. O lançamento reduz uma categoria de complexidade sem transformar o treinamento de agentes em um fluxo de trabalho comum de notebook.

As organizações também precisam de gestão disciplinada do conhecimento em torno desses experimentos. Trajetórias, falhas de avaliação, mudanças de configuração e definições de tarefas rapidamente se tornam difíceis de pesquisar. Uma base de conhecimento técnica pode preservar o raciocínio por trás dos resultados, e não apenas a pontuação final de benchmark.

A mudança estratégica, portanto, diz respeito à modularidade. Pesquisadores podem manter seu modelo e interface de agente preferidos enquanto substituem um backend de ambiente personalizado. Se esse padrão ganhar adoção, a reutilização de infraestrutura poderá se tornar uma expectativa básica para a pesquisa aberta sobre agentes.

Microsoft Orchard Aprende com Partes Úteis do Fracasso

A ideia mais forte do framework é que uma execução malsucedida de um agente ainda pode conter evidências valiosas para treinamento.

A receita de engenharia de software, chamada Orchard-SWE, começa com aproximadamente 107.000 trajetórias destiladas de MiniMax-M2.5 e Qwen3.5-397B. A Microsoft informa que o corpus abrange 2.788 repositórios do GitHub.

O conjunto de dados de trajetórias do projeto descreve 107.185 registros de engenharia de software. Ele lista 74.649 trajetórias resolvidas e 32.536 trajetórias não resolvidas. Um registro resolvido significa que o patch final passou pela suíte de testes ocultos da tarefa.

O ajuste fino supervisionado tradicional favorece exemplos bem-sucedidos. Isso faz sentido intuitivamente, porque o modelo aprende a reproduzir comportamentos que chegaram ao resultado correto. No entanto, descartar toda trajetória que falhou pode desperdiçar trabalho intermediário útil.

Uma execução de programação malsucedida pode localizar corretamente o módulo relevante, identificar uma condição defeituosa e escrever a maior parte de um patch válido. Uma edição posterior pode comprometer a solução. Tratar a trajetória inteira como sem valor perde o progresso anterior.

A receita introduz o ajuste fino supervisionado por atribuição de crédito para recuperar esse sinal. Atribuição de crédito significa identificar quais ações contribuíram para o progresso, em vez de atribuir um único resultado a todas as etapas.

Para execuções não resolvidas, um modelo professor analisa a trajetória completa junto ao resultado final dos testes. Ele estima como a probabilidade de resolver a tarefa mudou após cada etapa. Em seguida, o pipeline seleciona segmentos contíguos em que essa probabilidade estimada aumentou.

Esses segmentos ascendentes se tornam alvos supervisionados. Observações anteriores permanecem disponíveis como contexto, enquanto a perda de treinamento se concentra em raciocínios e ações gerados pelo assistente e considerados representativos de progresso. Respostas de ferramentas são excluídas da perda de previsão.

Essa técnica não transforma fracasso em sucesso. Ela faz uma afirmação mais restrita: algumas partes de uma tentativa malsucedida podem ensinar a um modelo como é uma exploração produtiva. A confiabilidade dessa lição depende das estimativas retrospectivas do modelo professor.

A receita então adiciona aprendizado por reforço, no qual o modelo gera novas tentativas e recebe recompensas no nível da tarefa. A parte difícil é obter grupos informativos de tentativas sem gastar a maior parte do orçamento em resultados uniformes.

Se todas as tentativas forem bem-sucedidas, o grupo fornece pouca informação sobre quais escolhas de política foram melhores. O mesmo problema ocorre quando todas as tentativas falham. A amostragem padrão de tamanho fixo pode gastar muita capacidade computacional gerando esses grupos de baixa variância.

A Microsoft chama sua alternativa de Balanced Adaptive Rollout. O método gera tentativas progressivamente e procura montar um grupo de treinamento que contenha um equilíbrio útil entre recompensas positivas e negativas. Ele pode parar após encontrar um grupo informativo ou continuar dentro de um orçamento máximo fixo.

A abordagem prioriza eficiência, não apenas precisão. Ela aloca mais amostragem a prompts que exigem tentativas adicionais para produzir uma comparação significativa. Grupos que continuarem inadequados podem ser filtrados e reabastecidos com outras tarefas.

O projeto relata que um modelo inicializado a partir do Qwen3-30B-A3B-Thinking alcançou 64,3% no SWE-bench Verified após ajuste fino supervisionado. Após aprendizado por reforço, chegou a 67,5%.

SWE-bench Verified testa se agentes conseguem resolver problemas reais do GitHub em ambientes de repositório reproduzíveis. As pontuações dependem da versão do benchmark, do harness, das configurações de inferência e dos procedimentos de avaliação; portanto, comparações exigem alinhamento metodológico rigoroso.

A Microsoft descreve seu resultado como um novo ponto alto entre modelos abertos de porte comparável. Essa ressalva é importante. O resultado não estabelece superioridade sobre todos os sistemas de agentes, especialmente modelos fechados que usam diferentes orçamentos computacionais ou scaffolding não divulgado.

Ainda assim, o mecanismo é mais interessante do que a posição no ranking. Treinar a partir de progresso parcial e amostrar em busca de variação informativa na recompensa são técnicas que outras equipes podem testar de forma independente. Seu valor não depende inteiramente de uma única pontuação reportada.

Um Ambiente Dá Suporte a Três Agentes Muito Diferentes

As três receitas testam se a reutilização da infraestrutura resiste a mudanças no tamanho do modelo, na interface, na estrutura das tarefas e no desenho das recompensas.

A programação é a maior demonstração, mas não é a única. O Orchard-GUI aplica a mesma abstração de ambiente a um modelo visão-linguagem de 4 bilhões de parâmetros que interage com interfaces de navegador.

A receita usa, segundo relatos, cerca de 400 trajetórias destiladas e 2.200 tarefas abertas. A Microsoft afirma que o modelo resultante alcançou uma taxa de sucesso de 74,1% no WebVoyager, 67,0% no Online-Mind2Web e 64,0% no DeepShop.

Esses benchmarks abrangem diferentes formas de interação na web. Um agente de navegador precisa interpretar o estado visual, escolher ações e se adaptar quando um site responde. Ao contrário de uma tarefa de programação, o sucesso pode depender de navegar por interfaces dinâmicas em vez de produzir um patch testável.

O volume de dados reportado chama atenção por ser muito menor do que o corpus de engenharia de software. Ele reforça o argumento da Microsoft de que uma receita focada e um ambiente estável podem ajudar um modelo menor a competir sem igualar os maiores sistemas proprietários em número de parâmetros.

No entanto, o sucesso em benchmarks não garante uma navegação confiável fora da distribuição de testes. Sites mudam, interfaces apresentam estados ambíguos e pequenas diferenças visuais podem desviar um agente. Os avaliadores também precisam de uma definição precisa de conclusão de tarefa.

A terceira receita, Orchard-Claw, é voltada a agentes de assistente pessoal. Segundo o artigo, ela usa uma base Qwen3-30B-A3B-Thinking e aproximadamente 200 tarefas sintéticas.

A Microsoft reporta 59,6% de pass@3 no Claw-Eval. Pass@3 dá ao agente até três tentativas e considera a tarefa bem-sucedida quando pelo menos uma delas passa. O resultado sobe para 73,9% quando o modelo opera com o harness ZeroClaw mais robusto.

Essa diferença ilustra uma lição essencial sobre benchmarks de agentes. O modelo é apenas uma parte de um sistema de agentes. O desenho do harness, a formatação das ferramentas, o comportamento de repetição, a gestão de contexto e as regras de avaliação podem afetar significativamente o resultado final.

Isso também complica as alegações sobre modelos menores. Uma política compacta pode ter bom desempenho quando cercada por infraestrutura eficaz, mas o sistema total ainda pode ser operacionalmente exigente. A contagem de parâmetros, por si só, não mede custo nem complexidade de implantação.

Juntas, as três receitas criam um teste de portabilidade mais crível do que três variantes de um único benchmark de programação. Elas abrangem texto e visão, testes determinísticos e interfaces abertas, além de diferentes escalas de modelo.

A camada comum não torna todos os domínios idênticos. Cada receita ainda tem sua própria coleta de dados, cálculo de recompensas, base de modelo e harness de agente. A reutilização ocorre abaixo dessas escolhas específicas de cada tarefa.

Esse limite faz sentido. Um serviço universal de ambiente deve padronizar primitivas de ciclo de vida e comunicação sem fingir que uma tarefa de navegador e um reparo de repositório têm os mesmos critérios de sucesso.

A questão mais ampla é se equipes externas conseguem reproduzir essa separação. Sistemas internos de pesquisa muitas vezes parecem modulares em diagramas, mas dependem de convenções não documentadas, configurações de nuvem ou etapas de preparação de dados. O uso pela comunidade revelará se as interfaces são realmente portáveis.

A Alegação de Código Aberto Ainda Enfrenta um Teste de Reprodutibilidade

Uma arquitetura publicada e resultados fortes em benchmarks são apenas o começo de uma divulgação de pesquisa aberta.

O artigo fornece amplos detalhes de implementação, descrições de algoritmos e configurações experimentais. Os materiais do projeto da Microsoft também identificam os pesquisadores, modelos, fontes das tarefas e principais resultados de avaliação.

No entanto, a abertura prática tem várias camadas. Pesquisadores precisam de código acessível, instruções de instalação, conjuntos de dados compatíveis, checkpoints de modelo, imagens de ambiente, licenças e detalhes de configuração suficientes para recriar os experimentos.

A página do conjunto de dados exibe atualmente um aviso de que sua disponibilização está suspensa e informa que os dados serão enviados novamente. Ela afirma que o esquema documentado está correto, mas pode não representar a forma final. As equipes devem verificar o status da página antes de projetar um pipeline em torno dela.

Essa pausa não invalida a pesquisa. Mas limita a reprodutibilidade imediata, sobretudo da receita de engenharia de software, cujo valor depende fortemente da coleta de trajetórias.

O licenciamento também exige atenção cuidadosa. A documentação do conjunto de dados alerta que as trajetórias fazem referência a repositórios upstream com suas próprias licenças. Pesquisadores que redistribuírem patches, material de teste ou artefatos derivados precisam examinar esses termos individualmente.

A segurança é outra restrição. O treinamento de agentes executa deliberadamente ações geradas pelo modelo. Mesmo ambientes isolados exigem políticas de rede, limites de recursos, controles de credenciais, varredura de imagens e procedimentos de limpeza.

O artigo descreve mecanismos de isolamento de rede e tratamento de falhas, mas cada implantação controla seu próprio limite de ameaça. Um cluster de pesquisa que lida com repositórios públicos enfrenta riscos diferentes de um ambiente corporativo que contém código privado ou ferramentas internas.

A contaminação de benchmarks continua difícil de excluir de forma conclusiva. Modelos professores podem ter encontrado problemas públicos, patches ou código relacionado durante o pré-treinamento. Testes de avaliação ocultos reduzem alguns riscos, mas não resolvem todas as questões sobre memorização.

O método retrospectivo de atribuição de crédito acrescenta outra incerteza. Um modelo professor estima se etapas intermediárias aumentaram a probabilidade de sucesso. Essas estimativas só são rótulos úteis quando o professor consegue interpretar de modo confiável a trajetória e o resultado do teste.

Uma estimativa equivocada pode recompensar um comportamento plausível, porém irrelevante. Também pode deixar de reconhecer uma etapa cujo valor só fica claro mais tarde. Ablações independentes devem testar quanto do desempenho vem de dados de falhas parciais, em vez de escala do modelo, qualidade do professor ou composição do conjunto de dados.

O Balanced Adaptive Rollout exige escrutínio semelhante. Selecionar grupos com variação útil de recompensa pode melhorar a eficiência do treinamento, mas falhas reais do ambiente podem parecer falhas da política. Timeouts, erros de contêiner ou testes quebrados não devem se tornar recompensas enganosas.

A Microsoft relata lógica de repetição, controles de timeout e filtros para grupos inutilizáveis. Equipes externas precisam determinar se essas salvaguardas permanecem eficazes em diferentes clusters, cargas de trabalho e distribuições de tarefas.

Os números reportados devem, portanto, ser lidos como evidência em apoio a um desenho, não como prova final de generalidade. A reprodução em infraestrutura independente fortaleceria o argumento. Resultados em novos domínios testariam se a abstração de ambiente se estende além das três receitas preparadas.

O resultado mais consequente talvez não seja outro recorde de benchmark. Pode ser um substrato experimental compartilhado que permita a pesquisadores comparar métodos de treinamento sem reconstruir a infraestrutura por baixo de cada experimento.

O Que os Pesquisadores Devem Observar a Seguir

Três sinais determinarão se o Orchard se tornará infraestrutura de pesquisa comum ou permanecerá uma impressionante implementação de referência da Microsoft.

O primeiro sinal é a completude da disponibilização. Pesquisadores devem acompanhar a restauração do acesso ao conjunto de dados, repositórios de código estáveis, instruções de instalação reproduzíveis, artefatos de modelo e definições versionadas de ambiente.

Uma disponibilização completa reforçaria a alegação da Microsoft de que equipes menores podem reutilizar o sistema. Lacunas persistentes a enfraqueceriam, pois as partes mais difíceis do treinamento de agentes frequentemente estão na preparação de dados e na configuração operacional.

O segundo sinal é a reprodução independente. Um teste crível usaria as receitas publicadas em infraestrutura gerenciada separadamente e reportaria tanto os resultados dos benchmarks quanto os requisitos totais de recursos.

Igualar a pontuação exata de destaque não é o único resultado útil. Pesquisadores devem documentar o tempo de configuração, taxas de falha do sandbox, throughput de trajetórias, consumo computacional e sensibilidade às escolhas de harness. Essas medições revelam se a reutilização gera economias significativas.

Experimentos independentes também devem isolar a contribuição do ajuste fino de atribuição de crédito. As comparações podem treinar modelos equivalentes apenas com trajetórias bem-sucedidas, trajetórias completas não resolvidas e segmentos selecionados de progresso.

A mesma abordagem se aplica a rollouts adaptativos. Pesquisadores podem comparar amostragem fixa com amostragem balanceada, mantendo constantes os modelos, as tarefas, as funções de recompensa e os orçamentos. Isso mostraria se o método produz mais sinal de aprendizado por trajetória gerada.

O terceiro sinal é a adoção além dos domínios preparados pela Microsoft. Um novo ambiente forneceria o teste mais forte, em especial um que tivesse ferramentas e estruturas de recompensa diferentes.

Análise de segurança, trabalho com dados, fluxos de trabalho científicos e aplicações de escritório são candidatos plausíveis. Cada um introduz requisitos de ambiente diferentes dos de reparo de repositórios ou navegação em navegador. Uma reutilização bem-sucedida sustentaria a alegação de que a abstração é realmente independente de harness.

As respostas de concorrentes também importam, embora devam permanecer evidência de apoio, e não a história principal. Outros projetos de treinamento de agentes podem adotar interfaces de ambiente compatíveis, publicar backends alternativos ou padronizar formatos de trajetória.

A interoperabilidade criaria mais valor do que a proliferação de frameworks. Pesquisadores poderiam mover conjuntos de dados, políticas e avaliadores entre sistemas sem traduzir todos os formatos de ação e observação.

Enquanto isso, desenvolvedores devem evitar interpretar a disponibilização como um agente de produção pronto para uso. O projeto é uma infraestrutura de pesquisa para criar e avaliar políticas. Sistemas de produção ainda precisam de lógica de aplicação, permissões de usuários, monitoramento, comportamento de fallback e revisão de segurança.

Para compradores corporativos, a questão relevante não é se o framework vence um benchmark. É se uma infraestrutura modular de treinamento reduz a dependência de um único modelo proprietário ou de uma pilha de avaliação controlada por fornecedor.

Para pesquisadores, o próximo passo prático é mais restrito. Examine o artigo de pesquisa, verifique quais artefatos estão disponíveis e escolha uma receita que corresponda a um ambiente de avaliação existente. Meça o custo operacional juntamente com o desempenho nas tarefas.

A Microsoft apresentou uma proposta clara: a pesquisa aberta sobre agentes melhora quando os ambientes se tornam infraestrutura reutilizável, em vez de mecanismos ocultos dos projetos. Agora, a comunidade precisa testar a metade mais difícil dessa proposta. Equipes independentes conseguem reproduzir os resultados, transferir esse aparato para novas tarefas e preservar a eficiência prometida fora da própria configuração da Microsoft?