Đã đăng vào khoảng 11 giờ trước 18 phút đọc

Multi-Agent Pattern: Cách hoạt động và lựa chọn kiến trúc phù hợp

1. Multi-Agent Patterns là gì ?

Nếu bạn từng xây dựng một RAG chatbot, rất có thể bạn đã vô tình áp dụng một dạng multi-agent pattern đơn giản mà không nhận ra. Hãy tưởng tượng lại luồng RAG-chatbot quen thuộc:

Người dùng gửi câu hỏi → hệ thống chọn collection/vector store phù hợp → retrieve các đoạn context liên quan → LLM sinh ra câu trả lời.

Nếu bạn còn thêm một bước tóm tắt lịch sử hội thoại định kỳ (để lưu long-term memory giúp session tránh hiện tượng quên thông tin) , hoặc một bước kiểm tra tính chính xác trước khi trả lời, thì bạn đang có nhiều thành phần chuyên trách khác nhau, mỗi thành phần nhận input từ bước trước và truyền output cho bước sau. Đó chính là bản chất cốt lõi của multi-agent pattern: phân công công việc, chuyên môn hóa và phối hợp có hệ thống giữa nhiều “tác nhân” để hoàn thành một nhiệm vụ phức tạp. Tuy nhiên, trước khi đi sâu vào các pattern cụ thể, chúng ta cần làm rõ một điểm quan trọng để tránh nhầm lẫn:

Phân biệt Multi-Agent Pattern với Multi-Agent System:

Multi-Agent System (MAS - Hệ thống đa tác nhân) là một kiến trúc AI gồm nhiều AI Agent (tác nhân thông minh) cùng làm việc, tương tác và phối hợp để giải quyết nhiệm vụ phức tạp mà một agent đơn lẻ không làm tốt hoặc không đủ khả năng. Mỗi agent thường:
- Có vai trò chuyên biệt (researcher, writer, reviewer, planner, executor…).
- Được điều khiển bởi LLM (như GPT, Claude, Grok…).
- Có khả năng tự lập kế hoạch, sử dụng tool, ghi nhớ, và giao tiếp với agent khác.
Cách hoạt động:
- Phân tích nhiệm vụ lớn → chia nhỏ thành sub-task.
- Các agent hợp tác (sequential, parallel, hierarchical, hoặc decentralized).
- Thường có orchestration layer (lớp điều phối) để quản lý.
Toàn bộ hệ sinh thái, bao gồm nhiều lớp: orchestration, memory (ngắn hạn, dài hạn, bộ nhớ chung), communication (cách các agent nói chuyện với nhau), trust & validation (ai kiểm tra ai), deployment và monitoring.
Multi-Agent Pattern (MAP) là các mẫu thiết kế kiến trúc dùng để tổ chức và phối hợp nhiều AI Agent (tác nhân thông minh dựa trên LLM) làm việc cùng nhau, nhằm giải quyết các nhiệm vụ phức tạp mà một agent đơn lẻ khó xử lý hiệu quả.

Nói đơn giản:

Nếu Multi-Agent System là “đội ngũ nhiều chuyên gia AI”, thì Multi-Agent Pattern chính là những “cách sắp xếp đội ngũ” (cách giao tiếp, điều phối, phân công nhiệm vụ) để đội ngũ đó hoạt động hiệu quả, có kiểm soát và đáng tin cậy. Do đó MAP sẽ tập trung trả lời một câu hỏi hẹp và quan trọng hơn: “Chúng ta nên tổ chức và phối hợp các agent theo cấu trúc nào để giải quyết hiệu quả nhất một loại nhiệm vụ?”

Đây thường là quyết định đầu tiên và có ảnh hưởng lớn nhất khi thiết kế hệ thống. Pattern bạn chọn sẽ quyết định độ phức tạp, chi phí chạy, khả năng debug, độ tin cậy và cách triển khai tất cả các lớp còn lại.

“Multi-agent không phải là một pattern duy nhất — từ pipeline đơn giản như RAG cho đến các hệ thống decentralized phức tạp. Và chính sự đa dạng này khiến việc chọn pattern trở thành một quyết định quan trọng ngay từ đầu khi xây dựng các hệ thống multi-agent.”

Trong bài viết này, mình sẽ giới thiệu những multi-agent pattern phổ biến nhất hiện nay, ưu nhược điểm của từng loại, và cách chọn pattern phù hợp cho dự án của bạn.

2. Mô hình tư duy: 3 chiều để lựa chọn Multi-Agent Pattern phù hợp

Trước hết mình sẽ list ra 3 pattern cơ bản phổ biến là: Swarm, Graph, Workflow ( bạn nào thích tìm đọc hiểu kĩ hơn về Swarm có thể đọc bài viết về Kimi K2.5 mình đã viết ở blog trước ). Để các bạn hình dung về Multi-Agent Pattern dễ hơn mình sẽ minh họa nó dưới mô hình tư duy bên dưới:

Giải thích 3 chiều:

Trục dọc (Y): Ai quyết định bước tiếp theo?
- Đỉnh trên: AI/agent tự quyết định (Swarm sẽ có quyền tự quyết hơn hơn so với Graph và Workflow).
- Đỉnh dưới: Developer/Con người tự quyết định thông qua flow (Workflow thiên về Developer control nhiều hơn Swarm).
Trục ngang (X): Độ phức tạp và tính động của nhiệm vụ/bài toán.
- Bên trái: Nhiệm vụ đơn giản, lặp lại, có thể dự đoán trước.
- Bên phải: Nhiệm vụ phức tạp, có nhiều nhánh điều kiện, cần adaptive.
Chiều sâu (Context Sharing): Các agent biết gì về nhau và chia sẻ context ra sao?
- Swarm: Thường dùng full transcript hoặc group chat → token cost cao, debug khó.
- Workflow: Context được tổ chức chặt chẽ, chỉ truyền những gì cần thiết → tiết kiệm token, dễ debug.
- Graph/Hierarchical: Dùng shared state hoặc memory graph, developer định nghĩa rõ edge và data flow.

Hầu hết các bài viết so sánh multi-agent pattern hiện nay chỉ dừng lại ở hai câu hỏi: Ai kiểm soát luồng thực thi? và Nhiệm vụ phức tạp đến mức nào? (Trục X và Trục Y). Tuy nhiên, khi build hệ thống thực tế ở môi trường production, còn có một chiều thứ ba cực kỳ quan trọng nhưng thường bị bỏ qua:

Context được chia sẻ giữa các agent như thế nào (Chiều sâu )? Chiều này ảnh hưởng trực tiếp đến chi phí token, khả năng debug, độ ổn định và cách hệ thống xử lý khi fail.

Tóm lại, mỗi multi-agent pattern thực chất đang trả lời cùng lúc ba câu hỏi cốt lõi:

Ai quyết định bước tiếp theo? (AI hay Developer?) Các agent được tổ chức theo topology nào? (Linear, Graph, Mesh…) Chúng được phép biết gì về nhau và chia sẻ context như thế nào?

Khi bạn nắm vững mô hình tư duy 3 chiều này, bạn sẽ không còn chọn pattern dựa vào “framework nào dễ dùng" như CrewAI / LangGraph / AutoGen, mà sẽ chọn dựa trên đặc thù thực tế của bài toán, ngân sách và yêu cầu vận hành.

3. Các Multi-Agent Pattern phổ biến

Dưới đây là các pattern được sử dụng rộng rãi trong CrewAI, LangGraph, AutoGen, Strand Agent SDK, Azure AI, Google ADK…:

Sequential Pattern (Pipeline / Assembly Line / Linear Workflow ) _{Nguồn ảnh: Sequential Pattern}
- Các agent chạy tuần tự, output của agent trước làm input cho agent sau. Ví dụ: Researcher → Writer → Reviewer → Editor.
- Ưu điểm: Dễ kiểm soát, deterministic, debug dễ.
- Nhược điểm: Không tận dụng parallel, chậm với task lớn.
- Phù hợp: Workflow rõ ràng, có thứ tự cố định (viết báo cáo, xử lý dữ liệu, content pipeline).
Parallel Pattern (Fan-Out Fan-In / Map-Reduce / Concurrent)
- Nhiều agent chạy song song trên các sub-task độc lập, sau đó tổng hợp kết quả. Ví dụ: 3 agent nghiên cứu 3 nguồn dữ liệu khác nhau → Aggregator tổng hợp.
- Ưu điểm: Nhanh, bao quát nhiều góc nhìn.
- Nhược điểm: Cần cơ chế resolve conflict.
- Phù hợp: Research đa nguồn, phân tích dữ liệu, đánh giá rủi ro.
Hierarchical / Supervisor Pattern (Manager-Worker / Orchestrator-Worker)
- Có một Supervisor/Orchestrator Agent trung tâm phân tích nhiệm vụ, phân công cho các Worker Agent chuyên biệt, theo dõi tiến độ và tổng hợp kết quả. Đây vẫn là pattern phổ biến nhất trong enterprise.
- Ưu điểm: Kiểm soát tốt, dễ debug, linh hoạt.
- Nhược điểm: Supervisor dễ thành bottleneck.
- Phù hợp: Hầu hết ứng dụng phức tạp (customer support, report generation, software engineering agent).
Swarm Pattern (Decentralized / Peer-to-Peer / Group Chat / Emergent)
- Các agent bình đẳng, tự giao tiếp, đàm phán và handoff nhiệm vụ cho nhau mà không cần (hoặc cần rất ít sự can thiệp) của Orchestrator Agent. Ví dụ: AutoGen GroupChat hoặc Strands Swarm (agent dùng tool handoff_to_agent).
- Ưu điểm: Linh hoạt cao, sáng tạo, thích ứng tốt.
- Nhược điểm: Khó kiểm soát, dễ lặp vòng, debug khó, token cost cao.
- Phù hợp: Brainstorm, research khám phá, ý tưởng sáng tạo.
Graph Pattern (hay Agent Graph / Stateful Graph)
- Đây là phiên bản linh hoạt hơn của Sequential Pattern.
- Developer định nghĩa các node (agent) và edges (đường chuyển).
- Tại mỗi node, LLM/agent quyết định đường đi tại mỗi node (conditional branching), có cơ chế cycles/vòng lặp.
- Context thường chia sẻ qua shared state/dict.
- Đây là pattern hybrid, kết hợp được nhiều đặc tính của Sequential, Parallel, Adaptive và Hierarchical.
- Phù hợp: Workflow có điều kiện, cần feedback loop, iterative refinement (ví dụ: planning → execute → critique → revise).
Thực sự còn rất nhiều loại mình không list ra hết được như Loop pattern, Review and critique pattern , Review and critique pattern , Reason and act (ReAct) pattern , Human-in-the-loop pattern ,... mình sẽ để link ở phầm tham khảo cho các bạn muốn tìm hiểu thêm .

4. Cơ chế hoạt động của các Pattern

Vì mình thấy 3 Pattern : Sequential Pattern, Graph Pattern , Swarm Pattern là 3 cái hay dùng và có vẻ dễ tiếp cận với các bài toán hiện nay nhất nên phần trình bày cơ chế hoạt động mình sẽ chỉ trình bày của 3 Pattern này:

4. 1 Sequential Pattern (Workflow Pattern) - predictable, cheap, và dễ audit

Sequential có thể nói là pattern đơn giản nhất trong 3 pattern: bạn define một chuỗi steps có thứ tự, execute tuần tự từng bước, output của bước trước tự động thành input của bước sau. Không có conditional, không có cycle, không có AI quyết định "bước tiếp theo là gì".

Điểm cốt lõi của Sequential là ở cột phải — curated context. Mỗi agent chỉ nhận output của bước liền trước, không phải toàn bộ history. Writer ở step 3 không biết gì về những gì Extractor làm ở step 1 — trừ khi Analyzer ở step 2 chủ động truyền lại thông tin đó.

Đây vừa là điểm mạnh vừa là điểm yếu:

Điểm mạnh — token cost thấp nhất trong 3 pattern vì context được trim tối đa. Pipeline 10 bước không bị "phình" context theo số bước như Swarm hay Graph.
Điểm yếu — schema drift âm thầm. Step 2 thay đổi output format do prompt update, step 3 nhận sai shape nhưng không throw error ngay — chỉ trả về fail ở output cuối. Do đó, sẽ luôn validate output schema tại mỗi step bằng structured output trước khi pass xuống bước tiếp theo.

Lưu ý về cycle: Sequential không hỗ trợ cycle. Không thể loop lại bước trước, không có retry logic tự động. Nếu task cần iterative refinement ("viết → review → sửa → review lại"), Sequential không phải lựa chọn đúng đắn.

Dùng khi:

Bạn cần audit trail rõ ràng — compliance, fintech, healthcare đều cần biết chính xác bước nào đã chạy.
Output cần reproducible — cùng input phải ra cùng output structure.
Bạn cần phải estimate runtime chính xác vì không có nhánh bất ngờ nên bạn biết trước hệ thống sẽ chạy đúng N bước, không hơn không kém.
Token budget quan trọng — Sequential là rẻ nhất vì context được trim về minimum.

Không dùng khi:

Task cần adapt giữa chừng dựa trên output của bước trước.
Bạn cần retry / iterative loop (dùng Graph với cycle).
Có nhiều task có thể chạy song song theo dependency (nên chọn Graph).
Agent cần biết toàn bộ lịch sử để ra quyết định đúng.

4.2 Graph Pattern - structured với conditional routing và parallel execution

Graph Pattern cho phép bạn define một directed graph của các agent nodes, với conditional edges và khả năng chạy parallel. Khác với Sequential chạy tuần tự cứng nhắc, Graph tự động unblock các node khi dependencies của chúng đã hoàn thành. Quan trọng hơn: Graph hỗ trợ cycle — bạn có thể tạo loop có chủ đích như retry, validation vòng lặp, hay iterative refinement.

Nhìn hình minh họa ở trên có thể thấy:

Khi Researcher xong → Legal và Financial chạy song song → Writer tổng hợp. Tất cả nodes đọc/ghi vào cùng một shared dict, nên Writer thấy full kết quả của cả 2. Cơ chế này gọi là share context: Graph dùng một shared dict object được pass vào tất cả agents. Bất kỳ agent nào cũng có thể đọc và ghi vào dict này. Toàn bộ conversation history là một key trong shared state — mọi agent đều có full context. Đây là điểm khác biệt lớn so với Sequential do đó, Graph tốn nhiều token hơn nhưng agent có thể reason dựa trên toàn bộ lịch sử.
Conditional + cycle — Writer xong, nếu chưa approved thì loop ngược lên Researcher với feedback, nếu approved thì kết thúc- Đây là intentional cycle.

Code demo:

Hơn nữa Graph Pattern còn có cơ chế Behavior control : Input của user tại mỗi bước có thể trực tiếp ảnh hưởng đến path mà graph đi theo. Một LLM node có thể quyết định đi sang edge nào dựa trên kết quả của node trước — đây là "controlled but dynamic" theo đúng nghĩa. Bạn define tất cả possible paths, AI quyết định đi path nào.

Code demo:

Dùng Graph Pattern khi:
- Có dependency rõ ràng giữa các agent nhưng một số phần có thể chạy song song.
- Cần conditional routing — node A xong, tùy kết quả mà đi sang node B hoặc node C.
- Task cần iterative loop — ví dụ: generate → validate → nếu fail thì quay lại generate.
- Cần explicit error handling với fallback path rõ ràng.
Không dùng khi:
- Bạn muốn AI tự quyết định cả graph structure lúc runtime (đó là Swarm Pattern).
- Task đơn giản, không có parallelism hay conditional — overhead không đáng.

4.3 Swarm Pattern - emergent intelligence, non-deterministic

Có thể nói Swarm Pattern là kiến trúc phi tập trung nhất: không có orchestrator, không có flow định sẵn. Mỗi agent được trang bị một handoff_to_agent tool và có access vào shared context chứa toàn bộ lịch sử. Agent tự đọc context, tự quyết định làm gì tiếp, và tự quyết định handoff sang ai khi cần chuyên môn khác.

Cơ chế context: Swarm dùng shared transcript được inject vào system prompt của mỗi agent, chứa: task gốc, lịch sử handoff, knowledge đóng góp bởi agent trước, và danh sách agent khả dụng. Đây là pattern tốn token nhất — context tăng theo mỗi handoff và được pass vào từng agent call. Nhưng đổi lại, agent có thể reason dựa trên bức tranh toàn cảnh của context.

Dùng Swarm Pattern khi:
- Task mơ hồ hoặc open-ended — bạn không biết trước cần bao nhiêu bước hay chuyên môn gì.
- Cần emergent reasoning — task benefit từ việc nhiều agent có chuyên môn khác nhau tự coordinate.
- Agent có thể question và refine lẫn nhau qua shared context.
Không dùng khi:
- Bạn cần reproducibility — cùng input có thể ra flow hoàn toàn khác nhau.
- Có compliance requirement — audit trail của Swarm rất khó đọc.
- Task có Service Level Agreement (SLA) cứng — runtime dao động lớn, khó estimate.
- Token budget quan trọng — shared transcript tăng cost đáng kể theo số handoff.

5. Tham Khảo

LargeLanguageModels AgenticAi