Phần 3 trong 3 của chuỗi bài “Bí thuật Claude Code”
Ở hai bài trước, chúng ta đã xây dựng được một “Siêu nhân”: một Agent biết suy nghĩ (TAOD Loop) và biết sử dụng công cụ một cách khôn ngoan (Tool & Context).
Nhưng ngay cả siêu nhân cũng có giới hạn. Khi độ phức tạp của dự án tăng lên—ví dụ: xây dựng toàn bộ một ứng dụng web full-stack từ đầu—một Agent đơn lẻ sẽ bắt đầu quá tải. Nó sẽ quên context, nhầm lẫn giữa code frontend và backend, hoặc đơn giản là kiệt sức vì context window bị đầy.
Đó là lúc chúng ta cần bước sang cấp độ tiếp theo: Hệ thống Đa Agent (Multi-Agent Systems).
Mô hình Ban nhạc: Tại sao nhiều người lại tốt hơn một người
Hãy tưởng tượng một dàn nhạc giao hưởng. Nếu bạn bắt một người nhạc công vừa chơi violin, vừa thổi kèn trumpet, vừa đánh trống, kết quả sẽ là một mớ hỗn độn. Thay vào đó, chúng ta có những chuyên gia (specialists) tập trung vào nhạc cụ của họ, và một nhạc trưởng (conductor) giữ nhịp điệu chung.
Trong thế giới AI, mô hình này giải quyết vấn đề “Bão hòa ngữ cảnh” (Context Saturation). Thay vì bắt một Agent nhớ tất cả luật lệ của SQL, React, CSS, và AWS cùng lúc, chúng ta chia nhỏ chúng ra.
Chuyên gia vs. Đa năng: Cuộc chiến hiệu suất
Agent Đa năng (Generalist)
- Prompt: “Bạn là một lập trình viên full-stack giỏi mọi thứ.”
- Ưu điểm: Dễ xây dựng.
- Nhược điểm: “Nhạc nào cũng nhảy nhưng không hay”. Dễ bị ảo giác khi chuyển đổi context (ví dụ: đang viết Python lại nhầm sang cú pháp JS).
Agent Chuyên gia (Specialist)
- Prompt: “Bạn là chuyên gia về CSS Tailwind. Nhiệm vụ duy nhất của bạn là làm cho giao diện đẹp, đúng chuẩn design system. Bạn không quan tâm logic JS.”
- Ưu điểm:
- Prompt tập trung: Ít luật lệ hơn = tuân thủ tốt hơn.
- Context sạch sẽ: Chỉ chứa những file CSS liên quan.
- Hiệu suất cao: Giống như thợ hàn làm việc của thợ hàn.
Các Vai trò trong “Công ty phần mềm AI”
Để giải quyết một vấn đề lớn, chúng ta có thể mô phỏng cấu trúc của một đội ngũ phát triển phần mềm thực thụ bằng các Agent:
1. Người điều phối (The Orchestrator / Product Manager)
- Nhiệm vụ: Không viết code. Nhiệm vụ là hiểu yêu cầu người dùng, chia nó thành các ticket nhỏ, và giao cho đúng người.
- Công cụ:
assign_task,review_plan.
2. Kiến trúc sư (The Planner)
- Nhiệm vụ: Đọc codebase hiện tại, vẽ ra bản đồ thay đổi, xác định các file cần tạo/sửa.
- Công cụ:
read_file,find_files.
3. Kỹ sư Frontend / Backend (The Builders)
- Nhiệm vụ: Nhận một ticket cụ thể (“Tạo component Button”), viết code, chạy test cục bộ.
- Công cụ:
write_file,run_test.
4. Người kiểm thử (The QA/Reviewer)
- Nhiệm vụ: Đóng vai người khó tính. Tìm lỗi logic, lỗ hổng bảo mật, hoặc vấn đề về style.
- Công cụ:
run_lint,analyze_code.
Cơ chế Ủy quyền (Delegation Patterns)
Làm sao để các Agent này nói chuyện với nhau?
1. Router Pattern (Mô hình Bộ định tuyến)
Người dùng nói chuyện với Router. Router phân tích ý định và chuyển tiếp đến Agent phù hợp.
User: “Tại sao database bị lỗi?” Router: “Câu này dành cho Backend Agent. Chuyển tiếp…”
Đây là mô hình đơn giản nhất, thường dùng cho các tác vụ hỗ trợ khách hàng hoặc tra cứu.
2. Manager-Worker Pattern (Mô hình Quản lý – Công nhân)
Manager (Điều phối viên) giữ trạng thái tổng thể của dự án (Global State). Nó gọi Worker lên, giao việc, chờ Worker báo cáo kết quả “Xong”, rồi mới gọi Worker tiếp theo.
- Manager: “Planner, hãy lập kế hoạch.” -> Wait -> “Đã có kế hoạch.”
- Manager: “Coder, hãy thực thi bước 1 của kế hoạch.” -> Wait -> “Đã xong.”
- Manager: “Reviewer, hãy kiểm tra code đó.”
Đây là mô hình mạnh mẽ nhất cho các tác vụ lập trình (coding tasks), vì nó duy trì được mạch lạc của dự án.
Kỹ năng được đóng gói (Skill Activation)
Một khái niệm thú vị trong điều phối là “Kỹ năng” (Skills). Thay vì tạo ra một Agent hoàn toàn mới cho mỗi việc nhỏ, chúng ta có thể nạp (inject) các “gói kỹ năng” vào một Agent worker.
Ví dụ: Khi cần sửa lỗi, Orchestrator nạp prompt “Debug Specialist” vào Worker. Khi cần viết tài liệu, nó nạp prompt “Technical Writer”. Điều này giúp tiết kiệm tài nguyên hệ thống (không cần nuôi 10 agent chạy nền) mà vẫn đảm bảo tính chuyên môn hóa.
Sự thật ngã ngửa: Đơn giản vẫn là vua
Đọc đến đây, bạn có thể muốn xây dựng một đồ thị (graph) phức tạp với 20 Agent nói chuyện chéo với nhau. Đừng làm vậy.
Định luật Gall: “Mọi hệ thống phức tạp hoạt động được đều phát triển từ một hệ thống đơn giản hoạt động được.”
Trong thực tế, 90% các use-case hàng ngày chỉ cần một mô hình tuyến tính đơn giản: Planner -> Executor -> Reviewer.
Sự phức tạp nên nằm ở Prompts (hướng dẫn chi tiết cho từng vai trò) chứ không phải ở Kiến trúc (cách chúng nối dây với nhau). Một hệ thống orchestration rối rắm thường dẫn đến việc các Agent “cãi nhau” hoặc đi vào vòng lặp vô tận mà bạn không thể debug nổi.
Tổng kết chuỗi bài viết
Vậy là chúng ta đã đi qua hành trình khám phá “Bí thuật” đằng sau những AI Agent hiện đại.
- Vòng lặp Agentic (TAOD): Biến AI từ cái miệng biết nói (Chatbot) thành đôi tay biết làm (Agent).
- Công cụ & Context: Trang bị cho Agent những công cụ tối giản và một bộ nhớ ngăn nắp.
- Điều phối & Ủy quyền: Nâng cấp từ cá nhân xuất sắc thành tập thể vô địch.
Tương lai của lập trình không phải là AI thay thế con người. Tương lai là mỗi lập trình viên sẽ trở thành một Nhạc trưởng, chỉ huy một dàn nhạc các AI Agent để cùng nhau tạo ra những bản giao hưởng phần mềm tuyệt vời hơn, nhanh hơn và sáng tạo hơn bao giờ hết.
Giờ thì, cây đũa chỉ huy đang ở trong tay bạn. Hãy bắt đầu bản nhạc của mình!
Hết.
