AI-system: Självhostade assistenter, RAG och lokal infrastruktur

Sidinnehåll

De flesta lokala AI-uppsättningar börjar med en modell och en körningstid (runtime).

Du laddar ner en kvantiserad modell, startar den via Ollama eller en annan körningstid och börjar prompta. För experiment är detta mer än tillräckligt. Men när du går bort från nyfikenhet — när du börjar bry dig om minne, hämtningskvalitet, routingbeslut eller kostnadsmedvetenhet — börjar enkelheten visa sina begränsningar.

Denna kluster utforskar ett annat tillvägagångssätt: att behandla AI-assistenten inte som ett enskilt modellanrop, utan som ett koordinerat system.

Den skillnaden kan tycks subtil i första hand, men den förändrar hur du tänker på lokal AI helt och hållet.

AI-systems orchestrering med lokala LLM:er, RAG och minneslager

Vad är ett AI-system?

Ett AI-system är mer än en modell. Det är ett orchestration-lager som kopplar ihop inferens, hämtning, minne och exekvering till något som beter sig som en sammanhängande assistent.

Att köra en modell lokalt är infrastrukturarbete. Att designa en assistent kring den modellen är systemarbete.

Om du har utforskat våra bredare guider om:

så vet du redan att inferens bara är ett lager i stapeln.

AI Systems-klustret sitter ovanpå dessa lager. Det ersätter dem inte — det kombinerar dem.

För en tvärsnittskarta över hur dessa lager passar ihop i produktionsassistenter — LLM, minne, verktyg, routing och observabilitet, med OpenClaw och Hermes som referenssystem — se AI-assistentarkitektur: LLM, minne, verktyg, routing, observabilitet.

När assistentarkitekturen är solid är nästa steg att göra den proaktiv. Polling-agenter i AI-assistenter: 11 implementationmönster täcker hur bakgrundspollingarbetare, köbaserad exekvering, hållbara arbetsflöden och semantiska LLM-utvärderare förvandlar en reaktiv assistent till en som vakar, beslutar och agerar på egen hand.

När en ensam assistent inte räcker och flera agenter behöver koordinera, avgör valet av koordineringsmönster allt: latens, feltolerans, kostnad och felsökningsbarhet. Multi-Agent Orchestreringsmönster: En praktisk guide täcker de sex kanoniska mönstren — orchestrator-worker, sekventiell pipeline, fan-out, hierarkisk, swarm och mesh — med specifika felmoder och ett beslutsramverk för att välja rätt arkitektur.

OpenClaw: Ett självvärdshostat AI-assistentsystem

OpenClaw är ett öppen källkod, självvärdshostat AI-assistentsystem designat för att operera över meddelandepattformar medan det körs på lokal infrastruktur.

På en praktisk nivå:

  • Använder lokala LLM-körningstider som Ollama eller vLLM
  • Integrerar hämtning över indexerade dokument
  • Underhåller minne bortom en enskild session
  • Exekverar verktyg och automatiseringsuppgifter
  • Kan instrumenteras och observeras
  • Opererar inom hårdvarubegränsningar

Det är inte bara ett skal runt en modell. Det är ett orchestration-lager som kopplar ihop inferens, hämtning, minne och exekvering till något som beter sig som en sammanhängande assistent.

Kom igång och arkitektur:

Kontext och analys:

Utöka och konfigurera OpenClaw:

Plugins utökar OpenClaw-körningstiden — och lägger till minnesbackends, modellleverantörer, kommunikationskanaler, webbverktyg och observabilitet. Skills utökar agentbeteende — och definierar hur och när agenten använder dessa förmågor. Produktionskonfiguration innebär att kombinera båda, formad kring vem som faktiskt använder systemet.

Hermes: En persistent agent med Skills och verktygsandboxing

Hermes Agent är en självvärdshostad, modellagnostisk assistent med fokus på persistent operation: den kan köras som en långlevande process, exekvera verktyg genom konfigurerbara backends och förbättra arbetsflöden över tid genom minne och återanvändbara skills.

På en praktisk nivå är Hermes användbar när du vill:

  • En terminal-först-assistent som också kan brygga in i meddelandeappar
  • Leverantörsflexibilitet genom OpenAI-kompatibla ändpunkter och modellbyte
  • Verktygsexekveringsgränser via lokala och sandboxade backends
  • Dag-två-operationer med diagnostik, loggar och konfigurationshygien

Hermes-profiler är fullt isolerade miljöer — var och en med sin egen konfiguration, hemligheter, minnen, sessioner, skills och tillstånd — vilket gör profiler till den verkliga enheten för produktionsägande, inte den enskilda skillen.

Persistent kunskap och minne

Vissa problem löses inte av ett större kontextfönster ensamt — de behöver persistent kunskap (grafer, inmatningspipelines) och agentminnesplugins (Honcho, Mem0, Hindsight och liknande backends) trådade in i assistenter som Hermes eller OpenClaw.

MCP: Model Context Protocol-servrar

Model Context Protocol (MCP) är en öppen standard introducerad av Anthropic för att koppla AI-språkmodeller till externa datakällor, verktyg och system. Den löser N×M-integrationsproblemet genom att tillhandahålla ett universellt gränssnitt — tänk på det som en USB-C-port för AI-applikationer. Att bygga MCP-servrar låter dig utöka AI-assistenter med anpassade integrationer för filer, databaser, API:er och anropbara verktyg, med ett enkelt JSON-RPC-baserat protokoll över stdio eller HTTP.

  • MCP-server i Go — protokollarkitektur, JSON-RPC-meddelandestruktur, kapacitetsförhandling, officiell Go SDK och en steg-för-steg-tutorial för att bygga MCP-servrar i Go
  • Bygga MCP-servrar i Python — praktisk Python-implementationguide som täcker webbsök och skrapning MCP-servrar, stdio- och SSE-transporter och Claude Desktop-integration

