Arquitetura de Agentes de IA: Roteamento de Modelos e Descoberta de Ferramentas

Conectar um LLM é suficiente para fazer um aplicativo gerar texto. Não é suficiente para fazer um agente de IA completar uma tarefa do mundo real.

Peça a um modelo para resumir um documento já em seu contexto, e a camada do modelo é suficiente. Peça para comparar os preços dos concorrentes de hoje, enriquecer um registro de empresa, verificar uma conta social ou escolher a melhor API para um trabalho desconhecido, e a metade que falta se torna óbvia: o agente precisa de uma maneira confiável de acessar sistemas externos.

Um agente de produção, portanto, toma duas decisões separadas:

1. Qual modelo deve lidar com esta etapa?
2. Qual ferramenta ou API deve fornecer os dados ou a ação?

AIHubMix aborda a primeira decisão com acesso unificado ao modelo e roteamento de modelo em tempo de solicitação. Monid aborda a segunda com descoberta de ferramentas em tempo de execução, inspeção de esquema e execução por chamada. Os produtos estão em diferentes camadas da mesma arquitetura.

Divulgação: Este artigo foi criado como parte de uma colaboração de conteúdo com a Monid. AIHubMix é a plataforma de modelo discutida abaixo; Monid é a plataforma de ferramentas. Cada uma pode ser usada de forma independente.

Os dois problemas de roteamento dentro de um agente de IA

Uma execução de agente raramente é uma chamada homogênea de modelo. Um agente de pesquisa pode classificar uma solicitação, buscar informações atuais, extrair fatos estruturados, comparar resultados e escrever uma resposta final. Essas etapas requerem diferentes capacidades.

O mesmo é verdade fora do modelo. Uma tarefa de pesquisa de empresa pode precisar de uma API de busca hoje, um endpoint de enriquecimento de empresa amanhã e uma ferramenta de automação de navegador na próxima semana. Se cada modelo e ferramenta estiver codificado de forma rígida no momento da construção, cada nova tarefa se torna um projeto de integração.

As duas camadas são paralelas:

Essa separação é importante. Um modelo melhor não pode criar acesso a dados ao vivo, e um catálogo de ferramentas maior não pode raciocinar sobre os dados que retorna. O agente precisa de ambas as capacidades, com um contrato claro entre elas.

Monid apresenta a visão complementar do lado da ferramenta em Por que um Agente de IA Precisa de Duas Integrações. Do lado do modelo, a lição arquitetônica é a mesma: mantenha a seleção de modelo e a seleção de ferramenta independentes, e então otimize cada camada para seu próprio trabalho.

Por que um modelo fixo se torna caro em um loop de agente

Usar um modelo em todos os lugares parece simples. Na prática, força cada etapa a aceitar o mesmo compromisso entre capacidade, latência e preço.

Considere um agente de pesquisa de mercado:

• A classificação de intenção é curta e mecânica.
• A seleção de ferramenta precisa de seguimento de instruções confiável.
• Extrair campos de JSON retornado é principalmente transformação.
• O relatório final pode exigir raciocínio mais forte e melhor redação.

Enviar todas as quatro etapas para o modelo mais capaz desperdiça dinheiro em trabalho rotineiro. Enviar todas as quatro para o modelo mais barato pode reduzir a qualidade da única saída que o usuário lê. À medida que um loop de agente cresce, esse compromisso é repetido em cada chamada.

AIHubMix fornece um endpoint compatível com OpenAI em um amplo catálogo de modelos. Uma integração existente do SDK da OpenAI pode apontar para AIHubMix alterando a chave da API e base_url:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto:balanced",
    messages=[
        {"role": "user", "content": "Classifique esta solicitação e proponha o próximo passo."}
    ],
)

Definir model como auto move a seleção de modelo para o caminho da solicitação. O roteador analisa a tarefa e a resolve para um modelo adequado. Um sufixo de política torna o objetivo de otimização explícito:

O roteamento não adiciona uma taxa separada. A solicitação é cobrada pelo preço de tabela do modelo que realmente a manipulou. O modelo resolvido e os detalhes de roteamento são expostos na resposta, incluindo o cabeçalho X-Aihubmix-Router-Resolved-Model, para que a decisão permaneça observável em vez de se tornar uma caixa-preta.

O comportamento completo, os endpoints suportados, as políticas e as limitações atuais estão documentados no guia do AIHubMix LLM Router.

O roteamento de modelo não fornece dados ao vivo a um agente

Depois que o roteamento de modelo é configurado, o agente pode escolher um cérebro melhor para cada etapa. Ele ainda não pode saber o que mudou após os dados de treinamento do modelo, acessar um sistema de negócios privado ou realizar uma ação em outro aplicativo, a menos que uma ferramenta forneça essa capacidade.

É aqui que muitos projetos de agentes acumulam código frágil. Uma equipe conecta uma API de busca, depois uma API de scraping, depois uma API de enriquecimento. Cada integração introduz outra conta, credencial, formato de solicitação, modelo de erro e relacionamento de faturamento. As descrições das ferramentas são frequentemente copiadas para um prompt do sistema e lentamente se tornam obsoletas.

O modo de falha é perigoso porque pode parecer bem-sucedido. Um modelo pode produzir uma chamada plausível contra um esquema desatualizado, receber uma resposta incompleta e continuar como se a tarefa tivesse sido concluída com sucesso. A inspeção de esquema em tempo de execução é mais segura do que pedir ao modelo para lembrar um contrato de API do treinamento ou de um prompt antigo.

A camada de ferramentas deve, portanto, responder a três perguntas antes da execução:

1. Que ferramenta pode satisfazer este objetivo?
2. Que esquema e preço se aplicam agora?
3. Que resultado a chamada realmente retornou?

A descoberta de ferramentas é a segunda camada de roteamento

Monid transforma o acesso a ferramentas em um fluxo de trabalho de descobrir-inspecionar-executar. Em vez de exigir que o desenvolvedor preveja cada API que um agente pode precisar, o agente pode pesquisar um catálogo em linguagem natural, inspecionar o contrato de um candidato e executar o endpoint selecionado.

O fluxo básico é assim:

# 1. Encontrar ferramentas que correspondam ao objetivo
monid discover -q "encontrar preços atuais de produtos em uma página da web pública"

# 2. Ler o esquema e o preço do endpoint selecionado
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. Executar somente após o agente ter verificado o contrato
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

A descoberta e a inspeção permitem que o agente compare opções antes de gastar qualquer coisa. A execução é cobrada de acordo com o modelo de preços do endpoint selecionado. O desenvolvedor mantém uma integração enquanto o agente ganha acesso a ferramentas de vários provedores.

Para tempos de execução de agentes que podem ler instruções de configuração, a Monid também publica uma habilidade legível por máquina:

Configurar https://monid.ai/SKILL.md

A documentação do fluxo de trabalho da Monid explica as etapas de catálogo, inspeção e execução em mais detalhes.

Como as duas camadas trabalham juntas

O gateway do modelo e a camada de ferramentas devem permanecer componentes separados com uma pequena transferência explícita:

1. O agente recebe um objetivo do usuário.
2. AIHubMix roteia uma chamada de planejamento para um modelo apropriado.
3. O plano identifica informações ausentes ou uma ação externa necessária.
4. Monid descobre ferramentas candidatas e expõe seus esquemas e preços.
5. O agente seleciona e executa uma ferramenta dentro de suas permissões e orçamento.
6. A ferramenta retorna fatos ou um resultado de ação.
7. AIHubMix roteia a chamada de síntese de acordo com a qualidade, custo ou latência exigidos.
8. O agente retorna uma resposta fundamentada no resultado da ferramenta.

Em Python simplificado, as chamadas do lado do modelo podem permanecer inalteradas enquanto o resultado da ferramenta é inserido como contexto:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# Um modelo rápido é suficiente para uma etapa de planejamento leve.
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "Planeje como comparar os preços atuais desses produtos.",
        }
    ],
)

# Seu agente usa Monid para descobrir, inspecionar e executar uma ferramenta apropriada.
# Substitua esses espaços reservados pelo resultado estruturado retornado por essa chamada.
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "Escreva uma comparação concisa. Use apenas o resultado da ferramenta fornecido, "
                "preserve URLs de origem e declare quando um valor estiver ausente."
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

O detalhe importante não é o número de linhas. É que nenhuma das escolhas precisa ser permanentemente incorporada na lógica do aplicativo. O modelo pode mudar à medida que o prompt muda, e a ferramenta pode mudar à medida que a tarefa muda.

Controles de custo pertencem a ambas as camadas

Os custos de modelo e ferramenta usam unidades diferentes, portanto, devem ser medidos separadamente.

Na camada do modelo, o modelo resolvido determina o preço dos tokens. AIHubMix torna essa decisão rastreável e permite que os desenvolvedores escolham uma política de roteamento ou restrinjam os modelos que uma chave de API pode usar. Etapas rotineiras podem favorecer custo ou latência, enquanto saídas voltadas para o usuário podem favorecer qualidade.

Na camada da ferramenta, um endpoint pode cobrar por chamada ou por resultado. Monid expõe preços durante a inspeção, antes da execução. Um agente pode rejeitar um endpoint que exceda seu orçamento, preferir uma opção verificada ou pedir aprovação antes de uma operação incomumente cara.

Controles de produção úteis incluem:

• Uma lista de permissão de modelos ou teto de preço para cada chave de API.
• Um orçamento máximo de chamadas de ferramenta por tarefa.
• Listas de permissão de provedores ou endpoints para dados regulamentados.
• Registros que conectam a decisão de roteamento do modelo à chamada da ferramenta e à resposta final.
• Confirmação explícita antes de ações irreversíveis ou sensíveis.
• Validação de saída para que os dados da ferramenta sejam tratados como entrada não confiável, não como instruções.

Essa divisão também facilita a depuração de custos. Se uma execução se tornar cara, os registros de tokens mostram se o agente raciocinou demais, enquanto os registros de ferramentas mostram se ele buscou demais. As correções são diferentes, e a arquitetura deve preservar essa distinção.

