Trả lời ngắn: Multi-Agent System là hệ thống có nhiều agent phối hợp theo vai trò và giao thức chung để hoàn thành một mục tiêu. Mỗi agent có context hoặc tool riêng; cơ chế điều phối chia việc, chuyển trạng thái và ghép kết quả. Thêm agent chỉ hữu ích khi nhiệm vụ chia được và có kiểm soát phối hợp.

Đọc xong, bạn sẽ hiểu:

  • Agent, vai trò và tool khác nhau ở đâu.
  • Ba cách phối hợp agent phổ biến.
  • Vì sao task contract, owner và shared state quan trọng.
  • Khi nào một agent đơn giản tốt hơn cả một “đội quân”.

Lưu ý giáo dục: Bài dùng tác vụ và dữ liệu giả. Hệ nhiều agent không tự an toàn hay chính xác hơn; mỗi agent vẫn cần quyền tối thiểu, validation, ngân sách và điểm dừng.

1. Multi-Agent System là gì? Nhiều agent chưa chắc thành một đội

a. Một agent là một vòng làm việc có biên

Trong bài trước, Prompt Routing #26 chọn đúng nhánh trước khi xử lý. Multi-Agent System đi thêm một bước: nhiều agent cùng tham gia. Mỗi agent là một vòng model nhận context, suy luận, dùng tool được phép, quan sát kết quả rồi tiếp tục hoặc dừng.

Gọi ba prompt là “Researcher”, “Writer”, “Reviewer” chưa đủ. Một đội phải biết ai giao việc, mỗi agent nhận input gì, dùng tool nào, trả output ra sao và ai chịu trách nhiệm cuối.

Ví dụ, một agent tìm tính năng, một agent đọc chính sách riêng tư, một agent kiểm claim. Nếu cả ba cùng sửa một file, đó là chen vào một bàn chứ chưa phải phối hợp.

Hình 1 — Nhiều agent tạo giá trị khi nhiệm vụ tách rõ và kết quả quay về một điểm tổng hợp.

b. Vai trò không phải tool

Vai trò mô tả trách nhiệm: nghiên cứu, phân tích hoặc review. Tool là khả năng cụ thể: web search, đọc file hoặc truy vấn dữ liệu. Hai agent có thể dùng cùng model nhưng khác prompt, context và tool; ngược lại, một agent có nhiều tool vẫn chỉ là một agent.

Ranh giới này giúp cấp quyền đúng. Reviewer cần đọc report và evidence, không nhất thiết có quyền sửa source hoặc gửi email. Tên “reviewer” không tự chặn hành động; harness phải thật sự giới hạn tool.

c. Lợi ích đến từ sức chứa và sự độc lập

Nhiều agent có context riêng nên có thể khám phá các hướng độc lập song song. Anthropic cho biết hệ Research của họ dùng lead agent cùng subagents để tìm nhiều hướng, rồi tổng hợp; họ cũng nhấn mạnh kiến trúc này tốn token cao và không hợp các việc phụ thuộc chặt vào cùng context. Anthropic — Multi-agent research system

Vậy lợi ích không phải “nhiều bộ não luôn thông minh hơn”. Chỉ cân nhắc nhiều agent khi subtask có thể chạy độc lập, một agent không đủ context/thời gian, và eval cho thấy chất lượng hoặc tốc độ tăng đủ bù token cùng lỗi phối hợp.

2. Ba cách phối hợp agent thường gặp

a. Orchestrator–worker

Orchestrator là agent điều phối: hiểu mục tiêu, chia subtask, chọn worker, theo dõi tiến độ và ghép kết quả. Worker nhận một phần việc có biên rồi trả output theo contract.

Trong case ứng dụng ghi chú, orchestrator có thể giao:

  • Worker A: lập bảng tính năng từ ba tài liệu giả.
  • Worker B: trích điều khoản riêng tư từ ba policy giả.
  • Reviewer: đánh dấu claim thiếu evidence, chỉ đọc.
  • Orchestrator: xử lý xung đột và viết bảng cuối.

Mẫu này hợp research có nhánh độc lập. Nhưng orchestrator chia sai thì cả đội đi sai; một worker treo có thể giữ lượt tổng hợp.

b. Handoff theo trạng thái

Handoff là chuyển quyền xử lý cùng một payload trạng thái sang agent khác. Triage agent có thể nhận ticket, gắn nhãn và chuyển billing agent với issue, evidence, missing_fields, allowed_actions.

Ví dụ handoff: issue="trừ tiền hai lần"; evidence=["ảnh hóa đơn E1"]; missing_fields=["transaction_id"]; allowed_actions=["read_status"].

Handoff giống chuyền hồ sơ qua các bàn. Payload thiếu trường khiến agent sau phải đoán. Vì vậy, “chuyển sang billing” phải kèm trạng thái, không chỉ câu nhắn tự do.

c. Peer, debate và reviewer

Một số hệ cho agents trao đổi ngang hàng hoặc tạo nhiều phương án rồi dùng reviewer chọn. Microsoft Research mô tả AutoGen như hạ tầng ghép các agent hội thoại có thể kết hợp model, human input và tool theo nhiều conversation pattern. Microsoft Research — AutoGen

Mẫu peer linh hoạt nhưng khó biết ai có quyền quyết định. Với production, nên ghi rõ: reviewer đưa verdict/evidence; owner cuối mới được sửa artifact. “Hai agent đồng ý” không thay thế fact check.

3. Một hệ nhiều agent chạy từ đầu đến cuối ra sao?

a. Bắt đầu bằng task contract

Task contract là phiếu giao việc có cấu trúc. Tối thiểu gồm:

  1. Objective: kết quả cần đạt.
  2. Input và nguồn được phép.
  3. Output schema cùng evidence bắt buộc.
  4. Tool và hành động được phép/cấm.
  5. Owner của artifact.
  6. Done rule, deadline và stop rule.

Hình 2 — Phiếu bàn giao rõ giúp worker biết việc nào phải làm, việc nào phải dừng.

Một lệnh “hãy nghiên cứu privacy” quá rộng. Lệnh tốt hơn là: “Đọc ba policy giả P1–P3; trả bảng năm tiêu chí, mỗi claim có evidence ID; không mở web; Dừng sau 10 phút; nếu thiếu bất kỳ policy nào, trả bảng phần đã xác minh, ghi unknown cho app thiếu nguồn và liệt kê policy cần bổ sung.”

b. Giữ shared state có schema và owner

Shared state là nơi lưu kế hoạch, task status, evidence và artifact chung. Nó không nên là một đoạn chat dài mà mọi agent tự diễn giải. Dùng schema như task_id, owner, status, inputs, output_ref, error giúp resume và audit dễ hơn.

Mỗi artifact có một owner ghi. Workers trả patch hoặc result riêng; orchestrator mới ghép vào report. Cách này tránh hai agent cùng sửa một hàng rồi một bên đè mất thay đổi bên kia.

c. Validate trước rồi mới aggregate

Aggregation là ghép kết quả workers và xử lý trùng lặp, mâu thuẫn hoặc thiếu evidence. Đừng nối ba đoạn văn rồi gọi đó là synthesis.

Pipeline nên kiểm output schema, nguồn, phạm vi task và lỗi trước. Worker thất bại có thể retry có giới hạn, giao lại hoặc đánh dấu thiếu; không được âm thầm bịa phần còn trống. Orchestrator chỉ kết thúc khi done rule toàn hệ đạt, không phải khi mọi agent nói “xong”.

4. Khi nào nhiều agent làm hệ thống tệ hơn?

a. Năm lỗi phối hợp hay gặp

  • Làm trùng: task quá mơ hồ nên workers tìm cùng một thứ.
  • Bỏ sót: mỗi agent tưởng phần khó thuộc người khác.
  • Write conflict: nhiều agent cùng sửa artifact có thể làm mất thay đổi.
  • Context loss: handoff chỉ chuyển kết luận mà bỏ evidence và constraint.
  • Delegation spiral: agent tiếp tục sinh agent hoặc retry mà không có trần.

Lỗi còn có thể cộng dồn. Nếu worker hiểu sai, reviewer kiểm hời hợt và orchestrator tổng hợp tự tin, output cuối trông mượt hơn nhưng sai sâu hơn.

b. Chi phí và độ trễ tăng theo phối hợp

Mỗi agent mới tạo thêm lượt gọi AI, lượt dùng công cụ và dữ liệu phải lưu. Chạy song song có thể giảm thời gian chờ, nhưng tổng xử lý và chi phí vẫn tăng.

Anthropic nhận thấy hệ nhiều agent hợp với tác vụ giá trị cao, cần khảo sát nhiều hướng và dùng nhiều công cụ. Việc cần dùng chung một bối cảnh hoặc có nhiều bước phụ thuộc chặt thường kém phù hợp hơn. Anthropic

Đừng chỉ đo final answer. Eval cần đo completion, evidence, làm trùng, handoff fail, token/latency, retry và tỷ lệ người thật phải sửa để thấy rủi ro toàn hệ.

c. Checklist chọn một hay nhiều agent

Dùng nhiều agent khi:

  • Có ít nhất hai subtask độc lập và output ghép được.
  • Mỗi subtask cần context hoặc tool riêng.
  • Giá trị kết quả đủ trả chi phí phối hợp.
  • Có schema, owner, budget và stop rule kiểm được.

