AI Conversational Agent ทำงานอย่างไรภายใน

วิธีการทำงานภายในของ AI Agent สำหรับการสนทนา (สถาปัตยกรรม OpenClaw)

AI agent สำหรับการสนทนาทำงานอย่างไร ในทางปฏิบัติ ทีละรอบ? โพสต์นี้เปิดกล่องดำของ OpenClaw: ตั้งแต่ช่วงเวลาที่ข้อความของลูกค้ามาถึง WhatsApp จนถึงข้อความที่ agent เขียนตอบกลับ จะเป็นเนื้อหาเชิงเทคนิค คุ้มค่าถ้าคุณเป็นคนตัดสินใจเรื่องสถาปัตยกรรมผลิตภัณฑ์ ถ้าคุณจะซื้อโซลูชันและต้องการประเมินอย่างลึกซึ้ง หรือถ้าคุณชอบรู้ว่าเบื้องหลังการสนทนาเกิดอะไรขึ้น

TL;DR: แต่ละรอบผ่าน 6 ขั้นตอน — ingest, resolve context, เลือก skills, ตัดสินใจ action ถัดไป, execute พร้อม guard-rails, persist memory ทั้งวงจรทำงานใน <2 วินาทีบน edge ของ Cloudflare โดยไม่ต้องมีเซิร์ฟเวอร์ถาวร

---

ทำไมสถาปัตยกรรมถึงสำคัญ

Agent สนทนาที่ดูเหมือนทำงานได้ในเดโมแต่พังในโปรดักชัน มักจะมี 1 ใน 4 ปัญหาเหล่านี้:

1. Latency สูง — ลูกค้ารอ 8 วินาทีเพื่อรับคำตอบ การสนทนาตายไป
2. Hallucination ที่ควบคุมไม่ได้ — agent แต่งราคา เวลา นโยบายขึ้นมาเอง
3. Context หาย — ลูกค้ากลับมาหลังจาก 2 วันแล้ว agent "ลืม" ทุกอย่าง
4. ต้นทุนควบคุมไม่ได้ — การสนทนายาวๆ แต่ละครั้งทำให้ prompt เต็มและคุณจ่ายค่า token มหาศาล

ทั้ง 4 ข้อเป็นเรื่องของการเลือกสถาปัตยกรรม ไม่ใช่ข้อจำกัดของโมเดล OpenClaw ถูกสร้างมาเพื่อหลีกเลี่ยงทั้ง 4 ข้อ — และทางที่จะเข้าใจคือดูวงจรของแต่ละรอบ

---

วงจรของหนึ่งรอบ (6 ขั้นตอน)

ลองนึกภาพว่าลูกค้าเพิ่งส่งข้อความ "quero marcar pra sábado de manhã" สิ่งที่เกิดขึ้นระหว่าง "received" กับคำตอบของ agent คืออะไร?

ขั้นตอนที่ 1 — Ingest (edge worker, <50ms)

ข้อความจาก WhatsApp มาถึงผ่าน webhook ของ Meta ตรงเข้า Cloudflare Worker ที่จุดให้บริการ (PoP) ที่ใกล้ที่สุดทางภูมิศาสตร์ ในบราซิล หมายถึงเซาเปาลูหรือรีโอ latency ของเครือข่าย < 20ms

Worker ทำ 3 สิ่ง:

1. ตรวจสอบ signature ของ webhook (HMAC เทียบกับ secret ของ WABA)
2. ระบุ tenant จากหมายเลขโทรศัพท์ของผู้รับ (multi-tenant โดย to_number)
3. Normalize payload — เสียงถูกแปลงเป็นข้อความถอดเสียง, รูปภาพถูกแปลงเป็นคำอธิบาย, ตำแหน่งถูกแปลงเป็น {lat,lng}, ข้อความคงไว้ตามเดิม

เมื่อจบขั้นตอนที่ 1 คุณจะได้ object {tenant_id, conversation_id, user_message} พร้อมสำหรับขั้นตอนถัดไป

ขั้นตอนที่ 2 — Resolve context (D1 + KV, ~80ms)

Agent ต้องการ context 3 ส่วนก่อนตัดสินใจ:

• ประวัติล่าสุด ของการสนทนา (N เทิร์นล่าสุดที่เกี่ยวข้อง)
• หน่วยความจำระยะยาว ของลูกค้า (ความชอบ, ประวัติการซื้อ, บันทึก)
• สถานะของเอเจนต์ (เพอร์โซนา, skills ที่เปิดใช้งาน, กฎ)

ทั้งหมดมาจาก D1 (SQLite แบบกระจายของ Cloudflare) D1 ทดแทน Postgres/Mongo แบบดั้งเดิม — ไม่ต้องดูแลเซิร์ฟเวอร์ฐานข้อมูล, เข้าถึงได้ในไม่กี่ ms จาก worker, รองรับ multi-tenant ด้วย tenant_id

จุดสำคัญ: เรา ไม่ได้โหลดการสนทนาทั้งหมด ลงใน prompt Memory Manager v2 ของ OpenClaw (อธิบายไว้ในเอกสารภายในของเรา) เลือกเฉพาะเทิร์นที่เกี่ยวข้องกับเทิร์นปัจจุบัน (N ล่าสุด + N ที่มีความเกี่ยวข้องเชิงความหมายสูง) สิ่งนี้ทำให้ต้นทุนโทเค็นคาดการณ์ได้แม้ในการสนทนาที่มี 100+ เทิร์น

สเตจ 3 — การเลือก skills (policy engine, ~20ms)

แต่ละเอเจนต์มีชุดของ skills ที่พร้อมใช้งาน — ฟังก์ชันที่สามารถเรียกใช้ได้ ตัวอย่าง: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano

เมื่อได้รับข้อความ "quero marcar pra sábado de manhã" policy engine จะกรอง:

• Skills ที่เข้ากันได้กับ เจตนาที่ตรวจจับได้ (การนัดหมาย)
• Skills ที่อนุญาตสำหรับ ขั้นตอนนี้ของการสนทนา (ไม่ใช่ทุก skill จะพร้อมใช้งานตลอดเวลา)
• Skills ที่ tenant นี้เปิดใช้งาน (calendar จะปรากฏเฉพาะเมื่อ tenant ได้ทำการเชื่อมต่อแล้ว)

ในท้ายที่สุดคุณจะได้ชุดย่อยเล็กๆ ของ skills ที่ส่งให้โมเดล — ไม่ใช่ 50 ตัวที่เป็นไปได้ทั้งหมด แค่ 4 ตัวที่สมเหตุสมผลในบริบทนี้ สิ่งนี้ลดโอกาสที่โมเดลจะเรียกใช้ skill ผิดได้อย่างมาก

สเตจ 4 — การตัดสินใจ (LLM call, 400-1200ms)

ตอนนี้โมเดลเข้ามาทำงาน OpenClaw ทำการเรียก LLM ระดับแนวหน้าครั้งเดียว (Anthropic Claude, OpenAI GPT, Google Gemini — กำหนดค่าได้ตาม tenant) โดยมี:

• System prompt = เพอร์โซนาของเอเจนต์ + กฎ + skills ที่พร้อมใช้งาน
• History = เทิร์นที่เลือกในสเตจ 2
• User message = ข้อความของเทิร์นปัจจุบัน

โมเดลตอบกลับ หนึ่งในสองอย่าง:

• คำตอบสุดท้าย (ข้อความส่งตรงถึงลูกค้า)
• Tool call (คำขอให้เรียกใช้ skill เฉพาะพร้อมพารามิเตอร์)

ในตัวอย่าง "quero marcar pra sábado de manhã" โมเดลมักจะส่งกลับ:

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

สเตจ 5 — การดำเนินการพร้อม guard-rails (ไม่แน่นอน, ~100-500ms)

Skill ไม่ได้ ทำงานในโมเดล มันทำงานในโค้ดของเรา ซึ่ง:

1. ตรวจสอบพารามิเตอร์ (date_range มีรูปแบบถูกต้องหรือไม่? อยู่ภายในกฎของ tenant หรือไม่?).
2. ตรวจสอบสิทธิ์ (เอเจนต์นี้มีสิทธิ์เข้าถึงปฏิทินนี้หรือไม่?).
3. ดำเนินการเรียก (Google Calendar API ในกรณีนี้).
4. ส่งผลลัพธ์ที่มีโครงสร้าง กลับไปยังโมเดล.

ทำไมสิ่งนี้ถึงสำคัญ? เพราะ โมเดลไม่เคยสร้างผลลัพธ์ขึ้นมาเอง ถ้าปฏิทินส่งกลับ [10h, 11h] นั่นคือสิ่งที่จะถูกส่งไปยังการเรียกครั้งถัดไปอย่างแม่นยำ ถ้า skill ล้มเหลว โมเดลจะรู้ว่าล้มเหลว ไม่มีความเสี่ยงที่เอเจนต์จะ "แต่งขึ้น" ว่ามีเวลาว่างตอน 9 โมงทั้งที่ไม่มี

สำหรับกรณีที่เกี่ยวข้องกับข้อมูลที่ละเอียดอ่อน (ราคา, กำหนดเวลา, ชื่อลูกค้า) ไปป์ไลน์จะบังคับใช้ tool call — ไม่ปล่อยให้โมเดลตอบจาก "ความรู้" ของตัวเอง สิ่งนี้ กำจัดประเภทของ hallucination ที่พบบ่อยที่สุดในเอเจนต์เชิงพาณิชย์

ขั้นตอนที่ 6 — การตอบกลับและการบันทึกข้อมูล (~50ms)

เมื่อได้ผลลัพธ์จาก skill แล้ว โมเดลจะทำการเรียกครั้งที่สอง — คราวนี้เพื่อสร้างคำตอบสุดท้ายให้ลูกค้า ตัวอย่าง:

"มีวันเสาร์ 10 โมงและ 11 โมงค่ะ เลือกเวลาไหนดีคะ?"

ในขณะเดียวกัน worker จะ:

1. ส่ง ข้อความกลับผ่าน API ของ WhatsApp.
2. บันทึก เทิร์นทั้งหมด (user + assistant + tool calls + ระยะเวลา) ลงใน D1.
3. อัปเดตหน่วยความจำระยะยาว หากเทิร์นนั้นสร้างข้อเท็จจริงใหม่ (เช่น: "ลูกค้าชอบวันเสาร์").
4. ส่งอีเวนต์ observability (เมตริกความหน่วง, ต้นทุนโทเค็น, อัตราการส่งต่อให้มนุษย์).

ทั้งหมดนี้ทำงานแบบขนาน การบันทึกข้อมูล ไม่บล็อก การส่งข้อความ — ลูกค้าไม่ต้องรอ D1

---

แนวป้องกัน Hallucination อยู่ตรงไหน

เอเจนต์ที่เกิด hallucination ในโปรดักชันจะสูญเสียความไว้วางใจอย่างรวดเร็ว OpenClaw มีแนวป้องกัน 4 ชั้น:

1. บังคับใช้แหล่งข้อมูลที่เชื่อถือได้ ข้อมูลเชิงข้อเท็จจริง (ราคา, เวลา, ชื่อ) มาจาก skill เสมอ ไม่เคยมาจากโมเดลเพียงอย่างเดียว.
2. การตรวจสอบซ้ำสำหรับข้อมูลที่ละเอียดอ่อน การนัดหมายจะได้รับการยืนยันกับลูกค้าก่อนบันทึก การชำระเงินจะได้รับการยืนยันก่อนเปิดสิทธิ์เข้าถึง.
3. กฎเชิงลบที่ชัดเจน Persona ของแต่ละเอเจนต์รวมถึง "ห้ามแต่งเรื่อง X, Y, Z" — โมเดลจะปฏิบัติตาม.
4. Fallback ไปยังมนุษย์ เมื่อไม่มี skill ใดครอบคลุมคำถาม เอเจนต์จะบอกว่า "ขอเช็คกับทีมก่อนนะคะ" และเปิดตั๋ว — ไม่เดาตอบ.

จากการตรวจสอบที่เราทำในช่วง 6 เดือนที่ผ่านมา (บทสนทนาจริงที่ตรวจสอบด้วยตนเอง) อัตรา hallucination เชิงข้อเท็จจริงอยู่ต่ำกว่า 0.3% ของเทิร์น — และเกือบทุกกรณีเกิดจากการตั้งค่า (tenant ลืมเปิดใช้งาน skill ที่เกี่ยวข้อง) ไม่ใช่ข้อผิดพลาดของโมเดล

---

ต้นทุนต่อบทสนทนา

สถาปัตยกรรมที่ดีนั้นมองไม่เห็นจนกว่าคุณจะดูใบแจ้งหนี้ เนื่องจากแต่ละเทิร์นทำการเรียก LLM 1-2 ครั้ง + lookups ใน D1 ต้นทุนโดยทั่วไปต่อการสนทนาทั้งหมด (10-15 เทิร์น) อยู่ที่: