หนึ่งเซสชันของ Gemini CLI คือเอเจนต์หนึ่งตัวที่ทำงานอยู่ในไดเรกทอรีเดียว พอคุณอยากให้มีงานที่สองเดินไปพร้อมกัน ไม่ว่าจะเป็นการแก้บั๊กขณะที่ refactor กำลังรัน หรือการเขียนเทสขณะที่ฟีเจอร์กำลังขึ้น คุณก็เปิดเทอร์มินัลอีกหน้าต่าง จากนั้นก็หน้าต่างที่สาม ภายในหนึ่งชั่วโมงคุณจะมีสี่แท็บ สี่ไดเรกทอรีทำงาน และไม่มีคำตอบที่ชัดเจนสำหรับคำถามง่ายๆ ข้อเดียวว่า เอเจนต์ตัวไหนกำลังทำอะไร และตัวไหนเพิ่งแตะไฟล์ที่คุณกำลังจะแก้
การรันงาน Gemini หลายงานพร้อมกันไม่ใช่เรื่องยากที่จะเริ่ม แต่ยากที่จะคุมให้เป็นระเบียบ แต่ละอินสแตนซ์เร็วในตัวเอง สิ่งที่ต้องแลกมาคือการประสานงาน และการประสานงานก็คือส่วนที่เทอร์มินัลไม่เคยให้คุณได้
บทความนี้จะพาไปดูการตั้งค่าแบบแมนนวลสำหรับเอเจนต์ Gemini CLI แบบขนาน ระบุโหมดความล้มเหลวที่รออยู่ในแต่ละขั้นตอน และชี้ให้เห็นว่าบอร์ดงานเข้ามารับช่วงตรงไหน บอร์ดงานนั้นคือ Sharkly แพลตฟอร์มสั่งการและจัดการเอเจนต์แบบครบวงจร Sharkly ไม่ได้มาแทน Gemini CLI แต่เพิ่มชั้นของงานที่แชร์ร่วมกัน, Computer, บริบท และการรีวิว ไว้รอบๆ รันไทม์ที่ทีมคุณใช้อยู่แล้ว เพื่อให้การรันแบบขนานยังมอบหมายและตรวจสอบย้อนหลังได้ แทนที่จะกระจัดกระจายไปตามแท็บต่างๆ
“เอเจนต์แบบขนาน” หมายถึงอะไรใน Gemini CLI
Gemini CLI รันเอเจนต์หนึ่งตัวต่อหนึ่งโปรเซส มันอ่านไดเรกทอรีปัจจุบัน โหลดไฟล์บริบท GEMINI.md ถ้ามี และทำงานตามพรอมป์ของคุณในเวิร์กทรีเดียวนั้น ไม่มีตัวกระจายงานในตัวที่คอยแยกเป้าหมายออกไปยังเอเจนต์ย่อยหลายตัวแล้วรวมงานกลับมาให้คุณ
ดังนั้น “เอเจนต์ Gemini แบบขนาน” ในทางปฏิบัติจึงหมายถึงสิ่งเดียว: โปรเซส gemini หลายตัวรันพร้อมกัน แต่ละตัวอยู่ในสภาพแวดล้อมที่แยกจากกัน แต่ละตัวทำงานของตัวเอง Gemini CLI เป็นโอเพนซอร์สและรันฟรีกับบัญชี Google ส่วนตัว ซึ่งก็คือเหตุผลที่คนเปิดพร้อมกันสี่ตัวพอดี อุปสรรคไม่เคยอยู่ที่การเริ่มรัน แต่อยู่ที่การทำให้งานอิสระสี่งานไม่ชนกันในรีโพซิทอรีเดียวกัน และการรู้ว่าอีกหนึ่งชั่วโมงต่อมาแต่ละตัวสร้างอะไรออกมา
นี่คือปัญหาเรื่องการประสานงานแบบเดียวกับที่คุณเจอใน Claude Code หรือ Codex รันไทม์เปลี่ยน แต่ความวุ่นวายไม่เปลี่ยน
การตั้งค่าแบบแมนนวล ทีละขั้นตอน
นี่คือเวอร์ชันที่เล็กที่สุดที่ใช้งานได้ของ Gemini CLI แบบขนาน พร้อมสิ่งที่พังในแต่ละขั้นตอน
ขั้นที่ 1: ให้เอเจนต์แต่ละตัวมีเวิร์กทรีของตัวเอง อย่ารันเอเจนต์สองตัวในโฟลเดอร์เดียวกัน ให้ใช้ git worktree ต่อหนึ่งงาน เพื่อให้แต่ละเช็กเอาต์แยกออกจากกันจริงๆ:
git worktree add ../repo-auth feature/auth
git worktree add ../repo-tests chore/tests
git worktree add ../repo-bugfix fix/login-redirect
โหมดความล้มเหลวถ้าไม่ทำ: เอเจนต์สองตัวที่แก้ไขเช็กเอาต์เดียวกันจะเขียนทับกันกลางทาง ตัวหนึ่งจัดรูปแบบไฟล์ใหม่ขณะที่อีกตัวแก้ไปได้ครึ่งทาง และทั้งคู่ก็ทิ้งทรีไว้ในสภาพที่ไม่มีใครตั้งใจ worktree ให้เอเจนต์แต่ละตัวมีแบรนช์สะอาดและไดเรกทอรีสะอาด เราลงลึกเรื่องนี้ใน git worktrees สำหรับเอเจนต์เขียนโค้ด AI
ขั้นที่ 2: เปิด Gemini CLI หนึ่งตัวต่อหนึ่งเวิร์กทรี เปิดเทอร์มินัลในแต่ละไดเรกทอรีแล้วเริ่มเซสชัน:
cd ../repo-auth && gemini
สำหรับการรันแบบไม่มีคนเฝ้า ให้ใช้โหมด non-interactive เพื่อให้เอเจนต์รับพรอมป์เดียวแล้วออก:
cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."
โหมดความล้มเหลว: เซสชันแบบอินเทอร์แอกทีฟจะหยุดที่พรอมป์ขออนุญาตอันแรกแล้วรออยู่ตรงนั้น คุณกลับมาอีกยี่สิบนาทีต่อมาก็พบเอเจนต์ที่ไม่ได้ทำอะไรเลยเพราะมันต้องการคำตอบว่าใช่ ตัดสินใจตั้งแต่ต้นว่าการรันใดเป็นแบบอินเทอร์แอกทีฟและอันใดเป็นแบบ headless และให้ตัว headless มีพรอมป์ที่รวมขั้นตอนตรวจสอบของตัวเองไว้ด้วย
ขั้นที่ 3: แยกบริบทตามแต่ละงาน แต่ละเวิร์กทรีสามารถมี GEMINI.md ของตัวเองพร้อมกฎสำหรับงานนั้น: แตะอะไรได้ ปล่อยอะไรไว้ และรันเทสอย่างไร
โหมดความล้มเหลว: ไฟล์บริบทไฟล์เดียวที่ใช้ร่วมกันทุกเอเจนต์หมายความว่าคำสั่งที่ตั้งใจไว้สำหรับงาน auth จะรั่วไปสู่งานเทส ให้กำหนดขอบเขตบริบทให้ตรงกับทรีที่เป็นของมัน
ขั้นที่ 4: จับตาโควตา ทุกอินสแตนซ์ที่รันอยู่ดึงจากขีดจำกัดบัญชีเดียวกัน เอเจนต์สี่ตัวที่เผาโควตากับการ refactor ครั้งใหญ่จะชนลิมิตเรตเร็วกว่าตัวเดียว และเอเจนต์ที่ถูกจำกัดจะล้มเหลวเงียบๆ ในแท็บที่คุณไม่ได้มอง
โหมดความล้มเหลว: การรันค้างอยู่ที่ข้อผิดพลาดเรื่องโควตาและคุณไม่ทันสังเกตจนกว่าจะไปเช็กแท็บนั้น ไม่มีมุมมองร่วมที่บอกคุณว่าเอเจนต์หยุดไปแล้ว ถ้าคุณกำลังจับงานที่หนักกว่าเข้ากับโมเดลที่เหมาะ โมเดลไหนเหมาะกับงานเขียนโค้ดแบบไหน ครอบคลุมการแลกเปลี่ยนตรงนี้ไว้แล้ว
ที่สามหรือสี่งาน วิธีนี้ใช้ได้ แบรนช์จริง การแยกจริง ความขนานจริง ไม่ต้องใช้เครื่องมือเพิ่ม
จุดที่การตั้งค่าแบบทำเองไปต่อไม่ไหว
การตั้งค่าแบบแมนนวลไม่ได้พังที่การรัน แต่พังที่ทุกอย่างรอบๆ มัน ดูว่าอะไรเกิดขึ้นเมื่อจำนวนงานไต่สูงขึ้น
คุณหลุดแผนที่ ในสี่เทอร์มินัลคุณยังจำได้หมด แต่พอแปดตัวกระจายอยู่สองรีโพซิทอรี คุณจำไม่ไหว แท็บไหนคือเอเจนต์ auth งานเทสรันเสร็จหรือตายเพราะโควตา การมอนิเตอร์เอเจนต์เขียนโค้ดที่รันขนานกัน เป็นงานที่เทอร์มินัลไม่เคยถูกออกแบบมาให้ทำ
ผลลัพธ์กระจัดกระจาย เอเจนต์แต่ละตัวทิ้งงานไว้เป็น diff บนแบรนช์และสกรอลล์แบ็กกองโตในแท็บที่คุณกำลังจะปิด ไม่มีบันทึกที่แชร์กันว่าการรันแต่ละครั้งเปลี่ยนอะไร เพราะอะไร หรือผ่านเทสของตัวเองหรือเปล่า เมื่อเพื่อนร่วมทีมถามว่าการแก้ล็อกอินทำอะไรไปบ้าง คำตอบก็อยู่ในเทอร์มินัลที่ไม่มีอยู่แล้ว
การรีวิวไม่มีที่อยู่ เอเจนต์แบบขนานสร้าง diff แบบขนาน และทุกอันยังต้องมีคนกดยอมรับ อ่านสี่แบรนช์โดยไม่มีสรุป ไม่มีผลการตรวจสอบ และไม่มีบริบท ช้ากว่าที่เอเจนต์จะเร็วเสียอีก ความเร็วที่ได้มาจากการรัน คุณต้องคืนไปตอนรีวิว
นี่คือคู่ตัดสินใจแบบตรงไปตรงมา ถ้าคุณรันงาน Gemini สามหรือสี่งานนานๆ ครั้ง ก็ใช้วิธีตั้งค่า worktree ข้างบนต่อไป มันง่ายและได้ผล และบอร์ดงานจะเป็นภาระที่คุณยังไม่จำเป็นต้องมี ให้หยิบมันมาใช้เมื่อการรันแบบขนานกลายเป็นเรื่องปกติ: เอเจนต์หลายตัว มากกว่าหนึ่งรีโพซิทอรี มากกว่าหนึ่งคนที่ต้องเห็นความคืบหน้า และการรีวิวที่ต้องตรวจสอบย้อนหลังได้ ไม่ใช่แค่จำเอา การเปรียบเทียบเครื่องมือที่ใช้จัดการเอเจนต์ขนาน คุ้มค่าที่จะทำตอนนั้น
บอร์ดงานเข้ามาเติมอะไร
บอร์ดงานเปลี่ยนหน่วยของงานจาก “แท็บเทอร์มินัล” เป็น “Task” การเปลี่ยนแค่จุดเดียวนี้คือสิ่งที่การตั้งค่าแบบทำเองขาดไป
กับ Sharkly คุณมอบหมาย Task ให้กับ Agent ที่ขับเคลื่อนด้วย Gemini CLI ตัว Agent จะรับงานนั้น ทำในเวิร์กทรีที่แยกออกมา และการรัน อุปสรรค ผลลัพธ์ และการพูดคุยต่อยอดจะกลับสู่ไทม์ไลน์ของ Task แทนที่จะหายไปในเทอร์มินัลส่วนตัว รันหลายงานพร้อมกันแล้วแต่ละงานคือแถวที่คุณมองเห็น ไม่ใช่แท็บที่คุณต้องไปตามหา Gemini CLI ยังเขียนโค้ดเหมือนเดิม ส่วน Sharkly ดูแลการมอบหมาย, Computers ที่เชื่อมต่อ, บริบท และการรีวิวของทุกการรัน
การแบ่งงานยังชัดเจน เอเจนต์ค้นคว้า ลงมือทำ เทส และรายงาน คนกำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้ดุลยพินิจของทีม และการรันแต่ละครั้งกลับมาพร้อมสรุปการเปลี่ยนแปลงและผลการตรวจสอบของตัวเอง การจะกดยอมรับหรือปฏิเสธ diff จึงแค่มองแวบเดียว ไม่ต้องขุดคุ้ยแบบนักโบราณคดี บริบท ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยคน ยังมองเห็นได้ตั้งแต่คำขอจนถึงการปล่อย
คุณเก็บสิ่งที่คุณมีอยู่แล้วไว้ได้ Sharkly ไม่ได้ขอให้คุณทิ้ง Gemini CLI หรือผูกติดกับรันไทม์ใดรันไทม์หนึ่ง เพราะมันเป็นกลางต่อผู้ให้บริการ บอร์ดงานเดียวกันจึงรันเอเจนต์ Claude Code และ Codex ควบคู่ไปกับ Gemini ของคุณได้ เวิร์กโฟลว์ของคุณจึงอยู่รอดไม่ว่าตัวต่อไปที่ดีที่สุดจะกลายเป็นใคร ความเป็นกลางนั้นคือประเด็นสำคัญ: คุณกำลังจัดการเอเจนต์ของคุณในที่เดียว ไม่ต้องสลับระบบนิเวศทุกครั้งที่มีตัวใหม่เปิดตัว
เช็กลิสต์ที่เริ่มใช้ได้วันนี้
ลองทำตามนี้ก่อนเริ่มงาน Gemini แบบขนานชุดถัดไป:
- [ ] หนึ่ง git worktree ต่อหนึ่งงาน; อย่าเอาเอเจนต์สองตัวไว้ในเช็กเอาต์เดียว
- [ ]
GEMINI.mdที่กำหนดขอบเขตตามแต่ละงาน ไม่ใช่ไฟล์เดียวที่ใช้ร่วมกันทั้งหมด - [ ] การรันแบบ headless ใช้
gemini -pพร้อมขั้นตอนตรวจสอบในตัว เพื่อไม่ให้ค้างอยู่ที่พรอมป์ - [ ] เพดานที่รู้ชัดของจำนวนอินสแตนซ์ที่รันพร้อมกัน เพื่อไม่ให้โควตาที่แชร์กันไปจำกัดการรันที่คุณมองไม่เห็น
- [ ] ที่เดียวที่ตอบได้ว่า “เอเจนต์ตัวไหนทำงานอะไร และอันไหนเสร็จแล้ว” โดยไม่ต้องเปิดทุกแท็บ
- [ ] ทุกการรันที่เสร็จแล้วทิ้งสรุปการเปลี่ยนแปลงและผลเทสที่คนรีวิวได้ ไม่ใช่แค่ diff บนแบรนช์
สี่ข้อแรกคุณทำได้ด้วย worktree และเทอร์มินัลคืนนี้เลย สองข้อหลังคือจุดที่การตั้งค่าแบบแมนนวลไปไม่ไหว ถ้าคุณรันเอเจนต์ Gemini CLI หลายตัวพร้อมกันอยู่แล้ว Sharkly ให้ที่เดียวสำหรับมอบหมายงาน เฝ้าดูความคืบหน้า และรีวิวผลลัพธ์ คุณจะสร้างชั้นการประสานงานขึ้นเองก็ได้ หรือจะ รันเอเจนต์เขียนโค้ดที่คุณมีอยู่ผ่าน Sharkly แล้วข้ามไปยังส่วนที่ขยายได้เลยก็ได้
