Tool: presence, sync_status, events — เห็นว่าใครทำงานอยู่ตรงไหน โดยไม่บังคับให้ทุกคนต้องเปิดใช้

เผยแพร่ 12 สิงหาคม 2569

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

Presence เป็น opt-in — ไม่ใช่ทุกคนต้องเปิดใช้

จุดสำคัญที่สุดที่ต้องเข้าใจก่อน: ทั้ง endeavor_presence_start/heartbeat/stop มีคำเตือนตรงกันว่า “Use only when the user explicitly asks agents to announce work or is coordinating multiple concurrent sessions” — ไม่ใช่ค่าเริ่มต้นที่ agent ควรเปิดใช้เองโดยไม่มีใครขอ เพราะการเขียนแถว presence ทุกครั้งเป็นการเขียนฐานข้อมูลที่ไม่จำเป็นถ้าไม่มีสถานการณ์ที่ต้องประสานงานกันจริงๆ (agent เดียวทำงานตามลำดับปกติไม่ต้องการ presence เลย)

start → heartbeat → stop: วงจรชีวิตที่ชัดเจน

endeavor_presence_start — ประกาศว่า (machine, agent, project[, instance]) นี้กำลังทำงานอยู่ พร้อมคำอธิบายงานสั้นๆ ให้ agent อื่นที่ทำงานบนเครื่องเดียวกันเห็นผ่าน presence_list แทนที่จะไปทำงานซ้ำกัน — เรียกครั้งเดียวต่อ task/session ไม่ใช่ทุก turn
endeavor_presence_heartbeat — รีเฟรช timestamp ให้แถวไม่ถูกมองว่า stale เรียกตามจังหวะเดียวกับการเขียน checkpoint (ไม่ใช่สร้าง polling loop แยกต่างหาก) — ถ้าเรียก heartbeat แต่ไม่เคย start ไว้ (หรือ stop ไปแล้ว) จะได้ {"updated": false} กลับมา ไม่ใช่ error และไม่ปลุกแถวที่ stop ไปแล้วให้กลับมาทำงาน ต้อง start ใหม่เท่านั้นถึงจะกลับมา active
endeavor_presence_stop — เคลียร์แถวเมื่อจบงานตามธรรมชาติ — ถ้า process ล่มโดยไม่ได้เรียก stop ระบบยังจัดการได้เอง: แถวนั้นจะถูกติดธง stale หลัง 30 นาทีที่ไม่มี heartbeat แทนที่จะหายไปเงียบๆ หรือค้างอยู่ตลอดไป

Local vs remote: ความสดที่ไม่เท่ากัน

endeavor_presence_list แยกผลลัพธ์เป็น 2 ส่วนชัดเจน: local (แถวสดจริงของเครื่องนี้ real-time) กับ remote (snapshot ล่าสุดที่ mirror มาจากเครื่องอื่นผ่าน sidecar file — ไม่ใช่ live) — คำเตือนสำคัญ: treat “remote” as last-known, never as proof of current activity เพราะการมองเห็นข้าม host เป็นแบบ best-effort ผ่านไฟล์ sidecar เท่านั้น ไม่ใช่การเชื่อมต่อแบบ real-time ข้ามเครื่อง — สอดคล้องกับหลักการที่อธิบายไว้ใน how it works ว่า ENDMEMEX ไม่รองรับการเขียนพร้อมกันจากหลายเครื่องผ่าน filesystem sync โดยตรง

endeavor_sync_status — บอกแค่ “รู้ล่าสุดเมื่อไร” ไม่ใช่การรับประกัน

คืนเวลาที่แต่ละเครื่อง (host) เขียนล่าสุดตามที่ sidecar ของแต่ละเครื่องรายงานไว้ — docstring เตือนตรงๆ ว่าเป็นข้อมูลสำหรับอ้างอิงเท่านั้น: “a lower bound on when another host wrote, never a synchronization guarantee or write authorization” พูดง่ายๆ คือ sync_status บอกได้แค่ว่า “อย่างน้อยก็เขียนไปแล้วตอนนี้” ไม่ใช่หลักประกันว่าข้อมูลทุกเครื่อง sync ตรงกันแล้ว และไม่ได้ให้สิทธิ์เขียนอะไรทั้งสิ้น — เป็น tool สำหรับ diagnose สถานการณ์เท่านั้น ไม่ใช่กลไก coordination จริง

Event: สะพานเชื่อมงาน background กลับสู่บทสนทนาเจ้าของ

endeavor_memory_event_poll / endeavor_memory_event_ack คือกลไกที่ทำให้ งานที่ spawn ผ่าน sub-agent แบบ background หา conversation เจ้าของกลับมาได้ — ตามที่อธิบายไว้ใน how it works: “durable_events provides an at-least-once host notification boundary” เมื่องาน background เสร็จในขอบเขตโปรเจกต์ จะมี terminal event ถูก publish ไว้

event_poll — คืน event ที่ยังไม่ถูก acknowledge เรียงตาม ID จากน้อยไปมาก (monotonic) — ผู้เรียกต้องเก็บ ID สูงสุดที่จัดการแล้วไว้เอง (persist) และ ack เฉพาะเมื่อจัดการสำเร็จจริง
event_ack — เป็น idempotent โดยตั้งใจ (ack ซ้ำได้อย่างปลอดภัย) เพื่อรองรับat-least-once delivery: ถ้า host ล่มระหว่างจัดการ event แล้ว restart มาใหม่ อาจเห็น event เดิมอีกครั้งและ ack ซ้ำได้โดยไม่เกิดปัญหา — ดีกว่าความเสี่ยงที่จะพลาด event ไปเลยถ้าเลือกใช้ exactly-once ที่ทำผิดพลาดได้ง่ายกว่า

ทำไมเรื่องนี้ถึงสำคัญ

กลุ่ม tool นี้แสดงหลักการสำคัญของการออกแบบระบบที่รองรับหลาย agent ทำงานพร้อมกันแบบไม่บังคับ: ไม่ใช่ทุก session ต้องการการประสานงานแบบนี้ (จึงเป็น opt-in) แต่เมื่อจำเป็นจริง ระบบต้องซื่อสัตย์เกี่ยวกับขอบเขตความน่าเชื่อถือของข้อมูล — remote presence ไม่ใช่ live, sync_status ไม่ใช่การรับประกัน, event ต้องจัดการแบบ at-least-once ไม่ใช่ exactly-once เพราะระบบแบบกระจาย (แม้จะเบาแค่ sidecar file) ไม่มีทางรับประกันความสดหรือความแน่นอนแบบสมบูรณ์ได้ การบอกขอบเขตที่แท้จริงของแต่ละกลไกให้ผู้ใช้เห็นชัดเจน ดีกว่าการแสร้งทำเป็นว่าระบบแม่นยำกว่าที่เป็นจริง

อ่านเพิ่มเติม

ความคิดเห็น

กำลังโหลดความคิดเห็น...