Framein - ไม่ใช่ค็อกพิท ไม่ใช่พร็อกซี และไม่ใช่ฮาร์เนส แต่เป็นเลเยอร์สถานะงานใต้ AI coding agent

ช่วงนี้ผมทำงานเขียนโค้ดส่วนใหญ่ร่วมกับ terminal agent อยู่เสมอ โดยเปิด Claude Code, Codex และ Gemini CLI เรียงกันไว้ใน VS Code แล้วให้ Claude ทำงาน implement หลัก ส่วนเวลาต้องการมุมมองจากภายนอก เช่น เรื่องความปลอดภัยหรือ regression ก็ให้ Codex ช่วยตรวจทาน แต่พอทำแบบนี้ ทุกครั้งที่เปลี่ยนโมเดล ผมต้องอธิบายใหม่เสมอว่าเป้าหมายคืออะไร อะไรห้ามพัง และโมเดลก่อนหน้าลองทำอะไรแล้วล้มเหลวไปบ้าง สุดท้ายผมเลยกลายเป็น human clipboard ที่คอยเชื่อมระหว่างสามเทอร์มินัลไปโดยปริยาย

พอลองหาดู ก็พบว่ามีเครื่องมือคล้ายกันอยู่มากแล้ว ไม่ว่าจะเป็นค็อกพิทที่รวมหลายเอเจนต์ไว้ในหน้าต่างเดียว (เช่น Claude Squad, Orch term), พร็อกซีที่ให้เรียกใช้โมเดลอื่นจากฮาร์เนสเดียวกันได้ (เช่น opencodex, oh-my-free-models) หรือออร์เคสเตรเตอร์ที่แบ่งบทบาทและกระจายงาน (เช่น Oh My OpenCode) แต่ปัญหาที่ผมเจอจริง ๆ คือการทำให้งานไม่สะดุดแม้จะเปลี่ยนโมเดล กลับมีเครื่องมือที่จัดการเรื่องนี้ตรง ๆ น้อยกว่าที่คิด ส่วนใหญ่จะเน้นไปทาง "ทำ handoff ให้ดีขึ้น" มากกว่า

Framein เลือกอีกทางหนึ่ง แทนที่จะทำให้ handoff ดีขึ้น มันพยายามทำให้ไม่จำเป็นต้องมี handoff ตั้งแต่แรก มันไม่ใช่ IDE ใหม่ ไม่ใช่ค็อกพิท ไม่ใช่พร็อกซี และไม่ใช่อีกหนึ่งฮาร์เนส แต่เป็นเลเยอร์สถานะงาน (work-state) แบบโลคัลที่บางและวางอยู่ใต้เอเจนต์ที่คุณใช้อยู่แล้ว เพราะเอเจนต์ทั้งสามตัวสามารถอ่าน task contract, บันทึกการตัดสินใจ และผลการตรวจสอบชุดเดียวกันจากใน repo ได้ร่วมกัน การ "ส่งต่องาน" จึงไม่ต้องกลายเป็นขั้นตอนแยกอีกต่อไป โมเดลถัดไปไม่ได้อ่านข้อเท็จจริงที่ผมสรุปให้ แต่ได้อ่านข้อเท็จจริงนั้นโดยตรง

ลูปการทำงานมีอยู่ 4 คำกริยา โดยคำว่า 'lead' ในที่นี้หมายถึงโมเดลที่กำลังรับผิดชอบการ implement อยู่จริงในตอนนั้น ใช้เพื่อแยกจากโมเดลที่ทำหน้าที่รีวิว

