บันทึกและเผยแพร่

นี่คือกฎข้อแรกที่ควรเข้าใจที่สุดในการใช้ LoopAgent และเป็นจุดที่สับสนได้ง่ายที่สุด: 「บันทึก」อัปเดตเฉพาะเวอร์ชัน Debug เท่านั้น ส่วน「เผยแพร่」จึงจะอัปเดตเวอร์ชัน Online

กฎหลัก

• คลิกบันทึกในหน้าตั้งค่า (เปลี่ยนโมเดล แก้ไขเพอร์โซนา ผูกฐานความรู้ เพิ่มเครื่องมือ……) → เขียนเข้าเวอร์ชัน Debugเท่านั้น → แชท Debug ทางด้านขวามีผลทันที จึงตรวจสอบได้เลย
• แต่ทุกช่องทางภายนอก (Open API, หน้าแชร์, Widget, ปลั๊กอินเว็บไซต์, Telegram, Slack, LiveChat, LiveDesk……) จะทำงานด้วยสแนปช็อตการตั้งค่าที่ถูกตรึงไว้ ณ ครั้งที่「เผยแพร่」ล่าสุด

หากไม่คลิก「เผยแพร่」ระบบจริงจะยังคงเป็นการตั้งค่าเก่าเสมอ

flowchart LR
    S[คลิกบันทึก] --> DBG[เวอร์ชัน Debug]
    DBG --> DC[แชท Debug มีผลทันที]
    P[คลิกเผยแพร่] --> PROD[เวอร์ชัน Online]
    PROD --> CH[ช่องทางภายนอกมีผล]

คำถามที่พบบ่อย: 「ฉันเปลี่ยนการตั้งค่า / เพอร์โซนาแล้ว ทำไมระบบจริงไม่เปลี่ยน?」——เพราะคุณแค่บันทึก แต่ยังไม่เผยแพร่ หากต้องการให้การเปลี่ยนแปลงมีผลกับระบบจริง จะต้องคลิกเผยแพร่ / Releaseอีกครั้ง แชท Debug ทำงานปกติ ≠ ระบบจริงทำงานปกติ

หาก LoopAgent ไม่เคยถูกเผยแพร่เลย ช่องทางภายนอกจะรายงานข้อผิดพลาดและรันไม่ได้เลย ก่อนเชื่อมต่อ API หรือช่องทางเป็นครั้งแรก ต้องเผยแพร่หนึ่งครั้งเสมอ

การเปลี่ยนแปลงใดมีผลเมื่อเผยแพร่ และการเปลี่ยนแปลงใดมีผลทันที

ไม่ใช่ทุกอย่างต้อง「เผยแพร่」จึงจะมีผล การแยกให้ชัดเจนช่วยลดการเสียเวลา:

กล่าวสั้น ๆ: เปลี่ยนการตั้งค่าต้องเผยแพร่ ส่วนเปลี่ยนข้อมูล / ทรัพยากรระดับองค์กรมีผลทันที

แชท Debug

แชท Debug ทางด้านขวาของหน้าตั้งค่าใช้สำหรับตรวจสอบผลของการกำหนดค่า:

• มันอ่านการตั้งค่าเวอร์ชัน Debug ซึ่งมีผลทันทีหลังบันทึก จึงปรับได้ซ้ำ ๆ และเห็นผลทันที
• แชท Debug เป็นบทสนทนาจริง และมีการคิดค่าใช้จ่ายเช่นเดียวกัน
• ในโหมด Debug / พรีวิว จะไม่มีการนำความจำข้ามรอบมาด้วย (แต่ละครั้งเป็นบริบทที่สะอาด) ซึ่งเป็นเรื่องปกติ

การส่งข้อความติด ๆ กันจะถูกรวมเป็นคำตอบเดียว

หากคุณส่งข้อความเพิ่มขณะที่เอเจนต์กำลังสร้างคำตอบอยู่ ข้อความเหล่านั้นจะไม่หาย ระบบจะแย่งล็อกเซสชันก่อน: ข้อความที่แย่งได้จะถูกประมวลผลทันที ส่วนที่แย่งไม่ได้จะเข้าคิวหรือถูกทำเครื่องหมายเพื่อรอดูดซับ และสุดท้ายจะถูกรวมเป็นคำตอบเดียว ดังนั้น「ส่งไปหลายข้อความแต่ได้คำตอบเดียว」จึงเป็นพฤติกรรมที่ออกแบบไว้ ไม่ใช่ข้อความหาย

การส่งข้อความติด ๆ กันมีการจัดการสองโหมด: QUEUE (คิว) และ APPEND (ต่อท้าย)

QUEUE (คิว ค่าเริ่มต้น)

ข้อความที่เข้าคิวจะถูกรวมที่ขอบเขตข้อความ——ต้องรอให้คำตอบปัจจุบันจบสมบูรณ์ก่อน จึงจะนำข้อความที่ตามมาไปประมวลผลเป็นรอบใหม่

• ข้อความ① แย่งล็อกเซสชันได้ จึงถูกประมวลผลทันทีและสร้างคำตอบ① ของตัวเอง
• ข้อความ②③ มาถึงขณะที่① ยังประมวลผลอยู่ แย่งล็อกไม่ได้ จึงเข้าคิว
• ต่อเมื่อ① ประมวลผลเสร็จและปล่อยล็อกแล้ว ระบบจึงรันอีกหนึ่งรอบโดยอัตโนมัติ โดยรวม②③ เข้าด้วยกันในคราวเดียวเป็นคำตอบเดียว

ข้อความ② จะไม่มีคำตอบแยกของตัวเอง——นี่คือจุดที่มักถูกเข้าใจผิดว่าเป็น「ข้อความหาย」มากที่สุด

APPEND (ต่อท้าย)

ข้อความที่ต่อท้ายไม่จำเป็นต้องรอให้รอบนี้จบ แต่จะถูกดูดซับเข้าไปในรอบที่กำลังดำเนินอยู่ในการร้องขอโมเดลครั้งถัดไป

• ข้อความ② มาถึงขณะที่① ยังทำงานอยู่ และ——แทนที่จะเข้าคิวหรือรอให้① จบ——จะถูกทำเครื่องหมายเป็น「รอดูดซับ」เท่านั้น
• เมื่อเอนจินไปถึงการวนซ้ำครั้งถัดไปและร้องขอโมเดล ก็จะนำเนื้อหาของ② ไปด้วย

การรวมเกิดขึ้นที่ขอบเขตการวนซ้ำ ซึ่งเร็วกว่าใน QUEUE: ไม่มีการสร้างข้อความใหม่และไม่มีคำตอบเพิ่ม ลูกค้ายังคงเห็นคำตอบ① เดิมที่ได้รับอิทธิพลจากเนื้อหาที่「ต่อท้าย」เข้าไป เหมาะกับการเพิ่มเติมและแก้ไขแบบเรียลไทม์ระหว่างทำงาน

การส่งเนื้อหาหลายรูปแบบติด ๆ กัน: หากข้อความที่ส่งติด ๆ กันระหว่างรอบมีเนื้อหาหลายรูปแบบ เช่น รูปภาพ ไฟล์ หรือเสียง เนื้อหานั้นจะถูกส่งให้โมเดลพร้อมกับการรวมด้วย——โดยมีเงื่อนไขว่าโมเดลที่เลือกรองรับอินพุตหลายรูปแบบที่เกี่ยวข้อง และเปิดใช้งานหมวดหมู่นั้นในการตั้งค่าอินพุตแล้ว

เนื้อหาของข้อความที่เข้าคิว / ต่อท้ายแต่ละข้อความมีขีดจำกัดอยู่ที่ 8192 อักขระ