Um modelo gratuito de código aberto está executando 300 agentes paralelos em 4.000 etapas coordenadas a partir de um único prompt, e obtém pontuações mais altas em tarefas de pesquisa reais do que modelos pelos quais você paga 5x mais.
A maioria das pessoas nunca o abriu.
Elas abrem o Kimi, digitam uma pergunta, recebem uma resposta e fecham a aba. Essa é a caixa de chat. Funciona. Mas representa apenas cerca de 10% do que o produto pode fazer.
Aqui está a parte que a maioria das pessoas pula:
O enxame não apenas executa rápido. Execute-o corretamente e ele sempre deixa algo para trás – uma habilidade reutilizável, uma especificação mais refinada, uma restrição que impede a próxima execução de repetir o erro de hoje.
O enxame que executou sua tarefa ontem deve ser mais inteligente do que aquele que a executa hoje.
https://x.com/Kimi_Moonshot/status/2047190578493096122
Esse é o ciclo. O Kimi faz o trabalho e o aprendizado. O Opus 4.8 fica em um portão – o portão de verificação – e sua única função é impedir que lixo seja salvo como habilidade. O motor aprende. O fiscalizador mantém a honestidade.
Algumas pessoas escolhem um modelo e se casam com ele. Outras perseguem a linha de pontuação mais alta do benchmark. Outras ainda configuram o LangGraph e passam um fim de semana depurando um DAG.
O resultado geralmente é o mesmo: um fluxo de trabalho que faz exatamente a mesma coisa na execução nº 50 e na execução nº 1.
Isto não é isso. Este é o guia completo para um enxame que se multiplica. 10 etapas. Cada prompt é copiar e colar. Cada número é verificado.
Parte 1 – Construa o ciclo uma vez. Execute-o para sempre.
01. Escreva uma especificação, não um prompt
Quando a maioria das pessoas ouve "300 agentes", elas disparam uma frase de uma linha – "pesquise o mercado de aplicativos de fitness" – e esperam brilhantismo. Essa é a maneira mais rápida de queimar créditos e obter lixo.
Um prompt de uma linha dá ao enxame permissão para decidir tudo, e ele decidirá errado.
Trate o enxame como um contratante, não como um gênio da lâmpada. Uma especificação define o que coletar, o que conta como válido, quais fontes são permitidas, o formato exato de saída e o que fazer em caso de conflito. Aqui está a parte que a maioria das pessoas pula: o Kimi decide a decomposição sozinho.
Você não constrói os agentes como faria no CrewAI, não conecta o gráfico como no LangGraph, não define a estrutura como no AutoGen. Você descreve o objetivo – o enxame constrói o organograma.
A especificação é o artefato de maior alavancagem em todo o ciclo, porque na etapa 4 ela se torna a semente da sua habilidade reutilizável.
1# PROJETO: [nome]2OBJETIVO: [uma frase — a entrega, não o tópico]3ESCOPO: [o que está incluído, o que está explicitamente excluído]4REGRAS: [validação — o que conta como uma linha/descoberta verificada]5FONTES: [publicações oficiais, artigos, apenas primárias — sem agregadores]6SAÍDA: [tipo de arquivo / quantidade / nomenclatura / detalhes de formato]7EM CASO DE CONFLITO: sinalize a linha, nunca resolva silenciosamente8CONDIÇÃO DE PARADA: [quando parar e relatar em vez de adivinhar]
02. Leia o plano de decomposição antes de gastar um centavo
Esta é a etapa que os iniciantes pulam, e é a mais cara de pular.
Depois de enviar a especificação, o Kimi mostra o plano de execução antes de executá-lo – quantos subagentes, o que cada um manipula, a ordem de dependência, o orçamento de etapas.
Leia-o. Um enxame de 200 agentes decomposto incorretamente custa dinheiro real e horas reais. Verificar o plano não custa nada. Você está procurando por três coisas: se ele entende o escopo, se o número de agentes é razoável para o tamanho da tarefa e se o plano de saída corresponde ao que você realmente precisa.
Um detalhe que vale a pena saber: as 4.000 etapas são um orçamento total coordenado em todo o enxame, não 4.000 etapas por agente. Uma execução de 300 agentes tem uma média de ~13 etapas cada – subtarefas curtas e especializadas. Isso diz se sua tarefa se encaixa no formato.
1Mostre a decomposição proposta antes de executar:2- quantos subagentes, e o que cada um manipula3- a ordem de dependência (o que bloqueia o quê)4- orçamento estimado de etapas5- onde está o maior risco de queda de qualidade6NÃO execute ainda. Aguarde minha confirmação.
Um prompt de uma linha é um desejo. Uma especificação é uma ordem. O enxame executa ordens.
03. Deixe-o ser desperdiçador – essa é a ideia
Agora você executa. Até 300 subagentes disparam em ondas paralelas. A primeira onda lida com subtarefas totalmente independentes.
À medida que os resultados chegam, o orquestrador lança a próxima onda naquilo que dependia deles, até que o gráfico de dependências seja resolvido.
Cada subagente trabalha em sua própria janela de contexto limitada. Esse é o truque estrutural: um único agente em uma tarefa longa preenche sua janela até se afogar e começar a sumarização com perdas, e cada etapa de raciocínio depois disso piora.
O enxame dá a cada subtarefa seu próprio contexto com escopo, de modo que apenas a saída estruturada flui de volta para o coordenador. É por isso que ele não colapsa em tarefas que quebram um único agente.
Como o Kimi custa $0,95/M de entrada e $4,00/M de saída – com acertos de cache a $0,16 – você pode se dar ao luxo de jogar fora a primeira tentativa e executá-la novamente. O volume barato muda o que você está disposto a tentar.
1Execute a especificação do início ao fim.2Paralelize onde o plano permitir.3Relate o progresso a cada 30 etapas.4Sinalize qualquer bloqueador imediatamente — não o contorne silenciosamente.5Se um subagente travar >10 min, reatribua ou relate.6Mescle tudo na SAÍDA definida na especificação.
04. Exija arquivos reais, não uma resposta de chat
A saída de um enxame não é texto em uma janela. São entregas estruturadas que vão diretamente para o seu trabalho – e esta é a parte que a maioria dos artigos ignora.
Uma execução gera PDFs, planilhas, conjuntos de dados, apresentações de slides e código funcional, tudo a partir de um único lançamento, porque o Kimi emite esses formatos nativamente.
Portanto, lidere sempre a especificação com a saída.
"Um relatório abrangente" dá aos agentes permissão para parar cedo. "Um PDF de 40 páginas + um CSV com 20.000 linhas + 14 gráficos PNG prontos para exportação" dá a eles um alvo de qualidade a atingir.
A especificidade no nível da saída é a diferença.
1SAÍDA: [tipo de arquivo] / [quantidade] / [nomenclatura] / [detalhe do formato]23# exemplos fortes:4SAÍDA: 1 .xlsx, uma linha por modelo, + resumo de 200 palavras5SAÍDA: 30 arquivos HTML, um por loja, nomeados pelo negócio6SAÍDA: PDF de 40 páginas + CSV de 20.000 linhas + 14 gráficos PNG
05. Aponte o modelo honesto para a saída e pergunte o que está errado
Aqui está a única batida que não é do Kimi. A falha conhecida do enxame: a menos que você exija explicitamente a verificação, ele produz alegações confiantes e com poucas citações, e subagentes independentes às vezes se contradizem. "Parece pronto" e "está correto" são planetas diferentes.
O Opus 4.8 é construído exatamente para este portão. A Anthropic relata que ele é cerca de 4 vezes menos provável do que o 4.7 de deixar passar uma falha em seu próprio código sem ser notada, e é o primeiro Claude a obter 0% em relatar acriticamente resultados falhos.
Sua única função aqui é refutar, não elogiar. Você não está pagando tokens premium para gerar – você está pagando para detectar a falha silenciosa antes que a etapa 4 a salve em uma habilidade para sempre.
O volume barato só é um superpoder quando algo confiável está verificando o trabalho. Mantenha o portão de verificação.
06. Salve todo o fluxo de trabalho como uma Habilidade
Esta é a batida que torna o ciclo auto-aprimorável. Após uma execução que você repetirá, diga ao Kimi para capturar todo o fluxo de trabalho como uma Habilidade reutilizável – formato de entrada, etapas do agente, formato de saída.
A primeira execução leva 20 minutos. Cada execução depois dela leva 30 segundos.
Essa é a versão honesta de "auto-aprendizagem". O modelo não está retreinando seus pesos entre suas execuções.
O sistema ao seu redor está ficando mais inteligente – sua biblioteca de habilidades cresce a cada projeto, e cada enxame futuro aplica essas habilidades automaticamente.
Um concorrente não pode copiar essa biblioteca em uma semana. Ela é construída a partir de meses de suas execuções reais.
1Salve todo este fluxo de trabalho como uma Habilidade reutilizável: "[nome]"2Capture:3- formato de entrada (que tipo de arquivos / formato de especificação ele espera)4- as etapas do agente que funcionaram5- o formato de saída e a convenção de nomenclatura6- as regras de validação da especificação7Da próxima vez que eu executar isso, anexarei novos arquivos e obterei o mesmo formato.
07. Alimente seus próprios documentos como conhecimento do enxame
As habilidades capturam o processo. Documento-para-Habilidade captura o domínio. Carregue seu melhor trabalho – uma proposta de negócio fechado, um relatório refinado, um deck – e o Kimi captura sua impressão digital estrutural e estilística como uma habilidade que todo enxame futuro aplica automaticamente.
Aqui é onde se multiplica: cada PDF, transcrição ou planilha que você alimenta se torna um contexto contra o qual todos os 300 agentes paralelos podem se basear, em vez de depender de dados de treinamento gerais.
Quanto mais você o alimenta, mais precisa se torna cada execução subsequente. Os relatórios param de soar como IA genérica e começam a soar como seu trabalho.
1Capture este documento como uma habilidade reutilizável. Identifique o que o faz funcionar:2- estrutura e ordem das seções3- tom e registro de voz4- profundidade da análise por seção5- o ritmo de escrita e as decisões de formatação6Salve-o como "[nome]". Em seguida, produza um novo documento sobre [tópico diferente]7usando a habilidade capturada — iguale o nível de qualidade, não o conteúdo.
08. Transforme o feedback da verificação em uma regra permanente
A etapa 5 detecta uma falha uma vez. A etapa 8 garante que o enxame nunca mais a cometa. Pegue a lista de correções do Opus e não apenas corrija a saída – incorpore a lição em um arquivo de restrições de nível de projeto que o Kimi lê automaticamente no início de cada sessão.
Este é o ciclo aprendendo com seus próprios fracassos. A deriva que o Opus sinalizou na execução nº 1 se torna uma regra rígida na execução nº 2.
Ao longo de alguns projetos, seu arquivo de restrições se transforma em documentação viva que se autoaplica – e o portão de verificação tem cada vez menos a detectar a cada vez.
1# RESTRICOES.md — carregado automaticamente2- toda figura reivindicada deve remeter a uma fonte primária ou ser sinalizada3- nenhuma resolução silenciosa de conflitos — superfícies de contradições4- [regra destilada do feedback do Opus da última execução]5- [o erro que você nunca quer repetir]6Bloqueio de escopo: não toque em nada fora do bloco ESCOPO da especificação.
09. Reexecute a habilidade em novas entradas – veja o custo despencar
Agora o retorno. A execução nº 2 não começa do zero. Ela começa da habilidade, do conhecimento do enxame e do arquivo de restrições que você construiu nas etapas 6–8.
Mesmo fluxo de trabalho, novos arquivos, uma fração da configuração.
É aqui que "multiplicação" deixa de ser um chavão e aparece na fatura. A primeira execução de monitoramento competitivo leva uma especificação completa e uma passada de verificação.
A quarta é um prompt de 30 segundos contra a habilidade salva, e a saída é mais nítida porque herda todas as correções das execuções anteriores.
1Execute a habilidade salva "[nome]" nestas novas entradas.2Aplique RESTRICOES.md. Use o formato de saída capturado.3[Anexar novos arquivos]4Relate apenas desvios do formato esperado da habilidade.
20 minutos na execução um. 30 segundos na execução cinquenta. Essa lacuna é a razão inteira para construir um ciclo em vez de um prompt.
10. Promova o ciclo a um agente de fundo
O movimento final: uma vez que um ciclo está estável e apoiado por habilidades, você para de lançá-lo manualmente.
Aponte o Kimi para o gatilho – um cronograma, um novo arquivo depositado, a página de preços de um concorrente – e deixe-o executar todo o ciclo proativamente, exibindo apenas a entrega e os desvios.
O monitoramento competitivo é o exemplo claro.
Na execução nº 1, você constrói e verifica manualmente. Quando se torna um agente de fundo, ele está verificando todos os concorrentes em paralelo semanalmente e deixando um resumo na sua caixa de entrada com custo de tempo marginal zero.
O único humano restante no ciclo é a pergunta que você define e a decisão que você toma sobre a resposta.
1Execute a habilidade "[nome]" em um cronograma semanal.2Gatilho: [cronograma / novo arquivo / URL monitorada]3Em cada execução: execute o enxame, aplique RESTRICOES.md,4verifique, depois entregue a SAÍDA + uma diferença em relação à última execução.5Apenas me notifique se um desvio ultrapassar [limite].
Conclusão:
Enquanto os laboratórios fechados continuam lançando um chatbot mais inteligente de cada vez, um modelo aberto está executando 300 agentes em paralelo – e ficando mais inteligente no nível do sistema a cada execução que você dá a ele.
Já vimos essa impressão digital exata uma vez. Um lançamento aberto reformula o que a fronteira fechada pensava possuir, e todo o campo se recalibra da noite para o dia. Aconteceu com o DeepSeek.
Um enxame auto-aprendiz em um modelo de pesos abertos tem a mesma forma.
Os construtores ainda discutindo qual modelo "venceu" estão respondendo a uma pergunta que deixou de importar.
A pergunta agora não é qual modelo é o mais inteligente. É quantos você pode executar ao mesmo tempo, quem está verificando o trabalho deles e se sua configuração está mais afiada hoje do que estava ontem.
A maioria das pessoas lerá isso e continuará usando o Kimi como uma caixa de chat. Alguns construirão o ciclo esta semana. A primeira execução leva 20 minutos. Cada execução depois disso é alavancagem que você possui.
Construa-o. Verifique-o. Destile-o. Depois veja-o ficar mais barato e mais afiado toda vez que você o executa.
