Multi-agent with Codex: แบ่งงานให้ทีม AI ช่วยพัฒนาและทดสอบซอฟต์แวร์

• 1. Multi-agent คืออะไร
  • ลำดับงานที่ใช้ในบทความ
• 2. เริ่มใช้งาน Subagents ใน Codex
  • ใช้ผ่านช่องทางใดได้บ้าง
• 3. เตรียม Codex CLI
• 4. ตั้งค่าจำนวนตัวแทนย่อย
• 5. สร้าง Custom Agents ให้ใช้ซ้ำ
  • 5.1 Reviewer: ตรวจโค้ดโดยไม่แก้ไฟล์
  • 5.2 Tester: เขียนเฉพาะชุดทดสอบ
  • 5.3 Docs: เขียนวิธีใช้จากข้อกำหนด
• 6. กำหนดข้อตกลงร่วมใน AGENTS.md
• 7. Workshop: ตรวจและแก้ฟังก์ชันค่าจัดส่งด้วยทีม AI
  • ขั้นที่ 1: สร้างโครงการ
  • ขั้นที่ 2: เขียนสัญญาของฟังก์ชัน
  • ขั้นที่ 3: สร้างโค้ดเริ่มต้นที่ตั้งใจให้มีข้อผิดพลาด
  • ขั้นที่ 4: เปิด Codex แล้วสั่งแบ่งงาน
  • ขั้นที่ 5: ตรวจชุดทดสอบที่ได้
  • ขั้นที่ 6: เปรียบเทียบกับแนวทางแก้ไข
  • ขั้นที่ 7: รันและตรวจผลรวม
• 8. ทำไมต้องกำหนดเจ้าของไฟล์
• 9. ออกแบบ Prompt ให้ตรวจผลงานได้
  • ตัวอย่างสำหรับวิเคราะห์ปัญหา Playwright
  • ตัวอย่างสำหรับเพิ่มฟีเจอร์ API
• 10. แยก Native Subagents ออกจาก SDK และ API
• 11. เลือกงานที่คุ้มกับการแบ่ง
  • ตัวชี้วัดสำหรับห้องเรียนหรือการทดลอง
• 12. แก้ปัญหาที่พบบ่อย
• เอกสารอ้างอิง

เมื่อใช้ Codex กับโครงการที่มีหลายส่วน เราสามารถมอบหมายให้ตัวแทนย่อยหรือ Subagents รับผิดชอบงานคนละด้าน แล้วให้ตัวแทนหลักรวบรวมหลักฐาน ตัดสินใจ และตรวจสอบผลลัพธ์ร่วมกันได้

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

ตรวจสอบเอกสารทางการวันที่ 17 ตุลาคม 2026 บทความนี้เน้น Codex รุ่นปัจจุบันบนเครื่องผู้ใช้ คำสั่งและรูปแบบตั้งค่าของรุ่นเก่าอาจแตกต่างกัน ตัวอย่างเวิร์กช็อปและ Prompt เป็นตัวอย่างที่ผู้เขียนออกแบบเพื่อการเรียนรู้

#1. Multi-agent คืออะไร

Multi-agent คือการจัดงานให้ตัวแทน AI หลายตัวร่วมกันแก้ปัญหา โดยแต่ละตัวมีหน้าที่ ขอบเขต และสิ่งที่ต้องส่งกลับให้ตรวจสอบได้

ในเวิร์กช็อปนี้ใช้โครงสร้างแบบ ตัวแทนหลักประสานงาน และตัวแทนย่อยทำงานเฉพาะด้าน ดังนี้

การให้ Agent เดียวสวมหลายบทบาทตามลำดับ ยังไม่มีการมอบหมายไปยัง Subagent จริง การใช้ Subagents จะมีเธรดของตัวแทนย่อยแยกออกมาให้ติดตามได้ในไคลเอนต์ที่รองรับ [1]

#ลำดับงานที่ใช้ในบทความ

flowchart TD
    S["ข้อกำหนดและโค้ดเริ่มต้น"] --> M["ตัวแทนหลักแบ่งงาน"]
    M --> R["Reviewer: รายงานปัญหา"]
    M --> T["Tester: สร้างชุดทดสอบ"]
    M --> D["Docs: เขียนวิธีใช้งาน"]
    R --> J["ตัวแทนหลักรอและรวมผล"]
    T --> J
    D --> J
    J --> F["แก้โค้ดและรันทดสอบรวม"]
    F --> Q{"ผ่านข้อกำหนดหรือไม่"}
    Q -->|ยังไม่ผ่าน| F
    Q -->|ผ่าน| O["ส่งมอบโค้ดและหลักฐาน"]

จุดที่ทำพร้อมกันคือการตรวจโค้ด สร้างชุดทดสอบ และเขียนเอกสารจากข้อกำหนด ส่วนการแก้โค้ดและตรวจผลรวมต้องรอข้อมูลที่เกี่ยวข้องก่อน

#2. เริ่มใช้งาน Subagents ใน Codex

เอกสารปัจจุบันระบุว่า Codex เปิดใช้ Subagent workflows โดยค่าเริ่มต้น ผู้ใช้สั่งให้แบ่งงานโดยตรงได้ และ Codex ยังทำตามคำแนะนำที่ร้องขอการแบ่งงานใน AGENTS.md หรือ Skill ที่เกี่ยวข้องได้ด้วย [1]

เริ่มจาก Prompt ที่ระบุบทบาทและผลลัพธ์ให้ชัดเจน เช่น

ช่วยตรวจโครงการนี้โดยใช้ Subagents 3 ตัวทำงานพร้อมกัน

1. ตัวแรกตรวจความถูกต้องของ business logic
2. ตัวที่สองตรวจช่องว่างของชุดทดสอบ
3. ตัวที่สามตรวจ README เทียบกับวิธีใช้งานจริง

รอบนี้ทุกตัวอ่านอย่างเดียว ห้ามแก้ไขไฟล์
ให้แต่ละตัวรายงานปัญหาพร้อมตำแหน่งไฟล์และหลักฐาน
รอผลครบทั้งสามตัว แล้วรวมรายการปัญหาที่ซ้ำกัน
จัดลำดับตามผลกระทบและเสนอขั้นตอนแก้ไข

#ใช้ผ่านช่องทางใดได้บ้าง

รายละเอียด UI และการเข้าถึงขึ้นกับไคลเอนต์และบัญชีที่ใช้งาน [1]

#3. เตรียม Codex CLI

หากยังไม่มี Codex ให้ติดตั้งตาม คู่มือ Codex CLI สำหรับระบบปฏิบัติการของตนเอง ตัวอย่างคำสั่งติดตั้งบน macOS/Linux ที่เอกสารปัจจุบันแสดงคือ [2]

curl -fsSL https://chatgpt.com/codex/install.sh | sh

จากนั้นเปิดไดเรกทอรีโครงการ

cd /path/to/your-project
codex --version
codex

เข้าใช้ด้วยวิธีลงชื่อเข้าที่ไคลเอนต์แสดง แล้วเลือกโมเดลที่บัญชีใช้งานได้ บทความนี้ไม่กำหนดชื่อโมเดลในไฟล์ตัวอย่าง เพื่อให้ใช้ค่าที่ตั้งไว้ในเครื่องได้ [2]

เมื่อต้องการตรวจสถานะการตั้งค่าใน CLI ใช้

/status

และใช้คำสั่งต่อไปนี้ใน CLI สำหรับดูเธรดของตัวแทนย่อย

/subagents

คำสั่งที่ขึ้นต้นด้วย / ให้พิมพ์ในหน้าจอ Codex CLI ไม่ใช่ใน Bash

#4. ตั้งค่าจำนวนตัวแทนย่อย

โดยทั่วไปเริ่มสั่งงานได้เลย หากต้องการกำหนดเพดานตัวแทนย่อย ให้เพิ่มค่าต่อไปนี้ใน .codex/config.toml ของโครงการ หรือ ~/.codex/config.toml สำหรับค่าระดับผู้ใช้ [3][4]

[agents]
enabled = true
max_concurrent_threads_per_session = 3

ค่า 3 ในตัวอย่างหมายถึงเปิดเธรดตัวแทนย่อยพร้อมกันได้สูงสุดสามเธรด ไม่นับเธรดหลัก และเป็นค่าที่เลือกใช้ในเวิร์กช็อปนี้ ไม่ใช่การระบุค่าเริ่มต้นของระบบ [4]

หากไฟล์มีตาราง [agents] อยู่แล้ว ให้เพิ่มหรือปรับคีย์ในตารางเดิม ไม่สร้างตารางชื่อซ้ำ โครงการต้องได้รับความเชื่อถือก่อน Codex จึงจะโหลดการตั้งค่าระดับโครงการ [3]

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

เอกสารปัจจุบันยังระบุ agents.max_threads เป็นชื่อเดิมที่ใช้แทน agents.max_concurrent_threads_per_session ได้ ตัวอย่างใหม่นี้ใช้ชื่อปัจจุบัน [4]

#5. สร้าง Custom Agents ให้ใช้ซ้ำ

หากต้องทำงานรูปแบบเดิมบ่อย ๆ สามารถสร้างตัวแทนเฉพาะงานเป็นไฟล์ TOML ได้ โดยวางไว้ที่ [1]

ไฟล์แต่ละตัวต้องมี name, description และ developer_instructions ตัวอย่างต่อไปนี้ตั้งชื่อบทบาทสำหรับเวิร์กช็อปของเรา โดยไม่ระบุโมเดลเพื่อให้สืบทอดค่าจากตัวแทนหลัก [1]

#5.1 Reviewer: ตรวจโค้ดโดยไม่แก้ไฟล์

ไฟล์ .codex/agents/code-reviewer.toml

name = "code_reviewer"
description = "ตรวจ business logic และกรณีขอบจากข้อกำหนด โดยไม่แก้ไขไฟล์"

developer_instructions = """
อ่าน REQUIREMENTS.md และโค้ดที่ได้รับมอบหมาย
ตรวจความถูกต้องของเงื่อนไข การตรวจข้อมูล และกรณีขอบ
ห้ามแก้ไขไฟล์และห้ามสั่งคำสั่งที่เปลี่ยนแปลงโครงการ
รายงานแต่ละปัญหาพร้อมไฟล์ สัญลักษณ์ที่เกี่ยวข้อง
ตัวอย่างข้อมูลเข้า ผลที่เกิดขึ้น และผลที่ควรเป็น
แยกปัญหาที่มีหลักฐานออกจากข้อสงสัย
"""

#5.2 Tester: เขียนเฉพาะชุดทดสอบ

ไฟล์ .codex/agents/test-writer.toml

name = "test_writer"
description = "สร้างชุดทดสอบจาก REQUIREMENTS.md ใน tests/ เท่านั้น"

developer_instructions = """
อ่าน REQUIREMENTS.md ก่อนออกแบบการทดสอบ
แก้ไขหรือสร้างไฟล์ได้เฉพาะใน tests/
ใช้ node:test และ node:assert/strict
ครอบคลุมกรณีปกติ ขอบเขต และข้อมูลไม่ถูกต้อง
อย่าเปลี่ยนข้อกำหนดหรือโค้ดใน src/ เพื่อให้การทดสอบผ่าน
รายงานคำสั่งที่ใช้และผลจริง หากไม่ได้รันให้ระบุว่าไม่ได้รัน
"""

#5.3 Docs: เขียนวิธีใช้จากข้อกำหนด

ไฟล์ .codex/agents/docs-writer.toml

name = "docs_writer"
description = "เขียน README.md ให้ตรงกับข้อกำหนดและคำสั่งของโครงการ"

developer_instructions = """
อ่าน REQUIREMENTS.md และ package.json
เขียนหรือแก้ไขได้เฉพาะ README.md
อธิบายหน่วยเงิน ชนิดข้อมูล เงื่อนไขค่าจัดส่ง และวิธีรันทดสอบ
ระหว่างพัฒนาให้แยกพฤติกรรมตามข้อกำหนดจากสถานะโค้ดปัจจุบัน
ห้ามอ้างว่าชุดทดสอบผ่านหากไม่ได้เห็นผลรัน
"""

ข้อความจำกัดไฟล์ในตัวอย่างเป็นคำแนะนำการทำงาน ตัวแทนย่อยยังสืบทอดสิทธิ์และ Sandbox จากเซสชันหลัก การเขียนว่า “ห้ามแก้ไฟล์” จึงไม่ได้สร้าง Sandbox แบบอ่านอย่างเดียวแยกขึ้นมา [1]

#6. กำหนดข้อตกลงร่วมใน AGENTS.md

AGENTS.md ใช้บอกแนวทางของโครงการที่ Codex ควรอ่านก่อนทำงาน เหมาะกับคำสั่งทดสอบและข้อตกลงร่วมของทีม [5]

สร้างไฟล์ AGENTS.md ที่รากโครงการเวิร์กช็อป

# แนวทางสำหรับเวิร์กช็อป Shipping Fee

## ข้อกำหนดหลัก

- ใช้ REQUIREMENTS.md เป็นเกณฑ์ตรวจพฤติกรรม
- จำนวนเงินใช้หน่วยสตางค์ และเป็นจำนวนเต็มที่ปลอดภัยของ JavaScript
- ใช้ Node.js 22 ขึ้นไป และ ES modules
- รันทดสอบด้วย npm test

## การแบ่งงาน

- เมื่อผู้ใช้ขอให้ใช้ Multi-agent ให้ใช้ Subagents ตามบทบาทที่ระบุ
- code_reviewer อ่านและรายงานเท่านั้น
- test_writer แก้ไขได้เฉพาะ tests/
- docs_writer แก้ไขได้เฉพาะ README.md
- ตัวแทนหลักรับผิดชอบ src/ และการตรวจผลรวม
- ห้ามแก้ไขหรือย้อนงานของตัวแทนอื่นโดยไม่ประสานกับตัวแทนหลัก
- รอชุดทดสอบและรายงานตรวจโค้ดก่อนแก้ business logic

## การส่งผล

- ระบุไฟล์ที่เปลี่ยน คำสั่งที่รัน และผลจริง
- แยกข้อเท็จจริง สมมติฐาน และงานที่ยังไม่ได้ตรวจสอบ

ในโครงการจริงควรปรับคำสั่งและขอบเขตให้ตรงกับโครงสร้างของทีม ตัวอย่างนี้เป็นข้อตกลงสำหรับห้องฝึกปฏิบัติ

#7. Workshop: ตรวจและแก้ฟังก์ชันค่าจัดส่งด้วยทีม AI

เป้าหมายคือทดลองครบวงจร ตั้งแต่ข้อกำหนด โค้ดที่มีข้อผิดพลาด การแบ่งงานตรวจ และการตรวจผลหลังแก้

ใช้ Node.js 22 ขึ้นไปเพื่อรันตัวอย่าง และใช้ Git เก็บสถานะเริ่มต้นเมื่อพร้อม โค้ดฝึกปฏิบัติไม่ต้องติดตั้งแพ็กเกจทดสอบเพิ่มเติม

#ขั้นที่ 1: สร้างโครงการ

mkdir codex-multi-agent-workshop
cd codex-multi-agent-workshop
git init
mkdir -p src tests .codex/agents

สร้างไฟล์ package.json

{
  "name": "codex-multi-agent-workshop",
  "private": true,
  "type": "module",
  "scripts": {
    "test": "node --test tests/shipping.test.mjs"
  }
}

จากนั้นสร้างไฟล์ตั้งค่า ตัวแทนทั้งสาม และ AGENTS.md ตามหัวข้อก่อนหน้า

#ขั้นที่ 2: เขียนสัญญาของฟังก์ชัน

สร้าง REQUIREMENTS.md

# Shipping Fee Requirements

ฟังก์ชัน: shippingFee(subtotalCents, isMember = false)
ส่งออกจาก src/shipping.mjs

## ข้อมูลเข้า

- subtotalCents ต้องมีชนิด number
- subtotalCents ต้องเป็น safe integer และมีค่าตั้งแต่ 0 ขึ้นไป
- ชนิดของ subtotalCents ผิด: โยน TypeError
- subtotalCents เป็นตัวเลขแต่ผิดช่วงหรือไม่ใช่ safe integer:
  โยน RangeError รวมถึง NaN และ Infinity
- isMember ต้องเป็น boolean หากส่งชนิดอื่นให้โยน TypeError
- ตรวจสอบข้อมูลเข้าทั้งหมดก่อนใช้สิทธิ์ส่งฟรี

## กติกา

- สมาชิกส่งฟรีทุกยอดซื้อที่ถูกต้อง
- ผู้ซื้อทั่วไปมียอดตั้งแต่ 100000 สตางค์ขึ้นไป: ส่งฟรี
- ผู้ซื้อทั่วไปมียอดต่ำกว่า 100000 สตางค์: ค่าส่ง 5000 สตางค์
- ผลลัพธ์เป็นจำนวนเต็มหน่วยสตางค์
- ห้ามแปลง string เป็น number หรือใช้ truthy แทน boolean

การระบุหน่วยเงินและชนิดข้อผิดพลาดช่วยให้ Reviewer กับ Tester ใช้เกณฑ์เดียวกัน เช่น 100000 สตางค์หมายถึง 1,000 บาท และ 5000 สตางค์หมายถึง 50 บาท

#ขั้นที่ 3: สร้างโค้ดเริ่มต้นที่ตั้งใจให้มีข้อผิดพลาด

ไฟล์ src/shipping.mjs

export function shippingFee(subtotalCents, isMember = false) {
  if (isMember) {
    return 0;
  }

  if (subtotalCents > 100_000) {
    return 0;
  }

  return 5_000;
}

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

#ขั้นที่ 4: เปิด Codex แล้วสั่งแบ่งงาน

codex

ส่ง Prompt ต่อไปนี้

ทำ Workshop นี้โดยใช้ Subagents 3 ตัวพร้อมกัน

ใช้ REQUIREMENTS.md เป็นข้อกำหนดร่วม

1. code_reviewer:
   ตรวจ src/shipping.mjs โดยอ่านอย่างเดียว
   รายงานบั๊กพร้อมข้อมูลเข้าที่ทำให้เกิดและผลที่ควรได้

2. test_writer:
   สร้าง tests/shipping.test.mjs ด้วย node:test
   แก้ไขได้เฉพาะ tests/
   ครอบคลุมยอดต่ำกว่า เท่ากับ และสูงกว่าเกณฑ์
   รวมถึงสมาชิก ชนิดข้อมูลผิด NaN Infinity และ unsafe integer
   รัน npm test กับโค้ดเริ่มต้นแล้วรายงานผลตามจริง

3. docs_writer:
   เขียน README.md อธิบายสัญญาของฟังก์ชันและวิธีรันทดสอบ
   แก้ไขได้เฉพาะ README.md
   อย่าใส่ผลทดสอบที่ยังไม่ได้เห็น

ตัวแทนหลัก:
- รอทั้งสามตัวทำเสร็จ
- ตรวจผลของทุกตัวเทียบกับข้อกำหนด
- แก้ src/shipping.mjs ตามปัญหาที่ตรวจพบ
- รัน npm test อีกครั้งหลังรวมงาน
- ตรวจ README กับพฤติกรรมสุดท้าย
- สรุปบั๊กที่แก้ ไฟล์ที่เปลี่ยน และผลทดสอบก่อนและหลัง

ระหว่างทำงานใช้ /subagents ดูเธรด และส่งข้อความเพิ่มเติมให้ตัวแทนหลักประสานงานเมื่อพบงานทับซ้อน

#ขั้นที่ 5: ตรวจชุดทดสอบที่ได้

ตัวอย่างด้านล่างเป็นชุดทดสอบอ้างอิงสำหรับเปรียบเทียบกับชุดที่ Agent สร้าง ไม่จำเป็นต้องเหมือนกันทุกบรรทัด แต่ต้องตรวจพฤติกรรมที่กำหนดได้

ไฟล์ tests/shipping.test.mjs

import test from 'node:test';
import assert from 'node:assert/strict';
import { shippingFee } from '../src/shipping.mjs';

test('ผู้ซื้อทั่วไป ยอดต่ำกว่าเกณฑ์ เสียค่าส่ง', () => {
  assert.equal(shippingFee(0), 5_000);
  assert.equal(shippingFee(99_999), 5_000);
});

test('ยอดเท่ากับเกณฑ์ ส่งฟรี', () => {
  assert.equal(shippingFee(100_000), 0);
});

test('ยอดสูงกว่าเกณฑ์ ส่งฟรี', () => {
  assert.equal(shippingFee(100_001), 0);
});

test('สมาชิกส่งฟรีเมื่อข้อมูลถูกต้อง', () => {
  assert.equal(shippingFee(0, true), 0);
  assert.equal(shippingFee(99_999, true), 0);
});

test('จำนวนเต็มบวกสูงสุดที่ปลอดภัยยังเป็นยอดที่รับได้', () => {
  assert.equal(shippingFee(Number.MAX_SAFE_INTEGER), 0);
});

test('ยอดที่มีชนิดผิดต้องถูกปฏิเสธ', () => {
  for (const value of ['100000', null, undefined]) {
    assert.throws(() => shippingFee(value), TypeError);
  }
});

test('ตัวเลขผิดช่วงหรือไม่เป็น safe integer ต้องถูกปฏิเสธ', () => {
  for (const value of [-1, 0.5, NaN, Infinity, Number.MAX_SAFE_INTEGER + 1]) {
    assert.throws(() => shippingFee(value), RangeError);
  }
});

test('สถานะสมาชิกต้องเป็น boolean', () => {
  for (const value of ['yes', 1, 0, null]) {
    assert.throws(() => shippingFee(10_000, value), TypeError);
  }
});

test('สมาชิกก็ต้องผ่านการตรวจยอดซื้อ', () => {
  assert.throws(() => shippingFee(-1, true), RangeError);
  assert.throws(() => shippingFee('100000', true), TypeError);
});

สิ่งที่ควรมองหาในการตรวจงานของทีมคือ ตัวทดสอบที่ล้มเหลวต้องเชื่อมโยงกับข้อกำหนดจริง และตัวแทนหลักต้องแก้สาเหตุของปัญหา

#ขั้นที่ 6: เปรียบเทียบกับแนวทางแก้ไข

ตัวอย่าง src/shipping.mjs หลังแก้

export function shippingFee(subtotalCents, isMember = false) {
  if (typeof subtotalCents !== 'number') {
    throw new TypeError('subtotalCents must be a number');
  }

  if (!Number.isSafeInteger(subtotalCents) || subtotalCents < 0) {
    throw new RangeError('subtotalCents must be a non-negative safe integer');
  }

  if (typeof isMember !== 'boolean') {
    throw new TypeError('isMember must be a boolean');
  }

  return isMember || subtotalCents >= 100_000 ? 0 : 5_000;
}

ตัวอย่างนี้แก้ทั้งเงื่อนไขขอบเขต > เป็น >= และเพิ่มการตรวจข้อมูลก่อนใช้เงื่อนไขส่งฟรี

#ขั้นที่ 7: รันและตรวจผลรวม

npm test
git status --short
git diff

หากไฟล์ยังไม่เคยเพิ่มเข้า Git ไฟล์ใหม่จะยังไม่อยู่ใน git diff ให้ดูจาก git status --short และเปิดไฟล์นั้นตรวจโดยตรง

ผลของ ชุดทดสอบอ้างอิงข้างต้น ที่ตรวจในสภาพแวดล้อมจัดทำบทความ:

ผลนี้เป็นการรันตัวอย่าง JavaScript กับ Node.js โดยตรง ไม่ใช่หลักฐานว่ามีการรันเซสชัน Codex CLI หรือ Custom Agents จริงในสภาพแวดล้อมของผู้อ่าน จำนวนกรณีที่ Agent สร้างอาจต่างกัน และควรตรวจคุณภาพกรณีทดสอบควบคู่กับจำนวนที่ผ่าน

#8. ทำไมต้องกำหนดเจ้าของไฟล์

การแยกเธรดสนทนาไม่ได้แปลว่าไฟล์ถูกแยกออกจากกันโดยอัตโนมัติ ในเวิร์กช็อปจึงกำหนดผู้รับผิดชอบให้ชัดเจน

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

สำหรับงานพัฒนาขนาดใหญ่ อาจแยกงานเป็นคนละ Git worktree ซึ่งมีชุดไฟล์ของตนเองและใช้ข้อมูล Git ร่วมกัน เอกสาร Codex อธิบายการใช้ Worktrees เพื่อทำงานหลายแชตในโครงการเดียวกันได้ [6]

ตัวอย่างแนวทางจัดงานคือให้ทีมหนึ่งพัฒนา API ใน Worktree A และอีกทีมพัฒนา UI ใน Worktree B จากสัญญา API ที่ตกลงไว้ จากนั้นจึงรวมการเปลี่ยนแปลงและรันทดสอบการเชื่อมต่อ การสร้าง Worktree สำหรับแชตต่าง ๆ เป็นขั้นตอนจัดสภาพแวดล้อมที่ต้องเลือกใช้อย่างชัดเจน

#9. ออกแบบ Prompt ให้ตรวจผลงานได้

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

เป้าหมาย:
ผลลัพธ์ที่ต้องการให้ผู้ใช้หรือระบบทำได้

แหล่งอ้างอิงร่วม:
ข้อกำหนด โค้ดเริ่มต้น และเอกสาร API ที่เกี่ยวข้อง

แบ่งงาน:
Agent A ทำอะไร
Agent B ทำอะไร
แต่ละตัวอ่านหรือแก้ไขไฟล์ใดได้บ้าง

จุดที่ต้องรอ:
งานใดเริ่มได้ทันที
งานใดต้องรอผลจากงานก่อนหน้า

ผลที่ต้องส่งกลับ:
ไฟล์ หลักฐาน คำสั่งทดสอบ และข้อจำกัดที่พบ

การรวมงาน:
ใครตัดสินใจเมื่อข้อเสนอขัดกัน
ใครตรวจผลบนโค้ดสุดท้าย

#ตัวอย่างสำหรับวิเคราะห์ปัญหา Playwright

ใช้ Subagents 3 ตัววิเคราะห์ Playwright test ที่ล้มเหลว

A: ตรวจ locator และความเปลี่ยนแปลงของ DOM
B: ตรวจ API response และข้อมูลทดสอบ
C: ตรวจ timing, isolation และ shared state

ทุกตัวอ่านอย่างเดียวในรอบแรก
ให้รายงานหลักฐานพร้อมไฟล์และสมมติฐานที่ยังไม่ยืนยัน
รอผลครบ แล้วให้ตัวแทนหลักเลือกสมมติฐานที่จะทดลองก่อน
แก้โค้ดทีละสาเหตุ และรันกรณีที่ล้มเหลวซ้ำ

ตัวอย่างนี้แบ่งตามสาเหตุที่เป็นไปได้ ทำให้แต่ละตัวมีคำถามที่ต้องตอบชัดเจน

#ตัวอย่างสำหรับเพิ่มฟีเจอร์ API

ก่อนแบ่งงาน ให้กำหนด request/response และสถานะ HTTP ร่วมกัน

จากนั้นใช้ Subagents:
- ตัวที่หนึ่งพัฒนา endpoint ใน backend/
- ตัวที่สองสร้าง API tests ใน tests/api/
- ตัวที่สามอัปเดตคู่มือใน docs/api/

รอทุกตัวทำเสร็จ แล้วตรวจสัญญา API และรัน integration tests
ให้ตัวแทนหลักรับผิดชอบไฟล์ dependency และไฟล์ config ที่ใช้ร่วมกัน

#10. แยก Native Subagents ออกจาก SDK และ API

คำว่า Multi-agent อาจหมายถึงการใช้งานคนละระดับ จึงควรเลือกเครื่องมือจากสิ่งที่ต้องควบคุม

Codex SDK เป็นช่องทางควบคุม Codex ผ่านโปรแกรม ส่วน Native Subagents เป็นการมอบหมายงานภายในเวิร์กโฟลว์ของ Codex การเรียกหลาย Thread จากโปรแกรมไม่ได้กำหนดการแบ่งบทบาท การรวมผล หรือการแยกไฟล์ให้เราโดยอัตโนมัติ [7]

สำหรับ Agents API เอกสารมีการตั้งค่า agent.multi_agent.enabled ระหว่างสร้าง Session ซึ่งเป็นสัญญาของ API คนละส่วนกับ [agents] ในไฟล์ตั้งค่า Codex [8]

บทความนี้จึงเริ่มจาก Native Subagents ก่อน เพื่อให้เห็นเรื่องข้อกำหนด การมอบหมาย และการตรวจผลโดยไม่ต้องสร้างระบบประสานงานด้วยโค้ดเพิ่ม

หากพบตัวอย่างเก่าที่ใช้ codex mcp-server ให้ตรวจคู่มือปัจจุบันก่อน เอกสาร Codex SDK ระบุว่าคำสั่งดังกล่าวถูกนำออกแล้ว และแนะนำ SDK สำหรับงานอัตโนมัติ หรือ app server สำหรับการเชื่อมต่อที่ลึกขึ้น [7]

#11. เลือกงานที่คุ้มกับการแบ่ง

การใช้หลายตัวแทนอาจลดเวลาของงานอิสระ แต่ยังมีเวลาในการส่งมอบบริบท รอผล รวมงาน และแก้ข้อขัดแย้ง จึงควรวัดจากงานจริง

ตัวอย่างสมมติ: หากงานย่อยใช้เวลา 8, 6 และ 5 นาที การทำทีละงานใช้ 19 นาที ส่วนการทำพร้อมกันมีช่วงทำงานย่อยยาวสุดประมาณ 8 นาที และต้องบวกเวลารวมงาน ตัวเลขนี้ใช้สาธิตการคิดเวลา ไม่ใช่ผล Benchmark ของ Codex

ตัวแทนย่อยแต่ละตัวทำงานโมเดลและเครื่องมือของตนเอง เอกสารจึงระบุว่าโดยทั่วไปใช้โทเคนมากกว่างานที่เทียบเคียงกันด้วย Agent เดียว [1]

#ตัวชี้วัดสำหรับห้องเรียนหรือการทดลอง

หากเปรียบเทียบ Single-agent กับ Multi-agent ให้ใช้โค้ดเริ่มต้น ข้อกำหนด เครื่องมือ และเกณฑ์ผ่านชุดเดียวกัน แล้วทำซ้ำหลายรอบ ไม่สรุปความเหนือกว่าจากการทดลองครั้งเดียว

#12. แก้ปัญหาที่พบบ่อย

เริ่มใช้งานจากการตรวจโค้ดแบบอ่านอย่างเดียวก่อน แล้วค่อยเพิ่มงานเขียนที่แบ่งเจ้าของไฟล์ได้ชัดเจน สำหรับงานที่มีการแก้ไขพร้อมกัน ให้ตัวแทนหลักตรวจผลบนโค้ดสุดท้ายทุกครั้ง

#เอกสารอ้างอิง

1. OpenAI — Subagents
2. OpenAI — Codex CLI
3. OpenAI — Config basics
4. OpenAI — Configuration Reference
5. OpenAI — Custom instructions with AGENTS.md
6. OpenAI — Worktrees
7. OpenAI — Codex SDK
8. OpenAI — Agents API: Multi-agent