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

Um assistente de IA em produção não é “um LLM com um prompt”. É um sistema que aceita a intenção, mantém o estado, decide quando recuperar informações ou agir e expõe detalhes suficientes da 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 aplicativos que planejam, chamam ferramentas, colaboram e mantêm estado suficiente para trabalhos 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 runtimes 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”. Os 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 artigo “Lost in the Middle” (Perdido no Meio) alertam que apenas empilhar mais tokens no contexto não garante recuperação confiável.

O uso de ferramentas é uma fronteira contratual, não mágica. A chamada de função da OpenAI, o uso de ferramentas da Anthropic e o MCP dependem todos do mesmo padrão: o modelo emite uma solicitação estruturada, algum runtime a executa e o resultado flui de volta para a conversa. Se essa fronteira for negligente, o assistente se torna negligente.

Meu viés é simples: comece com o básico. Um orquestrador, um caminho de memória durável, um rastreamento 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ê conseguir 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 runtime 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. OpenClaw e Hermes vão um passo adiante e mostram o que acontece quando você coloca essas capacidades atrás de gateways persistentes, canais, sessões e memória.

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 rastreamento

Esse contrato importa 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 rastreamento diz que o sistema gastou tempo. O OpenTelemetry define traces (rastreamentos) como o caminho de uma solicitação através de um aplicativo, que é exatamente a abstração que assistentes sérios precisam. LangSmith e OpenLIT então especializam 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 encontro mais durável. É também a divisão que melhor se alinha com as APIs oficiais e os runtimes 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 retries e rastreamento. A API Responses da OpenAI é projetada explicitamente para interações com estado, mais 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 fornecem uma estrutura hospedada se você não quiser construir o loop você mesmo. Runtimes auto-hospedados como vLLM e llama.cpp importam 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 Busca de Arquivos da OpenAI então camadam busca semântica e por palavras-chave sobre as lojas vetoriais. Pinecone, Weaviate, pgvector e Milvus representam quatro formas comuns de armazenamento: 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 apoiadas em arquivos, promoções revisadas e snapshots escopados à sessão são frequentemente o design mais honesto. Sistemas de Memória em Assistentes de IA mapeia o modelo entre frameworks; Sistema de Memória do Agente Hermes detalha a memória central limitada e snapshots de sessão congelados em um produto.

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 funcionalidade definida por esquema que o modelo pode decidir invocar. A Anthropic diz a mesma coisa de forma mais explícita: o uso de ferramenta é 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 — a mesma fronteira descrita passo a passo em Servidor MCP em Go. LangChain e LlamaIndex encaixam-se 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 tenant, qual orçamento, qual classe de latência e qual fallback?”. O LiteLLM é útil porque seus documentos oficiais são refrescantemente concretos: escolha 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 via de execução.

A camada de Observabilidade é o que impede a arquitetura de se transformar em lenda urbana. O OpenTelemetry dá a você a abstração de trace. O LangSmith dá visibilidade ponta a ponta sobre os passos de aplicativos LLM e suporta formas de implantação em nuvem, híbridas e auto-hospedadas. O OpenLIT dá observabilidade de IA nativa do OpenTelemetry com opções de instrumentação zero-code e manual, incluindo suporte para LLMs, frameworks de agentes, bancos de dados vetoriais e GPUs. Para métricas de produção, traces e padrões de SLO através de inferência e fluxos de trabalho de agentes, veja Observabilidade para Sistemas LLM. Se seu assistente não tem trace por solicitação, não tem span por chamada de modelo e não tem histórico de eventos para execução de ferramenta, você realmente não tem uma arquitetura ainda. Você tem “vibes” (sensações).

Capturar, enriquecer, responder

A sequência que continua aparecendo em sistemas reais é capturar -> enriquecer -> responder -> registrar. Diferentes frameworks embrulham isso de forma diferente, 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 como Ferramentas ou MCP
    participant O as Observabilidade

    U->>G: mensagem, arquivo ou comando
    G->>O: iniciar trace raiz
    G->>R: solicitação + identidade + sessão + política
    R->>M: carregar estado da sessão e recuperar contexto
    M-->>R: notas, chunks, metadados
    R->>L: prompt + contexto + esquemas de ferramenta
    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

O passo de captura é geralmente mais importante do que parece. OpenClaw e Hermes colocam ambos um gateway persistente na frente do assistente porque o ingress não é apenas entrada de texto. Ele 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 cru, eventualmente você terá que reanexá-la como middleware ad hoc de qualquer maneira.

O passo de enriquecimento é onde sistemas maduros divergem de demonstrações brinquedo. A Recuperação e Busca de Arquivos da OpenAI tornam a recuperação explícita através de lojas vetoriais e chamadas de busca. O LlamaIndex formaliza o mesmo padrão através de conectores de dados, índices, motores de consulta e fluxos de trabalho. O Hermes vai além ao dividir o parque de modelos em slots principais e auxiliares, delegando trabalho como compressão, sumarização e roteamento para modelos menores ou mais especializados. Esse é um padrão de design que vale a pena roubar: não gaste os tokens do seu modelo mais caro com tarefas rotineiras.

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

O passo de registro é onde as semânticas de consistência aparecem. O Pinecone separa os caminhos de escrita e leitura e processa as escritas após o reconhecimento durável. A memória do Hermes é injetada como um snapshot congelado por sessão para que possa preservar o desempenho do cache de prefixo, o que significa que novas escritas não aparecem automaticamente no prompt da sessão atual. O sistema Dreaming 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 através de 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 execução com gateways, sessões, ferramentas, memória e múltiplos backends de modelo.

Este mapeamento está 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 Dreaming. O Hermes documenta um gateway de mensagens, um loop central AIAgent, slots de modelo principais e auxiliares, memória integrada e integração MCP nativa.

Minha leitura ligeiramente opinada é que ambos os sistemas fazem o mesmo argumento arquitetural em sotaques diferentes. O OpenClaw é fortemente gateway-first. O Hermes é fortemente agent-loop-first. Mas ambos rejeitam a ideia rasa de que um assistente é apenas “prompt mais modelo”. Eles modelam canais, identidades, semânticas de memória, superfícies de ferramenta 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 isso:

edge:
  gateway: hermes ou openclaw

routing:
  proxy: litellm
  policy: ciente de latência e orçamento
  tenancy: escopo de 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: filesystem, browser, busca 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 fundamentado em vez de um blueprint prescrito por 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 rastrear todo o caminho.

Padrões, tabelas e tradeoffs

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 dos provedores. Um assistente focado em recuperação trata memória e busca 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 apoiam versões desses padrões, mesmo que os nomeiem de forma diferente.

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 individual.

Notas da tabela: A Busca 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 vários 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 exato e aproximado ao Postgres. O Milvus se posiciona como um banco de dados vetorial de alta performance e escalável de código aberto, com Zilliz Cloud como a opção gerenciada.

Notas da tabela: A OpenAI documenta Responses como sua interface avançada para respostas com estado e ferramentas integradas. A Anthropic documenta a API Messages e o contrato de uso de ferramenta 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 tradeoffs é uma inferência arquitetural 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 os caminhos de escrita e leitura, o Hermes congela a memória em 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 para o modelo, o priva do contexto correto, permite que as ferramentas se desviem ou torna a depuração impossível.

A base de evidências para esta tabela é ampla, mas consistente. Os documentos de ferramenta da Anthropic deixam claro que o uso de ferramenta é uma fronteira contratual. O OpenAI Guardrails inclui detecção de alucinação contra uma base de conhecimento de referência via Busca de Arquivos. O SelfCheckGPT mostra que a auto-consistência entre amostras pode ajudar a detectar afirmações sem suporte. 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.

O stack de mitigação preferido poderia ser entediante e repetitivo: trace cada solicitação, versionar prompts, avaliar a recuperação independentemente, manter ferramentas idempotentes e executar evals de regressão antes de mudar rotas ou política de memória. Os docs e repo de Evals da OpenAI são diretos sobre o porquê: sem evals, é 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 ir mais fundo, 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 Responses, Chamada de Função, Uso de Ferramentas, Recuperação, Busca de Arquivos, Evals e MCP para servidores de ferramenta remotos.

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

• O MCP em si: 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.

• Runtimes auto-hospedados e sistemas de assistente: vLLM, servidor llama.cpp, embeddings Ollama, documentos e repo OpenClaw, documentos e repo Hermes.

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

• Artigos de pesquisa: Geração Aumentada por Recuperação para Tarefas NLP Intensivas em Conhecimento, Perdido no Meio e SelfCheckGPT.