Agent Teams trong Claude Code: nhiều phiên Claude làm việc như một team thật

Subagent giúp Claude giao việc cho “trợ lý” rồi nhận kết quả về. Agent Teams tiến thêm một bước: nhiều phiên Claude Code làm việc như một nhóm thật — có trưởng nhóm, có bảng việc chung, và các thành viên nhắn tin trực tiếp cho nhau để chia sẻ phát hiện, phản biện lẫn nhau. Đây là tính năng thử nghiệm, nhưng rất đáng thử cho review, debug và các feature lớn.

Bật tính năng

Agent Teams đang ở trạng thái experimental và tắt mặc định. Bật bằng biến môi trường trong shell hoặc trong settings.json:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Hai điều cần biết khi bật:

• Khi tính năng bật, subagent nào được Claude đặt tên lúc khởi tạo sẽ chạy thành teammate — nên team có thể tự hình thành dù bạn không yêu cầu. Muốn quay lại subagent thường, đặt biến về 0 (có hiệu lực ngay, không cần mở phiên mới).
• Teammate chỉ được tạo trong phiên tương tác. Ở chế độ claude -p hay Agent SDK, Claude không sinh teammate.

Kiến trúc của một team

Teammate tự động nạp context dự án như một phiên thường (CLAUDE.md, MCP server, skill) và nhận prompt giao việc từ lead — nhưng không thừa hưởng lịch sử hội thoại của lead.

Subagent hay Agent Team?

Với việc tuần tự, sửa chung một file, hoặc nhiều phụ thuộc, một phiên đơn hoặc subagent hiệu quả hơn.

Khởi tạo team đầu tiên

Không cần cấu hình gì thêm — mô tả việc và đội hình bằng ngôn ngữ tự nhiên:

Tôi đang thiết kế một CLI giúp dev theo dõi comment TODO trong codebase.
Tạo 3 teammate để khám phá từ 3 góc: một người lo UX,
một người lo kiến trúc kỹ thuật, một người đóng vai phản biện.

Có thể chỉ định số lượng và model: “Tạo 4 teammate refactor song song các module này, mỗi người dùng Sonnet.” Nếu Claude chỉ tạo subagent thay vì team, hãy yêu cầu lại rõ ràng là “agent team”.

Điều khiển team

• Chế độ in-process (mặc định): mọi teammate chạy trong terminal chính. Dùng phím ↑/↓ trong agent panel để chọn teammate, Enter để xem phiên và nhắn trực tiếp, Esc để bỏ chọn hoặc ngắt lượt đang chạy, x để dừng teammate, Ctrl+T để bật/tắt task list.
• Chế độ split pane: mỗi teammate một pane riêng, cần tmux hoặc iTerm2 (cài CLI it2). Bật bằng "teammateMode": "auto" trong ~/.claude/settings.json hoặc cờ claude --teammate-mode auto. Không hỗ trợ terminal tích hợp của VS Code, Windows Terminal, Ghostty.

Giao và nhận việc

Lead tạo task, teammate xử lý. Task có thể phụ thuộc task khác — task bị chặn sẽ không được tự nhận cho tới khi task trước hoàn thành. Lead có thể giao đích danh, hoặc teammate làm xong tự nhận task kế tiếp chưa có người. Việc nhận task dùng file lock nên không bị hai người tranh cùng một task.

Bắt teammate lên kế hoạch trước

Với việc rủi ro, chuyển lead sang plan mode trước rồi yêu cầu: “Tạo một teammate kiến trúc sư để refactor module xác thực.” Teammate đó làm việc ở chế độ chỉ đọc cho tới khi có kế hoạch, gửi yêu cầu duyệt kế hoạch về lead, được duyệt mới bắt tay sửa code.

Cổng chất lượng bằng hook

Kết thúc

Gọi tên teammate: “Yêu cầu teammate researcher shut down.” Teammate có thể đồng ý hoặc từ chối kèm lý do. Thư mục cấu hình team tự dọn khi phiên kết thúc; task list vẫn được giữ lại trên đĩa theo cleanupPeriodDays.

3 kịch bản đáng thử

1. Review PR song song

Tạo 3 teammate review PR #142:
- một người tập trung vào bảo mật
- một người kiểm tra ảnh hưởng hiệu năng
- một người xác minh độ phủ test
Mỗi người review và báo cáo phát hiện.

Một reviewer đơn lẻ thường chỉ bám một loại lỗi; chia “lăng kính” giúp cả ba khía cạnh được soi kỹ cùng lúc.

2. Debug bằng các giả thuyết cạnh tranh

Người dùng báo app thoát sau một tin nhắn thay vì giữ kết nối.
Tạo 5 teammate điều tra 5 giả thuyết khác nhau. Yêu cầu họ nhắn cho nhau
để tìm cách bác bỏ giả thuyết của người khác, như một cuộc tranh luận khoa học.
Cập nhật tài liệu kết luận theo đồng thuận cuối cùng.

Điều tra tuần tự dễ bị “neo” vào giả thuyết đầu tiên. Khi các teammate chủ động phản bác nhau, giả thuyết còn trụ lại nhiều khả năng là nguyên nhân thật.

3. Feature cắt ngang nhiều lớp

Frontend, backend và test mỗi phần một teammate sở hữu, phối hợp qua task list và tin nhắn.

Kinh nghiệm vận hành

• Quy mô: bắt đầu với 3–5 teammate. Token tăng tuyến tính theo số người, chi phí phối hợp cũng tăng; 3 người tập trung thường hiệu quả hơn 5 người dàn trải.
• Cỡ task: mỗi task là một sản phẩm rõ ràng (một hàm, một file test, một bản review). Khoảng 5–6 task mỗi teammate để lead dễ điều chuyển khi có người kẹt.
• Tránh xung đột file: hai teammate sửa cùng một file sẽ ghi đè nhau — chia việc theo nhóm file.
• Spawn prompt đủ context: nêu rõ thư mục, công nghệ, tiêu chí đánh giá, vì teammate không thấy lịch sử chat của lead.
• Bắt lead chờ: nếu lead tự lao vào làm thay, nhắc “Chờ các teammate hoàn thành task trước khi tiếp tục”.
• Giảm prompt xin quyền: quyền của teammate dồn về phiên lead — hãy pre-approve các lệnh thường dùng trước khi tạo team.
• Người mới: bắt đầu bằng việc không viết code (review, nghiên cứu thư viện, điều tra bug) để thấy giá trị trước khi đụng tới implement song song.

Giới hạn hiện tại

• /resume và /rewind không khôi phục teammate in-process.
• Trạng thái task đôi khi bị trễ — teammate quên đánh dấu xong làm task phụ thuộc bị chặn.
• Mỗi phiên chỉ một team; không có team lồng nhau; lead cố định suốt phiên.
• Không đặt chế độ quyền riêng cho từng teammate lúc khởi tạo (chỉ đổi được sau đó).

Áp dụng thế nào?

• Dev: Thử ngay với review PR lớn trước khi merge — 3 teammate, 3 lăng kính, lead tổng hợp. Không đụng tới code nên rủi ro thấp.
• Tech Lead: Định nghĩa sẵn các vai (security-reviewer, test-runner) dưới dạng subagent trong .claude/agents/; khi tạo team chỉ cần gọi “dùng agent type security-reviewer”.
• PM: Coi agent team như một squad nhỏ: lead = Tech Lead kiêm Scrum Master, task list = board, hook TaskCompleted = Definition of Done. Các nguyên tắc chia việc độc lập, giới hạn WIP vẫn y nguyên.