สถานะการใช้งานและการเปรียบเทียบเวิร์กโฟลว์ของ coding agent ณ เดือนกุมภาพันธ์ 2026

• เกณฑ์หลักในการเลือก coding agent กำลังเปลี่ยนจาก ประสิทธิภาพของโมเดลเพียงอย่างเดียว ไปเป็น เวลาที่ผู้ใช้มีให้และระยะเวลาที่เอเจนต์ทำงานได้อย่างอัตโนมัติ โดยใช้ Claude Code และ Codex ควบคู่กันตามสถานการณ์
• Opus เด่นด้าน การจัดการ context window และการใช้เครื่องมือ และเหมาะกับการสำรวจและวางแผนอย่างรวดเร็วเพราะสามารถรัน sub-agent หลายตัวพร้อมกันได้
• Codex เหนือกว่า Opus ในด้าน ความถูกต้องของโค้ด แต่มีข้อเสียคือประมวลผลช้าเพราะยังขาดการมอบหมายงานข้าม context window
• ผ่านการทำ skill automation ได้ค่อย ๆ สร้างลูป plan → implement → review → bug fix แบบเป็นขั้นตอน และแนวทางที่มีประสิทธิภาพคือ ค่อย ๆ ทำงานมือที่เกิดซ้ำให้เป็นอัตโนมัติ แทนการออกแบบทั้งหมดตั้งแต่แรก
• ในที่สุดกำลังมุ่งไปสู่อนาคตที่เอเจนต์ทำงานได้อย่างอัตโนมัติ 24/7 แต่ ข้อจำกัดของ context window และ ความต้านทานต่อ prompt injection ยังคงเป็นอุปสรรคหลัก

---

แบ็กกราวด์

• เคยทำงานเกี่ยวกับ Codex เวอร์ชันเว็บ และออกจาก OpenAI ในเดือนกรกฎาคม 2025
• เรียบเรียงบทความนี้ขึ้นเพื่อสรุปกลยุทธ์การใช้งาน coding agent อย่างละเอียด หลังจาก YC Lightcone Podcast
• เกณฑ์การเลือกเอเจนต์กำลังเปลี่ยนจากประสิทธิภาพของโมเดลไปสู่ ระยะเวลาการทำงานอัตโนมัติและความสำคัญของงาน มากขึ้น
• สมัครใช้ Claude Max, ChatGPT Pro และ Cursor Pro+ ทั้งหมด และมองว่าคุ้มค่ามากเมื่อเทียบกับผลผลิตที่ได้

หลักการสำคัญ: เข้าใจ context

• ถ้าจะใช้ coding agent ให้เก่ง ต้องเข้าใจ context ให้ดี
• ไม่ว่าเอเจนต์จะเก่งแค่ไหน สุดท้ายก็ยังทำ next token prediction และทุก token ต้องอยู่ภายใน context window
• หลักสำคัญที่ตามมาจากสิ่งนี้:
  • ต้อง แบ่งปัญหาให้มีขนาดเหมาะสม กับ context window เพราะถ้าปัญหาใหญ่เกินไปจะใช้เวลานานและผลลัพธ์ก็แย่ลง
  • Compaction เป็นเทคนิคที่มีการสูญเสียข้อมูล โดยเอเจนต์จะต้องตัดสินใจเองว่าจะเก็บหรือจะละข้อมูลไหน และยิ่ง compaction มาก ประสิทธิภาพก็มักลดลง
  • หาก ทำให้ context อยู่ภายนอกบทสนทนาไว้ใน filesystem เช่นในเอกสารแผนงาน เอเจนต์จะสามารถเลือกอ่านและจดจำเฉพาะส่วนที่ต้องใช้ได้ โดยไม่ต้องเติม context ทั้งหมดในบทสนทนา
  • สิ่งสำคัญคือ อยู่ใน 'ครึ่งที่ฉลาด' ของ context window เพราะโมเดลฝึกกับ context ที่สั้นกว่ามาได้ดีกว่า จึงมักให้ผลลัพธ์ดีกว่าเมื่อหน้าต่างยังไม่แน่นเกินไป — Dex Horthy เรียกแนวคิดนี้ว่าให้อยู่พ้น 'dumb zone'
  • หากเอเจนต์พลาดไฟล์หรือแพ็กเกจที่เกี่ยวข้อง มันอาจเดินไปในทิศทางที่ไม่คาดคิดได้ ดังนั้น 'progressive disclosure' ของโครงสร้าง codebase และสถาปัตยกรรมจึงช่วยได้ — OpenAI เคยเผยแพร่บล็อกโพสต์เกี่ยวกับ วิธีจัดโครงสร้างไฟล์ Markdown หลายไฟล์
• ประสิทธิภาพและความเร็วของโมเดลไม่ได้ขึ้นอยู่แค่ความสามารถล้วนของตัวโมเดล แต่ยังขึ้นอยู่กับ ความสามารถในการจัดการหลาย context window และการมอบหมายงานให้ sub-agent/ทีม ด้วย

Opus: การจัดการ context, การใช้เครื่องมือ, และความรู้สึกแบบมนุษย์

• ใช้ Claude Code เป็นเครื่องมือหลักสำหรับ การวางแผน การประสานงานในเทอร์มินัล และการจัดการงาน git/GitHub
• Opus ถูกฝึกมาให้ ทำงานข้ามหลาย context window ได้อย่างมีประสิทธิภาพมาก ทำให้เมื่อใช้ Claude Code จะรู้สึกว่าเร็วกว่าตอนใช้ Codex
• มักเห็น Opus รัน sub-agent หลายตัวพร้อมกัน เช่นการเรียก Explore หรือ Task
  • เครื่องมือ Explore ใช้ Haiku จึงประมวลผล token ปริมาณมากได้รวดเร็วและส่ง context ที่เกี่ยวข้องกลับไปให้ Opus
• ยังถูกฝึกมาอย่างดีในการใช้เครื่องมือภายในเครื่อง เช่น gh, git และ MCP server หลายแบบ
  • สามารถตรวจสอบบั๊กผ่านส่วนขยาย /chrome ได้ แต่บางครั้งอาจช้าและไม่เสถียร
• โมเดลสิทธิ์การเข้าถึง ของ Claude Code เข้าใจง่ายกว่า Codex — โมเดล Codex มีแนวโน้มจะเขียนสคริปต์คำสั่งใน bash ทำให้การ whitelist เครื่องมือ CLI แบบรายตัวทำได้ยาก
• จุดเด่น UX จุกจิกของ Claude Code: อัปเดตชื่อหน้าต่างเทอร์มินัลให้สัมพันธ์กับงาน, แสดง PR ปัจจุบันในแถบสถานะ, และมีข้อความสถานะเล็ก ๆ
• Opus เก่งกว่า Codex ในการสร้าง คำอธิบาย PR ที่มนุษย์อ่านเข้าใจง่าย และแผนภาพสถาปัตยกรรมแบบละเอียด
• เวลาขอให้ช่วยอธิบายโครงสร้างโค้ด มักจะใช้ Claude Code
• Opus มีความ 'สร้างสรรค์' มากกว่าในการวางแผน โดยมักเสนอส่วนที่ผู้ใช้อาจไม่ได้เอ่ยถึง หรือชี้จุดที่ยังคลุมเครือ

Codex: ความถูกต้องของโค้ดที่เหนือชั้น

• จุดที่ Codex โดดเด่นคือ ความถูกต้องของโค้ด (correctness) และนักพัฒนาคนอื่นที่ใช้โมเดลหนัก ๆ ก็เห็นตรงกัน
• เมื่อรันด้วย GPT-5.3-Codex-xhigh หรือ high โค้ดจาก Codex มีบั๊กน้อยกว่าอย่างชัดเจน
• ตัวอย่างข้อผิดพลาดที่ Opus ทำบ่อย:
  • React component ผ่าน unit test แต่ ลืมเพิ่มเข้าไปใน <App> ระดับบนสุด
  • มองไม่เห็น off-by-one error ที่ชัดเจน
  • พลาด dangling references หรือ race condition แบบละเอียดอ่อน
• เคยคิดอยู่นานว่าความต่างระหว่างสองโมเดลน้อยจนมองข้ามได้ แต่หลังจากเห็น PR มากพอผ่านการรีวิวอัตโนมัติของ Codex และ Cursor Bugbot ก็สรุปว่าโมเดลของ OpenAI มีคุณภาพด้านโค้ดที่ดีกว่า
  • หากอยาก A/B test เอง ให้ checkout branch แล้วเปรียบเทียบ /code-review ของ Claude Code กับ /review ของ Codex
• อย่างไรก็ตาม Codex ช้า — สาเหตุหลักคือยังขาดการมอบหมายงานข้าม context window และยังรู้สึกได้ว่า token latency สูงกว่า
  • ถ้าเปิดใช้ sub-agent support แบบทดลอง (/experimental toggle) ก็ใช้งานได้ แต่ยังไม่ลื่นเท่า Claude และยังขาดความสามารถด้าน parallelism
• ดังนั้นรูปแบบการใช้งานจริงคือ เริ่มด้วย Claude Code และเปิดค้างไว้ ก่อนจะ สลับไปใช้ Codex ในขั้นตอนเขียนโค้ดจริง

เครื่องมือและการตั้งค่าที่มีประโยชน์

• ตอนนี้กำลังทำงานบน greenfield codebase ซึ่งเล็กกว่าและใช้ token ได้มีประสิทธิภาพกว่ามากเมื่อเทียบกับ production codebase
• โครงสร้าง repo: ทุก repo มีโฟลเดอร์ plans/ สำหรับเก็บเอกสารแผนงานแบบมีหมายเลข, แยกบริการด้วยโฟลเดอร์ apps/, จัดการ TypeScript monorepo ด้วย turborepo, และใช้ bun เพื่อติดตั้งได้เร็ว
• Ghostty: เทอร์มินัลของ Mitchellh ที่เร็ว เป็น native และพัฒนาอย่างต่อเนื่อง — เมื่อก่อนเคยใช้ tmux เพื่อรัน Claude/Codex หลายอินสแตนซ์ แต่ตอนนี้ใช้หลาย pane ในแท็บเทอร์มินัลเดียวแทน
• Next.js บน Vercel, API ใช้ Cloudflare Durable Objects: โครงสร้างที่ pre-partition ฐานข้อมูลไว้ล่วงหน้า ปลุกขึ้นมาใช้งานได้ตามต้องการ และกังวลเรื่อง concurrent writes น้อย — เหมาะในมุมโครงสร้างพื้นฐานสำหรับยุคที่เอเจนต์ทำงานกับข้อมูลชิ้นเล็ก ๆ
  • Cloudflare กำลังขยายแนวทางนี้ต่อด้วยไลบรารี cloudflare/actors ที่รวม compute กับ storage ขนาดเล็กซึ่งอยู่ร่วมกัน
• Worktrees: เพราะโค้ดมีขนาดเบา จึงใช้ worktree แบบขนานได้ โดยแต่ละอันรัน bun install → bun run dev เพื่อตรวจสอบในเครื่อง — ใช้ skill worktree ที่คัดลอกแผนงาน ตัวแปรแวดล้อม และอัปเดตที่เกี่ยวข้อง ก่อนเริ่ม branch ใหม่
  • ก่อนยุค coding agent ส่วนใหญ่ใช้แค่ branch แต่การจับคู่ worktree กับ Claude Code มีประโยชน์มาก
• Plan, Implement, Review: แทบจะบังคับให้โมเดล เริ่มจากการวางแผนก่อนเสมอ — 1) เพื่อทำให้ context อยู่ภายนอกเกินกว่าหนึ่ง context window 2) เพื่อให้สามารถรีวิวหรือถามต่อจากสิ่งที่ทำไว้ได้ — ถ้าเอเจนต์หยุด ก็สามารถกลับมาทำตามแผนต่อใน context window ใหม่ได้
• Preview deploys: ทุก branch จะได้ Web + API deployment ใหม่ ทำให้เหมาะกับการทำงานขนานและทดสอบอย่างรวดเร็ว — ขาดฟีเจอร์นี้ไปจะทำงานยากมาก
• Cursor Bugbot และ Codex Code Review: ใช้เพื่อทำความเข้าใจโค้ดในระดับสถาปัตยกรรมและ spot check แต่ตอนนี้เริ่ม ไม่ได้อ่านทุกบรรทัดของทุก PR แล้ว — เอเจนต์เก่งกว่ามากในการหาบั๊กที่ละเอียดอ่อน
  • เคยใช้ทั้ง Claude Code, Cursor Bugbot และ Codex พร้อมกัน แต่เพราะ Claude Code จับประเด็นที่มีสาระไม่ค่อยได้ จึงให้ Cursor เป็นตัวเลือกหลัก และมองว่า Codex ก็ให้ผลลัพธ์ดีเช่นกัน

Skills: หัวใจของระบบอัตโนมัติ

• นิยาม skill หลายรายการพร้อม AGENTS.md/CLAUDE.md ที่ใช้ร่วมกันไว้ใน repo ชื่อ claudefiles
• กฎในการเพิ่ม skill: จะไม่รีบเพิ่ม แต่จะเพิ่ม หลังจากทำซ้ำหลายครั้งและเวิร์กโฟลว์นิ่งแล้วเท่านั้น
• AGENTS/CLAUDE.md มีประโยชน์ต่อการกำหนดทิศทางโดยรวมของโมเดล ส่วน skill มีสองเป้าหมาย:
  1. เชื่อมเวิร์กโฟลว์และทำให้เป็นอัตโนมัติ — สร้าง skill แยกสำหรับ plan → implement ทีละขั้น → review แล้วทำ meta skill ที่รันต่อกันตามลำดับ
  2. แบ่ง context window — เมื่อเรียก skill ใน Claude Code แล้วตั้ง context: fork ก็สามารถรันใน context window ใหม่ได้ แยก 'master orchestrator' ออกจาก sub-agent
• skill ประหยัด context มาก ต่างจากการเรียก MCP ที่กินหลายพัน token โดยทั่วไป skill ใช้เพียง ~50-100 token

วิวัฒนาการของ skill automation

• ช่วงแรกสนใจแนวคิด skill marketplace (ติดตั้ง skill สำหรับ frontend design, security check, architecture review ฯลฯ) แต่เมื่อทำงานจริงไปเรื่อย ๆ ก็ เลิกใช้ skill ที่คนอื่นเขียนไว้เกือบทั้งหมด
• หลังจากนั้นเปลี่ยนมาเป็นแนวทางที่ทำงานด้วยมือก่อน แล้วค่อยคิดว่าจะทำให้เป็นอัตโนมัติอย่างไร
• ลำดับการพัฒนาของ skill:
  • /commit: แทนที่จะบอกให้โมเดล commit และ push ด้วยหลายวิธี ก็รวมไว้ใน skill เดียว — ยืมมาจาก Claude Code โดยตรง
  • /worktree: ให้เอเจนต์ทำงานใน worktree แยก โดยสร้าง worktree ใหม่จากหมายเลขแผนงาน (เช่น 00034-add-user-auth)
  • /implement: รวมงานที่ต้องทำซ้ำคือรันตามขั้นของแผน แล้วตามด้วย /commit ไว้ใน skill เดียว
  • /implement-all: ผูก path ของ worktree ปัจจุบันเข้ากับหมายเลขแผน เพื่อให้ implement ทุกขั้นได้อัตโนมัติ — เมื่อต้องรันตอนกลางคืนก็ใช้ /ralph-loop เพื่อทำต่อจนกว่าทุกขั้นจะเสร็จ และใช้ /codex-review ในเครื่องเพื่อสร้างกระบวนการ codex --review
  • /address-bugs: ค้นหาคอมเมนต์จาก Cursor + Codex ผ่าน GitHub API หลัง commit ล่าสุด แล้วพยายามตรวจสอบและแก้บั๊ก
  • /pr-pass: รันเมื่อ /implement-all จบลง โดยทำ 1) push ไปยัง remote 2) รอให้ CI ผ่านทั้งหมด 3) รัน /address-bugs แล้วถ้าจำเป็นก็วนกลับไปทำข้อ 1 อีกครั้ง
  • /focus: ตรวจดูไดเรกทอรี plans, PR ที่ยังไม่เสร็จ, และ worktree เพื่อรีเฟรชความจำและช่วยติดตามงาน
• ถ้าพยายามสร้างกระบวนการนี้ ให้ครบตั้งแต่แรกคงไม่สำเร็จ และหัวใจสำคัญคือค่อย ๆ สร้างขึ้นจากการมองเห็นจุดเล็ก ๆ ที่ทำให้เป็นอัตโนมัติได้เมื่อเวลาผ่านไป

เครื่องมืออื่น ๆ

• เพิ่งลองใช้ Codex App และประทับใจกับรายละเอียดและสัมผัสเล็ก ๆ หลายอย่าง — แต่ยังไม่ย้ายไปทั้งหมดเพราะชอบความยืดหยุ่นของเครื่องมือ CLI มากกว่า
• เคยลอง Cowork ด้วย แต่ทำให้ใช้งานได้อย่างถูกต้องค่อนข้างยาก และทั้งสองกรณีนี้ โมเดลการ sandboxing สร้างความแตกต่างอย่างมาก
• บางครั้งยังใช้เว็บอินเทอร์เฟซสำหรับงานแบบ asynchronous แต่พึ่งพา CLI มากขึ้นเรื่อย ๆ — ต่างจากเมื่อ 6 เดือนก่อนที่ส่วนใหญ่ใช้ Cursor และ agent/extension ในตัว
• ใช้ pencil.dev สำหรับงาน frontend UI — โมเดลการ deploy ที่ shell out ไปยัง Claude Code ในเครื่องเพื่อใช้ subscription เดิมซ้ำเป็นแนวคิดที่น่าสนใจ
• รู้สึกว่าต้องการ issue tracker ที่เป็นระบบมากขึ้น และมองว่า Dex ของ David Cramer กับ beads ของ Steve Yegge มีอนาคต แต่ตอนนี้ยังรู้สึกว่าซับซ้อนเกินความจำเป็น
• ตอนนี้ยังไม่ได้ใช้ automated e2e MCP อย่าง Playwright

คำแนะนำต่อแล็บต่าง ๆ

• ข้อเสนอแนะต่อ Anthropic

  • โมเดล: Opus ให้ความรู้สึกเหมือนมนุษย์ ใช้เครื่องมือวิศวกรรมเก่ง แบ่ง context เก่ง และเสนอสิ่งที่ "ผู้ใช้อาจลืมไป" ได้ดี แต่ยังขาดความถูกต้องของโค้ด — อยากเห็นโหมด 'Opus Strict' ที่เสริม RL ให้โมเดลพื้นฐานเพื่อยกระดับประสิทธิภาพ
    • แม้จะเริ่มจาก Opus แต่ให้ Codex เป็นคนเขียนโค้ด และถ้ามีข้อจำกัดด้านงบประมาณก็จะเลือก Codex
  • product harness: แทบไม่มีอะไรให้ติ และไอเดียของ Boris กับ Cat ยอดเยี่ยมมาก
    • อยากให้มีการยอมรับมาตรฐาน agent skills — การทำ symlink ไดเรกทอรีข้าม CLI หลายตัวนั้นไม่สะดวก
    • อยากให้เปิดเผย รูปแบบเอาต์พุตของ --stream-json — สนใจที่จะรัน Claude Code ใน sandbox แทนผู้ใช้ แต่กังวลเรื่องการเปลี่ยน format และการตั้งค่า path ที่ยุ่งยากกว่า CLI ตัวอื่น (Codex, Cursor, Gemini)

• ข้อเสนอแนะต่อ OpenAI

  • โมเดล: สิ่งที่ควรปรับปรุงเป็นอันดับแรกคือ การแบ่งงานข้าม context window และการมอบหมายให้ sub-agent — แนวคิดแบบ "ทำมากกว่าที่ขอ" ที่ Opus ทำได้ดีในขั้นวางแผนก็น่าจะมีประโยชน์
  • ข้อเสนอแนะเชิงรายละเอียดต่อ product harness:
    • โมเดล sandboxing เข้าใจยากกว่า เมื่อเทียบกับ Claude Code — เพราะโมเดลพยายามเขียนสคริปต์ ทำให้ต้องขออนุมัติบ่อย และน่ากังวลเมื่อต้องใช้โหมด --yolo
    • อยากให้มี คู่มือผู้ใช้ที่ฝังอยู่ใน CLI แบบเดียวกับ Claude Code — เพื่อให้ถามได้ว่า skill อยู่ที่ไหน, รองรับ field อะไร, ตั้งค่า sandboxing model อย่างไร
    • อยากให้เปลี่ยน /review จากคำสั่งที่แพ็กมาเป็นพิเศษให้เป็น skill ทั่วไป — เพื่อให้โมเดลเรียกใช้แบบไดนามิกได้
    • อยากให้ เปลี่ยนชื่อแท็บเทอร์มินัลตามงานที่ทำ ระหว่างรัน — ไม่เช่นนั้นจะสับสนเมื่อมีแท็บ codex หลายสิบแท็บ
    • ต้องการ การฝึกเฉพาะทางสำหรับคำอธิบาย PR และคำอธิบาย commit — บุคลิกที่กระชับของ Codex นั้นดีอยู่แล้ว แต่ยังต้องขยายเรื่องการอธิบาย
    • อยากให้รองรับ context: fork ในการนิยาม skill
    • อยากให้ลิงก์ใน pane คลิกได้แม้ข้อความขึ้นบรรทัดใหม่
    • อยากให้แสดง ชื่อ worktree/PR/branch ปัจจุบัน ที่ด้านล่างของ status bar

มุมมองในอนาคต

• อ้างถึงโพสต์ Gas Town ของ Steve Yegge — ที่เสนอว่าควรใช้ token ให้เต็มตลอดเวลา ให้ worker pool ทำงาน 24/7 และคาดหวังได้ว่าจะวางแผนแล้วทิ้งไปจำนวนมาก
  • แม้จะยังถกเถียงได้ว่าคำอธิบายเปรียบเทียบนั้นแม่นยำหรือไม่ แต่ในเชิงทิศทางแล้วมองว่า ถูกต้องอย่างยิ่ง
• อนาคตในอุดมคติคือ notebook หรือ cloud sandbox จะ ประมวลผลไอเดียอย่างต่อเนื่องอยู่เบื้องหลัง และผู้ใช้มีหน้าที่คอยปรับทิศทาง ทำวิจัย หรือรีวิวผลลัพธ์
  • การทำงานร่วมกับ coding agent ให้ความรู้สึกคล้าย บทบาท engineering manager แต่ไม่ต้องกังวลเรื่องแรงจูงใจหรือบุคลิกของเอเจนต์
• ตอนนี้เข้าใกล้อนาคตแบบนั้นมากพอสมควรแล้ว — แม้ใน Twitter จะมีการโฆษณาเกินจริง แต่ในทางปฏิบัติก็มีรูทีน สั่งงาน 3-4 งานใน Codex ก่อนนอน แล้วค่อยมาตรวจตอนเช้า
  • อย่างไรก็ตาม ยังไม่ถึงระดับที่จะ ปล่อยเอเจนต์ทำงาน 24/7 ได้จริง
• มี อุปสรรคสองอย่าง ที่ขวางความก้าวหน้าครั้งใหญ่กว่าเดิม:
  1. ขนาด/การประสาน context window — เอเจนต์ไม่สามารถบีบอัดหรือรีไซเคิล context window เดิมไปเรื่อย ๆ ได้ไม่รู้จบ จึงต้องมี harness หรือกลไกการมอบหมายที่ฉลาดกว่า
  2. ความต้านทานต่อ prompt injection — เอเจนต์อาจส่งคำขออนุมัติภายในไม่กี่นาที ทำให้ยังเชื่อถือโหมด --yolo ไม่ได้ แม้จะยังมีบางชุดของสิทธิ์/โดเมนที่ยอมรับได้
• สำหรับปัญหาแรก Cursor กำลังผลักขีดจำกัดของ agent swarm ข้ามหลาย context window ส่วนปัญหาที่สองเป็นพื้นที่วิจัยที่ยังเคลื่อนไหวอย่างมาก
  • การรันใน sandbox ยังเป็นทางอ้อมที่ดีที่สุดในตอนนี้ แต่การตั้งค่ายังยุ่งยาก และถ้าเอเจนต์ เข้าถึงอินเทอร์เน็ตแบบเปิดและข้อมูลสิทธิพิเศษพร้อมกัน ก็จะเสี่ยงต่อสิ่งที่ Simon Willison เรียกว่า 'Lethal Trifecta'
• สำหรับวิศวกรเดี่ยว ตอนนี้สิ่งที่กลายเป็นคอขวดคือ ไอเดียที่ถูกต้อง อยู่แล้ว และต่อไป ไอเดีย สถาปัตยกรรม และการจัดลำดับโปรเจกต์ จะยิ่งกลายเป็นข้อจำกัดสำคัญในการสร้างผลิตภัณฑ์ที่ยอดเยี่ยม

[yangeok]

สถาปัตยกรรมด้วยเหรอ..?

[wegaia]

ถ้า Codex มีแค่ฟีเจอร์ซับเอเจนต์ก็น่าจะย้ายไปแล้วนะ
แต่นี่เหมือนไม่ได้สนใจเลยหรือไง..

[tested]

https://developers.openai.com/codex/multi-agent
แม้จะยังอยู่ในขั้นทดลอง แต่ก็ดูเหมือนว่ากำลังดำเนินการอยู่ครับ

[kgcrom]

ใน codex cli
ถ้าพิมพ์คำสั่ง /experimental จะมีฟีเจอร์ทดลองที่ให้ใช้ Multi-agents อยู่ครับ
› [x] Multi-agents Ask Codex to spawn multiple agents to parallelize the work and win in efficiency.

ไม่แน่ใจว่าจะเป็นแนวเดียวกับซับเอเจนต์ที่คุณพูดถึงไหม แต่ลองดูได้ครับ