Dàn dựng multi-agent — ai chỉ huy, ai vẽ?

Một agent thì dễ. Năm agent chạy cùng lúc mà không đạp lên nhau — đó mới là bài toán thật sự.

Bao nhiêu agent thì đủ?

Câu hỏi này mình nhận được ít nhất ba lần trong tháng qua, từ ba team khác nhau. Và cả ba đều mắc cùng một lỗi: tách mỗi task thành một agent riêng, rồi thắc mắc sao ghép lại thì loạn.

Agent load data chạy xong chưa kịp trả kết quả — agent thống kê đã nhảy vào xử lý. Agent vẽ chart nhận data sai format. Agent viết report thì bám vào dataset cũ từ lần chạy trước.

Bạn có thể build 10 agent đỉnh cao. Nhưng nếu không có orchestration layer — không ai giữ nhịp — thì đống agent đó chẳng khác gì mười người vẽ chung một bức tranh mà không ai thấy bản phác thảo.

Khoan — chuyện phức tạp hơn "gọi A xong gọi B"

Nói thẳng ra thì multi-agent orchestration có ít nhất ba vấn đề mà hầu hết tutorial lướt qua:

Shared state — ai giữ bức tranh tổng thể?

Khi nhiều agent cùng thao tác trên một bộ data, câu hỏi đầu tiên: data sống ở đâu? Google ADK giải quyết bằng cách tạo một DataStore trung tâm — mọi agent đọc/ghi vào đó. SmolAgents đi hướng khác: mỗi agent có memory tool riêng, agent chính (CodeAgent) tự quản lý trạng thái qua code execution.

Framework nào cũng được, nhưng câu hỏi vẫn giống nhau: state nằm ở đâu, ai được ghi, và khi hai agent ghi cùng lúc thì chuyện gì xảy ra?

Routing — task nào về tay ai?

Google ADK dùng "master analyst agent" làm dispatcher — nhận yêu cầu, phân tích, chuyển cho đúng specialist. PaperOrchestra (Google Research) cũng theo pattern tương tự cho việc tự động viết paper. OpenClaw — một project open-source đang được chú ý — cho phép multi-agent routing qua plugin architecture với giao thức A2A (Agent-to-Agent), linh hoạt hơn nhưng debug cũng cay hơn đáng kể.

Error propagation — domino effect

Đây là thứ mà demo nào cũng bỏ qua. Giả sử agent thống kê trả kết quả lỗi vì dataset có null values. Agent vẽ chart không biết, cứ vẽ. Agent report không biết, cứ viết. Kết quả: một báo cáo đẹp mắt với số liệu sai hoàn toàn. Bạn sẽ không phát hiện cho đến khi sếp hỏi "sao số này khác Excel?"

Thực tế từ hai team quen

Pipeline phân tích dữ liệu bán hàng

Giả sử team bạn 5 người, chạy báo cáo tuần từ data bán hàng. Thay vì notebook Jupyter 500 dòng mà chỉ một người hiểu, bạn tách thành: agent loader đọc CSV, agent analyst chạy mean/correlation/outlier detection, agent visualizer tạo chart, agent reporter tổng hợp thành text.

Google ADK cho setup kiểu này khá nhanh — mỗi agent là một function Python được wrap lại. Điểm hay: bạn swap agent bất kỳ lúc nào — đổi visualizer từ matplotlib sang plotly mà không ảnh hưởng phần còn lại.

Hệ thống support ticket tự động

Một team ở TP.HCM mình quen đang build bằng SmolAgents: agent phân loại ticket, agent tra cứu knowledge base (đúng kiểu RAG mà mình đã bàn nhiều ở các bài trước), agent soạn draft reply. Họ chọn ToolCallingAgent cho phân loại vì cần output có cấu trúc, còn CodeAgent cho tra cứu vì cần linh hoạt.

Bài học hay nhất từ team này: đừng ép mọi agent dùng cùng một paradigm. Có agent cần chạy code tự do, có agent cần bị giữ trong khuôn khổ tool calling.

Thử ngay chiều nay

Bạn không cần cả hệ thống production để nếm thử multi-agent:

Bước 1: pip install google-adk (hoặc pip install smolagents nếu thích hướng Hugging Face)

Bước 2: Tạo DataStore chung — đây là tấm canvas mà mọi agent cùng vẽ lên:

class DataStore:
    def __init__(self):
        self.datasets = {}

    def save(self, name, df):
        self.datasets[name] = df

    def get(self, name):
        return self.datasets.get(name)

Bước 3: Viết 2 agent đơn giản — một load data, một mô tả data. Mỗi agent nhận DataStore làm dependency.

Bước 4: Tạo master agent dùng LLM để quyết định gọi agent nào dựa trên câu hỏi người dùng.

Bước 5: Test: "Load file sales.csv rồi cho mình trung bình doanh thu." Quan sát master agent có route đúng thứ tự không.

Mục tiêu buổi chiều: cảm nhận cái flow request vào, routing, execution, kết quả quay về. Chưa cần production-ready.

Bẫy phổ biến: agent inflation

Mình đặt tên cho lỗi này là "agent inflation" — thấy task nào cũng muốn tạo agent riêng. 5 task? 5 agent. 20 task? 20 agent, mỗi đứa một prompt, một config, một failure mode.

Quy tắc mình hay dùng: bắt đầu với 2-3 agent. Chỉ tách thêm khi thấy rõ bottleneck hoặc khi hai agent cần chạy song song nhưng đang block lẫn nhau. Đôi khi một agent tốt với nhiều tool hiệu quả hơn hẳn năm agent chuyên biệt.

Open-source đáng để trên radar

Không framework nào vừa vẽ chi tiết vừa phủ nền được — chọn theo bài toán, không theo hype.

Đúc kết

Multi-agent khó ở chỗ dàn dựng, không phải ở chỗ build từng agent. Trước khi thêm agent thứ tư, hãy chắc ba agent đầu đã thật sự phối hợp được với nhau.

Plot twist: hệ thống multi-agent hiệu quả nhất mình từng thấy — chỉ có hai agent.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo