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

En produktionsklar AI-assistent är inte “en LLM med en prompt”. Det är ett system som tar emot avsikt, behåller tillstånd, beslutar när det ska hämta information eller utföra åtgärder, och exponerar tillräckligt med detaljer om körningen för att kunna felsöka fel.

Detta systemperspektiv ä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 arbetsflöden med flera steg, 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 ansvar i fem lager: LLM, Minne, Verktyg, Ruttning och Observabilitet. Denna uppdelning matchar de funktioner som exponeras av stora leverantörs-API:n, av MCP, av självhostade körmiljöer som vLLM och llama.cpp, och av verkliga assistentsystem som OpenClaw och Hermes.

Minne bör behandlas som mer än “längre kontext”. Hämtningssystem (retrieval systems) omvandlar extern kunskap till explicit icke-parametriskt minne — samma utrymme som täcks ingående i Retrieval-Augmented Generation (RAG) — och både Anthropics kontextguidering och papperet “Lost in the Middle” varnar för att det inte räcker att bara stoppa in fler token i kontexten för att garantera 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, en körmiljö utför den, och resultatet flödar tillbaka i samtalet. Om denna gräns ä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-felfall utan att gissa.

Vad ett AI-assistentsystem är

En praktisk definition är denna: ett AI-assistentsystem är en körmiljö som omvandlar användarens avsikt till ett svar eller en åtgärd genom att kombinera ett modellgränssnitt, kontextsammanställning, verktygsexekvering, tillståndshantering och telemetri. Det är därför de användbara dokumentationen inte bara är modellkort (model cards). Den användbara dokumentationen är API-referenser, verktygsavtal, hämtningsguider, ruttningdokumentation och spårningsdokumentation. OpenAIs Responses API exponerar tillståndsbundna 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 funktioner bakom beständiga gateways, kanaler, sessioner och minne.

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

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

Detta avtal ä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 spenderade tid. OpenTelemetry definierar spårningar (traces) 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 denna idé för LLM:er, verktyg, vektordatabaser och agentarbetsflöden.

Kernkomponenter 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:na och de open-source-körmiljöer som folk faktiskt driver.

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

LLM-lagret bör göra tre saker väl: konsumera en aktuell arbetskongtext, 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åndsbundna 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 hostat ramverk om du inte vill bygga loopen själv. Självhostade körmiljöer som vLLM och llama.cpp är viktiga eftersom de bevarar bekanta leverantörsliknande gränssnitt samtidigt som de låter dig placera inferensen i din egen miljö.

Minneslagret bör mentalt delas upp i tre kategorier: arbetsminne, bestående symboliskt minne och sökbar semantiskt minne. OpenAI embeddings returnerar vektorer som kan indexeras och sökas i; OpenAI Retrieval och File Search lagerar sedan semantisk och nyckordsbaserad sökning ovanpå vektorlagring. Pinecone, Weaviate, pgvector och Milvus representerar fyra vanliga lagringsformer: fullt hanterad, open-source vektornativ, Postgres-nativ och distribuerad vektordatabas. Hermes och OpenClaw lägger till en användbar påminnelse om att inte allt minne hör hemma i en vektordatabas: filbaserade anteckningar, granskade förbättringar och sessionsspecifika ögonblicksbilder är ofta en ärligare design. Memory Systems in AI Assistants karterar den tvärvägsmodellen; Hermes Agent Memory System bryter ner begränsat kärnminne och frusna sessionssnappschots i en produkt.

Verktygslagret är där en assistant slutar vara en sammanfattare och börjar vara mjukvara. OpenAIs function calling behandlar verktyg som schemadefinierad funktionalitet som modellen kan besluta 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 detta avtal 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 orkestreringsbibliotek: LangChain fokuserar på en färdig agentarkitektur och integrationer, medan LlamaIndex fokuserar på kontextutökad dataåtkomst, querymotorer och arbetsflöden.

Ruttlagret existerar eftersom “vilken modell?” aldrig är den enda frågan. Du behöver också “vilken leverantörsväg, vilken tenant, vilken budget, vilken latensklass och vilken fallback?”. LiteLLM är användbart eftersom dess officiella dokumentation är uppfriskande konkret: viktad val, minst upptagen, latensbaserad, kostnadsbaserad ruttning och begränsade failovers är alla förstaklasssmönster. OpenClaw utökar ruttningen uppåt till kanal- och agentisolering, medan Hermes utökar den nedåt till modellslots för huvud- och hjälpuppgifter som sammanfattning, kontextkompression och MCP-verktygsruttning. Det är den rätta mentala modellen: routern väljer mer än en modell, den väljer en exekveringsfil.

Observabilitetslagret är det som förhindrar att arkitektur blir till folktro. OpenTelemetry ger dig spårningsabstraktionen. LangSmith ger dig end-to-end-synlighet över steg i LLM-applikationer och stödjer moln-, hybrid- och självhostade 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 assistant inte har ett spår 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 dyker upp i verkliga system är fånga -> berika -> svara -> registrera. Olika ramverk paketerar det olika, men flödet är stabilt nog för att behandlas som ryggraden.

Fågningssteget (capture) är oftast viktigare än det ser ut. Både OpenClaw och Hermes placerar en beständig gateway framför assistenten eftersom ingress inte bara är textinmatning. Det inkluderar kanalmetadata, identiteter, auktorisering, sessionsgränser, direktmeddelanden, grupper, cron-ticks och leveranssemantik. Om du hoppar över detta lager och förlitar dig på en abstraktion för en rå chattwidget, kommer du till slut att borra fast den tillbaka som ad hoc-middleware ändå.