A2A: Agent-to-Agent Protocol

Agent2Agent Protocol (A2A) är en öppen standard för kommunikation mellan oberoende distribuerade AI-agentsystem. Där MCP kopplar en agent till verktyg, kopplar A2A agenter till andra agenter — vilket låter dem upptäcka varandra via Agent Cards, utbyta uppgifter och meddelanden, streama framsteg och returnera typade artefakter. A2A är designad för system där agenter ägs av olika team, byggs med olika ramverk eller distribueras som separata tjänster som behöver interagera.

Vad som gör AI-system olika

Flera egenskaper gör AI-system värda att undersöka närmare.

Modellrouting som ett designval

De flesta lokala uppsättningar standardiseras till en modell. AI-system stödjer medveten modellval.

Det introducerar frågor:

  • Borde små förfrågningar använda mindre modeller?
  • När rättfärdigar resonemang ett större kontextfönster?
  • Vad är kostnads skillnaden per 1 000 token?

Dessa frågor kopplar direkt till prestandavvägningar diskuterade i LLM-prestandaguiden och infrastrukturbeslut utlagda i LLM-värdskapsguiden.

AI-system lyfter fram dessa beslut istället för att dölja dem.

Hämtning behandlas som en utvecklande komponent

AI-system integrerar dokumenthämtning, men inte som ett enkelt “embed och sök”-steg.

De erkänner:

  • Chunk-storlek påverkar recall och kostnad
  • Hybrid sökning (BM25 + vektor) kan överträffa ren dense-hämtning
  • Reranking förbättrar relevans till kostnad av latens
  • Indexeringsstrategi påverkar minnesanvändning

Dessa teman stämmer överens med de djupare arkitektoniska överväganden diskuterade i RAG-tutorialen.

Skillnaden är att AI-system inbäddar hämtning i en levande assistent snarare än att presentera det som en isolerad demo.

Minne som infrastruktur

Stateless LLM:er glömmer allt mellan sessioner.

AI-system introducerar persistenta minneslager. Det väcker omedelbart designfrågor:

  • Vad ska lagras långsiktigt?
  • När ska kontext sammanfattas?
  • Hur förhindrar man token-explosion?
  • Hur indexerar man minne effektivt?

Dessa frågor korsar direkt datalageröverväganden från datainfrastruktur-guiden. För Hermes Agent specifikt — begränsat 2-filskärnminne, prefix-cache, externa plugins — börja med Hermes Agent minnessystem och den tvärsystemjämförelsen Agentminnesleverantörer jämförda. AI Systems Memory hub listar relaterade Cognee- och kunskapslagringsguides.

Minne slutar vara en funktion och blir ett lagringsproblem.

Observabilitet är inte valfri

De flesta lokala AI-experiment stannar vid “det svarar”.

AI-system gör det möjligt att observera:

  • Tokenanvändning
  • Latens
  • Hårdvaruutnyttjande
  • Genomströmningsmönster

Detta kopplar naturligt med övervakningsprinciperna beskrivna i observabilitetsguiden.

Om AI körs på hårdvara, bör den vara mätbar som någon annan arbetslast.

Vad det känns som att använda

Utanifrån kan ett AI-system fortfarande se ut som ett chattgränssnitt.

Under ytan händer mer.

Om du ber den sammanfatta en teknisk rapport lagrad lokalt:

  1. Den hämtar relevanta dokumentsegment.
  2. Den väljer en lämplig modell.
  3. Den genererar ett svar.
  4. Den registrerar tokenanvändning och latens.
  5. Den uppdaterar persistent minne vid behov.

Den synliga interaktionen förblir enkel. Systembeteendet är lagrat.

Det lagrade beteendet är vad som skiljer ett system från en demo.

Var AI-system passar i stapeln

AI Systems-klustret sitter vid skärningspunkten mellan flera infrastrukturlager:

  • LLM-värdskap: Körningstidslagret där modeller exekveras (Ollama, vLLM, llama.cpp)
  • RAG: Hämtningslagret som tillhandahåller kontext och grounding
  • Prestanda: Mätningsslaget som spårar latens och genomströmning
  • Observabilitet: Övervakningslagret som tillhandahåller metrik och kostnadsspårning
  • Datainfrastruktur: Lagringslagret som hanterar minne och indexering

Att förstå den skillnaden är användbart. Att köra det själv gör skillnaden tydligare.

För en minimal lokal installation med OpenClaw, se OpenClaw snabbstartsguide, som går igenom en Docker-baserad uppsättning med antingen en lokal Ollama-modell eller en molnbaserad Claude-konfiguration.

Om din uppsättning beror på Claude, denna policyändring för agentverktyg förklarar varför API-faktura nu krävs för tredjeparts OpenClaw-arbetsflöden.

Resurser

A2A: Agent-to-Agent Protocol:

MCP-servrar:

AI-assistentguides:

Infrastrukturlager:

Prenumerera

Få nya inlägg om system, infrastruktur och AI-ingenjörskonst.