- Swarms คือฟีเจอร์ การออร์เคสเตรตมัลติเอเจนต์ ที่มีอยู่ภายใน Claude Code แต่ยังไม่เคยเปิดเผย
- ผู้ใช้จะไม่ได้คุยกับ AI coder เดี่ยวอีกต่อไป แต่จะ โต้ตอบกับ AI ที่ทำหน้าที่เป็นหัวหน้าทีม
- หัวหน้าทีมจะไม่เขียนโค้ดเอง แต่จะ วางแผน แบ่งงาน และสรุปผลลัพธ์ แล้วกระจายบทบาทให้เอเจนต์ย่อย
- หลังจากแผนได้รับการอนุมัติ เอเจนต์ผู้ปฏิบัติงานเฉพาะทาง จะทำงานแบบขนานเพื่อรับผิดชอบการพัฒนาจริง
- แสดงให้เห็นทิศทางที่ Claude Code กำลังขยายจากเครื่องมือเดี่ยวไปสู่ กระบวนการพัฒนาแบบทีม
วิธีการทำงาน
- เมื่อผู้ใช้อนุมัติแผน ระบบจะสลับไปเป็น Delegation Mode
- เอเจนต์ผู้ปฏิบัติงานเฉพาะทางหลายตัวจะถูกสร้างขึ้นและทำงานแบบขนาน
- ผู้ปฏิบัติงานแต่ละตัวรับผิดชอบงานลงมือทำจริง เช่น การเขียนโค้ด การวิเคราะห์ และการแก้ไข
- มีการประสานความคืบหน้าและการพึ่งพากันผ่านข้อความระหว่างผู้ปฏิบัติงาน
- ผลลัพธ์ทั้งหมดจะถูกรวบรวมกลับไปยัง หัวหน้าทีม และ ส่งคืนเป็นคำตอบสุดท้าย
เครื่องมือ claude-sneakpeek
- Repo claude-sneakpeek ให้บิลด์แบบขนานของ Claude Code ที่เปิด feature flag แล้ว
- สามารถทดลองใช้ฟีเจอร์ที่ยังไม่เปิดเผยรวมถึงโหมด Swarms ได้ และรันในสภาพแวดล้อมที่แยกจากการติดตั้ง Claude Code เดิมโดยสมบูรณ์
- ใช้การตั้งค่า เซสชัน MCP server และข้อมูลยืนยันตัวตนแยกต่างหาก
- มี ฟีเจอร์เพิ่มเติมที่ฝังอยู่ใน Claude Code แต่ยังไม่เปิดเผยต่อสาธารณะ ให้ใช้งาน
- รองรับการทำงานแบบมัลติเอเจนต์โดยตรงผ่าน Swarm mode
- สร้างเอเจนต์เบื้องหลังผ่าน Delegate mode
- มีฟีเจอร์ส่งข้อความระหว่างสมาชิกทีมและจัดการความเป็นเจ้าของงาน
- รองรับโมเดลและผู้ให้บริการเพิ่มเติม
- รองรับ Z.ai, MiniMax, OpenRouter และเชื่อมต่อโมเดลภายในเครื่องผ่าน cc-mirror ได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
พูดตามตรง มันอาจฟังดูเหมือนเรื่องเพี้ยนๆ แต่ผมเคยได้ โค้ดที่คุณภาพสูงที่สุด แบบนี้มาก่อน
ค่าใช้จ่ายสูงขึ้นราว 10 เท่า แต่ผมให้ “ทีมโปรเจกต์” ทั้งทีมที่มีเอเจนต์ย่อยหลายตัว ถูกจัดการด้วย Opus instance ตัวเดียว
งานคือพอร์ต Java server แบบ legacy ไปเป็น C# .NET 10 โดยใช้เอเจนต์ 9 ตัว, Kanban 7 ขั้น และโครงสร้าง Git Worktree ที่แยกกัน
แต่ละบทบาทมีดังนี้ —
Manager (Claude Opus 4.5): global event loop ที่ปลุกเอเจนต์ตามสถานะใน Kanban
Product Owner (Claude Opus 4.5): ดูแลกลยุทธ์, กัน scope creep
Scrum Master (Opus 4.5): จัดลำดับความสำคัญ backlog และมอบหมาย ticket
Architect (Sonnet 4.5): รับผิดชอบด้านออกแบบเท่านั้น ไม่ทำ implementation
Archaeologist (Grok-Free): อ่าน decompile ของ Java legacy เฉพาะเวลาจำเป็น
CAB (Opus 4.5): gatekeeper ที่คอยปฏิเสธฟีเจอร์ในขั้น design และ code
Dev Pair (Sonnet 4.5 + Haiku 4.5): วนลูป AD-TDD โดย Junior เขียน failing test แล้ว Senior แก้
Librarian (Gemini 2.5): จัดการเอกสารและ trigger การ retrospective
ถ้าถามตรงๆ ว่า “จำเป็นขนาดนั้นไหม?” ก็คงตอบว่า “ไม่” แต่การได้เห็น AI agents ทำงานร่วมกันมันสนุกมาก
เวอร์ชันเริ่มต้นของโปรเซสอยู่ที่ภาพนี้
อยากรู้ว่าเป็นแบบใช้ prompt ล้วนๆ, เป็น plugin หรือเป็นโครงสร้างที่วนเรียกผ่าน script
แล้ว Kanban อยู่ที่ไหนด้วย
เป็นรูปแบบที่มี coordinator หนึ่งตัว และมี เอเจนต์เฉพาะทาง อีกหลายตัว เช่น ผู้เชี่ยวชาญ backend, frontend, DB
หัวใจสำคัญคือ coordinator มันช่วยลดภาระการรับรู้ของผม และติดตามความคืบหน้าทั้งหมดได้ดี
ประมาณว่า “ไม่อยากคุยกับลิง อยากคุยกับคนเล่นออร์แกน” เริ่มจากสัมภาษณ์ manager กับ program manager ก่อน แล้วหลังจากนั้นปล่อยให้พวกเขาจัดการกันเอง และขอแค่เดโมกับอัปเดตเป็นระยะๆ ฟังดูขำดี
จริงๆ แล้วนี่คือการใช้ ฟีเจอร์ sub agent ที่มีอยู่ใน Claude
ไม่จำเป็นต้องไปสร้างอะไรแบบ tmux abstraction 300,000 บรรทัดด้วย Go
แค่สั่ง Claude ให้ทำงานขนานกันด้วย sub agent แบบ background ก็พอ
ควรมีไฟล์สำหรับส่งต่อ prompt, ติดตามความคืบหน้า และรายงานผล และแนะนำให้จำกัดแต่ละเอเจนต์ไว้ใน worktree แยก
ผมกำลังรวบรวม pattern นี้ไว้ที่ workforest.space
คนส่วนใหญ่กำลังพยายามสร้าง orchestrator แยกต่างหาก แต่จริงๆ แล้ว Claude เองนี่แหละคือ orchestrator ที่ดีที่สุด
ความต่างจากเครื่องมือเดิมคือมันเป็น abstraction ระดับ งาน ไม่ใช่ระดับบทสนทนา
Claude Code มีข้อจำกัดเพราะปัญหาจากแอป third-party เลยยังยึดกับ conversation เป็นหลัก แต่ Claude Code Web เป็นตัวแรกที่ขยายข้อจำกัดนั้น
วิธีนี้ทำให้ AI ประสานงานงานต่างๆ ด้วยตัวเอง โดยผู้ใช้ไม่ต้องคอยโยน prompt ตลอดเวลา
มันซับซ้อน แต่กำลังพัฒนาไปเป็นโครงสร้างแบบ AI จัดการ AI อีกที
เพียงแต่รายละเอียดด้านการวางแผนยังไม่พอ เลยยังเชื่อถือได้ไม่มากนัก
main agent ถูกสลับไปอยู่ใน context mode ที่เน้นการมอบหมายงาน และรวมเข้ากับระบบ task แบบทีมและระบบ mailbox
เป็นระดับของการผสานรวมที่ทำเป็น plugin ไม่ได้
ปกติผมจะซ้อน commit ไว้เหมือน PR แล้วค่อยเก็บด้วย rebase ซึ่งค่อนข้างทรมาน
ตอนนี้น่าจะเปลี่ยนไปใช้วิธีแยก branch เป็น 2~3 อันและจัดการให้ conflict น้อยที่สุดได้
มันช่วยรักษา context ให้สะอาดและยังได้ผลลัพธ์คุณภาพสูง
ผมอยากให้โค้ดพัฒนาไปในทางที่ สั้นลงและคุณภาพสูงขึ้น
แต่ตอนนี้ทิศทางเหมือนจะตรงกันข้าม
ถ้าโมเดลแข็งแรงขึ้น และมี common sense กับ feedback loop ที่ดีขึ้น มันก็น่าจะมีประโยชน์ แต่ตอนนี้กลับเหมือน “ยิ่งโค้ดเยอะยิ่งดี” จนทำให้ปัญหาหนักขึ้น
เดโมสวยๆ น่ะทำได้ แต่ในสภาพแวดล้อม production จริง โค้ดอาจซับซ้อนขึ้น 10~100 เท่า
ตอนที่ Claude บอกให้เพิ่มสถิติ test coverage ใน CI มันกลับพยายาม เขียน Istanbul ใหม่ด้วย bash เพราะยังไม่ได้ติดตั้ง nyc
สุดท้ายผมต้องบอกว่า “ติดตั้ง nyc ไปเลย”
ถึงอย่างนั้น การทดลองแบบนี้ก็น่าจะช่วยขยายขีดจำกัดของโมเดลได้
ตอนนี้อาจยังไม่ใช่ แต่ราวปี 2026 ก็คงเป็นไปได้
อยากให้ใน HN มีโหวตสำรวจ อันดับความนิยมของ AI coding agent เป็นระยะๆ
คล้าย TIOBE Index ของแต่ละภาษา จะได้เห็นแนวโน้มว่าโมเดลไหนกำลังได้รับความนิยม
การแข่งเรื่องอันดับสุดท้ายก็เป็นแค่ วัฏจักรไฮป์ ที่หมุนเวียนไปเรื่อยๆ
รู้สึกน่าสนใจที่ MiniMax 2.1 อยู่อันดับเหนือ GPT ส่วนใหญ่
และที่ openrouter.ai ก็พอดู throughput กับต้นทุนของโมเดลได้คร่าวๆ
เพราะแบบนั้นเลยได้เปลี่ยนมาใช้ Opus 4.5 เป็นตัวหลักภายในสัปดาห์แรกที่เปิดตัว
ในกลุ่มผู้ใช้นั้นประมาณ 80% ใช้ Claude Code และ 75% อยู่ในสภาพแวดล้อม darwin-arm64
Claude สร้างโค้ดเยอะเกินไปจน รีวิวยาก เป็นปัญหาอยู่
บางคนบอกว่า “แค่ผ่านเทสต์ก็พอ” แต่กับโปรเจกต์ที่ต้องดูแลระยะยาวมันน่ากังวล
อยากรู้ประสบการณ์ของคนที่ลองปล่อยให้ generate โค้ดแบบ YOLO ในโปรเจกต์ระยะยาวจริงๆ
คุณภาพโค้ดยังไม่ดีพอ และการ debug ก็ยังพลาดบ่อย
แต่ก็มีประโยชน์ในแง่การค้นหา ความเข้าใจ และการต่อยอดไอเดีย
ถ้าเป็นโปรเจกต์ทดลองส่วนตัว แนว YOLO ก็โอเค
แบบนี้จะทำให้สร้างโค้ดอัตโนมัติได้ แต่ยังรักษาความเข้าใจระบบไว้ได้
ให้ Codex เสนอประเด็นสำหรับรีวิว แล้วค่อยตรวจสอบความแม่นยำของมันในรีวิวจริง
มีคำพูดว่า “ตอนนี้ไม่ได้คุยกับ AI coder แล้ว แต่คุยกับ team lead”
แต่ตลกตรงที่แม้แต่ทวีตนั้นเองก็ดูเหมือน AI เขียน
ปี 2026 น่าจะเป็นปีที่ agent orchestrator กลายเป็นเทรนด์หลัก
การใช้คำศัพท์ซอฟต์แวร์เดิมๆ เช่น team lead, team member น่าจะช่วยให้คนเข้าใจและยอมรับได้ง่ายขึ้น
ถ้า Anthropic จัดระเบียบโมเดลของตัวเองได้ เลเยอร์พวกนี้ก็จะไม่จำเป็น
สุดท้ายแก่นจริงๆ คือระบบ messaging และ task management
ประโยค “บอก team lead กับทั้งทีมว่า ทำปุ่มนี้ให้เป็นสีแดง” มันตลกดี
สุดท้ายบทสรุปคือ “โอเค ทีนี้ทำปุ่มให้เป็นสีแดง!” เป็นการเสียดสีที่สมบูรณ์แบบ
ดูวิดีโอนี้แล้วจะเข้าใจอารมณ์
ถ้าใส่คำแนะนำเพิ่มใน CLAUDE.md ก็สามารถปรับไม่ให้มันใช้ swarm mode กับงานเล็กๆ ได้
ในเวอร์ชัน 2.1.9 ล่าสุด วิธีที่ ลูปหลัก orchestrate เอเจนต์ย่อย เปลี่ยนไปอย่างสิ้นเชิง
มี log แบบ “FTSChunkManager agent ยังรันอยู่ แต่กำลังคืบหน้า งั้นรอก่อน” โผล่มา พร้อม stack trace และ JSON output
ผมเคยเห็นพฤติกรรมแบบนี้โดยตรงในแอป Claude Code เดสก์ท็อป
ใต้ master task จะมี worker leader agents จำนวนมากคอยสำรวจ codebase แล้วเขียนรายงานกับ TODO list
จากนั้นอีกระบบหนึ่งจะนำสิ่งเหล่านั้นมารวมเป็น master schema และแผนงาน
ผมสร้างแชตแยกสำหรับ devops, frontend, architecture, security และเมื่อแต่ละแชตจบก็ให้บันทึก log แล้วอัปเดตกันไปมา
ถ้าให้มันเชื่อม SSH ไปยัง droplet แล้วใช้ terminal Claude ก็จะ build, แก้ไข, test, verify วนซ้ำด้วยตัวเอง
ผมทำโปรเจกต์นี้เสร็จภายใน 3 วันด้วยวิธีนี้