Subagent-Driven Development: Cách vận hành các agent phụ (subagents) thực thi từng task độc lập và tự động review lại công việc.

Subagent-Driven Development (SDD) là mô hình phát triển phần mềm nơi một quy trình kỹ thuật phức tạp được chia tách và giao cho nhiều tác tử AI (agents) nhỏ, chuyên biệt. Thay vì nhồi nhét toàn bộ context của một dự án lớn vào một luồng chat duy nhất khiến AI bị "ảo giác" (hallucinate) hoặc quên logic, SDD giới hạn phạm vi của mỗi subagent vào một tệp (file) hoặc một nhiệm vụ duy nhất, tuân thủ nguyên tắc Single Responsibility (Đơn trách nhiệm).

Cốt lõi của SDD là thiết lập một hệ thống phân cấp, trong đó các agents không chỉ viết code mà còn tự động giám sát, phản biện và sửa lỗi lẫn nhau trước khi trình lên kết quả cuối cùng.

Cấu Trúc Đội Hình Multi-Agent

Một luồng SDD tiêu chuẩn thường bao gồm 3 vai trò chính, được thiết lập thông qua các system prompt riêng biệt:

Orchestrator (Quản lý luồng): Nắm giữ "Writing Plan" (Kế hoạch mã hóa). Orchestrator không viết code. Nhiệm vụ của nó là đọc spec, chẻ nhỏ thành các micro-tasks, khởi tạo các Subagent và tổng hợp kết quả cuối cùng để commit.
Executor Subagents (Kỹ sư thực thi): Các agent chỉ tồn tại trong vòng 2-5 phút. Chúng được bơm một ngữ cảnh cực hẹp. Ví dụ: Database Subagent chỉ biết về schema SQL; Auth Subagent chỉ biết về JWT logic.
Reviewer Subagents (Chuyên gia QA): Kẻ thù tự nhiên của Executor. Reviewer được lập trình để cực kỳ khó tính, chuyên săn lùng các lỗi bảo mật, race conditions, memory leaks, hoặc vi phạm coding convention.

Cơ Chế Vận Hành: Từ Giao Việc Đến Tự Phản Biện (Self-Reflection)

Để các subagent hoạt động trơn tru mà không cần con người can thiệp vào từng bước, luồng thực thi phải được đóng kín thành một vòng lặp (Feedback Loop).

Bước 1: Isolation (Cách ly ngữ cảnh)

Orchestrator khởi tạo một Executor Subagent để giải quyết một task cụ thể (ví dụ: Viết một worker xử lý queue gửi email). Context được cấp cho Executor này bị giới hạn nghiêm ngặt:

Chỉ cung cấp file Interface/Type khai báo đầu vào/đầu ra.
Chỉ cung cấp template file cần viết.
Tuyệt đối không cung cấp toàn bộ mã nguồn dự án để tránh AI tự ý sửa các file không liên quan.

Bước 2: Execution (Thực thi)

Executor sinh ra đoạn code nháp đầu tiên. Trong mô hình AI thông thường, đây là lúc bạn copy/paste vào dự án. Trong SDD, đoạn code này bị chặn lại và chuyển sang bước 3.

Bước 3: Automated Self-Review (Tự động Phản biện)

Đoạn code nháp được chuyển cho một Reviewer Subagent với một Prompt kiểm định khắt khe.

Mẫu Prompt của Reviewer Subagent:

"Bạn là một Senior Security & Performance Engineer. Hãy review đoạn code Go/Node.js sau. Nhiệm vụ của bạn: KHÔNG khen ngợi. Chỉ tìm kiếm 3 rủi ro sau:

Có khả năng xảy ra N+1 query không?

Các kết nối tới Redis/Postgres đã được giải phóng (release/close) đúng cách khi xảy ra lỗi chưa?

Có nguy cơ Race Condition khi chạy đồng thời nhiều worker không? Nếu phát hiện lỗi, trả về định dạng: [FAIL] - Tên lỗi - Giải pháp khắc phục. Nếu hoàn hảo, trả về [PASS]."

Bước 4: Auto-Correction (Tự động Sửa lỗi)

Nếu Reviewer trả về [FAIL], Orchestrator sẽ lấy phản hồi đó (Feedback), đóng gói cùng đoạn code cũ và gửi lại cho Executor Subagent kèm lệnh: "Code của bạn không vượt qua bài test. Hãy sửa lại dựa trên 피드백 (feedback) sau". Vòng lặp này tiếp diễn (thường giới hạn tối đa 3-5 lần) cho đến khi Reviewer trả về [PASS]. Khi đó, Orchestrator mới ghép (merge) đoạn code vào hệ thống.

Ứng Dụng Thực Tế Trong Luồng Làm Việc

Nếu bạn đang sử dụng các công cụ lập trình AI CLI (như Claude Code) hoặc các IDE tích hợp AI (như Cursor Pro), bạn có thể mô phỏng mô hình SDD bằng cách kiểm soát luồng giao tiếp thay vì tự tay code các hệ thống agent phức tạp (như LangChain hay AutoGen).

Chiến lược "Chaining Prompts" trong Cursor/Claude Code: Thay vì ra một lệnh duy nhất, hãy ra một chuỗi lệnh (rules) ép AI tự đóng các vai:

Lệnh 1 (Khởi động Executor): "Đọc file user.service.ts và writing_plan.md. Implement hàm lockUser theo đúng spec. Báo cáo khi viết xong, chưa được phép sửa file khác."
Lệnh 2 (Khởi động Reviewer - ép IDE chạy tool): "Bây giờ, hãy chuyển vai thành QA. Hãy tự chạy lệnh npx eslint src/services/user.service.ts và npm run test:unit. Hãy soi kỹ xem hàm lockUser vừa viết có handle lỗi khi DB timeout không. Trình bày các điểm yếu tìm thấy."
Lệnh 3 (Khởi động Auto-Correction): "Dựa trên các lỗi vừa tìm thấy, hãy tự refactor lại hàm lockUser và chạy lại test cho đến khi pass xanh toàn bộ."

Bằng cách thiết lập cơ chế kiểm tra chéo này, bạn chuyển vai trò của mình từ một người "thợ gõ phím" sang một "kiến trúc sư trưởng", chỉ cần duyệt các bản thiết kế và để các subagent tự động thi công, tự động kiểm tra chéo và hoàn thiện chi tiết.

Claude code