Arquitetura de Assistente de IA: LLM, Memória, Ferramentas, Roteamento, Observabilidade

Um assistente de IA de produção não é “um LLM com um prompt”. É um sistema que aceita a intenção do usuário, mantém estado, decide quando recuperar informações ou agir e expõe detalhes suficientes de tempo de execução para depurar falhas.

Essa visão em nível de sistema é o que o cluster de Sistemas de IA explora quando os assistentes vão além de uma única invocação de modelo.

A OpenAI descreve agentes como aplicações que planejam, chamam ferramentas, colaboram e mantêm estado suficiente para trabalho em múltiplos passos, enquanto a Anthropic enquadra o mesmo problema como uma estrutura gerenciada que pode executar arquivos, comandos, acesso à web e código de forma segura.

A arquitetura mais limpa divide as responsabilidades em cinco camadas: LLM, Memória, Ferramentas, Roteamento e Observabilidade. Essa divisão corresponde às capacidades expostas pelas APIs principais dos provedores, pelo MCP, por tempos de execução auto-hospedados como vLLM e llama.cpp, e por sistemas de assistentes reais como OpenClaw e Hermes.

A memória deve ser tratada como algo mais do que “contexto mais longo”. Sistemas de recuperação transformam conhecimento externo em memória não paramétrica explícita — o mesmo espaço de design abordado em profundidade por Geração Aumentada por Recuperação (RAG) — e tanto as diretrizes de contexto da Anthropic quanto o paper “Lost in the Middle” alertam que apenas enfiar mais tokens no contexto não garante uma recuperação confiável.

O uso de ferramentas é um limite de contrato, não magia. A chamada de função da OpenAI, o uso de ferramentas da Anthropic e o MCP baseiam-se no mesmo padrão: o modelo emite uma solicitação estruturada, algum tempo de execução a executa e o resultado retorna para a conversa. Se esse limite for negligente, o assistente torna-se negligente.

Meu viés é simples: comece com o básico. Um orquestrador, um caminho de memória durável, um traço por solicitação e uma política explícita para execução de ferramentas. Grafos multi-agente são úteis, mas apenas depois que você puder explicar os casos de falha do seu agente único sem adivinhar.

O que é um sistema de assistente de IA

Uma definição prática é esta: um sistema de assistente de IA é um tempo de execução que transforma a intenção do usuário em uma resposta ou ação, combinando uma interface de modelo, montagem de contexto, execução de ferramentas, gerenciamento de estado e telemetria. É por isso que os documentos úteis não são apenas fichas de modelo. Os documentos úteis são referências de API, contratos de ferramentas, guias de recuperação, documentos de roteamento e documentos de rastreamento. A API Responses da OpenAI expõe interações com estado, ferramentas integradas e chamada de funções. A API Claude da Anthropic expõe acesso direto a Mensagens, bem como Agentes Gerenciados. O OpenClaw e o Hermes vão um passo além e mostram o que acontece quando você coloca essas capacidades atrás de gateways, canais, sessões e memória persistentes.

Em outras palavras, um sistema de assistente tem um contrato mais amplo do que uma conclusão de chat. Um bom contrato interno parece algo assim:

AssistantRequest  = intenção do usuário + identidade + sessão + anexos + política
AssistantResponse = resposta + ações + citações + mudanças de estado + ID de traço

Esse contrato é importante porque toda divergência em produção eventualmente se reduz a uma dessas perguntas: qual contexto estava visível, qual ferramenta foi executada, qual modelo respondeu, qual memória foi lida ou gravada e onde o traço diz que o sistema passou o tempo. A OpenTelemetry define traços como o caminho de uma solicitação através de um aplicativo, que é exatamente a abstração de que assistentes sérios precisam. O LangSmith e o OpenLIT especializam então essa ideia para LLMs, ferramentas, lojas vetoriais e fluxos de trabalho de agentes.

Componentes principais e interfaces

A divisão de componentes abaixo é a que considero mais durável. Também é a divisão que melhor se alinha com as APIs oficiais e os tempos de execução de código aberto que as pessoas realmente operam.

A tabela acima é derivada das interfaces oficiais dos provedores, MCP, documentos de bancos de dados vetoriais e documentos de runtime para vLLM, llama.cpp, OpenClaw e Hermes.

A camada LLM deve fazer três coisas bem: consumir um contexto de trabalho atual, emitir uma resposta final ou uma solicitação de ação estruturada e retornar metadados suficientes para suportar retentativas e rastreamento. A API Responses da OpenAI é explicitamente projetada para interações com estado, bem como ferramentas integradas e chamada de funções. A API Messages da Anthropic expõe o mesmo loop central através de blocos tool_use e retornos tool_result, enquanto os Agentes Gerenciados oferecem uma estrutura hospedada se você não quiser construir o loop você mesmo. Tempos de execução auto-hospedados como vLLM e llama.cpp são importantes porque preservam interfaces estilo provedor familiares, permitindo que você coloque a inferência dentro do seu próprio ambiente.

A camada de Memória deve ser dividida mentalmente em três categorias: memória de trabalho, memória simbólica durável e memória semântica pesquisável. Os embeddings da OpenAI retornam vetores que podem ser indexados e pesquisados; a Recuperação e Pesquisa de Arquivos da OpenAI então camadam pesquisa semântica e de palavras-chave sobre lojas vetoriais. Pinecone, Weaviate, pgvector e Milvus representam quatro formatos de armazenamento comuns: totalmente gerenciado, vetor nativo de código aberto, nativo do Postgres e banco de dados vetorial distribuído. Hermes e OpenClaw adicionam um lembrete útil de que nem toda memória pertence a uma loja vetorial: notas baseadas em arquivos, promoções revisadas e instantâneos escopados à sessão são frequentemente o design mais honesto — padrões detalhados em Sistema de Memória do Agente Hermes para memória central limitada e instantâneos de sessão congelados.

A camada de Ferramentas é onde um assistente deixa de ser um resumidor e começa a ser software. A chamada de função da OpenAI trata as ferramentas como funcionalidades definidas por esquema que o modelo pode decidir invocar. A Anthropic diz a mesma coisa mais explicitamente: o uso de ferramentas é um contrato entre seu aplicativo e o modelo, e o modelo nunca executa nada por conta própria. O MCP generaliza esse contrato para um protocolo cliente-servidor onde hosts se conectam a um ou mais servidores que expõem ferramentas, prompts e recursos — o mesmo limite descrito passo a passo em Servidor MCP em Go. LangChain e LlamaIndex se encaixam confortavelmente aqui como bibliotecas de orquestração: o LangChain foca em uma arquitetura de agente pré-construída e integrações, enquanto o LlamaIndex foca em acesso a dados aumentados por contexto, motores de consulta e fluxos de trabalho.

A camada de Roteamento existe porque “qual modelo?” nunca é a única pergunta. Você também precisa de “qual caminho de provedor, qual inquilino, qual orçamento, qual classe de latência e qual fallback?”. O LiteLLM é útil porque seus documentos oficiais são refrescantemente concretos: seleção ponderada, menos ocupado, baseado em latência, baseado em custo e failovers limitados são todos padrões de primeira classe. O OpenClaw estende o roteamento para cima em direção ao isolamento de canal e agente, enquanto o Hermes o estende para baixo em direção a slots de modelo para trabalho principal e auxiliar, como sumarização, compressão de contexto e roteamento de ferramentas MCP. Esse é o modelo mental correto: o roteador escolhe mais do que um modelo, ele escolhe uma faixa de execução.

