Miten Keskusteleva Tekoälyagentti Toimii Sisältä

Kuinka keskusteleva tekoälyagentti toimii sisältä (OpenClaw-arkkitehtuuri)

Kuinka keskusteleva tekoälyagentti toimii käytännössä, vuoro vuorolta? Tämä postaus avaa OpenClaw'n mustan laatikon: siitä hetkestä kun asiakkaan viesti saapuu WhatsAppiin siihen tekstiin, jonka agentti kirjoittaa takaisin. Tämä tulee olemaan teknistä. Kannattaa lukea, jos päätät tuotearkkitehtuurista, jos aiot ostaa ratkaisun ja haluat arvioida sen syvyyttä, tai jos haluat tietää mitä keskustelun takana tapahtuu.

TL;DR: jokainen vuoro käy läpi 6 vaihetta — ingest, kontekstin selvitys, taitojen valinta, seuraavan toiminnon päätös, suoritus suojakaiteilla, muistin tallennus. Koko sykli toimii <2 sekunnissa Cloudflaren reunalla, ilman kiinteää palvelinta.

---

Miksi arkkitehtuuri on tärkeä

Keskusteleva agentti, joka näyttää toimivan demossa mutta hajoaa tuotannossa, kärsii yleensä yhdestä näistä 4 ongelmasta:

1. Korkea latenssi — asiakas odottaa 8 sekuntia vastausta, keskustelu kuolee.
2. Hallitsematon hallusinaatio — agentti keksii hinnan, ajan, käytännön.
3. Menetetty konteksti — asiakas palaa 2 päivän jälkeen ja agentti "unohtaa" kaiken.
4. Hallitsemattomat kustannukset — jokainen pitkä keskustelu täyttää promptin ja maksat omaisuuden tokeneista.

Kaikki 4 ovat arkkitehtuurivalintoja, eivät mallin rajoituksia. OpenClaw rakennettiin välttämään kaikki 4 — ja tapa ymmärtää tämä on tarkastella vuoron sykliä.

---

Vuoron sykli (6 vaihetta)

Kuvittele, että asiakas on juuri lähettänyt viestin "haluan varata lauantaiaamuun". Mitä tapahtuu "received"-ilmoituksen ja agentin vastauksen välillä?

Vaihe 1 — Ingest (edge worker, <50ms)

WhatsApp-viesti saapuu Metan webhookin kautta suoraan Cloudflare Workeriin lähimmässä maantieteellisessä läsnäolopisteessä (PoP). Brasiliassa tämä tarkoittaa São Pauloa tai Riota, verkkolatenssi < 20ms.

Worker tekee kolme asiaa:

1. Validoi webhookin allekirjoituksen (HMAC WABA:n salaisuutta vastaan).
2. Tunnistaa vuokraajan vastaanottajan puhelinnumeron perusteella (multi-tenant to_number-arvon mukaan).
3. Normalisoi payloadin — ääni muuttuu transkriptioksi, kuva kuvaukseksi, sijainti muotoon {lat,lng}, teksti pysyy sellaisenaan.

Vaiheen 1 lopussa sinulla on objekti {tenant_id, conversation_id, user_message} valmiina seuraavaa vaihetta varten.

Vaihe 2 — Kontekstin selvitys (D1 + KV, ~80ms)

Agentti tarvitsee 3 kontekstin osaa ennen päätöksentekoa:

• Viimeaikainen historia keskustelusta (viimeiset N relevanttia vuoroa).
• Pitkäaikainen muisti asiakkaasta (mieltymykset, ostohistoria, muistiinpanot).
• Agentin tila (persoona, käytössä olevat taidot, säännöt).

Kaikki tulevat D1:stä (Cloudflaren hajautettu SQLite). D1 korvaa perinteisen Postgres/Mongo -ratkaisun — ei tietokantapalvelinta ylläpidettäväksi, pääsy muutamassa millisekunnissa workerista, multi-tenant tenant_id:n kautta.

Keskeinen kohta: me emme lataa koko keskustelua promptiin. OpenClaw'n Memory Manager v2 (kuvattu sisäisessä dokumentaatiossa) valitsee vain nykyiselle vuorolle relevantit vuorot (viimeiset N + N semanttisesti erittäin relevanttia). Tämä pitää token-kustannukset ennustettavina jopa 100+ vuoron keskusteluissa.

Vaihe 3 — Taitojen valinta (policy engine, ~20ms)

Jokaisella agentilla on joukko saatavilla olevia taitoja — funktioita, joita se voi kutsua. Esimerkkejä: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Kun viesti on "quero marcar pra sábado de manhã", policy engine suodattaa:

• Havaitun intention kanssa yhteensopivat taidot (ajanvaraus).
• Taidot, jotka ovat sallittuja tässä keskustelun vaiheessa (kaikki taidot eivät ole saatavilla koko ajan).
• Taidot, jotka tämä tenant on ottanut käyttöön (kalenteri näkyy vain, jos tenant on integroinut sen).

Lopulta saat pienen osajoukon taitoja, jotka välitetään mallille — ei kaikkia 50 mahdollista, vain ne 4, jotka ovat järkeviä tässä. Tämä vähentää dramaattisesti todennäköisyyttä, että malli kutsuu väärää taitoa.

Vaihe 4 — Päätös (LLM-kutsu, 400-1200ms)

Nyt malli tulee mukaan. OpenClaw tekee yhden kutsun huippuluokan LLM:ään (Anthropic Claude, OpenAI GPT, Google Gemini — konfiguroitavissa tenanttikohtaisesti) seuraavilla tiedoilla:

• System prompt = agentin persoona + säännöt + saatavilla olevat taidot.
• History = vaiheessa 2 valitut vuorot.
• User message = nykyisen vuoron viesti.

Malli vastaa kahdella tavalla:

• Lopullinen vastaus (suora teksti asiakkaalle).
• Tool call (pyyntö suorittaa tietty taito parametreilla).

Esimerkissä "quero marcar pra sábado de manhã" malli tyypillisesti palauttaa:

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

Vaihe 5 — Suoritus guard-raileilla (vaihteleva, ~100-500ms)

Taito ei toimi mallissa. Se toimii meidän koodissamme, joka:

1. Validoi parametrit (onko date_range oikeassa muodossa? onko se vuokraajan sääntöjen mukainen?).
2. Tarkistaa käyttöoikeuden (onko tällä agentilla oikeus tarkastella tätä kalenteria?).
3. Suorittaa kutsun (Google Calendar API tässä tapauksessa).
4. Palauttaa jäsennellyn tuloksen mallille.

Miksi tämä on tärkeää? Koska malli ei koskaan keksi tulosta. Jos kalenteri palauttaa [10h, 11h], juuri se menee seuraavaan kutsuun. Jos taito epäonnistuu, malli tietää sen epäonnistuneen. Nolla riskiä siitä, että agentti "keksii" ajan olevan klo 9, kun sitä ei ole.

Tapauksissa, jotka sisältävät arkaluonteista tietoa (hinta, määräaika, asiakkaan nimi), pipeline pakottaa tool call -toiminnon — ei anna mallin vastata omasta "tiedostaan". Tämä eliminoi yleisimmän hallusinaatioluokan kaupallisissa agenteissa.

Vaihe 6 — Vastaus ja pysyvyys (~50ms)

Kun taidon tulos on käsillä, malli tekee toisen kutsun — nyt muodostaakseen lopullisen vastauksen asiakkaalle. Esim:

"Minulla on lauantaina klo 10 ja 11. Kumman haluat?"

Samanaikaisesti worker:

1. Lähettää viestin takaisin WhatsApp API:n kautta.
2. Tallentaa koko kierroksen (user + assistant + tool calls + kesto) D1:een.
3. Päivittää pitkäaikaisen muistin, jos kierros tuotti uuden faktan (esim: "asiakas suosii lauantaita").
4. Lähettää havaittavuustapahtuman (latenssin mittari, token-kustannus, eskalaationopeus).

Kaikki tämä toimii rinnakkain. Pysyvyys ei estä viestin lähettämistä — asiakas ei odota D1:tä.

---

Missä on puolustus hallusinaatiota vastaan

Agentti, joka hallusinoi tuotannossa, menettää luottamuksen nopeasti. OpenClawlla on 4 puolustuslinjaa:

1. Pakotettu totuuden lähde. Faktatiedot (hinta, aika, nimi) tulevat aina taidosta, ei koskaan pelkästään mallista.
2. Kaksinkertainen tarkistus arkaluonteisissa tiedoissa. Varaus vahvistetaan asiakkaan kanssa ennen tallentamista. Maksu vahvistetaan ennen käyttöoikeuden myöntämistä.
3. Eksplisiittiset kieltosäännöt. Jokaisen agentin persoonaan sisältyy "älä koskaan keksi X, Y, Z" — malli tottelee.
4. Varajärjestely ihmiselle. Kun mikään taito ei kata kysymystä, agentti sanoo "anna kun tarkistan tiimiltä" ja avaa tiketin — ei arvaa.

Viimeisten 6 kuukauden aikana tekemissämme auditoinneissa (todelliset keskustelut tarkistettu manuaalisesti) faktuaalisen hallusinaation osuus jäi alle 0,3 % kierroksista — ja lähes kaikki tapaukset johtuivat konfiguraatiosta (vuokraaja unohti ottaa käyttöön relevantin taidon), eivät mallin virheestä.

---

Kustannus per keskustelu

Hyvä arkkitehtuuri on näkymätön, kunnes katsot laskua. Koska jokainen vuoro tekee 1-2 LLM-kutsua + D1-hakuja, tyypillinen kustannus täydellisestä keskustelusta (10-15 vuoroa) on: