Codex Parallel Agents: วิธีรันงาน Codex หลายงานพร้อมกัน

คุณมีงาน Codex รันอยู่หนึ่งงาน, บั๊กที่แก้เสร็จแล้วรอส่งต่อ, ชุดทดสอบที่ยังขาด coverage และ refactor ที่คุณผัดผ่อนมาเรื่อย ๆ ทั้งสี่อย่างนี้เป็นงานอิสระต่อกัน ไม่มีเหตุผลใดที่มันจะรันพร้อมกันไม่ได้เลย ยกเว้นเหตุผลในทางปฏิบัติข้อเดียว คือถ้าคุณชี้ Codex สองเซสชันไปที่ checkout เดียวกัน มันจะเริ่มเขียนทับการแก้ไขของกันและกัน ความขนานที่คุณต้องการก็กลายเป็น merge ที่คุณไม่ได้ขอ

การรันงาน Codex หลายงานพร้อมกันไม่ใช่ฟีเจอร์ที่แค่เปิดสวิตช์ แต่เป็นสิ่งที่ต้องจัดตั้งขึ้นมา มีสามเส้นทาง ได้แก่ cloud tasks ของ Codex, การเปิด CLI session หลายตัวในเครื่อง และ subagents ภายในเซสชันเดียว แต่ละเส้นทางให้ความขนานจริง และแต่ละเส้นทางมีจุดพังจุดหนึ่งที่จะโผล่ขึ้นมาทันทีที่การเขียนทับกันเกิดขึ้น คู่มือนี้จะพาไปดูทั้งสามเส้นทางพร้อมคำสั่งและจุดพังที่ระบุไว้ในแต่ละขั้น จากนั้นจะแสดงว่ากระดานงาน (task board) เข้ามารับช่วงตรงไหน

กระดานงานที่ว่านี้คือ Sharkly คุณมี Codex อยู่แล้ว Sharkly วางตัวอยู่เหนือมัน: มันรัน Codex เป็น Runtime และเปลี่ยนการรันแบบขนานแต่ละครั้งให้กลายเป็น Task ที่มี checkout แยกของตัวเอง มี log ของตัวเอง และมี reviewer ของตัวเอง บทความนี้จะพูดถึงการตั้งค่าแบบmanual ก่อน เพราะคุณควรเข้าใจสิ่งที่กำลังจะไป automate ก่อนที่จะ automate มัน

สรุปสั้น ๆ

Codex parallel agents หมายถึงการรันงาน Codex หลายงานพร้อมกันแทนที่จะทำทีละงาน มีสามวิธี: Codex cloud tasks (แต่ละงานอยู่ในสภาพแวดล้อมแยกของตัวเอง ตามเอกสารของ OpenAI), การเปิดเซสชัน codex CLI หลายตัวในเครื่อง หรือ subagents ภายในเซสชันเดียว กฎที่ครอบคลุมทุกวิธีคือ หนึ่งสำเนาทำงานต่อหนึ่งหน่วยงาน: ให้แต่ละงานมี git worktree ของตัวเอง เพื่อที่การแก้ไขที่เกิดขึ้นพร้อมกันจะไม่แตะไฟล์เดียวกันเลย วิธีนี้รองรับงานไม่กี่งานได้สบาย แต่พอเกินกว่านั้น การติดตามว่า agent ตัวไหนทำอะไร และการรีวิวผลลัพธ์แต่ละอันแยกกัน กลายเป็นคอขวด ซึ่งเป็นเลเยอร์ที่ Sharkly เข้ามาเสริม

สามวิธีรัน Codex แบบขนาน

เลือกเส้นทางจากว่างานรันที่ไหนและคุณต้องเห็นมากแค่ไหน ไม่ใช่จากว่าเส้นทางไหนฟังดูทรงพลังที่สุด

ใช้ Codex cloud tasks เมื่องานมีขอบเขตชัดเจนและคุณโอเคที่จะไปตรวจทีหลัง ใช้ CLI session ในเครื่องเมื่อคุณอยากกำกับแต่ละการรันแบบสด ๆ ใช้ subagents เมื่องานส่วนใหญ่เป็นการอ่าน เพราะ agent ที่ถูก spawn จะใช้ working directory ร่วมกัน และตามพฤติกรรมของ Codex subagents เซสชันจะรอพวกมันทั้งหมดแล้วส่งคำตอบรวมเป็นชุดเดียว รูปแบบหลังนี้ไม่เหมาะกับการเขียนแบบขนาน เพราะ agent ที่แก้โค้ดพร้อมกันจะสร้าง conflict และคำสรุปเดียวก็รีวิวทีละส่วนไม่ได้

ทีละขั้นตอน: รันงาน Codex หลายงานในเครื่องโดยไม่ชนกัน

เส้นทางในเครื่องเป็นเส้นทางที่คนส่วนใหญ่หยิบมาใช้ก่อน และเป็นเส้นทางแรกที่พังก่อน นี่คือการตั้งค่าที่อยู่รอดได้

ขั้นที่ 1. ให้แต่ละงานมี checkout ของตัวเอง git worktree คือ working directory แห่งที่สองที่ใช้ repository เดียวกัน但与อยู่บนแบรนช์ของตัวเอง สร้างหนึ่งอันต่อหนึ่งงาน:

git worktree add ../app-authfix -b fix/token-refresh
git worktree add ../app-tests   -b test/checkout-coverage
git worktree add ../app-refactor -b refactor/api-client

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

ขั้นที่ 2. เปิดเซสชัน Codex หนึ่งตัวต่อหนึ่ง worktree เปิด terminal ในแต่ละไดเรกทอรีแล้วรัน Codex ที่นั่น:

cd ../app-authfix && codex

ถ้าไม่ทำขั้นนี้จะเจออะไร: เซสชันเดียวที่มีสี่เป้าหมายอยู่ใน context จะไหลไปมาระหว่างกัน และจำไม่ได้ว่าการเปลี่ยนแปลงไหนเป็นของงานไหน

ขั้นที่ 3. เขียนสคริปต์สำหรับงานที่ไม่ต้องมีคนนั่งเฝ้า สำหรับงานที่มีขอบเขตชัดเจน โหมด non-interactive จะรันจนจบโดยไม่ต้องป้อนอะไร:

cd ../app-tests && codex exec "add tests for the checkout flow until coverage passes"

ถ้าไม่ทำขั้นนี้จะเจออะไร: คุณต้องนั่งเฝ้าเซสชันที่ไม่ต้องการคุณเลย ซึ่งก็ทำลายจุดประสงค์ของการรันแบบขนานไปหมด

ขั้นที่ 4. merge อย่างตั้งใจ ทีละแบรนช์ แต่ละ worktree คือหนึ่งแบรนช์ ดังนั้นให้รีวิวและ merge แยกกัน อย่าปล่อยให้ agent merge งานของกันและกันเด็ดขาด ถ้าไม่ทำขั้นนี้จะเจออะไร: แบรนช์สามอันลงพร้อมกัน conflict โผล่ใน merge commit แล้วคุณก็แยกไม่ออกอีกต่อไปว่าการเปลี่ยนแปลงของ agent ตัวไหนทำให้เกิด

สำหรับกลไกการล้าง worktree อย่างสะอาดหลังใช้งาน ดูการจัดการ worktree สำหรับ coding agent โดยไม่ต้องปวดหัวกับการล้าง pattern worktree เดียวกันนี้ยังใช้ได้กับการรัน Claude Code agent หลายตัว ด้วย เพราะมันเป็นกลางต่อ runtime โดยการออกแบบ

จุดที่การตั้งค่าแบบ DIY เริ่มไปต่อไม่ได้

Worktree แก้ปัญหาการชนกันได้ แต่มันไม่ได้แก้ทุกอย่าง และกำแพงก็ใกล้กว่าที่คิด

ที่สามหรือสี่งาน การตั้งค่านี้ยังไหว แต่พอถึงแปดงาน ตาราง terminal ก็ไม่ใช่พื้นที่ทำงานอีกต่อไป แต่กลายเป็นแบบทดสอบความจำ ความล้มเหลวไม่ได้หวือหวา แต่มันสะสมไปเรื่อย ๆ:

• คุณหลุดแผนที่ หน้าต่างไหนคือ auth fix? อันไหนเสร็จแล้ว? อันไหนล้มเหลวเมื่อยี่สิบนาทีที่แล้วและว่างมาตั้งแต่ตอนนั้น? สถานะทั้งหมดอยู่ในหัวคุณเท่านั้น และเลื่อนหายไปจากจอ
• การรีวิวไม่มีรอยต่อ ผลลัพธ์ของแต่ละเซสชันคือกำแพง scrollback ไม่มีบันทึกต่อ task ว่ามันแตะอะไร รันอะไร และหยุดตรงไหน คุณจึงรับผลอันหนึ่งและปฏิเสธอีกอันได้ไม่สะอาด
• ไม่มีอะไรแชร์กัน พอเพื่อนร่วมทีมอยากดูความคืบหน้า คุณก็ต้องก๊อป diff ไปแปะในเธรด Slack งานเป็นของจริงแต่กลับมองไม่เห็น

นี่คือสามปัญหาที่ทุก workflow ของ parallel agent ต้องเจอเหมือนกัน และเป็นเหตุผลที่ทีมต่างมองหาเครื่องมือเฉพาะทางสำหรับจัดการ parallel coding agent เมื่อจำนวนงานเพิ่มขึ้น การแยกส่วนเป็นปัญหาที่แก้แล้ว แต่การมองเห็นและการรีวิวยังไม่ อย่างน้อยก็ไม่ใช่ด้วยตาราง terminal

กระดานงานเข้ามาเสริมอะไร

ตรงนี้แหละที่เลเยอร์เหนือ agent ขึ้นมาแสดงคุณค่า Task คือบันทึกที่ใช้ร่วมกันของงานหนึ่งหน่วยใน Sharkly และการรันงาน Codex แบบขนานก็กลายเป็นการรัน Task แบบขนาน

แต่ละ Task จะจอง git worktree ที่แยกออกมาให้เองโดยอัตโนมัติ ดังนั้นparallel agent ใน worktree ที่แยกออกจากกัน ก็ไม่ใช่สิ่งที่คุณต้องเขียนสคริปต์อีกต่อไป แต่กลายเป็นค่าเริ่มต้น สิบ Task ต่อหนึ่ง repository ไม่มี state ร่วมกันเลย ไม่ต้องพิมพ์ git worktree add ด้วยมือ Runtime ที่แก้โค้ดยังคงเป็น Codex แต่การแยกส่วนถูกจัดให้รอบ ๆ มัน

การแบ่งงานกันทำคือประเด็นสำคัญ Agent ค้นคว้า ลงมือ ทำการทดสอบ และรายงานผล คนกำหนดทิศทาง ให้อำนาจ และรับผลลัพธ์ Automation หยุดตรงจุดที่ต้องใช้ดุลยพินิจของทีม ดังนั้นแต่ละการรันจึงเก็บ execution log ของตัวเองไว้ พร้อม trigger, tool call และจุดที่หยุด และผลลัพธ์สุดท้ายก็กลับมาที่ Task แทนที่จะเลื่อนผ่านไปใน terminal context ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์ ยังมองเห็นได้ตั้งแต่คำขอจนถึง release และคุณรีวิวแต่ละอันแยกกันแทนที่จะอ่านสรุปของสรุป สำหรับด้านการรายงานของเรื่องนี้ ดูวิธีติดตามงานที่ AI coding agent ทำเสร็จ

Sharkly ไม่ใช่ตัวแทนของ Codex แต่เพิ่มเลเยอร์ task, checkout, context และการรีวิวที่ใช้ร่วมกันรอบ ๆ agent ที่คุณรันอยู่แล้ว ถ้าคุณรันเซสชัน Codex ทีละตัวเสมอ คุณก็ไม่จำเป็นต้องใช้มัน แต่ถ้าคุณรันหลายตัวกับโค้ดเบสเดียวและเริ่มตามไม่ทัน นั่นแหละคือปัญหาที่มันถูกสร้างมาเพื่อแก้ คุณจะสร้าง setup worktree ข้างบนด้วยมือเองก็ได้ หรือรันงาน Codex ที่มีอยู่ผ่าน Sharkly แล้วให้ workflow เก็บ state ไว้ให้คุณ

เช็กลิสต์ที่เอาไปใช้ได้วันนี้เลย

• หนึ่ง git worktree ต่อหนึ่งงาน แต่ละอันอยู่บนแบรนช์ของตัวเอง ไม่มีงานสองงานที่ใช้ checkout ร่วมกัน
• หนึ่งเซสชัน Codex ต่อหนึ่ง worktree หรือใช้ codex exec สำหรับงานที่ไม่ต้องการคุณ
• ใช้ subagents เฉพาะงานที่เน้นอ่านเป็นหลัก ส่วนการเขียนพร้อมกันให้แยก checkout ออกไป
• Merge ทีละแบรนช์ และรีวิวแต่ละอันก่อนที่มันจะลง
• เก็บบันทึกว่างานไหนคืออะไร งานแต่ละอันแตะอะไร และผลลัพธ์เป็นอย่างไร ไว้ในที่ที่เพื่อนร่วมทีมเห็นได้
• เมื่อตาราง terminal เริ่มจำไม่ไหว ให้ย้ายการติดตามและการรีวิวไปที่กระดานงาน Task เพื่อให้แต่ละการรันส่งผลลัพธ์กลับมาที่จุดร่วมจุดเดียว

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

Codex รันหลายงานพร้อมกันได้ไหม? ได้ Codex cloud รันงานในสภาพแวดล้อมที่แยกกันตามเอกสารของ OpenAI และในเครื่องคุณก็รันเซสชัน codex หลายตัวพร้อมกันได้ ข้อจำกัดอยู่ที่ checkout ไม่ใช่ตัว Codex: ให้แต่ละงานในเครื่องมี git worktree ของตัวเอง เพื่อที่การแก้ไขจะไม่ชนกัน

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

จำเป็นต้องใช้ worktree ไหม หรือเปิด terminal เพิ่มก็ได้? การเปิด terminal เพิ่มในไดเรกทอรีเดียวกันหมายถึงการเขียนไฟล์เดียวกันพร้อมกันและการเขียนทับกันแบบเงียบ ๆ Worktree ให้แต่ละเซสชันมีไดเรกทอรีและแบรนช์ของตัวเอง ซึ่งเป็นสิ่งที่ทำให้การทำงานแบบขนานในเครื่องปลอดภัย ดูgit worktree สำหรับ AI coding agent

Codex subagents กับ parallel tasks ต่างกันอย่างไร? Subagents รันภายในเซสชันเดียว ใช้ working directory ร่วมกัน และส่งคำตอบรวมเป็นชุดเดียว ซึ่งเหมาะกับการอ่านและการจัดลำดับความสำคัญ ส่วน parallel tasks เป็นการรันแยกกันโดยมี checkout แยกกัน ซึ่งเป็นสิ่งที่คุณต้องการสำหรับการเขียนพร้อมกันและการรีวิวแบบอิสระ