Subagent

สถานะ: 🟢 Complete | อัพเดท: 2026-07-11

Subagent, Skill และการออกแบบ Workflow ใน Claude Code

1. Subagent คืออะไร

Subagent = Claude อีกตัวหนึ่งที่ทำงานแยก context window ของตัวเอง มีระบบพรอมต์เป็นของตัวเอง มีสิทธิ์ใช้ tools ที่กำหนดได้เอง เลือก model ได้เอง

เมื่อ main session เจองานที่ตรงกับหน้าที่ของ subagent ตัวไหน จะ “โยนงาน” ไปให้ทำ แล้วรับกลับมาแค่ สรุปผล — รายละเอียดที่ subagent ค้น/รัน/ลองผิดลองถูก จะไม่ไหลกลับเข้ามาในบทสนทนาหลักให้รก

Built-in subagent ที่มีอยู่แล้ว

• Explore — ค้นหาโค้ด อ่านอย่างเดียว
• Plan — ค้นข้อมูลช่วงวางแผน (plan mode)
• general-purpose — งานซับซ้อนที่ต้องทั้งสำรวจและแก้ไข

---

2. โครงสร้างไฟล์ subagent

---
name: code-reviewer          # required, ไม่ซ้ำใคร
description: ...             # required, Claude ใช้ตัดสินใจว่าเมื่อไหร่ควร delegate
tools: Read, Grep, Glob      # optional, ไม่ใส่ = inherit ทุก tool
model: sonnet                # optional, ค่า default = inherit จาก main session
skills:
  - some-skill                # optional, preload เนื้อหา skill เต็มเข้า context ตั้งแต่ spawn
memory: project               # optional, ให้ subagent มีความจำข้ามเซสชัน
---
 
system prompt ของ subagent อยู่ตรงนี้

ตำแหน่งไฟล์ (scope)

Location	Scope	เหมาะกับ
.claude/agents/	เฉพาะโปรเจกต์นี้	subagent ที่ผูกกับเครื่องมือ/โครงสร้างเฉพาะโปรเจกต์
~/.claude/agents/	ทุกโปรเจกต์ในเครื่อง	SOP/นิสัยการทำงานส่วนตัวที่ใช้ซ้ำได้ทุกที่

local ชนะ global ถ้าชื่อซ้ำกัน

---

3. Global vs Local — เมื่อไหร่ควรใช้แบบไหน

• Local เหมาะกับ subagent ที่ผูกกับ context เฉพาะโปรเจกต์ (เช่น เครื่องมือเฉพาะเกม) และอยากแชร์ทีมผ่าน git
• Global เหมาะกับ SOP ส่วนตัวที่ใช้ได้ทุกโปรเจกต์ (เช่น pipeline: research → plan → implement → review)

---

4. Skill vs Subagent — คนละกลไก

	Subagent	Skill
คืออะไร	”ใคร/context แยก” ที่ทำงาน	”วิธีการ/ความรู้” ที่ใส่เข้าไปในงาน
Reuse ข้าม subagent อื่นได้ไหม	ไม่ได้โดยตรง	ได้ — subagent หลายตัวเรียก skill เดียวกันได้
ผูกกับ context แยกไหม	ผูก (context window ของตัวเอง)	ไม่ผูก — โหลดเข้า context ของผู้เรียก

ใส่ skill ใน subagent ได้ 2 แบบ

1. ไม่ใส่ skills: field — subagent ยังเรียก skill ที่ติดตั้งไว้เองอัตโนมัติได้ผ่าน Skill tool ตามสถานการณ์
2. ใส่ skills: field — บังคับ preload เนื้อหาเต็มของ skill นั้นตั้งแต่ spawn การันตีว่าถูกใช้แน่นอน เหมาะกับ workflow ที่ตายตัว ไม่อยากเสี่ยงให้ Claude ลืมเรียก

เขียนฝังในตัว subagent เลย vs สร้างเป็น skill แยก

