Cách xây dựng đội ngũ 4 tác nhân AI giúp bạn hoàn thiện tính năng ngay cả khi đang ngủ (Chi tiết thiết lập bên trong)

Bốn AI agent có thể hoàn thành một tính năng trong khi bạn ngủ. Hầu hết mọi người không bao giờ kết nối chúng lại với nhau.

Họ gửi một cái đến người đánh giá, một cái khác đến người tạo test, thủ công, từng cái một, mỗi cái quên mất cái trước đã làm gì. Bạn vẫn là nút thắt cổ chai.

Giải pháp: Planner → Coder → Tester → Reviewer, được xâu chuỗi để tự động bàn giao. Một kích hoạt, bốn giai đoạn, một tính năng hoàn chỉnh vào buổi sáng.

Đây là toàn bộ pipeline, kèm mã có thể copy-paste 👇

Trước khi đi sâu, tôi chia sẻ ghi chú hàng ngày về AI & vibe coding trên kênh Telegram của tôi: https://t.me/zodchixquant 🧠

Tại sao một pipeline lại tốt hơn một đống agent

Một agent làm tất cả sẽ lấp đầy context window của nó với kế hoạch, mã, test và ghi chú đánh giá cho đến khi chất lượng giảm sút.

Bốn chuyên gia, mỗi người ở trong một context sạch sẽ và hẹp.

Bí quyết nằm ở file bàn giao (handoff file). Mỗi agent ghi đầu ra của nó vào nơi agent tiếp theo có thể đọc: Planner ghi spec vào .pipeline/spec.md, Coder đọc nó và ghi .pipeline/changes.md, và cứ thế.

Orchestrator chạy chúng theo thứ tự là một lệnh gạch chéo (slash command) duy nhất. Đó là toàn bộ vấn đề: bốn subagent, một lệnh, một thư mục dùng chung cho việc bàn giao.

Agent 1: The Planner (subagent, opus)

Planner không bao giờ viết mã. Nó biến một yêu cầu tính năng mơ hồ thành một spec cụ thể mà Coder có thể làm theo mà không cần phải đoán.

Tạo .claude/agents/planner.md:

1---
2name: planner
3description: Biến một yêu cầu tính năng thành spec triển khai. Sử dụng như giai đoạn đầu tiên của pipeline tính năng.
4tools: Read, Grep, Glob, Write
5model: opus
6---
7
8Bạn là một chuyên gia lập kế hoạch. Bạn KHÔNG viết mã triển khai.
9
10Với một yêu cầu tính năng:
111. Đọc các phần liên quan của codebase để hiểu các mẫu (pattern) hiện tại.
122. Viết một spec vào `.pipeline/spec.md` bao gồm:
13   - Các file cần tạo hoặc sửa đổi, kèm đường dẫn chính xác
14   - Giao diện (interface) hoặc chữ ký hàm (function signature) cần có
15   - Các trường hợp biên (edge case) mà quá trình triển khai phải xử lý
16   - Mẫu (pattern) hiện tại nào cần tuân theo (đặt tên file để sao chép)
173. Đánh dấu bất cứ điều gì mơ hồ là CÂU HỎI MỞ (OPEN QUESTION) ở đầu spec.
18
19Giữ spec ngắn gọn. Coder chỉ đọc cái này và không gì khác, vì vậy đừng
20để lại khoảng trống và đừng phát minh ra các yêu cầu không được yêu cầu.

Planning chạy trên opus vì giai đoạn này đặt ra trần chất lượng cho mọi thứ sau nó. Một spec mơ hồ tạo ra mã mơ hồ, bất kể Coder có giỏi đến đâu.

Agent 2: The Coder (subagent, sonnet)

Coder đọc spec và viết mã triển khai. Nó không lập kế hoạch và không đánh giá công việc của chính mình, nó chỉ xây dựng những gì spec yêu cầu.

Tạo .claude/agents/coder.md:

1---
2name: coder
3description: Triển khai spec tại .pipeline/spec.md. Sử dụng như giai đoạn thứ hai của pipeline tính năng, sau planner.
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8Bạn là một chuyên gia triển khai.
9
101. Đọc toàn bộ `.pipeline/spec.md`. Nếu có CÂU HỎI MỞ, hãy dừng lại và
11   đưa ra chúng thay vì đoán.
122. Triển khai chính xác những gì spec mô tả. Tuân theo các mẫu (pattern)
13   nó chỉ định. Đừng thêm các tính năng nó không yêu cầu.
143. Viết một bản tóm tắt ngắn vào `.pipeline/changes.md`: file nào đã thay đổi,
15   mỗi thay đổi làm gì, và bất cứ điều gì Tester nên tập trung vào.
16
17Bạn viết mã phù hợp với repo. Bạn không tái cấu trúc (refactor) mã
18không liên quan hoặc "cải thiện" những thứ nằm ngoài phạm vi của spec.

Sonnet là lựa chọn đúng ở đây: triển khai dựa trên một spec rõ ràng chính xác là công việc cân bằng giữa chi phí và chất lượng mà Sonnet xử lý tốt nhất.

Ghi chú bàn giao tại .pipeline/changes.md cho phép Tester nhắm đúng bề mặt thay vì test một cách mù quáng.

Agent 3: The Tester (subagent, sonnet)

Tester đọc những gì đã thay đổi và viết các test chứng minh tính năng hoạt động, sau đó chạy chúng.

Tạo .claude/agents/tester.md:

1---
2name: tester
3description: Viết và chạy các test cho những thay đổi được mô tả trong .pipeline/changes.md. Giai đoạn thứ ba của pipeline tính năng.
4tools: Read, Write, Edit, Grep, Glob, Bash
5model: sonnet
6---
7
8Bạn là một chuyên gia test.
9
101. Đọc `.pipeline/changes.md` để xem những gì đã được xây dựng và ở đâu.
112. Đọc các file đã thay đổi và spec tại `.pipeline/spec.md`.
123. Viết các test bao gồm: luồng chính (happy path), các trường hợp biên (edge case) mà spec đã nêu,
13   và ít nhất một trường hợp thất bại (failure case). Phù hợp với framework test của repo.
144. Chạy các test. Nếu bất kỳ test nào thất bại, hãy ghi các lỗi vào
15   `.pipeline/test-results.md` và DỪNG LẠI. Đừng tự sửa mã.
165. Nếu tất cả đều qua, hãy ghi chú điều đó vào `.pipeline/test-results.md`.
17
18Bạn kiểm tra hành vi (behavior), không phải chi tiết triển khai. Một test thất bại có nghĩa là
19pipeline sẽ tạm dừng để Reviewer xem xét, không phải bạn vá nó.

Agent 4: The Reviewer (subagent, opus)

Cánh cổng cuối cùng. Reviewer đọc mọi thứ mà pipeline tạo ra và đưa ra phán quyết trước khi bất cứ thứ gì đến được nhánh chính (main branch) của bạn.

Tạo .claude/agents/reviewer.md:

1---
2name: reviewer
3description: Đánh giá cuối cùng toàn bộ đầu ra của pipeline. Giai đoạn thứ tư và cuối cùng trước khi có sự chấp thuận của con người.
4tools: Read, Grep, Glob, Bash
5model: opus
6---
7
8Bạn là một senior reviewer. Bạn chỉ đọc. Bạn không chỉnh sửa mã.
9
101. Đọc spec, bản tóm tắt thay đổi và kết quả test từ
11   `.pipeline/`.
122. Chạy `git diff` để xem các thay đổi thực tế.
133. Đánh giá: mã có khớp với spec không? Các test có ý nghĩa hay chỉ
14   hời hợt? Có vấn đề gì về bảo mật, hiệu suất hoặc tính đúng đắn không?
154. Viết phán quyết vào `.pipeline/review.md`:
16   - PHÁN QUYẾT: SHIP / NEEDS WORK / BLOCK
17   - Với NEEDS WORK hoặc BLOCK, hãy liệt kê chính xác những gì cần sửa và ở đâu.
18
19Hãy là tuyến phòng thủ cuối cùng. Nếu test xanh nhưng mã sai,
20hãy nói BLOCK. Test xanh không đồng nghĩa với hành vi đúng.

Các công cụ chỉ đọc có nghĩa là Reviewer không thể che đậy vấn đề bằng cách chỉnh sửa, nó chỉ có thể phán xét.

Orchestrator: một lệnh để chạy cả bốn

Bây giờ là phần biến bốn agent riêng lẻ thành một pipeline. Một lệnh gạch chéo (slash command) gọi chúng theo thứ tự, mỗi agent nhận file bàn giao mà agent trước đã viết.

Tạo .claude/commands/ship.md:

1Chạy toàn bộ pipeline tính năng cho: $ARGUMENTS
2
3Thực thi các giai đoạn này theo thứ tự. Đừng nhảy cóc. Sau mỗi giai đoạn,
4xác nhận file bàn giao tồn tại trước khi bắt đầu giai đoạn tiếp theo.
5
61. Ủy quyền cho subagent `planner` với yêu cầu tính năng ở trên.
7   Chờ `.pipeline/spec.md`.
82. Nếu spec có CÂU HỎI MỞ, hãy dừng lại và hiển thị chúng cho tôi. Nếu không,
9   hãy ủy quyền cho subagent `coder`. Chờ `.pipeline/changes.md`.
103. Ủy quyền cho subagent `tester`. Chờ `.pipeline/test-results.md`.
11   Nếu test thất bại, hãy dừng lại và hiển thị lỗi cho tôi.
124. Ủy quyền cho subagent `reviewer`. Hiển thị cho tôi `.pipeline/review.md`.
13
14Báo cáo phán quyết cuối cùng. Đừng merge bất cứ thứ gì. Để lại nhánh (branch)
15cho tôi đánh giá vào buổi sáng.

Sau đó, một dòng lệnh duy nhất kích hoạt toàn bộ chuỗi: /ship thêm giới hạn tốc độ cho endpoint đăng nhập.

Nơi tôi chạy phiên bản qua đêm

Đó là lý do tôi sử dụng Teamly: dịch vụ cloud hosting được quản lý, được xây dựng riêng cho các AI agent.

Bạn thuê một đội, nó chạy 24/7 trên cơ sở hạ tầng chuyên dụng, và bạn không bao giờ phải đụng đến server.

Lý do @Teamly phù hợp cụ thể với bài viết này: vấn đề bàn giao đã được giải quyết cho bạn.

Mọi thứ chúng ta tự xây dựng thủ công ở trên (file spec, file thay đổi, orchestrator xâu chuỗi agent này với agent khác) Teamly thực hiện với một Coordinator.

Nó phân luồng công việc giữa các agent, chuyển context từ agent này sang agent tiếp theo và giữ một bản tóm tắt (brief) dùng chung mà tất cả đều đọc.

Cùng một luồng Planner-to-Coder-to-Tester, ngoại trừ việc bạn không phải tự kết nối các bước bàn giao.

Sự khác biệt là @Teamly không chỉ dành cho mã. Cùng một sự phối hợp đó có thể chạy một đội marketing, một đội nghiên cứu hoặc một đội hỗ trợ.

Pipeline Claude Code của bạn giao hàng tính năng qua đêm; một đội marketing của Teamly giao hàng nội dung theo cùng một cách, với cùng logic bàn giao bên dưới.

Xây dựng đội ngũ chính xác mà bạn cần

Tính năng mới, nhóm đó vừa ra mắt: Đội Của Tôi (My Team)

Bây giờ bạn có thể xây dựng đội của mình chỉ với 3 câu hỏi.

Bạn cũng có thể kiểm soát: quy tắc giọng điệu (voice rules), các cụm từ bị cấm, tích hợp, phong cách đội (Nghiêm ngặt / Thông thường / Sáng tạo) và quy mô đội (2-4 agent).

@Teamly trả về một đội với một lý do thực sự giải thích tại sao mỗi chuyên gia lại có mặt ở đó, không phải là văn bản sáo rỗng. Hoán đổi bất kỳ agent nào bằng một cú nhấp chuột. Chỉnh sửa bản tóm tắt nếu nó không phù hợp.

Vấn đề là một bản tóm tắt có cấu trúc buộc phải rõ ràng, sau đó tạo nên một đội mà bạn có thể kiểm tra trước khi thuê.

Cùng một kiến trúc bàn giao như các đội được xây dựng sẵn, được điều chỉnh cho phù hợp với vấn đề cụ thể của bạn.

Dùng thử miễn phí trước

Bạn có thể kiểm tra toàn bộ mọi thứ miễn phí trong 3 ngày trên Teamly 5, không tính phí cho đến ngày thứ 4.

Nếu bạn ở lại, giá là $29/tháng cho 5 agent.

Đủ rẻ để một tính năng được giao hàng trả tiền cho cả tháng.

Điểm mấu chốt

Sự khác biệt giữa một đống agent và một pipeline nằm ở việc bàn giao.

Bốn chuyên gia ghi vào các file dùng chung, một orchestrator chạy chúng theo thứ tự, mỗi giai đoạn xây dựng dựa trên giai đoạn trước thay vì bắt đầu lại từ đầu.

Xây dựng Planner và Coder trước và chạy chúng như một chuỗi hai giai đoạn. Khi luồng đó cảm thấy ổn định, hãy thêm Tester và Reviewer.

Vào thời điểm cả bốn được kết nối, bạn sẽ khởi động một tính năng trước khi đi ngủ và đọc phán quyết cùng với tách cà phê.

Để có ghi chú hàng ngày về AI agent, vibe coding và thiết lập Claude Code: https://t.me/zodchixquant 🧠