Hệ thống multi-agent là một kiến trúc gồm nhiều mô hình ngôn ngữ lớn (LLM) hoạt động tự hành, sử dụng các công cụ trong một vòng lặp (loop) để cùng giải quyết các tác vụ phức tạp.
Thay vì dựa vào một thực thể duy nhất, multi-agent phân rã bài toán thành các phần nhỏ hơn để chuyên môn hóa hoặc xử lý song song.
Nghe có vẻ gọn, nhưng multi-agent không sửa giúp bạn một hệ thống vốn đã hỏng, và nó cũng không phải nấc nâng cấp mặc định khi agent đơn của bạn chạy chậm; đây là một quyết định kiến trúc, và nó có hóa đơn đi kèm.
Bạn đang hy sinh sự đơn giản và chấp nhận chi phí token cực cao để đổi lấy khả năng mở rộng hiệu suất (scaling) mà một agent đơn lẻ không thể đạt tới.
Multi-agent là gì và khi nào bạn cần đến nó?
Multi-agent là hệ thống các mô hình ngôn ngữ lớn (Large Language Model, LLM) vận hành tự hành, có khả năng gọi công cụ và phối hợp để đạt được mục tiêu chung.
Dưới góc độ kỹ sư, lý do thực sự để bạn triển khai multi-agent là khả năng mở rộng token (token scaling). Trong bài thử nghiệm BrowseComp, riêng lượng token tiêu thụ đã giải thích tới 80% khác biệt về hiệu suất giữa các agent. Trên bộ đánh giá nghiên cứu nội bộ của Anthropic, một hệ multi-agent dùng Claude Opus 4 làm agent điều phối (lead) và các subagent (agent con) Claude Sonnet 4 đã vượt agent đơn lẻ Claude Opus 4 tới 90,2% nhờ khả năng tiêu thụ nhiều token hơn để suy luận sâu. Thậm chí, việc nâng cấp lên Claude Sonnet 4 mang lại hiệu quả cao hơn cả việc gấp đôi ngân sách token cho bản Claude Sonnet 3.7.
Tôi đọc con số 90,2% đó như một phép đo ngân sách token hơn là một phép đo trí thông minh. Nhiều agent nghĩa là nhiều cửa sổ ngữ cảnh, mà nhiều cửa sổ ngữ cảnh nghĩa là nhiều lượt suy luận hơn cho cùng một câu hỏi, và nếu bài toán của bạn không cần thêm lượt suy luận nào, kiến trúc này chẳng có gì để bán cho bạn cả.
Bạn chỉ nên dựng hệ multi-agent khi:
- Tìm kiếm bề ngang (breadth-first): Cần theo đuổi nhiều hướng nghiên cứu độc lập cùng lúc.
- Vượt ngưỡng cửa sổ ngữ cảnh: Khi lượng dữ liệu đầu vào và kết quả trung gian vượt quá giới hạn của một lần gọi model (ví dụ: nghiên cứu hàng trăm tài liệu).
- Chuyên môn hóa công cụ: Khi cần tương tác với hàng chục công cụ khác nhau mà một prompt duy nhất không thể quản lý hiệu quả.
Vì sao chia sẻ ngữ cảnh là phần khó nhất?
Trong môi trường sản xuất, nhiệm vụ số 1 của bạn không phải là prompt engineering mà là kỹ thuật ngữ cảnh (context engineering): thiết kế đường đi của dữ liệu giữa các agent sao cho vừa tự động vừa chính xác.
Sự chia sẻ ngữ cảnh mong manh hơn bạn tưởng nhiều. Hãy nhìn vào ví dụ kinh điển "Flappy Bird và Mario": nếu bạn chia task "lập trình Flappy Bird" cho hai subagent, một agent có thể tạo nền theo phong cách Mario trong khi agent kia tạo con chim theo phong cách hiện thực. Hệ thống sụp đổ vì "hành động luôn mang theo các quyết định ngầm định" (actions carry implicit decisions). Không agent nào làm sai phần việc của mình cả, nhưng khi các giả định ngầm định này xung đột và không được mô tả rõ trong prompt, kết quả cuối cùng vẫn không thể khớp nối.
Hai vấn đề kỹ thuật sẽ cắn bạn trước tiên. Một là đổ ngữ cảnh (context dumping): việc quăng toàn bộ lịch sử chat vào mỗi lượt khiến chi phí token tăng tuyến tính, và đống lịch sử đó gây nhiễu cho các agent nhận việc sau. Hai là lỗi cộng dồn (compounding errors), và đây mới là thứ khó chữa: 36,9% thất bại của hệ multi-agent đến từ việc mất đồng bộ giữa các agent (misalignment). Một sai lệch nhỏ ở agent đầu tiên sẽ trở thành "sự thật" cho các agent sau, nên toàn bộ pipeline sụp đổ ở những bước cuối cùng, đúng vào lúc bạn đã đốt gần hết token cho lượt chạy đó.
Khi bàn giao, agent nhận việc thực sự nhận được gì?
Cơ chế "bàn giao" (handoff) là việc sử dụng công cụ để cập nhật biến trạng thái (như active_agent)
và chuyển giao quyền kiểm soát.
Trong LangChain và OpenAI Agents SDK, một handoff bắt buộc phải gồm cặp tin nhắn: AI Message (gọi
công cụ handoff) và Tool Message (xác nhận bàn giao). Nếu thiếu cặp này, lịch sử hội thoại sẽ bị
lỗi (malformed), khiến agent tiếp nhận bị bối rối. Trong kiến trúc đồ thị con (subgraph), bạn nên sử
dụng Command.PARENT để điều hướng.
Lưu ý quan trọng: Đừng bao giờ chuyển toàn bộ lịch sử subagent cho agent nhận việc. Bạn chỉ nên chuyển cặp tin nhắn handoff hoặc bản tóm tắt tinh gọn để giữ ngữ cảnh sạch, tránh làm loãng bộ não của agent tiếp theo. Chỗ này đau ở một điểm mà không tài liệu nào quyết hộ bạn được: bản tóm tắt bỏ đi cái gì là do bạn chọn, và mỗi thứ bạn bỏ đi đều có xác suất chính là thứ agent sau đang cần.
Bộ nhớ dùng chung hoạt động ra sao?
Để các agent không hoạt động chồng chéo, bạn cần thiết kế hạ tầng bộ nhớ bền vững. Ba mô hình dưới đây đều chạy được, chỉ là mỗi mô hình trả giá ở một chỗ khác nhau:
| Đặc điểm | Tập trung (Centralized) | Phân tán (Distributed) | Lai (Hybrid) |
|---|---|---|---|
| Cấu trúc | Một kho lưu trữ chung duy nhất | Mỗi agent có kho riêng, đồng bộ chọn lọc | Kết hợp kho riêng và tầng chia sẻ |
| Sự phối hợp | Đọc/ghi đơn giản vào một nguồn | Giao thức đồng bộ (sync) phức tạp | Truy cập phân tầng (User/Agent/App) |
| Tính nhất quán | Rất cao, single source of truth | Nhất quán cuối cùng (eventual) | Có thể cấu hình tùy use case |
| Agent Registry | Thường được gán cứng | Cần registry để khám phá nhau | Registry lưu metadata và khả năng (capabilities) |
Khái niệm cốt lõi là phân vùng bộ nhớ (memory scoping): bộ nhớ cần phân hóa theo bốn chiều là User, Agent, Session và App. Việc có thêm Agent Registry là bắt buộc để các agent tự tìm thấy nhau và hiểu khả năng của nhau mà không cần bạn phải gán cứng mọi đường nối. Bỏ qua bước này, demo vẫn chạy ngon, vì với ba agent, gán cứng hết cũng chẳng chết ai; nó chỉ sập khi agent thứ tư xuất hiện.
Truyền tin có cấu trúc giữa các agent
Khi kết nối các hệ thống agent độc lập hoặc từ bên thứ ba, giao thức A2A (Agent2Agent) là tiêu chuẩn. Cột trụ của nó là thực thi mờ đục (opaque execution): các agent phối hợp dựa trên khả năng được khai báo mà không cần quyền truy cập vào trạng thái nội bộ, bộ nhớ hay công cụ của nhau. Nhờ vậy, hai hệ thống của hai đội khác nhau làm việc được với nhau mà không đội nào phải mở ruột gan của mình ra.
Cấu trúc dữ liệu trong A2A:
- Task: Đơn vị công việc có định danh và vòng đời.
- Message: Các lượt hội thoại giao tiếp.
- Artifact: Kết quả đầu ra (tài liệu, code). Luôn trả kết quả qua Artifact, đừng dùng Message để tránh nhầm lẫn giữa thảo luận và sản phẩm.
Agent điều phối lọc ngữ cảnh như thế nào?
Trong mô hình lead researcher, lead agent là bộ não chiến lược. Nó vừa phân việc, vừa phải nén thông tin bằng một LLM riêng để tóm tắt lịch sử hành động.
Một chi tiết kỹ thuật sống còn: khi task kéo dài, lead agent phải lưu research plan (kế hoạch nghiên cứu) vào bộ nhớ ngoài. Nếu không, khi cửa sổ ngữ cảnh vượt quá 200.000 token và bị cắt (truncate), agent sẽ "quên" mục tiêu ban đầu, mà nó quên rất lịch sự: vẫn trả lời trôi chảy, chỉ là trả lời cho một câu hỏi khác. Ngoài ra, subagent nên dùng tư duy xen kẽ (interleaved thinking) để tự đánh giá kết quả từ công cụ trước khi gửi bản tóm tắt tinh gọn về cho lead.
Cái giá phải trả: token, độ trễ và lỗi dồn lại
Hóa đơn của kiến trúc này nằm ở ba chỗ, và cả ba đều đo được:
- Chi phí: Hệ multi-agent dùng lượng token gấp 15 lần so với chat thông thường.
- Độ trễ (latency): Việc thực thi tuần tự có thể biến một task từ vài phút thành vài giờ. Gọi công cụ song song giúp cắt tới 90% thời gian nghiên cứu với các truy vấn phức tạp, nhưng rủi ro lỗi dồn tích và mất đồng bộ tăng vọt.
- Tỷ lệ thất bại: 36,9% đến từ mất đồng bộ giữa các agent. Càng nhiều node trong đồ thị (graph), xác suất sụp đổ càng cao.
Đặt ba dòng đó cạnh nhau sẽ thấy rõ multi-agent chỉ hợp với những bài toán mà câu trả lời đáng giá hơn nhiều lần chi phí bỏ ra để tìm nó.
Khi nào không nên dựng hệ multi-agent?
Nguyên tắc mặc định của tôi: bắt đầu với một agent đơn luồng tuyến tính (single-threaded linear agent). Tránh dùng multi-agent cho các tác vụ có quá nhiều phụ thuộc chéo (cross-dependencies) hoặc yêu cầu sự nhất quán cực kỳ chi tiết. Coding là một ví dụ điển hình — việc chia nhỏ task coding cho nhiều agent thường lợi bất cập hại do yêu cầu tính đồng nhất của codebase quá cao.
Nếu bạn chưa giải quyết được bài toán memory engineering và context engineering cho một hệ thống chỉ có một agent, việc thêm agent vào chỉ nhân đúng những vấn đề đó lên, kèm theo hóa đơn token gấp 15 lần.
Tài liệu tham khảo
- How we built our multi-agent research system — Anthropic
- Don't Build Multi-Agents — Cognition
- When to use multi-agent systems (and when not to) — Anthropic
- A2A Protocol Specification
- Passing Context Between Agents in Multi-Agent A2A Systems — Microsoft ISE
- Handoffs — Docs by LangChain
- Handoffs — OpenAI Agents SDK
- How to Design Multi-Agent Memory Systems for Production — Mem0
- Why Do Multi-Agent LLM Systems Fail? — Cemri et al.