A camada de Observabilidade é o que impede que a arquitetura se transforme em folclore. A OpenTelemetry oferece a abstração de traço. O LangSmith oferece visibilidade ponta a ponta sobre as etapas da aplicação de LLM e suporta formatos de implantação em nuvem, híbridos e auto-hospedados. O OpenLIT oferece observabilidade de IA nativa da OpenTelemetry com opções de instrumentação zero-código e manual, incluindo suporte para LLMs, frameworks de agentes, bancos de dados vetoriais e GPUs. Para métricas de produção, traços e padrões de SLO em inferência e fluxos de trabalho de agentes, consulte Observabilidade para Sistemas de LLM. Se seu assistente não tem traço por solicitação, span por chamada de modelo e histórico de eventos para execução de ferramentas, você realmente não tem uma arquitetura ainda. Você tem apenas “vibes”.

Capturar, enriquecer, responder

A sequência que continua aparecendo em sistemas reais é capturar -> enriquecer -> responder -> registrar. Diferentes frameworks embrulham isso de maneiras diferentes, mas o fluxo é estável o suficiente para ser tratado como a espinha dorsal.

sequenceDiagram
    participant U as Usuário ou Canal
    participant G as Gateway ou UI
    participant R as Roteador
    participant M as Memória e Recuperação
    participant L as LLM
    participant T as Ferramentas ou MCP
    participant O as Observabilidade

    U->>G: mensagem, arquivo ou comando
    G->>O: iniciar traço raiz
    G->>R: solicitação + identidade + sessão + política
    R->>M: carregar estado da sessão e recuperar contexto
    M-->>R: notas, trechos, metadados
    R->>L: prompt + contexto + esquemas de ferramentas
    L-->>R: resposta ou chamada de ferramenta
    alt chamada de ferramenta
        R->>T: executar ferramenta ou ação MCP
        T-->>R: resultado da ferramenta
        R->>L: resultado da ferramenta + contexto atualizado
        L-->>R: resposta final
    end
    R->>M: persistir mudanças da sessão e candidatos de memória
    R->>O: spans, métricas, eventos de avaliação
    G-->>U: resposta

A etapa de captura é geralmente mais importante do que parece. Tanto OpenClaw quanto Hermes colocam um gateway persistente na frente do assistente porque o ingresso não é apenas entrada de texto. Inclui metadados de canal, identidades, autorização, limites de sessão, mensagens diretas, grupos, ticks cron e semânticas de entrega. Se você pular essa camada e depender de uma abstração de widget de chat bruto, eventualmente o reverterá como middleware ad hoc de qualquer forma.

A etapa de enriquecimento é onde sistemas maduros se separam de demos de brinquedo. A Recuperação e Pesquisa de Arquivos da OpenAI tornam a recuperação explícita através de lojas vetoriais e chamadas de pesquisa. O LlamaIndex formaliza o mesmo padrão através de conectores de dados, índices, motores de consulta e fluxos de trabalho. O Hermes vai mais longe ao dividir o patrimônio de modelos em slots principais e auxiliares, delegando trabalhos como compressão, sumarização e roteamento para modelos menores ou mais especializados. Esse é um padrão de design que vale a pena copiar: não gaste os tokens do seu modelo mais caro em tarefas domésticas.

A etapa de resposta não é “gerar texto”. É “fechar o loop atual”. Se o modelo puder responder diretamente, ele o faz. Se precisar de uma ferramenta, ele emite uma solicitação estruturada. O contrato de uso de ferramentas da Anthropic e o guia de chamada de função da OpenAI tornam isso explícito. A razão pela qual isso é importante arquitetonicamente é que as saídas agora incluem linguagem e fluxo de controle. Seu objeto de resposta é parcialmente prosa e parcialmente plano de runtime.

A etapa de registro é onde as semânticas de consistência aparecem. O Pinecone separa os caminhos de escrita e leitura e processa as gravações após o reconhecimento durável. A memória do Hermes é injetada como um instantâneo congelado por sessão para que possa preservar o desempenho do cache de prefixo, o que significa que novas gravações não aparecem automaticamente no prompt da sessão atual. O sistema de Sonho do OpenClaw só promove candidatos revisados e fundamentados para MEMORY.md, e é opt-in em vez de sempre ativo. A lição prática é que a memória raramente é verdadeiramente leitura-após-escrita em todas as camadas. Você precisa projetar para visibilidade em estágios.

OpenClaw e Hermes como sistemas de referência

OpenClaw e Hermes são casos de referência úteis porque não são apenas wrappers em torno de uma API de provedor. Ambos apresentam um assistente como um sistema de longa duração com gateways, sessões, ferramentas, memória e múltiplos backends de modelo.

Este mapeamento é fundamentado nos documentos e repositórios oficiais do OpenClaw e Hermes. O OpenClaw documenta uma arquitetura de gateway, roteamento multi-agente, suporte a provedores personalizados e auto-hospedados incluindo vLLM e Ollama, memória ativa opcional e promoção baseada em Sonho. O Hermes documenta um gateway de mensagens, um loop central AIAgent, slots de modelo principais e auxiliares, memória integrada e integração nativa com MCP.

Minha leitura ligeiramente opiniosa é que ambos os sistemas fazem o mesmo argumento arquitetônico em sotaques diferentes. O OpenClaw é fortemente gateway-first. O Hermes é fortemente agent-loop-first. Mas ambos rejeitam a ideia superficial de que um assistente é apenas “prompt mais modelo”. Eles modelam canais, identidades, semânticas de memória, superfícies de ferramentas e heterogeneidade de backend como preocupações de primeira classe. Isso é exatamente o que uma arquitetura de produção deve fazer.

Uma pilha híbrida prática inspirada por ambos os sistemas parece com isto:

edge:
  gateway: hermes ou openclaw

routing:
  proxy: litellm
  policy: ciente de latência e orçamento
  tenancy: escopado por sessão e canal

llm:
  primary: respostas openai ou mensagens anthropic
  local_fallback: vllm
  local_dev: ollama ou llama.cpp

memory:
  session: sqlite ou postgres
  semantic: pgvector ou weaviate
  embeddings: embeddings openai ou embeddings ollama

tools:
  contract: ferramentas de esquema json mais mcp
  examples: sistema de arquivos, navegador, pesquisa web, APIs internas

observability:
  traces: opentelemetry
  ai_dashboards: openlit ou langsmith
  evals: evals openai mais conjuntos de regressão específicos do app

Essa pilha é um padrão de implantação ponderado em vez de um blueprint prescrito por um fornecedor. Funciona porque as interfaces oficiais se alinham: OpenAI e Anthropic expõem APIs orientadas a ferramentas, vLLM e llama.cpp emulam endpoints estilo provedor, Ollama lida com modelos e embeddings locais, MCP padroniza ferramentas externas, LiteLLM lida com roteamento e failover, e plataformas compatíveis com OpenTelemetry podem traçar o caminho inteiro.

Padrões, tabelas e compensações

Existem alguns padrões de assistente repetíveis que valem a pena nomear. Um assistente gerenciado mantém a maior parte do runtime dentro das APIs do provedor. Um assistente focado em recuperação trata memória e pesquisa como o principal diferenciador. Um assistente focado em ferramentas se comporta mais como um operador do que como um chatbot. Um assistente de gateway prioriza acesso sempre ativo através de superfícies de mensagens. Uma malha de especialistas decompõe o trabalho em múltiplos agentes ou rotas. Documentos oficiais da OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw e Hermes suportam versões desses padrões, mesmo que os nomeiem diferentemente.

Esta tabela de padrões é uma síntese dos documentos dos provedores, documentos de frameworks e sistemas de referência, em vez de uma reivindicação de qualquer fornecedor único.

Notas da tabela: A Pesquisa de Arquivos hospedada da OpenAI é uma ferramenta gerenciada, a Anthropic oferece uma estrutura gerenciada, o Pinecone é um serviço vetorial gerenciado, enquanto vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith auto-hospedado e OpenLIT suportam operação auto-gerenciada ou híbrida em diversos graus.

Notas da tabela: O Pinecone documenta um plano de controle gerenciado e planos de dados regionais. O Weaviate documenta índices vetoriais e invertidos com múltiplos tipos de índice vetorial. O pgvector adiciona busca de vizinho mais próximo exata e aproximada ao Postgres. O Milvus se posiciona como um banco de dados vetorial de alto desempenho, escalável e de código aberto, com o Zilliz Cloud como a opção gerenciada.

Notas da tabela: A OpenAI documenta Respostas como sua interface avançada para respostas com estado e ferramentas integradas. A Anthropic documenta a API Messages e o contrato de uso de ferramentas separadamente dos Agentes Gerenciados. O vLLM expõe um servidor compatível com OpenAI mais suporte à API Messages da Anthropic. O Ollama documenta fluxos de trabalho de embedding e modelo locais. O llama.cpp documenta rotas de chat, respostas e embeddings compatíveis com OpenAI, mais conclusões de chat compatíveis com Anthropic.

Esta matriz de compensações é uma inferência arquitetônica dos documentos oficiais, não um benchmark de fornecedor. A linha de consistência importa mais do que muitos posts de blog admitem: o Pinecone separa caminhos de escrita e leitura, o Hermes congela a memória nos prompts de início de sessão e o OpenClaw promove memória durável através de revisão em estágios. Isso significa que “memória atualizada” e “memória visível para a resposta atual” são frequentemente verdades diferentes.

Modos de falha e mitigações

A maioria dos assistentes não falha porque o modelo base é “ruim”. Eles falham porque o sistema ao redor mente ao modelo, o priva do contexto correto, deixa as ferramentas desviarem ou torna a depuração impossível.

A base de evidências para esta tabela é ampla, mas consistente. Os documentos de ferramentas da Anthropic deixam claro que o uso de ferramentas é um limite de contrato. Os Guardrails da OpenAI incluem detecção de alucinação contra uma base de conhecimento de referência via Pesquisa de Arquivos. O SelfCheckGPT mostra que a auto-consistência entre amostras pode ajudar a detectar afirmações não suportadas. Os resultados de “Lost in the Middle” e as diretrizes de contexto da Anthropic reforçam a mesma lição operacional: mais tokens não removem a necessidade de curadoria de contexto.

A pilha de mitigação preferida poderia ser chata e repetitiva: trace cada solicitação, versionar prompts, avaliar a recuperação independentemente, manter as ferramentas idempotentes e executar avaliações de regressão antes de mudar rotas ou política de memória. Os documentos e repositório de Evals da OpenAI são diretos sobre o porquê: sem avaliações, é difícil e demorado entender como mudanças de modelo ou prompt afetam seu caso de uso. Isso se aplica tanto a roteadores e recuperação quanto a prompts.

Mais leituras

Se você quiser se aprofundar, estas são as fontes primárias mais úteis para manter abertas enquanto projeta ou revisa uma arquitetura de assistente.

• OpenAI: Visão Geral de Respostas, Chamada de Função, Uso de Ferramentas, Recuperação, Pesquisa de Arquivos, Evals e MCP para servidores de ferramentas remotas.

• Anthropic: Visão Geral da API, Uso de Ferramentas, o contrato de uso de ferramentas, Agentes Gerenciados, Janelas de Contexto e o conector MCP.

• O próprio MCP: a Visão Geral da Arquitetura e a Especificação valem a pena ler diretamente, porque explicam hosts, clientes, servidores, ferramentas, prompts, recursos, transportes e negociação de capacidades de forma limpa.

• Frameworks e roteamento: Visão Geral do LangChain, documentos de aumento de contexto do LlamaIndex, documentos de roteamento do LiteLLM, documentos de observabilidade do LangSmith.

• Tempos de execução auto-hospedados e sistemas de assistentes: vLLM, servidor llama.cpp, embeddings Ollama, documentos e repositório OpenClaw, documentos e repositório Hermes.

• Armazenamento e observabilidade: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Papers de pesquisa: Geração Aumentada por Recuperação para Tarefas de NLP Intensivas em Conhecimento, Lost in the Middle e SelfCheckGPT.