Subagents ใน Claude Code: โครงสร้าง บทบาท 5 แบบ และการประสานงาน

Subagent ใน Claude Code คืออะไร และทำไมจึงไม่ใช่ “แค่ Skill อีกแบบหนึ่ง”?#

เอกสารประกอบ Claude Code ให้คำจำกัดความไว้ดังนี้:

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

Subagents ใน Claude Code ทำงานในลักษณะเดียวกัน แชตหลักคือผู้อำนวยการ ส่วน subagent คือผู้เชี่ยวชาญที่มีงานเฉพาะด้าน บริบท และชุดเครื่องมือของตัวเอง เมื่อมีงานที่ตรงกับคำอธิบายของผู้เชี่ยวชาญ ผู้อำนวยการก็จะมอบหมายงานให้ โดยไม่ต้องจมอยู่กับรายละเอียด

5 เป้าหมายที่ Anthropic สร้าง Subagents มาเพื่อรองรับ

เอกสารประกอบของ Anthropic ระบุเหตุผลไว้ 5 ข้อสำหรับการสร้าง subagent ของคุณเอง:

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

ตรวจการรองรับซ้อนเอเจนต์ในรุ่นที่ติดตั้ง

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

Subagent แตกต่างจาก Skill, Slash Command และ Hook อย่างไร?#

คู่มือก่อนหน้าเกี่ยวกับ Skills อธิบายว่า skills กับ slash commands ใน Claude Code ได้รวมเป็นรูปแบบเดียวกันในทางปฏิบัติแล้ว แต่ subagent เป็นอีกสิ่งหนึ่ง ไม่ใช่แค่ “skill ที่ใหญ่กว่า”

ตารางสรุปกลไกทั้งสี่:

คำอธิบายที่เหมาะกับคู่มือภาษาอังกฤษคือ: skills เหมือนสูตรอาหาร ส่วน subagents เหมือนเพื่อนร่วมงานเฉพาะทาง

วางง่าย ๆ: Skills เหมือนสูตรอาหาร ส่วน subagents เหมือนเพื่อนร่วมงานเฉพาะทาง

ในทางปฏิบัติเป็นแบบนี้: skills จะทำงานโดยอัตโนมัติเมื่อคำอธิบายตรงกับงาน ส่วน subagents จะถูกเรียกใช้อย่างชัดเจน ไม่ว่าแชตหลักจะตัดสินใจมอบหมายงานให้ หรือคุณเรียกใช้ด้วยชื่อเอง

แผนผังตัดสินใจ: “ควรเลือกอะไร?”

เมื่อคุณคิดว่า “ฉันต้องการให้ Claude ทำ X” ให้ลองตอบคำถาม 4 ข้อนี้:

1. นี่คือความรู้ที่ควรพร้อมใช้งานอยู่เสมอหรือไม่? ตัวอย่างเช่น “เราแปลเป็นภาษาที่ผู้ใช้ต้องการ” หรือ “เราไม่ใช้ em dash” ให้ใส่ไว้ใน CLAUDE.md.
2. นี่คือวิธีการที่ถูกเรียกใช้เมื่อมีเงื่อนไข และตอนนี้คุณทำเองอยู่หรือไม่? ตัวอย่างเช่น “ฉันเขียนรายงานการขายทุกวันจันทร์” ให้สร้าง skill.
3. งานนี้จะใช้บริบทของแชตหลักมากหรือไม่ หรือสามารถทำงานขนานกันได้? ตัวอย่างเช่น “ค้นคว้าเชิงลึกจาก 30 แหล่ง” หรือ “ตรวจสอบความปลอดภัยระหว่างที่ฉันเขียนฟีเจอร์ใหม่” ให้สร้าง subagent.
4. คุณต้องการให้ตอบสนองต่อเหตุการณ์ใน Claude Code โดยอัตโนมัติหรือไม่? ตัวอย่างเช่น “เรียกใช้ linter หลังการ Edit ทุกครั้ง” ให้เขียน hook.

งานของผู้ประกอบการ 90% อยู่ในสองหมวดแรก Subagents เป็นเครื่องมือขั้นต่อไป สำหรับเวลาที่คุณเปลี่ยนจากการทำ “ทีละงาน” ไปสู่การประสานงานหลายงาน

Subagents อยู่ที่ใด และตัวใดมีลำดับความสำคัญเหนือกว่า?#

ลำดับชั้นของ subagent มี 5 ระดับ เรียงจากความสำคัญสูงสุดไปต่ำสุด:

ตรรกะของลำดับความสำคัญเหมือนกับ Skills และ CLAUDE.md: การตั้งค่าขององค์กรมีลำดับเหนือ CLI, CLI เหนือโปรเจกต์, โปรเจกต์เหนือส่วนตัว และส่วนตัวเหนือปลั๊กอิน

เรื่องที่ควรรู้เกี่ยวกับการโหลด

Subagents จะโหลดเมื่อเริ่มเซสชัน Claude Code หากคุณแก้ไขไฟล์ agent บนดิสก์ด้วยตนเอง การเปลี่ยนแปลงจะไม่มีผลจนกว่าจะเริ่มเซสชันใหม่ การแก้ไขผ่าน UI แบบโต้ตอบ /agents จะมีผลทันที

หนึ่ง subagent ต่อหนึ่ง scope หมายถึงหนึ่งไฟล์ หาก .claude/agents/ มี code-reviewer.md และมี code-reviewer.md อีกไฟล์อยู่ข้าง ๆ (เช่น จากข้อมูลสำรองเก่า) Claude Code จะเพิกเฉยต่อไฟล์ใดไฟล์หนึ่งโดยไม่แจ้งให้ทราบ

Subagents ของปลั๊กอินเป็นอีกกรณีหนึ่ง เพราะมีข้อจำกัดด้านความปลอดภัย โดย ไม่รองรับ ฟิลด์ hooks, mcpServers และ permissionMode เพื่อป้องกันไม่ให้การติดตั้งปลั๊กอินจากบุคคลที่สามทำให้ปลั๊กอินมีสิทธิ์เรียกใช้โค้ดใด ๆ บนเครื่องของคุณ

โครงสร้างไฟล์ Subagent: Frontmatter และเนื้อหา#

ตัวอย่างขั้นต่ำจากเอกสารอย่างเป็นทางการ มีเพียง 9 บรรทัด:

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

เท่านี้ก็เพียงพอแล้ว หากผู้ใช้พูดว่า “review my PR” ในแชตหลัก Claude จะจับคู่คำว่า “reviewer / code / quality” กับ description แล้วมอบหมายงานให้ subagent Subagent จะอ่าน diff เขียนความคิดเห็น และส่งสรุปกลับไปยังแชตหลัก แชตหลักจึงไม่รกไปด้วยบันทึกและการวิเคราะห์ระหว่างทาง

สคีมาของ Frontmatter ฉบับเต็ม

ฟิลด์ model: haiku เป็นตัวอย่างของ “การควบคุมค่าใช้จ่าย” ตามรายการ 5 เป้าหมายพอดี หากคุณมี research agent ที่ต้องอ่านเอกสาร 50 หน้า ให้ใช้ Haiku เพื่อประหยัดค่าใช้จ่ายได้ 5–7 เท่าเมื่อเทียบกับ Opus

ฟิลด์ isolation: worktree แก้ปัญหาสำคัญกรณีที่ subagent อาจเปลี่ยนแปลงสิ่งที่เสี่ยง เช่น refactoring หรือ migration แต่คุณไม่อยากให้มันแตะสำเนางานของคุณ ให้ตั้ง isolation: worktree แล้ว Claude Code จะสร้างสำเนาโปรเจกต์ชั่วคราวใน git จากนั้น subagent จะทำงานในนั้นและส่ง diff กลับมาให้ตรวจสอบ

เนื้อหาในไฟล์คือ System Prompt

หลัง frontmatter คือ Markdown ทั่วไป ซึ่งเป็น system prompt ของ subagent ไม่จำเป็นต้องมีโครงสร้างพิเศษ แต่รูปแบบนี้ผ่านการพิสูจน์แล้วว่าใช้ได้ดี:

1. คุณเป็นใคร — หนึ่งประโยค เช่น “คุณคือ code reviewer” “คุณคือผู้ตรวจสอบความปลอดภัย” หรือ “คุณคือผู้ดูแลเอกสารประกอบ”
2. เมื่อถูกเรียกใช้และควรทำอะไรก่อน — การกระทำ 2–3 อย่างแรกหลังได้รับงาน
3. รายการตรวจสอบหรือขั้นตอน — 5–10 ข้อที่ subagent ต้องทำตาม
4. สิ่งที่ต้องส่งกลับ — รูปแบบรายงานสุดท้าย เรื่องนี้สำคัญมาก หากไม่ระบุรูปแบบ subagent จะเขียน “เรียงความ” แทนที่จะเป็นสรุปที่มีโครงสร้าง
5. สิ่งที่ห้ามทำ — ระบุข้อจำกัดให้ชัดเจน หากไม่มีหัวข้อนี้ subagent จะเริ่มด้นสด

เขียนเนื้อหาในไฟล์ให้มีความยาว 200–500 บรรทัด หากยาวกว่านี้ ให้ย้ายข้อมูลอ้างอิงที่ยาวไปยังไฟล์อื่นที่อยู่ใกล้กัน แล้วใส่ลิงก์ใน prompt

เขียน Description อย่างไรให้ Claude เรียกใช้ Subagent แน่นอน#

ปัญหาที่พบบ่อยคือการตั้งค่า subagent สำหรับ code review แต่ Claude กลับทำทุกอย่างเองโดยไม่ใช้ agent โดยมากมีสาเหตุเดียวคือเขียน description ว่า “ตัวช่วยสำหรับ code review” Claude จึงไม่เข้าใจว่าควรเรียกใช้เมื่อใด

สูตรเขียน Description ที่มีประสิทธิภาพ (3 ส่วน)

ส่วนที่ 1 — มันทำอะไร เขียนหนึ่งประโยคเกี่ยวกับผลลัพธ์ ไม่ใช่กระบวนการ ไม่ใช่ “วิเคราะห์โค้ด” แต่เป็น “ค้นหาช่องโหว่ในโค้ดและส่งรายการที่ระบุระดับความรุนแรงพร้อมวิธีแก้กลับมา”

ส่วนที่ 2 — เรียกใช้เมื่อใด เขียน 3–5 วลีในเครื่องหมายอัญประกาศตามที่ผู้ใช้ร้องขอจริง อย่าเดา ให้ดูประวัติแชตและถ้อยคำที่ใช้จริง

ส่วนที่ 3 — ห้ามเรียกใช้เมื่อใด เขียน 1–2 วลีเกี่ยวกับงานคล้ายกันที่ subagent นี้ไม่ควรตอบสนอง หากไม่มีส่วนนี้ agents สองตัวที่คล้ายกันจะขัดแย้งกันตลอดเวลา

วิเศษตรงวลี “ใช้เชิงรุก”

เอกสารประกอบอย่างเป็นทางการของ Anthropic ให้คำแนะนำโดยตรงดังนี้:

กล่าวอีกอย่างคือ โดยปกติ Claude มีแนวโน้ม ไม่ เรียกใช้ subagent หาก description ไม่มีสัญญาณที่ชัดเจน ให้เพิ่ม “ใช้เชิงรุก” หรือ “ใช้ทันทีหลังเขียนโค้ด” แล้วการเรียกใช้จะเพิ่มขึ้นอย่างมาก

ตัวอย่าง Description ที่ดี

description: |
  Expert code review specialist. Proactively reviews code for quality,
  security, and maintainability. Use immediately after writing or
  modifying code. Returns prioritized list of issues with severity
  and fix recommendations.
  Do not invoke for documentation changes, README edits, or commit
  message rewrites - these are handled by doc-maintainer.

สิ่งที่ได้ผลในตัวอย่างนี้:

• คำกริยา “reviews” + “returns” ระบุผลลัพธ์ที่จับต้องได้ ไม่ใช่กระบวนการ
• “Proactively” และ “immediately after” เป็นเงื่อนไขเรียกใช้ที่ชัดเจน
• “Do not invoke for...” ป้องกันการขัดแย้งกับ subagent ที่คล้ายกัน
• ใช้ภาษาอังกฤษใน description เป็นเรื่องปกติ Claude จับคู่ได้ดีกว่าเมื่อใช้ภาษาอังกฤษ

บทบาท Subagent พร้อมใช้ 5 แบบที่ตั้งค่าได้ใน 10 นาที#

แต่ละบทบาทด้านล่างคือไฟล์เดียว .claude/agents/<name>.md หลังสร้างไฟล์แล้ว ให้เริ่ม Claude Code ใหม่ เปิด /agents และตรวจว่า agent ใหม่ปรากฏในรายการ จากนั้นเรียกใช้ด้วย @agent-name ได้เลย

1. code-reviewer — ตรวจโค้ดหลังการเปลี่ยนแปลงทุกครั้ง

นี่คือตัวอย่างอย่างเป็นทางการจากเอกสารของ Anthropic ซึ่งปรับให้เข้ากับกระบวนการทำงาน:

---
name: code-reviewer
description: |
  Expert code review specialist. Proactively reviews code for quality,
  security, and maintainability. Use immediately after writing or
  modifying code.
tools: Read, Grep, Glob
model: inherit
color: blue
---

You are a senior code reviewer ensuring high standards of code quality.

When invoked:
1. Read the diff and changed-file list supplied by the main session. If missing, ask the main session to provide them.
2. Use Read, Grep, and Glob to inspect the relevant files.
3. Return findings without changing files or running shell commands.

Review checklist:
- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Test coverage adequate
- Performance considerations addressed

Provide feedback organized by priority:
- Critical issues (must fix before merge)
- Warnings (should fix)
- Suggestions (consider improving)

Format: for each issue - file:line + 1 sentence why it's a problem + concrete fix.

หัวใจคือ tools: Read, Grep, Glob ผู้รีวิวมีเครื่องมืออ่านและค้นไฟล์ ไม่มี Bash, Write หรือ Edit เซสชันหลักเตรียม diff ส่งให้ การสั่งให้รันเพียง git diff ไม่ได้จำกัด Bash ที่ให้เต็มสิทธิ์

2. security-auditor — ค้นหาช่องโหว่และข้อมูลรั่วไหล

บทบาทนี้ใช้ opus เพื่อเหตุผลลึกและจำกัดเครื่องมือ Read, Grep, Glob เช่นกัน เทมเพลตอ่านอย่างเดียวนี้เว้น persistent memory เพราะเปิด agent memory แล้วได้ความสามารถเขียน memory ด้วย:

---
name: security-auditor
description: |
  Security audit specialist. Use proactively to find OWASP Top 10
  vulnerabilities, exposed secrets, injection risks, broken auth.
  Run before any deploy or merge to main.
tools: Read, Grep, Glob
model: opus
color: red
---

You are a security auditor. Find exploitable vulnerabilities, not style issues.

Audit checklist:
- SQL / NoSQL injection
- XSS (stored, reflected, DOM-based)
- CSRF / SSRF risks
- Hardcoded secrets (API keys, tokens, passwords)
- Broken auth / session management
- Insecure deserialization
- Missing input validation
- Path traversal
- Open redirects
- Insecure direct object references (IDOR)

For each finding:
- Severity: Critical / High / Medium / Low
- File:line
- Attack scenario in 1–2 sentences
- Fix recommendation with code example

Skip linter or style noise. Report only exploitable issues.

เครื่องมือเป็นแบบอ่านอย่างเดียว พร้อมใช้ model: opus สำหรับการตรวจสอบที่ซับซ้อน เช่น การเชื่อมโยงช่องโหว่หลายขั้น

3. research-agent — ค้นคว้าเชิงลึกจากแหล่งข้อมูลตั้งแต่ 8 แห่งขึ้นไป

รูปแบบนี้ Anthropic อธิบายไว้ในบทความเกี่ยวกับระบบวิจัยแบบหลายเอเจนต์ของตน จุดสำคัญคือกำหนดรูปแบบผลลัพธ์ให้ชัดและห้ามส่งผลดิบจำนวนมาก:

---
name: research-agent
description: |
  Deep web research specialist. Use proactively for fact-finding,
  competitive analysis, gathering external documentation, comparing
  approaches across multiple sources.
tools: WebFetch, WebSearch, Read, Write
model: sonnet
maxTurns: 30
color: purple
---

You are a research analyst. Goal: synthesized brief, not raw search dumps.

Process:
1. Decompose the question into 3–5 sub-queries
2. WebSearch each sub-query, fetch top 3–5 sources per query
3. Cross-verify claims across at least 2 independent sources
4. Reject SEO-farm and aggregator content; prefer primary sources
5. Quote verbatim with URL attribution for any specific claim
6. Return: TL;DR (3 bullets) + Findings + Sources (8+ domains minimum)

Anti-patterns to avoid:
- Don't cite a fact from a single source
- Don't paraphrase quotes as if they were verbatim
- Don't return raw search result dumps to the parent
- Don't include filler intro / outro ("Hope this helps")

maxTurns: 30 เป็นมาตรการป้องกันไม่ให้การค้นคว้าวนซ้ำไม่รู้จบ Anthropic รายงานตัวเลขนี้ในระบบวิจัยแบบหลายเอเจนต์ของตน:

ตัวเลขเก้าสิบเปอร์เซ็นต์หมายถึงงานทดสอบเกณฑ์มาตรฐานด้านการวิจัย ในทางปฏิบัติ ผลที่ได้จากงานธุรกิจจะน้อยกว่า แต่โดยรวมมีขนาดใกล้เคียงกัน

4. doc-maintainer — ดูแลเอกสารให้สอดคล้องกับโค้ด

บทบาทนี้ใช้ model: haiku ซึ่งเป็นตัวอย่างทั่วไปของ “การควบคุมค่าใช้จ่าย” งานเอกสารไม่จำเป็นต้องใช้ Opus; Haiku ทำงานได้ในราคาหนึ่งในสาม:

---
name: doc-maintainer
description: |
  Documentation sync specialist. Use after merging features to update
  README, API docs, CHANGELOG. Reads recent commits, identifies
  undocumented changes, updates docs proactively.
tools: Read, Write, Edit, Glob, Grep, Bash
model: haiku
memory: project
color: green
---

You maintain documentation in sync with code.

When invoked:
1. Run `git log --since="last release"` to see recent changes
2. Read README.md, docs/, CHANGELOG.md
3. Identify gaps: new features without docs, removed APIs still
   documented, version mismatches

Output:
- Updated files (use Edit, not Write - preserve existing structure)
- CHANGELOG.md entry in Keep-A-Changelog format
- List of changes you made (actual diff summary, not paraphrase)

Style rules:
- Active voice, present tense
- Code examples must be copy-pasteable
- No marketing language ("powerful", "robust", "seamless")
- No filler ("This guide will help you...")

5. refactor-agent — ทำ refactoring อย่างปลอดภัยผ่าน worktree

บทบาทนี้ใช้ isolation: worktree ซึ่งหมายความว่า subagent ทำงานในสำเนาแยกของ repository และคุณจะ merge ก็ต่อเมื่อเห็นว่าเรียบร้อย:

---
name: refactor-agent
description: |
  Safe refactor specialist. Use for renames, extracts, inlines that
  shouldn't touch your working copy until reviewed. Runs in a
  temporary git worktree.
tools: Read, Edit, Write, Bash, Grep, Glob
model: sonnet
isolation: worktree
permissionMode: acceptEdits
color: yellow
---

You refactor code without changing behavior.

Strict rules:
1. Tests must pass BEFORE and AFTER the refactor.
   If pre-refactor tests fail, STOP and report.
2. One atomic refactor per commit (extract, rename, inline).
3. Never change public APIs without explicit instruction.
4. Never modify tests unless they test the refactored implementation
   directly.

Process:
- Run test suite -> baseline
- Make atomic refactor
- Run test suite -> verify
- Commit with conventional message: refactor(scope): what

Return: summary of changes + worktree path so user can diff and merge.

ด้วยบทบาทนี้ ปัญหาการ refactoring ที่ชวนปวดหัวที่สุด—“ฉันทำพังแล้วไม่รู้จะย้อนกลับอย่างไร”—จะหมดไป สำเนาต้นฉบับยังคงเดิม และ subagent ทำงานใน worktree ที่แยกไว้

เปิดใช้ 5 Subagents พร้อมกัน: Orchestrator + Workers#

การประสานงานแบบขนานมีรูปแบบ “วาทยกร + วงออร์เคสตรา” วาทยกรถือแผนไว้ ไม่ได้เขียนโน้ตดนตรีเอง และตรวจสอบสิ่งที่นักดนตรีเล่น หากมีใครเล่นผิด วาทยกรจะขอให้เล่นใหม่ แทนที่จะพยายามทำงานจนเสร็จแทนเขา

สำหรับผู้ประกอบการ อุปมาที่ใกล้ตัวกว่าคือบริษัทการตลาดที่เตรียมกลยุทธ์ให้ลูกค้าใหม่ นักวิเคราะห์คนหนึ่งทำ SWOT อีกคนวิเคราะห์คู่แข่ง คนที่สามสร้างโปรไฟล์กลุ่มเป้าหมาย นักวิเคราะห์อาวุโสคัดสมมติฐานที่ไม่สอดคล้องกับงบประมาณออก และผู้จัดการโครงการรวบรวมเป็นงานนำเสนอฉบับสุดท้าย ใน Claude Code กระบวนการนี้เริ่มด้วยประโยคเดียว และมีผู้วิจารณ์เป็นส่วนหนึ่งของกระบวนการตั้งแต่ต้น ไม่ได้มาทีหลัง

Prompt สำหรับการประสานงานแบบขั้นต่ำ

แค่ประโยคเดียวในแชตหลักก็เพียงพอ:

Launch five subagents in parallel: three research-agents on different sources
(Anthropic docs, GitHub repos, AI bloggers), one critic-agent to filter out
weak conclusions, and one summary-agent for the final document.

Context: I am writing a guide about X. Target length: 2,000 words with sources.
Before starting, each one reads CLAUDE.md.

จากนั้น Claude จะมอบหมายงานให้ agents ทั้งห้า แต่ละตัวทำงานในบริบทของตัวเอง: research agents ใช้แหล่งข้อมูลของตน critic คัดกรอง และ summary agent รวบรวม มีเพียงสรุปสุดท้ายเท่านั้นที่ส่งกลับมายังแชตหลัก

กรณีที่การทำงานขนานกันคุ้มค่า

ไม่ได้คุ้มค่าเสมอไป การทำงานแบบขนานเหมาะสมก็ต่อเมื่อ:

1. งาน เป็นอิสระต่อกัน หาก research-agent #2 รอผลจาก research-agent #1 ก็จะไม่มีการทำงานแบบขนาน ทั้งคู่จะทำงานเรียงลำดับกันในทางปฏิบัติ
2. งาน ใช้เวลานาน การทำงานขนานเพื่อ “ตัดช่องว่างท้ายบรรทัด” ไม่มีประโยชน์ เพราะค่าใช้จ่ายในการเปิด subagents จะกินผลประโยชน์ที่ได้
3. คุณมี โควตาเพียงพอ รายละเอียดเพิ่มเติมอยู่ในหัวข้อแยกด้านล่าง subagents ที่ทำงานขนานกันใช้โทเค็นอย่างรวดเร็ว

Multi-Agent v2 ของ Anthropic: ก้าวต่อไป

ในเดือนพฤษภาคม 2026 Anthropic เปิดตัว Multi-Agent Orchestration v2 ซึ่งแตกต่างจากแนวทางดั้งเดิมที่เปิดใช้ subagents ขนานกันอยู่ 3 ประเด็นสำคัญ อ่านเพิ่มเติมในหัวข้อถัดไป

มีอะไรใหม่ใน Multi-Agent v2: Orchestration, Outcomes, Dreaming#

Multi-Agent Orchestration: ระบบไฟล์ที่ใช้ร่วมกัน + การตรวจสอบระหว่างทำงาน

Anthropic อธิบายฟีเจอร์นี้ไว้ดังนี้:

ความแตกต่างสำคัญจาก subagents แบบเดิมคือ ระบบไฟล์ที่ใช้ร่วมกัน ก่อนหน้านี้ subagent แต่ละตัวทำงานแยกจากกันโดยสิ้นเชิง และแลกเปลี่ยนข้อมูลกันได้ผ่านสรุปที่ส่งกลับมาเท่านั้น ตอนนี้ผู้เชี่ยวชาญสามารถเขียนลงโฟลเดอร์ที่ใช้ร่วมกันได้ และ lead agent อ่านผลลัพธ์ได้ระหว่างที่งานกำลังดำเนินไป ไม่ต้องรอจนจบ วิธีนี้ช่วยแก้ปัญหา “ทุกคนทำงานกันทั้งวัน แต่สุดท้ายกลับพบว่ามีสองคนใช้แนวทางที่เข้ากันไม่ได้”

อีกเรื่องคือ การตรวจสอบระหว่างทำงาน Lead agent หยุดงานชั่วคราวแล้วถามผู้เชี่ยวชาญคนใดก็ได้ว่า “เป็นอย่างไรบ้าง” จากนั้นปรับแผนโดยรวมได้ วิธีนี้ใกล้เคียงกับการทำงานของผู้จัดการทีมจริง ๆ

Outcomes: ใช้เกณฑ์ประเมินแทนคำสั่งทีละขั้นตอน

ด้วย Outcomes คุณเขียนเกณฑ์ความสำเร็จ แล้ว agent จะหาวิธีทำให้บรรลุเกณฑ์นั้น Grader แยกต่างหากจะตรวจสอบผลลัพธ์ในบริบทของตัวเอง เพื่อไม่ให้ “ปนเปื้อน” ด้วยการให้เหตุผลของ agent หลัก

การเพิ่มขึ้นสิบเปอร์เซ็นต์ในงานที่ท้าทายถือเป็นผลที่มาก โดยเฉพาะเมื่อตั้งโจทย์ว่า “จัดทำบทความยาวที่ตรงตามเกณฑ์คุณภาพเหล่านี้” แทนที่จะเป็น “ทำตามขั้นตอน 1–7”

Dreaming: Agents สั่งสมประสบการณ์ระหว่างเซสชัน

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

Anthropic รายงานว่า Harvey (บริษัทเทคโนโลยีกฎหมาย) พบว่าอัตราความสำเร็จในงานร่างเอกสารกฎหมายเพิ่มขึ้นประมาณหกเท่าหลังนำ Dreaming มาใช้ ฟีเจอร์นี้ทำงานจริงในระบบ production แล้ว ไม่ใช่แค่การสาธิต

สิ่งนี้หมายถึงอะไรสำหรับผู้ประกอบการที่ไม่เขียนโปรแกรม

ขณะนี้ Multi-Agent Orchestration ใช้งานได้ผ่าน Claude Agent SDK แต่ยังใช้โดยตรงใน CLI ของ Claude Code ไม่ได้ อย่างไรก็ตาม แนวทางชัดเจนแล้ว: การประสานงานกำลังเปลี่ยนจาก “คุณเปิด subagents จำนวน N ตัวด้วยตนเอง” เป็น “คุณอธิบายงาน แล้ว lead agent ตัดสินใจว่าจะมอบหมายให้ใครและอย่างไร” หากเพิ่งเริ่มใช้ subagents ยังไม่ต้องกังวลกับ v2 เรียนรู้รูปแบบดั้งเดิม “แชตหลัก 1 แชต + subagents 3–5 ตัวที่มีบทบาทแตกต่างกัน” แล้วใน 3–6 เดือน คุณก็ปรับไปใช้ Managed Agents ได้อย่างเป็นธรรมชาติ

7 ข้อผิดพลาดที่ทำให้ Subagents ไปต่อไม่ได้#

ข้อผิดพลาด 1. Description แบบ “ตัวช่วยสำหรับ X” ไม่กระตุ้นให้เรียกใช้

อาการ: คุณเขียน subagent ตรวจสอบโครงสร้างแล้ว ทุกอย่างถูกต้อง แต่ Claude ไม่เรียกใช้งานเมื่อตอบคำขอของผู้ใช้ สาเหตุแทบจะเหมือนกันทุกครั้ง: description เป็นนามธรรม เช่น “ตัวช่วยสำหรับ code review” วิธีแก้: เขียนวลีที่ผู้ใช้พูดจริง 3–5 วลีในเครื่องหมายอัญประกาศลงใน description โดยตรง พร้อมกับ “ใช้เชิงรุก” / “ใช้ทันทีหลังจาก”

