เจาะลึก AI Agent Swarms: การทำงานของ Planner, Workers และ Verifiers

สรุปใจความสำคัญ (TL;DR)

AI agent swarm แบ่งเป้าหมายเดียวออกเป็น 3 บทบาทหลัก ได้แก่ Planner ที่คอยย่อยงานออกเป็นงานย่อย, Workers ที่ลงมือสร้างงานเหล่านั้นไปพร้อมกันแบบคู่ขนานในพื้นที่ทำงานแยกส่วน และ Verifiers ที่คอยทดสอบทุกความเปลี่ยนแปลงก่อนนำไปใช้งานจริง โดย Planner และ Verifier จะใช้โมเดลที่ทรงพลังที่สุดของคุณ ส่วน Workers จะใช้โมเดลที่ประหยัดและรวดเร็วกว่า รูปแบบนี้จะล้มเหลวก็ต่อเมื่อ Workers แก้ไขไฟล์ร่วมกัน, Verifiers อนุมัติผ่าน ๆ โดยไม่ตรวจสอบจริง หรือไม่มีใครกำหนดเพดานค่าใช้จ่าย

ทำไม AI Agent Swarm ถึงกลับมาเป็นที่พูดถึงอีกครั้ง

Google ได้เปิดตัว Gemini 4 Carbon สู่การใช้งานทั่วไป พร้อมเปิดตัวพรีวิวคำสั่ง /swarm ใน Google Antigravity ซึ่งจะเปลี่ยนพรอมต์เพียงข้อความเดียวให้กลายเป็นทีม Agent ที่ทำงานประสานกันอย่างเป็นระบบ ตามคำอธิบายของ Google นั้น Carbon จะรับผิดชอบด้าน “การออกแบบสถาปัตยกรรม การประสานงาน และการตรวจสอบ” โดยจับคู่กับ “โมเดลที่มีความเร็วและมีขนาดเบากว่า ซึ่งทำงานคู่ขนานกันในพื้นที่ทำงานที่แยกเป็นอิสระต่อกัน ร่วมกับ Adversarial Verifier ที่คอยตรวจสอบความเปลี่ยนแปลงทุกจุดอย่างเข้มข้น”

ประโยคข้างต้นได้อธิบายถึงรูปแบบการทำงานที่คุณสามารถนำไปปรับใช้กับโมเดลที่มีอยู่แล้วได้ คู่มือนี้จะพาคุณไปรู้จักกับทั้ง 3 บทบาท เหตุผลว่าทำไมงบประมาณส่วนใหญ่จึงควรนำไปใช้กับการวางแผนและการตรวจสอบ จุดที่ Swarm มักจะพัง และวิธีรัน Swarm บนบอร์ดที่ใช้ร่วมกัน หากคุณรัน Coding Agent หลายตัวอยู่แล้ว Sharkly จะช่วยมอบหมาย Task ให้แต่ละตัว พร้อมบันทึก Run Log และมีขั้นตอน Review ให้ในตัว ซึ่งครอบคลุมเกือบทุกสิ่งที่ Swarm จำเป็นต้องมี

AI Agent Swarm คืออะไร?

AI Agent Swarm คือกลุ่มของ AI Agent ที่ช่วยกันแบ่งเป้าหมายใหญ่ออกเป็นงานย่อยที่เป็นอิสระต่อกัน แล้วลงมือทำพร้อมกัน โดยมี Agent ตัวหนึ่งทำหน้าที่วางแผนและมอบหมายงาน Agent อีกหลายตัวลงมือทำไปพร้อม ๆ กันแบบคู่ขนาน และมี Agent หนึ่งตัวขึ้นไปคอยตรวจสอบผลลัพธ์แต่ละชิ้นก่อนที่จะนำมารวมเข้าด้วยกัน แต่ละบทบาทจะมีขอบเขตหน้าที่ที่เจาะจงชัดเจนและมีการส่งต่องานที่เป็นระบบ

