ซับเอเจนต์แบบ OoO/Speculation (Superscalar) + ไลฟ์บอร์ด A2A ระหว่างเอเจนต์ (Constellation) — โมดูล 2 ตัวสำหรับการใช้งาน AI coding แบบมัลติเอเจนต์

EstreGenesis ที่เคยแนะนำไว้ในโพสต์ก่อนหน้า ได้เพิ่มโมดูลใหญ่สองตัวตลอดช่วงเวอร์ชัน 2.0~2.3
ทั้งสองอย่างเป็นความพยายามที่จะยกระดับ การทำงานแบบหลายตัวของ AI coding agent ไปอีกขั้น

---

Constellation — การสื่อสารแบบเรียลไทม์ระหว่างหน้าต่างสนทนาของเอเจนต์ (A2A WebSocket liveboard)

แนวคิด sub-agent แบบเดิมเป็นโมเดลพ่อแม่-ลูก — เอเจนต์หลักสร้างลูกขึ้นมา (spawn) แล้วรับผลลัพธ์กลับในโครงสร้างทางเดียว ไม่มีการ สื่อสารโดยตรงกับหน้าต่างสนทนาของเอเจนต์ตัวอื่น

Constellation ทำลายข้อจำกัดนั้น:

• A2A (Agent-to-Agent) WebSocket bridge — เอเจนต์แต่ละตัว (Claude Code · Codex · Cursor ฯลฯ) ยังคงรักษา IDE session ของตัวเองไว้ตามเดิม ขณะที่ daemon process แยกต่างหากจะเชื่อมเข้ากับ WebSocket liveboard เพื่อส่งข้อความไปยัง หน้าต่างสนทนาของเอเจนต์ตัวอื่น เป็นโมเดลแบบ peer-to-peer ระหว่างโหนดที่เท่าเทียมกัน ไม่ได้ยึดกับความสัมพันธ์พ่อแม่-ลูก (การทดสอบจริงยืนยันถึง Claude/Codex เท่านั้น ในการใช้งานต้องเปิดโหมดอนุมัติอัตโนมัติ (AutoMode) ของแต่ละเอเจนต์)
• การแยกบทบาท — main (orchestrator PM) / local (worker) / upstream (peer เอเจนต์อัตโนมัติอย่าง Hermes Agent) / collab (peer ผู้ร่วมงานภายนอก) เมื่อ main ส่ง Delegate (มอบหมาย) ให้ worker, worker จะรันทันทีใน IDE ของตัวเองและตอบกลับด้วย WorkerReport (รายงาน)
• รองรับเอเจนต์แบบ turn-based — แพตเทิร์นสำหรับ runtime แบบที่ บทสนทนาจบลงเมื่อจบหนึ่ง turn เช่น Claude Code: bridge daemon (file IO inbox/outbox) จะรับข้อความค้างไว้ และ self-wake watcher (ตัวเฝ้าดูที่ปลุกตัวเอง) จะเริ่ม turn ถัดไปเมื่อมีข้อความเข้า สามารถแยกจาก shell session (detached) และอยู่เบื้องหลังได้ตลอด
• แดชบอร์ด — มองเห็นงาน ข้อความ และสถานะของเอเจนต์ทั้งหมดได้ในหน้าจอเดียว ดูแค่บอร์ดก็สามารถประกอบลำดับการไหลของงานกลับมาได้

