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 intenção, mantém estado, decide quando recuperar ou agir e expõe detalhes suficientes de tempo de execução para depurar falhas.

Essa visão de 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 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 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 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 coberto em profundidade por Geração Aumentada por Recuperação (RAG) — e tanto a orientação de contexto da Anthropic quanto o papel “Lost in the Middle” (Perdido no Meio) alertam que apenas enfiar mais tokens no contexto não garante uma recuperação confiável.

O uso de ferramentas é uma fronteira de contrato, 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 tempo de execução a executa e o resultado flui de volta para a conversa. Se essa fronteira for descuidada, o assistente se torna descuidado.

Meu viés é simples: comece algo 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ê puder explicar seus casos de falha de 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 ao combinar 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 Responses API 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 dã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 do rastreamento

Esse contrato importa porque toda discrepâ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 rastreamentos como o caminho de uma solicitação através de uma aplicação, que é exatamente a abstração de que assistentes sérios precisam. O LangSmith e o 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 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 tempo de execução 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 Responses API da OpenAI é explicitamente projetada para interações com estado, além de ferramentas integradas e chamada de funções. A API de Mensagens da Anthropic expõe o mesmo loop principal 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 sozinho. Tempos de execução auto-hospedados como vLLM e llama.cpp importam porque preservam interfaces familiares estilo provedor, 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 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 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 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 ferramentas é um contrato entre sua aplicação 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 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 tenant, 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 isolamento de canal e agente, enquanto o Hermes o estende para baixo em 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 a arquitetura de se tornar lenda urbana. O OpenTelemetry fornece a abstração de rastreamento. O LangSmith fornece visibilidade ponta a ponta sobre etapas de aplicações LLM e suporta formatos de implantação em nuvem, híbridos e auto-hospedados. O OpenLIT oferece 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, rastreamentos 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 rastreamento por solicitação, não tem span por chamada de modelo e não tem histórico de eventos para execução de ferramentas, você realmente não tem uma arquitetura ainda. Você tem vibes.

Capturar, enriquecer, responder

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

A etapa de captura geralmente é mais importante do que parece. Tanto o OpenClaw quanto o 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 você a voltará como middleware ad hoc de qualquer maneira.

A etapa de enriquecimento é onde os sistemas maduros divergem de demonstrações de 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 mais longe, dividindo 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 roubar: 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 pode responder diretamente, ele faz. Se precisar de uma ferramenta, 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 importa arquiteturalmente é que as saídas agora incluem linguagem e fluxo de controle. Seu objeto de resposta é parcialmente prosa e parcialmente plano de tempo de execução.

A etapa de registro é onde as semânticas de consistência aparecem. O Pinecone separa caminhos de gravação e leitura e processa gravações após confirmação 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 gravações não aparecem automaticamente no prompt da sessão atual. O sistema Dreaming do OpenClaw apenas 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-gravação 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 ao redor 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 Dreaming. O Hermes documenta um gateway de mensagens, um loop central AIAgent, slots de modelo principais e auxiliares, memória integrada e integração nativa MCP.

Minha leitura ligeiramente opinativa é 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 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 stack híbrida prática inspirada por ambos os sistemas parece assim:

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: sistema de arquivos, navegador, 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 stack é um padrão de implantação raciocinado 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 compensações

Existem alguns padrões de assistente repetíveis que valem a pena nomear. Um assistente gerenciado mantém a maior parte do tempo de execução dentro das APIs do provedor. 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 suportam versões desses padrões, mesmo que os nomeiem diferentemente.

O padrão de malha de especialistas cresce para uma disciplina de engenharia distinta à medida que o número de agentes aumenta. Para os seis padrões canônicos de coordenação — orquestrador-trabalhador, pipeline sequencial, fan-out, hierárquico, enxame e malha — com modos de falha específicos e um framework de decisão de produção, veja Padrões de Orquestração Multi-Agente.

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

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 todos 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 vetores e índices invertidos com múltiplos tipos de índice vetorial. O pgvector adiciona busca exata e aproximada de vizinhos mais próximos ao Postgres. O Milvus se posiciona como um banco de dados vetorial de alta performance e escalável 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 de Mensagens e o contrato de uso de ferramentas separadamente dos Agentes Gerenciados. O vLLM expõe um servidor compatível com OpenAI mais suporte à API de Mensagens Anthropic. O Ollama documenta fluxos de trabalho de embedding e modelo local. O llama.cpp documenta rotas de chat, respostas e embeddings compatíveis com OpenAI, além de conclusões de chat compatíveis com Anthropic.

Esta matriz de compensações é 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 caminhos de gravação 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 ao modelo, o priva do contexto certo, deixa as ferramentas desviar 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 é uma fronteira de contrato. Os Guardrails da OpenAI incluem 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 a orientação de contexto da Anthropic reforçam a mesma lição operacional: mais tokens não removem a necessidade de curadoria de contexto.

A stack de mitigação preferida poderia ser chata e repetitiva: rastreie cada solicitação, version prompts, avalie a recuperação independentemente, mantenha ferramentas idempotentes e execute 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 aprofundar, aqui estã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, Usando Ferramentas, Recuperação, Busca de Arquivos, Evals e MCP para servidores de ferramentas remotos.

• 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 eles explicam hosts, clientes, servidores, ferramentas, prompts, recursos, transportes e negociação de capacidades de forma limpa. Para uma comparação prática do MCP com o protocolo Agent2Agent e quando um sistema multi-agente precisa de ambas as camadas, veja A2A vs MCP: Agentes de IA Realmente Precisam de Ambos os Protocolos? e para os próprios conceitos do A2A — Agent Cards, ciclo de vida de tarefas, mensagens, partes e artefatos — veja O que é o Protocolo A2A? Agent Cards e Tarefas Explicados.

• Assistentes de background e proativos: a camada de ferramentas é apenas uma parte de como os assistentes agem. Para saber como fazer um assistente observar, decidir e agir por conta própria — agendadores, trabalhadores baseados em filas, protocolos de reivindicação, fluxos de trabalho duráveis e polling semântico — veja Agentes de Polling em Assistentes de IA: 11 Padrões de Implementação.

• Protocolo A2A e adoção: uma vez que os agentes são implantados independentemente e precisam colaborar através de limites de propriedade, o A2A torna-se relevante. Para uma visão prática de 2026 de onde o A2A realmente tem tração, as questões de segurança que levanta e um framework de decisão para quando adotá-lo, veja Protocolo Google A2A em 2026: Adoção, Hype e Realidade. Quando esses agentes trocam tarefas de longa duração em vez de turnos de chat únicos, Streaming A2A e Tarefas Assíncronas para Fluxos de Trabalho de Agentes de Longa Duração cobre SSE, push e design input_required na fronteira do protocolo.

• 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: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle e SelfCheckGPT.