Um contrato, vários frameworks
Todo adaptador implementa `TriageRunner`, e um teste compartilhado roda cada um contra os mesmos casos.
Código: src/supportops_agents/contracts.py
Descartado: Comparar frameworks pelos próprios demos.
Orquestração multiagente
Triagem multiagente com laço limitado, comparada entre frameworks no mesmo contrato.
verificado offline, qualidade pendenteÚltima verificação: 2026-10-30 · Commit e9de403
Resumo
- Problema
- Demos de framework raramente mostram como manter contratos, retries, pausas de aprovação e término comparáveis.
- Meu papel
- Construí o supervisor, o contrato compartilhado e os adaptadores, e a contabilidade da operação live.
- Stack
- Python, LangGraph, CrewAI, AutoGen, LlamaIndex, Semantic Kernel
- Resultado
- Um workflow sintético live rodou com quatro tentativas ao provedor e 1274 in, 261 out tokens. Isso mostra que transporte e contabilidade funcionam. Não diz nada sobre qualidade de resposta.
Um supervisor delega para workers especialistas com estado compartilhado, limite rígido de passos e condições de parada explícitas. O mesmo ticket passa por vários adaptadores de framework atrás de um contrato `TriageRunner`, então a escolha de framework vira decisão medida, não preferência.
Veja rodando
O demo ao vivo roda este sistema contra um modelo real e mostra cada passo.
Como funciona
O fluxo inteiro. Aperte tocar ou próximo para percorrer.
Versão em texto deste diagrama
- Contrato TriageRunner P01. Todo adaptador de framework implementa o mesmo contrato.
- depois Supervisor
- Supervisor P01. Delega um passo por vez e é dono das condições de parada.
- depois Classificador
- Classificador P01. Define a categoria e se deve escalar.
- depois Pesquisador
- Pesquisador P01. Lê as fontes fornecidas.
- depois Agente de billing
- Agente de billing P01. Confere o lado financeiro.
- depois Responder
- Responder P01. Escreve a resposta e cita uma fonte.
- depois Condição de parada
- Condição de parada P01. Um limite rígido de passos encerra a execução, diga o que disser o modelo.
Decisões
A condição de parada pertence ao supervisor
Um limite rígido de passos encerra a execução seja o que for que um worker devolva, então um modelo em laço não estende o próprio orçamento.
Código: src/supportops_agents/core.py
Descartado: Confiar que o modelo diga que terminou.
Resultados
Medido
| Métrica | Valor | Modo | Fonte |
|---|---|---|---|
| Um workflow sintético live, quatro tentativas ao provedor (tokens) Só transporte e contabilidade. Nada sobre a qualidade da resposta. | 1274 in, 261 out | modelo real | docs/harness/progress.mdCommit 6c8e06d · 2026-10-30 · Exit code 0 |
Não medido, então não afirmado
- Qual framework é o melhor. A comparação roda offline sobre fixtures.
- Qualidade da resposta do workflow live.
Galeria de falhas
- O que aconteceu
- Uma chamada concluída sem uso informado trocava a reserva por zeros.
- Causa
- A contabilidade acumulada tratava uso desconhecido como nenhum uso.
- O que mudou
- Uso desconhecido mantém a reserva original, com teste de regressão.
- O que aconteceu
- Um adaptador antigo rodava para outra chave após uma falha transitória e contornava a contabilidade.
- Causa
- Ele criava os clientes do provedor em vez de usar a fronteira de recibos compartilhada.
- O que mudou
- Escrevi primeiro os testes vermelhos, depois movi o adaptador para trás da fronteira contabilizada.
Valide você mesmo
git clone https://github.com/DiegoVSouza/supportops-agents.git
cd supportops-agents
uv sync --locked --all-groups && uv run --locked python scripts/check_fast.pyEsperado: A suíte offline passa. Um teste que compara com um módulo exclusivo do lab é pulado, com o motivo impresso, fora do lab.
O que eu faria diferente
Eu escreveria a condição de parada como um módulo pequeno e separado, com testes próprios, antes de escrever qualquer worker.