Passo 6 · Multi-agente · Multi-agente · Loop Engineering ENPT
Multi-agente · Passo 6 · Como um modelo comanda uma equipe

Delegação entre agentes via cli -p

Uma execução do loop não precisa ser feita por uma única IA. Um modelo — o orquestrador — pode distribuir trabalho a uma equipe inteira de outros assistentes de IA, um pequeno serviço de cada vez, conversando com cada um pela sua linha de comando. Esta lição é sobre como esse repasse realmente funciona: quem está na equipe, como o orquestrador verifica que um assistente está sequer disponível antes de confiar nele, os comandos exatos que ele usa para chamar cada um, e a única regra de segurança que torna tudo isso confiável.

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

A grande ideia: um modelo conduzindo uma equipe

Até aqui o loop teve um único trabalhador fazendo cada passo. Mas existem muitos assistentes de IA capazes, e cada um é melhor em algumas coisas do que em outras. O harness permite que um deles atue como encarregado — nós o chamamos de orquestrador — e distribua o trabalho de verdade aos outros, um pequeno serviço bem definido de cada vez.

A maneira como o encarregado conversa com cada assistente é deliciosamente comum: ele executa o programa de linha de comando do assistente, o mesmo tipo de comando digitado que você rodaria num terminal. Cada um desses assistentes oferece um modo "headless" — um jeito de fazer uma única pergunta e receber uma única resposta de volta, sem janela de chat, sem cliques, só texto entrando e texto saindo. O encarregado injeta uma tarefa, lê o resultado e segue para o próximo serviço. Esse é todo o truque: delegar é apenas o orquestrador executando o comando de outro assistente e lendo o que volta.

Três coisas precisam ser verdadeiras para que isso seja seguro, e elas se encaixam em três tipos de participante. Uma pessoa decide, logo no começo, quais assistentes sequer têm permissão na equipe — essa lista nomeada se chama roster. O orquestrador (ele mesmo uma IA) verifica que cada assistente está de fato instalado nesta máquina antes de confiar nele, escolhe o comando certo para chamá-lo, e nunca deixa o mesmo assistente construir uma coisa e ser o que aprova essa coisa. E os assistentes em si apenas fazem o único serviço que recebem e devolvem o resultado. Ninguém precisa ficar de babá da tela enquanto isso acontece — essa disciplina de não intervir veio da lição anterior.

Pense nisso como… um chef de cozinha durante o pico do jantar. O chef não cozinha cada prato pessoalmente. Ele chama um pedido de cada vez — "mesa quatro, o salmão" — para o cozinheiro que comanda aquela estação, e só chama estações que estão de fato cobertas hoje à noite. Mais importante, o chef faz uma segunda pessoa provar o prato antes de ele sair da cozinha — nunca o cozinheiro que o fez, porque quem faz é o pior juiz do próprio trabalho. Onde a analogia se dobra: na nossa cozinha o chef também é um dos cozinheiros, e o "chamar" é literalmente digitar um comando e ler a resposta.

O que "delegar via cli -p" significa, com precisão

O orquestrador é um modelo de ponta conduzindo a execução. Para delegar, ele invoca a interface de linha de comando de outro agente em modo não interativo — convencionalmente a flag -p ("prompt") ou um subcomando exec — passando uma unidade delimitada de trabalho como prompt e capturando o stdout. Não há memória compartilhada nem sessão ativa: cada chamada é uma invocação nova e sem estado, que é exatamente o que torna uma unidade delimitada. O contrato é "aqui está um serviço e o contexto de que ele precisa; devolva o resultado".

Uma unidade de cada vez, de propósito

A delegação é serial por unidade, não um vale-tudo. O orquestrador entrega uma única unidade, lê o resultado, verifica-o no limite real (o Portão da Prova da lição 3), e só então despacha a próxima. Isso mantém cada passo auditável no LOOP-LOG.md e impede que dois agentes corram pelo mesmo artefato. O roster pode ser heterogêneo — Claude, Codex, Kimi, Grok, GLM, Minimax — e o orquestrador é deliberadamente agnóstico: ele escolhe por unidade, não uma única vez para toda a execução.

2

A delegação em uma imagem

Aqui está todo o repasse como um único fluxo. Uma pessoa define o roster; o orquestrador pega uma unidade, verifica que o assistente escolhido está instalado, executa o comando dele e lê o resultado de volta; então um assistente diferente o valida. Se o assistente não estiver instalado, o orquestrador simplesmente o pula — ele nunca chama um comando que não existe.

Pessoa declara o roster Orquestrador pega UMA unidade Agente instalado? Invoca cli -p prompt entra → texto sai Bloqueado — pulado não está nesta máquina Validador nunca o construtor Resultado stdout sim não checado por um agente diferente
Leia da esquerda → direita. O caminho sólido é uma delegação bem-sucedida; o caminho vermelho tracejado é um agente que não está instalado, bloqueado antes de qualquer comando rodar.
pessoa define o roster orquestrador escolhe por unidade preflight antes de confiar uma unidade de cada vez validador ≠ construtor
3

As quatro camadas, passo a passo

A delegação se empilha em quatro camadas, e o jeito mais fácil de senti-las é percorrê-las uma de cada vez. Use a trilha abaixo: cada parada é uma camada do repasse, da pessoa que nomeia a equipe, à verificação de segurança do orquestrador, ao comando em si, à aprovação independente. Clique numa aba, ou avance com Próximo.

loop-engineering · uma unidade delimitada · orquestrador → agente instalado
Entregue uma unidade ao assistente certo, com segurança
AFK · humano na observabilidade 4 camadas roster: claude · codex · kimi · grok · glm · minimax

Uma pessoa declara a equipe — antes de a execução começar.

O orquestrador não pode inventar os próprios ajudantes. Logo no início de uma execução, um humano anota o roster de agentes: o conjunto nomeado de assistentes a que esta execução pode delegar. O padrão é agnóstico — qualquer assistente capaz pode estar nele — mas a lista é explícita, então você sempre sabe quem poderia tocar no seu trabalho.

  • claudeA CLI da Anthropic. Forte e versátil; muitas vezes o próprio orquestrador.instalado
  • codexO agente de código da OpenAI, executado em modo headless com exec.instalado
  • kimi · grokConstrutores adicionais, cada um com suas próprias flags headless.instalado
  • glm · minimaxAcessados por um proxy local (cliproxyapi) em vez de uma CLI nativa.instalado
  • pi · agyNo roster pelo nome, mas não instalados nesta máquina — então precisam ser bloqueados, nunca chamados.bloqueado
Camada 1 de 4 · Roster

Por que cada flag é o que é

--output-format json (Claude) entrega um envelope estruturado que o orquestrador consegue interpretar sem raspar prosa. codex exec --quiet suprime a tagarelice de progresso para que o stdout seja só a resposta. kimi -p … --output-format text é o caminho headless suportado — combinar -p com --yolo não é suportado e --work-dir é rejeitado, então nenhum dos dois é usado. grok -p … --output-format plain --always-approve --cwd "$PWD" roda de forma não interativa, aprova automaticamente as próprias tool calls (não há humano para clicar), e fixa o diretório de trabalho explicitamente.

GLM e Minimax não têm CLI nativa

Eles são acessados por cliproxyapi, um processo local que os expõe em um endpoint HTTP compatível com OpenAI. O orquestrador chama esse endpoint em vez de um binário, mas o contrato é idêntico: uma unidade delimitada entra, um resultado sai, validado por outra pessoa.

Bloqueando agentes ausentes

pi e agy aparecem no roster por portabilidade, mas numa máquina onde command -v não consegue encontrá-los eles são excluídos do conjunto de candidatos para toda unidade. O bloqueio é silencioso e por máquina: o mesmo arquivo de roster funciona em todo lugar, e cada host simplesmente delega ao subconjunto que de fato estiver instalado.

4

Preflight: nunca chame um comando que não existe

Esta camada merece seu próprio momento porque é a diferença entre uma equipe robusta e uma frágil. O orquestrador trata "este assistente está instalado?" como uma pergunta a ser respondida pela máquina, não presumida. Se a resposta for não, esse assistente é bloqueado — tirado da disputa por esta unidade — e o trabalho vai para alguém que de fato está presente. É o mesmo hábito anti-suposição do LEARN, aplicado à própria equipe.

Rode o preflight à mão

A partir do diretório do seu projeto, pergunte ao shell quais agentes existem. command -v imprime o caminho resolvido de cada binário que encontra e fica em silêncio para o resto, então os que imprimem são seus candidatos instalados.

terminal — liste quais agentes estão instalados agora 
# rode de qualquer lugar; imprime uma linha por agente
for a in claude codex kimi grok pi agy; do
  if command -v "$a" >/dev/null 2>&1; then
    echo "disponível: $a"
  else
    echo "bloqueado:  $a"   # não instalado → nunca invocado
  fi
done

Se o harness incluir detect_panel.sh, dar source nele faz a mesma varredura e deixa o resultado em PANELISTS. De qualquer forma, o orquestrador só delega a um nome que sobreviveu a esta verificação.

5

As invocações comprovadas, lado a lado

Depois que um assistente passa no preflight, o orquestrador o chama com o único comando que se sabe funcionar em modo headless para aquela ferramenta. Você as viu na demo; aqui elas estão reunidas como referência, com as armadilhas explicitadas. O ponto da camada simples: cada assistente é chamado de um jeito diferente, as flags não são intercambiáveis, e algumas combinações são proibidas.

referência de cli -p — copie ao pé da letra, as flags são essenciais 
claude  -p "<unidade>" --output-format json
codex   exec --quiet "<unidade>"
kimi    -p "<unidade>" --output-format text        # nunca -p + --yolo; sem --work-dir
grok    -p "<unidade>" --output-format plain --always-approve --cwd "$PWD"
# glm / minimax → via cliproxyapi (endpoint compatível com OpenAI, sem CLI nativa)

Lendo um resultado de volta

Como as chamadas são sem estado, o orquestrador captura o stdout de cada invocação e o interpreta conforme o formato que pediu — JSON para o Claude, texto puro para os demais. Não há turno de continuação; se for preciso mais, isso é uma nova unidade delimitada e uma nova chamada. É isso que mantém cada delegação auditável de forma independente.

As duas armadilhas do Kimi

Dois erros específicos quebram o Kimi em modo headless: parear -p com --yolo, e passar --work-dir. A forma suportada é exatamente kimi -p "<unidade>" --output-format text. O harness codifica isso para que um orquestrador delegante não caia em nenhuma das duas armadilhas.

6

Por que o Validador nunca é o construtor

Se você guardar uma regra desta lição, que seja esta. O assistente que produziu uma unidade é o pior juiz de se ela está correta — ele já está convencido. Por isso o harness nunca deixa um construtor aprovar o próprio trabalho. A validação sempre vai para um assistente diferente do roster, que verifica o resultado contra a realidade: rodar o teste, chamar o endpoint, ler o arquivo. Só então a unidade conta como concluída.

Esta é a razão mais profunda para manter uma equipe mista. Com vários assistentes disponíveis, há sempre um segundo que não escreveu o código e consegue olhá-lo com olhos novos. O orquestrador roteia a verificação para longe do autor automaticamente — e o veredito ainda precisa ser evidência real (o Portão da Prova), registrado onde o humano pode ler.

PROIBIDO agente A constrói agente A valida EXIGIDO agente A constrói agente B valida limite real · Portão da Prova LOOP-LOG.md
Em cima: um construtor avaliando a si mesmo — cego para os próprios bugs. Embaixo: um agente diferente valida contra evidência real, e então é registrado.

A regra única

Construtor e validador são sempre dois agentes diferentes. Quem faz não pode certificar o próprio trabalho — o segundo par de olhos é todo o sentido de ter uma equipe.

7

Quem faz o quê: uma pessoa, o orquestrador, os assistentes

Todo o mecanismo se resume a três responsabilidades, e mantê-las separadas é o que torna uma execução multi-agente segura em vez de caótica. Elas não são três fases que você faz em ordem — são três papéis agindo ao mesmo tempo.

Uma pessoa

Declara o roster de agentes no início da execução — o conjunto nomeado de assistentes a que se pode delegar. Depois disso, ela permanece na observabilidade (lendo o LOOP-LOG.md), não na execução.

O orquestrador (uma LLM)

Faz o preflight de cada agente, escolhe o comando cli -p certo, distribui uma unidade delimitada de cada vez, e roteia a validação para que o Validador nunca seja o construtor.

Os assistentes (agentes)

Cada um executa o único serviço que recebe em uma chamada nova e sem estado e devolve o resultado. Os não instalados aqui — pi, agy — são bloqueados e nunca chamados.

Por que a divisão importa

O humano que detém o roster delimita quem pode tocar no trabalho; o orquestrador que detém o despacho delimita como (uma unidade, o comando certo, validação independente); os agentes que detêm a execução mantêm cada chamada sem estado e substituível. Quebre qualquer um deles — deixe o orquestrador inventar ajudantes, ou um construtor se autovalidar, ou chamar um binário não instalado — e a execução perde a propriedade de que todo passo é auditável e reproduzível.

8

Verificação rápida

Três perguntas rápidas para fixar as regras. Escolha uma resposta; você verá na hora se ela se sustenta.

Q1Antes de delegar uma unidade ao kimi, o orquestrador roda command -v kimi e não recebe nada de volta. O que acontece?

Q2O agente A acabou de produzir uma unidade. Quem deve validá-la?

Q3Qual invocação do Kimi é a headless suportada?

Respondidas 0 / 3 · 0 corretas
Seu agente é seu professor. Quer ver uma delegação real — seu orquestrador fazendo o preflight dos agentes na sua máquina e entregando uma unidade a quem passou? Peça a ele para rodar o preflight e despachar uma única unidade delimitada, depois validá-la com um agente diferente. A seguir, mantemos mais de um assistente em jogo ao mesmo tempo e julgamos suas respostas: fusion: do painel ao juiz.