ข้อผิดพลาด 2. สร้าง Subagent ทั้งที่ควรใช้ Skill

Subagent มีค่าใช้จ่ายมากกว่า Skill เพราะสร้างบริบทของตัวเอง โหลด system prompt ของตัวเอง และใช้โทเค็นมากกว่า หากงานสั้น ไม่ใช้บริบทหลักมาก และทำได้ในรอบเดียว ก็ควรใช้ Skill ไม่ใช่ subagent ตัวอย่างรูปแบบที่ไม่ควรทำ: subagent format-validator ที่ตรวจ JSON schema เทียบกับกฎ 20 ข้อ งานนี้ควรใช้ Skill เพราะใช้โมเดลเดียว ไม่จำเป็นต้องแยกบริบท และไม่ต้องโหลดบริบทเพิ่มเติม

ข้อผิดพลาด 3. เปิด “agents 60 ตัวพร้อมกัน” ตั้งแต่เริ่ม

นี่คือภาพลวงตาที่แพร่หลายที่สุด คุณเห็นทวีตว่า “ฉันมี agents 1,500 ตัวกำลังทำงาน” แล้วคิดว่า “ฉันก็ควรทำแบบนั้นเหมือนกัน” ในทางปฏิบัติ agents 60 ตัวใช้โควตาแผน Pro หมดภายในหนึ่งชั่วโมง สร้างผลลัพธ์ที่ขัดแย้งกันเป็นกอง และสุดท้ายเมื่อหมดวันก็ไม่มีอะไรเสร็จ

ผู้ใช้งานจริงคนหนึ่งบน Medium อธิบายไว้ว่า:

วิธีแก้: เริ่มจาก subagent หนึ่งตัวกับงานหนึ่งงาน เมื่อชำนาญแล้วค่อยเพิ่มตัวที่สองซึ่งมีบทบาทต่างกัน เมื่อชำนาญการประสานงานสองตัวแล้ว จึงขยับไปสู่ทีม 3–5 ตัว การกระโดดจาก “เพิ่งติดตั้ง Claude Code เมื่อวาน” ไปเป็น “วันนี้เปิดพร้อมกัน 20 ตัว” รับประกันว่าจะทำให้โค้ดเสียและใช้โควตาหมด

ข้อผิดพลาด 4. ให้เครื่องมือทั้งหมดแก่ทุก Agent

หาก code reviewer ของคุณใช้ Bash, Write และ WebFetch ได้ นั่นเป็นช่องโหว่ด้านความปลอดภัยและค่าใช้จ่ายขนาดใหญ่ reviewer ไม่ควรมีสิทธิ์เขียนไฟล์ ยิ่งไม่ควรเข้าถึงอินเทอร์เน็ต

วิธีแก้: จำกัด tools อย่างเข้มงวด Code reviewer ใช้เพียง Read, Grep, Glob security auditor ใช้เครื่องมืออ่าน/ค้นชุดเดียวกันและรับ diff จากเซสชันหลัก การเพิ่ม Bash ให้ความสามารถ shell ไม่ได้จำกัดเป็น git diff อัตโนมัติ Research agent ใช้ WebFetch, WebSearch, Read, Write อย่าให้สิทธิ์ subagent มากกว่าที่ต้องใช้สำหรับงานเฉพาะหนึ่งงาน

ข้อผิดพลาด 5. Subagent ส่งผลดิบจำนวนมากเข้า Main Context

หาก research agent ส่ง “นี่คือหน้าเว็บทั้ง 30 หน้าที่ฉันเจอ ลองไปจัดการต่อเอง” กลับไปยังแชตหลัก คุณก็เสียข้อดีสำคัญที่สุดของ subagents ไปแล้ว นั่นคือการแยกสิ่งรบกวน วิธีแก้: ระบุรูปแบบผลลัพธ์ใน system prompt ของ subagent อย่างชัดเจน “ส่งกลับเฉพาะ: TL;DR 3 bullet + รายการแหล่งข้อมูล 5 แห่ง ห้ามส่งโค้ดจำนวนมาก ห้ามส่งผลการค้นหาดิบ” รูปแบบนี้ควร เข้มงวด subagent ไม่ควรมีอิสระที่จะ “เขียนเป็นเรียงความ”

ข้อผิดพลาด 6. เรียกใช้งานคลุมเครือ: คำขอมอบหมายงานไม่ชัดเจน

Subagent มองไม่เห็น ประวัติการสนทนาหลัก มันเริ่มต้นด้วยบริบทที่ว่างเปล่า + CLAUDE.md + สิ่งที่คุณเขียนให้โดยตรง หากคุณเขียนว่า “แก้ระบบยืนยันตัวตน” subagent ก็จะคิดข้อมูลขึ้นมาเอง ให้เขียนว่า “แก้ลูป OAuth redirect ที่หลังจากเข้าสู่ระบบสำเร็จแล้ว ผู้ใช้ถูกเปลี่ยนเส้นทางไปที่ /login แทน /dashboard ไฟล์: src/lib/auth.ts”