• ใช้ซ้ำหลายที่ → ทำเป็น skill (แก้ที่เดียว มีผลทุกจุด)
• เฉพาะเจาะจงกับ subagent ตัวเดียว ไม่มีวันใช้ที่อื่น → เขียนฝังในตัว subagent ได้เลย ไม่ต้อง over-engineer

---

5. Orchestrator vs Controller

• Orchestrator = ตัวที่ “สั่งงาน” จัดลำดับว่าใครทำอะไรก่อนหลัง ส่งงานต่อให้ใคร
• Controller = ตัวที่ “ตัดสินใจ/อนุมัติ” ที่จุด gate ว่าจะไปต่อได้ไหม

ข้อสรุปสำคัญ: อย่าทำ orchestrator เป็น subagent แยกต่างหากสำหรับ workflow ที่มี approval gate ต้องรอมนุษย์ตัดสินใจ เพราะ subagent มี context แยก คุณจะไม่เห็นและแทรกแซงระหว่างทางไม่ได้ — ควรให้ main session เป็น orchestrator (เดินตามสคริปต์ที่เขียนไว้) และหยุดรอให้ คุณเป็น controller ที่จุด gate

---

6. ตัวอย่าง Workflow ที่ออกแบบร่วมกัน

main session (orchestrator, model: opus/fable)
  │
  ▼
docs-researcher (sonnet, skill: skill A)
  │ สรุปเอกสาร
  ▼
readiness-checker (opus หรือย้ายมาที่ main session)
  │ GO / NOT-GO ← [รออนุมัติจากคุณ]
  ▼
planner (opus)
  │ เขียนแผน
  ▼
scrutinizer (opus, skill: skill B) ← subagent ใหม่เสมอ ไม่ resume
  │ ผ่าน/ไม่ผ่าน ← [ถ้าไม่ผ่านกลับไป planner]
  ▼
implementer (sonnet, skill: skill C) ← resume ได้ ทำต่อเนื่องทีละ phase
  │ ทำทีละ phase
  ▼
scrutinizer (เรียกซ้ำทุกจบ phase) ← subagent ใหม่ทุกครั้งเช่นกัน
  │
  ▼ (วนจนครบทุก phase)

---

7. Model routing — ใช้โมเดลต่างกันตามงาน

• model field ของแต่ละ subagent independent จาก main session เด็ดขาด
• ไม่ใส่ = inherit จาก main session (ถ้า main เป็น opus subagent ก็จะเป็น opus ไปด้วยโดยไม่ตั้งใจ)
• หลักคิด: gate/ตัดสินใจ/วางแผน → opus, execute งานตามคำสั่งที่ชัดแล้ว → sonnet

---

8. ที่เก็บ Workflow — CLAUDE.md vs Skill

• CLAUDE.md: โหลดอัตโนมัติทุก session เสมอ ไม่มีกลไกเลือก เหมาะกับกฎที่ apply ทุกครั้งไม่มีทางเลือก (เช่น “ห้าม commit โดยไม่ขอ”)
• Skill: เรียกได้ตามชื่อ เหมาะกับ workflow ที่มีหลายแบบให้เลือกใช้ตามสถานการณ์ — เขียนได้หลาย workflow-skill โดยใช้ subagent global ชุดเดียวกันร่วมกัน

---

9. เศรษฐศาสตร์ Token — ต้นทุนของแต่ละอย่าง

ประเภท	ต้นทุนตอนสร้างทิ้งไว้ไม่ใช้	ต้นทุนตอนถูกเรียกใช้จริง
Skill (global)	ต่ำมาก (~100 token/ตัว/session สำหรับ description)	ปานกลาง (โหลดเนื้อหาเต็มตอน invoke)
Skill (local)	แทบศูนย์นอกโปรเจกต์นั้น	เท่า global
Subagent	ต่ำ (แค่ description)	สูง (เปิด context window ใหม่ทั้งก้อน)
CLAUDE.md ฝัง workflow ตรงๆ	สูงเสมอ ไม่ว่าใช้หรือไม่	เท่าเดิม

