Dual-Brain — สกิลที่เพิ่มเวิร์กโฟลว์ดีเบตแบบ ‘สมองซีกซ้าย·สมองซีกขวา’ ให้กับ Codex/Claude Code

สวัสดีครับ/ค่ะ ช่วงนี้ผม/ฉันใช้ Codex และ Claude Code ในงานจริงอยู่ และอยากแนะนำ Dual-Brain ซึ่งเป็นโปรโตคอลสกิลส่วนขยายแบบโอเพนซอร์สที่กำลังพัฒนา เพื่อช่วยลดปัญหาที่ LLM มักโอเวอร์โหลดได้ง่ายหรือกลับคำตัดสินใจเดิมเมื่อเขียนโค้ดที่ซับซ้อน

Dual-Brain ไม่ได้ใกล้เคียงกับวิธีแบ่งบทบาทให้ AI เป็นตำแหน่งอย่าง “PM / นักพัฒนา / QA” แต่จะใกล้กับการแยกฟังก์ชันการคิดที่ใช้มองปัญหามากกว่า

แทนที่เอเจนต์ตัวเดียวจะตอบออกมาทันที มันจะบังคับให้ผ่านการซักถามเชิงบริบทในบทบาทสมองซีกขวา และการตรวจสอบเชิงตรรกะในบทบาทสมองซีกซ้ายตามลำดับ ก่อนให้ orchestrator สังเคราะห์ผลลัพธ์สุดท้าย

1. 3 รูปแบบความล้มเหลวของการรันเอเจนต์เดี่ยวแบบเดิม

เมื่อสั่งให้ LLM ออกแบบสถาปัตยกรรมที่ซับซ้อนหรือทำ refactoring ครั้งเดียวจบในเทอร์มินัล มักเจอปัญหาต่อไปนี้บ่อย

• กับดักของการรับคำตามตัวอักษร
  มันรับ requirement ที่กำกวมไปตรง ๆ แล้วสร้างโค้ดผิดทิศผิดทางอย่างมั่นใจ
• นรกของรายละเอียด
  มันหมกมุ่นอยู่กับไวยากรณ์โค้ดระดับจุลภาคและ edge case จนพลาดเส้นทางเชิงสถาปัตยกรรมที่เรียบง่ายและดีกว่า
• ลูปความจำเสื่อม
  เมื่อจบเซสชันแล้วบริบทก่อนหน้าหายไป ทำให้ทิศทางสถาปัตยกรรมที่ตัดสินใจไว้ตั้งแต่สัปดาห์ก่อน ถูกกลับคำอีกครั้งในเซสชันถัดไป

2. วิธีแก้: ฟังก์ชันการคิดสองชุด

เมื่อโหลด Dual-Brain แล้ว เอเจนต์หลักจะรับบทเป็น orchestrator และจะไม่ตอบทันที แต่จะรันขั้นตอนทบทวนภายในสองขั้นตามลำดับที่กำหนด

• สมองซีกขวา, Right Brain: บริบท / แพตเทิร์น / การซักถาม
  มันจะไม่รีบลงมือทำตามความต้องการของผู้ใช้ทันที แต่จะตั้งข้อสงสัยก่อน เช่น “จุดบอดของ requirement นี้คืออะไร?”, “มันขัดกับการตัดสินใจในอดีตหรือไม่?”, “คำศัพท์มีความกำกวมหรือเปล่า?”
• สมองซีกซ้าย, Left Brain: ตรรกะ / การตรวจสอบ / โค้ด
  มันจะนำคำจำกัดความของปัญหาที่สมองซีกขวาสร้างขึ้น ไปเทียบกับ codebase จริง เอกสารทางการ และ memory ของโปรเจกต์ เพื่อกรอง API หลอน สมมติฐานที่ล้าสมัย และดีไซน์ที่ทำจริงไม่ได้ แล้วขัดเกลาให้อยู่ในรูปแบบที่นำไปปฏิบัติได้

ท้ายที่สุด orchestrator จะสังเคราะห์ผลลัพธ์จากทั้งสองฝั่ง แล้วต่อยอดไปถึงการแก้โค้ด การทำเอกสาร และการอัปเดต memory

3. ระบบจัดระดับความจำ

สกิลนี้จะเก็บความจำระยะยาวไว้ใน .dual-brain/MEMORY.md ที่ root ของโปรเจกต์

แต่เมื่อโปรเจกต์ใหญ่ขึ้น อาจเกิดปัญหาที่การตัดสินใจเมื่อหลายเดือนก่อนกับข้อจำกัดที่ยัง active อยู่เมื่อสัปดาห์ก่อน ถูกปะปนกันด้วยน้ำหนักเท่ากัน เพื่อแก้เรื่องนี้ memory จึงไม่ได้ถูกมองเป็นเอกสารแบบ flat แต่เป็น tiered memory

• Hot Memory
• Warm Memory
• Cold Memory
• Archived Decisions

Hot Memory คือการตัดสินใจและข้อจำกัดที่ยัง active และส่งผลแรงต่อการทำงานปัจจุบัน

Warm Memory คือบริบทที่มีประโยชน์ซึ่งจะถูกอ่านเฉพาะในงานที่เกี่ยวข้อง

Cold Memory และ Archived Decisions จะไม่ถูกอ่านทั้งหมดโดยอัตโนมัติ แต่จะถูกเรียกดูเฉพาะเมื่อจำเป็นต้องค้นหาด้วยคีย์เวิร์ดหรือใช้ตรวจสอบความขัดแย้ง

refs จะไม่เพิ่มขึ้นเพียงเพราะมีการอ่าน แต่จะเพิ่มเฉพาะเมื่อมันมีผลต่อคำถามจริง การตรวจสอบ การสังเคราะห์ หรือการลงมือทำ

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

ข้อมูลอ่อนไหว โทเค็น คีย์ และข้อมูลส่วนบุคคล จะไม่ถูกเก็บหรือสรุป แต่จะถูกจัดการเป็นข้อมูลที่ต้องลบหรือไม่บันทึก

สิ่งสำคัญคือ memory ไม่ใช่แหล่งความจริงสูงสุด ใน Dual-Brain นั้น memory เป็น advisory context และโค้ดปัจจุบันกับเอกสารทางการจะมีลำดับความสำคัญเหนือ stale memory

4. เบนช์มาร์ก

ใน repo มี benchmark harness ขนาดเล็กสำหรับเปรียบเทียบวิธี single-agent กับวิธี Dual-Brain โดยอ้างอิงจาก Codex

Dual-Brain ไม่ใช่วิธีที่เร็วกว่า ตรงกันข้าม มันมีเป้าหมายให้คิดมากขึ้นในช่วงต้น เพื่อช่วยลดลูปที่มนุษย์ต้องกลับมาแก้และอธิบายใหม่ในภายหลัง

5. การติดตั้ง

หากใช้ SkillsGate คุณสามารถติดตั้งและจัดการสกิลในสภาพแวดล้อม Codex CLI และ Claude Code ได้

npx skillsgate add sleeplesshan/dual-brain -g  
สามารถติดตั้งด้วยตนเองได้  
 - Codex  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.codex/skills/dual-brain  
 - Claude Code  
Bash  
git clone [https://github.com/sleeplesshan/dual-brain.git](https://github.com/sleeplesshan/dual-brain.git) ~/.claude/skills/dual-brain  
หลังการติดตั้ง สามารถเรียกใช้งานได้ตามปกติด้วยภาษาธรรมชาติ  
  
6. เหมาะจะใช้เมื่อไร
Dual-Brain ถือว่าเกินความจำเป็นสำหรับการแก้ไขง่าย ๆ ไม่จำเป็นต้องใช้กับการเปลี่ยนชื่อตัวแปร แก้บั๊กหนึ่งบรรทัด หรือ boilerplate ที่ชัดเจน
แต่เหมาะมากในสถานการณ์ต่อไปนี้
- refactoring ที่ requirement ไม่ชัดเจน
- การตัดสินใจด้านสถาปัตยกรรม
- การรวม API หรือ SDK ที่ไม่คุ้นเคย
- การเปลี่ยนแปลงที่อาจขัดกับการตัดสินใจในอดีต
- งานที่ hallucinated API อาจนำไปสู่ปัญหาจริงในการทำงาน
- งานประเภทที่รู้สึกว่า “ฉันยังไม่แน่ใจด้วยซ้ำว่ากำลังตั้งคำถามได้ถูกหรือเปล่า”
  
ได้เปิดเผยทั้ง `SKILL.md` และ benchmark harness แบบโอเพนซอร์ส (ไลเซนส์ MIT) ไว้แล้ว
อยากรับฟังฟีดแบ็กจากผู้ที่สนใจเรื่อง LLM orchestration, prompt engineering และการออกแบบ agent memory