Workflow hay Agent? 5 pattern từ Anthropic để chọn đúng kiến trúc

“Agent” là từ khoá nóng nhất trong AI hiện nay, đến mức nhiều team bắt đầu mọi dự án bằng câu “mình làm một agent nhé”. Bài viết “Building effective agents” của Anthropic (Erik Schluntz và Barry Zhang, tháng 12/2024) — tổng kết từ hàng chục team triển khai thực tế — đưa ra lời khuyên ngược lại: phần lớn hệ thống thành công dùng các pattern đơn giản, ghép được với nhau, không phải framework phức tạp. Bài này tóm lại phân biệt workflow/agent và 5 pattern nền tảng.

Workflow và Agent khác nhau thế nào?

Cả hai đều xây trên một khối cơ bản: “augmented LLM” — một LLM được bổ sung retrieval, tool và bộ nhớ.

5 pattern workflow

1. Prompt chaining — chuỗi bước

Chia việc thành chuỗi bước cố định, đầu ra bước trước là đầu vào bước sau; có thể chèn “cổng kiểm tra” bằng code giữa các bước.

• Dùng khi: việc chia được thành các bước rõ ràng, chấp nhận chậm hơn để chính xác hơn.
• Ví dụ: viết dàn ý → kiểm tra dàn ý đạt tiêu chí → viết bài theo dàn ý → dịch.

2. Routing — phân luồng

Phân loại đầu vào rồi chuyển tới nhánh chuyên biệt có prompt/tool riêng.

• Dùng khi: đầu vào thuộc các nhóm khác biệt rõ và phân loại đủ tin cậy.
• Ví dụ: ticket hỗ trợ → kỹ thuật / hoá đơn / góp ý; câu hỏi dễ → model nhỏ, câu khó → model lớn.

3. Parallelization — song song

Hai biến thể: sectioning (chia việc thành phần độc lập chạy song song) và voting (chạy cùng một việc nhiều lần để lấy đa số hoặc tăng độ tin cậy).

• Dùng khi: các phần độc lập, cần nhiều góc nhìn, hoặc cần tốc độ.
• Ví dụ: review code theo 3 tiêu chí cùng lúc; một luồng trả lời người dùng trong khi luồng khác kiểm duyệt nội dung; 3 lần đánh giá lỗ hổng rồi lấy đa số.

4. Orchestrator-workers — điều phối viên và thợ

Một LLM trung tâm phân tích việc, tự quyết định chia thành những phần nào, giao cho các worker, rồi tổng hợp.

• Dùng khi: không đoán trước được các việc con.
• Ví dụ: sửa code ở nhiều file chưa biết trước; nghiên cứu cần tìm từ nhiều nguồn.

5. Evaluator-optimizer — tạo và chấm

Một LLM tạo kết quả, một LLM khác chấm và góp ý, lặp lại tới khi đạt.

• Dùng khi: có tiêu chí đánh giá rõ và vòng góp ý cải thiện được kết quả đo lường được.
• Ví dụ: dịch thuật có sắc thái; viết lại cho đạt checklist; tìm kiếm phức tạp cần nhiều vòng.

Khi nào mới cần agent?

• Bài toán mở, không đoán trước được số bước (debug, nghiên cứu, coding).
• Môi trường có phản hồi rõ ràng để agent tự kiểm — test pass/fail, kết quả tool, lỗi compile.
• Chấp nhận chi phí cao hơn và có guardrail: giới hạn số vòng, sandbox, điểm dừng chờ người duyệt.

Hai lĩnh vực bài viết nêu là phù hợp với agent: hỗ trợ khách hàng (hội thoại + hành động qua tool, có tiêu chí thành công rõ) và coding agent (kết quả kiểm chứng được bằng test tự động).

Ba nguyên tắc khi xây agent

1. Đơn giản: giữ thiết kế tối giản; framework có thể giúp bắt đầu nhanh nhưng dễ che giấu prompt và phản hồi bên dưới, khiến debug khó hơn. Hiểu rõ code bên dưới nếu dùng framework.
2. Minh bạch: cho thấy các bước lập kế hoạch của agent.
3. Thiết kế giao diện agent–máy (ACI) cẩn thận: đầu tư vào mô tả tool, tài liệu và kiểm thử tool như đầu tư vào giao diện người dùng — đặt tên rõ, ví dụ, trường hợp biên, định dạng tham số dễ dùng cho model.

Chọn kiến trúc: cây quyết định nhanh

Một lần gọi LLM tốt (kèm retrieval + ví dụ) đã đủ?   → Dừng ở đó.
Các bước cố định, biết trước?                         → Prompt chaining.
Đầu vào chia nhóm rõ?                                 → Routing.
Các phần độc lập / cần nhiều góc nhìn?                → Parallelization.
Việc con không biết trước?                            → Orchestrator-workers.
Có tiêu chí chấm rõ, cần nhiều vòng chỉnh?            → Evaluator-optimizer.
Bài toán mở, có phản hồi tự kiểm, chấp nhận chi phí? → Agent (có guardrail).

Áp dụng thế nào?

• Dev: Trước khi viết agent, thử giải bài toán bằng 1–2 pattern workflow. Chỉ chuyển sang agent khi đo được workflow không đủ.
• Tech Lead: Dùng 5 pattern làm “từ vựng chung” trong design review: “phần này là routing, phần kia là evaluator-optimizer” giúp cả team hiểu nhanh.
• PM: Khi team đề xuất “làm agent”, hỏi: “một workflow cố định có giải được 80% trường hợp không?”. Workflow rẻ hơn, dự báo được chi phí và thời gian hơn.