Passo 3 · Runtime & operação · Runtime · SubagentBatch & disco ENPT
Kimi CLI AgentSwarm · Curso Visual

SubagentBatch & estado em disco

Como o runtime lança subagentes com rampa 5 + 700ms — e onde a forense vive em wire.jsonl e state.json.

Leia a versão simples ou abra a camada técnica em qualquer seção.
1

A ideia central

Quando AgentSwarm passa na validação, a classe SubagentBatch do binário assume. Ela expande cada item em prompt concreto, cria diretórios persistidos de subagentes e os lança com rampa controlada para evitar rate limits do provider.

Política de rampa (documentada + confirmada na sessão 30e21381):

  • Burst: 5 subagentes lançados imediatamente
  • Rampa: +1 subagente a cada 700 ms
  • Cap: opcional KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY limita o burst inicial
  • Rate limit: subagente reenfileirado — Provider rate limit; subagent requeued for retry.

Cada agente (main e sub) tem wire.jsonl append-only. O state.json da sessão guarda o registry com parentAgentId, swarmItem e type: main|sub. Essa é sua trilha forense.

Pense assim… embarque em um wide-body. Os primeiros cinco passageiros entram de uma vez (burst), depois um a cada 700ms (rampa) para não congestionar o portão. Cada passageiro tem seu log de voo (wire.jsonl); o manifesto (state.json) lista quem pertence a qual grupo.

Timestamps observados (8 agentes)

21:41:44.204 agent-3
21:41:44.207 agent-4
21:41:44.210 agent-1
21:41:44.215 agent-2
21:41:44.218 agent-0   ← 5 em ~14 ms
21:41:44.847 agent-5   ← +629 ms
21:41:45.548 agent-6   ← +701 ms
21:41:46.253 agent-7   ← +705 ms

Sessão de stress e046c6c5: 43 agentes, 10× AgentSwarm, 7.471+ eventos no main wire — prova missões multi-swarm sequenciais em produção.

2

Em uma imagem

~/.kimi-code/sessions/ wd_<hash>/session_<uuid>/ state.json registry de agentes agents/ main/wire.jsonl agent-0/wire.jsonl … agent-N/ Rampa SubagentBatch 5 imediatos → +1 / 700ms KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY tipos de evento wire.jsonl tool.call · tool.result · swarm_mode.enter context.append_loop_event (append-only)
Esquerda: layout em disco por sessão. Direita: política de rampa do SubagentBatch e taxonomia de eventos wire.
3

No código

O registry liga cada subagente ao seu item de swarm. O wire registra cada tool call e result.

state.json — registry (sessão 30e21381) 
{
  "agents": {
    "main": { "type": "main", "parentAgentId": null },
    "agent-0": { "type": "sub", "parentAgentId": "main", "swarmItem": "claude" },
    "agent-1": { "type": "sub", "parentAgentId": "main", "swarmItem": "grok" }
  }
}
Strings SubagentBatch (binário v0.18.0) 
AGENT_SWARM_MAX_CONCURRENCY_ENV = "KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY"
RATE_LIMIT_MESSAGE = "Provider rate limit; subagent requeued for retry."

class SubagentBatch {
  normalLaunchCount = 0;
  normalLaunchTimer;
  maxConcurrency;
}

Checagens reproduzíveis

jq '.agents' ~/.kimi-code/sessions/wd_*/session_*/state.json
rg 'AgentSwarm' ~/.kimi-code/sessions/wd_*/session_*/main/wire.jsonl
KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY=4 kimi
4

Experimente: simule a rampa

Arraste o slider para ver quais agentes estariam ativos em cada tick da rampa 5+700ms (swarm de 8 agentes).

0 ms
Fase burst: lançando os primeiros 5 agentes…
Próximo: como Kimi AgentSwarm se compara a Droid Missions — e padrões operacionais que combinam execução swarm com proof gates.