Loop Engineering ภาคปฏิบัติ ตอนที่ 3: Sub-agents, Skills, และ Worktrees — เมื่อ Loop เดียวไม่พอ
โดย Nokka (นก-กา) | 2 กรกฎาคม 2026
TL;DR — สำหรับคนที่รีบ
ตอนที่ 2 เราสร้าง Loop แรกด้วย /goal และ /loop — แต่ Loop เดียวมีข้อจำกัด: context window เต็ม, ทำงานทีละอย่าง, ไม่มีหน่วยความจำ
ตอนที่ 3 เราจะแก้ปัญหานี้ด้วย 3 เครื่องมือ:
- Sub-agents — ให้ Agent สร้าง Agent ย่อยสำหรับงานเฉพาะ
- Skills — บันทึกความรู้ให้ Agent จำได้ข้าม session
- Worktrees — แยก environment ให้แต่ละ Agent ไม่ทับกัน
และปิดท้ายด้วย Dynamic Workflows — เมื่อคุณต้องการ Agent เป็นร้อยทำงานพร้อมกัน
1. ปัญหาของ Loop เดียว
ก่อนจะไปดู Sub-agents — มาทำความเข้าใจข้อจำกัดของ Loop แบบเดียวก่อน:
| ปัญหา | อาการ | สาเหตุ |
|---|---|---|
| Context เต็ม | Agent เริ่มลืมงานช่วงแรก | Context window มีจำกัด |
| คอขวด | ทำงานทีละอย่าง | Agent ตัวเดียวทำทุกอย่าง |
| ไม่มีหน่วยความจำ | เริ่มใหม่ทุกครั้ง | State อยู่ใน context ไม่ใช่ไฟล์ |
| ตรวจสอบตัวเอง | Agent บอกว่างานเสร็จทั้งที่ยังไม่ | คนทำงาน = คนตรวจสอบ |
ในมุมมองของผม ปัญหาเหล่านี้คือเหตุผลที่ Boris Cherny บอกว่า "My job is to write loops" — เพราะพอคุณออกแบบระบบดีๆ ระบบจะจัดการเองโดยที่คุณไม่ต้องยุ่ง
2. Claude Code Agent และ Sub-agent คืออะไร?
ก่อนจะลงรายละเอียดเรื่อง Sub-agents — มาปูพื้นความเข้าใจกันก่อน
2.1 Claude Code Agent คืออะไร?
Claude Code Agent คือ Claude ที่ทำงานใน terminal ของคุณ — เหมือนมี programmer คนหนึ่งนั่งข้างๆ คุณ สามารถอ่านไฟล์, แก้โค้ด, รันคำสั่ง, และตรวจสอบผลได้ด้วยตัวเอง [1]
ความแตกต่างระหว่าง Claude Chat กับ Claude Code Agent:
| มิติ | Claude Chat (เว็บ) | Claude Code Agent (terminal) |
|---|---|---|
| ที่ทำงาน | ในเบราว์เซอร์ | ใน terminal ของคุณ |
| เข้าถึงไฟล์ | อัปโหลดเท่านั้น | อ่าน/แก้ไฟล์ใน repo ได้ตรงๆ |
| รันคำสั่ง | ไม่ได้ | รัน bash, npm, git ได้ |
| context | จบเมื่อปิดแชท | จำได้ใน session (แต่ลืมเมื่อปิด) |
| เครื่องมือ | จำกัด | MCP, hooks, subagents, skills |
เวลาคุณพิมพ์คำสั่งใน Claude Code — คุณกำลังคุยกับ Agent ตัวหลัก (main agent) มันทำงานในวงจรที่เรียกว่า agentic loop [8]:
┌─────────────────────────────────────────────────────────┐
│ AGENTIC LOOP │
│ │
│ คุณพิมพ์ → Claude อ่าน → คิด → ทำงาน → ตรวจสอบ → ตอบ │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Gather │────▶│ Act │────▶│ Verify │ │
│ │ context │ │ (แก้โค้ด) │ │ (รัน test)│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │
│ └──────────────────────────────┘ │
│ วนซ้ำจนกว่าจะเสร็จ │
└─────────────────────────────────────────────────────────┘
ทุกครั้งที่คุณสั่งงาน — Agent จะวนใน loop นี้: อ่าน context → ทำงาน → ตรวจสอบ → ถ้ายังไม่ผ่านก็แก้ต่อ จนกว่าจะเสร็จหรือต้องการ input จากคุณ
2.2 ทำไมต้องมี Sub-agent?
ปัญหาของ Agent ตัวเดียวคือ context window มีจำกัด — ลองนึกถึงการจ้างคนเดียวทำทุกอย่าง: เขียนโค้ด, รัน test, review security, เขียน docs — คนคนนั้นจะเหนื่อมและเริ่มลืม
Sub-agents คือการจ้าง คนเฉพาะทาง มาช่วย — แต่ละคนมีหน้าที่ชัดเจน ทำงานใน context ของตัวเอง แล้วส่งผลกลับไปให้คนหลัก [1]
Claude Code team ให้คำจำกัดความว่า loops คือ "agents repeating cycles of work until a stop condition is met" [8]
2.3 Sub-agent คืออะไร?
Sub-agent คือ Agent ย่อยที่ถูกสร้างโดย Agent หลัก (Orchestrator) เพื่อทำงานเฉพาะอย่าง — เหมือนการมอบหมายงานให้ลูกทีม [1]
หลักการสำคัญ:
- Agent หลัก (Orchestrator) เป็นคนวางแผน, กระจายงาน, และรวบรวมผล
- Sub-agent แต่ละตัวทำงานใน context ของตัวเอง — ไม่แชร์ context กับ Agent หลัก
- ผลลัพธ์ ของ sub-agent ถูกส่งกลับเป็นสรุป — ไม่ใช่ทั้ง context
ทำไมแยก context ถึงสำคัญ?
❌ ไม่มี Sub-agent (Agent ตัวเดียวทำทุกอย่าง):
┌──────────────────────────────────────────┐
│ Context: 200K tokens │
│ ├── อ่านโค้ด 50 files (80K tokens) │
│ ├── รัน test (20K tokens) │
│ ├── Security review (30K tokens) │
│ ├── เขียน docs (20K tokens) │
│ └── เหลือ: 50K → เริ่มลืมงานช่วงแรก │
└──────────────────────────────────────────┘
✅ มี Sub-agent (แยกงาน):
┌──────────────────────────────────────────┐
│ Orchestrator context: 200K tokens │
│ ├── ส่งงาน "security review" ไป subagent │
│ │ └── Subagent context: 200K (แยก) │
│ ├── ส่งงาน "write tests" ไป subagent │
│ │ └── Subagent context: 200K (แยก) │
│ ├── รับผลลัพธ์สรุปกลับมา (5K tokens) │
│ └── เหลือ: 195K → จำทุกอย่างได้ │
└──────────────────────────────────────────┘
Addy Osmani อธิบาย pattern นี้ว่า [2]: "The usual split in both tools is one agent explores, one implements, one verifies against the spec."
2.4 สร้าง Sub-agent ใน Claude Code
สร้างไฟล์ .claude/agents/:
# .claude/agents/security-reviewer.toml
name = "security-reviewer"
description = "Reviews code for security vulnerabilities"
instructions = """
You are a security expert. Review code for:
- SQL injection vulnerabilities
- XSS vulnerabilities
- Hardcoded secrets or API keys
- Insecure authentication flows
Report findings with severity levels: CRITICAL, HIGH, MEDIUM, LOW
"""
model = "claude-sonnet-5"
# .claude/agents/test-writer.toml
name = "test-writer"
description = "Writes unit tests for existing code"
instructions = """
You are a testing specialist. For each function:
1. Identify edge cases
2. Write unit tests covering happy path, error cases, and edge cases
3. Use the project's existing test framework
4. Ensure all new tests pass before reporting done
"""
2.5 ใช้ Sub-agent ใน Loop
/loop "Every morning, run the security-reviewer subagent on all new code
merged in the last 24 hours. Write findings to SECURITY-LOG.md"
--schedule "0 7 * * 1-5"
2.6 Orchestrator + Specialists Pattern
┌─────────────────────────────────────────────────────────────┐
│ ORCHESTRATOR AGENT │
│ (วางแผน + กระจายงาน + รวบรวมผล) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Explorer │ │ Implementer │ │ Verifier │ │
│ │ (ค้นหา) │ │ (เขียนโค้ด) │ │ (ตรวจสอบ) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Worktree A │ │ Worktree B │ │ Worktree C │ │
│ │ (isolated) │ │ (isolated) │ │ (isolated) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Pattern นี้คือที่มาของชื่อ "Orchestrator + Specialists" — Agent หลักไม่ได้ทำงานเอง แต่กระจายงานให้ specialist แต่ละตัว [2]
3. Skills — ทำให้ Agent จำได้ข้าม Session
Skills คือไฟล์ .claude/skills/ หรือ SKILL.md ที่บอก Agent ว่าควรทำงานยังไง — เหมือนคู่มือการทำงาน [3]
3.1 ตัวอย่าง Skill
---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone:
1. Start the dev server and open the edited page in the browser
2. Interact with the change directly — click it, confirm state change
3. Check browser console: zero new errors or warnings
4. Use Chrome Devtools MCP, run a performance trace
5. Audit Core Web Vitals
If any step fails, fix the issue and rerun from step 1.
3.2 ใช้ Skill ใน Loop
/loop "Review all open PRs using the verify-frontend-change skill"
--schedule "0 10 * * 1-5"
3.3 Skills vs Prompts
| มิติ | Prompt ปกติ | Skill |
|---|---|---|
| ที่เก็บ | ในข้อความ | ไฟล์ .claude/skills/
|
| ใช้ซ้ำ | ต้อง copy ทุกครั้ง | เรียกใช้ด้วยชื่อ |
| อัปเดต | แก้ทุกที่ที่ใช้ | แก้ไฟล์เดียว |
| แชร์ทีม | ส่งต่อยาก | commit ใน repo |
| Agent รู้จัก | เฉพาะ session | อัตโนมัติ |
4. Worktrees — แยก Environment แต่ละ Agent
Worktrees คือการแยก environment ให้ Agent แต่ละตัวทำงานโดยไม่ทับกัน [4]
4.1 วิธีใช้ Worktree
# สร้าง worktree สำหรับ Agent
git worktree add ../feature-branch feature/new-auth
# รัน Claude Code ใน worktree
cd ../feature-branch && claude
4.2 Worktree ใน Claude Code
Claude Code รองรับ worktree isolation โดยตรง:
# ใช้ --worktree flag
claude --worktree ../isolated-env
# หรือใช้ isolation:worktree ใน subagent config
4.3 ทำไม Worktree ถึงสำคัญ
ถ้าไม่มี worktree — Agent A แก้ไฟล์ auth.ts พร้อมกับ Agent B — ไฟล์จะทับกันและพัง
❌ ไม่มี Worktree:
Agent A: แก้ auth.ts → เขียนทับ
Agent B: แก้ auth.ts → เขียนทับ → ไฟล์พัง
✅ มี Worktree:
Agent A: แก้ auth.ts ใน worktree A
Agent B: แก้ auth.ts ใน worktree B
Orchestrator: merge ตอนทั้งคู่เสร็จ
5. Agent Teams — Orchestrator + Specialists
Agent Teams คือการให้ Agent หลัก (lead) ดูแล Agent อื่นๆ (peers) ที่ทำงานคู่ขนาน [5]
5.1 วิธีสร้าง Agent Team
# .claude/agents/feature-team.toml
name = "feature-team"
description = "Team that implements new features end-to-end"
[[agents]]
name = "planner"
description = "Analyzes requirements and creates implementation plan"
[[agents]]
name = "implementer"
description = "Writes code based on the plan"
[[agents]]
name = "reviewer"
description = "Reviews code for bugs, security, and style issues"
5.2 รัน Agent Team
/team feature-team "Add user avatar upload feature with image resize"
5.3 เปรียบเทียบ: Sub-agents vs Agent Teams vs Workflows
| Sub-agents | Agent Teams | Dynamic Workflows | |
|---|---|---|---|
| ใครถือแผน | Claude, turn by turn | Lead agent | JavaScript script |
| ขนาด | ไม่กี่ตัวต่อ turn | หลายตัว long-running | หลายสิบถึงร้อย |
| ผลลัพธ์ | อยู่ใน context | Shared task list | Script variables |
| ทำซ้ำได้ | ตัว Agent | ทีม | orchestration script |
| ใช้ตอนไหน | งานย่อยใน Loop | งานที่ต้องทำงานร่วมกัน | งานขนาดใหญ่ |
6. Dynamic Workflows — เมื่อต้องการ Agent เป็นร้อย
Dynamic Workflows คือ JavaScript script ที่ Claude เขียนให้ — มัน orchestrate subagents เป็นร้อยตัวพร้อมกัน [6]
6.1 วิธีใช้
# วิธีที่ 1: พิมพ์ ultracode ใน prompt
ultracode: audit every API endpoint under src/routes/ for missing auth checks
# วิธีที่ 2: ใช้ /deep-research
/deep-research What changed in the Node.js permission model between v20 and v22?
# วิธีที่ 3: เปิด ultracode mode
/effort ultracode
6.2 สิ่งที่เกิดขึ้นเบื้องหลัง
- Claude เขียน JavaScript script
- Runtime execute script ใน background
- Script สร้าง subagents หลายสิบตัว
- แต่ละตัวทำงานอิสระ
- ผลลัพธ์ถูกรวบรวมและ cross-check
- รายงานส่งกลับมา — context ของคุณไม่เต็ม
6.3 ตรวจสอบสถานะ
/workflows # ดู workflow ที่กำลังรัน
# เลือก workflow → Enter → ดูแต่ละ phase
# p = pause/resume, x = stop, s = save as command
7. เคสจริง #1: Claire's PR Review Loop + Sub-agents
Claire (จาก Lenny's Newsletter) สร้าง Loop ที่ไม่ใช่แค่ตรวจ PR — มัน spawns subagents สำหรับแต่ละ PR [7]
โครงสร้าง
┌─────────────────────────────────────────────────────────────┐
│ DAILY PR REVIEW LOOP (10:15 AM) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ ORCHESTRATOR AGENT │ │
│ │ - ค้นหา PR ที่ค้าง │ │
│ │ - สร้าง subagent สำหรับแต่ละ PR │ │
│ │ - รวบรวมผล → รายงาน │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Subagent │ │ Subagent │ │ Subagent │ │
│ │ PR #142 │ │ PR #145 │ │ PR #148 │ │
│ │ ตรวจสอบ │ │ ตรวจสอบ │ │ ตรวจสอบ │ │
│ │ + แก้ไข │ │ + แก้ไข │ │ + แก้ไข │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Worktree A│ │Worktree B│ │Worktree C│ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
คำสั่ง
/loop "Every morning at 10:15 AM:
1. Find all open PRs older than 2 days
2. For each PR, spawn a subagent that:
- Reads the PR diff and comments
- Runs the test suite
- If tests fail, fixes them
- Posts a status comment
3. Each subagent runs in its own worktree
4. Write a summary to PR-REVIEW-LOG.md
Use GitHub MCP for all API calls"
--schedule "15 10 * * 1-5"
สิ่งที่ทำให้พิเศษ
| องค์ประกอบ | รายละเอียด |
|---|---|
| Sub-agents | แต่ละ PR ได้ Agent ของตัวเอง |
| Worktrees | แต่ละ Agent ทำงานใน environment แยก |
| Parallel | PR หลายอันถูกรีวิวพร้อมกัน |
| State | PR-REVIEW-LOG.md เก็บประวัติ |
8. เคสจริง #2: Skills-Identification Loop
Claire สร้าง Loop อีกตัวที่ทำงานทุกสัปดาห์ — มัน identify skills ที่ขาดหายและ spawns subagents เพื่อ validate [7]
วิธีการทำงาน
- Loop ตรวจสอบ merged PRs ทั้งสัปดาห์
- วิเคราะห์ว่า Agent ใช้ skills อะไรบ้าง
- Identify skills ที่ยังไม่มี
- Spawns subagents เพื่อสร้าง skill ใหม่
- แต่ละ subagent ใช้
/goalเพื่อ validate ว่า skill ใช้ได้จริง
/loop "Every Friday at 10 AM:
1. Review all PRs merged this week
2. Identify patterns where agents repeated work
3. For each pattern, check if a skill exists
4. If no skill exists, spawn a subagent to:
- Create a new SKILL.md
- Test it with a sample task
- Validate with /goal
5. Write new skills to .claude/skills/
6. Summarize in SKILLS-LOG.md"
--schedule "0 10 * * 5"
9. วิธีเริ่มต้น: Roadmap สู่ Sub-agents
┌─────────────────────────────────────────────────────────────┐
│ ROADMAP: จาก Loop → Sub-agents │
├─────────────────────────────────────────────────────────────┤
│ │
│ สัปดาห์ที่ 1: สร้าง Skill แรก │
│ ├── สร้าง .claude/skills/verify-frontend.md │
│ └── ใช้ skill ใน /goal │
│ │
│ สัปดาห์ที่ 2: สร้าง Sub-agent แรก │
│ ├── สร้าง .claude/agents/security-reviewer.toml │
│ └── เรียกใช้ใน /loop │
│ │
│ สัปดาห์ที่ 3: ใช้ Worktree │
│ ├── ตั้งค่า git worktree │
│ └── ให้ subagent แต่ละตัวใช้ worktree แยก │
│ │
│ สัปดาห์ที่ 4: ลอง Dynamic Workflow │
│ ├── รัน /deep-research │
│ └── ทดลอง ultracode กับงาน audit │
│ │
└─────────────────────────────────────────────────────────────┘
ในมุมมองของผม อย่าเพิ่งรีบไป Dynamic Workflows ถ้าคุณยังไม่ชินกับ Sub-agents และ Skills — เพราะยิ่งระบบซับซ้อนมากเท่าไหร่ การ debug ก็ยากขึ้น
สรุป
| เครื่องมือ | ปัญหาที่แก้ | วิธีเริ่ม |
|---|---|---|
| Sub-agents | Context เต็ม, คอขวด | .claude/agents/*.toml |
| Skills | ไม่มีหน่วยความจำ | .claude/skills/*.md |
| Worktrees | Environment ทับกัน | git worktree add |
| Agent Teams | ต้องการทำงานร่วมกัน | .claude/agents/*-team.toml |
| Dynamic Workflows | ต้องการ scale |
ultracode: หรือ /effort ultracode
|
ตอนหน้า: ความเสี่ยง, ต้นทุน, และ Production Best Practices — เมื่อ Loop ของคุณเริ่มทำงานจริง
เอกสารอ้างอิง
[1] Claude Code Docs — Create custom subagents (2026)
[2] Addy Osmani — Loop Engineering (O'Reilly Radar, June 7, 2026)
[3] Claude Code Docs — Extend Claude with skills (2026)
[4] Claude Code Docs — Isolate sessions with worktrees (2026)
[5] Claude Code Docs — Run agent teams (2026)
[6] Claude Code Docs — Orchestrate subagents at scale with dynamic workflows (2026)
[7] Lenny's Newsletter — How to design AI agent loops: schedules, goals, and subagents in Claude Code and Codex (June 17, 2026)
[8] Claude Code Docs — Getting started with loops (June 30, 2026)
บทความนี้เขียนโดย AI (DeepSeek V4 Flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ — Nokka (นก-กา)
Top comments (0)