Hvordan Fungerer en IA Konversasional Agent Indenfor?

Hvordan Fungerer en AI-Konversasional Agent Indenfor (Arkiteturen OpenClaw)

Hvordan fungerer en AI-konversasional agent i praksis, tur for tur? Dette post åbner lågen på OpenClaw: fra det øjeblik, hvor klientens besked ankommer på WhatsApp til teksten, som agenten skriver tilbage. Det bliver teknisk. Det er værd at se, hvis du beslutter om produktarkitektur, hvis du skal købe en løsning og vil evaluere grundlaget, eller hvis du nyder at vide, hvad der sker bagved konversationen.

TL;DR: hver tur går igennem 6 faser — indtage, løse kontekst, vælge færdigheder, bestemme næste handling, udføre med vandkraft, fastholde hukommelse. Alt cirkulerer på <sekunder på Cloudflares kant, uden fast server.

---

Hvorfor er arkiteturen vigtig

Konversasional agent, der ser ud til at fungere i en demo, men brister i produktion, har en af disse 4 problemer:

1. Høj latens — klienten venter 8 sekunder på svar, konversationen dør.
2. Ukontrolleret fantasi — agenten opfinder pris, tid, politik.
3. Tabt kontekst — klienten vender tilbage efter 2 dage og agenten "glemmer" alt.
4. Ukontrolleret omkostninger — hver lange konversation fylder prompten og du betaler en formue i token.

De 4 er valg af arkitetur, ikke begrænsninger af modellen. OpenClaw blev bygget til at undgå de 4 — og vejen til at forstå er at se cirklen i en tur.

---

Cirklen i en tur (6 faser)

Forestil dig, at klienten lige har sendt beskeden "jeg vil bestille til lørdag morgen". Hvad sker mellem "modtaget" og agentens svar?

Fase 1 — Indtage (edge worker, <ms)

Beskeden fra WhatsApp ankommer via webhook fra Meta direkte til en Cloudflare Worker på det nærmeste geografiske punkt (PoP). I Brasilien betyder det São Paulo eller Rio, netværkslatens <0ms.

Arbejderen gør tre ting:

1. Validere signatur på webhook (HMAC mod hemmelig WABA).
2. Identificere tenant ved hjælp af telefonnummer på modtager (multi-tenant efter to_number).
3. Normalisere payload — lyd bliver transkription, billeder bliver beskrivelse, placering bliver {lat,lng}, tekst bliver som den er.

I slutningen af fase 1 har du et objekt {tenant_id, conversation_id, user_message} klar til næste skridt.

Fase 2 — Løse kontekst (D1 + KV, ~80ms)

Agenten har brug for 3 dele af konteksten før han kan bestemme:

1. Klientens historie — hvilke beskeder har klienten sendt før?
2. Klientens profil — hvilke data har klienten angivet om sig selv?
3. Aktuel konversation — hvilke beskeder har klienten sendt i denne konversation?

Agenten kan hente disse oplysninger fra en database (D1) og en nøgle-verdi-database (KV).

• Seneste historik af konversationen (sidste N relevante vendinger).
• Langtidsminde af klienten (præferencer, købs historik, noter).
• Agentens tilstand (persona, aktiverede færdigheder, regler).

Alle kommer fra D1 (Cloudflare's distribueret SQLite). D1 erstatter traditionel Postgres/Mongo uden server til at holde, fås på få ms fra arbejderen, multi-tenant via tenant_id.

Hovedpunkt: vi ikke laster hele konversationen i promptet. OpenClaws Memory Manager v2 (beskrevet i vores intern dokumentation) vælger kun relevante vendinger til den aktuelle vending (sidste N + N med høj semantisk relevans).

Trin 3 — Færdighedssammenhæng (policy engine, ~20ms)

Hver agent har en sæt af færdigheder til rådighed — funktioner, der kan blive invokeret. Eksempler: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamado_humano.

Givet beskeden "quero marke til søndag morgen", policy engine filtrerer:

• Færdigheder, der er kompatibelt med det detekterede formål (agendement).
• Færdigheder, der er tilladt i denne fase af konversationen (ikke alle færdigheder er tilgængelige hele tiden).
• Færdigheder, der er aktiveret af denne tenant (kalender vises kun, hvis tenant har integreret).

I slutningen har du en lille undermængde af færdigheder, der bliver sendt til modellen — ikke de 50 mulige, men kun de 4, der er relevant her. Dette reducerer dramatisk chancen for, at modellen invokerer en forkert færdighed.

Trin 4 — Beslutning (LLM opkald, 400-1200ms)

Nu træder modellen ind. OpenClaw gør en enkelt opkald til et LLM på frontlinjen (Anthropic Claude, OpenAI GPT, Google Gemini — konfigurerbart af tenant) med:

• System prompt = agentens persona + regler + aktiverede færdigheder.
• Historik = valgte vendinger fra trin 2.
• Brugerbesked = beskeden fra den aktuelle vending.

Modellen svarer enten af to ting:

• Endelig svar (direkte tekst til klienten).
• Tool call (anmodning om at udføre en specifik færdighed med parametre).

I eksemplet "quero marke til søndag morgen", modellen typisk returnerer:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 til 12:00" }
}

