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

Ett produktionsklart AI-assistent är inte “en LLM med en prompt”. Det är ett system som accepterar intentioner, behåller tillstånd, beslutar när det ska hämta data eller agera, och exponerar tillräckligt med runtime-detalyjer för att kunna felsöka fel.

Detta systemperspektiv är det som AI Systems-klustret utforskar när assistenter går bortom en enda modellanrop.

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

Den renaste arkitekturen delar upp ansvarsområdena i fem lager: LLM, Minne, Verktyg, Routing och Observabilitet. Denna uppdelning matchar de funktioner som exponeras av stora leverantörers API:er, av MCP, av självhostade runtimes som vLLM och llama.cpp, och av verkliga assistantsystem 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 designutrymme som behandlas ingående i Retrieval-Augmented Generation (RAG) — och både Anthropics kontextriktlinjer och papperet “Lost in the Middle” varnar för att bara stoppa in fler token i kontexten inte garanterar pålitlig återkallning.

Verktygsanvändning är en avtalsgräns, inte magi. OpenAIs function calling, Anthropics tool use och MCP bygger alla på samma mönster: modellen emitterar en strukturerad begäran, en runtime exekverar den, och resultatet flyter tillbaka till konversationen. Om denna gräns är slarvig blir också assistenten slarvig.

Min bias är enkel: börja tråkigt. En orkestrator, en hållbar minnesväg, en spår 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-fel utan att gissa.

Vad ett AI-assistentsystem är

