---
title: "Multi-agent là gì? Khi nào một agent không đủ và 3 cách chia việc"
description: "Multi-agent là gì: mạnh ở bài toán rộng chạy được song song, nhưng chỉ nên tách khi phần việc làm độc lập được và bù nổi chi phí token."
canonical: "https://200lab.io/blog/multi-agent-la-gi"
published: "2026-11-06T12:59:34Z"
updated: "2026-11-06T13:47:50Z"
authors: ["Việt Trần"]
tags: ["AI", "Agent"]
reading_minutes: 12
access: "public"
---

Nhiều anh em mới làm sản phẩm hay nghĩ cứ thêm agent là hệ thống mạnh hơn. Với bài toán rộng thì đúng có lúc như vậy. Nhưng hệ multi-agent tốn token hơn nhiều so với một agent đơn lẻ.

Chuyện đáng bàn là khi nào bạn thật sự cần tách nhỏ nhiệm vụ, và tách thế nào cho hợp lý.

## Multi-agent là gì và khác single agent ở chỗ nào

Nếu bạn đã tìm hiểu [khái niệm AI agent cơ bản](https://200lab.io/blog/ai-agent-la-gi), bạn biết mỗi agent là một LLM tự dùng tool trong vòng lặp.

Cần tách hai khái niệm này cho rõ. Với **workflow**, LLM và tool được điều phối theo đường code định sẵn. Với **agent**, LLM tự quyết định quy trình. Các cách chia việc trong bài này đều thuộc nhóm hệ thống agentic.

Với **single agent**, một agent nhận việc, tự chọn bước tiếp theo, gọi tool, xem kết quả rồi đi tiếp trong cùng một context. **Multi-agent** thì nhiều agent phối hợp để giải quyết bài toán. Khác nhau như một đầu bếp tự nấu hết các món, so với bếp nhà hàng chia nhiều trạm riêng.

Trong Claude Code, mỗi **subagent** là một agent phụ chạy trong context window riêng. Nó có system prompt, quyền truy cập tool và quyền hạn độc lập. Cả cụm đó tạo thành [phần khung riêng quanh model](https://200lab.io/blog/phan-biet-agent-va-harness).

Subagent làm phần việc phụ trong context của nó, rồi chỉ trả bản tóm tắt về cuộc trò chuyện chính. Context chính nhờ vậy không bị ngập kết quả tìm kiếm, log hay nội dung file không dùng lại.

Mỗi lần giao việc giữa các agent là một lần bàn giao (handoff). Thông tin nào bạn không ghi vào brief giao việc thì agent nhận sẽ không có. Subagent của Claude Code luôn bắt đầu với context trống: nó không thấy lịch sử trò chuyện trước đó, chỉ đọc được tin giao việc do agent chính viết ra.

## Khi nào cần nhiều agent: nhiều hướng song song, context lớn, tách quyền

Multi-agent hợp với nhiệm vụ giá trị cao, chia song song được nhiều phần, lượng thông tin vượt quá một context window, và phải làm việc với nhiều tool phức tạp. Nó mạnh nhất ở những câu hỏi rộng, cần tìm hiểu nhiều hướng độc lập cùng lúc.

Trong một đánh giá nghiên cứu nội bộ, hệ multi-agent gồm một **lead agent** điều phối và nhiều subagent cho kết quả tốt hơn 90,2% so với một single agent dùng cùng model mạnh nhất.

Chẳng hạn khi cần tìm toàn bộ thành viên hội đồng quản trị của các công ty Công nghệ thông tin trong S&P 500, hệ multi-agent làm được nhờ chia nhỏ cho các subagent. Single agent thất bại vì tìm tuần tự quá chậm.

Multi-agent hiệu quả chủ yếu vì nó cho phép dùng đủ lượng token để giải quyết bài toán. Mỗi agent có context window riêng, nên tổng dung lượng suy luận song song của cả hệ thống tăng lên.

Tách agent còn để tách biệt quyền hạn và giới hạn tool của từng subagent. Ví dụ, một subagent chuyên review code chỉ được cấp quyền đọc qua `Read`, `Grep` và `Glob`, không được sửa file. Cách làm này sát với bài [phân quyền cho AI agent](https://200lab.io/blog/cho-bot-quyen-gi-phan-quyen-ai-agent).

File cấu hình một subagent review code chỉ đọc trông như thế này:

```markdown
---
# .claude/agents/code-reviewer.md
name: code-reviewer
description: Reviews code for quality and security. Use after code changes.
# Read-only: no Edit or Write, so this subagent cannot change files
tools: Read, Grep, Glob
model: sonnet
---

You are a code reviewer. Read the changed files, list issues by priority,
and return a short summary with file paths and line numbers.
```

## Khi nào một agent là đủ

Theo mình, cứ tìm giải pháp đơn giản nhất trước. Chỉ thêm độ phức tạp khi nó cải thiện kết quả rõ ràng, đo được. Đôi khi bạn chẳng cần hệ thống agentic nào cả: tối ưu một lần gọi LLM, kết hợp truy xuất thông tin, rồi đưa vài ví dụ vào prompt là đủ.

Về chi phí, một agent thường dùng gấp khoảng 4 lần token so với chat thông thường. Hệ multi-agent dùng gấp khoảng 15 lần. Chia nhiều agent chỉ đáng công khi giá trị nhiệm vụ đủ cao để bù khoản đó.

Những việc đòi hỏi các agent chia sẻ chung context, hoặc phụ thuộc chặt vào nhau, cũng chưa hợp multi-agent. Phần lớn công việc lập trình có ít phần chạy song song được hơn so với nghiên cứu. Các agent hiện tại chưa giỏi phối hợp theo thời gian thực.

Với Claude Code, giữ việc ở cuộc trò chuyện chính khi bạn cần trao đổi hoặc sửa chữa nhiều vòng. Khi lên kế hoạch, viết code và chạy test dùng chung nhiều context, hoặc khi chỉ cần sửa nhanh một chỗ nhỏ, một agent làm tốt hơn. Cách này cũng giảm độ trễ, vì subagent mới luôn bắt đầu từ đầu và tốn thời gian lấy lại context.

Trước khi quyết định tách thêm agent, bạn có thể hỏi nhanh bốn câu:

1. Phần việc tách ra có làm độc lập được và trả về được bản tóm tắt rõ ràng không?
2. Các phần việc có tránh được cảnh chờ đợi hoặc phụ thuộc chặt vào nhau không?
3. Giá trị nhiệm vụ có đủ cao để trả cho chi phí token tăng gấp nhiều lần không?
4. Bạn đã đo kết quả của phiên bản một agent để làm mốc so sánh chưa?

## Cách chia việc orchestrator-worker: một agent điều phối nhiều worker

Với **orchestrator-worker**, một LLM trung tâm (orchestrator) linh hoạt chia nhỏ nhiệm vụ, giao cho các agent thực thi (worker), rồi tổng hợp kết quả.

Khác với chạy song song thông thường, các phần việc không định sẵn từ trước. Orchestrator tự quyết định cách chia tùy từng đầu vào. Cách này hợp với những nhiệm vụ không đoán trước được cần tách thành những phần nào. Ví dụ: sửa code trên nhiều file mà số lượng file lẫn kiểu sửa đều phụ thuộc từng yêu cầu, hoặc gom và phân tích thông tin từ nhiều nguồn.

Theo bài [How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system), hệ Research dùng một lead agent để phân tích câu hỏi, lên chiến lược và tạo các subagent tìm kiếm song song từng khía cạnh. Lead agent lưu kế hoạch vào bộ nhớ ngoài để tránh bị cắt mất khi context quá dài, nhận kết quả, quyết định xem có cần tìm thêm không, rồi chuyển cho CitationAgent gắn trích dẫn trước khi trả đoạn text trả lời cho người dùng.

Một vòng điều phối đi như sau:

```mermaid
flowchart TD
    U["Câu hỏi của người dùng"] --> L["Lead agent: lên kế hoạch, lưu vào bộ nhớ"]
    L --> S1["Subagent 1"]
    L --> S2["Subagent 2..N"]
    S1 -- "Tóm tắt" --> G["Lead agent: tổng hợp kết quả"]
    S2 -- "Tóm tắt" --> G
    G -- "Thiếu" --> L
    G -- "Đủ thông tin" --> C["CitationAgent: gắn trích dẫn"]
    C --> R["Báo cáo gửi người dùng"]
```

## Cách chia việc chạy song song rồi gộp kết quả

Cách này cho nhiều LLM làm việc cùng lúc, rồi gộp kết quả bằng code. Có hai biến thể: **sectioning** (chia nhiệm vụ thành các phần độc lập chạy cùng lúc) và **voting** (chạy cùng một nhiệm vụ nhiều lần để lấy các kết quả khác nhau).

Với sectioning, bạn có thể cho một model tạo đoạn text trả lời trong khi model khác chạy song song để lọc nội dung không phù hợp. Hoặc khi đánh giá prompt, mỗi lần gọi model chấm điểm một khía cạnh riêng.

Với voting, bạn dùng nhiều prompt khác nhau cùng lúc để review code tìm lỗ hổng bảo mật. Prompt nào thấy vấn đề thì gắn cờ cảnh báo.

Với việc phức tạp nhiều khía cạnh, LLM thường làm tốt hơn khi mỗi khía cạnh do một lần gọi riêng xử lý. Khi triển khai tách nhánh rồi gộp bằng code, bước gộp cuối cùng cần biết rõ mỗi kết quả trả về thuộc phần việc nào.

```mermaid
flowchart TD
    subgraph SEC["Sectioning: chia phần độc lập"]
        I1["Đầu vào"] --> A1["Phần A"]
        I1 --> A2["Phần B"]
        A1 --> M1["Gộp bằng code theo từng phần"]
        A2 --> M1
    end
    subgraph VOTE["Voting: lặp cùng một việc"]
        I2["Đoạn code cần review"] --> V1["Prompt 1"]
        I2 --> V2["Prompt 2"]
        V1 --> M2["Gộp phiếu: có prompt gắn cờ thì báo"]
        V2 --> M2
    end
    SEC ~~~ VOTE
```

## Cách chia việc theo chuỗi: prompt chaining, routing và bàn giao

**Prompt chaining** chia nhiệm vụ thành các bước nối tiếp, bước sau xử lý kết quả của bước trước. Bạn có thể chèn bước kiểm tra bằng code ở giữa để giữ quy trình đi đúng hướng. Cách này đánh đổi độ trễ lấy độ chính xác, vì mỗi bước nhỏ dễ làm hơn. Ví dụ quen thuộc: cho agent viết dàn ý, kiểm tra đã đạt tiêu chí chưa, rồi mới viết bài hoàn chỉnh.

**Routing** phân loại đầu vào rồi chuyển sang nhánh chuyên biệt. Với ticket hỗ trợ khách hàng, hệ thống phân loại thành câu hỏi chung, yêu cầu hoàn tiền hoặc hỗ trợ kỹ thuật. Mỗi nhánh có sẵn prompt và bộ tool riêng.

Claude Code cũng cho phép nối các subagent với nhau. Ví dụ, một subagent review code tìm vấn đề hiệu năng, rồi agent chính chuyển context liên quan sang cho subagent tối ưu sửa code.

Rủi ro lớn nhất ở mỗi lần nối tiếp: nếu tin bàn giao thiếu thông tin, bước sau sẽ làm sai ngay.

Với ticket hỗ trợ, routing và prompt chaining ghép lại như sau:

```mermaid
flowchart TD
    T["Ticket hỗ trợ"] --> R{"Routing: phân loại"}
    R --> B["Nhánh chuyên biệt: chung, hoàn tiền hoặc kỹ thuật"]
    B --> D["Soạn đoạn text trả lời"]
    D --> GATE{"Gate: kiểm tra bằng code"}
    GATE -- "Chưa đạt" --> D
    GATE -- "Đạt" --> S["Gửi khách"]
```

Gom lại thành bảng cho dễ nhìn:

| Cách chia việc | Hợp khi | Cần chú ý |
| --- | --- | --- |
| Orchestrator-worker | Không đoán trước được cách chia, số phần việc phụ thuộc đầu vào như tìm kiếm rộng hoặc sửa code nhiều file. | Cần lưu kế hoạch ra bộ nhớ ngoài nếu context quá dài và tốn nhiều token điều phối. |
| Chạy song song rồi gộp | Các phần việc tách biệt rõ (sectioning) hoặc cần chạy nhiều lần đối chiếu kết quả như rà lỗi bảo mật (voting). | Bước gộp bằng code phải biết chính xác mỗi kết quả trả về thuộc phần việc nào. |
| Chuỗi tuần tự và bàn giao | Chia được thành từng bước cố định có kiểm tra ở giữa, hoặc cần phân loại đầu vào về nhánh chuyên biệt. | Độ trễ tăng do chạy nối tiếp và bước sau sẽ làm sai nếu thiếu thông tin bàn giao. |

## Lỗi hay gặp khi chia việc cho nhiều agent và cách xử lý

Chia việc cho nhiều agent, bạn rất dễ gặp cảnh các agent dẫm chân lên nhau hoặc làm sai ý ban đầu. Năm lỗi hay gặp và cách xử lý:

1. **Brief giao việc quá ngắn.** Ban đầu lead agent chỉ giao lệnh ngắn kiểu "research the semiconductor shortage". Một subagent đi tìm khủng hoảng chip ô tô trước đây, còn hai subagent khác lại tìm trùng nhau về chuỗi cung ứng hiện tại. Mỗi subagent cần được cấp rõ mục tiêu, định dạng kết quả, hướng dẫn dùng tool, nguồn dữ liệu và giới hạn công việc. Toàn bộ brief, tool và quyền hạn này chính là phần khung; bạn có thể đọc thêm trong bài [agent harness là gì](https://200lab.io/blog/agent-harness-la-gi).
2. **Không chỉnh số agent theo độ khó của việc.** Phiên bản đầu tiên có lúc tự tạo tới 50 subagent chỉ cho một câu hỏi đơn giản. Cách xử lý là ghi thẳng quy tắc vào prompt: tìm một dữ kiện đơn giản chỉ cần 1 agent với 3 đến 10 lần gọi tool; so sánh trực tiếp cần 2 đến 4 subagent, mỗi subagent 10 đến 15 lần gọi; nghiên cứu phức tạp mới dùng hơn 10 subagent và phân chia trách nhiệm rõ ràng.
3. **Thông tin méo dần qua nhiều tầng.** Kết quả truyền qua nhiều agent dễ rơi rụng chi tiết như trò truyền tin. Cho subagent ghi thẳng kết quả ra hệ thống lưu trữ ngoài như file, rồi chỉ gửi tham chiếu nhẹ về cho agent điều phối. Cách này giảm mất thông tin và đỡ tốn token chép lại qua lịch sử trò chuyện.
4. **Mô tả tool kém khiến agent chọn nhầm công cụ.** Mỗi tool cần có mục đích riêng và mô tả rõ. Cho agent nguyên tắc phải xem hết các tool có sẵn trước, chọn tool khớp ý định người dùng, và ưu tiên tool chuyên biệt hơn tool chung.
5. **Khó đánh giá kết quả của hệ thống.** Cùng một đầu vào, các agent có thể đi nhiều đường khác nhau mà vẫn hợp lệ, nên khó chấm điểm. Bắt đầu đánh giá ngay với khoảng 20 câu hỏi đại diện cho cách dùng thật, dùng LLM làm giám khảo chấm theo tiêu chí, kết hợp người kiểm tra thủ công để bắt các ca máy bỏ sót. Nếu agent làm thay đổi trạng thái thì chỉ chấm trạng thái cuối, không chấm từng bước.

Nếu bạn muốn đi sâu chuyện một lần bàn giao cần mang theo gì và khi nào nên tách thêm agent, khóa Agent Harness Foundations của 200Lab có bài "Multi-agent: thêm một Agent là thêm một lần bàn giao".

![Agent Harness Foundations](https://assets.200lab.io/sha256/7d/7d10dab27b878eeb97b71bf30112001ee144303e521c32d1aa20dd5466b2f6d8/generations/3b7588991172f063d96597212486357a0e018d60bec854c770c2a5546b206488)

- [Agent Harness Foundations](https://200lab.io/courses/agent-harness-foundations.md)

Thêm một agent là thêm một lần bàn giao. Theo mình, chỉ tách khi phần việc đó thật sự làm độc lập được.

## Đọc thêm

- [Cách nhờ Grok Bot lọc khách quen và soạn nháp tin hỏi thăm](https://200lab.io/blog/grok-bot-repeat-customer-check-in.md): Soạn tin hỏi thăm khách quen bằng Grok Bot: bot lọc khách theo thời gian cháy, ghi rõ cách tính và chỉ viết nháp để bạn đọc lại rồi tự gửi.
- [Cách nhờ Grok Bot viết checklist đóng gói đơn hàng cho người mới](https://200lab.io/blog/grok-bot-packing-checklist.md): Soạn checklist đóng gói bằng Grok Bot từ lời kể lộn xộn của chủ shop: bot xếp rõ từng việc cho người thời vụ, hỏi lại chỗ thiếu và chỉ bám sát ý bạn.
- [Hướng dẫn nhờ Grok Bot và Jev phân loại email Gmail mỗi sáng cho shop nhỏ](https://200lab.io/blog/grok-bot-gmail-inbox-triage.md): Phân loại email bằng Grok Bot và Jev: Jev gắn nhãn kèm confidence, Grok Bot tóm tắt và soạn nháp, ca ngoài quy định chờ chủ shop, bot không tự gửi thư.
- [Embedding là gì? Chạy thử và chọn embedding model cho RAG tiếng Việt](https://200lab.io/blog/embedding-la-gi.md): Embedding là gì và vì sao quyết định RAG tìm đúng hay sai? Tạo vector embedding bằng Python, đo cosine similarity, so sánh và chọn embedding model tiếng Việt.
- [Cách nhờ Grok Bot trả kết quả kiểm tra được trước khi giao việc](https://200lab.io/blog/grok-bot-reviewable-results.md): Nhờ Grok Bot trả kết quả kiểm tra được bằng cách đặt trước bảng có link nguồn, giờ xem và tách 5 phần để biết đâu là số liệu thật, đâu là điều bot đoán.
- [Mọi bài viết chủ đề AI](https://200lab.io/blog/tags/ai.md)

Toàn bộ nội dung: https://200lab.io/llms.txt