Giữ một agent khi task nhỏ, phụ thuộc tuần tự chặt, cần cùng context hoặc một prompt + vài tool đã làm tốt. Hãy chứng minh single-agent baseline thiếu gì trước khi thêm đội.

5. Bài tập 15 phút: lập Multi-Agent Team Card

a. Case giả và giới hạn

Trên giấy hoặc Markdown, đặt mục tiêu: “So sánh ba app ghi chú giả A, B, C theo năm tiêu chí.” Dùng bộ F1–F6 và P1–P3 được cung cấp; trong đó có một claim mâu thuẫn và một nguồn thiếu. Sau khi điền Team Card, đối chiếu bảng expected flags.

Chọn coordinator, feature worker, privacy worker và reviewer. Với mỗi agent, ghi objective, input, output, tool giả, quyền cấm và stop rule.

b. Mẫu đối chiếu đã điền

Trường Mẫu điền
Shared goal Bảng 3 app × 5 tiêu chí, claim có evidence ID.
Feature worker Đọc F1–F6; trả 5 dòng; không sửa bảng cuối.
Privacy worker Đọc P1–P3; trả retention/export; không suy đoán.
Reviewer Read-only; flag claim thiếu evidence hoặc mâu thuẫn.
Owner Coordinator là người duy nhất sửa bản tổng hợp.
Budget 15 phút, tối đa một lượt sửa cho mỗi worker.
Failure route Thiếu nguồn thì ghi unknown, không bịa.
Stop rule Dừng khi còn hai claim chưa xác minh.

c. Tự kiểm topology

Hỏi ba câu: workers có đang làm trùng không; handoff có mang evidence không; ai quyết định khi hai kết quả mâu thuẫn? Nếu chưa trả lời được bằng một dòng, Team Card chưa đủ rõ.

Hình 3 — Team Card buộc hệ thống chốt quyền, ngân sách và đường lỗi trước khi chạy.

6. Tổng kết: chia đúng việc trước khi thêm người

a. Năm ý chính

  • Multi-Agent System là nhiều agent phối hợp bằng giao thức chung, không chỉ nhiều tên vai trò.
  • Orchestrator–worker hợp việc song song; handoff hợp luồng chuyển trạng thái; peer/reviewer cần quyền quyết định rõ.
  • Task contract phải ghi objective, input, output, tool, owner và done/stop rule.
  • Shared state có schema và một owner cho mỗi artifact giúp tránh mất context, write conflict.
  • Chỉ thêm agent khi single-agent baseline thiếu năng lực mà lợi ích đáng chi phí phối hợp.

b. Câu hỏi tự kiểm tra

  • Vì sao ba prompt có tên vai trò chưa chắc là một multi-agent system?
  • Orchestrator khác worker ở đâu?
  • Vì sao shared artifact cần một owner ghi?
  • Khi nào nên giữ một agent?

c. Gợi ý đáp án

Xem gợi ý câu 1Cần thêm giao thức phối hợp, input/output, quyền, state và người chịu trách nhiệm kết quả. → Xem mục 1.
Xem gợi ý câu 2Orchestrator chia, theo dõi và tổng hợp; worker làm subtask có biên rồi trả result. → Xem mục 2.
Xem gợi ý câu 3Một owner tránh hai agent ghi đè hoặc làm mất thay đổi của nhau. → Xem mục 3.
Xem gợi ý câu 4Khi task nhỏ, phụ thuộc chặt, cần cùng context hoặc baseline một agent đã đạt yêu cầu. → Xem mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Multi-Agent System Nhiều agent phối hợp để đạt mục tiêu chung.
Agent Vòng model, context, tool và hành động có biên.
Orchestrator Agent chia việc, theo dõi và tổng hợp.
Worker Agent xử lý một subtask theo contract.
Handoff Chuyển quyền xử lý kèm payload trạng thái.
Shared state Trạng thái chung có schema và owner.
Task contract Phiếu objective, input, output, quyền và stop.
Aggregation Ghép và xử lý xung đột giữa kết quả.
Write conflict Nhiều agent ghi cùng artifact gây đè dữ liệu.
Eval Bộ kiểm output và chất lượng phối hợp.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Prompt Routing #26 nếu chưa rõ cách chọn nhánh. Học tiếp Guardrails & Safety #28: đặt biên nào quanh model, tool, dữ liệu và hành động để một lỗi không lan khắp hệ thống?

Nhắc lại: Đây là nội dung giáo dục. Một đội agent chỉ đáng tin bằng contract, quyền, dữ liệu, validation và khả năng dừng của cả hệ thống.