Bagaimana Ejen AI Perbualan Berfungsi dari Dalam

Bagaimana Ejen AI Perbualan Berfungsi dari Dalam (Seni Bina OpenClaw)

Bagaimana ejen AI perbualan berfungsi dalam praktik, giliran demi giliran? Post ini membuka kotak hitam OpenClaw: dari saat mesej pelanggan tiba di WhatsApp hingga teks yang ejen tulis semula. Ia akan bersifat teknikal. Berbaloi jika anda membuat keputusan seni bina produk, jika anda ingin membeli penyelesaian dan mahu menilai secara mendalam, atau jika anda suka mengetahui apa yang berlaku di sebalik perbualan.

TL;DR: setiap giliran melalui 6 peringkat — ingest, selesaikan konteks, pilih skills, tentukan tindakan seterusnya, laksanakan dengan guard-rails, simpan memori. Keseluruhan kitaran berjalan dalam <2 saat di edge Cloudflare, tanpa pelayan tetap.

---

Mengapa seni bina itu penting

Ejen perbualan yang kelihatan berfungsi dalam demo tetapi rosak dalam produksi biasanya mempunyai satu daripada 4 masalah ini:

1. Latensi tinggi — pelanggan menunggu 8 saat untuk respons, perbualan mati.
2. Halusinasi tidak terkawal — ejen mereka-reka harga, waktu, polisi.
3. Konteks hilang — pelanggan kembali selepas 2 hari dan ejen "lupa" semuanya.
4. Kos tidak terkawal — setiap perbualan panjang memenuhi prompt dan anda membayar mahal untuk token.

Keempat-empatnya adalah pilihan seni bina, bukan batasan model. OpenClaw dibina untuk mengelakkan keempat-empatnya — dan cara untuk memahaminya adalah dengan melihat kitaran satu giliran.

---

Kitaran satu giliran (6 peringkat)

Bayangkan pelanggan baru sahaja menghantar mesej "quero marcar pra sábado de manhã". Apa yang berlaku antara "received" dan respons ejen?

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

Mesej WhatsApp tiba melalui webhook Meta terus ke Cloudflare Worker di titik kehadiran (PoP) yang paling dekat secara geografi. Di Brazil, ini bermaksud São Paulo atau Rio, latensi rangkaian < 20ms.

Worker melakukan tiga perkara:

1. Mengesahkan tandatangan webhook (HMAC terhadap rahsia WABA).
2. Mengenal pasti tenant melalui nombor telefon penerima (multi-tenant mengikut to_number).
3. Menormalisasi payload — audio ditukar kepada transkripsi, imej ditukar kepada penerangan, lokasi ditukar kepada {lat,lng}, teks kekal seperti sedia ada.

Di akhir peringkat 1 anda mempunyai objek {tenant_id, conversation_id, user_message} yang sedia untuk langkah seterusnya.

Peringkat 2 — Selesaikan konteks (D1 + KV, ~80ms)

Ejen memerlukan 3 bahagian konteks sebelum membuat keputusan:

• Sejarah terkini perbualan (N giliran terakhir yang relevan).
• Memori jangka panjang pelanggan (keutamaan, sejarah pembelian, catatan).
• Keadaan ejen (persona, skills yang diaktifkan, peraturan).

Semuanya datang daripada D1 (SQLite teragih Cloudflare). D1 menggantikan Postgres/Mongo tradisional — tiada pelayan pangkalan data untuk diselenggara, akses dalam beberapa ms dari worker, multi-tenant melalui tenant_id.

Perkara utama: kami tidak memuatkan keseluruhan perbualan ke dalam prompt. Memory Manager v2 OpenClaw (diterangkan dalam dokumentasi dalaman kami) memilih hanya giliran yang relevan untuk giliran semasa (N terakhir + N dengan relevansi semantik tinggi). Ini mengekalkan kos token yang boleh diramal walaupun dalam perbualan 100+ giliran.

Peringkat 3 — Pemilihan skills (policy engine, ~20ms)

Setiap ejen mempunyai satu set skills yang tersedia — fungsi yang boleh dipanggilnya. Contoh: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Berdasarkan mesej "quero marcar pra sábado de manhã", policy engine menapis:

• Skills yang serasi dengan niat yang dikesan (penjadualan).
• Skills yang dibenarkan untuk fasa perbualan ini (tidak semua skill tersedia sepanjang masa).
• Skills yang tenant ini telah aktifkan (calendar hanya muncul jika tenant telah mengintegrasikannya).

Akhirnya anda mempunyai subset kecil skills yang dihantar kepada model — bukan 50 yang mungkin, hanya 4 yang relevan di sini. Ini mengurangkan secara drastik kemungkinan model memanggil skill yang salah.

Peringkat 4 — Keputusan (LLM call, 400-1200ms)

Sekarang model masuk. OpenClaw membuat satu panggilan tunggal kepada LLM frontier (Anthropic Claude, OpenAI GPT, Google Gemini — boleh dikonfigurasi mengikut tenant) dengan:

• System prompt = persona ejen + peraturan + skills yang tersedia.
• History = giliran yang dipilih pada peringkat 2.
• User message = mesej giliran semasa.

Model menjawab salah satu daripada dua perkara:

• Respons akhir (teks terus kepada pelanggan).
• Tool call (permintaan untuk melaksanakan skill tertentu dengan parameter).

Dalam contoh "quero marcar pra sábado de manhã", model biasanya mengembalikan:

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

Peringkat 5 — Pelaksanaan dengan guard-rails (berubah-ubah, ~100-500ms)

Skill tidak dijalankan dalam model. Ia dijalankan dalam kod kami, yang:

1. Mengesahkan parameter (date_range mempunyai format yang betul? adakah ia mematuhi peraturan tenant?).
2. Menyemak kebenaran (adakah ejen ini mempunyai hak untuk menyemak kalendar ini?).
3. Melaksanakan panggilan (Google Calendar API dalam kes ini).
4. Mengembalikan hasil berstruktur kepada model.

Mengapa ini penting? Kerana model tidak pernah mereka-reka hasil. Jika kalendar mengembalikan [10h, 11h], itulah tepat yang akan dihantar ke panggilan seterusnya. Jika skill gagal, model tahu ia gagal. Sifar risiko ejen "mencipta" bahawa ada slot pada jam 9 pagi sedangkan tiada.

Untuk kes yang melibatkan maklumat sensitif (harga, tempoh masa, nama pelanggan), pipeline memaksa tool call — tidak membenarkan model menjawab daripada "pengetahuan" sendiri. Ini menghapuskan kelas halusinasi yang paling biasa dalam ejen komersial.

Peringkat 6 — Respons dan persistensi (~50ms)

Dengan hasil skill di tangan, model membuat panggilan kedua — kali ini untuk membentuk respons akhir kepada pelanggan. Contoh:

"Saya ada hari Sabtu pada jam 10 pagi dan 11 pagi. Yang mana anda pilih?"

Secara selari, worker:

1. Menghantar mesej kembali melalui API WhatsApp.
2. Menyimpan giliran lengkap (user + assistant + tool calls + tempoh) dalam D1.
3. Mengemas kini memori jangka panjang jika giliran menghasilkan fakta baharu (contoh: "pelanggan lebih suka hari Sabtu").
4. Mengeluarkan peristiwa kebolehcerapan (metrik kependaman, kos token, kadar eskalasi).

Semua ini berjalan secara selari. Persistensi tidak menyekat penghantaran mesej — pelanggan tidak menunggu D1.

---

Di mana pertahanan terhadap halusinasi

Ejen yang berhalusinasi dalam produksi kehilangan kepercayaan dengan cepat. OpenClaw mempunyai 4 barisan pertahanan:

1. Sumber kebenaran dipaksa. Data faktual (harga, waktu, nama) sentiasa datang daripada skill, bukan daripada model sahaja.
2. Pengesahan berganda pada data sensitif. Penjadualan disahkan dengan pelanggan sebelum disimpan. Pembayaran disahkan sebelum akses diberikan.
3. Peraturan negatif yang eksplisit. Persona setiap ejen termasuk "jangan sesekali mereka-reka X, Y, Z" — model mematuhinya.
4. Fallback kepada manusia. Apabila tiada skill yang meliputi soalan tersebut, ejen berkata "biar saya semak dengan pasukan" dan membuka tiket — bukan meneka.

Dalam audit yang kami lakukan sepanjang 6 bulan terakhir (perbualan sebenar disemak secara manual), kadar halusinasi faktual kekal di bawah 0.3% daripada giliran — dan hampir semua kes disebabkan oleh konfigurasi (tenant terlupa untuk mengaktifkan skill yang berkaitan), bukan kesilapan model.

---

Kos setiap perbualan

Seni bina yang baik adalah tidak kelihatan sehingga anda melihat invois. Memandangkan setiap giliran membuat 1-2 panggilan LLM + carian dalam D1, kos tipikal bagi setiap perbualan lengkap (10-15 giliran) adalah: