Agentic Design Patterns — 7 mẫu thiết kế AI Agent mà Developer cần biết

Posted on: 5/10/2026 10:18:42 AM

1. Tại sao Design Pattern quan trọng với AI Agent?

Phần lớn thất bại của hệ thống AI Agent trong production giai đoạn 2024–2026 không phải do chất lượng model kém, mà do kiến trúc sai. Bạn có thể dùng GPT-4o hay Claude Opus — nhưng nếu agent không biết khi nào cần suy luận, khi nào hành động, khi nào dừng lại, kết quả vẫn sẽ không đáng tin cậy.

Agentic Design Patterns là tập hợp các mẫu kiến trúc đã được kiểm chứng trong thực tế, giúp developer xây dựng AI Agent có khả năng: tự suy luận, tự đánh giá output, phối hợp nhiều agent, và biết khi nào cần con người can thiệp. Bài viết này phân tích 7 pattern cốt lõi mà mọi developer làm việc với AI cần nắm vững.

2. Tool Use — Nền tảng của mọi Agent

Tool Use là pattern cơ bản nhất và cũng là nền móng cho toàn bộ hệ thống agent. Không có Tool Use, agent chỉ là một LLM sinh text dựa trên xác suất — không thể truy vấn database, không thể gọi API, không thể thao tác với thế giới thực.

Cơ chế hoạt động: LLM nhận mô tả các tool khả dụng (JSON Schema), tự quyết định tool nào cần gọi, sinh ra tham số phù hợp, sau đó hệ thống thực thi tool và trả kết quả về cho LLM diễn giải.

graph LR
    A[Người dùng gửi câu hỏi] --> B[LLM phân tích intent]
    B --> C{Cần tool?}
    C -->|Có| D[Chọn tool + sinh tham số]
    D --> E[Thực thi tool]
    E --> F[Trả kết quả về LLM]
    F --> G[LLM diễn giải và trả lời]
    C -->|Không| G
    style A fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style D fill:#e94560,stroke:#fff,color:#fff
    style E fill:#16213e,stroke:#fff,color:#fff
    style G fill:#4CAF50,stroke:#fff,color:#fff

3. ReAct — Suy luận xen kẽ Hành động

ReAct là pattern phổ biến nhất cho các tác vụ phức tạp, nơi đường đi đến lời giải không được xác định trước. Agent liên tục xen kẽ giữa suy luận (Thought) và hành động (Action), quan sát kết quả (Observation), rồi tiếp tục vòng lặp cho đến khi hoàn thành.

graph TD
    A[Nhận yêu cầu] --> B[Thought: Suy luận bước tiếp]
    B --> C[Action: Thực thi hành động]
    C --> D[Observation: Quan sát kết quả]
    D --> E{Đã đủ thông tin?}
    E -->|Chưa| B
    E -->|Rồi| F[Trả lời cuối cùng]
    style A fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style B fill:#e94560,stroke:#fff,color:#fff
    style C fill:#16213e,stroke:#fff,color:#fff
    style D fill:#2c3e50,stroke:#fff,color:#fff
    style F fill:#4CAF50,stroke:#fff,color:#fff

Ví dụ thực tế: Một agent nghiên cứu nội dung nhận yêu cầu phân tích đối thủ cạnh tranh. Nó suy luận rằng cần tìm hiểu website đối thủ trước → hành động scrape trang web → quan sát kết quả → suy luận cần so sánh pricing → hành động thu thập dữ liệu giá → cứ thế tiếp tục đến khi đủ thông tin để trả lời.

4. Reflection — Agent tự phản biện

Reflection cho phép agent tự đánh giá output của chính mình trước khi trả về cho người dùng. Cấu trúc là một vòng lặp Sinh → Phê bình → Cải tiến: agent tạo bản nháp đầu tiên, tự đánh giá theo tiêu chí cụ thể, dùng đánh giá đó làm cơ sở để sửa đổi, và lặp lại cho đến khi đạt ngưỡng chất lượng.

graph TD
    A[Nhận task] --> B[Sinh output ban đầu]
    B --> C[Tự đánh giá theo tiêu chí]
    C --> D{Đạt ngưỡng?}
    D -->|Chưa| E[Sửa đổi dựa trên critique]
    E --> C
    D -->|Đạt| F[Trả output cuối cùng]
    style A fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style B fill:#e94560,stroke:#fff,color:#fff
    style C fill:#16213e,stroke:#fff,color:#fff
    style E fill:#2c3e50,stroke:#fff,color:#fff
    style F fill:#4CAF50,stroke:#fff,color:#fff

Khi nào dùng: Các tác vụ đòi hỏi độ chính xác cao — phân tích tài chính, tóm tắt pháp lý, security audit, sinh code. Reflection đặc biệt hiệu quả khi bạn có thể định nghĩa rõ ràng tiêu chí đánh giá (ví dụ: code phải pass test, bản dịch phải đúng thuật ngữ chuyên ngành).

Giới hạn: Chất lượng phụ thuộc hoàn toàn vào việc tiêu chí đánh giá có đủ cụ thể hay không. Tiêu chuẩn mơ hồ gây ra vòng lặp vô tận. Mỗi cycle nhân đôi lượng token tiêu thụ.

5. Planning — Phân rã tác vụ trước khi thực thi

Thay vì nhảy vào thực thi ngay, agent tạo một kế hoạch tường minh — chia mục tiêu phức tạp thành các bước con, xác định thứ tự phụ thuộc, rồi mới lần lượt thực hiện. Mỗi bước hoàn thành được đánh dấu và kết quả được truyền cho bước tiếp theo.

graph TD
    A[Mục tiêu phức tạp] --> B[LLM sinh kế hoạch]
    B --> C[Bước 1: Thu thập dữ liệu]
    C --> D[Bước 2: Chuẩn hóa]
    D --> E[Bước 3: Phân tích]
    E --> F[Bước 4: Tổng hợp báo cáo]
    F --> G[Kết quả cuối cùng]
    style A fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style B fill:#e94560,stroke:#fff,color:#fff
    style C fill:#16213e,stroke:#fff,color:#fff
    style D fill:#16213e,stroke:#fff,color:#fff
    style E fill:#16213e,stroke:#fff,color:#fff
    style F fill:#16213e,stroke:#fff,color:#fff
    style G fill:#4CAF50,stroke:#fff,color:#fff

Ví dụ: Tạo báo cáo quý tự động → Phân rã thành: truy vấn dữ liệu → chuẩn hóa → phân tích xu hướng → sinh tóm tắt → phát hiện anomaly. Mỗi bước là một LLM call riêng biệt với prompt chuyên biệt.

6. Multi-Agent Collaboration — Nhiều Agent chuyên biệt phối hợp

Nhiều agent chuyên biệt với vai trò riêng biệt hoạt động dưới sự điều phối của một orchestrator trung tâm. Mỗi agent chịu trách nhiệm một miền cụ thể: Researcher tìm kiếm thông tin, Analyst phân tích dữ liệu, Writer viết nội dung, Critic đánh giá chất lượng.

Pattern này sinh ra 4 topology chính khi scale lên production:

5a. Orchestrator-Worker

Một orchestrator trung tâm nhận task, phân rã thành subtask, giao cho worker chuyên biệt, và tổng hợp kết quả. Worker hoạt động stateless, không giao tiếp trực tiếp với nhau. Debug dễ dàng nhờ luồng điều khiển đơn nhất.

graph TD
    A[Task đầu vào] --> B[Orchestrator]
    B --> C[Worker: Research]
    B --> D[Worker: Analysis]
    B --> E[Worker: Writing]
    C --> F[Tổng hợp kết quả]
    D --> F
    E --> F
    F --> G[Output cuối cùng]
    style B fill:#e94560,stroke:#fff,color:#fff
    style C fill:#16213e,stroke:#fff,color:#fff
    style D fill:#16213e,stroke:#fff,color:#fff
    style E fill:#16213e,stroke:#fff,color:#fff
    style G fill:#4CAF50,stroke:#fff,color:#fff

5b. Swarm

Các agent hoạt động ngang hàng tự trị, không có điều phối trung tâm. Sự phối hợp nảy sinh từ các quy tắc cục bộ đơn giản. Scalability cao nhưng khó kiểm soát và cần điều kiện dừng tường minh (max iterations, quality threshold, timeout).

5c. Mesh

Các agent duy trì kết nối trực tiếp, rõ ràng với nhau. Phù hợp cho nhóm 3–8 agent cần feedback loop chặt chẽ (ví dụ: planning → coding → testing → review). Số kết nối tăng theo N(N-1)/2, nên không khả thi với hơn 8 agent.

5d. Hierarchical

Agent tổ chức theo cấu trúc cây nhiều tầng: manager cấp cao định hướng chiến lược → supervisor giữa xử lý chiến thuật → worker lá thực thi. Phù hợp cho hệ thống 20+ agent nhưng mỗi tầng thêm ít nhất 2 giây latency.

7. Sequential Workflows — Pipeline tuần tự

Dữ liệu chảy qua các giai đoạn tuần tự đã được xác định trước. Output của Stage N trở thành input của Stage N+1. Không có logic vòng lặp — luôn đi tiến về phía trước.

graph LR
    A[Input] --> B[Stage 1: Nghiên cứu]
    B --> C[Stage 2: Outline]
    C --> D[Stage 3: Viết nháp]
    D --> E[Stage 4: SEO Audit]
    E --> F[Stage 5: Format]
    style A fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style B fill:#e94560,stroke:#fff,color:#fff
    style C fill:#16213e,stroke:#fff,color:#fff
    style D fill:#2c3e50,stroke:#fff,color:#fff
    style E fill:#16213e,stroke:#fff,color:#fff
    style F fill:#4CAF50,stroke:#fff,color:#fff

Ưu điểm nổi bật:

• Dễ monitor nhất — mỗi stage có input/output contract rõ ràng
• Tạo checkpoint tự nhiên cho human review giữa các stage
• Có thể swap model khác nhau cho từng stage tùy yêu cầu
• Khi lỗi xảy ra, dễ cô lập và tìm nguyên nhân ngay tại stage đó

Giới hạn: Không hỗ trợ branching dựa trên kết quả trung gian. Nếu một stage fail, toàn bộ pipeline bị block. Không phù hợp cho tác vụ cần thích ứng linh hoạt theo ngữ cảnh.

8. Human-in-the-Loop — Con người trong vòng lặp

Agent tạm dừng tại các điểm quyết định quan trọng để chờ con người xem xét và phê duyệt trước khi tiếp tục. Điểm mấu chốt là đặt giám sát đúng chỗ: nơi sai sót tự động tốn kém hơn thời gian review của con người.

graph TD
    A[Agent nhận task] --> B[Xử lý tự động]
    B --> C{Quyết định quan trọng?}
    C -->|Có| D[Tạm dừng - chờ approval]
    D --> E[Con người review]
    E --> F{Phê duyệt?}
    F -->|Có| G[Tiếp tục xử lý]
    F -->|Không| H[Agent điều chỉnh]
    H --> B
    C -->|Không| G
    G --> I[Hoàn thành]
    style D fill:#e94560,stroke:#fff,color:#fff
    style E fill:#ff9800,stroke:#fff,color:#fff
    style I fill:#4CAF50,stroke:#fff,color:#fff

Khi nào bắt buộc cần:

• Quyết định liên quan đến tiền — giao dịch tài chính, thanh toán, đặt hàng
• Nội dung publish công khai — bài viết, social media, email marketing
• Giao tiếp với khách hàng — support tickets, email reply
• Lĩnh vực regulated — y tế, pháp lý, bảo hiểm, tài chính

9. Kết hợp Pattern trong Production

Trong thực tế, không hệ thống nào chỉ dùng một pattern duy nhất. Sức mạnh thực sự nằm ở cách layer nhiều pattern lên nhau để tạo thành pipeline hoàn chỉnh:

Ví dụ 1: Content Production Pipeline

graph LR
    A[Tool Use + ReAct
Nghiên cứu thích ứng] --> B[Planning
Lập outline]
    B --> C[Sequential
Viết từng section]
    C --> D[Reflection
Self-critique chất lượng]
    D --> E[Human-in-the-Loop
Phê duyệt publish]
    style A fill:#e94560,stroke:#fff,color:#fff
    style B fill:#16213e,stroke:#fff,color:#fff
    style C fill:#2c3e50,stroke:#fff,color:#fff
    style D fill:#16213e,stroke:#fff,color:#fff
    style E fill:#ff9800,stroke:#fff,color:#fff

Ví dụ 2: Customer Service Automation

Tool Use + ReAct (chẩn đoán vấn đề) → Planning (xác định giải pháp) → Human-in-the-Loop (escalation khi vượt ngưỡng giá trị) → Sequential (thực thi giải pháp theo quy trình chuẩn).

Ví dụ 3: Multi-Agent Code Review

Orchestrator-Worker (phân chia file cho reviewer) → mỗi worker dùng ReAct (phân tích code) + Reflection (tự review findings) → Mesh (các reviewer thảo luận cross-file issues) → Human-in-the-Loop (senior dev approve).

10. Chọn Pattern nào? — Framework ra quyết định

11. Bài học từ Production 2026

Dựa trên các benchmark và case study thực tế (LOCOMO Dataset, LongMemEval), một số insight quan trọng cho developer:

Bài học #1: Kiến trúc đúng quan trọng hơn model mạnh. Một agent ReAct với guardrails chặt chẽ trên Claude Haiku thường outperform một agent không có pattern rõ ràng trên Claude Opus.

Bài học #2: Bắt đầu với Orchestrator-Worker cho multi-agent. Hierarchical và graph topology là hai pattern multi-agent duy nhất chứng minh được giá trị trong production. Swarm và blackboard hiếm khi outperform trong thực tế.

Bài học #3: Hybrid là default. Phần lớn hệ thống production dùng kết hợp nhiều pattern — ví dụ hierarchical system nơi các team lá dùng mesh coordination nội bộ, hoặc pipeline nơi một stage khởi chạy swarm cho parallel data collection.

12. Kết luận

7 Agentic Design Patterns không phải là danh sách tính năng để implement hết — mà là một bộ công cụ tư duy giúp bạn chọn đúng kiến trúc cho đúng bài toán. Trong thời đại LLM đủ mạnh để thực hiện hầu hết tác vụ, yếu tố phân biệt giữa demo thất bại và production thành công nằm ở cách bạn tổ chức luồng suy luận, hành động, và phản hồi của agent.

Tóm lược nhanh:

• Tool Use — nền tảng bắt buộc, kết nối agent với thế giới thực
• ReAct — vòng lặp suy luận-hành động cho tác vụ mở
• Reflection — tự phản biện để nâng cao chất lượng output
• Planning — phân rã trước, tối ưu chi phí sau
• Multi-Agent — phối hợp chuyên gia khi single-agent không đủ
• Sequential — pipeline đáng tin cậy cho quy trình ổn định
• Human-in-the-Loop — checkpoint an toàn cho quyết định quan trọng

Hãy nhớ nguyên tắc cốt lõi: bắt đầu đơn giản, đo lường kết quả, và chỉ thêm complexity khi dữ liệu thực tế yêu cầu.

Tham khảo

• The 7 Agentic AI Design Patterns Every Developer Should Know — DEV Community
• Agent Orchestration Patterns: Swarm vs Mesh vs Hierarchical — GurusUp
• Agent Architecture Patterns: 2026 Taxonomy Guide — Digital Applied
• Agentic AI Design Patterns: ReAct, ReWOO, CodeAct, and Beyond — Capabl
• Multi-Agent Orchestration Patterns: Complete Guide 2026 — Fastio