Anthropic เคยอธิบายรูปแบบการทำงานโครงสร้างเดียวกันนี้ไว้ในปี 2024 ในชื่อ Orchestrator-Workers Pattern โดยมีโมเดลศูนย์กลางทำหน้าที่แตกงานย่อย กระจายงาน และรวบรวมผลลัพธ์ แต่สิ่งที่เพิ่มเข้ามาใหม่คือ Verifier ซึ่งเป็นบทบาทที่ทีมส่วนใหญ่มักมองข้ามไป

Swarm ไม่ใช่ “การให้ Agent หลายตัวมานั่งทำงานแบบเดียวกัน” การใช้ Agent 5 ตัวด้วยพรอมต์เดียวกันบน Repository เดียวกันนั้นไม่ใช่การทำงานเป็นทีม แต่เป็นสภาวะแย่งชิงทรัพยากร (Race Condition) การแบ่งบทบาทหน้าที่ต่างหากที่ทำให้มันเป็น Swarm หากต้องการเห็นภาพรวมที่กว้างขึ้นว่าการประสานงานของ Agent ทำงานอย่างไร สามารถอ่านเพิ่มเติมได้ที่ AI Agent Orchestration คืออะไร

3 บทบาทสำคัญ: Planner, Workers และ Verifiers

แต่ละบทบาทจะตอบโจทย์คนละคำถาม และจำเป็นต้องใช้บริบทที่แตกต่างกัน

Planner ทำหน้าที่อะไร?

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

Workers ทำหน้าที่อะไร?

Worker แต่ละตัวจะรับผิดชอบสร้างงานทีละงานไปพร้อม ๆ กันแบบคู่ขนาน และไม่ทำสิ่งอื่นเกินหน้าที่ โดย Worker แต่ละตัวจะมีพื้นที่ทำงานเป็นของตัวเอง ซึ่งมักจะเป็น git worktree หรือการ checkout แยกต่างหากของ repository เดียวกันบน branch ของตัวเอง การแยกพื้นที่ทำงานอย่างเป็นอิสระนี้เองที่ช่วยให้ Worker สามตัวสามารถแก้ไขโค้ดได้พร้อมกันโดยไม่เขียนทับกัน อ่านรายละเอียดเพิ่มเติมได้ที่ การรัน Agent คู่ขนานใน Worktree ที่แยกเป็นอิสระ

Verifiers ทำหน้าที่อะไร?

Verifier จะพยายามหาข้อผิดพลาดของความเปลี่ยนแปลงที่เกิดขึ้น Google ใช้คำว่า “Adversarial” (การตรวจสอบแบบจับผิด) ซึ่งตรงจุดมาก เพราะ Verifier จะรันชุดทดสอบ ตรวจดู diff เทียบกับโจทย์ที่ได้รับ และมองหาทางลัดที่ Worker อาจทำไว้ หาก Verifier เพียงแค่ตั้งคำถามว่า “เทสต์ผ่านหรือไม่?” ก็อาจพลาดไม่ทันสังเกตว่า Worker แอบแก้ชุดทดสอบเพื่อให้เทสต์ผ่าน

ทำไมจึงต้องใช้โมเดลราคาสูงสำหรับการวางแผนและตรวจสอบ

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

Planner เขียนคำอธิบายงานเพียงไม่กี่ร้อยบรรทัด ส่วน Verifier ก็เขียนเพียงผลการตัดสิน ทั้งคู่ไม่ได้สร้างผลลัพธ์ออกมามากนัก ดังนั้นการจ่ายราคาพรีเมียมต่อโทเค็นจึงคิดเป็นค่าใช้จ่ายรวมเพียงเล็กน้อย ในทางกลับกัน Worker เป็นฝ่ายผลิตโทเค็นส่วนใหญ่ การเลือกใช้โมเดลราคาประหยัดในจุดนี้จึงช่วยประหยัดค่าใช้จ่ายได้มากที่สุด

นอกจากนี้ ผลกระทบจากความผิดพลาดยังทวีคูณต่างกันด้วย หากวางแผนผิดพลาด Worker ทุกตัวก็จะหลงทางกันหมด และหาก Verifier ละเลย โค้ดที่มีปัญหาก็จะหลุดผ่านไปทั้งหมด แต่หาก Worker ที่ความสามารถน้อยทำ diff ออกมาไม่ดี Verifier ก็ยังคอยตรวจจับได้อยู่ จงลงทุนกับการตัดสินใจในจุดที่ความผิดพลาดสามารถส่งผลกระทบลุกลามได้

การวางตำแหน่งผลิตภัณฑ์ของ Google เองก็สนับสนุนการแบ่งหน้าที่แบบนี้ โดยระบุว่า Gemini 4 Argon “ยังคงเป็นตัวเลือกที่เหมาะสมที่สุดสำหรับงานวิศวกรรมซอฟต์แวร์และงานด้านองค์ความรู้ส่วนใหญ่” ในขณะที่ Carbon จะใช้โทเค็นมากขึ้น “เพื่อสำรวจอย่างละเอียดถี่ถ้วน ให้เหตุผลเชิงลึก และรันลูปการตรวจสอบที่ครอบคลุม” Carbon มีราคาอยู่ที่ 2 ดอลลาร์ต่อ 1 ล้าน Input Token และ 10 ดอลลาร์ต่อ 1 ล้าน Output Token จนถึงวันที่ 30 พฤศจิกายน 2026 จากนั้นจะปรับเป็น 4 ดอลลาร์และ 20 ดอลลาร์ สำหรับรายละเอียดโมเดล สามารถอ่านเพิ่มเติมได้ที่ Gemini 4 Carbon สำหรับ Coding Agent และ Gemini 4 Argon สำหรับ Coding Agent ทั้งนี้แนวคิดเดียวกันยังสามารถนำไปปรับใช้กับการจับคู่โมเดลอื่น ๆ ได้เช่นกัน ดูรายละเอียดได้ที่ การจัด Crew แบบผสมผสานโมเดลด้วย Worker ราคาประหยัดและ Reviewer ประสิทธิภาพสูง

จุดที่ AI Agent Swarm มักจะล้มเหลว

ความล้มเหลวส่วนใหญ่ของ Swarm เกิดจากช่องโหว่ 3 ประการ ได้แก่ สถานะที่ใช้ร่วมกัน (Shared state), การตรวจสอบที่หละหลวม และการไม่มีเพดานงบประมาณ

ทำไม Agent ถึงเขียนทับงานกันเอง?

Worker สองตัวเข้าไปแก้ไขไฟล์เดียวกันเพราะแผนงานไม่ได้ระบุข้อห้ามไว้ หากไม่มีพื้นที่ทำงานที่แยกเป็นอิสระ การเขียนไฟล์ครั้งหลังสุดจะชนะ และการเปลี่ยนแปลงที่ Worker ตัวแรกทำไว้ก็จะสูญหายไป แต่หากมีการแยกพื้นที่ทำงาน การเปลี่ยนแปลงของทั้งคู่จะคงอยู่จนถึงขั้นตอน Merge ซึ่งจะเกิด Conflict ขึ้น วิธีแก้ปัญหาต้องเริ่มตั้งแต่การวางแผน นั่นคือ กำหนดสิทธิ์ความเป็นเจ้าของไฟล์ในแต่ละ Task ให้ชัดเจน และจัดลำดับงานที่ต้องใช้ไฟล์ร่วมกันให้ทำต่อกันทีละขั้น

ทำไม Verifier ถึงอนุมัติผ่าน ๆ?

Verifier ที่อ่านเพียงสรุปของ Worker แทนที่จะดู diff จริง ก็เปรียบเสมือนการตรวจให้คะแนนคำกล่าวอ้าง ไม่ใช่เนื้องานจริง เมื่อเห็นข้อความว่า “ทุกเทสต์ผ่านแล้ว” ก็กดอนุมัติทันที สิ่งที่ควรทำคือส่ง raw diff และผลลัพธ์ของเทสต์จริงให้ Verifier ตรวจสอบเสมอ และอย่าใช้รายงานสรุปจาก Worker เด็ดขาด นอกจากนี้ ควรให้ Verifier ทำงานบนโมเดลคนละตัวกับ Worker เพื่อจะได้ไม่เกิดจุดบอดเดียวกัน บทความ AI Code Review Agent: สิ่งที่ตรวจสอบได้และตรวจสอบไม่ได้ มีคำอธิบายว่า Agent ผู้ตรวจสอบสามารถและไม่สามารถยืนยันสิ่งใดได้บ้าง

