KwaiKAT lança o KAT-Coder-Pro V2.5, demonstrando capacidades avançadas de codificação

O modelo de codificação nacional está dominando! O KAT-Coder-Pro V2.5 da Kuaishou resolveu um bug real em 1 minuto e 20 segundos e criou manualmente “Minecraft” com 1.395 linhas de código; sua capacidade de engenharia de longo prazo se aproxima do Opus 4.8 — agora você não precisa mais ser o babá da IA.

Autor e fonte do artigo: Nova Inteligência

Será que a codificação com IA já chegou a este ponto?

Mesmo que seja exagerado, nada supera a experiência prática. A seguir, vamos colocar o KAT-Coder-Pro V2.5 em mais cenários reais para explorar plenamente suas capacidades.

Vamos direto ao ponto — o AI integrado ao CC é o KAT-Coder-Pro V2.5, lançado pelo Kuaishou, um modelo agente de codificação de ponta. Enquanto outros AIs ainda competem em “ajudar a completar um trecho de código”, este visa resolver o problema de fazer todo o projeto por você. Essa é exatamente a lacuna final que todos os modelos de codificação enfrentam.

O pênalti anterior era só aquecimento; agora vamos aumentar a intensidade para a V2.5 e recriar o Minecraft em tempo real.

O prompt também tem mais de 400 linhas. Compacte um pouco, mais ou menos assim:

Arquivo HTML único, Three.js, primeira pessoa. 14 blocos, cada um com dureza, transparência e propriedades de colisão; a rocha base é indestrutível. Todos os texturas devem ser geradas programaticamente como imagens de 16×16 pixels no Canvas — não use nenhuma textura externa. Gere uma ilha com ruído de semente fixa, incluindo colinas, costa, águas rasas e veios minerais subterrâneos. Gere programaticamente uma floresta de carvalhos, além de uma cabana na floresta acessível (piso de madeira, pilares de troncos, janelas de vidro, telhado de pedras arredondadas e chaminé de tijolos), e construa um caminho de pedras arredondadas desde o ponto de spawn até a cabana. Ao mirar, exiba uma linha de contorno; segure o botão esquerdo para exibir uma barra de progresso; ao cavar, solte partículas de fragmentos. Efeitos sonoros gerados em tempo real com Web Audio.

Em seguida, um mundo jogável do "Minecraft" foi concluído. Clique em "Entrar no Mundo", e o mouse será travado na tela. Sob seus pés, grama; acima, céu azul. Um caminho de pedras circulares se estende desde seus pés, contorna um carvalho e leva até uma pequena casa atrás da árvore — paredes de tábuas, pilares de troncos, telhado de pedras e uma chaminé de tijolos vermelhos, com janelas de vidro embutidas em todos os lados. Em seguida, caminhe até um terreno vazio à frente da casa, segure o botão esquerdo por um momento e ouça um "pop" enquanto o bloco de grama se quebra. Uma dúzia de pequenos cubos verdes saltam do buraco, girando ao cair. A cor dos fragmentos é exatamente a mesma do bloco que acabou de ser removido. Em seguida, deslize na barra de ferramentas para selecionar materiais como areia, madeira de carvalho e pedra — é hora de colocar sua criatividade em ação e construir sua casa. Surpreendentemente, neste mundo, presenciamos também um pôr do sol que tingiu todo o horizonte.

Mais um teste interativo: faça o V2.5 modelar um sistema solar com as mãos. Para avaliar seus limites, fornecemos condições extremamente rigorosas:

1000+ linhas de prompts, os pontos principais são os seguintes:

Um único HTML, apenas Canvas 2D, sem uso de Three.js. Oito planetas e onze satélites, todos com elementos orbitais reais do epoch J2000 — semieixo maior, excentricidade, inclinação, longitude do nó ascendente, parâmetro do periapsis, anomalia média. Proibido estritamente usar angle += speed. Planetas e satélites devem resolver a equação de Kepler por iteração de Newton, compartilhando o mesmo daysSinceJ2000. A rotação de Vênus e Urano deve ser negativa. Tritão deve orbitar em sentido retrógrado, com inclinação de 157,3°. Os anéis de Saturno e Urano devem ser desenhados em duas etapas — frente e atrás — para que os planetas ocultem os anéis. Em alta velocidade, os satélites devem operar em modo de trajetória para evitar cintilação. Ao pausar, a rotação da superfície dos planetas também deve parar; ao reverter, deve retroceder no sentido oposto. Todas as superfícies planetárias devem ser geradas por programa: Júpiter deve ter a Grande Mancha Vermelha, que gira através do hemisfério visível; os continentes da Terra devem desaparecer quando giram para o lado oposto e reaparecer do outro lado. Além disso: oito níveis de velocidade temporal, dois tipos de escala orbital, câmera virtual seguindo o objeto, 700 estrelas fixas com semente aleatória, cinturão de asteroides, cinturão de Kuiper, layout responsivo e nove teclas de atalho.

Diante de uma demanda tão complexa, a V2.5 demonstrou um pensamento engenhoso digno de livro-texto. Ela dividiu precisamente todo o projeto: desde o design da arquitetura e as estratégias de cálculo de órbitas, até o sistema global de proporções duplas, a geração do fundo estelar, a renderização em camadas dos anéis planetários e o gerenciamento complexo do sistema de satélites. Todos os módulos avançam de forma hierárquica, com lógica impecável. Sem mais delongas, vamos direto à demonstração.

Abra esta página da web; no centro está a data de hoje, e os oito planetas na tela estão exatamente nas posições reais que ocupam neste momento. Isso não é um diagrama do sistema solar — é um sistema solar em funcionamento real! O Sol está no centro, e os planetas se espalham ao redor. Entre Marte e Júpiter, há um anel fino de poeira girando lentamente — o cinturão de asteróides. Todos os corpos celestes, todos os satélites, cada nuvem na superfície dos planetas, são todos controlados pelo mesmo tempo de simulação. Quando você pressiona o botão de pausa, os planetas param de orbitar, os satélites param de orbitar e a Terra para de girar. Clique em Saturno e um painel de informações desliza para a direita. Na pequena janela de pré-visualização no topo do painel, Saturno gira lentamente, seus anéis giram junto, e as sobreposições de frente e atrás são perfeitamente precisas. Isso já não parece um trabalho escolar — parece um produto lançado.

Em seguida, colocamos o KAT-Coder-Pro V2.5 dentro de um bug real de código aberto. O resultado foi muito mais emocionante do que um teste de desempenho. O problema veio do humanize, uma biblioteca Python de código aberto real. Em 2024, ela tinha um bug real: naturaldelta(timedelta(hours=-5)) deveria retornar «5 hours», mas em vez disso dizia «a day». Cinco horas negativas foram traduzidas como um dia inteiro. Voltamos o repositório para o commit em que o bug ainda existia, fornecemos apenas o issue e deixamos que ele agisse sozinho, sem nenhum tipo de pista. Após pesquisar 2 padrões e ler 2 arquivos, ele forneceu diretamente o diagnóstico — o Python armazena timedelta negativos em complemento, então timedelta(hours=-5) internamente é days=-1, seconds=68400. O código original aplicava abs() separadamente a ambos os componentes: -1 dia se tornou 1 dia, e 68400 segundos permaneceram inalterados, resultando erroneamente em «1 day + 19 hours». Essa análise da causa raiz coincide perfeitamente com a diagnóstica da correção oficial — armazenamento em complemento, sinais inconsistentes entre componentes e erro causado por abs() aplicado separadamente. Porém, a solução que ele propôs foi diferente da oficial: enquanto a oficial aplica abs() ao timedelta inteiro, ele optou por converter primeiro para segundos totais e depois redividir. Por falar nisso, toda essa rodada foi executada no Claude Code. E o Claude Code é justamente um dos ambientes de treinamento mencionados explicitamente no Harness Scaling oficial — mini-swe-agent, Claude Code, Codex, OpenClaw. Treinar repetidamente em múltiplos frameworks visa garantir que «mudar de framework não cause rejeição». Os testes reais confirmaram que ele realmente conseguiu se adaptar perfeitamente, sem qualquer sinal de «rejeição».

