Bagaimana Agen AI Perbualan Berfungsi di Dalam

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

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

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

---

Mengapa seni bina penting

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

1. Latensi tinggi — pelanggan menunggu 8 saat untuk respons, perbualan mati.
2. Halusinasi tidak terkawal — ejen mencipta harga, waktu, polisi.
3. Konteks hilang — pelanggan kembali selepas 2 hari dan ejen "lupa" segala-galanya.
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 memahami adalah dengan melihat kitaran satu giliran.

---

Kitaran satu giliran (6 peringkat)

Bayangkan pelanggan baru sahaja menghantar mesej "saya nak buat temujanji untuk Sabtu pagi". 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 hampir secara geografi. Di Brazil, ini bermakna 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. Menormalkan payload — audio menjadi transkripsi, imej menjadi penerangan, lokasi menjadi {lat,lng}, teks kekal seperti sedia ada.

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

Peringkat 2 — Resolve 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, nota).
• Status agen (persona, kemahiran yang diaktifkan, peraturan).

Semuanya datang dari 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: kita tidak memuatkan keseluruhan perbualan 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 kemahiran (policy engine, ~20ms)

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

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

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

Pada akhirnya anda mempunyai subset kecil kemahiran yang dihantar ke model — bukan 50 yang mungkin, hanya 4 yang masuk akal di sini. Ini mengurangkan secara drastik kemungkinan model memanggil kemahiran yang salah.

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

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

• System prompt = persona agen + peraturan + kemahiran yang tersedia.
• History = giliran yang dipilih dalam peringkat 2.
• User message = mesej giliran semasa.

Model membalas salah satu daripada dua perkara:

• Respons akhir (teks terus kepada pelanggan).
• Tool call (permintaan untuk melaksanakan kemahiran 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)

Kemahiran tidak berjalan dalam model. Ia berjalan dalam kod kami, yang:

1. Mengesahkan parameter (adakah date_range mempunyai format yang betul? adakah ia mematuhi peraturan tenant?).
2. Memeriksa kebenaran (adakah ejen ini mempunyai hak untuk mengakses 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 hasil. Jika kalendar mengembalikan [10h, 11h], itulah yang akan dihantar ke panggilan seterusnya. Jika skill gagal, model tahu ia gagal. Tiada risiko ejen "mencipta" bahawa terdapat masa lapang pada 9h apabila tidak ada.

Untuk kes yang melibatkan maklumat sensitif (harga, tarikh akhir, 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 kegigihan (~50ms)

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

"Saya ada hari Sabtu pada 10h dan 11h. 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. Mengemaskini memori jangka panjang jika giliran menghasilkan fakta baru (contoh: "pelanggan lebih suka hari Sabtu").
4. Mengeluarkan peristiwa kebolehamatan (metrik latensi, kos token, kadar peningkatan).

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

---

Di mana pertahanan terhadap halusinasi

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

1. Source-of-truth dipaksa. Data fakta (harga, masa, nama) sentiasa datang dari skill, tidak pernah dari model sahaja.
2. Pengesahan berganda pada data sensitif. Penjadualan disahkan dengan pelanggan sebelum disimpan. Pembayaran disahkan sebelum memberikan akses.
3. Peraturan negatif eksplisit. Persona setiap ejen termasuk "jangan sekali-kali cipta X, Y, Z" — model mematuhi.
4. Fallback kepada manusia. Apabila tiada skill meliputi soalan, ejen berkata "biar saya semak dengan pasukan" dan membuka tiket — tidak meneka.

Dalam audit yang kami lakukan dalam 6 bulan terakhir (perbualan sebenar disemak secara manual), kadar halusinasi fakta kekal di bawah 0,3% daripada giliran — dan hampir semua kes adalah disebabkan oleh konfigurasi (tenant terlupa mengaktifkan skill yang relevan), 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 biasa bagi setiap perbualan lengkap (10-15 giliran) adalah: