Tool: readiness, handoff, pack, pending, timeline — หาทิศทางก่อนเริ่มงานโดยไม่ต้องถามผู้ใช้ซ้ำ
คำสั่ง orientation ช่วย agent ทำความเข้าใจสถานะงานก่อนเริ่ม โดยมองจากห้ามุม: ความพร้อม งานส่งต่อ ภาพรวม สิ่งที่ค้าง และลำดับเหตุการณ์ (readiness, handoff, pack, pending, timeline)
ปัญหาที่ทั้ง 5 tool นี้ร่วมกันแก้
Agent ที่เริ่ม session ใหม่ (หรือรับช่วงงานจาก agent ตัวก่อนหน้า) ไม่รู้อะไรเลยเกี่ยวกับสถานะปัจจุบันของโปรเจกต์ — 5 tool นี้แต่ละตัวตอบคำถามคนละแบบเกี่ยวกับ “ตอนนี้อยู่ตรงไหน” ให้เลือกใช้ตามสถานการณ์จริง แทนที่จะมี tool เดียวที่พยายามตอบทุกอย่าง
endeavor_memory_readiness — เช็คสุขภาพเครื่องก่อนทำอะไรทั้งสิ้น
Preflight ตัวเดียวที่บอก: role ของเครื่องนี้ (Main/Backup), สุขภาพฐานข้อมูล/FTS, ความครอบคลุมของ embedding, สถานะ ANN sidecar, ความสดของเอกสารที่ track ไว้ และ next_actions เรียงตามลำดับความสำคัญ — จุดสำคัญคือไม่มีผลข้างเคียงเลย: ไม่ bootstrap, ไม่ backfill, ไม่ warm companion, ไม่สร้าง ANN, ไม่เขียนฐานข้อมูล เป็นแค่การอ่านสถานะล้วนๆ — ผลลัพธ์สรุปเป็น ready/attention/blocked ให้ตัดสินใจได้ทันทีว่าควรทำอะไรต่อ ตาม next_actions ที่ให้มา (ห้าม auto-prune เอกสารที่ orphan ไปเองแม้ readiness จะรายงานว่ามี)
endeavor_memory_handoff — resume แบบเบา
คืน session + checkpoint ล่าสุดของ session ที่ resolve ได้ (ทั้งคู่เป็น null ได้ตามปกติถ้าโปรเจกต์ไม่มี session ค้างอยู่) — เลือก resolve ได้ 3 แบบ: project (unambiguous handoff ของโปรเจกต์นั้น), session (หลังผู้ใช้เลือก session ที่ต้องการ resume แล้ว), หรือ all_paused=true (คิว resume ข้ามทุกโปรเจกต์ — แหล่งความจริงที่ authoritative สำหรับ “มีอะไรค้างอยู่บ้าง”) จุดสำคัญ: โปรเจกต์ที่กำกวมจะถูกปฏิเสธ ไม่ใช่เดาเอาเอง — ป้องกัน agent resume ผิด session โดยไม่รู้ตัว
endeavor_memory_pack — briefing เต็มรูปแบบเมื่อ handoff อย่างเดียวไม่พอ
ถ้า handoff ให้ข้อมูลน้อยเกินไปสำหรับงานที่ไม่ trivial ให้ใช้ pack แทน — คืน handoff ที่เลือกแล้ว บวก actionable_records (งานค้างที่ lifecycle-aware แล้ว), open_records ดิบ (ระวัง: อาจมี record เก่าที่ historical ถูก resolve/supersede ไปแล้วก็ยังติดมาด้วย เพราะเป็นแค่สถานะ open ที่บันทึกไว้ ไม่ผ่านการ resolve lifecycle เหมือน actionable_records), knowledge ล่าสุด, และ activity — ทั้งหมดถูกจัดสรรภายในงบตัวอักษรที่กำหนด (ดีฟอลต์ 6,000 สูงสุด 50,000) พร้อม budget_omitted_counts บอกว่ามีอะไรถูกตัดทิ้งไปเพราะพื้นที่ไม่พอบ้าง — docstring เตือนว่าอย่าเรียกซ้ำระหว่างทำงานปกติ เพราะเป็น tool ที่ประมวลผลหนักกว่า handoff มาก เหมาะกับเรียกครั้งเดียวตอนเริ่มงานเท่านั้น
endeavor_memory_pending — งานค้างทั้งหมดแบบ lifecycle-aware
ต่างจาก pack/handoff ที่โฟกัสที่ session เดียว pending ให้ภาพรวมงานค้างทั้งหมด: presence ที่ active/last-known, session ที่ resumable/blocked, และ durable record ที่ยัง unresolved จริงๆ เท่านั้น (record ประวัติศาสตร์ที่ resolve ไปแล้วผ่าน lifecycle edge จะถูกกรองออก ต่างจาก pack’s open_records ที่ยังติดมา) — ต้องระบุ project หรือ all_projects=true อย่างใดอย่างหนึ่งเสมอ และมีคำเตือนสำคัญ: ห้าม resume session ที่ลิสต์มาแบบเงียบๆ เอง ถ้ามีมากกว่า 1 session ที่ resumable ต้องถามผู้ใช้ว่าจะเลือกอันไหน
endeavor_memory_timeline — ประวัติแบบ audit trail
ต่างจาก 4 tool ข้างบนที่โฟกัสที่ “ตอนนี้” timeline มองย้อนกลับ — ใครทำอะไรไปบ้างข้าม session ไหนบ้าง filter ได้ทั้งโปรเจกต์/agent/สถานะ session/session ID เฉพาะ แต่ละ record มี checkpoint_status (current = checkpoint ล่าสุดของ session นั้น, historical = ถูกแทนที่แล้ว) แยกจาก session_status (สถานะ lifecycle ของทั้ง session) — สำคัญคือ ผลลัพธ์ครอบคลุมเฉพาะ checkpoint ที่ยังถูกเก็บรักษาไว้เท่านั้น ไม่ใช่ activity_log ทั้งหมด (มี retention_notice กำกับเสมอ) เพราะ checkpoint ผ่านการ prune ตามนโยบายที่ตั้งไว้ (ยกเว้นอันที่ pin ไว้)
เลือก tool ไหนเมื่อไร
| สถานการณ์ | Tool ที่เหมาะ |
|---|---|
| เพิ่งเริ่มแตะโปรเจกต์นี้ ยังไม่รู้อะไรเลย | readiness ก่อนเสมอ |
| อยากรู้แค่ “resume ตรงไหนต่อดี” แบบเบาๆ | handoff |
| งานไม่ trivial ต้องการบริบทกว้างกว่า handoff | pack |
| อยากรู้งานค้างทั้งหมดของโปรเจกต์/ทุกโปรเจกต์ | pending |
| อยากรู้ประวัติว่าใครทำอะไรไปบ้าง | timeline |
ทำไมเรื่องนี้ถึงสำคัญ
การมี 5 tool ที่ตอบคำถาม “อยู่ตรงไหนแล้ว” คนละมุมแทนที่จะมี tool เดียวที่พยายามตอบทุกอย่าง สะท้อนหลักการที่เห็นซ้ำทั่วทั้ง ENDMEMEX: แต่ละ tool ควรมีขอบเขตชัดเจนและต้นทุนการประมวลผลที่คาดเดาได้ — readiness เบาและไม่มีผลข้างเคียงเลย เหมาะเรียกได้บ่อยๆ ในขณะที่ pack หนักกว่าและตั้งใจให้เรียกครั้งเดียว การแยกแบบนี้ทำให้ agent เลือก tool ที่คุ้มค่ากับสถานการณ์จริงได้ แทนที่จะเรียก tool ที่หนักที่สุดทุกครั้งเพราะไม่แน่ใจว่าตัวไหนพอ
ความคิดเห็น
กำลังโหลดความคิดเห็น...