การรัน Codex เอเจนต์ตัวเดียวนั้นง่ายมาก คุณเปิดเทอร์มินัล อธิบายงาน แล้วนั่งดูมันทำงาน ปัญหาจะเริ่มตอนมีสามตัว ตัวหนึ่งกำลังรีแฟกเตอร์โมดูล auth อีกตัวกำลังแก้เทสต์ที่รันไม่ผ่านบ้างผ่านบ้าง ตัวที่สามกำลังร่าง migration และแต่ละตัวก็อยู่ในแท็บเทอร์มินัลของตัวเองพร้อม scrollback ของตัวเอง สิบนาทีต่อมา คุณจำไม่ได้แล้วว่าแท็บไหนคืองานอะไร migration เสร็จหรือยัง หรือการแก้เทสต์ไปลงที่ branch ไหน ตัวเอเจนต์ไม่ได้มีปัญหา ความสามารถของคุณในการติดตามต่างหากที่พัง
นี่คือปัญหาจริงที่ซ่อนอยู่เบื้องหลัง "การจัดการ Codex เอเจนต์หลายตัว" มันไม่ใช่เรื่อง concurrency เพราะ Codex รันขนานกันได้สบาย ๆ ในไดเรกทอรีทำงานที่แยกจากกัน ปัญหาคือ สถานะ ของงานนั้น ไม่ว่าแต่ละเอเจนต์กำลังทำอะไร อะไรเสร็จแล้ว อะไรล้มเหลว และอะไรที่รอให้คุณรีวิว กลับกระจัดกระจายไปตามแท็บเทอร์มินัล โฟลเดอร์ worktree และความจำของคุณเอง พลาดอย่างใดอย่างหนึ่งไปก็เท่ากับหลุดประเด็น
Sharkly ถือกำเนิดขึ้นมาเพื่ออุดช่องว่างนี้โดยเฉพาะ คุณมี coding agent อยู่แล้ว Sharkly เปลี่ยนพวกมันให้กลายเป็นทีม ด้วยการมอบบันทึกที่ใช้ร่วมกันหนึ่งชุดให้กับการรันของทุกเอเจนต์ บทความนี้จะพาคุณผ่านการตั้งค่าด้วยมือก่อน เพราะคุณควรเข้าใจว่ากำลังจะไป automate อะไร แล้วจึงแสดงให้เห็นว่าบอร์ดงาน (task board) เข้ามามีบทบาทตรงไหน ปิดท้ายด้วยเช็กลิสต์ที่คุณนำไปใช้ได้ตั้งแต่วันนี้
“หลุดการติดตาม” จริง ๆ แล้วหมายถึงอะไร
การหลุดการติดตามไม่ใช่เรื่องคลุมเครือ แต่มันคือความล้มเหลวที่เจาะจงชัดเจน นั่นคือ สถานะงานของคุณไม่มีบ้านหลังเดียว เมื่อคุณรันเซสชัน Codex หลายตัวด้วยมือ ความจริงเกี่ยวกับแต่ละงานจะถูกแยกออกเป็นสี่ที่พร้อมกัน คำสั่งอยู่ในเทอร์มินัลที่คุณพิมพ์มันลงไป การเปลี่ยนแปลงอยู่ใน Git working directory สถานะอยู่ในหัวของคุณ และผลลัพธ์อยู่ใน pull request ที่คุณยังไม่ได้เปิด ไม่มีอะไรคอยทำให้สี่อย่างนี้ตรงกัน ปิดเทอร์มินัลแล้วคำสั่งก็หายไป สลับแท็บแล้วสถานะก็กลายเป็นการเดา ยิ่งเพิ่มเอเจนต์มากเท่าไร คุณก็ยิ่งต้องดูแลสำเนาของ "เกิดอะไรขึ้น" มากขึ้นเท่านั้น และคุณคือจุดเชื่อมต่อเดียวที่ยึดทุกอย่างไว้ด้วยกัน
ดังนั้นเป้าหมายของการจัดการ Codex เอเจนต์หลายตัวจึงแคบและควรพูดให้ตรง ๆ: เก็บงาน ความคืบหน้า การเปลี่ยนแปลง และสถานะการรีวิวของทุกเอเจนต์ไว้ในที่เดียว แทนที่จะแยกมันไปตามเซสชันเทอร์มินัลส่วนตัว ทุกอย่างข้างล่างนี้จะถูกตัดสินด้วยบททดสอบเดียวนี้
ขั้นตอนที่ 1: แยกเอเจนต์แต่ละตัวด้วย worktree
โหมดความล้มเหลวแรกคือการชนกัน ถ้าคุณชี้ Codex สองตัวไปที่โฟลเดอร์เดียวกัน พวกมันจะเขียนทับการแก้ไขของกันและกัน stage ไฟล์ของกันและกัน และได้ diff ที่ไม่มีใครอ่านออก Git worktrees แก้ปัญหานี้ได้อย่างสะอาด ด้วยการให้เอเจนต์แต่ละตัวมี checkout ของรีโปเดียวกันเป็นของตัวเอง บน branch ของตัวเอง
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
จากนั้นเริ่มเซสชัน Codex หนึ่งเซสชันในแต่ละไดเรกทอรี เอเจนต์แต่ละตัวจะเห็นแค่ไฟล์ของตัวเอง commit ลง branch ของตัวเอง และเหยียบงานของตัวอื่นไม่ได้
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
โหมดความล้มเหลวที่ต้องพูดถึงตรงนี้: worktree แก้ปัญหาการชนกันของไฟล์ แต่ไม่ช่วยเรื่องการติดตาม ตอนนี้คุณมีสามโฟลเดอร์ที่ชื่อเกือบเหมือนกัน และไม่มีบันทึกว่าโฟลเดอร์ไหนคืองานอะไร ควรตั้งธรรมเนียมการตั้งชื่อที่บอกชื่องานไว้ในตัวมันเอง (agent/<task>) เพราะอีกหนึ่งสัปดาห์ชื่ออย่าง repo-2 กับ repo-3 จะไม่มีความหมายอะไรเลย ถ้าอยากเข้าใจกลไกให้ลึกกว่านี้ อ่านได้ที่ Git worktrees สำหรับ AI coding agent และแพตเทิร์นที่กว้างขึ้นใน การรันงาน Codex หลายงานพร้อมกัน
ขั้นตอนที่ 2: ทำให้เซสชันทั้งหมดอยู่ในสายตา
เอเจนต์สามตัวในสามแท็บ หมายความว่าคุณอยู่ห่างจากการกด Cmd+W พลาดเพียงครั้งเดียวจากการฆ่างานที่กำลังรันอยู่และสูญเสีย scrollback ของมันไป ตัวจัดการเทอร์มินัลอย่าง tmux ช่วยให้ทุกเซสชันยังมีชีวิตอยู่ในหน้าต่างที่มีชื่อ ซึ่งคุณสามารถ detach ออกไปแล้วค่อย reattach กลับมาได้ภายหลัง
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
หน้าต่างที่มีชื่อ (auth, flaky, migration) ช่วยกู้ป้ายชื่อที่แท็บธรรมดาทิ้งไปกลับคืนมา detach ด้วย Ctrl-b d ปิดแล็ปท็อป แล้ว reattach ในตอนเช้า เซสชันก็ยังอยู่ครบ
โหมดความล้มเหลวที่ต้องพูดถึงตรงนี้: tmux ทำให้เซสชันยังทำงานอยู่ แต่มันไม่ได้บอกคุณว่าตัวไหนต้องการคุณ เอเจนต์ที่เพิ่งเสร็จไปยี่สิบนาทีกับเอเจนต์ที่เจอ error มองจากภายนอกแล้วหน้าตาเหมือนกันเป๊ะ คือหน้าต่างที่เงียบ ๆ คุณยังต้องไล่เข้าไปดูทุกหน้าต่างและอ่านบรรทัดท้าย ๆ ร้อยบรรทัดเพื่อรู้สถานะของมัน ต้นทุนการ polling นี้เพิ่มขึ้นตามจำนวนเอเจนต์ที่คุณเพิ่ม และมันคือภาษีที่ทำให้การตั้งค่าด้วยมือรู้สึกหนักขึ้นเรื่อย ๆ ตามเวลา
ขั้นตอนที่ 3: บันทึกสถานะและการรีวิวไว้ในที่ที่คงทน
ชิ้นส่วนสุดท้ายของการทำด้วยมือคือสิ่งที่คนมักข้ามไป นั่นคือการเขียนลงไปว่าเอเจนต์แต่ละตัวสร้างอะไรขึ้นมา และคุณรับมันหรือยัง scrollback ไม่ใช่บันทึก มันหายไป มันค้นข้ามงานไม่ได้ และเพื่อนร่วมทีมก็อ่านมันไม่ได้ วิธีที่เบาที่สุดคือเช็กลิสต์ธรรมดาที่คุณอัปเดตด้วยมือ
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
นี่คืองานทั้งหมดในฉบับย่อ: พื้นที่ที่คงทนซึ่งความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์ยังมองเห็นได้ตั้งแต่ตอนสั่งงานจนถึงตอนปล่อยงาน ถ้าคุณดูแลมันอย่างซื่อสัตย์ คุณก็จัดการเอเจนต์หลายตัวจากเทอร์มินัลได้อีกนาน จุดที่ต้องระวังคือ คุณ นี่แหละที่เป็นตัวซิงก์ อัปเดตมันด้วยมือทุกครั้งที่มีอะไรเปลี่ยนแปลง หากอยากอ่านเรื่องการทำให้ผลงานของเอเจนต์ตรวจสอบย้อนหลังได้ อ่านต่อที่ วิธีติดตามงานที่ AI coding agent ทำเสร็จ
จุดที่การตั้งค่าแบบ DIY ไปต่อไม่ไหว
พูดกันตรง ๆ ว่าวิธีทำด้วยมือนั้นพอเพียงเมื่อไร สำหรับ Codex เอเจนต์หนึ่งหรือสองตัวที่งานมีขอบเขตชัดเจน worktree บวกธรรมเนียมการตั้งชื่อ บวกไฟล์สถานะที่เขียนด้วยมือ ถือว่าดีพอจริง ๆ ไม่ต้องเพิ่มเครื่องมือที่คุณไม่จำเป็นต้องใช้ เพราะชิ้นส่วนที่ต้องขยับแทบจะเป็นศูนย์ และทั้งหมดก็เก็บไว้ในหัวคุณได้
สมการจะเปลี่ยนไป ณ จุดหนึ่งที่คาดเดาได้ คุณจะรู้สึกได้เมื่อ:
- คุณรันเอเจนต์สามตัวหรือมากกว่า และต้นทุนการ polling (ไล่ดูทุกหน้าต่าง อ่านบรรทัดท้าย ๆ จำสถานะ) กินเวลามากกว่าที่เอเจนต์ช่วยประหยัดให้
- งานพาดผ่านมากกว่าหนึ่งรีโป จน worktree เพียงอย่างเดียวไม่พอจะให้ภาพรวมที่สะอาดอีกต่อไป
- มีคนอื่นถามว่า "ตอนนี้เอเจนต์กำลังทำอะไรอยู่" แล้วคำตอบที่ตรงไปตรงมาที่สุดกลับอยู่ในเทอร์มินัลและความจำของคุณเท่านั้น
ทุกข้อคือสาเหตุรากเดียวกันกับที่พูดไว้ตอนต้นบทความ นั่นคือ สถานะงานที่ไม่มีบ้านร่วมกัน การตั้งค่าด้วยมือเก็บมันไว้ในที่เดียวที่ไม่สเกล นั่นคือตัวคุณ ทีมต่าง ๆ ชนกำแพงนี้เร็วที่สุด ซึ่งเป็นเหตุผลที่เครื่องมือที่ดีที่สุดสำหรับจัดการ AI coding agent แบบขนานล้วน conver ไปที่ทางออกเดียวกัน คือมอบบ้านให้งาน ภายนอกเทอร์มินัล
บอร์ดงานเข้ามาเพิ่มอะไร
บอร์ดงานเปลี่ยนหน่วยของการจัดการจาก "เซสชันเทอร์มินัล" เป็น "Task" ใน Sharkly คุณเชื่อมต่อ Computer ที่คุณใช้รัน Codex อยู่แล้ว จากนั้นมอบหมาย Task ให้กับ Codex Agent แทนการพิมพ์ลงในหน้าต่าง เอเจนต์จะรันใน worktree ที่แยกออกมาเป็นของตัวเอง และการทำงาน ความคืบหน้า อุปสรรค รวมถึงผลลัพธ์จะกลับมาอยู่ที่ Task คุณเลิก polling ได้ เพราะบอร์ดรู้อยู่แล้วว่าอะไรเสร็จแล้วและอะไรล้มเหลว
การแบ่งหน้าที่นี้เป็นความตั้งใจ และควรพูดเป็นเส้นแบ่งให้ชัด: Sharkly ไม่ใช่ตัวแทนของ Codex Codex ทำงานรัน ส่วน Sharkly เพิ่มชั้นของ task ที่ใช้ร่วมกัน, Computer, บริบท และการรีวิวเข้าไปรอบ ๆ เอเจนต์จะค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนเป็นผู้กำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์ Automation จะหยุดตรงจุดที่ต้องใช้วิจารณญาณของคุณ ซึ่งก็คือด่านรีวิว ไม่ใช่ตัวโค้ด
นั่นคือสิ่งที่ไฟล์สถานะด้วยมือพยายามจะไปให้ถึง ทำให้มันคงทนและใช้ร่วมกันได้ มีสามอย่างที่เทอร์มินัลให้คุณไม่ได้ และบอร์ดให้ได้:
- สถานะโดยไม่ต้อง polling แต่ละ Task แสดงว่า running, done, blocked หรือ needs-review โดยที่คุณไม่ต้องไปไล่ดูหน้าต่าง
- ภาพรวมเดียวข้ามรีโป Task จากหลายรีโปและหลาย Agent รวมอยู่ใน Space เดียว เอเจนต์เพิ่มขึ้นจึงไม่หมายความว่าต้องมีเทอร์มินัลให้เฝ้าเพิ่มขึ้น นี่คือเหตุผลเดียวกับที่ทีมต่าง ๆ รัน Claude Code และ Codex ไปพร้อมกันจากที่เดียว
- ขั้นตอนรีวิวที่ยึดอยู่ ผลลัพธ์จะรออยู่ที่ด่าน human-in-the-loop พร้อมสรุปการเปลี่ยนแปลงและหลักฐานแนบมา จึงไม่มีอะไรถูก merge ไปเพียงเพราะคุณลืมว่ามันค้างอยู่
คุณสร้างทั้งหมดนี้ด้วยมือได้ด้วย worktree และวินัย หรือจะใช้ Sharkly จัดการเวิร์กโฟลว์เมื่อจำนวนเอเจนต์ไต่สูงขึ้น Codex ยังคงเป็นอย่างที่มันเป็นทุกประการ เพียงแต่ภาระการจัดการย้ายออกจากบ่าคุณ ถ้าตอนนี้คุณรัน Codex เอเจนต์หลายตัวอยู่แล้ว นั่นคือปัญหาที่ Sharkly ถูกออกแบบมาเพื่อรับมือ
เช็กลิสต์ที่คุณนำไปใช้ได้วันนี้
ไม่ว่าคุณจะยังทำด้วยมือหรือย้ายไปใช้บอร์ด นี่คือขั้นต่ำที่กันไม่ให้คุณหลุดการติดตาม:
- [ ] worktree แยกต่างหากหนึ่งอันต่อเอเจนต์ อยู่บน branch ที่ตั้งชื่อตามงาน ไม่มีเอเจนต์สองตัวในโฟลเดอร์เดียวเด็ดขาด
- [ ] ธรรมเนียมการตั้งชื่อที่บอกชื่องานไว้ในตัว เช่น
agent/auth-refactorดีกว่าrepo-3 - [ ] เซสชันที่อยู่ยาว (tmux หรือบอร์ด) ซึ่ง detach ออกไปแล้ว reattach กลับมาได้โดยไม่ฆ่างานทิ้ง
- [ ] บันทึกสถานะที่คงทนนอกเหนือจาก scrollback ของเทอร์มินัล: งาน, branch, สถานะ, สถานะการรีวิว
- [ ] ด่านรีวิวที่ชัดเจน ไม่มี branch ไหนถูก merge จนกว่ามนุษย์จะรับมัน
- [ ] เช็กจำนวน: เมื่อมีเอเจนต์สามตัวขึ้นไป หรือมีรีโปสองแห่งขึ้นไป ให้ย้ายสถานะออกจากหัวคุณ
ใช้วิธีทำด้วยมือไปเรื่อย ๆ จนกว่าภาษีการ polling จะเริ่มเจ็บ เมื่อถึงตอนนั้น รัน coding agent ที่คุณมีอยู่แล้วผ่าน Sharkly เพื่อให้การติดตามเป็นหน้าที่ของบอร์ด ไม่ใช่ของคุณ
คำถามที่พบบ่อย
จริง ๆ แล้วฉันรัน Codex เอเจนต์พร้อมกันได้กี่ตัว? เท่าที่เครื่องและ rate limit ของคุณจะไหลไหว แต่เพดานที่คุณจะชนก่อนมักเป็นเพดานของมนุษย์ ไม่ใช่ของเทคนิค การติดตามสามตัวขึ้นไปด้วยมือคือจุดที่คนส่วนใหญ่หลุดประเด็น ดูขีดจำกัดฝั่งการรันได้ที่ เธรดและ subagent แบบขนานของ Codex
บอร์ดงานมาแทน Codex หรือเปล่า? ไม่ Codex เป็นตัวรัน ส่วนบอร์ดจัดการการมอบหมาย การแยกสภาพแวดล้อม บริบท และการรีวิวรอบ ๆ มัน สองอย่างนี้เสริมกัน
