Um modelo gratuito e 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 faz.
Aqui está a parte que a maioria das pessoas pula:
O enxame não corre apenas 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 o 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 único portal – o portal de verificação – e sua única função é impedir que lixo seja salvo como habilidade. O motor aprende. O auditor mantém a honestidade.
Algumas pessoas escolhem um modelo e se casam com ele. Outras perseguem a linha de pontuação mais alta no ranking. Outras ainda configuram o LangGraph e passam um fim de semana debugando um DAG.
O resultado geralmente é o mesmo: um fluxo de trabalho que faz exatamente a mesma coisa na execução nº 50 que fez na execução nº 1.
Isso não é assim. Este é o manual completo para um enxame que se consolida. 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 curta – "pesquise o mercado de aplicativos de fitness" – e esperam genialidade. 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 contratado, não como um gênio. 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 por si só.
Você não constrói os agentes como faria no CrewAI, não monta o gráfico como no LangGraph, não define 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á incluso, o que está explicitamente fora]4REGRAS: [validação — o que conta como uma linha/descoberta verificada]5FONTES: [posts oficiais, artigos, apenas primárias — sem agregadores]6SAÍDA: [tipo de arquivo / quantidade / nomenclatura / detalhes de formato]7EM 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 lida, 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 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 indica se sua tarefa se encaixa no formato.
1Mostre-me a decomposição proposta antes de executar:2- quantos subagentes e o que cada um lida3- 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 perdulário – essa é a ideia
Agora você o 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ência seja resolvido.
Cada subagente trabalha em sua própria janela de contexto limitada. Esse é o truque estrutural: um agente único 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 delimitado, de modo que apenas saída estruturada flui de volta para o coordenador. É por isso que ele não colapsa em tarefas que quebram um agente único.
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 pagar para jogar fora a primeira tentativa e executá-la novamente. Volume barato muda o que você está disposto a tentar.
1Execute a especificação de ponta a ponta.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 entregáveis estruturados que vão direto 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.
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 por 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á o único passo que não é do Kimi. A falha conhecida do enxame: a menos que você exija explicitamente a verificação, ele produz afirmaçõ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 foi construído exatamente para este portal. A Anthropic relata que ele é cerca de 4x menos provável que o 4.7 de deixar uma falha em seu próprio código passar despercebida, e é o primeiro Claude a pontuar 0% em relatar acriticamente resultados falhos.
Seu único trabalho aqui é refutar, não elogiar. Você não está pagando tokens premium para gerar – está pagando para pegar a falha silenciosa antes que a etapa 4 a salve em uma habilidade para sempre.
Volume barato só é um superpoder quando algo confiável está verificando o trabalho. Mantenha o portal de verificação.
06. Salve todo o fluxo de trabalho como uma Skill
Este é o passo que torna o ciclo autoaprimorável. Após uma execução que você repetirá, diga ao Kimi para capturar todo o fluxo de trabalho como uma Skill 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 "autoaprendizado". O modelo não está retreinando seus pesos entre suas execuções.
O sistema ao redor dele 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 Skill reutilizável: "[nome]"2Capture:3- formato de entrada (que tipo de arquivo / 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 Skills capturam o processo. Documento-para-Skill captura o domínio. Carregue seu melhor trabalho – uma proposta de negócio fechada, um relatório polido, uma apresentação – e o Kimi captura sua impressão digital estrutural e estilística como uma habilidade que todo enxame futuro aplica automaticamente.
Aqui é onde se consolida: cada PDF, transcrição ou planilha que você alimenta se torna contexto contra o qual todos os 300 agentes paralelos podem se basear, em vez de recorrer a dados genéricos de treinamento.
Quanto mais você o alimenta, mais precisa se torna cada execução subsequente. Os relatórios param de parecer IA genérica e começam a parecer 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 padrão de qualidade, não o conteúdo.
08. Transforme o feedback da verificação em uma regra permanente
A etapa 5 pega 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 erros. O desvio 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 torna uma documentação viva que se autoaplica – e o portal de verificação tem cada vez menos o que pegar a cada vez.
1# RESTRIÇÕES.md — carregado automaticamente2- todo número reivindicado deve ser rastreado até uma fonte primária ou sinalizado3- nenhuma resolução silenciosa de conflitos — superfície as 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. Reproduza a habilidade em novas entradas – veja o custo cair
Agora a recompensa. A execução nº 2 não começa do zero. Ela começa a partir 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 "consolidação" deixa de ser uma palavra da moda e aparece na fatura. A primeira execução de monitoramento competitivo leva uma especificação completa e uma passagem 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 RESTRIÇÕES.md. Use o formato de saída capturado.3[Anexar novos arquivos]4Relate apenas desvios do formato esperado da habilidade.
20 minutos na primeira execução. 30 segundos na quinquagésima. Essa diferença é toda a razão para construir um ciclo em vez de um prompt.
10. Promova o ciclo a um agente de fundo
O movimento final: quando um ciclo está estável e apoiado por habilidades, você para de iniciá-lo manualmente.
Aponte o Kimi para o gatilho – um cronograma, uma nova queda de arquivo, a página de preços de um concorrente – e deixe-o executar todo o ciclo proativamente, exibindo apenas o entregável 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 cada concorrente em paralelo semanalmente e deixando um resumo em sua caixa de entrada com custo de tempo marginal zero.
O único humano restante no ciclo é a pergunta que você definiu 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 RESTRIÇÕES.md,4verifique, depois entregue a SAÍDA + uma diferença em relação à última execução.5Só 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ê lhe dá.
Já vimos essa mesma impressão digital uma vez. Um lançamento aberto reestrutura o que a fronteira fechada pensava possuir, e todo o campo se recalibra da noite para o dia. Aconteceu com o DeepSeek.
Um enxame autoaprendizável 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 de uma vez, 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. Verifique. Depure. E veja-o ficar mais barato e mais nítido toda vez que você o executar.
