สถาปัตยกรรมภายในของเอเจนต์ AI สนทนาทำงานอย่างไร

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

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

TL;DR: แต่ละรอบผ่าน 6 ขั้นตอน — รับข้อมูล, แก้ไขบริบท, เลือกทักษะ, ตัดสินใจการกระทำถัดไป, ดำเนินการด้วย guard-rails, บันทึกความจำ วงจรทั้งหมดทำงานใน <2 วินาทีบน edge ของ Cloudflare โดยไม่มีเซิร์ฟเวอร์คงที่

---

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

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

1. เวลาแฝงสูง — ลูกค้ารอ 8 วินาทีสำหรับการตอบกลับ การสนทนาตาย
2. ภาพหลอนที่ไม่สามารถควบคุมได้ — เอเจนต์สร้างราคา เวลา นโยบาย
3. บริบทสูญหาย — ลูกค้ากลับมาหลังจาก 2 วันและเอเจนต์ "ลืม" ทุกอย่าง
4. ต้นทุนที่ไม่สามารถควบคุมได้ — การสนทนายาวแต่ละครั้งเติมเต็มพรอมต์และคุณจ่ายเงินมากมายสำหรับโทเค็น

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

---

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

ลองนึกภาพว่าลูกค้าเพิ่งส่งข้อความ "อยากนัดวันเสาร์ตอนเช้า" เกิดอะไรขึ้นระหว่าง "received" และการตอบกลับของเอเจนต์?

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

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

Worker ทำสามสิ่ง:

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

ในตอนท้ายของขั้นตอนที่ 1 คุณมีออบเจ็กต์ {tenant_id, conversation_id, user_message} พร้อมสำหรับขั้นตอนถัดไป

ขั้นตอนที่ 2 — แก้ไขบริบท (D1 + KV, ~80ms)

เอเจนต์ต้องการบริบท 3 ชิ้นก่อนตัดสินใจ:

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

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

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

ขั้นตอนที่ 3 — การเลือกทักษะ (policy engine, ~20ms)

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

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

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

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

ขั้นตอนที่ 4 — การตัดสินใจ (LLM call, 400-1200ms)

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

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

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

• คำตอบสุดท้าย (ข้อความโดยตรงสำหรับลูกค้า)
• Tool call (คำขอให้ดำเนินการทักษะเฉพาะด้วยพารามิเตอร์)

ในตัวอย่าง "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)

ทักษะไม่ทำงานในโมเดล มันทำงานในโค้ดของเราที่:

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

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

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

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

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

"มีวันเสาร์เวลา 10 โมงและ 11 โมง คุณชอบเวลาไหน?"

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

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

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

---

การป้องกันการหลอนลวงอยู่ที่ไหน

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

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

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

---

ต้นทุนต่อการสนทนา

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