Arkitektur för AI-assistent: LLM, minne, verktyg, routing, observabilitet

Ett produktionsberett AI-assistent är inte “en LLM med en prompt”. Det är ett system som accepterar avsikt, behåller tillstånd, avgör när det ska hämta data eller utföra åtgärder, och exponerar tillräckligt med detaljer om körningen för att kunna felsöka misslyckanden.

Den här systemorienterade synen är vad AI Systems-klustret utforskar när assistenter går bortom en enkel modellanrop.

OpenAI beskriver agenter som applikationer som planerar, anropar verktyg, samarbetar och behåller tillräckligt med tillstånd för flerstegsarbete, medan Anthropic beskriver samma problem som ett hanterat ramverk som kan köra filer, kommandon, webbtillgång och kod på ett säkert sätt.

Den renaste arkitekturen delar upp ansvaret i fem lager: LLM, Minne, Verktyg, Routing och Observabilitet. Denna uppdelning matchar de möjligheter som exponeras av stora leverantörs-API:er, av MCP, av självvärda körningar som vLLM och llama.cpp, samt av riktiga assistentsystem som OpenClaw och Hermes.

Minne bör behandlas som mer än bara “längre kontext”. Hämtningssystem (retrieval systems) omvandlar extern kunskap till explicit icke-parametriskt minne — samma utrymme som behandlas ingående i Retrieval-Augmented Generation (RAG) — och både Anthropics kontextriktlinjer och papperet “Lost in the Middle” varnar för att att bara stoppa in fler tokens i kontexten inte garanterar pålitlig återkallelse.

Verktygsanvändning är en kontraktsgräns, inte magi. OpenAIs funktionanrop (function calling), Anthropics verktygsanvändning och MCP bygger alla på samma mönster: modellen emitterar en strukturerad begäran, någon körning utför den, och resultatet flödar tillbaka till konversationen. Om den gränsen är slarvig blir assistenten slarvig.

Min bias är enkel: börja tråkigt. En orkestrator, en hållbar minnesväg, en spårning per begäran och en explicit policy för verktygsexekvering. Multi-agent-grafer är användbara, men först efter att du kan förklara dina single-agent-felscenarier utan att gissa.

Vad ett AI-assistentsystem är

En praktisk definition är denna: ett AI-assistentsystem är en körning som omvandlar användaravsikt till ett svar eller en åtgärd genom att kombinera ett modellgränssnitt, kontextsamling, verktygsexekvering, tillståndshantering och telemetri. Det är därför de användbara dokumenten inte bara är modelkort. De användbara dokumenten är API-referenser, verktygsavtal, hämtningar guider, routingsdokument och spårningsdokument. OpenAIs Responses API exponerar tillståndsberedda interaktioner, inbyggda verktyg och funktionanrop. Anthropics Claude API exponerar direkt åtkomst till Messages samt Managed Agents. OpenClaw och Hermes går ett steg längre och visar vad som händer när man placerar dessa möjligheter bakom persistenta gateway, kanaler, sessioner och minne.

Med andra ord har ett assistentsystem ett bredare avtal än en chatkomplettering. Ett bra internt avtal ser ut ungefär så här:

AssistantRequest  = användaravsikt + identitet + session + bilagor + policy
AssistantResponse = svar + åtgärder + citat + tillståndsförändringar + spår-ID

Det avtalet är viktigt eftersom varje diskussion i produktionen till slut reduceras till en av dessa frågor: vilken kontext var synlig, vilket verktyg exekverades, vilken modell svarade, vilket minne lästes eller skrevs, och var spårningen säger att systemet tillbringade tiden. OpenTelemetry definierar spårningar som vägen för en begäran genom en applikation, vilket är exakt den abstraktion seriösa assistenter behöver. LangSmith och OpenLIT specialiserar sedan den idén för LLM:er, verktyg, vektorlagring och agentarbetsflöden.

Kärnkomponenter och gränssnitt

Komponentuppdelningen nedan är den jag finner mest hållbar. Det är också den uppdelning som bäst stämmer överens med de officiella API:erna och de open-source-körningar som människor faktiskt driver.

Tabellen ovan är härledd från de officiella leverantörsgränssnitten, MCP, vektordatabas-dokumentation och körningsdokumentation för vLLM, llama.cpp, OpenClaw och Hermes.

LLM-lagret bör göra tre saker bra: konsumera en aktuell arbetskontext, emittera antingen ett slutgiltigt svar eller en strukturerad åtgärdsbegäran, och returnera tillräckligt med metadata för att stödja omförsök och spårning. OpenAIs Responses API är explicit designat för tillståndsberedda interaktioner plus inbyggda verktyg och funktionanrop. Anthropics Messages API exponerar samma kärnloop genom tool_use-block och tool_result-returneringar, medan Managed Agents ger dig ett värdhöst ramverk om du inte vill bygga loopen själv. Självvärda körningar som vLLM och llama.cpp är viktiga eftersom de bevarar bekanta leverantörsgränssnitt samtidigt som de låter dig placera inferens inom din egen miljö.

Minneslagret bör mentalt delas upp i tre kategorier: arbetsminne, hållbart symboliskt minne och sökbar semantiskt minne. OpenAI embeddings returnerar vektorer som kan indexerings och sökas; OpenAI Retrieval och File Search lagrar sedan semantisk och nyckelordsbaserad sökning ovanpå vektorlagring. Pinecone, Weaviate, pgvector och Milvus representerar fyra vanliga lagringsformer: fullt hanterad, open-source-vektor-nativ, Postgres-nativ och distribuerad vektordatabas. Hermes och OpenClaw lägger till en användlig påminnelse om att inte allt minne tillhör i en vektordatabas: filbaserade anteckningar, granskade promotioner och sessionsscopeade snapshotar är ofta den ärligare designen. Memory Systems in AI Assistants karterar den tvärramverksmodellen; Hermes Agent Memory System packar upp begränsat kärnminne och frusna sessionssnapshotar i en produkt.

Verktygslagret är där en assistent slutar vara en sammanfattare och börjar bli mjukvara. OpenAIs function calling behandlar verktyg som schemadeфинerad funktionalitet som modellen kan avgöra att anropa. Anthropic säger samma sak mer explicit: verktygsanvändning är ett avtal mellan din applikation och modellen, och modellen exekverar aldrig något på egen hand. MCP generaliserar det avtalet till ett klient-server-protokoll där värdar ansluter till en eller flera servrar som exponerar verktyg, prompts och resurser — samma gräns som beskrivs steg för steg i MCP Server in Go. LangChain och LlamaIndex sitter bekvämt här som orkestrationsbibliotek: LangChain fokuserar på förbyggd agentarkitektur och integrationer, medan LlamaIndex fokuserar på kontextutökad dataåtkomst, query-engines och arbetsflöden.

Routingslagret existerar eftersom “vilken modell?” aldrig är den enda frågan. Du behöver också “vilken leverantörsbana, vilken tenant, vilken budget, vilken latensklass och vilken fallback?”. LiteLLM är användbart eftersom dess officiella dokumentation är uppfriskande konkret: viktad plockning, minst upptagen, latensbaserad, kostnadsbaserad routing och begränsade failovers är alla förstaklassmönster. OpenClaw utökar routing uppåt till kanal- och agentisolering, medan Hermes utökar den nedåt till modellsnitt för huvud- och aukiliärt arbete som sammanfattning, kompression och MCP-verktygsrouting. Det är den rätt mentala modellen: routern väljer mer än en modell, den väljer en exekveringsfil.

Observabilitetslagret är det som förhindrar att arkitektur blir till folklore. OpenTelemetry ger dig spårningsabstraktionen. LangSmith ger dig end-to-end-synlighet över LLM-applikationssteg och stöder moln-, hybrid- och självvärd deployments. OpenLIT ger dig OpenTelemetry-nativ AI-observabilitet med zero-code- och manuell instrumenteringsalternativ, inklusive stöd för LLM:er, agentramverk, vektordatabaser och GPU:er. För produktionsmetriker, spårningar och SLO-mönster över inferens och agentarbetsflöden, se Observability for LLM Systems. Om din assistent inte har någon spårning per begäran, ingen span per modellanrop och ingen evenemangshistorik för verktygsexekvering, har du inte riktigt en arkitektur än. Du har vibes.

Fånga, berika, svara

Sekvensen som ständigt återkommer i riktiga system är fånga -> berika -> svara -> dokumentera. Olika ramverk paketerar det olika, men flödet är stabilt nog att behandlas som ryggraden.

Fånga-steget är oftast viktigare än det ser ut. Både OpenClaw och Hermes placerar en persistent gateway framför assistenten eftersom ingress inte bara är textinmatning. Den inkluderar kanalmetadata, identiteter, auktorisering, sessionsgränser, direkta meddelanden, grupper, cron-ticks och leveranssemantik. Om du hoppar över det lagret och förlitar dig på en raw chat widget-abstraktion, kommer du till slut att spikar tillbaka det som ad hoc middleware ändå.

Berika-steget är där mogna system divergerar från leksaksdemon. OpenAI Retrieval och File Search gör hämtning explicit genom vektorlager och sökanrop. LlamaIndex formaliserar samma mönster genom dataconnectors, index, query-engines och arbetsflöden. Hermes går längre genom att dela upp modellbeståndet i huvud- och aukiliära snitt, och outsourcar arbete som kompression, sammanfattning och routing till mindre eller mer specialiserade modeller. Det är ett designmönster värt att stjäla: spendera inte dina dyraste modelltokens på plikter.

Svara-steget är inte “generera text”. Det är “stäng den aktuella loopen”. Om modellen kan svara direkt, gör den det. Om den behöver ett verktyg, emitterar den en strukturerad begäran. Både Anthropics verktygsanvändningsavtal och OpenAIs guide för funktionanrop gör detta explicit. Anledningen till att detta är arkitektoniskt viktigt är att utdata nu inkluderar både språk och kontrollflöde. Ditt svarobjekt är delvis prosa och delvis körningsplan.

Dokumentera-steget är där konsistenssemantik dyker upp. Pinecone separerar skriv- och läsvägar och bearbetar skrifter efter hållbar bekräftelse. Hermes minne injiceras som en frusen snapshot per session så att det kan bevara prefix-cache-prestanda, vilket innebär att nya skrifter inte automatiskt dyker upp i den aktuella sessionsprompten. OpenClaws Dreaming-system promoverar endast granskade, jorderade kandidater till MEMORY.md, och det är opt-in snarare än alltid-på. Den praktiska läxan är att minne sällan är verkligen read-after-write över varje lager. Du behöver designa för stegvis synlighet.

OpenClaw och Hermes som referenssystem

OpenClaw och Hermes är användbara referensfall eftersom de inte bara är wrappers runt ett leverantörs-API. Båda presenterar en assistent som ett långvarigt system med gateways, sessioner, verktyg, minne och flera modellbackends.

Denna mappning är förankrad i de officiella OpenClaw- och Hermes-dokumenten och repos. OpenClaw dokumenterar en gateway-arkitektur, multi-agent-routing, stöd för anpassade och självvärda leverantörer inklusive vLLM och Ollama, valfritt aktivt minne och Dreaming-baserad promotion. Hermes dokumenterar en meddelandegateway, en central AIAgent-loop, huvud- och aukiliära modellsnitt, inbyggt minne och native MCP-integration.

Min något åsiktsstyrda tolkning är att båda systemen gör samma arkitektoniska argument i olika akcenter. OpenClaw är starkt gateway-first. Hermes är starkt agent-loop-first. Men båda avvisar den ytliga idén att en assistent bara är “prompt plus modell”. De modellerar kanaler, identiteter, minnessemantik, verktygsytor och backend-heterogenitet som förstaklassfrågor. Det är exakt vad en produktionsarkitektur ska göra.

En praktisk hybridstack inspirerad av båda systemen ser ut så här:

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

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

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

Den stacken är ett resonant deploymentsmönster snarare än en leverantörsföreskriven ritning. Den fungerar eftersom de officiella gränssnitten stämmer överens: OpenAI och Anthropic exponerar verktygsorienterade API:er, vLLM och llama.cpp emulerar leverantörsändpunkter, Ollama hanterar lokala modeller och embeddings, MCP standardiserar externa verktyg, LiteLLM hanterar routing och failover, och OpenTelemetry-kompatibla plattformar kan spåra hela vägen.

Mönster, tabeller och avvägningar

Det finns några upprepbara assistentmönster som är värda att namnge. En hanterad assistent behåller mestadels körningen inne i leverantörs-API:er. En retrieval-first-assistent behandlar minne och sökning som den huvudsakliga differensiatorn. En tool-first-assistent beter sig mer som en operatör än en chatbot. En gateway-assistent prioriterar alltid-på-åtkomst genom meddelandytor. Ett specialistnät dekomponerar arbete till flera agenter eller rutter. Officiella dokument över OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw och Hermes stödjer alla versioner av dessa mönster, även om de namger dem olika.

Specialistnät-mönstret växer till en distinkt ingenjörskapacitet när agentantalet ökar. För de sex kanoniska koordinationsmönstren — orchestrator-worker, sequential pipeline, fan-out, hierarchical, swarm och mesh — med specifika felmoder och ett produktionsbeslutsramverk, se Multi-Agent Orchestration Patterns.

Denna mönstertabell är en syntes från leverantörsdokument, ramverksdokument och referenssystem snarare än ett påstående från någon enskild leverantör.

Tabellanteckningar: OpenAI värdhostad File Search är ett hanterat verktyg, Anthropic erbjuder ett hanterat ramverk, Pinecone är en hanterad vektortjänst, medan vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith självvärd och OpenLIT alla stöder självhanterad eller hybrid drift i varierande grad.

Tabellanteckningar: Pinecone dokumenterar en hanterad kontrollplan och regionala dataplaner. Weaviate dokumenterar vektor- och inverterade index med flera vektorindextyper. pgvector lägger till exakt och approximativ närmaste-granne-sökning till Postgres. Milvus positionerar sig som en open-source högprestanda, skalbar vektordatabas, med Zilliz Cloud som det hanterade alternativet.

