Xin chào anh em,
Năm 2026 rồi, chắc anh em dev không còn lạ lẫm gì với việc "cặp kè" cùng AI để gõ code nữa nhỉ? Từ ngày Claude Code (con hàng CLI quái vật của Anthropic) ra mắt, anh em ta code như được lắp thêm tên lửa của Mỹ-Israel vào mông, code cứ phải gọi là vèo vèo.
Nhưng mà, dùng lâu mới biết đêm dài lắm mộng. Có bao giờ anh em đang “bay” cùng Claude thì tự dưng nó… ngáo chưa? Kiểu 5 phút trước còn khen logic file A hay lắm, quay sang hỏi lại thì nó tỉnh bơ: “File A là file nào nhỉ? – cảm giác KHÓ CHỊU VÔ CÙNG! Hôm nay, tôi sẽ bóc tách một tuyệt chiêu mà tôi tin là sẽ thay đổi hoàn toàn cách anh em dùng AI: Subagents. Không chỉ là tối ưu, mà đây là "cuộc cách mạng" về tư duy làm việc với AI Agent.
1. Nỗi đau mang tên "Main Session" – Càng lâu càng... lú
Anh em cứ tưởng tượng cái Main Session (phiên chat chính) của mình giống như một cái balo vậy.
Càng chat lâu, balo càng nặng (Token Bloat)
Khi anh em bắt đầu một project, anh em quăng vào đó đủ thứ: ls thư mục, grep tìm chuỗi, đọc nội dung file A, file B, file C... Mỗi hành động đó đều chiếm chỗ trong Context Window. Kết quả là gì?
- Lag: Claude bắt đầu "rùa bò" vì phải đọc lại cả tấn dữ liệu cũ trước khi trả lời câu tiếp theo.
- Quên: Khi “balo” đầy, Claude buộc phải vứt bớt đồ cũ ra. Mà nếu đen thì nó vứt đúng cái instruction quan trọng nhất mà anh em dặn từ đầu bài. Thế là "ngáo" thôi!
Hiện tượng "Vừa đá bóng, vừa thổi còi" (Confirmation Bias)
Đây mới là cái "tử huyệt" kỹ thuật mà ít anh em để ý. Khi anh em để Claude vừa code logic, vừa tự viết test ngay trong cùng một session:
- Vì dùng chung một context, Claude sẽ có xu hướng "tự huyễn hoặc" bản thân. Nó sẽ thấy cái code nó vừa viết trông cũng "đúng đúng", và cái test nó viết ra cũng vô tình né hết các góc khuất mà nó đã sai trước đó.
- Hệ quả: Ảo giác (Hallucination) tập thể! AI tin là nó đúng, anh em cũng tin nó đúng, cho đến khi lên Production thì... bùm! Hết cứu
2. Bản chất của Subagent – "Bình mới rượu cũ" hay bước ngoặt?
Để giải quyết đống "rác" context ở trên, Anthropic tung ra khái niệm Subagent. Nghe thì cao siêu, nhưng anh em cứ quy hết về bản chất cho mình: Subagent = Một New Session sạch tinh.
Định nghĩa lại Agent dưới góc nhìn "thực chiến"
Subagent không phải là một con AI khác, nó vẫn là Claude Code thôi. Nhưng khi anh em "spawn" (triệu hồi) một Subagent, Claude sẽ mở ra một không gian làm việc hoàn toàn độc lập, không dính líu gì đến đống hội thoại của anh em ở Main Session từ nãy đến giờ. Nói đơn giản: mọi thứ anh em đã chat từ đầu tới giờ không tồn tại trong session mới đó.
Tại sao "Isolated Memory" lại là cứu cánh?
Có thể hình dung bằng một phép so sánh rất quen thuộc với dân dev: RAM.
- Main Session giống như một thanh RAM đang bị nhồi quá nhiều dữ liệu. Context càng dài, càng nhiều thông tin thừa, càng dễ dẫn tới tình trạng overflow về mặt nhận thức.
- Còn Subagent giống như một sandbox memory riêng.
Vì Subagent có bộ nhớ riêng, nó buộc phải trace (truy vết) lại vấn đề từ A đến Z. Nó không có "định kiến" từ các câu trả lời trước của Main Agent. Mọi lựa chọn nó đưa ra đều dựa trên chuẩn pattern mà nó đã được train, thay vì dựa trên cái flow "sai sai" mà anh em đang dẫn dắt ở Main Session.
Nó giống như việc khi bế tắc, anh em gọi một ông dev khác tới hỗ trợ. Ông này không biết anh em đã sai ở đâu, cũng không nghe anh em giải trình. Ông ấy chỉ nhìn vào code hiện tại (Input) và yêu cầu (Prompt) để làm việc.
Chính sự “trong sạch” của context này lại là thứ giúp nó đưa ra kết quả ổn định và khách quan hơn.
Hẹ hẹ, xong phần "đạo lý" rồi đấy. Anh em đã thấy cái tầm của Subagent chưa?
Giờ là lúc chúng ta xắn tay áo lên để "mổ xẻ" xem con hàng Subagent này cấu tạo ra sao và làm thế nào để anh em build được một "biệt đội đánh thuê" thiện chiến nhất.
3. Giải phẫu một Custom Subagent – "Đồ chơi" này gồm những gì?
Để tạo ra một Subagent, anh em chỉ cần ném một file Markdown vào thư mục .claude/agents/.
Về mặt kỹ thuật, công thức của nó chỉ có 3 thành phần:
Subagent = Một Claude Session mới + System Prompt (nội dung file .md) + Task cụ thể.
Không container, không process riêng. Claude Code chỉ đơn giản là mở một "tab" chat mới, dán cái System Prompt của anh em vào, và giao việc.
Khi chạy Subagent, Claude Code chỉ đọc đúng hai thông tin:
- Tên agent – chính là tên file (ví dụ: code-reviewer)
- Nội dung prompt – những gì anh em viết bên trong file Markdown
Ví dụ, mình muốn một ông chuyên soi Performance cho React, mình chỉ cần tạo file .claude/agents/react-perf.md như sau:
You are an expert in React performance.
Focus on:
- Unnecessary re-renders
- Memoization (useMemo, useCallback)
- Large component trees
Output format:
- Component: [Name]
- Issue: [Description]
- Fix: [Code snippet]
Chỉ cần thế thôi là anh em đã có một "Chuyên gia React" luôn túc trực trong Terminal rồi. Hẹ hẹ, quá nhanh quá nguy hiểm!
4. "Mẹo" để Subagent thực sự là Chuyên gia (Tips & Tricks)
Tuy bản chất đơn giản, nhưng để "đệ" của anh em không làm việc kiểu "cưỡi ngựa xem hoa", thì đây là những kinh nghiệm xương máu từ dev experience của mình:
Tip 1: Dùng YAML Frontmatter để thả "thính"
Dù nội dung Prompt là quan trọng nhất, nên anh em cứ nghĩ description chỉ là mô tả cho vui, nhưng SAI LẦM! Với Claude Code, description chính là "nhận diện" đồng đội.
- Bản chất: Main Agent luôn "liếc" qua danh sách mô tả của các Subagents. Nếu anh em viết Subagent Security như sau: "Dùng để audit bảo mật khi có thay đổi liên quan đến Auth", thì ngay khi anh em vừa chạm vào logic Login, Claude sẽ tự động triệu hồi ông thần Security này ra ngay. Không cần anh em phải nhắc!
Tip 2: Giới hạn quyền hạn (The Sandbox Mindset)
Dù không phải là container thực thụ, nhưng anh em có thể giới hạn "tầm tay" của Subagent qua tool.
- Reviewer: Chỉ cho phép Read, Grep. Đừng cho nó quyền Write hay Edit. Anh em không muốn một con AI tự ý sửa code lung tung khi chưa được duyệt đúng không?
Tip 3. Chiến lược Mix Model: Đừng dùng đại bác bắn chim sẻ
Đây là nghệ thuật quản lý ví tiền của anh em thôi. Nếu anh em giàu có, dư dả thì có thể bỏ qua phần này. Còn nếu cũng như tôi, một dev quèn đủ ăn thì cần cân nhắc kỹ đấy. Không phải lúc nào cũng cần đến "bộ não" đắt đỏ nhất.
- Dùng Haiku: Cho các Agent chuyên đi "dọn dẹp" hoặc "tìm kiếm" file (Exploration). Nhanh, rẻ, không tốn context.
- Dùng Sonnet: Cho các việc thực thi code hàng ngày.
- Dùng Opus: Chỉ dành cho "Boss" Code Reviewer hoặc các task có architect phức tạp – những ông cần độ sâu sắc và suy luận đa tầng.
5. Xây dựng "Virtual Software Agency" – Khi anh em làm sếp tổng
Thay vì một mình "vật lộn" với Claude, mình đã thiết lập một team 5 "nhân sự" ảo trong thư mục .claude/agents, cảm giác mình như CEO, hehe.
- Tech Lead (Opus): Nhận yêu cầu, phân tích kiến trúc và "giao việc" cho các đệ khác.
- Backend & Frontend Dev (Sonnet): Hai thanh niên thực thi. Nhận Task ID từ Tech Lead và cắm đầu vào code.
- QA Engineer (Sonnet/Haiku): Chuyên gia "bới lông tìm vết". Chỉ nhảy vào khi Dev báo xong việc để chạy test và check edge cases.
- Code Reviewer (Opus): Soi từng dòng code, check bảo mật và coding convention. Chỉ khi ông này "Approve", code mới được coi là xong.
Vậy thì câu chuyện ở đây là, 5 ông này giao tiếp với nhau kiểu gì? Làm sao để ông QA biết ông Dev đã code xong?
Và đây là câu trả lời:
Dùng file làm “message bus”
Đơn giản là như thế này, mỗi Agent chỉ cần:
- Đọc file đầu vào
- Làm việc
- Ghi file đầu ra
File trở thành kênh giao tiếp duy nhất giữa các Agent.
Mình sẽ để sơ đồ vận hành ở đây cho anh em dễ hiểu:
Agent Workflow
┌─────────────────────────────────────────────────┐
│ Tech Lead (Opus) │
│ Nhận yêu cầu → Phân tích → Ghi task.md │
└──────────────────┬──────────────────────────────┘
│
task.md (Task ID + scope)
┌─────────┴──────────┐
▼ ▼
┌────────────────┐ ┌────────────────────┐
│ Backend (Sonnet)│ │ Frontend (Sonnet) │
│ Đọc task.md │ │ Đọc task.md │
│ → code logic │ │ → xây UI │
└───────┬────────┘ └──────────┬─────────┘
│ │
└───────┬───────────────┘
▼
Ghi "DONE" vào status.md
▼
┌────────────────────────┐
│ QA Engineer │
│ (Sonnet/Haiku) │
│ Trigger: status.md │
│ → Chạy test, ghi report│
└───────────┬────────────┘
▼
qa-report.md: PASS/FAIL
▼
┌────────────────────────┐
│ Code Reviewer (Opus) │
│ Trigger: qa-report.md │
│ → Soi code, Verdict │
└────────────────────────┘
Mình sử dụng các file .md làm "bus" trung chuyển tín hiệu. Mỗi file đóng vai trò như một cái biên bản bàn giao, trong đó:
| File | Vai trò |
|---|---|
task.md |
“Hợp đồng” từ Tech Lead xuống Dev |
status.md |
Báo cáo tiến độ Dev → QA |
qa-report.md |
Biên bản kiểm thử QA → Reviewer |
verdict.md |
Quyết định cuối cùng - End Workflow |
Để ông QA không tự dưng nhảy vào khi Dev đang code dở, anh em cần set up logic description và system prompt.
Soi thử snippet của ông QA Engineer mình đang dùng:
---
name: qa-engineer
model: claude-3-5-haiku-20241022 # Use Haiku for lower cost and faster execution
description: >
Specialist responsible for running tests and checking edge cases.
ONLY activate when the file status.md contains the line "BACKEND: DONE" or "FRONTEND: DONE".
Do nothing if this signal has not appeared yet.
tools:
- Read
- Bash # Only used to run pytest/jest/npm test, not to write code
---
You are a Senior QA Engineer. Your responsibilities are:
1. Read `status.md` to determine which module needs testing.
2. Read the corresponding source code to understand the logic.
3. Run the appropriate bash command (for example: `npm test`).
4. Write the results to `qa-report.md` using the format: `[PASS/FAIL]` + explanation.
Note: If `status.md` does not report DONE yet, respond with:
"Waiting for developers to finish..." and stop the workflow.
Sau 2 tuần làm "CEO ảo", mình rút ra 2 lợi ích cực lớn mà cách làm truyền thống lúc trước không bao giờ có được:
- Zero Context Infection (Chống nhiễm context): Ông QA chỉ đọc đúng status.md và file code liên quan. Ông ấy không cần biết ông Tech Lead và mình đã "cãi nhau" những gì ở Main Session. Kết quả test nhờ đó cực kỳ khách quan.
- Determinism (Tính xác định): Bằng cách dùng file làm "trạm gác", anh em tạo ra một quy trình có tính tuần tự. Agent không còn bị loạn khi phải xử lý quá nhiều thông tin dư thừa.
Nhìn các đệ Agent tự "nói chuyện" với nhau qua file, tự code, tự test rồi báo cáo lại cho mình, một trải nghiệm khá thú vị anh em ạ.
Để test xem cái đội ngũ của mình hoạt động ra sao, mình đã chạy song song hai kịch bản: Main session duy nhất và Sub-Agents cho task sau: Refactor lại toàn bộ module Authentication (tầm 20 files code) và viết lại Unit Test.
Dưới đây là benchmark thực nghiệm mình thu được:
| Metric | Main Session (Cách cũ) | Sub-Agents (Claude Code) |
|---|---|---|
| Active Context Tokens | ~160,000 tokens | ~8,000 tokens / agent |
| Task Token Usage | ~9,000 tokens | ~45,000 tokens |
| LLM Calls | ~15 calls | ~85 calls |
| Task Latency (Độ trễ) | ~30–40s / phản hồi | ~8–10s / phản hồi |
| Parallel Execution | ❌ Sequential | ✅ Parallel |
| Total Task Duration | ~28–30 phút | ~12–15 phút |
Như anh em có thể thấy, việc sử dụng Sub-Agents rõ ràng là chiến thuật đốt token để lấy ra sự chính xác, hay còn gọi là “Dùng tiền để mua thời gian” đấy. Dù tốn gấp 5 lần tài nguyên để điều phối, nhưng bù lại thời gian thực thi giảm 50% nhờ cơ chế chạy song song (Parallel). Đồng thời, việc cô lập context siêu gọn (~8k tokens) giúp dập tắt độ trễ và hạn chế tỷ lệ Hallucination (ảo giác).
Tóm lại, Sub-agents là chiến thuật “chia để trị”. Anh em chấp nhận trả nhiều token hơn -> đổi lấy một đội ngũ NHANH HƠN, TỈNH TÁO HƠN và quan trọng giúp anh em thoát khỏi cảnh ngồi đờ đẫn đợi AI trả lời.
6. Những "Cái bẫy" cần tránh – Đừng để Agent "dắt mũi"
Dùng Subagent sướng thì sướng thật, nhưng nếu không tỉnh táo là anh em "ăn hành" ngay:
- Vòng lặp vô tận (Infinite Review): Đừng bao giờ để Agent A review Agent B, rồi Agent B lại sửa theo ý Agent A... tuần hoàn. AI có tính ngẫu nhiên, nếu anh em không đặt ra một exit condition rõ ràng thì hai ông này có thể tranh luận mãi không dứt. Mình từng mất gần 10$ chỉ trong một đêm vì hai ông thần này cãi nhau xem nên đặt tên biến là data hay payload.
- Đừng quá kỳ vọng vào sự "hoàn hảo": Nhớ kỹ cho mình: Code chỉ có "PHÙ HỢP", không có "TUYỆT ĐỐI". Nếu Subagent đã đưa ra phương án đạt 80-90% yêu cầu, hãy nhận lấy và tự tay tinh chỉnh. Đừng cố đấm ăn xôi, spawn thêm 10 Agent nữa để lấy 10% cuối cùng không để làm gì cả!
- Quản lý "tiến vì": Mỗi lần spawn Subagent là một lần mở session mới. Dù nó tiết kiệm token tổng thể nhưng nếu anh em thiết kế workflow quá cồng kềnh, hóa đơn cuối tháng của Anthropic vẫn có thể làm anh em khóc đấy.
"Ai ơi bưng bát cơm đầy,
Token một hạt, đắng cay muôn phần."
Bonus: Kho Sub-Agents cho anh em tham khảo
Repo này tổng hợp các Sub-agent theo chuẩn best practice cho đủ mọi vai trò từ DevOps, Infra, Security Auditor cho đến SQL Architect. Khá xịn.
Kết luận: Từ "Prompting" sang "Agentic Workflow"
Anh em thấy đó, kỷ nguyên của việc ngồi hì hục viết những cái Prompt dài dằng dặc để hy vọng AI hiểu mình đã qua rồi. 2026 là năm của Agentic Workflow.
Thay vì dạy AI cách làm việc, hãy xây dựng cho nó một môi trường và đội ngũ để nó tự vận hành. Việc của anh em là dịch chuyển tư duy: Từ một người "thợ gõ" prompt sang một "quản lý dự án" (Project Manager).
Lời khuyên cuối cho anh em: Đừng đợi đến dự án lớn mới dùng. Hãy bắt đầu xây dựng thư viện ~/.claude/agents/ ngay hôm nay. Hãy tạo cho mình một thằng "đệ" chuyên review, một con chuyên viết doc... Anh em sẽ thấy năng suất của mình tăng theo cấp số nhân đấy.
Hẹ hẹ, bài dài rồi, chúc anh em "spawn" đệ thành công và không bị "cháy túi" nhé! Nếu thấy hay thì ngại gì không thử ngay một con Agent đầu tay đi nào?