• start : ตรึงคำขอให้กลายเป็น task contract (เป้าหมาย, acceptance criteria, พื้นที่ที่ต้องปกป้อง, non-goal) ก่อนที่การ implement จะเริ่มแกว่ง
• challenge : ขอให้โมเดลอื่นช่วยโต้แย้งแบบเจาะจงขอบเขตแคบ ๆ ให้ lead ตอบเพียงครั้งเดียว แล้วผมเป็นคนตัดสินใจ จุดนี้คือเวลาที่โมเดลหนึ่งพูดอย่างมั่นใจว่า "ผมทำ implementation เสร็จทั้งหมดแล้ว" ขณะที่อีกโมเดลหนึ่งซึ่งอ่าน contract และ diff ชุดเดียวกัน จะช่วยถามว่า "ยังมีความเสี่ยงอะไรที่แผนนี้ตกหล่นไปหรือไม่"
• capsule : เตรียมข้อเท็จจริงที่ lead คนถัดไปต้องอ่าน (contract, diff, verification, ADR, ledger)
• ship : ปิดงานด้วย build/test/risk gate จริง ไม่ใช่แค่ให้โมเดลพูดว่า "เสร็จแล้ว"

คุณสามารถเรียกใช้ได้จากเทอร์มินัลโดยตรง หรือภายใน Claude/Gemini ผ่านคำสั่ง slash แบบ /fr:* และใน Codex ผ่านสกิล $fr-* ไม่ว่าจะเรียกจากทางไหน ก็จะอ่านและเขียนผ่าน local engine และสถานะชุดเดียวกัน โครงสร้างนี้จึงคง harness, skill pack และ persona เดิมไว้ได้ทั้งหมด แล้วเพียงวาง contract, ledger และ gate ไว้ข้างใต้

สิ่งที่ใส่ใจเป็นพิเศษในงานออกแบบมีดังนี้

• บันทึกการตัดสินใจ (ADR) เป็นแบบ append-only จะไม่แก้ไขหรือลบ แต่แทนที่ด้วยบันทึกใหม่เท่านั้น ผมมองว่าหากบันทึกการตัดสินใจสามารถแก้เงียบ ๆ ได้ พอโมเดลตัวที่สองเชื่อมันขึ้นมา มันก็หมดคุณค่าในทันที
• ไม่เก็บ credential ไม่มีการ relay token, ไม่มีการ pooling subscription และไม่มีการ scrape อินพุต/เอาต์พุตของเทอร์มินัล การยืนยันตัวตนยังอยู่กับ official CLI ของแต่ละตัวตามเดิม และจะเรียกใช้จากโลคัลเมื่อจำเป็นเท่านั้น (จึงเป็นคนละชั้นกับเครื่องมือสายพร็อกซี)
• ไม่มี runtime dependency เลย ใช้แค่ node:sqlite ที่มากับ Node 22 และ test runner ในตัว SQLite store เป็นแคช ส่วนแหล่งข้อมูลจริงคือ JSON snapshot ที่เป็นมิตรกับ git ดังนั้นต่อให้ผ่านไปอีกครึ่งปี ก็ไม่ต้องกังวลว่า dependency เปลี่ยนจนติดตั้งพัง

ตอนนี้อยู่ในสถานะ pre-release v0.0.6 และมีการ implement ส่วน core แล้ว ได้แก่ store, การฉายไปยัง CLAUDE.md/AGENTS.md/GEMINI.md, task contract, verify/risk/ship gate, wrapper แบบ /fr:·$fr- และ MCP server โดยผ่านการทดสอบแล้ว 249 รายการ สิ่งที่ยังเกลาปรับอยู่คือเส้นทาง code signing บน Windows, การแจกจ่าย executable ที่เซ็นลายเซ็นและ notarized แล้ว, การตรวจสอบการติดตั้งบนเครื่องสะอาด และ workflow สำหรับนักพัฒนาหลายคน

ติดตั้งได้ด้วย npm install -g framein (ต้องใช้ Node 22.5+) และอยู่ภายใต้สัญญาอนุญาต MIT ชื่อนี้มาจากศัพท์ในวงการภาพยนตร์ ถ้าวัตถุหลุดออกไปนอกมุมภาพจะเรียกว่า frame out ส่วนการดึงกลับเข้ามาในเฟรมคือ frame in จึงตั้งชื่อนี้ในความหมายว่า ดึงเอเจนต์สามตัวที่กระจัดกระจายให้กลับมาอยู่ในเฟรมเดียวกัน

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

เว็บไซต์ : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
บันทึกจากผู้พัฒนา (ทำไมถึงสร้างมันขึ้นมา) : https://www.framein.dev/ko/why