En praktisk definition är denna: ett AI-assistentsystem är en runtime som omvandlar användarens intention till ett svar eller en handling genom att kombinera ett modellgränssnitt, kontextsamling, verktygsexekvering, tillståndshantering och telemetri. Det är därför de användbara dokumenten inte bara är model cards. De användbara dokumenten är API-referenser, verktygsavtal, hätningsguider, routingsdokument och spårdokument. OpenAIs Responses API exponerar tillståndsbaserade interaktioner, inbyggda verktyg och function calling. 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 persistenta gatewayar, 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ändarintention + identitet + session + bilagor + policy
AssistantResponse = svar + åtgärder + citat + 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året säger att systemet tillbringade tid. OpenTelemetry definierar spår (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, vektorlagring och agentarbetsflöden.

Kernkomponenter och gränssnitt

Komponentuppdelningen nedan är den jag finner mest hållbar. Det är också den uppdelning som passar bäst med de officiella API:erna och de open-source-runtimes som folk faktiskt driver.

Tabellen ovan är härledd från de officiella leverantörsgränssnitten, MCP, vektordatabasdokumentation och runtime-dokumentation 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 begäran om åtgärd, 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åndsbaserade interaktioner plus inbyggda verktyg och function calling. Anthropics Messages API exponerar samma kärnloop genom tool_use-block och tool_result-returneringar, medan Managed Agents ger dig en hostad ram om du inte vill bygga loopen själv. Självhostade runtimes som vLLM och llama.cpp är viktiga eftersom de bevarar kända leverantörsgränssnitt medan de låter dig placera inferensen i 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 indexeras och sökas; OpenAI Retrieval och File Search lägger 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 uppgraderingar och sessionsspecifika snapshotter är ofta en ärligare design — mönster som packas upp i Hermes Agent Memory System för begränsat kärnminne och frusna sessionssnapshotter.

Verktygslagret är där en assistent slutar vara en sammanfattare och börjar bli mjukvara. OpenAIs function calling behandlar verktyg som schemadefinerad 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 passar bekvämt här som orkestreringsbibliotek: LangChain fokuserar på en färdig agentarkitektur och integrationer, medan LlamaIndex fokuserar på kontexttärkt dataåtkomst, querymotorer och arbetsflöden.

Routingslagret finns eftersom “vilken modell?” aldrig är den enda frågan. Du behöver också “vilken leverantörsstig, vilken tenant, vilken budget, vilken latensklass och vilken fallback?”. LiteLLM är användbart eftersom dess officiella dokumentation är uppfriskande konkret: vägd pick, minst upptagen, latensbaserad, kostnadsbaserad routing och begränsade failovers är alla förstaklasssmönster. OpenClaw utökar routing uppåt till kanal- och agentisolering, medan Hermes utökar den nedåt till modellslots för huvud- och hjälpuppgifter som sammanfattning, kontextkomprimering och MCP-verktygsrouting. Det är rätt mental modell: 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årabstraktionen. LangSmith ger dig end-to-end-synlighet över LLM-applikationens steg och stödjer moln-, hybrid- och självhostade deploymentsformer. 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 produktionsmetrik, spår och SLO-mönster över inferens och agentarbetsflöden, se Observability for LLM Systems. Om din assistent inte har något 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 -> dokumentera. Olika ramverk wrapperar det på olika sätt, men flödet är stabilt nog för att behandlas som ryggraden.

sequenceDiagram
    participant U as User or Channel
    participant G as Gateway or UI
    participant R as Router
    participant M as Memory and Retrieval
    participant L as LLM
    participant T as Tools or MCP
    participant O as Observability

    U->>G: message, file, or command
    G->>O: start root trace
    G->>R: request + identity + session + policy
    R->>M: load session state and retrieve context
    M-->>R: notes, chunks, metadata
    R->>L: prompt + context + tool schemas
    L-->>R: answer or tool call
    alt tool call
        R->>T: execute tool or MCP action
        T-->>R: tool result
        R->>L: tool result + updated context
        L-->>R: final answer
    end
    R->>M: persist session changes and memory candidates
    R->>O: spans, metrics, eval events
    G-->>U: response

Fångststeget ä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. 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 rå chat-widget-abstraktion, kommer du till slut att bulta tillbaka det som ad hoc-middleware ändå.

Berikningssteget är där mogna system divergerar från leksaksdemos. OpenAI Retrieval och File Search gör hämtning explicit genom vektorlager och sökanrop. LlamaIndex formaliserar samma mönster genom dataconnectors, index, querymotorer och arbetsflöden. Hermes går längre genom att dela upp modellbeståndet i huvud- och hjälpslots, och outsourcerar arbete som komprimering, sammanfattning och routing till mindre eller mer specialiserade modeller. Det är ett designmönster värt att stjäla: spendera inte dina dyraste modelltoken på trädgårdsskötsel.

Svarssteget ä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 verktygsavtal och OpenAIs guide för function calling gör detta explicit. Anledningen till att detta är viktigt arkitekturellt är att utdata nu inkluderar både språk och kontrollflöde. Ditt svarsobjekt är delvis prosa och delvis runtime-plan.

Dokumenteringssteget ä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 befordrar 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 måste 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 gatewayar, sessioner, verktyg, minne och flera modellbackends.

Denna mappning är förankrad i de officiella OpenClaw- och Hermes-dokument och -repo. 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 uppfrämjning. Hermes dokumenterar en messaginggateway, en central AIAgent-loop, huvud- och hjälpslots, inbyggt minne och native MCP-integration.

Min lite åsiktsstyrda tolkning är att båda systemen gör samma arkitekturella argument i 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örstaklasssfrågor. 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 resonerat deploymentsmönster snarare än en leverantörsföreskriven blueprint. Den fungerar eftersom de officiella gränssnitten stämmer överens: OpenAI och Anthropic exponerar verktygsorienterade API:er, vLLM och llama.cpp emulerar leverantörsstilslutpunkter, 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 håller större delen av runtimen inne i leverantörs-API:er. En hämtning-first-assistent behandlar minne och sökning som den huvudsakliga differentiatorn. En verktyg-first-assistent beter sig mer som en operatör än en chatbot. En gateway-assistent prioriterar alltid-på-åtkomst genom messagingytor. 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.

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.

Tabellnoter: OpenAI hostad File Search är ett hanterat verktyg, Anthropic erbjuder en hanterad ram, 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 varierande grad.

Tabellnoter: 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.

Tabellnoter: OpenAI dokumenterar Responses som sitt avancerade gränssnitt för tillståndsbaserade 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-kompatibla chat, svar och embeddings-rutter, plus Anthropic-kompatibla chatkompletteringar.

Denna avvägningsmatris är en arkitekturell 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 främjar 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 mitigeringsåtgärder

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 drifta, eller gör felsökning omöjlig.

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

Föredragen mitigeringsstack kan vara tråkig och repetitiv: spåra varje begäran, versionera prompts, evalua hämtning oberoende, håll verktyg idempotenta, och kör regressionsvals innan du ändrar rutter eller minnespolicy. OpenAIs Evals-dokument och repo är raka 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 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 verktygsservrar.

• 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 routing: LangChain Overview, LlamaIndex kontexttärkningsdokument, LiteLLM routingdokument, LangSmith observabilitetsdokument.

• Självhostade runtimes och assistantsystem: vLLM, llama.cpp server, Ollama embeddings, OpenClaw dokument och repo, Hermes dokument 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.