รวมอยู่ในสเปกคอมโพเนนต์ Constellation.md + constellation/*.eux
และแม้ไม่ต้องดาวน์โหลด runtime แบบปิดเผยแพร่ — ก็มีการสรุปโปรโตคอลทั้งหมดไว้ในเนื้อหาแล้ว

---

Superscalar — นำสถาปัตยกรรมโปรเซสเซอร์มาใช้กับการรันเอเจนต์

ultracode ของ Claude Opus 4.8 ที่ประกาศในวันนี้ (5/29) ตั้งอยู่บนสมมติฐานของการใช้งาน sub-agent จำนวนมาก
และถ้าจะให้มีประสิทธิภาพจริง ก็ต้องมีการจัดตารางเพื่อกำหนดว่าจะปล่อย task ใดพร้อมกันกี่ตัว (dispatch)
Superscalar นำปัญหาที่สถาปัตยกรรม CPU ในยุค 1960~80 แก้ไว้แล้วมาใช้กับการจัดตาราง task ของเอเจนต์โดยตรง — การรันหลายคำสั่งพร้อมกัน (multi-issue / superscalar) · การรันโดยไม่ยึดลำดับเมื่อ dependency พร้อม (out-of-order, OoO) · การรันจากการคาดเดาผลลัพธ์ของ branch (speculation)

• สูตร issue_width แบบ 5 มิติ — จำนวน sub-agent ที่จะปล่อยพร้อมกันในช่วงเวลาใดเวลาหนึ่งถูกกำหนดจากค่าต่ำสุดของข้อจำกัด 5 อย่าง:
  1. effort band ตามระดับความยากของ task ที่ Anthropic เสนอไว้ (การประเมินขนาดงาน)
  2. เพดานของ pace_mode (โหมดความเร็วการรัน Cautious·Proactive·Burst·Sprint)
  3. throughput ตามกฎของ Little (ทฤษฎีคิว — ความเร็วในการรีวิวของ PM ÷ ความยาว task เฉลี่ย)
  4. เพดาน WIP ของ Kanban (จำนวนงานที่ทำค้างพร้อมกัน ≈ ขนาดทีม + 1)
  5. autonomy_available_workers (จำนวน worker ที่เปิดโหมดอนุมัติอัตโนมัติ — ถ้าไม่เปิดจะมีหน้าต่างขอสิทธิ์จากผู้ใช้ขึ้นมาทุกการกระทำ ทำให้ throughput พัง)
• การรันแบบ OoO + การรับประกันลำดับผลลัพธ์ (แพตเทิร์น Tomasulo·ROB) — ถ้า dependency พร้อม ก็จะรันจาก task ที่ ready ก่อนโดยไม่สน declared order (ลำดับที่ประกาศไว้) แต่ PM จะ retire (ผสานเสร็จสิ้น) ผลลัพธ์ ตามลำดับเดิม ทำให้จากมุมมองผู้ใช้ยังเห็นเป็น declared order เหมือนเดิม ใช้แพตเทิร์นเดียวกับงานวิจัย Reorder Buffer ของ Smith-Pleszkun ปี 1988
• Speculation (opt-in, ประยุกต์บทเรียนจาก Spectre) — ประกาศ 2 ขั้น + ack: "consider X" → ผู้ใช้ ack → "execute X (speculative lane)" → ถ้าคาดผิดก็ทิ้งทั้ง worktree (โฟลเดอร์แยกสำหรับงาน) บังคับใช้องค์ประกอบ 3 อย่างของ Toyota Andon (การทำให้ Jidoka มองเห็นได้) — สัญญาณภาพ · cord สำหรับหยุดฉุกเฉิน · log ทบทวนกรณีคำตอบผิด
• Cost-benefit gate — ตัดสินอัตโนมัติที่จุดซึ่ง spawn overhead < ประโยชน์จากการขนานกัน ในช่วง horizon crossover ราว ~30-60k โทเคน งานเล็กจะตกลงไปเป็น inline เองตามธรรมชาติ

ได้รับการตรวจสอบผ่าน deep research 3 แกน (canon ทางวิชาการด้านสถาปัตยกรรมโปรเซสเซอร์ / กรณีอุตสาหกรรมของ agent harness / การสื่อสารงานและวิชาการจัดการ)
และเสริมด้วยเนื้อหาใน Superscalar.md และบันทึกการทดสอบภายในระยะ Stage 1 (dogfooding) (§11)

---

พื้นฐาน — หลักการเด็ดขาดของการรันแบบอัตโนมัติ

โมดูลทั้งสองข้างต้นตั้งอยู่บนสมมติฐานของ การปฏิบัติการแบบอัตโนมัติ
ถ้า "ต้องรอการยืนยันจากผู้ใช้จน throughput พัง" ทั้งสองอย่างก็ไม่มีความหมาย
ดังนั้น EstreGenesis 2.3 จึงกำหนดสิ่งต่อไปนี้เป็น หลักการเด็ดขาด:

ขั้นถัดไปที่ถูกกำหนดไว้แล้ว (ลำดับ Phase · แทร็ก planned (ตามแผน) · ส่วนที่ปลดจาก blocked (ติดขัด) · คิว in-order retire (เสร็จตามลำดับ)) ให้เดินหน้าต่อโดยไม่ต้องถาม
และ user gate มีเพียง 4 กรณีต่อไปนี้เท่านั้น:

1. การสูญเสียหรือการเผยแพร่สู่ภายนอก (push · deploy · send · delete)
2. จุดที่ต้องตัดสินใจแยกทางครั้งสำคัญใหม่ (ขั้นตัดสินใจ RRP/การออกแบบ แต่การรัน Phase A/B/C ที่ถูกกำหนดจากผลนั้นถือเป็น การรันที่ตัดสินแล้ว)
3. การปรับจังหวะเวลาของ deploy ที่ต้องรีสตาร์ต (ตัวการใช้งานจริงให้ทำแบบอัตโนมัติ แต่ปรับเฉพาะ เวลาที่จะรีสตาร์ต)
4. การ steering จากผู้ใช้อย่างชัดเจน (ผู้ใช้สั่งเปลี่ยนทิศทางโดยตรง)

แพตเทิร์นอย่าง "จะเริ่ม Phase A ไหม?" ซึ่งเป็นการถามซ้ำถึง การรันที่ตัดสินแล้ว ถูกนิยามว่าเป็นการละเมิดการปฏิบัติการอัตโนมัติ
และมีการบัญญัติเป็นหลักสำคัญไว้ใน seed ทั้ง 6 แบบ เพื่อให้ downstream (โปรเจกต์ที่นำ seed ไปใช้) บังคับการปฏิบัติการอัตโนมัติได้ด้วยตัวเอง

---

รวมเข้ากับ bootstrap seed v2.0+

EstreGenesis เป็น harness bootstrap · seed prompt library
โดยคัดลอกไฟล์ 6 ชุดของ 3 tier คือ Master/Lite/Compact × EN/KO ไปยังโปรเจกต์ใหม่
เพื่อทำ bootstrap interview และสร้าง AGENTS.md อัตโนมัติ
และโมดูล v2.0 (Constellation) · v2.3 (Superscalar) ก็ถูกรวมไว้ใน seed ทั้ง 6 แบบทั้งหมด
ดังนั้นแค่คัดลอก seed ก็จะได้ทั้งสองโมดูล + หลักการรันแบบอัตโนมัติครบถ้วน

• Master: หลักสำคัญ #12 (Constellation) + #13 (Superscalar) + #14 (การรันอัตโนมัติ) แบบข้อความเต็ม + § Constellation + § Execution Scheduling
• Lite/Compact: เวอร์ชันย่อของหลักการเดียวกัน + § สำคัญ
• ทุก tier มีการบังคับความสม่ำเสมอของการปฏิบัติการอัตโนมัติที่ตรวจสอบได้ด้วย grep

---

GitHub: https://github.com/SoliEstre/EstreGenesis

เนื้อหาโมดูล:
Constellation.md
Superscalar.md

บันทึกการเปลี่ยนแปลง: CHANGELOG.md