Tabellanteckningar: OpenAI dokumenterar Responses som sitt avancerade gränssnitt för tillståndsberedda svar och inbyggda verktyg. Anthropic dokumenterar Messages API och verktygsanvändningsavtalet separat från Managed Agents. vLLM exponerar en OpenAI-kompatibel server plus Anthropic Messages API-stöd. Ollama dokumenterar lokal embedding- och modellarbetsflöden. llama.cpp dokumenterar OpenAI-kompatibel chat, responses och embeddings-rutter, plus Anthropic-kompatibla chatkompletteringar.

Denna avvägningsmatris är en arkitektonisk inferens från de officiella dokumenten, inte en leverantörsbenchmark. Konsistensraden är viktigare än många blogginlägg erkänner: Pinecone separerar skriv- och läsvägar, Hermes fryser minnet i sessionsstartprompts, och OpenClaw promoverar hållbart minne genom stegvis granskning. Det betyder att “minne uppdaterat” och “minne synligt för det aktuella svaret” ofta är olika sanningar.

Felmoder och mildringar

De flesta assistenter misslyckas inte eftersom basmodellen är “dålig”. De misslyckas eftersom det omgivande systemet ljuger för modellen, svälter den för rätt kontext, låter verktyg driva ifrån eller gör felsökning omöjlig.

Bevisbasen för denna tabell är bred men konsekvent. Anthropics verktygsdokument gör det klart att verktygsanvändning är en kontraktsgräns. OpenAI Guardrails inkluderar hallucineringsdetektering mot en referenskunskapsbas via File Search. SelfCheckGPT visar att självkonsistens över prover kan hjälpa till att detektera oberoende påståenden. Resultaten från “Lost in the Middle” och Anthropics kontextriktlinjer förstärker båda samma operationella läxa: fler tokens tar inte bort behovet av kontextkuratering.

Föredragen mildringsstack kan vara tråkig och upprepande: spåra varje begäran, versionera prompts, evaluerar hämtning oberoende, håll verktyg idempotenta och kör regressions evals innan du ändrar rutter eller minnespolicy. OpenAIs Evals-dokument och repo är rakt om varför: utan evals är det svårt och tidskrävande att förstå hur modell- eller promptförändringar påverkar ditt användningsfall. Det gäller lika mycket för routrar och hämtning som för prompts.

Mer läsning

Om du vill gå djupare, finns här de mest användbara primärkällorna att hålla öppna medan du designar eller granskar en assistentarkitektur.

• OpenAI: Responses Overview, Function Calling, Using Tools, Retrieval, File Search, Evals och MCP för remote tool servers.

• Anthropic: API Overview, Tool Use, tool-use contract, Managed Agents, Context Windows och MCP connector.

• MCP självt: Architecture Overview och Specification är värda att läsas direkt, eftersom de förklarar värdar, klienter, servrar, verktyg, prompts, resurser, transporter och kapacitetsförhandling rent. För en praktisk jämförelse av MCP med Agent2Agent-protokollet och när ett multi-agentsystem behöver båda lagren, se A2A vs MCP: Do AI Agents Really Need Both Protocols? och för A2A-koncepterna själva — Agent Cards, task lifecycle, messages, parts och artifacts — se What Is the A2A Protocol? Agent Cards and Tasks Explained.

• Bakgrund och proaktiva assistenter: verktygslagret är bara en del av hur assistenter agerar. För hur man får en assistent att titta, avgöra och agera på egen hand — schemaläggare, köbaserade workers, claim-protokoll, hållbara arbetsflöden och semantisk polling — se Polling Agents in AI Assistants: 11 Implementation Patterns.

• A2A-protokoll och adoption: när agenter är oberoende deployade och behöver samarbeta över ägandegränser, blir A2A relevant. För en praktisk 2026-syn på var A2A faktiskt har traction, de säkerhetsfrågor det väcker, och ett beslutsramverk för när man ska adoptera det, se Google A2A Protocol in 2026: Adoption, Hype, and Reality. När dessa agenter utbyter långvariga uppgifter snarare än enskilda chattvarv, täcker A2A Streaming and Async Tasks for Long-Running Agent Workflows SSE, push och input_required-design vid protokollgränsen.

• Ramverk och routing: LangChain Overview, LlamaIndex context-augmentation docs, LiteLLM routing docs, LangSmith observability docs.

• Självvärda körningar och assistentsystem: vLLM, llama.cpp server, Ollama embeddings, OpenClaw docs och repo, Hermes docs och repo.

• Lagring och observabilitet: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Forskningspapper: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle och SelfCheckGPT.