Berikningssteget (enrich) är där mogna system skiljer sig från lekdemo. OpenAI Retrieval och File Search gör hämtning explicit genom vektordatabaser och sökanrop. LlamaIndex formaliserar samma mönster genom dataconnectorer, index, querymotorer och arbetsflöden. Hermes går längre genom att dela upp modellbeståndet i huvud- och hjälpslots, och outsourcar arbete som kompression, sammanfattning och ruttning till mindre eller mer specialiserade modeller. Det är ett designmönster värt att stjäla: spendera inte dina dyraste modelltoken på hushållsarbete.

Svarssteget (respond) ä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. Anthropics verktygsavtal 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 svarsobjekt är delvis prosa och delvis körmiljöplan.

Registreringssteget (record) är där konsistenssemantik dyker upp. Pinecone separerar skriv- och läsvägar och bearbetar skrivningar efter bestående bekräftelse. Hermes minne injeceras som en frusen ögonblicksbild per session så att det kan bevara prefix-cache-prestanda, vilket innebär att nya skrivningar inte automatiskt dyker upp i den aktuella sessionsprompten. OpenClaws Dreaming-system främjar endast granskade, förankrade kandidater till MEMORY.md, och det är opt-in snarare än alltid på. Den praktiska lärdomen ä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 wrapper 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 den officiella OpenClaw- och Hermes-dokumentationen och repos. OpenClaw dokumenterar en gateway-arkitektur, multi-agent routing, stöd för anpassade och självhostade leverantörer inklusive vLLM och Ollama, valfritt aktivt minne och Dreaming-baserad förädling. Hermes dokumenterar en meldingsgateway, en central AIAgent-loop, huvud- och hjälpslots för modeller, inbyggt minne och native MCP-integration.

Min lite åsiktsstyrda tolkning är att båda systemen gör samma arkitektoniska argument med olika accenter. 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örstaklasssförhållanden. Det är exakt vad en produktionsarkitektur bör 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 här stacken är ett resonant deploymentsmönster snarare än en leverantörsförskrivna blueprint. Det fungerar eftersom de officiella gränssnitten stämmer överens: OpenAI och Anthropic exponerar verktygsorienterade API:er, vLLM och llama.cpp emulerar leverantörsliknande endpoints, Ollama hanterar lokala modeller och embeddings, MCP standardiserar externa verktyg, LiteLLM hanterar ruttning 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örmiljön inuti leverantörs-API:er. En retrieval-first assistent behandlar minne och sökning som den huvudsakliga differentieraren. En tool-first assistent beter sig mer som en operatör än en chattbot. En gateway assistent prioriterar always-on-åtkomst via meddelandeytor. Ett specialistnät dekomponerar arbete till flera agenter eller rutter. Officiell dokumentation över OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw och Hermes stödjer versioner av dessa mönster, även om de namger dem olika.

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

Tabellanteckningar: OpenAI hostad 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älvhostad och OpenLIT alla stödjer självhanterad eller hybrid drift i olika grad.

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

Tabellanteckningar: OpenAI dokumenterar Responses som sitt avancerade gränssnitt för tillståndsbundna svar och inbyggda verktyg. Anthropic dokumenterar Messages API och verktygsavtalet 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 chatt, svar och embeddings-routes, plus Anthropic-kompatibla chattkompletteringar.

Denna avvägningsmatris är en arkitektonisk inferens från den officiella dokumentationen, 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 främjar bestående minne genom stegrad granskning. Det betyder att “minne uppdaterat” och “minne synligt för det aktuella svaret” ofta är olika sanningar.

Felmoder och dämpningar

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

Bevisbasen för denna tabell är bred men konsekvent. Anthropics verktygsdokumentation gör det tydligt att verktygsanvändning är en kontraktsgräns. OpenAI Guardrails inkluderar hallucinationsdetektering mot en referenskunskapsbas via File Search. SelfCheckGPT visar att självkonsistens över prover kan hjälpa till att detektera ostödda påståenden. Resultaten från “Lost in the Middle” och Anthropics kontextguidering förstärker båda samma operativa lektion: fler token tar inte bort behovet av kontextkuratering.

En föredragen dämpningsstack kan vara tråkig och repetitiv: spåra varje begäran, versionera prompts, evaliera hämtning oberoende, håll verktyg idempotenta, och kör regressionsevals innan du ändrar rutter eller minnespolicy. OpenAIs Evals-dokumentation och repo är slätta om varför: utan evals är det svårt och tidskrävande att förstå hur ändringar i modell eller prompt påverkar ditt användningsfall. Det gäller lika mycket för rutter 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 remota verktygservrar.

• Anthropic: API Overview, Tool Use, verktygsavtalet, Managed Agents, Context Windows, och MCP-connectorn.

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

• Ramverk och ruttning: LangChain Overview, LlamaIndex dokumentation för kontextutökning, LiteLLM ruttningdokumentation, LangSmith observabilitetsdokumentation.

• Självhostade körmiljöer och assistentsystem: vLLM, llama.cpp server, Ollama embeddings, OpenClaw dokumentation och repo, Hermes dokumentation 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.