A confiabilidade requer contratos atualizados e decisões visíveis

A seleção dinâmica não deve significar comportamento imprevisível.

Do lado do modelo, AIHubMix relata o modelo resolvido e a política de roteamento para cada solicitação. A aderência à sessão pode preservar a consistência do modelo e os benefícios do cache de prompt em trabalhos de múltiplas turnos, enquanto o comportamento de fallback pode se afastar de um modelo não saudável quando necessário.

Do lado da ferramenta, o agente inspeciona o esquema do endpoint atual antes de fazer uma chamada paga. Os resultados da descoberta incluem as informações necessárias para comparar candidatos, e o resultado da chamada real se torna a única evidência externa passada para a conclusão final.

Juntas, essas controles criam uma trilha de auditoria útil:

objetivo do usuário
  -> decisão de roteamento e modelo resolvido
  -> ferramentas candidatas descobertas
  -> esquema e preço inspecionados
  -> endpoint selecionado e resultado
  -> decisão final do modelo e resposta fundamentada

Essa trilha é mais valiosa do que simplesmente ter acesso a muitos modelos ou muitas APIs. Ela explica por que o agente fez cada escolha e quais evidências apoiaram sua resposta.

Quando você não precisa de ambas as camadas

Nem todo fluxo de trabalho se beneficia da escolha em tempo de execução.

Se um aplicativo enviar um prompt estável para um modelo avaliado, especificar esse modelo diretamente é mais simples e mais determinístico do que o roteamento. Se um pipeline agendado sempre chamar uma API conhecida, integrar essa API diretamente pode ser mais claro do que adicionar uma camada de descoberta.

A arquitetura de duas camadas ganha seu lugar quando a variedade faz parte da carga de trabalho:

• Os prompts diferem o suficiente para que o melhor modelo mude a cada etapa.
• Os agentes fazem várias chamadas de modelo e precisam controlar o custo ou a latência cumulativa.
• As ferramentas necessárias não podem ser totalmente previstas no momento da construção.
• Os dados externos devem ser atuais e sua fonte deve ser visível.
• A equipe deseja adicionar capacidades sem adicionar uma nova integração de fornecedor para cada uma.

Use a camada de modelo, a camada de ferramenta ou ambas de acordo com as decisões que seu aplicativo realmente precisa tomar.

Construa o agente em torno de decisões, não de dependências

Um agente de IA em produção não é definido por quantos modelos ou APIs pode acessar. É definido por sua capacidade de escolher a capacidade certa para a etapa atual, operar dentro de um orçamento e explicar o que aconteceu.

AIHubMix dá ao agente um endpoint de modelo unificado e roteamento em tempo de solicitação com prioridades de custo, qualidade e latência. Monid fornece descoberta de ferramentas em tempo de execução, esquemas atuais, preços visíveis e execução entre provedores externos.

Uma camada decide como o agente pensa. A outra decide como ele descobre e age. Manter essas decisões separadas produz um agente que é mais fácil de estender, observar e controlar.

Comece com o início rápido do AIHubMix, depois conecte o lado da ferramenta através da Monid.

FAQ

O que é roteamento de modelo para agentes de IA?

O roteamento de modelo seleciona um modelo para cada solicitação com base em fatores como tipo de tarefa, capacidade, custo e latência. Com o AIHubMix, definir model como auto ou uma política como auto:quality_first permite a seleção em tempo de solicitação, preservando uma API compatível com OpenAI.

Por que um agente de IA precisa de ferramentas se o LLM já possui conhecimento?

Um LLM gera respostas a partir do contexto que recebe e do que aprendeu durante o treinamento. Ele não pode saber de forma confiável os preços atuais, consultar um banco de dados privado ou realizar uma ação externa sem uma ferramenta conectada. As ferramentas fornecem dados ao vivo e execução; o modelo planeja e interpreta o resultado.

Um gateway de modelo é o mesmo que um servidor MCP ou plataforma de ferramentas?

Não. Um gateway de modelo roteia solicitações de inferência para modelos. Servidores MCP e plataformas de ferramentas expõem capacidades externas a um agente. Eles resolvem problemas de integração complementares e podem ser usados juntos.

AIHubMix e Monid podem ser usados de forma independente?

Sim. AIHubMix pode roteirizar chamadas de modelo para aplicativos sem requisitos dinâmicos de ferramenta. Monid pode fornecer descoberta de ferramentas para agentes que usam outro provedor de modelo ou gateway. Usar ambos é útil quando um agente precisa de escolha em tempo de execução em ambas as camadas.

Como posso manter o roteamento automático auditável?

Registre o modelo resolvido, a política de roteamento, a ferramenta candidata, o preço inspecionado, o endpoint selecionado e o resultado retornado para cada tarefa. AIHubMix expõe detalhes de roteamento de modelo na resposta, enquanto a Monid separa descoberta e inspeção da execução para que a decisão da ferramenta possa ser registrada antes da chamada paga.