Muse Wonder Full ปรับเป็นระบบ Subscription เท่านั้น ส่งผลอย่างไรต่อทีม Agent

โมเดลที่ทรงพลังที่สุดของ Meta ไม่ได้เปิดให้ใช้งานผ่าน API ของ Meta โดย Muse Wonder Full ทำคะแนนได้ 56 บน Artificial Analysis Intelligence Index, เสมอกับ Claude Code บน Sonnet 5.5 ที่ 68 คะแนนบน Coding Agents Index และเอาชนะทุกโมเดลบนเบนช์มาร์กด้านโค้ดดิ้งระยะยาวของ Meta แต่คุณจะใช้งานโมเดลนี้ได้ก็ต่อเมื่อใช้งานภายใน Muse Code ซึ่งเป็น terminal agent ของ Meta ภายใต้แพ็กเกจ Power ราคา $50 หรือแพ็กเกจ Maximum ราคา $200 เท่านั้น ในขณะที่ตัว API ให้บริการเฉพาะ Muse Wonder รุ่นเล็กกว่าที่มีคะแนน 52 และ 63 อีกทั้ง Full ยังไม่มีราคาแบบคิดตามโทเค็น (per-token), ไม่มี gateway และยังไม่มีกำหนดการว่าจะเปิดให้บริการเมื่อใด

สำหรับนักพัฒนาเดี่ยว นี่เป็นเพียงเรื่องของการเลือกแพ็กเกจราคา แต่สำหรับทีมที่รัน agent ผ่านบอร์ดที่แชร์ร่วมกัน เรื่องนี้กลายเป็นประเด็นเชิงโครงสร้าง เพราะโมเดลที่ดีที่สุดของ Meta นั้นฝังตัวอยู่ในเทอร์มินัลของคนคนเดียว ภายใต้การสมัครสมาชิกของคนคนเดียว ด้วยการตั้งค่าข้อมูลของคนเพียงคนเดียว และไม่มี Task ใดที่ถูกมอบหมายสามารถเข้าถึงโมเดลนี้ได้ บทความนี้จะวิเคราะห์ว่าสิ่งนี้ส่งผลต่อ Crew อย่างไร และเราควรรับมือกับมันแบบไหน

สองโมเดล Wonder ในมุมมองของทีม

คอลัมน์ขวาคือเครื่องมือส่วนบุคคล ส่วนคอลัมน์ซ้ายคือเลนการทำงาน (lane) ของทีม ทุกสิ่งที่จะกล่าวถึงต่อไปนี้ล้วนมาจากความแตกต่างของสองสิ่งนี้

สิ่งที่ทีมต้องสูญเสีย เมื่อโมเดลที่ดีที่สุดกลายเป็นเครื่องมือส่วนตัว

งานหลุดออกไปจากบอร์ด คุณค่าสำคัญของ Sharkly คือการทำให้การมอบหมายงาน ความคืบหน้า อุปสรรค (blocker) ผลลัพธ์ และการรีวิว สามารถมองเห็นร่วมกันได้ตั้งแต่เริ่มคำขอจนถึงขั้นตอนรีลีส แต่เซสชันของ Muse Code กลับไม่มีสิ่งเหล่านี้เลย หากโมเดลที่เก่งที่สุดรันได้เฉพาะที่นั่น Task ที่ยากที่สุดก็จะถูกผลักไปอยู่กับใครก็ตามที่มีแพ็กเกจสมาชิก และสิ่งที่บอร์ดบันทึกได้ก็มีเพียง Task ที่เปลี่ยนสถานะเป็น Done โดยไร้ประวัติการรัน บันทึก log หรือเส้นทางการทำงานที่สามารถตรวจสอบย้อนหลังได้

การตั้งค่าของคนคนเดียวกลายเป็นนโยบายของทั้งทีม การสมัครสมาชิก Muse Code จะตั้งค่าเริ่มต้นเป็นโหมด Contributor ซึ่งอนุญาตให้ Meta นำพรอมต์ โค้ด และเอาต์พุตไปใช้ฝึกฝนโมเดลเพื่อแลกกับโควตาการใช้งานที่มากขึ้น แม้ผู้ใช้จะปิดโหมดนี้ได้ แต่ก็ไม่มีใครในทีมตรวจสอบได้ว่าเขาปิดไปแล้วจริงหรือไม่ ในทางกลับกัน Runtime บน Computer จะเรียกใช้ API ในโหมด Standard ซึ่งทราฟฟิกจะไม่ถูกนำไปใช้เทรนโมเดล และนโยบายนี้จะมีผลกับทุก Agent บน Computer โดยที่ไม่มีใครต้องคอยตรวจสอบการตั้งค่าเลย

ขีดจำกัดการใช้งานขึ้นอยู่กับระดับแพ็กเกจ ไม่ใช่คีย์ แพ็กเกจของ Muse Code จะรีเซ็ตโควตาทุก 5 ชั่วโมงและทุกสัปดาห์ ซึ่งสัปดาห์เปิดตัวก็แสดงให้เห็นแล้วว่าจะเกิดอะไรขึ้นเมื่อระบบมีปัญหา: ทั้ง Wonder และ Full ผลาญโควตาเร็วผิดปกติในวันแรก จน Meta ต้องรีเซ็ตระบบให้ทุกคน และ Alexandr Wang ก็ระบุว่ายังมีปัญหาที่ต้องแก้ไขอยู่ ส่วนเลนบน API มีข้อจำกัดที่ต่างออกไป คือรองรับได้ 3,000 คำขอและ 4 ล้านโทเค็นต่อนาทีโดยแชร์ร่วมกันทั้งทีม ซึ่งเป็นสิ่งที่ระบบบอร์ดสามารถวัดและจัดสรรปริมาณการใช้งานได้ ในขณะที่คนคนเดียวทำไม่ได้

เบนช์มาร์กที่เห็นไม่ใช่เบนช์มาร์กที่คุณได้ใช้งานจริง สื่อโปรโมตช่วงเปิดตัวของ Meta นำเสนอด้วยตัวเลขของรุ่น Full เป็นหลัก ใครก็ตามที่วางแผนกำลังการประมวลผลจากตัวเลขเหล่านั้น กำลังวางแผนให้กับโมเดลที่ Crew ไม่สามารถรันได้ ตัวเลขที่เกี่ยวข้องกับทีมจริงๆ คือของ Wonder รุ่นมาตรฐาน: 52 คะแนนบน index, 53.1 บน SWE-Marathon และ 25 ด้าน knowledge ซึ่งยังคงเป็นโมเดลที่ทำงานระยะยาวได้ดี และวิธีเปิดใช้งานก็ใช้เวลาตั้งค่าเพียงช่วงบ่ายวันเดียวเท่านั้น

สิ่งที่ทีมยังคงรักษาไว้ได้

ทั้งหมดนี้ไม่ได้หมายความว่า Full ไร้ประโยชน์ แต่มันเป็นเครื่องมือคนละประเภท และหากพูดกันตามตรง มันเหมาะกับบริบทเดียวกับที่ Claude Code หรือ Codex บนเทอร์มินัลส่วนตัวทำได้ดีอยู่แล้ว นั่นคือการสำรวจค้นคว้าของ lead engineer, งานศึกษาทดลอง (spike) ที่ยังไม่มีใครกำหนดขอบเขต, หรือเซสชันการดีบักสุดซับซ้อนที่ยังไม่สามารถนิยามเป็น Task ได้จนกว่าจะมีคนเข้าใจปัญหานั้นอย่างถ่องแท้ ซึ่ง Full ทำคะแนนได้ดีกว่าถึงสี่คะแนนในงานลักษณะนี้โดยเฉพาะ ดังนั้นจงใช้มันกับงานประเภทนี้

วินัยที่สำคัญอยู่ที่ขั้นตอนการส่งต่องาน (handoff) เมื่อเซสชันของ Muse Code เปลี่ยนความคลุมเครือให้กลายเป็นแผนงานที่ชัดเจน แผนงานนั้นก็จะกลายเป็น Task และ Task นั้นก็จะถูกส่งไปยังเลนการทำงานที่ทุกคนบนบอร์ดมองเห็นได้ จากนั้น Wonder Agent หรือ Opus 5.5 Agent ของ Crew จะเข้ามาจัดการงานที่ถูกกำหนดขอบเขตไว้เรียบร้อยแล้ว พร้อมมีบันทึก log การรันและผู้รีวิว สมาชิกรายบุคคลได้สิทธิ์ในการสำรวจทดลอง ส่วนทีมก็ยังคงรักษาบันทึกการทำงานส่วนกลางไว้ได้

แนวทางปฏิบัติเล็กๆ สองข้อที่จะช่วยให้กระบวนการนี้เป็นไปอย่างราบรื่น:

• ระบุชื่อโมเดลลงใน Task เนื่องจาก Sharkly ไม่ได้แสดงชื่อโมเดล ดังนั้นในคำสั่ง (instruction) ของ Agent ควรระบุ model id ไว้ที่ด้านบนสุดของรายงาน และผู้ที่คัดลอกผลลัพธ์มาจาก Muse Code ควรระบุข้อเท็จจริงนี้ไว้ในคอมเมนต์ของ Task เพราะหากผู้รีวิวไม่รู้ว่า diff นั้นมาจาก Full ในเทอร์มินัล หรือ Wonder บนเลนของระบบ ก็จะไม่สามารถประเมินความถูกต้องได้อย่างเหมาะสม
• ตัดสินใจเรื่องโหมด Contributor ร่วมกันทั้งทีม หากมีใครถือแพ็กเกจ Muse Code และใช้มันทำงานกับ repository ของทีม การเลือกปิดโหมดนี้ (opt-out) ต้องเป็นการตัดสินใจของทีมที่มีการบันทึกไว้อย่างชัดเจน ไม่ใช่ปล่อยให้เป็นการตั้งค่าส่วนตัวตามค่าเริ่มต้น บทความเรื่อง Prompt injection and agent guardrails ได้อธิบายไว้แล้วว่าเหตุใดด่านการรีวิว (review gate) จึงเป็นจุดควบคุมที่แท้จริง ไม่ใช่ตัวโมเดล

ตัวอย่างการทำงานในหนึ่งสัปดาห์

ลองจินตนาการถึงทีมที่มีสมาชิกห้าคนในสัปดาห์แรกหลังการเปิดตัว Lead ตัดสินใจซื้อ Muse Code Power ตั้งแต่วันแรก และใช้เวลาตลอดวันจันทร์ทำงานกับ Full เพื่อวางแผนการย้ายระบบ (migration) ที่ไม่มีใครอยากทำ พอถึงวันอังคาร แผนงานก็เริ่มเป็นรูปเป็นร่าง: แบ่งออกเป็นสี่ส่วนที่มีขอบเขตชัดเจน แต่ละส่วนมีชุดทดสอบที่ต้องผ่านให้ได้ งานทั้งสี่ส่วนนั้นกลายเป็น Task บนบอร์ด ซึ่งถูกมอบหมายให้ Wonder Agent บน Codex Runtime และรันไปพร้อมๆ กันแบบคู่ขนานบน Computer ของทีม ในขณะที่ lead คอยรีวิวจาก Inbox งานสองชิ้นผ่านฉลุยอย่างไร้ปัญหา งานชิ้นที่สามแจ้งกลับมาเพื่อสอบถามเกี่ยวกับการเปลี่ยนแปลง schema นอก repository ที่เชื่อมต่อไว้ ซึ่ง lead เข้าไปตอบคอมเมนต์ใน Task นั้น ส่วนงานชิ้นสุดท้ายรันชุดทดสอบไม่ผ่านสองครั้ง แต่ระบบยังคงดำเนินการต่อ จนกระทั่งปิดงานได้สำเร็จในการทดลองวิธีที่สาม พร้อม log ที่แสดงประวัติการทำงานทั้งสามครั้ง

