Bỏ qua để đến nội dung

Level: L8 — Automation & AI Agents (Bài 8/13) · Đối tượng: Người đã học bài 82 (Single Agent), đã áp dụng hết 4 mẫu

Multi-Agent là kiến trúc gồm từ 2 agent riêng biệt trở lên, mỗi agent có Reasoning/Planning độc lập (bài 80), cùng phối hợp để đạt 1 mục tiêu lớn hơn khả năng 1 agent xử lý tốt.

Điểm chuyển tiếp từ single agent (bài 82): mẫu hình thứ 5 — Orchestrator-Workers — là ranh giới mờ giữa 2 thế giới: 1 LLM trung tâm (“orchestrator”) chia nhỏ tác vụ và giao cho các LLM “worker” xử lý từng phần [S19]. Khi các “worker” này đủ độc lập (có ngữ cảnh riêng, tự quyết định cách hoàn thành phần việc của mình), chúng thực chất đã là các agent riêng biệt — đây chính là lúc Orchestrator- Workers “lớn lên” thành multi-agent thật sự.

Nhắc lại nguyên tắc đã học bài 82: multi-agent có chi phí phối hợp thật — nhiều agent cần giao tiếp, dễ phát sinh lỗi tích lũy qua nhiều tầng hơn 1 agent đơn lẻ. Hiểu đúng các mẫu hình multi-agent đã có tên chính thức giúp bạn chọn đúng cấu trúc thay vì tự phát minh 1 cách phối hợp tùy tiện — và giao tiếp rõ ràng hơn với đội kỹ thuật (“chúng ta cần Manager pattern ở đây” thay vì mô tả lại ý tưởng từ đầu).

3. How It Works — 3 mẫu hình multi-agent có tên chính thức

Phần tiêu đề “3. How It Works — 3 mẫu hình multi-agent có tên chính thức”
  • Manager pattern (OpenAI) — 1 agent “manager” trung tâm điều phối các agent chuyên biệt khác thông qua tool call, giữ quyền kiểm soát và tổng hợp kết quả cuối cùng [S20]. Manager coi mỗi agent con như 1 “tool” nó có thể gọi.
  • Decentralized pattern (OpenAI) — nhiều agent ngang hàng, “handoff” (chuyển giao 1 chiều) cho nhau dựa trên chuyên môn, không có agent trung tâm giữ quyền kiểm soát xuyên suốt [S20].
  • Multi-agent phân cấp (hierarchical) (Google ADK) — các agent tổ chức theo cấu trúc phân cấp, có thể điều phối/giao việc cho nhau [S21]. ADK hỗ trợ 2 cách tiếp cận orchestration: workflow agent xác định trước (Sequential/Parallel/Loop) hoặc LLM-driven dynamic routing (để LLM tự quyết định định tuyến) [S21].

Lưu ý minh bạch quan trọng (đã xác lập ở phần nền tảng Level 8): Sequential/Parallel/Loop của ADK không đồng nhất với 4 mẫu hình đã học bài 82 (Prompt Chaining/Routing/Parallelization/Evaluator-Optimizer) dù nghe giống — đây là 2 framework độc lập của 2 công ty khác nhau ( Google vs Anthropic), sự tương đồng chỉ ở mức khái niệm chung của ngành, không phải 1 framework mô phỏng framework kia [S21].

Sơ đồ đề xuất: 3 sơ đồ đặt cạnh nhau, mỗi sơ đồ nhiều vòng tròn Execution Loop riêng biệt (khác sơ đồ bài 82 chỉ có 1 vòng tròn):

  1. Manager pattern — hình sao: 1 vòng tròn trung tâm (Manager) nối ra nhiều vòng tròn vệ tinh (agent chuyên biệt), mũi tên 2 chiều.
  2. Decentralized pattern — nhiều vòng tròn ngang hàng, mũi tên 1 chiều (handoff) từ vòng tròn này sang vòng tròn khác, không có vòng tròn trung tâm.
  3. Hierarchical (ADK) — cấu trúc cây, vòng tròn gốc phân nhánh xuống nhiều tầng vòng tròn con.

5. Step-by-Step — Chọn đúng mẫu hình multi-agent