กฎที่ชัดเจนคือ เมื่อมอบหมายงาน ให้ข้อมูลบริบทแก่ subagent มากเท่ากับที่คุณจะให้ผู้รับเหมารายใหม่ซึ่งเพิ่งเข้าร่วมโปรเจกต์

ข้อผิดพลาด 7. ใช้ Agents ตามบทบาท แทนที่จะตามงาน

รูปแบบที่ชวนให้ลองคือ “มาสร้าง frontend-developer, backend-developer และ qa-engineer แล้วให้ทำงานเป็นทีมกัน” วิธีนี้ใช้ไม่ได้ แต่ละ “บทบาท” ขาดบริบทของโปรเจกต์โดยรวม และตกลงรายละเอียดกันไม่ได้เพราะมองไม่เห็นงานของกันและกัน

วิธีแก้: subagent ควรจัดการ งาน ที่เกิดซ้ำและมีผลลัพธ์ชัดเจน ไม่ใช่ บทบาท แทนที่จะใช้ “frontend-developer” ให้ใช้ “explore-ui-tree”, “refactor-component”, “audit-accessibility” Subagent ที่จัดตามงานแต่ละตัวทำงานเฉพาะอย่างหนึ่งและส่งผลลัพธ์เฉพาะอย่างหนึ่งกลับมา

Subagents แบบขนานมีค่าใช้จ่ายเท่าไร และคุ้มค่าเมื่อใด?#

หากเปิด subagents แบบขนาน 5 ตัวเพื่อทำงานซับซ้อน แผน Pro จะหมดภายในหนึ่งชั่วโมง Max 5x ($100) เป็นระดับขั้นต่ำที่สมเหตุสมผลสำหรับการทำงานขนานเป็นประจำ สำหรับทีมและ Enterprise เรื่องค่าใช้จ่ายจัดการกันในระดับงบประมาณเครื่องมืออยู่แล้ว

อ่านเพิ่มเติมเกี่ยวกับการประหยัดโทเค็นใน Claude Code ได้ในคู่มือแยกเรื่องขีดจำกัด กฎสำคัญสำหรับ subagents คือ จะคุ้มค่าเมื่องานต้องใช้สมาธิ อย่างน้อย 10 นาที หากงานสั้นกว่านั้น อย่าสร้าง subagent ให้ทำในแชตหลักหรือใช้ Skill

ผสาน Subagents เข้ากับ CLAUDE.md, Skills และ Second Brain อย่างไร?#

ก่อนสร้างผู้เชี่ยวชาญตัวแรก Subagent ต้องอาศัยสิ่ง 3 อย่างที่ควรมีอยู่ในโปรเจกต์ของคุณก่อน:

1. CLAUDE.md ที่เหมาะสม Subagent อ่าน CLAUDE.md ก่อนเริ่ม ซึ่งเป็นเหมือน “สัญญาจ้างงาน” หากไม่มีไฟล์นี้ subagent ก็ไม่รู้บริบทโปรเจกต์ ข้อจำกัด หรือโทนที่ต้องใช้ และจะคิดข้อมูลขึ้นมาเอง

2. Skills พื้นฐาน Skill คือวิธีการที่รวมเป็นแพ็กเกจ Subagent โหลดเฉพาะ Skills ที่ต้องใช้ ไม่ใช่ทั้งหมดพร้อมกัน หากไม่มี Skills subagent ก็ทำงานเดิมซ้ำจากศูนย์ทุกครั้ง

3. Second Brain: โครงสร้างความรู้ โฟลเดอร์ business/ (หรือโฟลเดอร์เทียบเท่าในสาขาของคุณ) คือคลังที่ subagents ทุกตัวใช้ค้นข้อมูล หากไม่มีสิ่งนี้ subagent ก็จะให้คำตอบ ChatGPT ทั่วไปที่ไม่ต่างจากคำตอบของใคร

การกลับลำดับเช่นนี้จะทำให้ได้กระแสโดยไม่มีผลลัพธ์ “ฉันมี subagents 60 ตัวทำงานขนานกัน” แต่โฟลเดอร์ business/ ว่างเปล่า ก็เท่ากับมีเซสชัน ChatGPT ทั่วไป 60 เซสชันที่ใช้แนวทางเดียวกัน

วิธีเริ่มต้นที่เร็วที่สุดคือคัดลอก code-reviewer จากตัวอย่างแรกด้านบนไปไว้ใน .claude/agents/code-reviewer.md เริ่ม Claude Code ใหม่ แล้วเรียกใช้ @agent-code-reviewer ใน commit ถัดไปของคุณ ภายใน 5 นาที คุณจะรู้ว่าต้องใช้ subagents หรือแชตหลักก็เพียงพอแล้ว