1. 「เหตุการณ์สำคัญ」คืออะไร

「เหตุการณ์สำคัญ」คือความสามารถด้านความจำทางธุรกิจระยะยาวที่มีในตัว GPTBots: ระหว่างที่ผู้ใช้สนทนากับ Bot ในหลายรอบ แพลตฟอร์มจะเรียกใช้ LLM เพื่อระบุเหตุการณ์ที่มีคุณค่าทางธุรกิจจากบทสนทนาโดยอัตโนมัติ (เช่น การถอนเงิน การร้องเรียน การจองนัด การคืนเงิน...) จัดเก็บอย่างเป็นโครงสร้างตามมิติของผู้ใช้ และนำกลับเข้ามาเป็นบริบทในบทสนทนาครั้งต่อ ๆ ไป เพื่อให้ Bot「จำได้」ว่าผู้ใช้คนนี้เคยเกิดอะไรขึ้นมาก่อน และเหตุการณ์ปัจจุบันดำเนินการไปถึงขั้นใดแล้ว

ปัญหาหลักที่แก้ไขได้คือ:

• การขาดความจำข้ามบทสนทนา: LLM แบบดั้งเดิมเห็นเฉพาะหน้าต่างความจำระยะสั้นของบทสนทนาปัจจุบันเท่านั้น การกระทำทางธุรกิจที่สำคัญจะถูกลืมเมื่อข้ามบทสนทนาหรือในบทสนทนาที่ยาว
• การสะสมข้อมูลที่เป็นโครงสร้าง: เปลี่ยนบทสนทนาที่กระจัดกระจายให้เป็นกระแสเหตุการณ์ที่สามารถสอบถาม สถิติ และตรวจสอบได้ เพื่อให้ฝ่ายควบคุมความเสี่ยง การตรวจสอบคุณภาพการบริการลูกค้า และการนำโปรไฟล์ผู้ใช้ไปใช้ซ้ำสามารถนำไปใช้ได้
• การติดตามการดำเนินการของสถานะ: เหตุการณ์แต่ละรายการมีสถานะ PENDING / IN_PROGRESS / RESOLVED / CLOSED ที่สามารถดำเนินการต่อเนื่องได้ระหว่างหลายบทสนทนา
  

2. แนวคิดการออกแบบ

1. เปลี่ยน "บทสนทนา" ให้เป็น "กระแสเหตุการณ์"

บทสนทนาเป็นข้อมูลที่ไม่มีโครงสร้าง ส่วนเหตุการณ์เป็นข้อมูลที่มีโครงสร้าง เหตุการณ์สำคัญแปล "สิ่งที่ผู้ใช้พูด สิ่งที่ผู้ใช้ทำ" ให้กลายเป็นบันทึกเหตุการณ์ที่ประกอบด้วย「ประเภท + สรุป + เอนทิตี + สถานะ + ลำดับความสำคัญ + ความเชื่อมั่น」เพื่อให้ระบบปลายทางอื่นนอกเหนือจาก LLM (สถิติ การควบคุมความเสี่ยง การตรวจสอบคุณภาพโดยมนุษย์) สามารถใช้ความจำชุดนี้ได้เช่นกัน

2. ทริกเกอร์สองช่องทาง หลีกเลี่ยงทั้งการพลาดและการสกัดมากเกินไป

ในบทสนทนาเดียวเหตุการณ์อาจปรากฏกลางทาง หรืออาจต้องสกัดเสริมหลังจากผู้ใช้ออกไปแล้ว ระบบใช้แผนสามระดับ ได้แก่ เกณฑ์จำนวนข้อความ (เรียลไทม์) + การหมดเวลาว่าง (เป็นชุด) + ทริกเกอร์ด้วยตนเอง (สำรอง) นักพัฒนาสามารถปรับพารามิเตอร์เพื่อสร้างสมดุลระหว่างต้นทุนและความรวดเร็ว

