Single-agent hay multi-agent: 5 câu hỏi trước khi thêm agent thứ hai

Nên dùng single-agent hay multi-agent?

Trả lời ngắn: Hãy bắt đầu bằng single-agent — một agent có mục tiêu, instructions và bộ tool rõ ràng. Chỉ chuyển sang multi-agent (hệ thống nhiều agent phối hợp) khi công việc có thể tách thành các nhánh tương đối độc lập, mỗi nhánh cần ngữ cảnh hoặc chuyên môn riêng, và lợi ích đo được đủ bù cho chi phí phối hợp, độ trễ và rủi ro mới.

Nhiều agent không mặc nhiên thông minh hơn một agent. Kiến trúc tốt là kiến trúc đơn giản nhất vẫn hoàn thành công việc trong giới hạn chất lượng, chi phí và kiểm soát đã đặt ra.

Hình 1. Single-agent giữ một vòng lặp tập trung; multi-agent thêm lớp phân công, handoff và tổng hợp.

Ngày rà soát nội dung: 06/09/2026. Đây là khung thực hành, không phải tiêu chuẩn ngành hoặc cam kết rằng một kiến trúc cụ thể sẽ tốt hơn trong mọi tình huống. Nếu phát hiện điểm cần sửa, vui lòng gửi qua trang Liên hệ.

Single-agent và multi-agent khác nhau ở đâu?

Single-agent là một agent giữ trách nhiệm xuyên suốt một vòng công việc: nhận mục tiêu, chọn tool, quan sát kết quả, điều chỉnh và trả đầu ra. Nó có thể dùng nhiều tool mà vẫn là một agent.

Multi-agent phân phối công việc cho nhiều agent có vai trò hoặc context (ngữ cảnh làm việc) khác nhau. Một agent có thể điều phối các agent chuyên trách, hoặc các agent có thể handoff quyền xử lý cho nhau.

OpenAI phân biệt hai mẫu orchestration: manager pattern, trong đó một agent trung tâm gọi các agent chuyên trách như tool; và decentralized pattern, trong đó agent handoff quyền thực thi cho agent khác. Hướng dẫn này cũng khuyên tăng dần độ phức tạp thay vì chuyển sang multi-agent quá sớm.

Năm câu hỏi trước khi thêm agent thứ hai

Hình 2. Năm câu hỏi kiểm tra xem độ phức tạp bổ sung có thực sự cần thiết hay không.

1. Công việc có các nhánh thực sự độc lập không?

Multi-agent có lợi thế rõ nhất khi nhiều nhánh có thể chạy song song mà không phải chờ nhau liên tục.

Ví dụ, khi nghiên cứu một ngành, ba nhánh “quy định”, “đối thủ” và “hành vi khách hàng” có thể tìm nguồn độc lập rồi trả về cho một coordinator tổng hợp. Ngược lại, nếu bước sau luôn cần toàn bộ kết quả của bước trước, việc tách agent có thể chỉ biến một chuỗi tuần tự thành nhiều handoff.

Anthropic mô tả hệ thống Research của họ dùng mô hình orchestrator–worker cho các truy vấn cần mở rộng theo nhiều hướng độc lập. Cùng bài viết đó lưu ý những công việc có nhiều phụ thuộc hoặc cần mọi agent chia sẻ cùng một context có thể không phù hợp.

Bài kiểm tra: Vẽ các nhánh công việc. Nếu không thể chạy ít nhất hai nhánh mà không trao đổi liên tục, hãy thử giữ single-agent.

2. Mỗi nhánh có cần context hoặc tool riêng không?

Tách agent hợp lý khi mỗi vai trò cần một phần context khác biệt và một bộ tool hẹp:

• agent nghiên cứu chỉ đọc nguồn và ghi evidence;
• agent phân tích dữ liệu chỉ truy cập dataset đã duyệt;
• agent biên tập chỉ nhận evidence packet và voice guide;
• coordinator chỉ nhận artifact cần thiết để tổng hợp.

Cách tách này có thể giảm nhiễu context và giới hạn quyền truy cập. Nhưng nếu các agent đều nhận cùng prompt, cùng dữ liệu và cùng tool, bạn có thể đang nhân bản một agent thay vì tạo chuyên môn thực sự.

Bài kiểm tra: Viết một dòng “vai trò — input — tool — output” cho từng agent. Nếu các dòng gần như giống nhau, chưa có lý do tốt để tách.

3. Có một owner chịu trách nhiệm tổng hợp không?

Nhiều đầu ra không tự biến thành một quyết định nhất quán. Cần một synthesis owner — agent hoặc người — chịu trách nhiệm:

• phát hiện kết quả mâu thuẫn;
• yêu cầu bổ sung khi một nhánh thiếu evidence;
• loại bỏ phần trùng lặp;
• giữ thuật ngữ và giả định nhất quán;
• quyết định khi nào đủ để dừng;
• trình bày phần chưa chắc chắn thay vì che giấu.

Nếu mỗi agent tự nói trực tiếp với người dùng mà không có quy tắc handoff, người dùng có thể phải làm coordinator thủ công.

Bài kiểm tra: Chỉ vào đúng một thành phần có quyền chấp nhận, yêu cầu làm lại hoặc loại bỏ đầu ra. Nếu chưa chỉ được, kiến trúc chưa sẵn sàng.

4. Handoff có giữ được bằng chứng và trạng thái không?

Mỗi lần handoff có thể làm mất chi tiết. Một câu “agent A đã nghiên cứu xong” không cho agent B biết nguồn nào đã dùng, điều gì còn thiếu hay giả định nào đang mở.

Hình 3. Handoff tốt chuyển artifact có cấu trúc, không chỉ chuyển một bản tóm tắt mơ hồ.

Một handoff tối thiểu nên có:

1. Objective: kết quả cần tạo và quyết định mà kết quả phục vụ.
2. Scope: phần được làm, phần bị loại trừ và giới hạn quyền.
3. Inputs: dữ liệu, nguồn và phiên bản được phép dùng.
4. Output contract: định dạng, trường bắt buộc và mức chi tiết.
5. Evidence: nguồn, log hoặc phép tính cần giữ lại.
6. Unknowns: khoảng trống, xung đột và giả định chưa xác minh.
7. Stop condition: điều kiện hoàn thành, dừng hoặc chuyển người.

Với artifact lớn, có thể lưu nó ở nơi dùng chung rồi chuyển reference (tham chiếu) thay vì nén toàn bộ qua nhiều lớp tóm tắt. Quan trọng là người tổng hợp có thể truy ngược từ kết luận đến evidence.

5. Bạn sẽ chứng minh multi-agent tốt hơn bằng cách nào?

Đừng chọn kiến trúc chỉ vì demo trông ấn tượng. Hãy so sánh trên một bộ tác vụ đại diện, với cùng tiêu chí:

• tỷ lệ hoàn thành đúng yêu cầu;
• lỗi nghiêm trọng và lỗi handoff;
• phần evidence bị mất hoặc gắn sai;
• thời gian đến kết quả có thể dùng;
• số lần tool call, token hoặc chi phí;
• tỷ lệ cần người sửa;
• độ ổn định khi đổi dữ liệu, prompt, model hoặc tool.

Multi-agent có thể tăng khả năng mở rộng tìm kiếm, nhưng cũng thêm chi phí và bề mặt lỗi. Kết quả nội bộ của một nhà cung cấp trên một benchmark không phải bảo đảm cho workflow của bạn. Hãy dùng benchmark riêng và giữ ngôn ngữ kết luận trong phạm vi đã thử.

Anthropic khuyến nghị đánh giá agent bằng nhiều lớp phù hợp với tác vụ, gồm kiểm tra deterministic khi có thể, model grader khi cần và human grader có chọn lọc. Với multi-agent, cần chấm cả chất lượng đầu ra cuối lẫn hành vi phối hợp tạo ra đầu ra đó.

Để so sánh hai phương án trên cùng điều kiện, dùng bộ 12 test case, scorecard 100 điểm và run log, rồi bổ sung failure mode phối hợp riêng cho phương án multi-agent.

Trước câu hỏi một hay nhiều agent, hãy xác nhận bài toán có cần agent bằng 5 cửa chọn Prompt, Workflow hay AI agent.

Cây quyết định đơn giản

Đi theo thứ tự sau:

1. Một prompt hoặc workflow cố định có đủ không? Nếu có, chưa cần agent.
2. Một agent với instructions và tool rõ có đủ không? Nếu có, giữ single-agent.
3. Agent đang thất bại vì tool hoặc instructions quá mơ hồ? Sửa interface và đánh giá lại trước khi tách.
4. Có nhánh độc lập, context/tool riêng và giá trị của xử lý song song không? Nếu không, chưa nên dùng multi-agent.
5. Có coordinator, output contract, stop condition và eval không? Nếu thiếu một phần, hãy thiết kế chúng trước.
6. Thử nghiệm có cho thấy lợi ích vượt chi phí và lỗi mới không? Chỉ khi có bằng chứng, mới mở rộng.

Nguyên tắc “đơn giản nhất có thể” cũng xuất hiện trong hướng dẫn Building Effective AI Agents của Anthropic: agentic system thường đổi thêm latency và cost để lấy hiệu quả ở tác vụ phù hợp, vì vậy chỉ nên tăng độ phức tạp khi cần.

Ví dụ: nghiên cứu nhanh cho một đề xuất tư vấn

Giả sử bạn cần chuẩn bị một memo về việc một doanh nghiệp nhỏ có nên mở dịch vụ mới.

Phương án single-agent

Một agent:

1. đọc brief;
2. tìm nguồn theo ba nhóm câu hỏi;
3. ghi evidence ledger;
4. so sánh phương án;
5. tạo memo nháp.

Phương án này phù hợp khi phạm vi hẹp, nguồn ít, thời hạn ngắn và một context đủ chứa phần cần thiết.

Phương án multi-agent

• Coordinator: chia câu hỏi, khóa tiêu chí nguồn và hợp nhất kết quả.
• Market agent: thu thập tín hiệu về nhu cầu và lựa chọn thay thế.
• Operations agent: kiểm tra phụ thuộc, năng lực và rủi ro triển khai.
• Evidence auditor: kiểm tra source-to-claim và điểm chưa biết.

Multi-agent chỉ đáng thử nếu ba nhánh có thể làm độc lập, mỗi nhánh có output contract, và coordinator không phải đọc lại mọi thứ từ đầu. Nếu các agent liên tục cần cùng một file hoặc sửa chung một bảng, lợi ích song song có thể biến thành xung đột trạng thái.

Những lỗi thường gặp

Tách theo chức danh thay vì theo phụ thuộc

Đặt tên “researcher”, “critic”, “writer” chưa đủ. Hãy chứng minh mỗi vai trò có input, decision right và output khác nhau.

Nhiều agent cùng làm một việc mà không có mục đích

Tạo ba câu trả lời rồi chọn câu “hay nhất” có thể hữu ích trong một eval cụ thể, nhưng cũng có thể chỉ tăng chi phí. Phải xác định diversity (độ đa dạng) nào cần tạo và cách chấm.

Coordinator trở thành nút thắt cổ chai

Nếu mọi chi tiết đều quay về coordinator, context của nó vẫn có thể quá tải. Hãy chuyển artifact có cấu trúc, giới hạn phần trả về và quy định điều kiện “đủ”.

Không kiểm tra lỗi phối hợp

Một agent có thể hoàn thành phần việc riêng nhưng toàn hệ thống vẫn sai vì hai agent dùng phiên bản dữ liệu khác nhau, một nhánh bị bỏ sót hoặc kết luận bị gắn nhầm nguồn.

Không có giới hạn mở rộng

Đặt giới hạn số agent, số vòng giao việc, thời gian, tool call và ngân sách. Khi chạm ngưỡng, hệ thống phải dừng hoặc handoff cho người thay vì tiếp tục sinh thêm agent.

Câu hỏi thường gặp

Multi-agent có luôn chính xác hơn single-agent không?

Không. Kết quả phụ thuộc vào tác vụ, model, context, tool, cách phân công, cách tổng hợp và eval. Multi-agent còn tạo thêm lỗi phối hợp mà single-agent không có.

Một agent dùng nhiều tool có phải multi-agent không?

Không. Số tool không quyết định số agent. Nếu một vòng điều khiển duy nhất giữ mục tiêu và chọn các tool, đó vẫn là single-agent.

Khi nào manager pattern phù hợp?

Khi cần một điểm tiếp xúc thống nhất, một agent giữ context chung và các agent chuyên trách hoạt động như tool. Coordinator phải có tiêu chí giao việc và tổng hợp rõ.

Khi nào handoff giữa các agent phù hợp?

Khi một agent khác cần tiếp quản workflow hoặc tương tác theo chuyên môn riêng. Cần ghi rõ phần context được chuyển, quyền hành động và cách quay lại hoặc chuyển người.

Nên có bao nhiêu agent?

Không có con số chung. Bắt đầu với số lượng ít nhất đủ để tách các nhánh có ý nghĩa. Thêm từng agent như một thay đổi có giả thuyết, chi phí và eval.

Bước tiếp theo: thử “một agent trước”

Chọn một workflow bạn đang cân nhắc. Viết hai bản thiết kế:

• Bản A: một agent, tool hẹp, output contract rõ;
• Bản B: một coordinator và tối đa hai agent chuyên trách.

Chạy cả hai trên cùng một bộ tình huống đại diện. So sánh chất lượng, lỗi handoff, thời gian, chi phí và phần người phải sửa. Nếu bản B không tạo ra lợi ích rõ trong phạm vi thử, hãy giữ bản A.

Kiến trúc tốt không phải kiến trúc có nhiều agent nhất. Đó là kiến trúc giúp người chịu trách nhiệm hiểu được hệ thống đã làm gì, dựa trên bằng chứng nào, và dừng nó ở đâu.