ต้นทุนของ Swarm บานปลายได้อย่างไร?

ทุกครั้งที่งานถูกปฏิเสธ จะกระตุ้นให้เกิดการเขียนโค้ดซ้ำและการตรวจสอบใหม่อีกครั้ง ดังนั้นงานที่ไม่ผ่าน 3 ครั้งจะเสียค่าใช้จ่ายเทียบเท่ากับการทำ 4 รอบ หากมี Worker 10 ตัวติดอยู่ในลูปปฏิเสธงานข้ามคืน ก็อาจผลาญงบประมาณของทั้งสัปดาห์จนหมดได้ ควรจำกัดจำนวนการลองใหม่ (Retry) ต่อ Task (ค่าเริ่มต้นที่เหมาะสมคือ 2 ครั้ง), จำกัดจำนวน Worker ที่ทำงานพร้อมกัน และส่งต่องานให้มนุษย์เข้ามาดูทันทีที่การลองใหม่ครั้งสุดท้ายล้มเหลว

นอกจากนี้ยังมีจุดล้มเหลวประการที่สี่ซ่อนอยู่เบื้องหลัง นั่นคือ หากแผนงาน การรันงาน และผลการตัดสินทั้งหมดรวมกันอยู่ใน Context Window เดียวกัน จะไม่มีใครสามารถตรวจสอบย้อนหลังได้เลย ดังนั้นจึงต้องมี บุคคลจากภายนอก Swarm คอยเฝ้าสังเกตการณ์อยู่เสมอ

วิธีรัน AI Agent Swarm บนบอร์ดที่ใช้ร่วมกัน

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

1. สร้าง Parent Task หนึ่งงานสำหรับเป้าหมายหลัก Planner จะอ่านงานนี้แล้วเขียนแผนออกมาเป็น Subtasks โดยแต่ละงานจะระบุไฟล์ที่เกี่ยวข้องและการทดสอบเพื่อยอมรับงาน
2. มอบหมายให้ Worker แต่ละตัวทำเพียงหนึ่งงานเท่านั้น หนึ่งงาน ต่อหนึ่ง Agent ต่อหนึ่ง Branch หากมีสอง Subtasks ที่ใช้ไฟล์ร่วมกัน ให้รวมเข้าด้วยกันก่อนเริ่มลงมือ
3. รันแต่ละงานในไดเรกทอรีของตัวเอง การใช้ Worktree แยกกันต่อหนึ่งการรันจะช่วยแยกการแก้ไขโค้ดที่ทำพร้อมกันไม่ให้ปะปนกัน
4. เพิ่มสถานะ Review ก่อนถึง Done ห้ามย้ายงานใดไปยังสถานะ Done เพียงเพราะ Worker บอกว่าเสร็จแล้ว
5. มอบหมายงานตรวจสอบให้ Verifier Agent ที่ใช้โมเดลประสิทธิภาพสูงกว่า ตัว Agent จะอ่าน diff และผลลัพธ์ของเทสต์ จากนั้นจึงอนุมัติงานหรือส่งกลับไปแก้ไขพร้อมระบุเหตุผล
6. ให้มนุษย์อยู่ในขั้นตอนสุดท้ายเสมอ Verifier ช่วยกรองและคัดสรรรายการงานให้สั้นลง แต่มนุษย์คือผู้ตัดสินใจยอมรับผลลัพธ์ขั้นสุดท้าย

นี่คือวิธีการนำไปปรับใช้บน Sharkly: Crew คือกลุ่มของบุคลากรและ Agent ที่นำกลับมาใช้ซ้ำได้ ซึ่งประสานงานโดย Agent ที่เป็นหัวหน้าทีม เมื่อมอบหมาย Parent Task ให้กับ Crew ตัวหัวหน้าจะเริ่มทำงานก่อนเป็นลำดับแรก โดยจะอ่าน Task จากนั้นจึงดึง Agent สมาชิกมารับผิดชอบงานเฉพาะส่วน และนำผลลัพธ์มารวมกัน ลำดับการทำงานที่ให้หัวหน้าเริ่มก่อนนี้ช่วยรับประกันว่าจะไม่มี Worker คนใดเริ่มทำงานก่อนที่แผนงานจะถูกสร้างขึ้น

Agent ที่อยู่ในโหมด Working-directory ชั่วคราว จะได้รับไดเรกทอรีแยกอิสระสำหรับแต่ละ Task และการรันงานที่ผูกกับ Repository สามารถจัดเตรียม Worktree ใหม่ได้เสมอ ทำให้ Worker ที่ทำงานคู่ขนานกันไม่ใช้ไฟล์ร่วมกัน ทั้งนี้ Agent แต่ละตัวจะทำงานบน Runtime ตามที่คุณกำหนดค่าไว้ ซึ่งช่วยให้หัวหน้าทีมและ Reviewer สามารถใช้โมเดลที่ทรงพลังกว่า Worker ได้อย่างลงตัว

Review Gate เป็นสถานะหนึ่งในกระบวนการทำงานของ Task โดย Agent สามารถปล่อย Task ให้อยู่ในสถานะรอการตรวจสอบจากมนุษย์ได้ และการส่งต่องานนี้จะแสดงขึ้นในโมดูล Task Chats บนแถบด้านข้างหลัก ดังที่มีระบุไว้ในเอกสารการทำงานของ Agent ส่วนการรันงานที่ล้มเหลวหรือติดขัดจะยังคงส่งตรงไปยัง Inbox ทั้งนี้ Agent มีหน้าที่ค้นคว้า ลงมือทำ ทดสอบ และรายงานผล ส่วนมนุษย์มีหน้าที่กำหนดทิศทาง มอบหมายอำนาจ และตรวจรับผลลัพธ์ คุณสามารถเริ่มต้นใช้งาน Sharkly ได้ฟรี เพียงเชื่อมต่อ Computer หนึ่งเครื่อง สร้าง Agent สองตัว แล้วลองมอบหมายงานเล็ก ๆ ให้ Crew จัดการ อ่านรายละเอียดเพิ่มเติมเกี่ยวกับบทบาทของมนุษย์ได้ที่ การออกแบบขั้นตอนการ Review สำหรับ Agent ที่ทำงานคู่ขนาน

เมื่อใดที่คุณไม่จำเป็นต้องใช้ AI Agent Swarm

คุณสามารถข้ามการใช้ Swarm ไปได้เลยเมื่องานไม่สามารถแยกส่วนได้ การแก้ไขบั๊กจุดเดียว การรีแฟกเตอร์ไฟล์เดียว หรือการคิดวิเคราะห์ต่อเนื่องยาว ๆ จะทำงานได้เร็วกว่าเมื่อใช้ Agent ตัวเก่งเพียงตัวเดียวคู่กับ Reviewer หนึ่งคน หากมีงานอิสระน้อยกว่า 3 งาน ต้นทุนในการประสานงานมักจะสูงเกินกว่าประโยชน์ที่ได้จากการทำงานแบบคู่ขนาน

ควรเลือกใช้ Swarm เมื่องานสามารถแบ่งออกเป็นส่วนย่อยที่แก้ไขไฟล์คนละไฟล์กัน เช่น การไมเกรตหลายแพ็กเกจ, การเขียนแบบทดสอบย้อนหลังครอบคลุมหลายโมดูล หรือการแก้ไข API จุดเดียวที่ส่งผลกระทบต่อสิบเซอร์วิส ทั้งนี้ Google ได้ยกตัวอย่าง “การไมเกรตหลายแพ็กเกจ” และ “การสืบหาต้นตอของปัญหาข้ามระบบย่อย” ว่าเป็นงานที่ Carbon จัดการได้เป็นอย่างดีในการทำงานแบบ Multi-agent

บทสรุป