ตลอดสัปดาห์นั้น ไม่มีส่วนไหนที่จำเป็นต้องนำ Full มารันบนบอร์ดเลย เพราะ Full ได้ทำหน้าที่ในส่วนที่ยังไม่พร้อมจะกลายเป็น Task ไปแล้ว ส่วน Wonder ก็ทำหน้าที่จัดการ Task เหล่านั้น บันทึกการทำงานแสดงให้เห็นชัดเจนว่าใครทำอะไรและใช้โมเดลใด เพราะ instruction ของ Agent มีการระบุ model id ไว้ที่ด้านบนสุดของทุกรายงาน และคอมเมนต์ของ lead เองก็ระบุชัดเจนว่าแผนนี้มาจากเซสชันของ Muse Code นี่คือการแบ่งหน้าที่การทำงานที่ Sharkly ออกแบบมาเพื่อรองรับ: เครื่องมือประมวลผลทำหน้าที่ลงมือปฏิบัติ ส่วนบอร์ดช่วยรักษาความโปร่งใส ให้ทุกคนมองเห็นทั้งการมอบหมาย บริบท อุปสรรค ผลลัพธ์ และการรีวิวในทุกขั้นตอน

ในทางกลับกัน ภาพความล้มเหลวของสัปดาห์เดียวกันนี้ก็จินตนาการได้ไม่ยาก Lead ทำงานทั้งสี่ส่วนด้วย Full เพียงลำพังเพราะความสะดวก กด push branch ในวันพฤหัสบดี แล้วทีมก็ต้องมารีวิว diff ขนาดยาวกว่า 2,000 บรรทัด โดยไม่มี log การรัน และไม่รู้เลยว่ามีส่วนไหนบ้างที่โมเดลไม่แน่ใจ เร็วขึ้นในวันจันทร์ แต่กลับมาชะงักและช้าลงในวันศุกร์

Full จะเปิดให้ใช้งานผ่าน API หรือไม่?

บล็อกสำหรับนักพัฒนาของ Meta ระบุว่า Full เปิดให้ใช้งานเฉพาะผ่านการสมัครสมาชิก Muse Code เท่านั้น และยังไม่มีการกำหนดกรอบเวลา เหตุผลทางธุรกิจนั้นชัดเจนอยู่แล้ว: Full คือเหตุผลที่ทำให้ผู้ใช้ยอมจ่าย $50 ต่อเดือน และการคิดราคาแบบต่อโทเค็นจะกลายมาเป็นคู่แข่งแย่งตลาดนี้เอง ถึงอย่างนั้น Meta ก็ได้ปล่อย dialect สำหรับ API ออกมาถึงสามแบบ จัดทำเอกสารแนะนำการใช้งาน Claude Code และ Codex บน Wonder รวมทั้งนำ Wonder ไปเปิดให้บริการบน Vercel และ Cloudflare ในสัปดาห์เปิดตัว จึงเห็นได้ชัดว่า API ไม่ใช่เรื่องที่ถูกมองข้าม ทิศทางที่มีความเป็นไปได้มากที่สุดคือ Full จะเปิดให้ใช้งานบน API ก็ต่อเมื่อมีโมเดลรุ่นถัดไปเข้ามารับตำแหน่งเรือธงใน Muse Code แทน ดังนั้น ตอนนี้ให้วางแผนเลนการทำงานบน Wonder ไปก่อน แล้วค่อยกลับมาทบทวนอีกครั้งเมื่อหน้ารายการโมเดลมีการเปลี่ยนแปลง

สรุปแนวทางการตัดสินใจในตารางเดียว

โมเดลที่มีคะแนนดีกว่าตัวที่ Agent ของคุณรันได้อยู่ 4 คะแนน อาจเป็นเหตุผลที่ดีในการรักษาสถานะสมาชิกไว้ แต่ไม่ใช่เหตุผลที่จะย้ายงานออกไปจากบอร์ด เพราะการรันที่มีความหมายอย่างแท้จริง คือการรันที่ทุกคนสามารถมองเห็นร่วมกันได้