Desenho de agent harness: escolher o modelo certo

Model routing é um controlo operacional, não uma competição de benchmarks. Privacidade e residência delimitam primeiro o pool admissível; sucesso e qualidade escolhem as rotas válidas; tokens, latência e custo só são otimizados depois. Modelos locais exigem frequentemente mais decomposição, retrieval e verificação determinística.

O harness é a unidade produtiva

Um agente enterprise combina intake, contexto, policy gates, modelo, ferramentas, estado, verificação, retry, observabilidade e escalamento. O modelo é substituível. Escolhemos uma rota admissível que alcança um estado de negócio verificado. Uma camada operacional por threads preserva routing, estado, autoridade e evidência quando muda o executor.

Gate um: privacidade, residência e admissibilidade contratual

O perfil cobre classe de dados, regiões, retenção, logging, training, subprocessadores, encriptação, identidade, auditoria, direitos de produção e documentos recuperados. Rotas não conformes são excluídas antes da qualidade. Residência inclui temporários, índices, traces, revisão e backups. Remover um nome mantendo identificadores não anonimiza. O gate cria opções permitidas, não um vencedor.

Gate dois: sucesso da tarefa, depois qualidade

Sucesso é uma resposta suportada por fontes resolúveis, um registo válido ligado à origem ou uma ação aprovada com readback. Prosa elegante com schema inválido, ferramenta proibida ou evidência ausente falha. Testamos casos frequentes, limites, dados contraditórios, falhas, injection, escalamento obrigatório e variação linguística. Schema, autoridade, evidência e abstention precedem estilo. As skills por domínio estabilizam estes controlos.

Gate três: tokens, latência e custo

Medimos custo por tarefa verificada, não preço por token.

Dimensão	Medida do harness
Sucesso	conclusões verificadas por tentativa admissível
Qualidade	first-pass, gravidade e escape rate
Tokens	input, cache, output e retry por conclusão
Latência	mediana e cauda até ao estado verificado
Custo	inferência, retrieval, ferramentas, revisão e retrabalho
Estabilidade	variação temporal, de formato e classe

A rota atual é Baseline = 100. Uma alternativa mais barata só serve se não degradar sucesso, exceções ou tempo de revisão.

Encaminhar tarefas, não utilizadores

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

Classe, residência e autoridade são determinísticas; a incerteza escolhe a rota mais segura. O recibo guarda policy, modelo, prompt ou skill, fontes, tool calls, verificadores e estado final.

Porque os modelos locais precisam de outro harness

Oferecem controlo e custo previsível, mas podem ser menos consistentes em instruções, ferramentas, contexto longo e idiomas.

Decompor mais

Separar seleção, extração, classificação, redação e verificação, com contratos estreitos e checkpoints.

Recuperar menos e melhor

Um repositório inteiro não é retrieval. Índices, filtros, freshness e pacotes curtos reduzem ruído. Um assistente local com retrieval e pesquisa web mostra o valor da camada de evidência.

Verificar deterministicamente

Schemas, parsers, allow-lists, constraints, cálculos, policy engines e readback verificam campos, IDs, totais, permissões e estado final. A mesma chamada não deve gerar, avaliar e aprovar.

Cascatas, fallbacks e abstention

A cascata começa pela rota qualificada mais económica e escala em schema inválido, evidência ausente, conflito, ferramenta indisponível, policy gate ou falha do verificador. Fallback não contorna residência ou autoridade nem finge uma ação. Recusar ou escalar corretamente conta como sucesso quando o contrato o exige.

Estado, versões e reprodutibilidade

Versionamos tarefa, policy, fornecedor, região, modelo, prompt, skill, tool schema, retrieval, fontes, freshness, parâmetros, verificadores, retry, revisão, ação e readback. Reprodutibilidade vem de inputs, configuração, ações e provas, não de raciocínio ilimitado. O ajuste de um agente específico de projeto exige mudanças e falhas observáveis.

Um processo prático de seleção

1. Definir classes. 2. Aplicar gates. 3. Construir casos representativos e adversariais. 4. Testar no harness real. 5. Excluir falhas duras. 6. Avaliar sucesso e qualidade. 7. Medir eficiência total. 8. Pilotar em shadow ou dry-run. 9. Aprovar por classe. 10. Reavaliar mudanças e drift.

A regra de decisão

Privacidade, residência e contrato determinam o permitido. Sucesso verificado e qualidade determinam o capaz. Tokens, latência e custo total determinam o eficiente. A escolha certa é o menor sistema admissível que conclui a tarefa dentro do limite e comprova o resultado.

Insights relacionados

• Arquitetura de uma camada operacional de IA por threads — routing, estado, autoridade e verificação
• Skills de agentes para workflows de domínio — procedimentos e controlos especializados
• Assistente local com pesquisa web e retrieval — inferência local, evidência e ferramentas