Phần tiêu đề “5. Step-by-Step — Chọn đúng mẫu hình multi-agent”
  1. Tác vụ có đủ phức tạp để cần nhiều chuyên môn khác nhau, không chỉ nhiều bước (nếu chỉ nhiều bước, quay lại bài 82 — Prompt Chaining/Routing có thể đã đủ)?
  2. Có cần 1 điểm kiểm soát trung tâm tổng hợp kết quả cuối, hay từng phần việc có thể giao thẳng cho đúng agent chuyên trách rồi kết thúc ở đó? → Câu trả lời đầu tiên dẫn tới Manager pattern; câu trả lời thứ hai dẫn tới Decentralized pattern.
  3. Quy mô có đủ lớn/phức tạp để cần cấu trúc phân cấp nhiều tầng (không chỉ 1 tầng manager–worker)? → cân nhắc mô hình hierarchical.
  4. Mặc định nên cân nhắc Manager pattern trước — chỉ chuyển sang Decentralized khi thực sự không cần 1 điểm kiểm soát trung tâm.

(2 ví dụ có nguồn thật từ [S20] — không bịa thêm.)

Manager pattern: 1 agent “manager” điều phối 3 agent chuyên biệt để dịch 1 câu sang nhiều ngôn ngữ khác nhau (Tây Ban Nha, Pháp, Ý) — manager gọi từng agent dịch thuật như 1 tool, tổng hợp kết quả trả về cho người dùng [S20].

Decentralized pattern: 1 agent “triage” (phân loại ban đầu) tiếp nhận yêu cầu khách hàng, sau đó handoff cho 1 trong 3 agent chuyên trách — hỗ trợ kỹ thuật, bán hàng, hoặc quản lý đơn hàng — tùy nội dung yêu cầu [S20]. Đây là phiên bản multi-agent của Customer Support Agent đã học bài 79 — khác với phiên bản single-agent-với-Routing đã học bài 82 (agent tự quyết định hướng xử lý bên trong chính nó, thay vì chuyển hẳn cho 1 agent khác).

Tác vụ này có cần nhiều chuyên môn riêng biệt không (không chỉ nhiều
bước)? [ ] Có / [ ] Không → nếu Không, quay lại bài 82.
Nếu Có:
[ ] Cần 1 điểm kiểm soát trung tâm tổng hợp kết quả? → Manager pattern
[ ] Không cần kiểm soát trung tâm, chỉ cần chuyển đúng chuyên gia? →
Decentralized pattern
[ ] Quy mô đủ lớn, cần cấu trúc nhiều tầng? → Hierarchical (ADK)

Quay lại agent bạn đã thiết kế ở bài 82 (đã áp dụng ít nhất 1 mẫu hình single-agent). Giả sử tác vụ đó mở rộng quy mô đáng kể — dùng worksheet mục 7 để xác định: nó có trở thành ứng viên multi-agent không, và nếu có, mẫu hình nào (Manager/Decentralized/Hierarchical) phù hợp hơn — giải thích lý do.

Manager AgentWorker AgentCritic Agent
Hình 8.8 — Multi-Agent: 3 mẫu hình chính thức — Manager, Decentralized, Hierarchical.

(Suy luận từ nguyên tắc [S19, S20, S21], không phải quan sát độc lập.)

  • Dùng multi-agent cho tác vụ mà 1 agent với Routing (bài 82) đã đủ — thêm chi phí phối hợp không cần thiết.
  • Nhảy thẳng vào Decentralized pattern khi 1 điểm kiểm soát trung tâm (Manager) thực ra an toàn hơn và dễ debug hơn.
  • Coi Sequential/Parallel/Loop (ADK) và 5 mẫu hình Anthropic là cùng 1 hệ thống — đây là lỗi đã cảnh báo tường minh ở nguồn gốc [S21], dễ gây nhầm lẫn nếu đọc tài liệu 2 hãng cùng lúc.
  • [S19] Building Effective Agents, Anthropic — Orchestrator-Workers, điểm chuyển tiếp single→multi-agent.
  • [S20] A Practical Guide to Building Agents, OpenAI — Manager pattern, Decentralized pattern, 2 ví dụ có nguồn thật (dịch thuật, triage khách hàng).
  • [S21] Agent Development Kit (ADK) — Technical Overview, Google — 4 primitive, cấu trúc hierarchical, 2 kiểu orchestration.
  • Dẫn chiếu (không trích dẫn mới): bài 79 (Customer Support Agent, đối chiếu phiên bản single-agent ở bài 82 với phiên bản Decentralized ở đây); bài 80 (8 bộ phận, mỗi agent trong hệ thống multi-agent vẫn có đủ 8 bộ phận riêng); bài 87 (Guardrails, dẫn chiếu ở mục 11).

Nội dung kiểm chứng qua nguồn Tier 1 (S19, S20, S21), tái sử dụng nguyên vẹn từ nghiên cứu đã có (2026-07-11), không cần freshness audit lại lần 2 trong cùng Level. Nguyên lý orchestration multi-agent ổn định; chi tiết phiên bản/tính năng cụ thể của ADK có thể đổi nhanh hơn (đã ghi rõ ở chapter nền tảng gốc).