Bỏ qua đến nội dung

Execution & Subagent

Mô hình subagent được mượn từ quản lý kỹ thuật tốt: đừng giao phó mọi task cho một người và hy vọng họ theo dõi tất cả mọi thứ. Hãy giao từng task cho một agent tập trung với scope được xác định rõ ràng.


Vấn Đề: Context Contamination

Khi một AI agent làm việc trên nhiều task theo trình tự, nó tích lũy context. Nó nhớ những gì đã xảy ra ở task trước. Đây tưởng như là một điều tốt — nhưng nó thường là một điểm yếu.

Context contamination là hiện tượng lỗi, giả định hoặc quyết định từ một task ảnh hưởng đến hành vi của task tiếp theo. Ví dụ:

  • Agent gặp lỗi trong Task 3. Khi đến Task 4, nó đưa ra các giả định phòng thủ dựa trên lỗi đó — ngay cả khi Task 4 hoàn toàn không liên quan đến lỗi.
  • Agent viết code theo một cách cụ thể trong Task 2. Trong Task 5, nó tuân theo cùng một cấu trúc đó — ngay cả khi đó là cách tiếp cận sai cho Task 5.
  • Agent review code của chính mình trong cùng session — thiên kiến xác nhận xuất hiện, nó tìm thấy những gì nó muốn tìm thấy.

Subagent model giải quyết vấn đề này bằng cách sử dụng các AI instance mới, biệt lập cho mỗi task.


Ba Lợi Ích Của Context Isolation

1. Không Có Lan Truyền Lỗi

Khi một subagent gặp lỗi và thất bại, lỗi đó ở lại với task đó. Subagent tiếp theo bắt đầu mới, không có kiến thức về những gì đã xảy ra ở task trước. Nó không thể bị ảnh hưởng bởi những gì không có trong context của nó.

2. Review Không Thiên Kiến

Khi một subagent mới được dispatch để review công việc của subagent trước, nó không có thiên kiến xác nhận. Nó chưa từng thấy code trước đây. Nó review những gì thực sự ở đó, không phải những gì nó nghĩ là ở đó.

3. An Toàn Khi Thực Thi Song Song

Các subagent với context biệt lập có thể chạy song song mà không can thiệp lẫn nhau. Hai subagent làm việc trên các phần độc lập của kế hoạch không chia sẻ trạng thái. Không có race condition trong lý luận.


CONTROLLER LOOP

Controller là agent điều phối sự thực thi kế hoạch. Nó không tự thực thi các task — nó dispatch các subagent để làm điều đó.

╔═══════════════════════════════════════════════════════════╗
║                    CONTROLLER LOOP                        ║
║                                                           ║
║  1. Load kế hoạch. Xác định task tiếp theo là TODO.       ║
║                                                           ║
║  2. Dispatch một subagent mới với:                        ║
║     - Nội dung task đầy đủ                                ║
║     - Các file và dependencies liên quan                  ║
║     - Không có context từ các task trước                  ║
║                                                           ║
║  3. Subagent trả về kết quả + status                      ║
║                                                           ║
║  4. Controller chạy TWO-STAGE REVIEW                      ║
║                                                           ║
║  5. Dựa trên status:                                      ║
║     DONE → đánh dấu task là DONE, tiếp tục               ║
║     DONE_WITH_CONCERNS → log concerns, tiếp tục          ║
║     NEEDS_CONTEXT → cung cấp context, retry              ║
║     BLOCKED → leo thang cho người dùng                   ║
╚═══════════════════════════════════════════════════════════╝

Controller duy trì trạng thái kế hoạch. Các subagent không duy trì trạng thái — chúng nhận một task, thực thi nó, báo cáo kết quả, và kết thúc.


Two-Stage Code Review

Mỗi task hoàn thành đi qua hai giai đoạn review trước khi được đánh dấu là DONE.

Giai Đoạn 1: Spec Compliance

Controller kiểm tra xem output của subagent có khớp với những gì task yêu cầu không:

  • File mong đợi có tồn tại không?
  • Code có làm những gì task mô tả không?
  • Verification step có pass không?
  • Không có thay đổi ngoài phạm vi nào được thực hiện không?

Giai đoạn 1 là về "chúng ta có xây dựng đúng thứ không?"

Giai Đoạn 2: Code Quality

Một subagent review mới kiểm tra code thực tế:

  • Code có rõ ràng và có thể bảo trì không?
  • Có sự trùng lặp nào nên được trích xuất không?
  • Có bất kỳ edge case nào không được xử lý?
  • Naming có phù hợp với các quy ước của codebase không?

Giai đoạn 2 là về "chúng ta có xây dựng đúng cách không?"

Hai mối quan tâm này được tách biệt có chủ đích. Spec compliance là nền tảng. Chất lượng code là quan trọng nhưng là thứ yếu.


Status Protocol

Khi một subagent hoàn thành một task, nó trả về một trong bốn status:

StatusÝ NghĩaHành Động Của Controller
DONETask hoàn thành, verification pass, không có concernsĐánh dấu task là DONE. Tiến hành task tiếp theo.
DONE_WITH_CONCERNSTask hoàn thành nhưng subagent gắn cờ điều gì đó đáng chú ýLog concerns. Đánh dấu task là DONE. Tiến hành với nhận thức.
NEEDS_CONTEXTTask không thể hoàn thành vì thiếu thông tinCung cấp context còn thiếu. Dispatch lại subagent.
BLOCKEDTask không thể hoàn thành vì một vấn đề bên ngoài scope của nóDừng. Leo thang cho người dùng với mô tả đầy đủ về tình trạng bị block.

DONE_WITH_CONCERNS

Status này là quan trọng. Nó tránh cả "vượt qua bất kể thế nào" và "chặn mọi thứ". Khi một subagent thấy điều gì đó đáng chú ý nhưng không phải là deal-breaker, nó log concern và tiếp tục. Controller track concerns đó.

Ví dụ về concerns chính đáng:

  • "Test pass nhưng coverage chỉ 67% — dưới ngưỡng thường thấy của codebase này"
  • "Implementation hoạt động nhưng tôi thấy một vấn đề performance tiềm ẩn với N lớn"
  • "Spec không đề cập đến xử lý lỗi cho trường hợp X — tôi đã bỏ qua nó nhưng nó có thể cần được đề cập"

BLOCKED

BLOCKED có nghĩa là một điều gì đó bên ngoài tầm kiểm soát của task đang ngăn tiến triển. Ví dụ:

  • Một dependency service không chạy
  • Một file cần thiết không tồn tại và không có trong scope để tạo
  • Task được xác định trên một giả định sai không thể được giải quyết trong task này

Khi BLOCKED, subagent mô tả chính xác điều gì đang block nó và tại sao nó không thể giải quyết. Controller leo thang cho người dùng với thông tin đó.


Chọn Model Cho Task

Không phải mọi task đều cần cùng một model. Chọn model phù hợp với độ phức tạp của task:

Loại TaskModel Được Khuyến NghịLý Do
Cơ học (đổi tên, định dạng, di chuyển file)Model nhỏ hơn, nhanh hơnChi phí thấp, không cần reasoning phức tạp
Tích hợp (implement feature, viết test)Model mid-tierCân bằng tốc độ và chất lượng
Kiến trúc (thiết kế hệ thống, debugging phức tạp)Model capable nhấtReasoning mở rộng tạo ra kế hoạch tốt hơn

Việc sử dụng model mạnh nhất cho mọi task lãng phí tài nguyên và làm chậm các task đơn giản không cần reasoning sâu.


Dispatching Parallel Agents

Một số task có thể chạy đồng thời. Khi các task không phụ thuộc vào nhau, dispatch chúng song song.

Bốn Quy Tắc Cho Parallel Execution

  1. Không có shared state: Các task song song không được đọc hoặc ghi vào cùng một file
  2. Không có dependencies ẩn: Nếu Task B cần output của Task A, chúng không song song — chúng là tuần tự
  3. Phạm vi rõ ràng: Mỗi task song song phải có phạm vi được xác định rõ ràng, không chồng chéo
  4. Phân loại riêng biệt: Mỗi task song song phải có một ranh giới rõ ràng để xác minh kết quả

Cú Pháp PARALLEL_GROUP

Trong kế hoạch, đánh dấu các task có thể chạy song song:

PARALLEL_GROUP: email-and-logging
  Task 5: Viết email service test
  Task 6: Viết logging service test
END_PARALLEL_GROUP

Các task trong một PARALLEL_GROUP có thể được dispatch đồng thời. Controller chờ tất cả hoàn thành trước khi tiến hành task tiếp theo ngoài group.

Khi Nào Không Nên Song Song

Đừng song song khi:

  • Task B sử dụng code được tạo bởi Task A
  • Task chia sẻ file (cả hai đọc/ghi vào cùng một file)
  • Thứ tự của output có ý nghĩa (ví dụ: migration database phải chạy theo thứ tự)
  • Bạn không chắc chắn về dependencies — nghi ngờ thì chọn tuần tự

Lỗi Thực Thi Phổ Biến

LỗiTrông Như Thế NàoCách Sửa
Context contaminationSubagent áp dụng các giả định từ task trước cho task nàyDispatch lại với context rõ ràng hơn
NEEDS_CONTEXT khi không cầnSubagent yêu cầu thông tin nằm trong task descriptionViết lại task description để rõ ràng hơn
Không bao giờ BLOCKED khi nênSubagent "giải quyết" vấn đề bằng cách đưa ra các giả định không được phê duyệtLàm rõ tiêu chí BLOCKED trong task
Bỏ qua Giai Đoạn 2Review spec compliance nhưng bỏ qua chất lượng codeThực thi cả hai giai đoạn, luôn luôn
Thiếu task testTask implementation không có task test tương ứngThêm task test trước task implementation

Sử Dụng Executing Plans Skill

Để gọi skill thực thi kế hoạch một cách rõ ràng:

/executing-plans [plan document]

Skill này hướng dẫn toàn bộ CONTROLLER LOOP, dispatch các subagent với context phù hợp, và thực thi two-stage review trên mỗi task hoàn thành.


Mô hình subagent được mượn từ quản lý kỹ thuật tốt. Bạn không giao mọi task cho một kỹ sư và yêu cầu họ nhớ mọi thứ từ mỗi task. Bạn giao từng task cho người phù hợp với context phù hợp, và bạn review kết quả trước khi tiến hành.