AI Agent Swarm คือการแบ่งงานออกเป็น 3 หน้าที่ ไม่ใช่การเขียนพรอมต์ยาวเหยียดเพียงข้อความเดียว นั่นคือ วางแผน สร้าง และตรวจสอบ จงใช้โมเดลที่ดีที่สุดของคุณไปกับการวางแผนและการตัดสิน ใช้โมเดลราคาประหยัดในการสร้าง และเก็บบันทึกทุกผลลัพธ์ไว้ในที่ที่มนุษย์สามารถเข้าไปอ่านและตรวจสอบได้ เริ่มต้นด้วย Parent Task หนึ่งงาน, Worker สามตัว และ Verifier หนึ่งตัว หากต้องการจัดโครงสร้างแบบนี้ด้วย Agent ที่คุณมีอยู่แล้ว เพียงเชื่อมต่อ Computer เข้ากับ Sharkly แล้วมอบหมายงานให้ Crew แรกของคุณได้เลย

คำถามที่พบบ่อย (FAQ)

Agent Swarm แตกต่างจาก Multi-agent Orchestration อย่างไร?

Orchestration คือแนวปฏิบัติทั่วไปในการประสานงานระหว่าง Agent หลายตัว ส่วน Swarm คือรูปแบบหนึ่งของ Orchestration ที่มีการกำหนดบทบาทตายตัว ได้แก่ Planner, Workers ที่ทำงานคู่ขนาน และ Verifiers ดังนั้น Swarm ทุกตัวจึงถือเป็น Orchestration แต่ไม่ใช่ Orchestration ทุกแบบที่จะเป็น Swarm

AI Agent Swarm ควรมี Agent กี่ตัว?

เริ่มต้นด้วย Planner 1 ตัว, Workers 3 ตัว และ Verifier 1 ตัว และค่อยเพิ่มจำนวน Workers เมื่อแต่ละงานยังคงเป็นอิสระต่อกันและคิวการตรวจสอบยังรองรับไหว เพราะการมี Worker มากเกินกว่ากำลังในการตรวจสอบผลลัพธ์ จะทำให้ปัญหาคอขวดย้ายไปตกอยู่ที่ Verifier เท่านั้น

Planner และ Verifier สามารถเป็น Agent ตัวเดียวกันได้หรือไม่?

ทั้งคู่สามารถใช้โมเดลประเภทเดียวกันได้ แต่ควรแยกการรันและแยก Context ออกจากกันโดยเด็ดขาด เพราะหาก Planner มาตรวจสอบผลลัพธ์จากแผนงานที่ตัวเองสร้างขึ้น มักจะมีแนวโน้มที่จะอนุมัติผ่านได้ง่าย การใช้ Verifier ที่มี Context สดใหม่จะช่วยให้อ่าน diff ได้โดยไม่มีสมมติฐานหรืออคติเดิมของ Planner

จำเป็นต้องมี Google Antigravity เพื่อรัน Agent Swarm หรือไม่?

ไม่จำเป็นเลย แม้ว่า /swarm จะเป็นฟีเจอร์พรีวิวภายใน Antigravity แต่โดยแก่นแท้ของรูปแบบนี้ต้องการเพียงการแบ่งงานย่อย, พื้นที่ทำงานที่แยกเป็นอิสระ และขั้นตอนการตรวจสอบเท่านั้น คุณสามารถสร้างระบบนี้ขึ้นมาได้เองด้วย git worktree และบอร์ดบริหารจัดการงาน โดยเลือกใช้ Coding Agent ใด ๆ ที่คุณใช้งานอยู่แล้วได้เลย

อะไรคือสิ่งป้องกันไม่ให้ Worker ใน Swarm แก้ไขไฟล์เดียวกัน?

การวางแผนงานจะกำหนดความเป็นเจ้าของไฟล์เพื่อไม่ให้งานซ้อนทับกัน และพื้นที่ทำงานที่แยกเป็นอิสระจะช่วยเก็บการแก้ไขของ Worker แต่ละตัวไว้ใน Branch ของตัวเองจนกว่าจะถึงขั้นตอน Merge นอกจากนี้ กฎ CODEOWNERS ยังช่วยเพิ่มการตรวจสอบอีกชั้นหนึ่งในระหว่างขั้นตอนการ Review