การทำงาน Claude Code แบบขนาน: worktree, เอเจนต์ และ Workflows

เอกสารประกอบเชิงปฏิบัติเกี่ยวกับการทำงานกับเอเจนต์พร้อมกัน: เอกสารของ Ailoot.

คู่มือนี้รวบรวมประสบการณ์จริงและแผนที่ว่าเครื่องมือเหมาะกับงานแบบใด มีทั้งองค์ประกอบอย่างเป็นทางการของ Claude Code ทั้ง 4 แบบ แผนที่การใช้งาน และกรอบคิดต้านกระแสเกินจริงเพื่อประเมินว่า vibe coder ต้องใช้เอเจนต์พร้อมกันกี่ตัว ตัวเลขและคำพูดทั้งหมดเชื่อมโยงไปยังแหล่งข้อมูลปฐมภูมิจาก Anthropic

multi-agent ใน Claude Code คืออะไร และทำไมจึงไม่ใช่ “เอเจนต์ 1000 ตัว”#

การตั้งค่าแบบ multi-agent คือการแบ่งงานหนึ่งออกเป็นหลายสายงานอิสระ แต่ละสายรับผิดชอบส่วนของตัวเองและส่งผลลัพธ์กลับมา ตัวอย่างง่าย ๆ คือเขียน frontend ในหน้าต่าง Claude Code หนึ่ง แล้วเขียน backend ในอีกหน้าต่างบนเครื่องเดียวกัน โดยทั้งคู่ใช้ repository git ร่วมกัน แค่นี้ก็เป็น multi-agent แล้ว แม้คำว่า “orchestration” จะดูเกินจำเป็นก็ตาม

ตัวอย่างที่ซับซ้อนขึ้น: ภายในเซสชัน Claude Code เดียว คุณเปิด subagents 5 ตัวที่มีบทบาทต่างกัน (นักพัฒนา frontend, นักพัฒนา backend, ผู้ตรวจสอบความปลอดภัย, ผู้ทดสอบ และผู้จัดทำเอกสาร) แล้วแต่ละตัวส่งส่วนของผลลัพธ์กลับมายังบทสนทนาร่วม นี่คือแนวทาง multi-agent แบบเดียวกัน เพียงแต่มีจุดควบคุมจุดเดียว

ซับซ้อนยิ่งขึ้นไปอีก: คุณบอก Claude ว่า “ตรวจสอบความปลอดภัยรายสัปดาห์ให้ครบทั้ง 500 ไฟล์ในโปรเจกต์ของฉัน” แล้ว Claude เขียนสคริปต์ orchestrator ด้วย JavaScript runtime เปิดเอเจนต์หลายสิบตัวในเบื้องหลัง แต่ละตัวตรวจสอบส่วนของตัวเอง จากนั้นเอเจนต์อิสระก็ตรวจสอบข้อค้นพบของกันและกัน แล้วคุณจะได้รับรายงานเดียว นี่คือ Dynamic Workflows ซึ่ง Anthropic เปิดตัวเมื่อวันที่ 28 พฤษภาคม 2026 ดูรายละเอียดฟีเจอร์ได้ในคู่มือ Dynamic Workflows ฉบับแยก

ความแตกต่างระหว่างสามสถานการณ์นี้ไม่ได้อยู่ที่จำนวนเอเจนต์ แต่อยู่ที่ ใครเป็นคนตัดสินใจว่าเอเจนต์ตัวถัดไปจะทำอะไร ในสถานการณ์แรกคือคุณ สถานการณ์ที่สอง Claude ตัดสินใจไปตามความคืบหน้าของบทสนทนา ส่วนสถานการณ์ที่สามคือสคริปต์ JavaScript ที่ Claude เขียน

ที่จริงแล้ว “เอเจนต์ 1000 ตัว” เป็นตัวเลขจริง นี่คือขีดจำกัดสูงสุดของ Dynamic Workflow หนึ่งครั้งใน Claude Code เอกสารอย่างเป็นทางการของ Anthropic ระบุว่า:

กล่าวอีกอย่างคือ นี่เป็นมาตรการป้องกันทางเทคนิคเพื่อไม่ให้การทำงานหลุดควบคุม ไม่ใช่ปริมาณงานที่แนะนำ ในทางปฏิบัติ งาน 95% ใช้สายงานขนาน 2–8 สายก็จัดการได้ หากคุณวางแผนจะใช้มากกว่านั้น ให้ถามตัวเองก่อนว่าพวกเขาจะทำอะไร

องค์ประกอบ Claude Code 4 แบบ: subagents, skills, agent teams และ workflows#

Claude Code มีองค์ประกอบอย่างเป็นทางการ 4 แบบสำหรับแบ่งงานหนึ่งให้เอเจนต์หลายตัว Anthropic รวบรวมทั้งหมดไว้ในตารางเปรียบเทียบในเอกสาร Dynamic Workflows ต่อไปนี้คือการเปรียบเทียบด้วยภาษาง่าย ๆ:

องค์ประกอบแต่ละแบบแก้ปัญหาคนละอย่าง Subagents เหมาะกับการมอบหมายงานตรวจสอบ 2–3 อย่างภายในงานเดียว Skills เหมาะเมื่อมีคำสั่งสำเร็จรูปที่ Claude ควรทำตาม (เช่น “ตรวจ PR ตาม checklist นี้”) Agent teams เหมาะเมื่อส่วนต่าง ๆ ของผลิตภัณฑ์อยู่ในหน้าต่างคนละบานและต้องมีผู้ประสานงานหนึ่งคน ส่วน workflows เหมาะเมื่องานใหญ่เกินกว่าจะทำใน context window เดียว

อ่านรายละเอียด subagents ได้ในคู่มือ Claude Code Subagents 2026 ส่วน decision tree สำหรับเลือก “เครื่องมือที่เหมาะกับงานนั้น” อยู่ในคู่มือ Skills, Subagents, MCP, Plugins คู่มือนี้ว่าด้วยการประกอบสิ่งเหล่านี้เป็นการตั้งค่า multi-agent บน git worktree

ระดับ 1: subagents ในเซสชันเดียว — จุดเริ่มต้นที่ง่ายที่สุด#

Subagent เป็นวิธีที่ง่ายที่สุดในการแบ่งงาน บทสนทนาหลักทำหน้าที่เป็นผู้ประสานงาน ส่วน subagents เป็นผู้ช่วยชั่วคราวที่เอเจนต์หลักเปิดใช้ระหว่างทำงาน

ตัวอย่างเฉพาะจากโปรเจกต์ที่กล่าวถึง หลังเขียนร่างแรกของคู่มือแล้ว จะจัดการตรวจทานแบบนี้: Claude ได้รับคำขอว่า “เปิด subagents 6 ตัวพร้อมกัน — ตัวแรกตรวจหาเครื่องหมายของ AI ตัวที่สองตรวจศัพท์กฎหมาย ตัวที่สามตรวจน้ำเสียงและสำนวน ตัวที่สี่ตรวจข้อเท็จจริงด้วย WebFetch ตัวที่ห้าตรวจโครงสร้าง SEO และตัวที่หกตรวจความถูกต้องของลิงก์ภายใน” แต่ละตัวส่งรายงานกลับมา แล้วจึงนำการแก้ไขไปใช้

ในทางเทคนิค ทำได้ด้วยไฟล์ใน .claude/agents/[subagent-name].md ที่อธิบายบทบาทและเครื่องมือ การเรียกใช้ทำผ่านเครื่องมือ Agent ในบทสนทนาหลัก Claude ตัดสินใจว่าจะส่งคำขอไปยัง subagent เมื่อใด

เหมาะกับงานแบบใด งานที่ต้องตรวจสอบสิ่งเดียวกัน 3–7 ด้านพร้อมกัน (โค้ด ข้อความ งานออกแบบ) การตรวจสอบแต่ละอย่างเป็นอิสระต่อกัน และผลลัพธ์ใส่ใน context window หลักได้

เริ่มไม่เหมาะเมื่อใด หากมีไฟล์ 50+ ไฟล์ หรือแต่ละการตรวจสอบต้องใช้ context ของตัวเอง 50K โทเค็น หน้าต่างหลักจะเต็ม ต้องใช้ workflows หรือ agent teams

ความเสี่ยงหลัก Subagent แต่ละตัวใช้โทเค็นแยกกัน หากเปิด 6 ตัวในโปรเจกต์ที่มี 200 ไฟล์ แล้วแต่ละตัวอ่านทั้ง 200 ไฟล์ซ้ำ คุณจะจ่าย 6 เท่า ดังนั้นคุณต้องระบุให้ชัดว่า subagent ควรตรวจไฟล์ใด ดูรายละเอียดได้ในคู่มือโทเค็นใน Claude Code ถูกใช้ไปกับอะไร

ระดับ 2: git worktree — แยกไฟล์ระหว่างเซสชันที่ทำงานพร้อมกัน#

เมื่อ subagents ไม่เพียงพอและคุณต้องการ Claude Code สองอินสแตนซ์เต็มรูปแบบในเทอร์มินัลคนละหน้าต่างเพื่อทำงานกับ repository เดียวกัน ปัญหาคลาสสิกจะเกิดขึ้น ทั้งคู่เริ่มแก้ไฟล์เดียวกัน ตัวหนึ่งบันทึกก่อน แล้วอีกตัวเขียนทับ ลูกค้าคนหนึ่งถามทีมสนับสนุนเมื่อสัปดาห์ที่แล้วว่า “5 ตัวเขียนทับงานของกันและกันพร้อมกัน”

วิธีแก้คือ git worktree ซึ่งเป็นฟีเจอร์ในตัวของ git ที่ช่วยให้มี working copy ของ repository เดียวกันได้หลายชุด แต่ละชุดอยู่บน branch ของตัวเองและใช้ repository .git ร่วมกัน มีต้นทางเดียว แต่ใช้ไดเรกทอรีคนละแห่งบนดิสก์ โดยไฟล์ไม่ทับซ้อนกัน กลไกนี้อธิบายอย่างละเอียดในคู่มือ Git worktree ใน Claude Code

คำสั่งตั้งค่าให้เสร็จในห้านาที:

# From the main project directory
cd ~/projects/my-app

# Create a worktree for feature/auth
git worktree add ../my-app-auth feature/auth

# Create a worktree for feature/billing
git worktree add ../my-app-billing feature/billing

# Open two terminal windows
cd ~/projects/my-app-auth && claude   # first Claude Code
cd ~/projects/my-app-billing && claude # second Claude Code

แต่ละ working copy อยู่บน branch ของตัวเอง Claude Code แต่ละอินสแตนซ์เขียนลงไดเรกทอรีของตัวเอง เมื่อทำงานเสร็จ ให้รัน git push จาก branch ของอินสแตนซ์นั้น แล้วรัน git worktree remove ../my-app-auth

สิ่งที่ควรรู้ Worktree ไม่ได้คัดลอก node_modules, .venv หรือไฟล์อื่น ๆ ใน .gitignore หากต้องใช้ dependencies แยกกัน (เช่น ต้องใช้ไลบรารีคนละเวอร์ชันในแต่ละ branch) ให้รัน npm install แยกในไดเรกทอรีใหม่หลัง worktree add

จำนวน worktrees ต่อคน จากแบบสำรวจทีมในปี 2026 จำนวนที่ใช้งานได้จริงสูงสุดคือ 4–8 worktrees พร้อมกันต่อนักพัฒนา ปัจจัยจำกัดไม่ใช่ Claude แต่เป็นความสามารถของคนในการตรวจและยอมรับผลลัพธ์ หากมี 10 worktrees ก็จะต้องรอการตรวจทาน

จากประสบการณ์ที่เล่าถึง คนมักใช้ worktrees พร้อมกัน 2–3 ชุด ชุดหลักหนึ่งชุดสำหรับงานที่กำลังทำ อีกชุดเป็นแผนสำรองสำหรับ hotfix เร่งด่วน และอีกชุดสำหรับทดลองฟีเจอร์ใหม่ที่ยังไม่แน่ใจ ไม่จำเป็นต้องมีมากกว่านี้

ระดับ 3: agent teams — หลายหน้าต่าง มีเอเจนต์นำทีมหนึ่งตัว#

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

วิธีนี้มีประโยชน์เมื่องานแบ่งเป็นสายงานใหญ่ 3–5 สาย แต่ละสายใช้เวลาหลายชั่วโมง (ย้ายโมดูลขนาดใหญ่ เขียนระบบย่อยใหม่ หรือตรวจสอบความปลอดภัยทั้งหมด) ในกรณีนั้น เอเจนต์นำเก็บแผนในไฟล์งานร่วมหนึ่งไฟล์ที่เป็น absolute path นอก worktree ผู้ทำงานอ่านเส้นทางเดียวกันและรายงานผล เฉพาะหัวหน้าปรับสถานะเพื่อเลี่ยงการเขียนไฟล์ประสานงานชนกัน

ในทางเทคนิค agent teams คือหลายหน้าต่างที่ทำงานบน git worktree โดยมีจุดวางแผนร่วมกันจุดเดียว ในทางปฏิบัติ คน 80% จัดการ agent teams ด้วยตัวเอง (ตามวิธี worktree ข้างต้น) และไม่ได้ใช้ “framework สำหรับทีม” โดยเฉพาะ ซึ่งก็ไม่เป็นไร

หากไม่แน่ใจว่าจำเป็นต้องใช้ framework หรือไม่ โอกาสสูงมากที่คุณไม่จำเป็น ใช้ worktree ด้วยตนเองและให้เอเจนต์นำทีมหนึ่งตัวอยู่ในไดเรกทอรีหลักก็พอ

ระดับ 4: Dynamic Workflows — Claude เขียนสคริปต์ orchestration ด้วย JS#

ทั้งสามระดับข้างต้นเก็บแผนไว้ในบทสนทนา ไม่ว่าจะอยู่ในหัวของเอเจนต์หลักหรือในรายการงานของเอเจนต์นำทีม Dynamic Workflows ย้ายแผน เข้าไปอยู่ในโค้ด Claude เขียนงานเป็นสคริปต์ JavaScript แล้ว runtime รันในสภาพแวดล้อมที่แยกไว้ ผลลัพธ์ระหว่างทางเก็บอยู่ในตัวแปรของสคริปต์แทนที่จะอยู่ใน context ของคุณ และเซสชันยังตอบสนองได้ขณะที่เอเจนต์ทำงานเบื้องหลัง

ตัวอย่างจากเอกสารทางการ คุณพูดว่า:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claude เขียนสคริปต์ JavaScript ด้วยตรรกะประมาณนี้: “นำไฟล์ทั้งหมดจาก src/routes/ มาแบ่งเป็นกลุ่ม กลุ่มละ 30 endpoints รันเอเจนต์หนึ่งตัวในแต่ละกลุ่มโดยใช้การตรวจสอบแบบเดียวกัน จากนั้นรันเอเจนต์ประเมินผลอิสระสองตัวเพื่อตรวจข้อค้นพบและรวบรวมเป็นรายงานฉบับสุดท้าย” สคริปต์จะทำงาน แล้วคุณจะได้ตารางผลลัพธ์และรายชื่อ endpoints ที่ควรตรวจสอบอย่างแน่นอน

เหมาะกับงานแบบใด

• ตรวจสอบทั้งโปรเจกต์เพื่อหาปัญหาอย่างเดียว (ความปลอดภัย typing หรือ API ที่เลิกใช้แล้ว)
• การย้ายระบบขนาดใหญ่ (500+ ไฟล์ที่อยู่ภายใต้กฎเดียวกัน)
• คำถามวิจัยที่ต้องตรวจสอบจากหลายมุมมองอิสระ (Anthropic ใช้วิธีนี้ในคำสั่ง /deep-research ที่มีมาให้)

ดูรายละเอียด Dynamic Workflows ข้อจำกัด และวิธีทำงานของ ultracode ได้ในคู่มือ Dynamic Workflows ใน Claude Code ฉบับแยก

เมื่อใดที่ไม่ควรใช้ เมื่องานเป็นเส้นตรงและชัดเจน ไม่จำเป็นต้องใช้ workflow กับงานอย่าง “ทำ component นี้ให้เสร็จ” workflow เหมาะเมื่องานแบ่งเป็นงานย่อยอิสระ 10+ งาน และต้องตรวจสอบข้ามกัน

ข้อจำกัดหลัก workflow ใช้โทเค็นมากกว่าเซสชันปกติอย่างมีนัยสำคัญ Anthropic แนะนำไว้ในเอกสาร ว่า:

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

Outcomes: rubric ของเกณฑ์และผู้ตรวจทานอิสระ#

สิ่งที่อันตรายที่สุดในการทำงานแบบ multi-agent คือ การเชื่อผลลัพธ์ของเอเจนต์ เอเจนต์แต่ละตัวส่งข้อความที่ดูเหมือนงานเสร็จแล้วกลับมา คำพูดดูน่าเชื่อถือ รายงานดูครบถ้วน งานย้ายระบบดูเสร็จแล้ว เมื่อมีเอเจนต์ตัวเดียว คุณตรวจเองได้ แต่เมื่อมี 10 ตัว คุณทำไม่ได้ เพราะไม่มีเวลา

Anthropic แก้ปัญหานี้ด้วย Outcomes ซึ่งเป็นฟีเจอร์ Managed Agents ที่เปิดตัวเมื่อวันที่ 6 พฤษภาคม 2026 แนวคิดเรียบง่าย: เพิ่มเอเจนต์ตัวที่สอง (grader) ให้กับเซสชัน โดยมีหน้าที่เพียงตรวจงานของเอเจนต์ตัวแรกเทียบกับ rubric ที่เข้มงวด

วิธีทำงานในทางเทคนิคคือ เขียน rubric เป็นเอกสาร Markdown ที่ระบุอย่างละเอียดว่า “เสร็จแล้ว” หมายถึงอะไร ต้องตรวจแหล่งข้อมูลใด และต้องใช้ป้ายกำกับใด แพลตฟอร์มจะสร้างเอเจนต์ grader โดยอัตโนมัติใน context window ใหม่ เอเจนต์นี้ได้รับเฉพาะ rubric และผลลัพธ์เท่านั้น ไม่มีอย่างอื่น หลังจากเอเจนต์หลัก (ผู้เขียน) พยายามแต่ละครั้ง grader จะอ่านผลลัพธ์ใหม่ แล้วอนุมัติหรือส่งรายการสิ่งที่ยังไม่ครบกลับมา

คำพูดจาก Anthropic Cookbook:

ตัวเลขผลกระทบจริง: หลังผสาน Outcomes เข้ากับ Claude Managed Agents อัตราการทำงานสำเร็จของบริษัท AI Harvey เพิ่มขึ้นประมาณ 6× ที่ Wisedocs (เอกสารทางการแพทย์) เวลาที่ใช้ตรวจเอกสารลดลง 50% ตัวเลขเหล่านี้มาจากประกาศฟีเจอร์อย่างเป็นทางการ

สิ่งที่สำคัญสำหรับ vibe coder มากกว่าองค์กร คือ Outcomes เป็นรูปแบบการทำงาน ไม่ใช่แค่ฟีเจอร์เฉพาะ คุณสร้างเอเจนต์ grader เองได้โดยระบุเกณฑ์แบบเดียวกันไว้ใน .claude/agents/grader.md แล้วขอให้เอเจนต์หลักเรียกใช้หลังจากพยายามแต่ละครั้ง วิธีนี้ใช้ได้กับการตั้งค่า multi-agent ทุกแบบ ไม่ใช่เฉพาะ Managed Agents

กฎสำคัญในการเขียน rubric จาก cookbook คือ ระบุสิ่งที่ตรวจสอบได้ ไม่ใช่สิ่งทั่วไป อย่าเขียนว่า “ตรวจสอบว่า brief ครอบคลุมเรื่องการเรียกเก็บเงิน” แต่ให้เขียนว่า “เปิด brief หาส่วนที่พูดถึงการเรียกเก็บเงิน และยืนยันว่าระบุจำนวนเงินเป็น $ หรือเปอร์เซ็นต์ของรายได้” คำสั่งแรกทำให้ grader อ่านผ่าน ๆ แล้วทำเครื่องหมายได้ ส่วนคำสั่งที่สองบังคับให้เปิดเอกสารและค้นหาตัวเลขที่ระบุชัดเจน

รูปแบบที่ควรหลีกเลี่ยง: “เอเจนต์ 50 ตัวกำลังทำเรื่องไร้สาระ”#

นี่คือรูปแบบที่ควรหลีกเลี่ยงหลักของ multi-agent มีคนรู้ว่า Claude Code เปิดเอเจนต์พร้อมกันได้ 16 ตัว และ Dynamic Workflows รันได้ 1000 ตัวต่อครั้ง จึงนั่งลงและเปิดใช้ทั้งหมด ผลลัพธ์: ศูนย์ การใช้โทเค็น: 10× ของเซสชันปกติ

วิธีทดสอบง่าย ๆ หยิบกระดาษหนึ่งแผ่นแล้ววาดกรอบให้เอเจนต์แต่ละตัว ในแต่ละกรอบเขียนว่า:

1. มันทำอะไรอย่างเจาะจง (หนึ่งประโยค)
2. แตะต้องไฟล์ใดบ้าง
3. ส่งอะไรกลับมา
4. ใครเป็นผู้ตรวจ

หากตอบคำถามข้อใดข้อหนึ่งไม่ได้ภายใน 30 วินาที ก็ไม่ควรมีเอเจนต์ตัวนั้น กฎนี้ใช้ได้กับทุกระดับ: subagents, agent teams และ Dynamic Workflows

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

รูปแบบที่ควรหลีกเลี่ยงข้อที่สามคือ ใช้ multi-agent เพื่อเร่งความเร็ว วิธีนี้ได้ผลถึงจุดหนึ่ง หากแบ่งงานเป็นสายงานอิสระ 4 สาย ทั้งหมดจะเสร็จในเวลาใกล้เคียงกับการทำงานสายเดียว (บวกเวลาเล็กน้อยสำหรับประสานงาน) แต่ถ้ามี 50 สายในเครื่องเดียว แต่ละสายจะทำงานช้าลงเพราะใช้ CPU ร่วมกัน ขีดจำกัดที่เหมาะกับแล็ปท็อปในทางปฏิบัติคือ Claude Code พร้อมกัน 4–6 อินสแตนซ์ หลังจากนั้นจะเริ่มถูกลดความเร็ว

มีค่าใช้จ่ายเท่าไร และจะหลีกเลี่ยงการใช้โควตาจนหมดได้อย่างไร?#

ในเดือนพฤษภาคม–มิถุนายน 2026 อุตสาหกรรมต้องเผชิญความจริงที่ว่าการเขียนโค้ดด้วย AI มีค่าใช้จ่ายสูงกว่าที่คาดไว้

แชต Claude Code ปกติเซสชันหนึ่งมีค่าใช้จ่ายค่อนข้างสมเหตุสมผล แต่หากเปิด Dynamic Workflows ให้ทำงานครอบคลุมทั้ง repository ก็จะได้บิลแพงขึ้น 20 เท่า จากเอกสารทางการของ Anthropic:

ควรทำอะไรในทางปฏิบัติ ต่อไปนี้คือกฎประหยัดจากประสบการณ์ที่เล่าถึง

1. ระบุไฟล์ที่เอเจนต์แต่ละตัวต้องตรวจให้ชัดเจน อย่าเขียนว่า “ตรวจดูโปรเจกต์แล้วหาปัญหา” แต่ให้เขียนว่า “ตรวจ src/auth/*.ts และเช็กว่าทุกฟังก์ชันตรวจสอบ userId” prompt แบบที่สองจะให้ผลลัพธ์ตรงกับงานที่คุณจ่ายเงิน

2. ทดลอง workflow กับไดเรกทอรีเดียวก่อนเสมอ อย่ารันกับ src/ ทั้งหมด เริ่มจาก src/auth/ หากพอใจกับผลลัพธ์และเข้าใจค่าใช้จ่ายแล้ว ค่อยขยายขอบเขต

3. ใช้ /effort high เป็นค่าเริ่มต้น และใช้ ultracode เฉพาะเมื่อตั้งใจเลือกเท่านั้น /effort ultracode หมายถึง xhigh พร้อม orchestration อัตโนมัติ ซึ่งมีค่าใช้จ่ายสูงมาก ใช้เมื่องานจำเป็นต้องมีหลายสายงานทำพร้อมกันจริง ๆ

4. เปลี่ยน subagents เป็นโมเดลขนาดเล็กลงเมื่อทำได้ หากมี subagents 6 ตัวตรวจคู่มือเดียวกัน ทั้งเอเจนต์ QA ที่ตรวจหา AI และตัวตรวจลิงก์ภายในไม่จำเป็นต้องใช้ Opus ใช้ Sonnet ก็เพียงพอ วิธีนี้ลดการใช้งานได้ 3–5 เท่า

ดูรายละเอียดการประหยัดโทเค็นได้ในคู่มือโทเค็นใน Claude Code ถูกใช้ไปกับอะไร และวิธีหลีกเลี่ยงการใช้โควตา Claude Code จนหมด

ควรเริ่มตรงไหนวันนี้: checklist 30 นาที#

1. อัปเดต Claude Code เป็น v2.1.154+

   นี่คือเวอร์ชันขั้นต่ำที่รองรับ Dynamic Workflows รัน claude update ในเทอร์มินัล

2. เปิดใช้งาน Dynamic Workflows ใน /config

   ฟีเจอร์นี้ปิดไว้เป็นค่าเริ่มต้นในแผน Pro เปิด /config หาแถว “Dynamic workflows” แล้วเปิดใช้งาน แผน Max, Team และ Enterprise เปิดใช้งานอยู่แล้ว

3. สร้าง worktree แรกของคุณ

   ในไดเรกทอรีโปรเจกต์หลัก รัน git worktree add ../<project>-experiment <branch> เปิดหน้าต่างเทอร์มินัลที่สองในไดเรกทอรีนั้น แล้วรัน claude

4. เพิ่มรายการงานที่ใช้ร่วมกัน

   ใช้ absolute path เดียวนอก worktree ทุกอัน tasks.md ในแต่ละ worktree เป็นคนละไฟล์และไม่ซิงก์เอง ให้เซสชันหัวหน้าเป็นผู้เขียนคนเดียว ผู้ทำงานอ่านรายการร่วมและรายงานผล

   สร้างโฟลเดอร์และรายการครั้งเดียว:

   mkdir -p "$HOME/projects/my-app-coordination"
   printf '%s\n' '# Tasks' '- Auth: assigned to the auth worktree' '- Billing: assigned to the billing worktree' > "$HOME/projects/my-app-coordination/tasks.md"
   

   เทอร์มินัลแรก:

   cd "$HOME/projects/my-app-auth"
   printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   เทอร์มินัลที่สอง:

   cd "$HOME/projects/my-app-billing"
   printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
   claude
   

   ให้ทั้งคู่ใช้ absolute path ที่ขยายแล้วอันเดียวซึ่งพิมพ์ด้านบน พร้อมคำสั่งว่า “อ่านรายการงานร่วมนี้ ทำเฉพาะงานและไฟล์ที่รับผิดชอบ ห้ามแก้รายการ รายงานผลและสิ่งติดขัดแก่หัวหน้าผู้ปรับสถานะ” ยืนยันว่าทั้งสองอ่านไฟล์เดียวกันได้ก่อนเริ่ม และแก้การขอสิทธิ์สำหรับเส้นทางนั้น รายการร่วมประสานสถานะ ส่วนโค้ดยังแยกในแต่ละ worktree

5. ทำงานแบบนี้เป็นเวลาหนึ่งสัปดาห์

   อย่าเพิ่งติดตั้ง GUI wrapper ใช้ worktrees สองชุดด้วยตนเองเป็นเวลาหนึ่งสัปดาห์ คุณจะเห็นว่าขาดอะไร แล้วค่อยเลือกเครื่องมือเพื่อแก้ปัญหาที่เจาะจง

6. จากนั้นค่อยเปิด `/effort ultracode`

   เลือกงานหนึ่งอย่าง เช่น “ค้นหา API endpoints ทั้งหมดใน src/routes/ ที่ไม่มีการตรวจสอบ auth” เปิดใช้ /effort ultracode ดูว่า Claude เขียน workflow แบบใด มีค่าใช้จ่ายเท่าไร และได้ผลลัพธ์อะไร นี่คือ Dynamic Workflow ครั้งแรกของคุณ

ขั้นต่อไป: memory ระหว่างเซสชัน, Code Review และ Multi-Agent v2#

สิ่งที่เปิดตัวในเดือนพฤษภาคม–มิถุนายน 2026 และทิศทางของ multi-agent ใน Claude Code

Managed Agents พร้อม Dreaming. เปิดตัวเมื่อวันที่ 6 พฤษภาคม 2026 ในงาน Code with Claude เป็นกระบวนการที่ทำงานตามกำหนด อ่าน transcript ที่ผ่านมาของเอเจนต์ระหว่างเซสชัน ระบุรูปแบบที่เกิดซ้ำ และอัปเดต memory บริษัท AI ด้านกฎหมาย Harvey มีอัตราการทำงานสำเร็จเพิ่มขึ้นหกเท่าโดยเฉพาะหลังใช้ Dreaming ยังอยู่ในช่วง research preview

Outcomes ในฐานะฟีเจอร์ Managed Agents. อธิบายไว้ข้างต้น ใช้ได้ผ่าน Claude Agent SDK ไม่ได้เปิดให้ใช้โดยตรงใน Claude Code CLI คุณสามารถใช้รูปแบบเดียวกันด้วยตนเองผ่าน grader subagent ได้ทันที

Multi-Agent Orchestration v2 ใน Claude Agent SDK. เอเจนต์นำทีมมอบหมายงานให้ subagents ด้วยตัวเอง โดยใช้ระบบไฟล์ร่วมกัน นี่คือการเปลี่ยนจาก “เปิด subagents N ตัวด้วยตนเอง” ไปเป็น “อธิบายงาน แล้วให้หัวหน้าตัดสินใจเองว่าจะมอบหมายให้ใครและอย่างไร” หากเพิ่งเริ่มเรียนรู้ subagents ยังไม่ต้องกังวลเรื่อง v2 เรียนรู้รูปแบบคลาสสิกก่อน — “เอเจนต์หลักหนึ่งตัว + subagents 3–5 ตัวที่มีบทบาทต่างกัน” — แล้วค่อยเปลี่ยนไปใช้ v2 ภายใน 3–6 เดือนตามธรรมชาติ

Code Review โดยทีมเอเจนต์. Anthropic ประกาศฟีเจอร์ตรวจโค้ดอัตโนมัติเมื่อเปิด PR ในงาน Code with Claude ทีมเอเจนต์ AI ตรวจ diff พร้อมกัน ค้นหาบั๊ก ตรวจสอบข้อค้นพบระหว่างกัน และจัดอันดับตามความรุนแรง ใช้ได้ในแผน Team และ Enterprise แต่ยังใช้ใน Pro ไม่ได้

Plugin Marketplace. เปิดตัวเมื่อวันที่ 23 พฤษภาคม 2026 ในเวอร์ชัน v2.1.128-136 ปลั๊กอินบางตัวใน marketplace เป็นการตั้งค่า multi-agent สำเร็จรูป (parallel-review, security-audit, migration-helper) ติดตั้งได้ด้วย /plugin install <name>@claude-plugins-official และดูวิธีประกอบปลั๊กอินเหล่านี้ได้ ซึ่งเป็นวิธีเรียนรู้การเขียนปลั๊กอินของคุณเองที่ดี

multi-agent ใน Claude Code ยังคงเป็นองค์ประกอบหลายแบบที่มีระดับความพร้อมต่างกัน Subagents และ git worktree เสถียร ผ่านการพิสูจน์แล้ว และใช้ได้ทุกที่ Agent teams เป็นระบบอัตโนมัติครึ่งหนึ่งและทำด้วยตนเองอีกครึ่ง Dynamic Workflows อยู่ในช่วง research preview และเปลี่ยนแปลงอย่างรวดเร็ว ส่วน Managed Agents v2 ใช้ได้เฉพาะองค์กร ซึ่งหมายความว่าในปีข้างหน้า การตั้งค่าที่เหมาะสมที่สุดสำหรับ vibe coder จะไม่ใช่ รุ่นล่าสุด แต่เป็นการตั้งค่าขั้นต่ำที่งานนั้นต้องใช้ worktrees สองชุดกับ grader subagent หนึ่งตัวก็เพียงพอสำหรับการทำงานอย่างต่อเนื่องหนึ่งเดือน เพิ่มความซับซ้อนเมื่อเริ่มรู้สึกว่าถูกจำกัดเท่านั้น

การตั้งค่าที่ใช้ได้จริงสำหรับ vibe coding#

เอกสารประกอบเชิงปฏิบัติ: เอกสารของ Ailoot

เอกสารและเครื่องมือเพิ่มเติม: Ailoot.