A última questão não era consertar um bug, mas sim inserir um conjunto inteiro de novas funcionalidades em um sistema vivo. Todos já experimentaram: você envia um arquivo de 1 GB, chega a 92% e a conexão cai. Atualiza — e recomeça do 0%. A solução se chama upload por fragmentos: divida em mil pedaços; se interromper, apenas envie os pedaços que não foram concluídos. Parece simples: dividir, enviar, reunir. Mas o difícil não são esses três passos, e sim o caos no meio:

Fragmentos chegaram fora de ordem. O cliente reconectou e retransmitiu, mas o servidor não consegue distinguir se é uma tentativa de reenvio ou uma sobrescrita. Após a reinicialização do servidor, 700 fragmentos no disco tornaram-se órfãos órfãos. Mesmo que todos cheguem completos, isso não garante que foram transmitidos corretamente.

Ele rodou por 20 minutos e 12 segundos. A solução foi dividir o disco em três gavetas: publicados, metadados de progresso e fragmentos incompletos. Os fragmentos permanecem sempre em chunks/, fisicamente inacessíveis à área publicada. Os metadados são primeiro escritos em arquivos temporários e depois renomeados atomicamente. Isso porque o processo pode falhar exatamente no meio da escrita do progresso, deixando dados corrompidos. Escrevendo primeiro tudo completo e depois renomeando de uma só vez, ou tudo funciona ou nada funciona. Após reiniciar, basta verificar rapidamente e o progresso retorna imediatamente. Fragmentação repetida, comparação byte a byte. Uma abordagem preguiçosa seria: “se já há um fragmento nessa posição, considere como duplicado e permita”. Mas aqui, é feito byte a byte: mesmo uma pequena diferença gera um erro, e os dados originais permanecem inalterados. O resultado final são 8 arquivos, cerca de 1400 linhas de código, cinco novas APIs e 26 testes de upload, incluindo pausa e continuação, bem como recuperação após recarregamento no navegador. npm test → 33 testes, 0 falhas. E nenhum dos cinco interfaces antigos foi quebrado. A chave deste problema foi, durante os vinte minutos, não esquecer uma única situação de “e se…?”. Na engenharia de software real, nove décimos do esforço são gastos nesses “e se…?”.

A capacidade de nível engenharia do Agente se aproxima diretamente do Opus 4.8

Vamos revisar o desempenho do KAT-Coder-Pro V2.5 nas listas reais. No PinchBench, que avalia a capacidade de uso de ferramentas agênticas, o KAT-Coder-Pro V2.5 obteve 94,2 pontos, superando o Opus 4.8. Na SWE-Bench Pro, amplamente reconhecida como a avaliação mais desafiadora para engenharia de software em escala de repositório, ele alcançou 65,2 pontos, ficando apenas atrás do Opus 4.8 (69,2 pontos) e superando significativamente uma série de modelos nacionais. Além disso, no conjunto interno de avaliação de engenharia real, o KAT Code Bench, ele obteve 53,1 pontos, classificando-se no segundo grupo; e no conjunto de avaliação agêntica voltado para negócios, o KAT Claw Bench, alcançou 85,5 pontos, competindo diretamente com os melhores modelos fechados e abertos. Em todo o cenário de modelos de codificação, isso representa uma ascensão real para o primeiro escalão. Após conhecer a força real do KAT-Coder-Pro V2.5, é hora de explorar suas implementações técnicas por trás.

Análise da tecnologia principal

Desta vez, a equipe KwaiKAT realizou uma atualização sistemática em torno de “cadeias de tarefas mais longas e fluxos de trabalho de negócios mais complexos”. Especificamente, o KAT-Coder-Pro V2.5 alcançou avanços abrangentes em três dimensões-chave:

Capacidade de engenharia de longo prazo, capacidade agente geral e o sistema de aprendizado por reforço agente em larga escala que sustenta tudo isso.

“Alto desempenho em um único arquivo” e “capacidade real de trabalhar no projeto” são duas coisas diferentes

A realidade que precisa ser reconhecida: pedir ao AI para “completar uma função” e pedir ao AI para “concluir um projeto de engenharia” são duas capacidades de ordens de grandeza diferentes. O primeiro, os modelos atuais já dominam perfeitamente. Mas a engenharia de software real sempre tem outro rosto. Os três erros mais comuns dos modelos em tarefas de repositórios de longo prazo são: localizar incorretamente arquivos cruzados, não seguir as normas do projeto e entregar o trabalho sem passar nos testes. O verdadeiro gargalo, porém, geralmente reside em um lugar contraintuitivo: o que travam os modelos não é geralmente a quantidade de código que eles leram, mas sim a quantidade de projetos reais que eles executaram completamente. O problema é que ambientes de repositórios executáveis e verificáveis são extremamente difíceis de montar em larga escala — a taxa de sucesso direta na indústria tem permanecido por volta de 16,5%. Em outras palavras, conseguir montar um repositório funcional a cada seis tentativas já é considerado bom. A solução do KwaiKAT é o AutoBuilder, que faz o modelo atuar como um “engenheiro de ambiente”: analisar o repositório, gerar configurações e validar em um sandbox isolado se os testes estão realmente sendo executados; se falhar, ele itera automaticamente para corrigir. Os resultados são imediatos: a taxa de sucesso na construção de ambientes subiu de 16,5% para 57,2%, acumulando mais de 100 mil ambientes de repositórios executáveis e verificáveis, cobrindo 12 linguagens de programação. Os tipos de alterações nesses ambientes abrangem correção de defeitos, complementação de funcionalidades, compatibilidade de interfaces, interação entre módulos e correção de regressões — quase replicando todos os cenários encontrados no desenvolvimento real. Este é o “ateliê de treinamento” da V2.5. Há também uma ideia engenhosa no processamento de dados. A indústria costuma “manter o correto e descartar o errado”, mas o KwaiKAT prefere buscar ouro nos fracassos — muitos fracassos estão apenas a um passo de sucesso: a direção está correta, a localização precisa, mas falta apenas um julgamento-chave. A equipe selecionou essas amostras, reaplicou-as com prompts direcionados e cerca de 20% se transformaram em dados de treinamento de alta qualidade e reproduzíveis. Assim, o modelo aprende não apenas “como fazer certo”, mas também algo ainda mais valioso: “como recuperar-se quando erra”.

Agente universal, da "capacidade de chamar ferramentas" à "capacidade de suportar negócios"

Escrever código é apenas metade da capacidade agente. A outra metade é dominar fluxos de trabalho de negócios reais. Os atuais testes de chamada de ferramentas são principalmente tarefas atômicas — verificar o tempo, reservar um bilhete, terminando em cerca de cinco etapas. Mas os negócios reais são de outra ordem de grandeza; por exemplo:

Ler os trending de várias plataformas por uma semana, filtrar itens do setor de vídeos curtos, obter os cinco mais populares por plataforma, e produzir um boletim com seções e limites de palavras, ordenado por data em ordem decrescente, sem inventar dados.

Esse tipo de tarefa envolve mais de dez interações e está envolto em uma série de restrições implícitas de formato e consistência; se um único elo for interrompido, todo o processo falha. Assim como engenharia de longo prazo, essa habilidade é desenvolvida no “chão de fábrica”. No lado do código, o AutoBuilder atua; no lado da operação, o KwaiClawEnv assume; juntos, formam um ciclo fechado de três camadas:

• A camada de serviço expande dinamicamente o pool e converte grande quantidade de Skill da comunidade em serviços implantáveis;
• A camada Task utiliza negócios reais como semente e deriva variações em grande quantidade de tarefas;
• A camada Eval usa um filtro duplo de "regras rígidas + revisão por modelo", mantendo apenas trajetórias executáveis, verificáveis e com comportamento natural.

Os dados de treinamento gerados contêm, em média, 15 chamadas de ferramentas por trajetória, com o máximo superando 100 passos, abrangendo análise de dados, integração entre sistemas, processamento em lote de documentos e geração de relatórios. Essas são exatamente as tarefas que milhares de engenheiros e profissionais de negócios da Kuaishou enfrentam diariamente.

Aprendizado por reforço em larga escala, permitindo que a IA aprenda sozinha "como fazer"

O fine-tuning supervision permite que o modelo copie exemplos, mas fica confuso diante de erros desconhecidos e feedbacks inesperados. É o RL em grande escala que realmente ensina o modelo a explorar, corrigir erros e validar. A equipe KwaiKAT concentrou seus esforços nos seguintes três pontos:

Primeiro, o andaime não tem limites (Harness Scaling).

Faça o modelo treinar alternadamente em diversos frameworks, como mini-swe-agent, Claude Code, Codex e OpenClaw. Esses frameworks apresentam grandes diferenças em protocolos de chamada, gerenciamento de contexto e fluxo de controle, forçando o modelo a desenvolver suas habilidades diretamente na "resolução de tarefas", de modo que não sofra adaptação ao mudar de framework.

Segundo, a atribuição de crédito de longo prazo.

Em centenas de interações, em qual passo exatamente foi alcançado o bom resultado? A equipe usou o PPO assimétrico: enquanto o modelo opera, ele só vê informações do ambiente real, mas o Critic, responsável pela avaliação durante o treinamento, pode aproveitar uma “visão de deus” adicional — assim, a recompensa ou punição é precisamente atribuída a um passo específico, evitando o efeito “um erro e tudo falha”.

Terceiro, três níveis de recompensas.

Nível superior: resultados reais de teste bloqueados, fechando caminhos para manipulação de pontuações; nível médio: padronização de chamadas de ferramentas, limpeza de arquivos temporários e outros hábitos de engenharia; nível inferior: fornecimento de feedback positivo para falhas valiosas, como “localização precisa, teste parcialmente realizado”, protegendo a curiosidade exploratória do modelo. Vale destacar que a equipe inicialmente acreditou que o problema do baixo reward era algorítmico, mas após investigação, descobriram que o culpado era o próprio ambiente de treinamento — nos estágios iniciais, cerca de 16% das trajetórias apresentavam pelo menos uma falha originada no sandbox, e não no modelo. Após um ciclo de aprimoramento intensivo da infraestrutura, a taxa de erro do sandbox foi reduzida para abaixo de 2%, e a frequência de falhas no treinamento diminuiu aproximadamente uma ordem de grandeza. São exatamente essas tarefas discretas e fundamentais que sustentam o treinamento estável que se seguiu.

Um modelo que abrange cinco habilidades

Engenharia de longo prazo, agente geral, terminal, estética de frontend, conhecimento geral — KwaiKAT treinou um especialista para cada uma dessas cinco áreas. O desafio era integrá-las em um único modelo, evitando o efeito "pressionar um lado e o outro subir". A solução da equipe foi o MOPD (Distilação Online de Estratégias com Múltiplos Professores): o aluno resolve os problemas sozinho, e, conforme o domínio do problema, um especialista correspondente o orienta; as capacidades são fundidas no espaço de funções, não por combinação rígida de parâmetros.

Um KAT-Coder-Pro V2.5, com as habilidades de cinco especialistas em um só, sem necessidade de trocar durante a implantação — escreva código, execute fluxos e crie páginas, tudo em um único lugar.

A excelente capacidade estética da versão anterior foi plenamente mantida nesta nova versão, confirmando exatamente este princípio: novas habilidades foram amplamente expandidas, enquanto as antigas permaneceram intactas. Essa reestruturação incansável diretamente resultou no histórico mais convincente.

Na segunda metade do coding, o que importa é a "engenharia".

Por trás do KAT-Coder-Pro V2.5 está um julgamento claro: atualmente, o limite para o fortalecimento dos modelos de programação já não está no "tamanho do modelo", mas sim na solidez da infraestrutura ao redor. Por isso, a construção do ambiente, a síntese de trajetórias, a estabilidade do RL e a fusão de capacidades foram tratadas como projetos sistêmicos de primeira linha. O resultado é um perfil de capacidade claro — uso avançado de ferramentas agênticas, combinado com habilidades de engenharia em escala de repositório, entre as mais próximas da vanguarda global. Para desenvolvedores, isso significa que finalmente é possível confiar um problema completo ou um fluxo de trabalho inteiro para ser executado sem precisar mais ser o "babá" da IA. Agora, o KAT-Coder-Pro V2.5 está totalmente disponível e pronto para ser experimentado imediatamente. Para começar: chame diretamente a API pelo StreamLake.com (ID do modelo: kat-coder-pro-v2.5).