3. เปิดใช้งานการสกัด LLM เป็นค่าเริ่มต้น สามารถลดระดับไปใช้โมเดลราคาถูกกว่าได้

การสกัดเหตุการณ์ต้องอาศัยการอนุมานของ LLM ซึ่งจะใช้ Token ดังนั้นโมเดลที่ใช้ในการสกัดและโมเดลของบทสนทนาหลักของ Bot สามารถกำหนดค่าได้แยกกัน — ตัวอย่างเช่น บทสนทนาหลักใช้ Claude / GPT ส่วนการสกัดใช้โมเดลขนาดเล็กที่ราคาถูกกว่า โดยเรียกเก็บเงินและปรับให้เหมาะสมแยกกัน

4. การสำรองข้อมูลตัวตนผู้ใช้สองช่องทาง

เหตุการณ์ถูกรวบรวมตามมิติของผู้ใช้ ใช้ userId ที่นักพัฒนาส่งผ่านมาเป็นลำดับแรก (ตัวระบุระดับสูงสุด) เมื่อขาดหายไปจะถอยกลับไปใช้ anonymousId ที่แพลตฟอร์มสร้างขึ้น (เช่น ผู้ใช้ที่ยังไม่ได้เข้าสู่ระบบ) แม้ว่านักพัฒนาจะไม่ส่ง userId มา บทสนทนาของผู้เยี่ยมชมแบบนิรนามก็ยังสามารถสะสมเหตุการณ์ได้

5. แยกขอบเขตของผู้ใช้อย่างเข้มงวด ป้องกันการปนเปื้อนจากภาพหลอนของ LLM

LLM อาจ "แต่ง" eventId ของผู้ใช้คนอื่นขึ้นมาในการดำเนินการ UPDATE / DELETE / MERGE โค้ดภายในจะตรวจสอบ matchesUserScope สำหรับการดำเนินการทุกครั้ง โดยบังคับให้ใช้ userId / anonymousId เป็นเงื่อนไขกรองที่เข้มงวด เพื่อป้องกันการปนเปื้อนของเหตุการณ์ข้ามผู้ใช้

6. การฉีด Prompt มีสองช่องทางทั้งแบบชัดเจนและแบบโดยปริยาย

• ชัดเจน: เขียน placeholder {{key_event_<eventType>}} ใน Prompt เพื่อรับค่าตามประเภทเหตุการณ์อย่างแม่นยำ
• โดยปริยาย: เมื่อไม่ได้เขียน placeholder ระบบจะเพิ่มย่อหน้า ## Recent Key Events ต่อท้ายของ Prompt โดยอัตโนมัติ ใช้งานได้โดยไม่ต้องตั้งค่า

3. หลักการทำงาน

3.1 โมเดลข้อมูล

โครงสร้างหลักของเหตุการณ์ (BotEventEntity) ฟิลด์หลัก:

3.2 กลไกการทริกเกอร์สามระดับ

                      
                      ┌── ระดับ 1: ทริกเกอร์เรียลไทม์ ─────────────────┐
│ ข้อความผู้ใช้แต่ละรายการ +1 นับจำนวน                 │
│ pendingMessageCount ≥ messageThreshold │
│ เรียก LLM สกัดทันที                      │
└──────────────────────────────────────┘
┌── ระดับ 2: ทริกเกอร์ขณะว่าง ─────────────────┐
│ การสแกนตามกำหนดเวลา (ทุก 30/60/300 วินาที)         │
│ เงื่อนไขที่ตรงกัน:                           │
│   - lastMessageTime > ก่อน idleTimeout │
│   - pendingMessageCount > 0          │
│   - extractionStatus == IDLE         │
└──────────────────────────────────────┘
┌── ระดับ 3: ทริกเกอร์ด้วยตนเอง ─────────────────┐
│ เรียก API:                             │
│   POST /bot/event/execute/.../retry  │
│ หรือคลิก "ลองใหม่" บนหน้าบันทึกการดำเนินการ               │
└──────────────────────────────────────┘

                    

ทางเข้าทั้งสามจะเข้าสู่ pipeline เดียวกันในที่สุด (BotEventExtractionService.extract) โดยใช้ Redis lock (bot:event:extract:{botId}:{conversationId} หมดเวลา 5 นาที) เพื่อให้แน่ใจว่าจะไม่มีการสกัดพร้อมกันในบทสนทนาเดียวกัน

3.3 ไปป์ไลน์การสกัด

                      
                      1. ตรวจสอบสวิตช์ → Redis ขอ lock
2. อ่านตัวตนสำรองสามชั้น Track / Redis / c_conversation
3. ดึงข้อความใหม่ที่อยู่หลัง lastExtractedMessageTime (≤100 รายการ)
   + เพิ่มข้อความประวัติย้อนหลัง 10 รายการเพื่อให้บริบทสมบูรณ์
   + เมื่อทริกเกอร์เรียลไทม์ ตัดส่วนท้ายของหน้าต่างความจำระยะสั้นออก (ให้สอดคล้องกับหน้าต่างของบทสนทนาหลัก)
4. ดึงเหตุการณ์ในอดีตของผู้ใช้นี้ N รายการล่าสุด (recentEventCount)
5. ประกอบ Prompt ตามแม่แบบ:
   - กฎการสกัดที่ผู้ใช้กำหนดเอง
   - ประเภทเหตุการณ์ที่อนุญาต (name + description)
   - เหตุการณ์ในอดีต (สำหรับการเปรียบเทียบเพื่อขจัดความซ้ำซ้อน)
   - บทสนทนาที่จะวิเคราะห์
6. เลือกโมเดลสกัด ส่ง JSON Schema (ใช้ได้เฉพาะกับตระกูล OpenAI)
7. แยกวิเคราะห์อาเรย์ operations ที่ LLM ส่งกลับ:
   CREATE  → สร้างเหตุการณ์ใหม่
   UPDATE  → ผลักดันสถานะ/สรุปของเหตุการณ์ที่มีอยู่
   MERGE   → รวมเหตุการณ์ที่ซ้ำซ้อนหลายรายการ
   DELETE  → ลบแบบนุ่ม (ผู้ใช้ถอนคำพูด/ปฏิเสธ)
8. บังคับตรวจสอบขอบเขตข้ามผู้ใช้
9. บันทึกการใช้เครดิต (ประเภท CONSUME_KEY_EVENT)
10. บันทึกการดำเนินการ + รีเซ็ต Track

                    

3.4 กลไกการฉีด

โหมด A: เพิ่มต่อท้ายอัตโนมัติ (ไม่ต้องตั้งค่า)

เมื่อ Bot เปิดใช้งานเหตุการณ์สำคัญ และใน Prompt ไม่มี placeholder {{key_event_*}} ระบบจะรวมเหตุการณ์ N รายการล่าสุดต่อท้ายของ Prompt โดยอัตโนมัติในรูปแบบต่อไปนี้ ก่อนจะเรียก LLM ทุกครั้ง:

                      
                      ## Recent Key Events
eventType: withdrawal | summary: ผู้ใช้ขอถอนเงิน 5000 บาท | status: กำลังดำเนินการ | priority: สูง | confidence: สูง | updateTime: 2026-04-28 09:21:33 | entities: {"amount":5000,"channel":"bank"}
eventType: complaint | summary: ผู้ใช้ร้องเรียนการบริการลูกค้าตอบช้า | status: แก้ไขแล้ว | priority: กลาง | confidence: กลาง | updateTime: 2026-04-27 18:02:11

                    

โหมด B: การแทนที่ placeholder (ควบคุมอย่างแม่นยำ)

เขียนใน Prompt / องค์ประกอบเวิร์กโฟลว์ / กฎ:

                      
                      {{key_event_withdrawal}}     ← ฉีดเฉพาะเหตุการณ์ประเภท "ถอนเงิน"
{{key_event_complaint}}      ← ฉีดเฉพาะเหตุการณ์ประเภท "ร้องเรียน"

                    

แพลตฟอร์มจะสร้างตัวแปรที่สอดคล้องกันโดยจัดกลุ่มตาม eventType ประเภทเหตุการณ์ที่ไม่ตรงกันจะไม่ถูกฉีดเข้า ฉีดได้สูงสุด 30 รายการ / ตัวแปร

Flow Bot: การควบคุมอิสระระดับองค์ประกอบ

แต่ละโหนด LLM ในเวิร์กโฟลว์มี FlowKeyEventConfig ของตัวเอง: เปิด/ปิด เลือกประเภทเหตุการณ์ และตั้ง recentEventCount (ค่าเริ่มต้น 5 รายการ) ได้แยกกัน เหตุการณ์ในบทสนทนาเดียวกันจะถูกค้นหาเพียงครั้งเดียว (แคชไว้ใน ChatContext) และโหนดหลายโหนดจะใช้ข้อมูลร่วมกัน

4. คู่มือการใช้งาน

4.1 เปิดใช้งานในแผงตั้งค่าของ Bot

เส้นทางการเข้า: คอนโซลนักพัฒนา → รายละเอียด Bot → การจัดการผู้ใช้ (User Manage) → ลิ้นชัก「เหตุการณ์สำคัญ」

ขั้นตอนการดำเนินการ:

1. เปิดสวิตช์หลัก
2. โมเดลสกัด: เป็นตัวเลือก เมื่อไม่ได้เลือกจะใช้โมเดลบทสนทนาเริ่มต้นของ Bot แนะนำให้เลือกโมเดลที่ราคาถูก (เช่น GPT-4o-mini / ตระกูล Haiku)
3. กฎการสกัด (≤2000 ตัวอักษร): ใช้ภาษาธรรมชาติเพื่อบอก LLM ว่าในบริบทของ Bot นี้ "อะไรนับเป็นเหตุการณ์สำคัญ" ตัวอย่าง:
   สกัดเฉพาะการกระทำทางธุรกิจที่เกี่ยวข้องกับการเงิน (ถอนเงิน ฝากเงิน โอนเงิน คืนเงิน) ละเว้นการพูดคุยทั่วไปและการแสดงอารมณ์ ฟิลด์เอนทิตีต้องประกอบด้วยจำนวนเงิน (amount) สกุลเงิน (currency) หมายเลขคำสั่งซื้อ (orderId)

                         
                         สกัดเฉพาะการกระทำทางธุรกิจที่เกี่ยวข้องกับการเงิน (ถอนเงิน ฝากเงิน โอนเงิน คืนเงิน)
   ละเว้นการพูดคุยทั่วไปและการแสดงอารมณ์
   ฟิลด์เอนทิตีต้องประกอบด้วยจำนวนเงิน (amount) สกุลเงิน (currency) หมายเลขคำสั่งซื้อ (orderId)
   
                       

   บล็อกโค้ดนี้ในหน้าต่างลอย
4. จำนวนเหตุการณ์ล่าสุด (050): จำนวนเหตุการณ์ที่ฉีดเข้า Prompt ในแต่ละบทสนทนา 0 หมายถึงไม่ฉีด ที่พบบ่อยคือ 510
5. เวลาทริกเกอร์:
   • เกณฑ์จำนวนข้อความ (5~50): ค่าเริ่มต้น 10
   • การหมดเวลาว่าง (2~60 นาที): ค่าเริ่มต้น 3
6. พจนานุกรมประเภทเหตุการณ์ (สูงสุด 10 รายการ): แต่ละประเภทประกอบด้วย「ชื่อ」(≤10 ตัวอักษร) และ「คำอธิบาย」(≤100 ตัวอักษร บอก LLM ว่าประเภทนี้บรรจุอะไรไว้)
7. คลิกบันทึก

⚠️ คำเตือน: เมื่อชื่อประเภทถูกเผยแพร่แล้วอย่าเปลี่ยนชื่อตามอำเภอใจ — เหตุการณ์ในอดีตยังคงเก็บชื่อเก่าไว้ ซึ่งจะทำให้ {{key_event_<ชื่อเก่า>}} ดึงค่าไม่ได้ หน้าบ้านจะแสดงคำเตือนสีส้มเมื่อประเภทมีอยู่แล้ว

4.2 อ้างอิงเหตุการณ์ใน Prompt

Prompt ของ Bot ทั่วไป

                      
                      คุณคือผู้ช่วยฝ่ายบริการลูกค้าด้านการเงิน

【การกระทำทางการเงินล่าสุดของผู้ใช้รายนี้】
{{key_event_withdrawal}}

【การร้องเรียนล่าสุดของผู้ใช้รายนี้】
{{key_event_complaint}}

กรุณาตอบคำถามของผู้ใช้โดยอ้างอิงจากบริบทข้างต้น

                    

Prompt ขององค์ประกอบใน Flow Bot

• คลิกที่โหนดที่ขับเคลื่อนด้วย LLM ในแคนวาส → ที่แผงตั้งค่าค้นหาการตั้งค่า「ความจำ-เหตุการณ์สำคัญ」
• ติ๊ก enable เลือกประเภทเหตุการณ์ที่จะฉีดเข้าโหนดปัจจุบัน และตั้งจำนวนเหตุการณ์ล่าสุดที่จะเรียกคืน (ค่าเริ่มต้น 5)

4.3 ตรวจสอบบันทึกการดำเนินการสกัด

เส้นทางการเข้า: คอนโซลนักพัฒนา → รายละเอียด Bot → การจัดการผู้ใช้ → แท็บบันทึกการดำเนินการ

ข้อมูลที่สามารถดูได้:

• สถานะของแต่ละการสกัด (PENDING / RUNNING / COMPLETED / FAILED)
• ที่มาของการทริกเกอร์ (REALTIME / SCHEDULED / MANUAL)
• จำนวนข้อความที่ประมวลผล / จำนวนเหตุการณ์ที่สกัดได้
• การใช้ Token / การใช้เครดิต
• เหตุผลความล้มเหลว + ปุ่ม「ลองใหม่」
• ลิ้นชักรายละเอียด: แสดงเหตุการณ์ทั้งหมดที่สร้าง / แก้ไขในการสกัดครั้งนี้

4.4 ใบแจ้งหนี้และการคิดค่าบริการ

ค่าใช้จ่ายในการเรียก LLM ของเหตุการณ์สำคัญจะถูกบันทึกในรายการ เหตุการณ์สำคัญ ของใบแจ้งหนี้ ซึ่งแยกการคิดค่าบริการออกจากกระบวนการบทสนทนาหลัก เพื่อความสะดวกในการควบคุมต้นทุนแยกต่างหาก

5. กรณีการใช้งานทั่วไป

6. แนวทางปฏิบัติที่ดีที่สุด

✅ ระดับการกำหนดค่า

1. เขียนคำอธิบายในพจนานุกรมประเภท — ต้องกรอกทั้ง name และ description LLM อาศัย description เป็นหลักในการตัดสินว่า "บทสนทนานี้เป็นประเภทนี้หรือไม่" การเว้น description ว่างจะลดความแม่นยำของการจัดประเภทอย่างมีนัยสำคัญ
2. ควบคุมจำนวนประเภทไว้ที่ 5~10 รายการ มากเกินไปจะทำให้ LLM ลังเลเมื่อจัดประเภทขณะสกัด และทำให้ Prompt บวมขึ้น รวมประเภทที่มีความหมายเดียวกันเข้าด้วยกัน ("ถอนเงิน" และ "ถอน" ใช้ตัวเดียวกัน)
3. กฎการสกัดควรเขียนทั้ง "ทำอะไร" และ "ไม่ทำอะไร" ตัวอย่าง:
   สกัดเฉพาะการกระทำทางธุรกิจที่ยืนยันแล้วว่าเสร็จสิ้นหรือกำลังดำเนินการ ยกเว้น: การพูดคุยเชิงสมมติ ("ถ้า...จะทำอย่างไร") อารมณ์ล้วน ๆ การพูดคุยทั่วไป

                         
                         สกัดเฉพาะการกระทำทางธุรกิจที่ยืนยันแล้วว่าเสร็จสิ้นหรือกำลังดำเนินการ
   ยกเว้น: การพูดคุยเชิงสมมติ ("ถ้า...จะทำอย่างไร") อารมณ์ล้วน ๆ การพูดคุยทั่วไป
   
                       

   บล็อกโค้ดนี้ในหน้าต่างลอย
4. เลือกโมเดลสกัดที่เล็กไม่ใช่ใหญ่ การสกัดเป็นงานที่ให้ผลลัพธ์เป็นโครงสร้าง ความต้องการด้านความสามารถในการอนุมานต่ำ GPT-4o-mini / Claude Haiku / DeepSeek-V3 มักจะเพียงพอ ต้นทุนต่อครั้งสามารถต่ำกว่าโมเดลบทสนทนาหลักได้หนึ่งเท่าตัว
5. อย่าตั้ง recentEventCount ให้สูงสุดตั้งแต่แรก การฉีดเหตุการณ์มากเกินไปจะแย่งบริบทของบทสนทนาหลัก เริ่มที่ 5 หาก Bot มัก "นึกไม่ออก" ก็ค่อยเพิ่ม

✅ พารามิเตอร์การทริกเกอร์

6. บทสนทนายาว / สถานการณ์บริการลูกค้า: messageThreshold = 10, idleTimeoutMinutes = 3 มักจะเหมาะสม
7. ปฏิสัมพันธ์สั้น / Bot แบบเชิงงาน: ตั้ง idleTimeoutMinutes ไปที่ 2 เพื่อหลีกเลี่ยงการสกัดเหตุการณ์ที่ล่าช้าหลังจากผู้ใช้สิ้นสุดบทสนทนา
8. บทสนทนาความถี่สูงคุณค่าต่ำ (เช่น คำถามทั่วไป): เพิ่ม messageThreshold เป็น 20~30 หลีกเลี่ยงการเรียก LLM สกัดทุกรอบจนสิ้นเปลืองต้นทุน

✅ การอ้างอิงใน Prompt

9. เลือกใช้ placeholder เป็นลำดับแรก แทนการพึ่งพาการเพิ่มต่อท้ายอัตโนมัติ placeholder ควบคุมได้และสามารถแบ่งตามประเภทได้อย่างแม่นยำ ส่วนการเพิ่มต่อท้ายอัตโนมัติเหมาะสำหรับสถานการณ์สำรองที่ "ต้องการทุกอย่าง"
10. ในการ Flow Bot อย่าเปิดใช้งานทุกโหนด เปิดใช้งานเฉพาะในโหนดที่ต้องการบริบทของเหตุการณ์อย่างแท้จริง (เช่น โหนดตอบกลับการบริการลูกค้า โหนดตัดสินใจการควบคุมความเสี่ยง) โหนดการจดจำเจตนา / การจัดเส้นทางไม่จำเป็นต้องเปิด
11. หลีกเลี่ยงการให้ {{key_event_xxx}} ปรากฏที่ส่วนบนของ Prompt ระดับระบบ — เหตุการณ์ในอดีตมักจะเพิ่มขึ้นตามเวลา หากมันเต็ม Token คำสั่งหลักจะถูกตัดทอน แนะนำให้วางที่ส่วนกลางของ Prompt หรือก่อน Few-shot

✅ การกำกับดูแลข้อมูล

12. ตรวจสอบเหตุการณ์ความเชื่อมั่นต่ำ LOW โดยมนุษย์เป็นระยะ LLM จะสกัดเนื้อหาที่ "ผู้ใช้กล่าวอ้างฝ่ายเดียว" ออกมาด้วย ฝ่ายธุรกิจควรกรองอีกชั้นหนึ่ง — สามารถตรวจสอบโดย confidence=LOW + disputeFlag=true
13. กระบวนการธุรกิจที่สำคัญควรใช้ร่วมกับการเขียนผ่าน API เช่น เมื่อระบบคำสั่งซื้อมีข้อมูลที่เป็นโครงสร้างอยู่แล้ว การเขียนตรง ๆ ด้วย createdBy=API จะแม่นยำกว่าการให้ LLM สกัดจากบทสนทนา และอยู่ร่วมกับผลการสกัดของ LLM ได้
14. ใช้การดำเนินการ MERGE อย่างระมัดระวัง LLM อาจรวมเหตุการณ์ที่ไม่ควรรวมเข้าด้วยกันเป็นครั้งคราว แนะนำให้สนใจการดำเนินการประเภท MERGE ในบันทึกการดำเนินการ และคืนสภาพโดยการแยกผ่าน API หากจำเป็น
15. ใช้ฟิลด์ entities ให้เป็นประโยชน์ ในกฎการสกัดให้กำหนดอย่างชัดเจนให้ LLM สกัด KV ที่สำคัญ (จำนวนเงิน หมายเลขคำสั่งซื้อ เวลา ฯลฯ) ในภายหลังสามารถสอบถามแบบมีโครงสร้างได้โดยตรง ซึ่งน่าเชื่อถือกว่าการแยกวิเคราะห์ข้อความ summary

⚠️ รายการตรวจสอบปัญหา

7. ขอบเขตความสามารถและข้อควรระวัง

• การสกัดไม่ใช่เรียลไทม์ แม้แต่ทริกเกอร์เรียลไทม์ระดับ 1 ก็ยังต้องรอจำนวนข้อความสะสมถึงเกณฑ์ก่อนจึงจะสกัด ธุรกิจที่ต้องการความสอดคล้องอย่างเข้มงวด (เช่น การทำธุรกรรม) ไม่สามารถพึ่งพากระแสเหตุการณ์ในการตัดสินใจได้ — เหตุการณ์เป็นความจำเสริม ไม่ใช่แหล่งที่มาของความจริง
• หน้าต่างการสกัดสูงสุด 100 ข้อความ (MAX_MESSAGES_PER_BATCH) บทสนทนาที่ยาวเกินไปจะถูกแบ่งออกเป็นหลายหน้าต่างเพื่อประมวลผล ความสัมพันธ์เชิงเหตุและผลข้ามหน้าต่างจะอาศัย "การเปรียบเทียบเหตุการณ์ในอดีต" เพื่อเรียกคืน
• การสอบถามเหตุการณ์มีการป้องกันการหมดเวลา 500ms การสอบถามที่ช้าจะไม่ลากระบบลูกโซ่ของแชท แต่ในกรณีสุดโต่งจะไม่มีการฉีดเหตุการณ์
• anonymousId จะถูกรีเซ็ตเมื่อล้างที่ฝั่งไคลเอนต์ ผู้ใช้นิรนามที่เปลี่ยนอุปกรณ์ / ล้างแคชจะถูกถือว่าเป็นผู้ใช้ใหม่ และเหตุการณ์จะไม่ตามไปด้วย
• กระแสเหตุการณ์ไม่เกี่ยวข้องในโหมด multi-agent (ดูคำประกาศการเลิกใช้งานใน CLAUDE.md ของ oversea-ailab)