Kimi K3 para agentes de código: harness, contexto e verificação
K3 em produção é problema de harness primeiro: permissões, o que você injeta no contexto de 1M e gates antes do merge — não mais um recap de benchmark.
A execução do agente ficou verde até alguém ver migrations/ no diff. O K3 não “saiu do controle” — deixamos escopo de escrita na raiz do repo e enfiámos 900k tokens de logs no contexto esperando que o modelo “desse um jeito”. O modelo fez exatamente o que pedimos: editou com confiança na camada errada.
Por isso este artigo existe. As notas de lançamento do Kimi K3 cobrem specs; aqui cobrimos o loop em torno do K3 — API Moonshot ou Kimi Code, disciplina de contexto 1M e gates antes do merge. Snapshot DevCove 2026-07-25: K3 rank #7, index 57, ~161s de primeiro chunk na mesma tabela — planeje batch/agente, não chat nervoso no IDE a menos que seu wrapper esconda a latência.
Layout do harness (o que desenhamos no quadro)
┌──────────────────────────────────────────────┐
│ Humano: escopo + testes de aceite │
├────────────────────┬─────────────────────────┤
│ Alimentação de │ Superfície de tools │
│ contexto │ (shell, MCP, rede) │
│ (paths curados) │ │
├────────────────────┴─────────────────────────┤
│ K3 (tier de raciocínio explícito na API) │
├──────────────────────────────────────────────┤
│ CI + review humano do diff (obrigatório) │
└──────────────────────────────────────────────┘
Harness fraco, qualquer frontier parece quebrado. Conserte a caixa antes de trocar modelo.
| Camada | Default ruim | Default melhor |
|---|---|---|
| Escopo | “Conserta o serviço” | Pacotes + arquivos permitidos nomeados |
| Contexto | Repo inteiro colado | Fatia de spec + teste falhando + um ADR |
| Tools | Shell sem limite | Allowlist; cmds destrutivos pedem humano |
| Saída | Dump multi-arquivo gigante | Patches pequenos por passo |
Contexto 1M: orçamento, não aterro
A janela 1,05M do K3 tenta times a subir tudo. Lixo entra, lixo sai — escala MoE não inventa disciplina.
| Alimente isto | Evite isto |
|---|---|
| User story + non-goals | node_modules inteiro ou SDKs gerados |
| Uma âncora de arquitetura | Cinquenta READMEs sem prioridade |
| Trecho da falha recente no CI | Histórico completo de log |
| Golden test como exemplo | Suite inteira inline |
Limitamos montagem de contexto a 15 minutos por tarefa de agente. Se curadoria demora mais que o fix, a tarefa não estava escopada para agente.
Kimi Code vs HTTP API
| Caminho | Escolha quando |
|---|---|
| Kimi Code | Quer defaults de agente terminal da Moonshot |
HTTP API (kimi-k3) | Embute num orquestrador interno |
| IDE de terceiros | Só se suporte oficial — confira residência de dados |
Security review vale para permissões, não rank de leaderboard. K3 bem no benchmark não aprova acesso a DB de produção.
Loop de verificação (não opcional)
Empreste de Verification gates for AI coding agents:
Ticket de tarefa
→ agente (K3) com tools escopadas
→ testes unit + integração
→ lint / types
→ humano lê diff (não resumo)
→ ship checklist em branches de release
O K3 às vezes alarga patches versus nosso modelo antigo. Patch mais largo = review mais largo, não merge mais rápido.
Quando ainda escolhemos Opus
Se Claude Code já está aprovado, Opus 5 high costuma parecer mais rápido em loops interativos no mesmo snapshot — veja Kimi K3 vs Claude Opus 5. Testamos K3 quando Moonshot está no contrato, custo por tarefa em 1M pesa, ou Kimi Code encaixa na ops.
Regra de ops: Sem overwrite parcial de snapshot GitHub no rate limit — mantenha último stars/models bom; mesma paciência em retries de agente (não desligue gates porque o modelo “quase sempre funciona”).
Links: Rankings · Pilar de metodologia · Ship checklist
Data de evidência: snapshot DevCove 2026-07-25; confira campos da API na doc Moonshot antes de produção.