Agentes Auto-Modificáveis Aumentam Pontuação de Benchmark para 0.61

Uma equipe de pesquisadores da HKUST e USTC publicou o MOSS, um sistema que permite que um agente autônomo reescreva seu próprio código-fonte em produção — lógica de roteamento, ordenação de hooks, dispatch, invariantes de máquina de estados — e demonstrou um ganho médio em grader-score de 0.25 para 0.61 em um conjunto de benchmark OpenClaw com quatro tarefas em um único ciclo de auto-modificação, sem intervenção humana.

Cada sistema existente de agente auto-evolucionário — Hermes Agent, SkillClaw, GenericAgent, EvoAgentX — confina a evolução a artefatos mutáveis em texto: arquivos de skill, configurações de prompt, esquemas de memória, grafos de workflow. O MOSS é o primeiro a também ter como alvo o harness do agente. O argumento central é que edições em camada de texto não conseguem corrigir falhas estruturais: mensagens mal-roteadas, hooks disparando fora de ordem, estado de sessão corrompido, bugs de atomicidade entre skills concorrentes. Essas falhas originam-se no harness, não no prompt. Conforme a complexidade do sistema escala, a lacuna entre o que a evolução mutável em texto consegue corrigir e o que realmente está quebrando em produção se amplia.

O pipeline do MOSS é executado em quatro estágios. Primeiro, evidência de falha em produção é automaticamente organizada em um lote de replay. Segundo, um pipeline determinístico multi-estágio gera modificações de harness candidatas delegando escrita de código a um CLI de coding-agent plugável. Terceiro, candidatos são verificados através do replay do lote de falha contra a imagem modificada dentro de workers de teste efêmeros. Finalmente, um candidato que passa é promovido via swap de container in-place com consent-gated do usuário, com rollback gated por health-probe como válvula de escape se o sistema vivo regredir pós-swap.

A arquitetura das escolhas de design principais traz tradeoffs deliberados. Edições em nível de fonte têm efeito determinístico: a lógica de roteamento é executada como código, não como um prompt que o modelo base deve relê e cumprir. Isso remove a dependência de compliance que prejudica as correções mutáveis em texto. Significa também que edições não se degradam sob drift de contexto longo, um modo de falha real para agentes acumulando semanas de patches em camada de prompt.

No lado quantitativo, o MOSS eleva o grader score médio das quatro tarefas no OpenClaw de 0.25 para 0.61 em um único ciclo de evolução. Essa é a única métrica operacional divulgada. Sem latência, throughput de token, custo-por-evolução ou GPU-horas consumidas foram reportados. Os workers de teste efêmeros implicam custo de infraestrutura por ciclo, mas nenhuma figura é dada. O CLI de coding-agent é plugável mas nenhum CLI benchmarked é nomeado, então o custo da etapa de code-generation também não é caracterizado. Este é um artigo de pesquisa sem evidência de implantação em produção; equipes avaliando o MOSS para adoção precisam instrumentar tanto o custo de replay do trial-worker quanto o tempo wall-clock de evolução end-to-end antes de qualquer dimensionamento em produção.

As questões abertas são a superfície de mutação e restrições de segurança. O user-consent gate e health-probe rollback são os únicos mecanismos de segurança descritos. O artigo não especifica quais restrições governam quais arquivos ou módulos o agente é permitido modificar, se o CLI de coding-agent opera em contexto sandboxado, ou como o sistema lida com um candidato que passa em replay mas introduz uma regressão de correção latente fora do lote organizado. Prompt-injection via corpus de evidência de falha também é uma superfície de ataque não abordada: um trace de falha crafted poderia direcionar código de harness para uma modificação controlada pelo atacante. A literatura de segurança em agentes estilo OpenClaw documenta que runtimes de agentes existentes falham sob assunções de ataque realistas mesmo sem auto-modificação; o MOSS expande aquela superfície.

Conclusão do arquiteto: se seus agentes auto-curativos apenas retorcem prompts e skills, você está ignorando toda a classe de bugs estruturais em camada de harness que cresce com complexidade do sistema. O MOSS lhe dá o threat model e um padrão concreto de pipeline, mas antes de adotá-lo você precisa de uma superfície de mutação definida e de um corpus de replay mais amplo do que o artigo demonstra.