Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 1 — Khi nào cần nhiều agent, khi nào một agent là đủ

Đã đọc 0/8 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Sai lầm phổ biến nhất khi mới học multi-agent là nhảy thẳng vào chia agent trước khi cần. Nhiều team dựng 5 agent cho một tác vụ mà một agent + vài tool đã giải quyết gọn gàng, kết quả là chậm hơn, tốn token gấp 3, và cực khó debug. Bài này cho bạn một khung quyết định rõ ràng.

Multi-agent thực sự là gì

Một "agent" là một vòng lặp LLM có khả năng gọi tool và tự quyết bước tiếp theo. Multi-agent nghĩa là nhiều vòng lặp LLM riêng biệt, mỗi cái có prompt/hệ thống, bộ tool và bộ nhớ riêng, phối hợp với nhau qua các thông điệp (hand-off). Điểm mấu chốt: mỗi agent là một ranh giới ngữ cảnh độc lập.

Ví dụ cụ thể: hệ thống viết báo cáo thị trường

Giả sử bạn xây trợ lý viết báo cáo phân tích đối thủ. Một agent duy nhất phải: (1) lập dàn ý, (2) tìm dữ liệu web, (3) tổng hợp, (4) tự kiểm tra số liệu. Khi nhồi hết vào một prompt, agent hay "quên" bước kiểm tra vì context đã đầy. Tách thành Planner (lập dàn ý), Researcher (thu thập), Writer (viết), Critic (soi lỗi) thì mỗi agent gọn ngữ cảnh và làm tốt phần của mình.

Nhưng nếu tác vụ chỉ là "tóm tắt 1 file PDF", thì một agent + tool đọc file là quá đủ — thêm agent chỉ tổ rối.

Khung quyết định: 5 câu hỏi

1. Tác vụ có nhiều VAI TRÒ khác nhau về kỹ năng/persona không?
   (VD: người tìm dữ liệu vs người phản biện)  -> có: cân nhắc tách
2. Ngữ cảnh có quá lớn cho một agent (>50% context window)? -> có: tách
3. Có bước cần GÓC NHÌN ĐỘC LẬP (critic không nên thấy quá trình
   sinh ra để tránh thiên vị)? -> có: tách
4. Các bước có chạy SONG SONG được không? -> có: tách để tăng tốc
5. Có cần chính sách/quyền tool KHÁC NHAU cho từng phần? -> có: tách

Nếu <2 câu "có": DÙNG MỘT AGENT + nhiều tool.

Chi phí ẩn của multi-agent

Mỗi lần hand-off là một lần mất mát thông tin: agent nhận chỉ thấy được thứ bạn truyền cho nó, không thấy toàn bộ suy luận trước đó. Điều này vừa là ưu điểm (cô lập ngữ cảnh) vừa là nhược điểm (dễ hiểu sai ý). Ngoài ra: chi phí token nhân lên theo số agent, độ trễ cộng dồn nếu chạy tuần tự, và bề mặt lỗi rộng hơn.

Các bước áp dụng cho dự án của bạn

  • Viết ra tác vụ end-to-end thành một chuỗi bước cụ thể.
  • Gắn nhãn mỗi bước bằng "vai trò" (planner/research/write/review/execute).
  • Chạy khung 5 câu hỏi ở trên cho toàn tác vụ.
  • Nếu quyết định dùng một agent, liệt kê các tool cần thiết thay vì các agent.
  • Nếu quyết định multi-agent, vẽ sơ đồ ai gọi ai (hand-off graph) TRƯỚC khi code.
  • Bắt đầu bằng phiên bản đơn giản nhất có thể chạy, rồi mới tách thêm khi thấy nghẽn thật.

Checklist "đã sẵn sàng tách agent chưa"

  • [ ] Tôi đã thử một-agent và xác định được điểm nghẽn cụ thể.
  • [ ] Mỗi agent dự kiến có một trách nhiệm rõ, phát biểu được trong một câu.
  • [ ] Tôi biết đầu vào/đầu ra (schema) của từng hand-off.
  • [ ] Tôi có tiêu chí đo "tốt hơn" (độ chính xác, độ trễ, chi phí).

Sai lầm thường gặp

  • Tách agent theo bước kỹ thuật thay vì theo vai trò. "Agent gọi API" không phải một vai trò — đó là một tool. Vai trò là ai chịu trách nhiệm ra quyết định gì.
  • Dựng multi-agent khi chưa từng chạy một-agent. Bạn sẽ không biết mình đang giải quyết vấn đề gì.
  • Bỏ qua chi phí độ trễ. 4 agent tuần tự = 4 lần round-trip LLM; người dùng chờ mòn mỏi.
  • Cho rằng nhiều agent = thông minh hơn. Thêm agent chỉ giúp khi nó cô lập được ngữ cảnh hoặc thêm góc nhìn độc lập — nếu không, nó chỉ thêm nhiễu.
Bài sau ta sẽ đi vào ba vai trò kinh điển planner/worker/critic — nền tảng của gần như mọi hệ multi-agent thực tế.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi