เชี่ยวชาญ 8 เซสชันได้ด้วยตัวคนเดียว! คู่มือฉบับสมบูรณ์สำหรับการจัดการ Claude Code

"ผมใช้ Claude Code อยู่ แต่เมื่อสเกลใหญ่ขึ้น คอนเท็กซ์ก็ล้นและความแม่นยำก็ลดลง"

"สุดท้ายแล้ว การที่ผมต้องลงมือแก้ไขคำสั่งให้ AI เอง กลายเป็นคอขวดที่ใหญ่ที่สุด"

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

สิ่งที่ผมเพิ่งค้นพบคือ Claude Code เองมีกลไกสามอย่างที่รองรับการรันหลายเซสชันแบบขนาน

ยิ่งไปกว่านั้น ทั้งสามอย่างนี้คล้ายกันแต่แตกต่าง ถ้าสับสนอาจเกิดปัญหาได้ ในทางกลับกัน ถ้าแบ่งตามบทบาท คุณจะขยับไปเป็น "ฝ่ายสั่งการ" ได้โดยไม่ต้องเขียนโค้ดสักบรรทัด

วันนี้ผมจะจัดระเบียบกลไกทั้งสามนี้และวิธีที่ถูกต้องในการกำหนดขอบเขตบทบาท โดยตรวจสอบข้อมูลหลักจากเอกสารทางการ

โดยเฉพาะอย่างยิ่ง จะแยกเป็นการกำหนดค่าให้มี 8 เซสชันในสามชั้น: คำสั่ง การใช้งาน และคุณภาพ

และเป็นโบนัส ผมจะใช้ข้อมูลหลักอธิบายด้วยว่าทำไมคำอธิบายทั่วไปอย่าง "การเขียน role ID ใน CLAUDE.md เพื่อสลับ" หรือ "แชร์หน่วยความจำด้วย SQLite" ถึงคลาดเคลื่อนจากกลไกทางการ

ผมชื่อ tatsuki (@nobel_824

ผมสนับสนุนการใช้งาน AI สำหรับธุรกิจขนาดเล็กและขนาดกลาง ช่วยในการนำ Claude / Codex ไปใช้งานจริง พร้อมกับใช้ Claude Code เองตลอดทั้งวัน การทำงานแบบขนานเป็นสิ่งที่ผมสัมผัสทุกวันทั้งในงานและโปรเจกต์ส่วนตัว

บทความที่เกี่ยวข้อง: Introduction to Vibe Coding: 6 Steps for Non-Coders to Build Apps with Claude. The Era of In-house Production in a Weekend

https://note.com/nobel/n/n8192ec07d689

1. ทำไมการ "ยัดทุกอย่างไว้ในเซสชันเดียว" ถึงล้มเหลว

กับดักแรกคือการใส่ข้อมูลมากเกินไปในเซสชันเดียว ไม่ว่า Claude จะฉลาดแค่ไหน มันก็มีขีดจำกัดทางโครงสร้าง

โดยเฉพาะ คุณจะเจอปัญหาสามอย่างนี้:

การปนเปื้อนของคอนเท็กซ์: เมื่อโค้ดการใช้งาน เทส ประวัติการดีบัก และดีไซน์คัสเซชั่นผสมกันในคอนเท็กซ์เดียวกัน พื้นฐานการให้เหตุผลจะมัวและความแม่นยำลดลง
ความขัดแย้งของคำสั่ง: ถ้า "ใช้งานด้วยความเร็วเป็นหลัก" กับ "เข้มงวดเรื่องความปลอดภัย" อยู่ในที่เดียวกัน การตัดสินใจจะครึ่งๆ กลางๆ
Token ล้น: การโหลดประวัติขนาดใหญ่ทุกครั้งเป็นการสิ้นเปลืองทั้งเวลาและต้นทุน

วิธีแก้คือแนวคิด "เป็นผู้บัญชาการคนเดียวและจัดแถว Claudes ที่เชี่ยวชาญเฉพาะด้าน" มันคล้ายกับ CTO ที่มี Tech Lead และ Backend Lead แต่สิ่งที่สำคัญไม่ใช่แค่แนวคิด แต่คือการใช้กลไกทางการของ Claude Code อย่างถูกต้อง

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

2. แก้ไข "กลไกขนานสามอย่าง" ที่ให้มาอย่างเป็นทางการ

นี่คือแกนหลักของบทความ Claude Code มีกลไกสามอย่างสำหรับการทำงานแบบขนาน แต่ละอย่างมีขอบเขตต่างกัน

อย่างแรกคือ subagent (AI ผู้ช่วยที่รันในคอนเท็กซ์แยกจากบทสนทนาหลัก) มันทำงานย่อย เช่น วิจัยหรือรีวิว โดยใช้หน้าต่างคอนเท็กซ์ของตัวเอง พร้อมต์ระบบเฉพาะ และสิทธิ์เครื่องมือที่จำกัด แล้วส่งเฉพาะสรุปผลลัพธ์กลับไปยังเซสชันหลัก จุดสำคัญคือ subagents รันภายในเซสชันเดียวกัน รายงานเฉพาะ main เท่านั้น และ subagents ไม่คุยกันเอง (เอกสารทางการ

อย่างที่สองคือ agent teams (กลไกที่ให้หลายเซสชัน Claude Code ทำงานร่วมกันเป็นทีม) เซสชันหนึ่งกลายเป็นหัวหน้าทีมและสร้างเพื่อนร่วมทีม ทำงานร่วมกันผ่านรายการงานและกล่องจดหมายที่ใช้ร่วมกัน ต่างจาก subagents ตรงที่เพื่อนร่วมทีมสามารถส่งข้อความถึงกันโดยตรง นี่เป็นฟีเจอร์ทดลองและปิดไว้โดยค่าเริ่มต้น คุณต้องตั้งค่า CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 และใช้ Claude Code v2.1.32 หรือใหม่กว่า (เอกสารทางการ

อย่างที่สามคือ git worktree (ฟีเจอร์ Git ที่ให้มีไดเรกทอรีทำงานหลายอันจากรีโพสิทอรีเดียวกัน) โดยเริ่มด้วย claude --worktree feature-auth Claude จะเปิดในสภาพแวดล้อมที่แยกออกไปใน branch/ไดเรกทอรีอื่น ถ้าคุณรันอีกอันในเทอร์มินัลอื่น พวกมันจะทำงานขนานกันโดยไม่ชนกันเรื่องไฟล์ (เอกสารทางการ) เมื่อใช้แอปเดสก์ท็อป worktree จะถูกสร้างอัตโนมัติสำหรับแต่ละเซสชันใหม่

นี่คือตารางเปรียบเทียบทั้งสาม:

คุณจะไม่สับสนถ้าจำไว้ว่า worktree จัดการเรื่องการแยกไฟล์ ส่วน subagents และ agent teams จัดการการประสานงานของงานเอง

หนึ่งสิ่งที่คุณทำได้วันนี้: ก่อนอื่นลองพิมพ์ claude --worktree bugfix-test เพื่อสัมผัสการเปิดเซสชันที่แยกออกมา เมื่อคุณทำเสร็จหลังจากแก้ไข มันจะถามว่าจะเก็บหรือลบ worktree

3. ปฏิบัติ: ใช้งาน 8 เซสชันใน "โครงสร้าง 3 ชั้น"

กลไกทั้งสามนี้กลายเป็น 8 เซสชันได้อย่างไร? ผมใช้ผังที่แบ่งเป็นชั้นคำสั่ง การใช้งาน และคุณภาพ

ชั้นคำสั่ง/ดีไซน์ (2 เซสชัน)

เซสชัน 1 PM (Project Manager): จัดการความก้าวหน้าโดยรวม แบ่งงาน รายงานให้มนุษย์
เซสชัน 2 Architect: ตัดสินใจความสอดคล้องทางเทคนิคและโครงสร้างไดเรกทอรี ต้องอนุมัติแผนเพื่อสร้างดีไซน์โดยไม่ต้องเขียนโค้ด

ชั้นการใช้งาน/ปฏิบัติการ (4 เซสชัน)

เซสชัน 3 Frontend: สร้างคอมโพเนนต์ ปรับ UI
เซสชัน 4 Backend: สร้าง endpoint ปรับ query
เซสชัน 5 Infra/DevOps: ดูแล Docker, CI/CD
เซสชัน 6 Security: ตรวจสอบช่องโหว่ ปรับปรุงการยืนยันตัวตน

ชั้นคุณภาพ/บำรุงรักษา (2 เซสชัน)

เซสชัน 7 QA/Reviewer: รีวิว PR ชี้จุดผิดปกติ
เซสชัน 8 Technical Writer: ดูแล README, เอกสาร API

มีเคล็ดลับสามอย่างสำหรับผังนี้: แยกสี่เซสชันชั้นการใช้งานด้วย worktrees เพื่อไม่ให้ชนกันเรื่องไฟล์ กำหนดบทบาทสำหรับชั้นคุณภาพเป็น subagent definitions หรือ agent team teammates และให้แต่ละเซสชันส่งข้อมูลผ่านไฟล์ Markdown ที่แชร์กัน (บันทึกดีไซน์หรือผลรีวิว) Architect อัปเดตดีไซน์ ชั้นการใช้งานทำงานตามนั้น และ Reviewer เขียนผลกลับ มนุษย์แค่ต้องให้คำสั่งกับแต่ละเซสชันเมื่อไฟล์เหล่านี้เปลี่ยน

ข้อควรจำ: หลักเกณฑ์ทางการสำหรับทีม agent หนึ่งทีมคือ 3–5 คน ดังนั้นอย่ายัดทั้ง 8 คนไว้ในทีมเดียว (เอกสารทางการ) ปลอดภัยกว่าที่จะรวมเซสชันที่แยกด้วย worktree กับทีม agent 3–5 คน และ subagents ตามต้องการเพื่อให้มีคนงานทั้งหมด 8 คน

หนึ่งสิ่งที่คุณทำได้วันนี้: เลือกสองบทบาทจาก 8 ด้านบนที่ดูเหมือนแยกง่ายในโปรเจกต์ปัจจุบันของคุณ ในหลายกรณี Architect และ Reviewer คือจุดแบ่งแรก

4. แก้ไขขอบเขตบทบาทด้วย "Subagent Definitions" ไม่ใช่ "CLAUDE.md"

ขอแก้ความเข้าใจผิดทั่วไปเกี่ยวกับการทำงานแบบขนาน คุณอาจเห็นคำอธิบายแบบ "เขียน roles (ID: arch, ID: dev-main...) ใน CLAUDE.md แล้วสลับบุคลิกตอนเริ่ม" แต่กลไกนี้ไม่มีอยู่จริง

CLAUDE.md เป็นไฟล์คำสั่งที่ใช้ร่วมกันที่ Claude Code อ่านเมื่อเริ่มต้น อย่างไรก็ตาม เอกสารทางการระบุชัดเจนว่า CLAUDE.md คือ "context, ไม่ใช่การตั้งค่าบังคับ" เพราะมันถูกส่งเป็นข้อความผู้ใช้หลังจากพร้มต์ระบบ การปฏิบัติตามอย่างเคร่งครัดจึงไม่รับประกัน ถ้าคุณต้องการหยุดบางอย่างจริงๆ ควรใช้ hooks (เอกสารทางการ) มองมันเป็นคำแนะนำที่แข็งแกร่ง ไม่ใช่ "รัฐธรรมนูญ" ที่เด็ดขาด

แล้วจะแก้ไขบทบาทตรงไหน? คำตอบคือ subagent definitions โดยการวางไฟล์ภายใต้ .claude/agents/ พร้อมชื่อ คำอธิบาย เครื่องมือที่มี และโมเดลใน frontmatter คุณจะได้ผู้เชี่ยวชาญที่ใช้ซ้ำได้ นี่คือตัวอย่างขนาดเล็ก:

name: security-reviewer

description: ตรวจสอบโค้ดอย่างมีวิจารณญาณจากมุมมองการยืนยันตัวตน การตรวจสอบอินพุต และการจัดการเซสชัน

tools: Read, Grep, Bash

model: sonnet

คุณเป็น senior security reviewer มุ่งเน้นที่การจัดการ token การจัดการเซสชัน และการตรวจสอบอินพุต และรายงานผลพร้อมระดับความรุนแรง

ยิ่งไปกว่านั้น คำจำกัดความเหล่านี้สามารถเรียกตามชื่อเป็นเพื่อนร่วมทีมใน agent teams ถ้าคุณขอให้ "ตั้งค่าเพื่อนร่วมทีมด้วยประเภท agent security-reviewer เพื่อตรวจสอบโมดูล auth" มันจะกลายเป็นสมาชิกที่สืบทอดเครื่องมือและโมเดลจากคำจำกัดความนั้น (เอกสารทางการ) การออกแบบให้คุณเขียนบทบาทครั้งเดียวเป็น subagent definition และใช้ซ้ำทั้งในฐานะ subagent และสมาชิกทีม

ตัวอย่างพร้มต์ให้ลอง (ให้ Claude สร้างคำจำกัดความบทบาท):

สร้างคำจำกัดความ subagent เพื่อวางใน .claude/agents/

บทบาทคือ "ผู้รีวิวที่ชี้ปัญหาเรื่องประสิทธิภาพและ N+1 queries ในโค้ดการใช้งาน"

รวม name / description / tools / model ใน frontmatter

และเขียนเนื้อหาในบุคลิกของวิศวกรอาวุโส

5. สร้างทีม "Architect-Reviewer" ด้วย Agent Teams เพื่อเพิ่มความแม่นยำ

การกำหนดค่าที่มีประสิทธิภาพสูงในการทำงานแบบขนานคือการแยก "ผู้สร้าง" และ "ผู้สงสัย" ออกจากกัน นี่ไม่ใช่แค่ทฤษฎี เอกสารทางการมีตัวอย่างในโลกจริง

ในตัวอย่าง "Parallel Code Review" ทางการ สำหรับ PR หนึ่ง มีเพื่อนร่วมทีมสามคนตั้งค่าไว้สำหรับความปลอดภัย ประสิทธิภาพ และความครอบคลุมของการทดสอบ แต่ละคนมองจากมุมมองต่างกัน ในขณะที่หัวหน้าทีมรวมผลลัพธ์ นอกจากนี้ ในตัวอย่าง "Competing Hypotheses" เพื่อนร่วมทีมห้าคนได้รับสมมติฐานต่างกันสำหรับบั๊ก เพื่อโต้แย้งและหักล้างทฤษฎีของกันและกัน ถือว่าทฤษฎีที่รอดเป็นสาเหตุหลัก (เอกสารทางการ) เนื่องจากผู้สืบสวนคนเดียวมักถูกดึงไปทางทฤษฎีแรก วิธีนี้จึงสร้างความขัดแย้งโดยเจตนาเพื่อเพิ่มความแม่นยำ

คุณยังสามารถทำให้ Architect "ไม่มีสิทธิ์เขียนโค้ด" โดยใช้ฟีเจอร์ทางการ โดยกำหนดให้เพื่อนร่วมทีมต้องขออนุมัติแผน เพื่อนร่วมทีมจะอยู่ในโหมดแผนแบบอ่านอย่างเดียว สร้างเฉพาะดีไซน์จนกว่าหัวหน้าทีมจะอนุมัติ เกณฑ์การอนุมัติสามารถเขียนในพร้มต์ของหัวหน้าทีม เช่น "อนุมัติเฉพาะแผนที่รวมความครอบคลุมของการทดสอบ"

ตัวอย่างพร้มต์ให้ลอง (ตั้งค่าโครงสร้างความขัดแย้งในครั้งเดียว):

สร้าง agent team เพื่อรีวิว PR #142 ตั้งค่าเพื่อนร่วมทีมสามคน:

หนึ่งคนสำหรับความปลอดภัย หนึ่งคนสำหรับประสิทธิภาพ และหนึ่งคนสำหรับความครอบคลุมของการทดสอบ

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

มีสองโหมดการแสดงผล: in-process (เพื่อนร่วมทีมทั้งหมดรันในเทอร์มินัลเดียวกัน วนด้วย Shift+Down) และ split panes (เพื่อนร่วมทีมแต่ละคนในแผงแยก; ต้องใช้ tmux หรือ iTerm2) เริ่มด้วย in-process ง่ายกว่าเพราะไม่ต้องตั้งค่าเพิ่มเติม

6. แชร์หน่วยความจำผ่าน Official Auto Memory (Markdown) ไม่ใช่ "SQLite"

เมื่อรันหลายเซสชัน อุปสรรคต่อไปคือ "การแชร์หน่วยความจำระหว่างเซสชัน" ในขณะที่เทคนิคขั้นสูงอย่าง "การเก็บหน่วยความจำแบบมีแท็กใน SQLite แล้วฉีดเข้าไปแบบไดนามิก" บางครั้งถูกแนะนำ แต่นั่นไม่ใช่ฟีเจอร์มาตรฐานของ Claude Code เป็นไปได้ถ้าคุณสร้าง DB ผ่าน MCP (Model Context Protocol) แต่คุณควรแยกมันออกจากกลไกหน่วยความจำที่ให้มาอย่างเป็นทางการ

auto memory ทางการทำงานกับไฟล์ markdown ภายใน ~/.claude/projects/<project>/memory/ มีไฟล์อย่าง MEMORY.md (ดัชนี) และไฟล์เฉพาะหัวข้ออย่าง debugging.md และ Claude จะเขียนลงไปเมื่อทำงาน กฎการโหลดชัดเจน: ทุกเซสชันอ่านสูงสุด 200 บรรทัดแรกหรือ 25KB ของ MEMORY.md และ Claude จะอ่านไฟล์เฉพาะหัวข้อเมื่อจำเป็นเท่านั้น ฟีเจอร์นี้มีตั้งแต่ Claude Code v2.1.59 บันทึกต่อรีโพสิทอรี (จึงแชร์ข้าม worktrees) และเก็บในเครื่อง (เอกสารทางการ

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

ในแง่ลำดับ ให้ใช้ auto memory แบบ markdown ทางการให้เต็มที่ก่อนที่จะลองสร้างโซลูชัน SQLite แบบกำหนดเอง

หนึ่งสิ่งที่คุณทำได้วันนี้: การพิมพ์ /memory ระหว่างเซสชันจะแสดงรายการไฟล์ CLAUDE.md และ auto memory ที่โหลดอยู่ ก่อนอื่นลองดูว่าคุณมีหน่วยความจำที่ไหนและเท่าไหร่

7. ข้อควรระวังสามประการในการทำงานแบบขนาน (ต้นทุน DB สิทธิ์)

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

อย่างแรกคือ ต้นทุน token เอกสารทางการระบุว่าเนื่องจากเพื่อนร่วมทีมใน agent team แต่ละคนมีคอนเท็กซ์อิสระ การใช้ token จึงเพิ่มขึ้นตามจำนวนคน การใช้ 5 คนสำหรับงานประจำจะทำให้ขาดทุนด้านต้นทุน นั่นคือเหตุผลที่คำแนะนำทางการคือ 3–5 คน โดยระบุว่า "สมาชิกที่โฟกัสสามคนมักดีกว่าสมาชิกที่วอกแวกห้าคน" (เอกสารทางการ

อย่างที่สองคือ ขอบเขตการแยกของ worktrees worktree เป็นเพียงกลไก Git สำหรับแยกไฟล์ ฐานข้อมูล ตัวแปรสภาพแวดล้อม และบริการที่ทำงานยังคงใช้ร่วมกัน ถ้าสองเซสชันรัน migrations บน DB ท้องถิ่นเดียวกัน มันจะพัง เอกสารทางการเตือนให้ "อย่าลืมเริ่มต้นสภาพแวดล้อมการพัฒนา (ติดตั้ง dependencies ตั้งค่า virtual envs) ในแต่ละ worktree" และถ้างานกระทบ DB คุณต้องแยก schemas, Docker containers หรือไฟล์ .env (เอกสารทางการ

อย่างที่สามคือ สิทธิ์ เพื่อนร่วมทีมสืบทอดการตั้งค่าสิทธิ์ของหัวหน้าทีมเมื่อถูกสร้าง ถ้าคุณรันหัวหน้าทีมด้วย --dangerously-skip-permissions เพื่อนร่วมทีมทั้งหมดก็จะอยู่ในสถานะไม่ยืนยันเหมือนกัน เนื่องจากผลกระทบของอุบัติเหตุกระจายแบบขนาน การจำกัดสิทธิ์ที่ฝั่งหัวหน้าทีมจึงปลอดภัยกว่า

8. FAQ สำหรับผู้ใช้ระดับกลาง: จำนวนคน การขยาย และประตูคุณภาพ

สุดท้ายนี้ คำตอบเพิ่มเติมสำหรับคำถามที่พบบ่อย

Q. กี่เซสชันถึงจะสมจริง?

แนวทางที่ดีคือโครงสร้าง 3 ชั้น 8 เซสชันที่กล่าวถึงก่อนหน้านี้ กุญแจสำคัญคือไม่ต้องยัด 8 คนในทีม agent ทีมเดียว แต่ใช้ทีม 3–5 คนเป็นแกนหลัก และเพิ่มเซสชัน worktree หรือ subagents ซึ่งสอดคล้องกับคำแนะนำทางการ (3–5 คนต่อทีม, 5–6 งานต่อเพื่อนร่วมทีม) ขีดจำกัดสูงสุดคือช่วงที่คุณสามารถติดตามและควบคุมได้ ถ้าคุณเพิ่มจำนวนเกินกว่าที่จะสั่งการได้ ประสิทธิภาพจะลดลง

Q. ถ้าฉันโตเกิน subagents และ agent teams ล่ะ?

ถ้าคุณต้องการติดตามเซสชันอิสระจำนวนมากจากที่เดียว หน้า subagents ทางการกล่าวถึงกลไกที่เรียกว่า background agents คิดเป็นชั้น: subagents สำหรับช่วยภายในเซสชัน agent teams สำหรับทีมขนานแบบสนทนา และ background agents สำหรับจัดการหลายเซสชันอิสระ

Q. ฉันจะรับประกันคุณภาพได้อย่างไร?

คำแนะนำใน CLAUDE.md เป็นแค่ "คำแนะนำที่ทำตามง่าย" สำหรับการตรวจสอบที่คุณต้องการให้ดำเนินการอย่างแน่นอน ให้บังคับด้วย hooks Agent teams มี hooks เช่น TeammateIdle, TaskCreated และ TaskCompleted การคืนค่า exit code 2 จะส่ง feedback และบังคับให้งานดำเนินต่อไป (เอกสารทางการ) หมายความว่าคุณสามารถบังคับใช้กฎเชิงโปรแกรม เช่น "อย่าทำให้เสร็จจนกว่าการทดสอบจะผ่าน"

สรุป: จากผู้ติดตามไปสู่นักออกแบบ/ผู้มอบหมาย

คุณค่าของ Claude Code อยู่ที่ความสามารถของคนคนเดียวในการควบคุม Claudes ที่เชี่ยวชาญหลายตัว มากกว่าแค่เขียนโค้ดเร็วขึ้น นี่คือประเด็นสำคัญ:

อย่าสับสนกลไกทั้งสาม: subagents ส่งคืนผลลัพธ์ agent teams คือทีมสนทนา worktrees แยกไฟล์ แบ่ง 8 เซสชันเป็นชั้นคำสั่ง การใช้งาน และคุณภาพ แยกการใช้งานด้วย worktrees และกำหนดบทบาทคุณภาพด้วย subagent definitions หรือ agent teams แก้ไขขอบเขตบทบาทใน subagent definitions มากกว่า CLAUDE.md และบังคับกฎเด็ดขาดด้วย hooks จัดระเบียบ auto memory แบบ markdown ก่อนสร้างโซลูชัน SQLite แบบกำหนดเอง ตั้งเป้า 3–5 คนต่อทีม และสร้างเป็น 8 คนโดยเพิ่มชั้น

3 ขั้นตอนที่ลองทำวันนี้:

[ ] พิมพ์ claude --worktree test-1 เพื่อสัมผัสการเปิดเซสชันที่แยกออกมา
[ ] เขียน subagent definition หนึ่งรายการสำหรับบทบาท "reviewer" ใน .claude/agents/ และให้มันรีวิวการใช้งานของคุณ
[ ] ตั้งค่า CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 และลองรันรีวิว PR แบบขนานกับเพื่อนร่วมทีมสามคน

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

ลิงก์อ้างอิง (แหล่งข้อมูลหลักทางการ)