Codex เริ่มรองรับ Subagents

• OpenAI Codex รองรับ เวิร์กโฟลว์แบบซับเอเจนต์ ที่ช่วย กระจายงานซับซ้อนแบบขนานไปยังเอเจนต์เฉพาะทางหลายตัวและรวมผลลัพธ์กลับเป็นหนึ่งเดียว
• จะสร้างซับเอเจนต์ก็ต่อเมื่อผู้ใช้ร้องขออย่างชัดเจนเท่านั้น และเนื่องจากแต่ละเอเจนต์ใช้โมเดลและเครื่องมือแยกกัน จึงทำให้ การใช้โทเคนสูงกว่าเอเจนต์เดี่ยว
• สามารถกำหนด คัสตอมเอเจนต์ ด้วยไฟล์ TOML เพื่อแยกตั้งค่าโมเดล โหมดแซนด์บ็อกซ์ เซิร์ฟเวอร์ MCP และอื่น ๆ สำหรับแต่ละเอเจนต์ได้อย่างอิสระ
• ยังมีฟีเจอร์ทดลอง spawn_agents_on_csv ที่ใช้แต่ละแถวของไฟล์ CSV เป็นหนึ่งหน่วยงาน แล้วสร้าง worker agent จำนวนมากในคราวเดียว
• เอกสารทางการยังแนะนำ แพตเทิร์นการจัดชุดคัสตอมเอเจนต์ สำหรับสถานการณ์ใช้งานจริง เช่น code review และการดีบักฟรอนต์เอนด์โดยตรง

---

ภาพรวมและการใช้งานของซับเอเจนต์

• Codex รองรับเวิร์กโฟลว์แบบซับเอเจนต์ที่สามารถ สร้าง (spawn) เอเจนต์เฉพาะทางแบบขนาน และรวบรวมผลลัพธ์กลับมาเป็นคำตอบเดียว
• มีประโยชน์อย่างยิ่งกับงานซับซ้อนที่ต้องการ ความขนานสูง เช่น การสำรวจ codebase หรือการวางแผนพัฒนาฟีเจอร์หลายขั้นตอน
• ในเวิร์กโฟลว์ซับเอเจนต์ ยังสามารถกำหนดคัสตอมเอเจนต์ที่มี การตั้งค่าโมเดลและคำสั่งแตกต่างกัน ตามลักษณะงานได้
• ใน Codex รุ่นปัจจุบัน เวิร์กโฟลว์ซับเอเจนต์ถูก เปิดใช้งานเป็นค่าเริ่มต้น
• ขณะนี้สามารถดูการทำงานของซับเอเจนต์ได้ใน แอป Codex และ CLI และจะเพิ่มการมองเห็นใน IDE Extension ในเร็ว ๆ นี้
• จะสร้างซับเอเจนต์ก็ต่อเมื่อผู้ใช้ร้องขออย่างชัดเจนเท่านั้น และเพราะแต่ละซับเอเจนต์มีการทำงานของโมเดลและเครื่องมือของตนเอง จึง ใช้โทเคนมากกว่าการรันแบบเอเจนต์เดี่ยว

เวิร์กโฟลว์ทั่วไป

• Codex จัดการ orchestration ระหว่างเอเจนต์ทั้งหมด ได้แก่ การสร้างซับเอเจนต์ใหม่ การส่งต่อคำสั่งภายหลัง การรอผลลัพธ์ และการปิดเธรดของเอเจนต์
• เมื่อมีหลายเอเจนต์กำลังทำงาน Codex จะ รอจนผลลัพธ์ของทุกคำขอพร้อม ก่อนส่งคำตอบแบบรวมกลับมา
• ตัวอย่างพรอมป์ต์: ขอให้สร้าง เอเจนต์คนละหนึ่งตัว สำหรับประเด็นด้าน security, code quality, bug, race condition, test instability และ maintainability ของ PR ปัจจุบัน แล้วสรุปผลทั้งหมด

การจัดการซับเอเจนต์

• ใน CLI สามารถใช้คำสั่ง /agent เพื่อ สลับระหว่างเธรดเอเจนต์ที่กำลังทำงาน และตรวจสอบเธรดที่กำลังดำเนินอยู่ได้
• สามารถสั่ง Codex โดยตรงเพื่อ ควบคุม หยุด หรือปิดเธรดที่เสร็จแล้ว ของซับเอเจนต์ที่กำลังรันอยู่ได้

การอนุมัติและการควบคุมแซนด์บ็อกซ์

• ซับเอเจนต์จะสืบทอด นโยบายแซนด์บ็อกซ์ปัจจุบัน ของผู้ใช้
• ในเซสชัน CLI แบบโต้ตอบ คำขออนุมัติจากเธรดเอเจนต์ที่ไม่ได้ active อาจแสดงขึ้นได้แม้กำลังใช้งานเธรดหลักอยู่ โดย overlay การอนุมัติจะมี ป้ายกำกับเธรดต้นทาง แสดงไว้
  • กด o เพื่อเปิดเธรดนั้น แล้วสามารถอนุมัติ ปฏิเสธ หรือโต้ตอบได้
• ในโฟลว์แบบไม่โต้ตอบ ไม่สามารถแสดงคำขออนุมัติใหม่ได้ ดังนั้นงานที่ต้องได้รับอนุมัติจะ ล้มเหลวและส่งต่อข้อผิดพลาดไปยังเวิร์กโฟลว์ระดับบน
• เมื่อสร้าง child agent ระบบจะนำ live runtime override ของ parent turn กลับมาใช้ใหม่ รวมถึงการเปลี่ยน /approvals หรือการตั้งค่าแบบโต้ตอบอย่าง --yolo
  • แม้ไฟล์คัสตอมเอเจนต์ที่เลือกจะกำหนดค่าเริ่มต้นต่างออกไป การตั้งค่าของ parent จะมีลำดับความสำคัญสูงกว่า
• สามารถ override การตั้งค่าแซนด์บ็อกซ์แยกตามคัสตอมเอเจนต์แต่ละตัว ได้ (เช่น กำหนดให้บางเอเจนต์อยู่ในโหมดอ่านอย่างเดียว)

คัสตอมเอเจนต์

• Codex มีเอเจนต์ในตัวมาให้ 3 แบบ
  • default: fallback agent สำหรับใช้งานทั่วไป
  • worker: เอเจนต์เน้นการลงมือทำ สำหรับการพัฒนาและแก้ไข
  • explorer: เอเจนต์เน้นการอ่าน สำหรับสำรวจ codebase
• เมื่อต้องการกำหนดคัสตอมเอเจนต์ ให้เพิ่ม ไฟล์ TOML แยกอิสระ ที่ ~/.codex/agents/ (ส่วนตัว) หรือ .codex/agents/ (ระดับโปรเจกต์)
• แต่ละไฟล์จะนิยามคัสตอมเอเจนต์หนึ่งตัว และ Codex จะโหลดไฟล์นั้นเป็น เลเยอร์การตั้งค่า ของเซสชันที่สร้างขึ้น
• ฟิลด์บังคับที่ต้องมีในไฟล์คัสตอมเอเจนต์ทุกไฟล์:
  • name, description, developer_instructions
• ฟิลด์ทางเลือก เช่น nickname_candidates, model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config จะ สืบทอดจากเซสชันแม่ หากละไว้

การตั้งค่าแบบโกลบอล

• การตั้งค่าโกลบอลของซับเอเจนต์นิยามไว้ในส่วน [agents] ของไฟล์ configuration
• agents.max_threads: จำนวนสูงสุด ของเธรดเอเจนต์ที่เปิดพร้อมกัน (ค่าเริ่มต้น 6)
• agents.max_depth: ระดับความลึกของการซ้อน ของเอเจนต์ที่ถูกสร้าง (ค่าเริ่มต้น 1 อนุญาตเฉพาะ child agent โดยตรง และป้องกันการซ้อนลึกกว่านั้น)
• agents.job_max_runtime_seconds: ค่า timeout เริ่มต้นต่อ worker สำหรับงาน spawn_agents_on_csv (หากไม่กำหนด จะใช้ค่าเริ่มต้น 1800 วินาทีต่อการเรียก)
• หากชื่อคัสตอมเอเจนต์ตรงกับเอเจนต์ในตัว เช่น explorer คัสตอมเอเจนต์จะถูกใช้ก่อน

สคีมาไฟล์คัสตอมเอเจนต์

• name (string, บังคับ): ชื่อเอเจนต์ ที่ Codex ใช้ตอนสร้างหรืออ้างอิงเอเจนต์
• description (string, บังคับ): คำแนะนำสำหรับมนุษย์ ว่าควรใช้เอเจนต์นี้เมื่อใด
• developer_instructions (string, บังคับ): คำสั่งหลัก ที่กำหนดพฤติกรรมของเอเจนต์
• nickname_candidates (string[], ทางเลือก): ชุดชื่อเล่นที่ใช้แสดงผล สำหรับเอเจนต์ที่ถูกสร้างขึ้น
• ยังสามารถใส่คีย์ config.toml อื่น ๆ ที่รองรับได้ เช่น model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config
• Codex ใช้ฟิลด์ name ในการระบุเอเจนต์ ดังนั้นแม้การตั้งชื่อไฟล์ให้ตรงกับชื่อเอเจนต์จะเป็นแนวทางที่ง่ายที่สุด แต่ ฟิลด์ name คือข้อมูลอ้างอิงหลัก (source of truth)

ชื่อเล่นที่ใช้แสดงผล

• nickname_candidates ใช้เพื่อให้ UI แสดง ป้ายชื่อที่แยกแยะได้ เมื่อต้องรันหลายอินสแตนซ์ของคัสตอมเอเจนต์ตัวเดียวกัน
• ชื่อเล่นใช้ เพื่อการแสดงผลเท่านั้น และ Codex ยังคงระบุและสร้างเอเจนต์ด้วย name
• รายการชื่อเล่นต้องเป็นชุดชื่อที่ไม่ซ้ำและไม่ว่าง และสามารถใช้อักขระ ASCII ตัวเลข ช่องว่าง ยัติภังค์ และขีดล่างได้
• ตัวอย่าง: หากกำหนดชื่อเล่น ["Atlas", "Delta", "Echo"] ให้เอเจนต์ reviewer ในแอปและ CLI จะ แสดงชื่อเล่น แต่ประเภทเอเจนต์พื้นฐานยังคงเป็น reviewer

ตัวอย่าง 1: แพตเทิร์นการรีวิว PR

• เป็นแพตเทิร์นที่แยกการรีวิวออกเป็น คัสตอมเอเจนต์เฉพาะทาง 3 ตัว
  • pr_explorer: เอเจนต์แบบอ่านอย่างเดียวที่ทำหน้าที่แมป codebase และ รวบรวมหลักฐาน (โมเดล: gpt-5.3-codex-spark, reasoning effort: medium)
  • reviewer: ผู้รีวิว PR ที่มองหาความถูกต้อง ความปลอดภัย และ ความเสี่ยงด้านการทดสอบ (โมเดล: gpt-5.4, reasoning effort: high)
  • docs_researcher: ผู้เชี่ยวชาญด้านเอกสารที่ใช้ MCP server เฉพาะเพื่อตรวจสอบ เอกสารของเฟรมเวิร์กหรือ API (โมเดล: gpt-5.3-codex-spark, อ่านอย่างเดียว)
• การตั้งค่าระดับโปรเจกต์: max_threads = 6, max_depth = 1
• คำสั่งของ pr_explorer: คงโหมดสำรวจ ติดตามเส้นทางการทำงานจริง อ้างอิงไฟล์และสัญลักษณ์ และ งดเสนอการแก้ไข เว้นแต่ parent agent จะร้องขอ
• คำสั่งของ reviewer: รีวิวจากมุมมองเจ้าของโค้ด ให้ความสำคัญกับความถูกต้อง ความปลอดภัย การ regression ของพฤติกรรม และ test coverage ที่ขาดหาย พร้อม แนบขั้นตอนการทำซ้ำเมื่อเป็นไปได้ และหลีกเลี่ยงคอมเมนต์เรื่องสไตล์ล้วน ๆ เว้นแต่จะบดบังบั๊กจริง
• คำสั่งของ docs_researcher: ใช้ docs MCP server เพื่อตรวจสอบ API, options และพฤติกรรมตามเวอร์ชัน แล้ว ตอบอย่างกระชับพร้อมลิงก์หรือข้อมูลอ้างอิงที่แม่นยำ โดยห้ามแก้โค้ด
• ตัวอย่างพรอมป์ต์ใช้งาน: "รีวิวสาขานี้เทียบกับ main โดยให้ pr_explorer แมปเส้นทางโค้ดที่ได้รับผลกระทบ reviewer หา risk ที่มีนัยสำคัญ และ docs_researcher ตรวจสอบ framework API ที่แพตช์นี้พึ่งพา"

การประมวลผลแบบแบตช์ด้วย CSV: spawn_agents_on_csv (ทดลอง)

• เป็น ฟีเจอร์ทดลอง ที่อาจมีการเปลี่ยนแปลงในอนาคต
• เมื่อมีงานลักษณะคล้ายกันจำนวนมาก สามารถใช้ หนึ่งแถวของ CSV เป็นหนึ่งหน่วยงาน แล้วสร้าง worker subagent แบบเป็นชุดได้
• Codex จะอ่าน CSV สร้าง worker agent ต่อหนึ่งแถว รอจนทั้งแบตช์เสร็จ แล้ว ส่งออกผลลัพธ์เป็น CSV
• กรณีใช้งานที่เหมาะสม:
  • รีวิว ไฟล์ แพ็กเกจ หรือบริการทีละหนึ่งรายการต่อแถว
  • ตรวจสอบ รายการ incident, PR หรือเป้าหมายการ migration
  • สร้างสรุปแบบมีโครงสร้าง สำหรับอินพุตจำนวนมากที่มีลักษณะคล้ายกัน
• พารามิเตอร์อินพุตของเครื่องมือ: csv_path (CSV ต้นทาง), instruction (เทมเพลตพรอมป์ต์ของ worker ที่ใช้ placeholder {column_name}), id_column (ID รายการแบบคงที่), output_schema (รูปแบบ JSON แบบตายตัว), output_csv_path, max_concurrency, max_runtime_seconds
• แต่ละ worker ต้องเรียก report_agent_job_result ให้ครบหนึ่งครั้งพอดี และหากจบงานโดยไม่รายงานผล แถวนั้นจะถูกระบุเป็นข้อผิดพลาด
• เมื่อรันด้วย codex exec ระหว่างประมวลผลแบตช์ จะมี การอัปเดตสถานะแบบบรรทัดเดียว แสดงบน stderr
• CSV ที่ส่งออกจะมีข้อมูลแถวต้นฉบับพร้อม เมทาดาทา เช่น job_id, item_id, status, last_error, result_json
• การตั้งค่า runtime ที่เกี่ยวข้อง: agents.max_threads (จำนวนเธรดพร้อมกันสูงสุด), agents.job_max_runtime_seconds (timeout ต่อ worker โดย max_runtime_seconds ต่อการเรียกจะมีลำดับความสำคัญสูงกว่า), sqlite_home (พาธจัดเก็บสถานะ SQLite ที่ใช้สำหรับงานของเอเจนต์และผลลัพธ์การส่งออก)

ตัวอย่าง 2: แพตเทิร์นการดีบักฟรอนต์เอนด์แบบบูรณาการ

• เป็นแพตเทิร์นที่เหมาะกับบั๊กแบบบูรณาการที่คร่อมทั้ง UI regression, browser flow ที่ไม่เสถียร, และทั้งโค้ดแอปพลิเคชันกับผลิตภัณฑ์ที่กำลังรันอยู่
• การจัดชุดคัสตอมเอเจนต์ 3 ตัว:
  • code_mapper: เอเจนต์สำรวจแบบอ่านอย่างเดียว ที่ค้นหาเส้นทางโค้ดฝั่งฟรอนต์เอนด์และแบ็กเอนด์ที่เกี่ยวข้อง (โมเดล: gpt-5.3-codex-spark, reasoning effort: medium)
  • browser_debugger: UI debugger ที่ใช้เครื่องมือเบราว์เซอร์เพื่อทำซ้ำปัญหาและ จับหลักฐาน (โมเดล: gpt-5.4, reasoning effort: high, sandbox: workspace-write)
    • ใช้ เครื่องมือเบราว์เซอร์ สำหรับภาพหน้าจอ เอาต์พุตคอนโซล และหลักฐานเครือข่าย โดยห้ามแก้ไขโค้ดแอปพลิเคชัน
    • เชื่อมต่อกับ Chrome DevTools MCP server (http://localhost:3000/mcp, startup_timeout_sec: 20)
  • ui_fixer: เอเจนต์เน้นการลงมือแก้ไข ที่รับผิดชอบการแก้แบบเล็กและตรงจุดหลังจากระบุปัญหาได้แล้ว (โมเดล: gpt-5.3-codex-spark, reasoning effort: medium)
    • ดำเนินการแก้ไขที่เล็กที่สุดเท่าที่สมเหตุสมผล ไม่แตะไฟล์ที่ไม่เกี่ยวข้อง และ ตรวจสอบเฉพาะพฤติกรรมที่เปลี่ยนไป
• ตัวอย่างพรอมป์ต์ใช้งาน: "ตรวจสอบว่าทำไม settings modal ถึงบันทึกไม่สำเร็จ โดยให้ browser_debugger ทำซ้ำปัญหา code_mapper ติดตามเส้นทางโค้ดที่เกี่ยวข้อง และ ui_fixer ลงมือแก้ไขให้น้อยที่สุด หลังระบุ failure mode ได้แล้ว"

[kgcrom]

ถ้า agent ใช้แค่โมเดล GPT-5.1-Codex-Mini
พอเพิ่มพรอมป์ต์ด้านล่างใน Custom instructions ของ Codex App
agent ก็ทำงานด้วย GPT-5.3-Codex-Spark ได้ครับ

"- when it spawns agents, use models "GPT-5.3-Codex-Spark" or higher."

หรือจะลองระบุโมเดลตอนสร้าง agent ก็สนุกดี
และผมชอบที่ใน Codex App แสดงผลเป็นโครงสร้างโฟลเดอร์ย่อยด้วยครับ

[hmmhmmhm]

ตอน KakaoTalk จัดโปรลดราคาสุดแรง ผมก็รีบกระโดดขึ้นขบวนเลย แล้วใช้งานได้คุ้มมากจริง ๆ 555

[shakespeares]

เสียดายจัง หรือว่าจะไม่จัดงานอีกแล้วนะ ฮือฮือ

[xguru]

Codex ก็ช่วยทำรีโมตคอนโทรลให้ไว ๆ หน่อยครับ!