Trin 5 — Udførelse med vandhjul (variabel, ~100-500ms)

Færdigheden ikke køres i modellen. Den køres i vores kode, der:

...

1. Validering af parametre (date_range har den korrekte format? er det inden for tenantens regler?).
2. Tjekker tilladelse (er dette agent har tilladelse til at spørge efter dette kalender?).
3. Udvores API-anmodning (Google Calendar API i dette tilfælde).
4. Returnerer struktureret resultat til model.

Hvorfor er det vigtigt? Fordi modellet aldrig fabrikerer resultatet selv. Hvis kalenderen returnerer [10h, 11h], er det præcis det, der går videre til næste anmodning. Hvis skillets fejler, ved modellet, at det fejler. Der er ingen risiko for, at agenten "skaber" en tid på 9h, når der ikke er nogen.

I tilfælde, hvor der er involveret følsomme informationer (pris, frist, kundens navn), kræver pipeline'en tool call - og lader ikke modellet svare fra eget "kendskab". Dette fjerner den mest almindelige klasse af hallucination i kommersielle agenter.

Fase 6 - Svar og persistens (~50ms)

Med skillets resultat i hånden gør modellet den anden anmodning - nu til at forme det endelige svar til kunden. Eksempel:

"Jeg har lørdag på 10h og 11h. Hvilken foretrækker du?"

Samtidig gør arbejderen:

1. Sender beskeden tilbage via WhatsApp-API.
2. Opslår hele tur (bruger + assistent + tool-anmodninger + varighed) på D1.
3. Opdaterer den lange-termiske hukommelse hvis turret producerer et nyt faktum (eks. "kunden foretrækker lørdag").
4. Udsender observabilitets-event (latens-måling, token-kost, skalaerings-hastighed).

Alt dette køres i parallelle. Persistensen blokkerer ikke beskeden - kunden venter ikke på D1.

---

Hvor er forsvarsklæderne mod hallucination

En agent, der hallucinerer i produktion, taber hurtigt tilliden. OpenClaw har 4 linjer af forsvar:

1. Kilde af sandhed forceret. Fakta (pris, tid, navn) kommer altid fra skillets, aldrig fra modellet selv.
2. Dobbelt kontrol i følsomme data. Agendement er bekræftet med kunden før opslag. Betaling er bekræftet før adgang tilgives.
3. Eksplicitke negativ regler. Personen for hver agent inkluderer "når aldrig opfinde X, Y, Z" - modellet følger.
4. Fald tilbage til menneske. Når ingen skillets dækker spørgsmålet, siger agenten "Lad mig tjekke med holdet" og åbner en ticket - ikke kaster.

I de sidste 6 måneder har vi gjort flere auditorier (konkrete konversationer revist manualt), og alucinationstabet i følsomme data er under 0,3% af tur - og de fleste tilfælde var på grund af konfig (tenanten havde glemt at aktivere relevant skillets), ikke fejl i modellet.

En god arkitektur er usynlig indtil du kigger på regningen. Medmindre hver tur gør 1-2 opkald til LLM + lookups i D1, bliver den gennemsnitlige omkostning pr. komplett konversation (10-15 tur) til:

(Note: I have translated the text exactly as per your requirements, preserving all markdown formatting and not translating URLs, code, or HTML tags.)