ข้อสรุป: subagent เป็น global + workflow เป็น skill แยก คือแนวทางประหยัด token ที่สุด — อย่าฝัง workflow เต็มๆ ลงใน CLAUDE.md

---

10. หลักเลือกจังหวะ spawn subagent (ไม่พร่ำเพรื่อ)

Spawn subagent เมื่อเข้าเกณฑ์ครบ 3 ข้อ:

1. สร้าง noise เยอะ (อ่าน/รัน/ค้นหาจำนวนมาก)
2. ผลลัพธ์สุดท้ายสรุปสั้นได้ (ไม่ต้องเก็บรายละเอียดระหว่างทาง)
3. ไม่ต้องพึ่งบริบทของบทสนทนาหลัก (งาน self-contained)

ถ้าขาดข้อใดข้อหนึ่ง → ทำในบทสนทนาหลักแทน อย่า spawn

ข้อควรระวังเพิ่มเติม:

• จับกลุ่มงานย่อยที่เกี่ยวเนื่องกันเป็นคำสั่งเดียว ไม่ spawn ทีละจิ๊บจ๊อย
• Parallel spawn คุ้มเฉพาะงานที่ independent จริงๆ ไม่พึ่งผลกันและกัน
• สั่งให้ subagent “สรุปสั้นๆ” ผลลัพธ์กลับมา ไม่ปล่อยให้รายงานทุกอย่างที่เจอ

---

11. Resume vs Memory — subagent ปิดหรือค้างไว้

• ค่า default: spawn ใหม่ทุกครั้ง แล้วปิดไปหลังส่งมอบงาน ไม่ค้าง process
• Resume ได้ ถ้าสั่งชัดเจน (subagent เดิมจะจำบทสนทนาเก่าทั้งหมด) — transcript เก็บแยกไฟล์ ~30 วัน
• เมื่อไหร่ควร resume: งานต่อเนื่องกันจริง เช่น implementer แก้ปัญหาต่อจากที่เพิ่งทำ
• เมื่อไหร่ไม่ควร resume: subagent ที่ทำหน้าที่ตรวจสอบอิสระ เช่น scrutinizer — resume จะทำให้เกิด anchoring bias (เอนเอียงตามที่เคยอนุมัติไปแล้ว) ขัดกับเป้าหมายที่อยากได้มุมมองคนนอกทุกจุดตรวจ
• ทางเลือกที่ดีกว่าสำหรับ scrutinizer: ใช้ memory: project แทน — สะสม “บทเรียน/pattern” ทั่วไปข้ามรอบได้ โดยไม่กระทบความเป็นกลางต่อแผนที่กำลังตรวจ (คนละกลไกกับ resume ที่จำบทสนทนาเต็ม)

---

12. เช็คลิสต์สรุปสำหรับ workflow ส่วนตัว (research → plan → implement)

subagent	ควร spawn เป็น subagent ไหม	resume ได้ไหม
docs-researcher	ใช่ ชัดเจน (noise เยอะ)	ไม่จำเป็น
readiness-checker	borderline — ถ้างานเล็กมาก พิจารณาย้ายเข้า main session + เก็บ logic เป็น skill	-
planner	มีเงื่อนไข — ขึ้นกับต้อง explore เพิ่มไหม	ไม่จำเป็น
scrutinizer	ใช่ แต่ด้วยเหตุผลเรื่อง objectivity ไม่ใช่ token	ไม่ควร resume — spawn ใหม่ทุกครั้ง ใช้ memory แทน
implementer	ใช่ ชัดเจนที่สุด (noise เยอะ)	ควร resume เมื่อแก้ต่อเนื่องจาก phase เดิม

---

เกี่ยวข้อง

• Multi-Agent Systems — แนวคิด orchestrator/subagent ทั่วไป
• Development Workflow v2 — workflow ที่ใช้ subagent pattern นี้จริง
• Skills
• Memory

---

อ้างอิงเอกสารทางการ: code.claude.com/docs/en/sub-agents และ code.claude.com/docs/en/costs