Koks Funkciju IA Agentas Is Vidun?

Kaip veikia Išmanusis Agentas Konversacijoje (Archtitectorius OpenClaw)

Kaip veikia išmanusis agentas konversacijoje praktikoje, ratų po ratu? Šis postas atvėrė OpenClaw: nuo kliento žinutės, kuri atvyksta į WhatsApp, iki teksto, kurį agentas rašo atgal. Bus techniškas. Verta, jei jūs norite architektūros produktui, jei norite įsigyti sprendimą ir norite įvertinti pagrindą, ar jei jūs mėtatės žinoti, kas vyksta už konversacijos.

TL;DR: kiekvienas ratas praeina per 6 etapus — įsigyti, išspręsti kontekstą, pasirinkti kompetencijas, nustatyti sekančią veiką, vykdyti su riboženkliais, išlaikyti atmintį. Visas ciklas vyksta <sekundės Cloudflare edge, be fiksuoto serverio.

---

Kodėl architektūra yra svarbi

Konversacinis agentas, kuris atrodo veikiantis demonstracijoje, bet prasideda veikti produkcijoje, dažniausiai turi vienu iš šių 4 problemų:

1. Aukšta laikina — klientas laukia 8 sekundžių, kol gaus atsakymą, konversacija miršta.
2. Nevaldoma aluzija — agentas sukuria kainą, laiką, politika.
3. Prarasta kontekstas — klientas grįžta po 2 dienų ir agentas "išmėgina" viską.
4. Neprižiūrimas išlaidų — kiekviena ilga konversacija užpildo promptą ir jūs mokote daugiau už tokenus.

Visi 4 yra architektūros pasirinkimai, ne riboženkliai. OpenClaw buvo sukurta, kad išvengtų 4 — ir keliu, kuris leidžia suprasti, yra žiūrėti ciklo vieno rato.

---

Ciklas vieno rato (6 etapai)

Supraskite, kad klientas paskutinę kartą siuntė žinutę "norėčiau užsakyti už šeštąjį ryto". Ką vyksta tarp "gauta" ir agento atsakymo?

Etapas 1 — Įsigyti (edge worker, <ms)

Žinutė iš WhatsApp atvyksta per webhook iš Meta tiesiogiai į Cloudflare Worker priešpriešėje (PoP) geografiškai artimiausioje vietoje. Brazilijoje tai reiškia São Paulo ar Rio, laikinės siekės <0ms.

Darbuotojas dar tris dalykus:

1. Patvirtina signaturą webhook (HMAC prieš signatūrą WABA).
2. Identifikuoja klientą pagal telefono numerį (multi-tenant pagal to_number).
3. Normalizuoja payload — audio pakeičia transkripcija, nuotraukos pakeičia aprašymą, lokaciją pakeičia {lat,lng}, tekstas lieka taip pat.

Etapo 1 pabaigoje jūs turite objektą {tenant_id, conversation_id, user_message} gatavą kitam etapui.

Etapas 2 — Išspręsti kontekstą (D1 + KV, ~80ms)

Agentas reikia 3 konteksto dalių prieš nuspręsdamas:

• Istorija recenti konversacijos (paskutiniai N svarbūs posetai).
• Ilgo laiko atmintis kliento (preference, įsigijimo istorija, pastabos).
• Agento būsena (persona, įgalintos galimybės, taisyklės).

Visi atsiranda iš D1 (Cloudflare distribuotasis SQLite). D1 pakeičia tradicinį Postgres/Mongo be serverio - be serverio prieiga per darbuotoją, daugiausiai klientų naudojama tenant_id.

Svarbiausia: mes neįkeliame visą konversaciją į promptą. OpenClaw Memory Manager v2 (aprašytas mūsų interne dokumentacijoje) pasirenka tik svarbius posetai šiuo metu (paskutiniai N + N svarbių semantinių posetai). Tai išlaiko žodžių kiekį pranašęs, net ir konversacijose, kuriose yra daugiau nei 100 posetai.

Etapas 3 - Galimybių pasirinkimas (policy engine, ~20ms)

Kiekvienas agentas turi savo galimybių rinkinį - galimybes, kurias jis gali įvykdyti. Pavyzdžiai: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Dadamas žodis "quero marcar pra sábado de manhã", policy engine filtruos:

• Galimybės, kompatybės su detekuotą intencija (agendavimas).
• Galimybės, leidžiamos šiuo konversacijos etape (ne visos galimybės yra visada prieinamos).
• Galimybės, įgalintos šiam klientui (kalendorius rodomas tik jei klientas jį integruoja).

Galiausiai jūs turite mažą galimybių rinkinį, kuris yra priskirtas modeliui - ne 50 galimybių, o tik 4, kurios yra svarbios šiuo atveju. Tai drastiškai sumažina modelio galimybę įvykdyti neteisingą galimybę.

Etapas 4 - Sprendimas (LLM call, 400-1200ms)

Šiuo metu modelis įeina. OpenClaw atlieka vieną LLM frontiero (Anthropic Claude, OpenAI GPT, Google Gemini - konfigūruojama kliento pagalba) pasaulio promptą su:

• Sistema prompt = agento persona + taisyklės + galimybės.
• Istorija = pasirinkti posetai etape 2.
• Vartotojo žinutė = šiuo metu pasirinkta žinutė.

Modelis atsako duose variantuose:

• Pabaigos atsakymas (teksto tiesiogiai klientui).
• Galimybių pasirinkimas (prašymas įvykdyti konkrečią galimybę su parametrais).

Pavyzdžiui, žodis "quero marcar pra sábado de manhã", modelis paprastai grąžina:

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

Etapas 5 - Įvykdyti su apsaugos ribomis (kintamasis, ~100-500ms)

Galimybė ne vykdoma modeliu. Ji vykdoma mūsų kodo, kuris:

...

1. Patikėtiniai reglai:

• Išsaugokite visą markdown formavimą iš tiksliai (galvos ##, sąrašai -, žymėjimai, žymėjimai, nuorodos, kodų bloksai, ir pan.).
• Neseniai vertinkite nuorodas, kodą, arba HTML taškus.
• Neseniai pridėkite prieludžius ar komentarų.
• Išvesties tik vertintas markdown, nieko kitko.

Šaltinis markdown:

1. Patikrinti parametrus (date_range turi teisingą formatą? yra įprastų reglų?).
2. Patikrinti leidimą (šis agentas turi teisę klausyti šio kalendoriaus?).
3. Atlikti pavadą (Google Calendar API šiuo atveju).
4. Grąžinti struktūrius rezultatus modeliui.

Kodėl tai yra svarbu? Dėl to, kad modelis niekada nekuria rezultatų. Jei kalendorius grąžina [10h, 11h], tai tik tas, kas bus paskui prieš tai. Jei skillas nepavyks, modelis žino, kad nepavyko. Žrūsas rizika, kad agentas "išrado" laiką 9 val. kai jis nėra.

Kas reiškia, kad agentas, kuris susijungia su informacija (prekė, laikas, kliento vardas), pipeline priverčia tool call – nėra leidžiama modeliui atsakyti iš savo "žinčių". Tai panaikina dažniausią klaidą, kurią agentai voušia.

Etapas 6 – Atsakymas ir priežiūra (~50ms)

Su rezultatu, kurį gavo skill, modelis atlieka antrą pavadą – dabar, kad formuotų paskutinį atsakymą klientui. Pvz:

"Aš turiu šeštadienį 10 val. ir 11 val. Koks jūsų pasirinkimas?"

Paraleliu, darbuotojas:

1. Priešai pranešimą grąžinti per API WhatsApp.
2. Priežiūra visą posėdį (vartotojas + agentas + tool calls + trukmė) D1.
3. Atnaujina ilgalaikę atmintį jei posėdis sukūrė naują faktą (pvz: "klientas pasirinko šeštadienį").
4. Išleidžia observavimo įvykį (laikymo metriką, tokenų kainą, skalavimo rytą).

Viskas vyksta paraleliu. Priežiūra neprižiūri pranešimo siuntimą – klientas nėra laukia D1.

---

Kur yra gynyba prieš alucinaciją

Agentas, kuris alucinuoja, greitai praranda pasitikėjimą. OpenClaw turi 4 linijas gynybos:

1. Šaltinio tikėtina. Faktiniai duomenys (prekė, laikas, vardas) visada atsiranda iš skill, niekada iš modelio.
2. Dvigubas patikrinimas informacijos. Užsakymas patikrinamas su klientu prieš priežiūrą. Mokėjimas patikrinamas prieš leidžiant prieigą.
3. Išskirtinės negatyvios reglai. Kiekvieno agento persona yra "niekada nekurkite X, Y, Z" – modelis atitinka.
4. Atsitraukimas prie žmogaus. Kai nėra skill, kuris apima klausimą, agentas sako "deja, aš tikrinau su komanda" ir atidaro tiketą – nėra bėda.

Auditorijose, kurias aš atlikau paskutinius 6 mėnesius (realios konversacijos, peržiūrėtos ranka), alucinacijos faktų procentas buvo žemiau 0,3% posėdžių – ir visi atvejai buvo dėl konfig (tenantas atsisakė įjungti relevantų skill), ne modelio klaida.

---

Kainos posėdžio

Translated markdown (lt-LT):

Archtitktura gerai gerai yra nepastebima, kol jis matytas, kai žiūrima faktūra. Nustatęs, kad kiekvienas ratas atlieka 1-2 LLM pranešimus + D1 peržiūras, tipiškas pokyčio kainos už pilną pokalbą (10-15 ratų) yra:

• 1-2 LLM pranešimai:
• 1 LLM pranešimas: 0,001-0,005 USD
• 2 LLM pranešimai: 0,002-0,01 USD
• D1 peržiūros:
• 1 peržiūra: 0,0005-0,0025 USD
• 2 peržiūros: 0,001-0,005 USD
• Papildomi išlaidos (išvestis, serveriai, kt.): 0,01-0,1 USD
• Bendras kainos diapazonas: 0,012-0,12 USD