Subagents ใน Claude Code — เลิกใช้ context window เปลือง ๆ แล้วเริ่มแตก task

เคยรู้สึกไหมครับ ว่าคุยกับ Claude Code ไปสัก 2-3 ชั่วโมง คำตอบเริ่มเพี้ยน ลืม decision ที่ตัดสินใจไปก่อนหน้า แล้วโค้ดที่แนะนำก็เริ่ม drift ออกจาก pattern เดิมของโปรเจ็กต์? 🤔

สวัสดีเพื่อน ๆ ทุกคนครับ วันนี้ผมอยากชวนคุยเรื่องที่บทความ “Claude Code Subagents: The Complete Guide to AI Agent Delegation” ของ Sathish Raju สรุปไว้ดีมาก — เป็นเรื่องที่ developer ทุกคนที่ใช้ Claude Code เกินครึ่งวันต้องเจอ คือ context window มันไม่ infinite และวิธีแก้ที่ทุกคนใช้คือ “เปิด session ใหม่” — ซึ่งก็แลกมาด้วยการที่ Claude ลืมทุกอย่างที่เพิ่งช่วยเราเข้าใจ codebase ไปหมด

ผู้เขียนเสนอทางออกที่เป็น architectural ไม่ใช่ workaround: Subagents — แตก task ออกเป็น Claude instance ตัวเล็กกว่า มี context window ของตัวเอง พอเสร็จงานคืน output สั้น ๆ กลับ main session โดยที่ tool call ระหว่างทางไม่กิน context หลัก

Subagent คืออะไร (ที่ไม่ใช่ marketing speak)

ตามคำของ Sathish: subagent คือ “a named, isolated Claude instance with its own system prompt, its own context window, its own tool access list, and its own permission mode.”

แปลเป็นภาษาคน: เป็น Claude คนละตัวกับที่คุณคุยอยู่ มี system prompt ของตัวเอง มีกล่อง context แยก เห็น tool ไม่เหมือนกัน และ permission ก็ตั้งแยก

จุดที่ผมว่าเฉียบที่สุดในบทความคือประโยคนี้: “subagents don’t enhance Claude’s intelligence but rather preserve the quality of the context that already exists.” Subagent ไม่ได้ทำให้ Claude ฉลาดขึ้น — แต่ทำให้ context หลักของเราไม่เน่า เพราะพอ session ทะลุ 2/3 ของ context limit เมื่อไหร่ คำตอบจะเริ่มเสียคุณภาพชัดเจน

Claude Code ส่งมาให้ใช้เลย 3 ตัว built-in:

• Explore — read-only, ใช้ Haiku ถูก/เร็ว, ไว้ map codebase
• Plan — เก็บ context ก่อน เสนอ approach
• General-purpose — task ที่ต้องทั้ง explore + แก้

โครงสร้างของ subagent file

แต่ละตัวเป็นไฟล์ Markdown มี YAML frontmatter ครอบ — กำหนด name, description, tools, model, permissionMode ส่วน body คือ system prompt

ตัวอย่างที่ Sathish ยกมา — Security Reviewer:

---
name: security-reviewer
description: Security-focused code reviewer. Use proactively after writing
             authentication, authorization, or data-handling code.
tools: Read, Grep, Glob
model: opus
effort: high
permissionMode: default
---

You are a senior application security engineer. Your role is to review code
for security vulnerabilities before it ships.

When invoked:
1. Run `git diff HEAD` to see recent changes
2. Identify highest-risk areas: auth flows, input handling, data exposure
3. Check for: SQL injection, XSS, IDOR, missing auth checks, secrets in code
4. Report findings as: CRITICAL / HIGH / MEDIUM / LOW with line references
5. Suggest minimal fixes — do not rewrite code

Return structured report. Do not modify files.

Key: field description ทำหน้าที่เป็น routing trigger — Claude หลักอ่านแล้วตัดสินใจว่าจะส่งงานต่อให้ subagent นี้อัตโนมัติเมื่อไหร่ ถ้าเขียน description กลวง = subagent ไม่ถูกเรียก ถ้าเขียนชัดเจน = main agent หาทันที

Subagent อยู่ตรงไหนได้บ้าง

4 ที่ ตาม priority สูง → ต่ำ:

1. Session-defined (สูงสุด)
2. Project agents → .claude/agents/ (commit เข้า repo, ทีมใช้ร่วมกัน)
3. User agents → ~/.claude/agents/ (personal tools ข้ามโปรเจ็กต์)
4. Plugin agents

แนะนำให้ใช้ /agents สร้างแบบ interactive จะได้ frontmatter ครบ — หรือสร้าง manual แล้ว verify ด้วย /agents อีกที

3 subagents ที่ใช้ใน production ได้จริง

ผู้เขียนแนะนำ 3 ตัวที่ใช้ได้ทุกโปรเจ็กต์:

1) Dependency Auditor (read-only)

• Tools: Read, Grep, Glob, Bash — disallowedTools: Edit, Write
• permissionMode: plan (ห้ามแตะไฟล์)
• หน้าที่: หา package.json/requirements.txt/go.mod/Cargo.toml → อ่าน lockfile → report CVE, version เก่า, version range หลวม

2) Test Runner & Fixer

• Tools: Read, Bash, Grep, Edit
• maxTurns: 20
• Workflow: run test → อ่าน failure → trace ไป source file ไม่ใช่ test file → fix root cause → re-run
• กฎ: ถ้า fix ไม่ได้ภายใน 3 ครั้ง ให้ stop และ report — ห้ามลบ test, ห้าม skip assertion

3) Researcher with Persistent Memory

• Tools: Read, Bash, Glob, Grep
• memory: user — เก็บ MEMORY.md ข้าม session
• Workflow: check MEMORY.md ก่อน → ค้นคว้า → update MEMORY.md ด้วย findings + sources + follow-up

ทั้ง 3 ตัวมี pattern เหมือนกัน: scope แคบ, tool เท่าที่จำเป็น, output มี structure ชัดเจน

Pattern ที่ผมว่าใช้ได้จริง: Explore → Plan → Execute

ผู้เขียนเสนอ pipeline 3 phase สำหรับ task ที่ซับซ้อน:

1. Explore — agent map ไฟล์ที่เกี่ยวข้อง (ถูก, read-only)
2. Plan — agent ออกแบบ approach
3. Execute — คน review approve ก่อน แล้วค่อยลงมือแก้

ประโยคที่สำคัญ: “The key insight is that the human review gate goes between Plan and Execute, not between Explore and Plan.” — gate ของคนต้องอยู่ระหว่าง Plan กับ Execute, ไม่ใช่ระหว่าง Explore กับ Plan

ตัวอย่าง rules ที่ใส่ใน CLAUDE.md:

## Agent Delegation Rules

### Explore-Plan-Execute pipeline
For ANY task touching more than 3 files or involving refactoring:
1. Invoke explore subagent to map relevant files
2. Use output to invoke plan subagent with specific scope
3. Present plan for approval
4. Only then invoke execute with approved plan as context

### Direct execution (no subagents)
- Quick targeted fixes (1 file, <20 lines)
- Changes to files already in conversation context
- Tasks needing frequent back-and-forth feedback

Parallel หรือ Sequential — ดูที่ dependency

Sathish เตือนชัด: “the overhead of launching a subagent is real — each one starts fresh and spends the first few turns rebuilding local understanding.”

• task ที่ใช้เวลาเป็น นาที → parallel ได้คุ้ม
• task ที่ใช้เวลาเป็น วินาที → parallel แพงกว่า serial เพราะ overhead ของการ spawn

หลักง่าย ๆ: ถ้า task A ต้องใช้ output ของ B → sequential อย่าฝืน parallel

Cost optimization — routing model ตาม tier

ที่ developer ส่วนใหญ่ลืม: subagent แต่ละตัว set model แยกได้

Pattern ที่แนะนำ:

• Main session → Opus (reasoning ระดับ architecture)
• Implementation work → Sonnet (search, code routine)
• File discovery → Haiku (lookup, transform — ถูกกว่า Opus ราว 15 เท่าต่อ token)

export CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-4-5-20250929"
claude --model claude-opus-4-6

ผลคือ Opus คุม high-level, Sonnet ทำ implementation, Haiku ทำ exploration — บิลลดเป็นหลักสิบเปอร์เซ็นต์ได้สบาย ๆ

Subagents ≠ Agent Teams

อย่าสับสนกัน:

• Subagents = ทำงานภายใน session เดียวกัน main agent มอบ task ให้ subagent แล้วรับ output กลับ
• Agent Teams = หลาย Claude Code session คุยกันได้โดยตรง (experimental, ต้อง set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1)

ผู้เขียนแนะ: “Use subagents when workers do not need to communicate with each other. Use Agent Teams when your teammates need to share discoveries mid-task, challenge each other’s assumptions, or coordinate on cross-cutting changes.”

ถ้า task ของคุณไม่ต้องการ inter-agent chat → subagent พอแล้ว stable กว่า

Takeaway สำหรับเอาไปใช้พรุ่งนี้

ประโยคปิดของ Sathish ที่ผมว่าคุ้มจดไว้:

“The skill that matters in 2026 is not writing better prompts. It is knowing how to decompose work — identifying which tasks are self-contained, which outputs can be summarized cleanly, where the human review gates belong, and which specialist agent should own which domain.”

skill ที่สำคัญในยุคนี้ไม่ใช่การเขียน prompt ให้สวย — แต่คือการ แตกงาน ให้รู้ว่า task ไหน self-contained, output ไหน summarize ได้สะอาด, gate ของคนควรอยู่ตรงไหน, และ specialist ตัวไหนควรเป็นเจ้าของ domain ไหน

ลองเริ่มแค่ 1 subagent ก่อนครับ — ผมแนะนำให้เริ่มที่ Dependency Auditor เพราะมัน read-only ปลอดภัย, run บน Sonnet ก็พอ, ใช้บ่อยสุดในงานจริง พอ workflow คงตัวค่อยขยายเป็น test-runner กับ researcher

ใครเริ่มใช้ subagent แล้วบ้าง? ตัวไหนใช้บ่อยสุดในโปรเจ็กต์? คอมเมนต์มาแชร์กันครับ 💭

Source: Sathish Raju — Claude Code Subagents: The Complete Guide to AI Agent Delegation (Apr 4, 2026)