3.7.6 · Padrões de orquestração

Os cinco padrões, com caso SAP

Roteamento, com a conta

def rotear(chamado: str) -> str:
    triagem = client.messages.create(
        model="claude-haiku-4-5",       # barato: 1 dólar por milhão de entrada
        max_tokens=16,
        system="Responda apenas SIMPLES ou COMPLEXO.",
        messages=[{"role": "user", "content": chamado}],
    )
    nivel = next(b.text for b in triagem.content if b.type == "text").strip()
    modelo = "claude-haiku-4-5" if nivel == "SIMPLES" else "claude-opus-5"
    return responder(chamado, modelo=modelo)

A economia depende inteiramente da proporção. Se 70% dos chamados são simples, 70% do volume roda a um quinto do preço de entrada, e a triagem custa quase nada. Se a proporção for outra, o padrão pode não pagar — e descobrir isso é medição, não intuição: você já tem o dataset do módulo 3.6.3 para responder.

Um cuidado: o roteador é ele mesmo um classificador, e classificador erra. Rotear um chamado complexo para o modelo barato produz resposta ruim, e sua avaliação precisa medir o fluxo inteiro, não cada modelo em separado.

Paralelização

import asyncio
from anthropic import AsyncAnthropic

aclient = AsyncAnthropic()

async def analisar(ricefw):
    r = await aclient.messages.create(
        model="claude-opus-5",
        max_tokens=4000,
        messages=[{"role": "user", "content": f"Analise o risco de: {ricefw}"}],
    )
    return next(b.text for b in r.content if b.type == "text")

async def analisar_todos(lista):
    return await asyncio.gather(*(analisar(r) for r in lista))

Duas formas, com propósitos diferentes:

• Fatiamento — itens independentes, cada um com sua chamada. Ganho de tempo.
• Votação — a mesma entrada, com ângulos ou prompts diferentes, e agregação no fim. Ganho de cobertura. É a versão em código da segunda opinião fria da aula 3.4.3.

Orquestrador-trabalhadores: a distinção que importa

Se você sabe as subtarefas na hora de escrever, use paralelização — é mais simples, mais barata e o custo é estimável. O orquestrador só se justifica quando a decomposição depende da entrada.

Avaliador-otimizador

def gerar_com_revisao(spec, max_rodadas=3):
    saida = gerar(spec)
    for _ in range(max_rodadas):
        nota, criticas = avaliar(saida, RUBRICA)   # a rubrica do módulo 3.6.4
        if nota >= 4:
            return saida, nota
        saida = corrigir(saida, criticas)
    return saida, nota                              # devolve o melhor obtido, com a nota

Três detalhes que fazem esse padrão funcionar em produção:

• Teto de rodadas. Sem ele, o laço pode não terminar.
• Critério de parada explícito. "Até ficar bom" não é critério; nota >= 4 é.
• Devolver a nota junto. Se saiu do laço por esgotar rodadas, quem consome precisa saber.

E a ligação com o módulo 3.6 é literal: RUBRICA é o mesmo texto do grader da aula 3.6.4. Escrever a rubrica uma vez serve para duas coisas — medir a qualidade e corrigi-la dentro do laço.

Regra Wayon Todo padrão com laço — avaliador-otimizador, orquestrador — roda com teto de iterações e teto de gasto por execução, declarados no código, não no combinado. E antes de subir de padrão, é preciso mostrar com a avaliação do módulo 3.6 que a versão mais simples não atende. Complexidade de orquestração é custo de sustentação que a Wayon paga por anos.

📖 Building effective agents · Graders — aula 3.6.4